Is a Definition Just a List of Attributes?

If we look at a data model, is a definition of an entity type automatically produced by listing the attributes of the entity type?  If this were true then a data modeler would not need to produce entity definitions - he or she would simply need to identify and list a sufficient number of attributes.  I have actually heard data modelers being criticized by terminologists for doing just this.  The extent to which such criticism is fair or not is a separate discussion, but the question remains as to whether a list of attributes can suffice as a definition.

I do not think that a list of attributes is sufficient based on the recent discussions about concept systems in this blog.  No concept exists in isolation.  Every concept exists in some kind of concept system where it has relationships to other concepts.  At least some of these relationships and/or related concepts have to enter into a definition so that the concept being defined can be located properly in a concept system, which appears to be necessary for knowledge.

A list of attributes usually will not distinguish between those that are determining for the concept under consideration, and those which are not - some of which may be shared with other concepts.  Thus, just reviewing a list of attributes becomes a test of figuring out which ones are pertinent to a definition.  This surely defeats the practical aspects of definition.

It would seem therefore that something more than a list of attributes is required to produce a quality definition.  While many data modelers do produce quality definitions, it can be seen that the practice of data modeling may present the temptation to just assume that the definition of an entity type is provided by the attributes captured for it.  Of course, relationships and other concepts are present in a data model, but it will need another blog to answer the question of whether a data model has enough information to produce a definition based on entity types, attributes, and relationships alone.

Generic vs. Partitive Concept Systems

For the past couple of blogs I have been exploring different types on concept systems.  I have found these discussed, oddly enough, not in the literature on data modeling, but in the literature on terminology work.  At this point, I want to look at the two major concept systems.  These are very abundant in the raw material of information management, and require special attention.

Generic:  This is the familiar supertype-subtype concept system, where a more generic concept encompasses a range of more specific concepts.  E.g. Animal - Chordate - Vertebrate - Mammal - Primate - Homo sapiens.  There are a couple of interesting properties of this concept system:

• Any instance found in a specific concept is also covered by a more general concept.  The more general concepts possess fewer attributes than the more specific ones, but every specific concept possesses the attributes of each "parent" generic concept.  
•  Intention is inversely related to extension.   That is, the greater the number of specifying characteristics (intension), the more restricted the population of instances that is covered by the concept (extension).

Partitive: This is the part-whole concept system.  The study of part-whole relationships is called mereology.  It seems a bit odd to have a named discipline for this type of concept system, but not for others.  Perhaps it is an artifact of the evolution of philosophy.  Anyway, an example of a part whole system would be the organs of the human body, such as brain, liver, pancreas, kidney, and so on.  To have a complete view of the human body we would have to include tissues, such as epithelium, blood, muscle, nerves, etc.  This concept system is totally unlike the generic one as the parts have quite different identities that do not share characteristics.  We also run into interesting problems such as denial that the whole is anything more than the sum of its parts.  To summarize its properties:

• Each concept in a partitive concept system covers a range of instances that are not found in any other concept in the system.  There is no overlap of instances among the concepts in the system, unlike the generic type of concept system.  
• There is no relation between extension and intension of the concepts in the system.  Each concept has characteristics, none of which apply to the system as a whole.

I think that understanding different types of concept system has been overlooked by data modelers. Presumably this is because the arrangement of boxes and lines in a data model does not look very different for a generic or a partitive concept system.

On Types of Concept System

In my previous blog I discussed the existence of different types of concept systems.  I have found these discussed, oddly enough, not in the literature on data modeling, but in the literature on terminology work.  I have not found discussion of concept systems in philosophy, but that might merely reflect my lack of education, reading in, and general knowledge of philosophy.

Before going further into types of concept systems, we need to establish what a concept system is.  Nordterm 8 Guide to Terminology by Heidi Suonuuti (ISBN 952-9794-14-2) states the following:

Concepts are not independent phenomena.  They are always related to other concepts in one way or another, and form concept systems which can vary from fairly simple to extremely complicated.  In terminology work, an analysis of the relations among concepts and an arrangement of them into concept systems, is a prerequisite for the successful drafting of definitions.

This is not a great definition of "concept system" but it is a good start.  The ISO 704 standard from ISO/TC 37/SC 1 tells us the following:

Concepts do not exist as isolated units of knowledge but always in relation to each other. Our thought processes constantly create and refine the relations between concepts, whether these relations are formally acknowledged or not. A set of concepts structured according to the relations among them is said to form a concept system. 

In organizing concepts into a concept system, it is necessary to bear in mind the subject field that gave rise to the concept and to consider the expectations and objectives of the target users. The subject field shall act as the framework within which the concept field, the set of thematically related but unstructured concepts, is established.

ISO 704 also states:

The terminology of a subject field is not an arbitrary collection of terms. The relevant concepts constitute a coherent concept system based on the relations existing between concepts. The unique position of each concept within a system is determined by the intension and the extension.

This is not the place to get into what is meant by a "subject field".  However, it does seem apparent that a concept system is a number of concepts and the relations between them.  This corresponds to what data modelers call a "conceptual data model", but which they should call a "conceptual model".  A conceptual model describes a set of business information as such, without any thought of how it might be stored as data.

A concept system also differs from a single relationship between two or more terms.   Baldwin's Dictionary of Philosophy defines "relation" in logic as follows:

The mutual dependence of two or more subjects upon a common principle, fact, or truth, of such a kind that any assertion regarding one modifies the meaning of the other.  Accordingly, the predicate is true or false of one taken not independently or in isolation, but only in reference, regard, or respect to the other.  

The way in which a concept system differs from a relationship is that a concept system contains many relationships.

So we have some idea of what a concept system is.   What is interesting is that concept systems are not all of different kinds, but are distributed in types.  This idea is found in terminology work, but does not seem to be found in data modeling.  Perhaps this is because data models are oriented to building databases for data storage, and not for describing business information.    

If there are types of concept system, then each type should have its own properties.  Understanding these properties might help us work with concept systems and hence with definitions.   Data modelers do not seem to have contributed much if any thought about types of concept systems.  It is true that there are many books on data model patterns, but these are oriented to data modeling goals such as not needing to change a database structure unless it is unavoidable.

A challenge will therefore be to catalog the different types of concept system, and their special properties, and find ways to apply them in the practical work of definition management.

The Idea of Concept Systems

An involuntary hiatus has prevented me from the pleasure of blogging on definitions for about a month.  I am now gradually getting back to normal, and am able to blog again.

Today I want to look at concept systems, and types of concept system.

In data modeling, only one type of concept system commonly appears - the generic concept system, containing Supertypes and Subtypes.  Very occasionally, the part-whole type of concept system can also be found.  The latter be seen in "bill of material" structures.  Strangely, the visual representation of a generic concept system and a part-whole concept system can look very similar in a data model.   I think that this leads data modelers to play down the idea of concept systems, and indeed the term "concept system" is not really met with in data modeling.

However, if we turn to the discipline of terminology, the idea of concept system is very prominent, and different types of concept systems are called out.  Let me quote from the Nordterm Guide to Terminology by Heidi Suonuuti (ISBN 952-9794-14-2):

"Concepts are not independent phenomena.  They are always related to other concepts in one way or another, and form concept systems which can vary from fairly simple to extremely complicated.  In terminology work, an analysis of the relations among concepts and an arrangement of them into concept systems, is a prerequisite for the successful drafting of definitions."

It is interesting that from the data modeler's perspective, concept systems are viewed only with respect to designing data storage solutions.  A terminologist, by contrast, is more interested in business information and how concepts are related within it - irrespective of how such information might be stored as data.

This makes me wonder about semantic modelers.  We hear a lot about semantics these days, and there is no doubt that semantics involves identifying concepts and providing definitions for them.  But finding the relationships between the concepts must be done prior to forming the definitions.  This is because a definition, in part, describes a concept's relations to other concepts in the concept system in which it is found.  So what good methodologies, notations, and techniques exist for describing or visualizing concept systems?  I am not sure we have yet got any good ones.   The danger is that we then fall back on the data modeling methodologies, notations, and techniques, which fail to capture significant semantic details.

But perhaps more important is that the terminologists have the idea of types of concept systems.  The generic and partitive types of concept system are the major ones, but there are others.  We will deal with the different types in a future post.

The Problem of Abstraction in Definitions of Data Objects

I think there is a major problem in not being able to understand and work with different levels of abstraction.  By "abstraction" in this sense I mean one concept system that somehow describes or defines (not merely relates to) another concept system.  I think this is a big problem for definitions in data models.

Let us take an example in a retail business such as mortgage banking: Customer Name.  Customer Name exists in the business.  They use it all the time.  Maybe it is sometimes called Borrower Name, but the concept is the same.  This is the Level 1 abstraction.

Now let us think of data values in a column in a table that holds Customer Name.  These data values are stored as a code of 1's and 0's.  Of course these bits are rendered into something we can read.  However, this is not the same as the Customer Name in the business.  I worked for a place where they prefixed the name of anyone who had recently left with "ZZZ".  So we could have "ZZZ_John Smith" as a data value, but the business would call him "John Smith" still.  The data value is the Level 2 abstraction.

Now let us think of the column itself that stores Customer Name, irrespective of whatever it contains.  This is the container used for the data.  It is merely a container, and anything can be put into it - just in the same way as the old peanut jelly jar I have on my desk is used to hold pens.  The column has certain characteristics, like the maximum length of text it can hold.  This is the Level 3 abstraction.

Now let us think of the data model that describes the column that will hold Customer Name.  In this, Customer Name is an attribute.  We worry about what naming convention to give it.  And behold!  Our data modeling tool asks us to enter a definition for Customer Name!  Yet, we are now at Level 4 of abstraction.

Let's summarize.  The concept system of the data model (Level 4) is a design for the concept system of the container of the data (Level 3) which will store the concept system of data values (Level 2) which we hope will satisfy the concept system of the information needs of our users (Level 1).

So tell me again what the definition entered in the data model is referring to?  Which of the four concept systems?.  Suppose it is stated as "an attribute that holds customer name" - I have seen this kind of thing quite often.  Well, an attribute is something in a data model (Level 4), and a thing that holds data is a container (Level 3).  

It would seem that the ideal thing would be to understand the Level 1 abstraction - the business information.  However, the chances of getting a good definition of this when you are at Level 4 would seem to be a challenge.  There are too many layers of abstraction in the way.  This, I think, is why semantics are so important.  They deal with business information as is, and do not have to worry about other concept systems.

Must a Definition Include Identification of Related Concepts?

The traditional answer to this question is "yes", because classic essential definitions follow the formula Definition = Genus + Specific Difference.

However, definitions of concepts in natural science tend to be more like descriptions than classical definitions.  This may be unavoidable, but there is always a danger in a descriptive definition of not mentioning any related concepts.  Such definitions may give the impression of a style in which definitions should be written, and this sometimes carries over into analyst work - so that some analysts tend to write descriptive definitions, even if essential ones could be provided.  And such definitions lack mention of related concepts.    

But should a definition always identify related concepts?  I think it should.  I think that practical usage of a definition requires an understanding of the Concept System in which the definition is located.  Without such an understanding, the user runs a risk of not being able to use the definition adequately.  I will have to return to this to offer a proof in the future. 

The Concept System itself is a concept.  Merely identifying the Concept System may be at too high a level of generalization - but it is better than nothing.  Better would be to find a proximate superordinate genus (an immediate parent supertype) within the Concept System, but this may sometimes be difficult.

A concept need not have just one relation (to the Concept System or a higher-level concept within it).  It may have other relationships.  Identifying such relationships in definitions will be helpful too.  This is a topic that leads to matching definitions to Conceptual Models, which we will have to return to. 

Therefore, I think that we have an additional quality assurance point for definitions: a definition must identify a superordinate genus within the Concept System in which it is located, or identify the Concept System itself.

A futher quality assurance point might be that a definition must identify all relations between the concept being defined and other relevant concepts - but this point needs to be followed up in a future post.

This leads to the consideration that a definition of a concept will change depending on the Concept System it is located in, and one concept can be located in more than one Concept System.  And that it yet another topic for a future post.

A First Note on Partial Definitions

I think that partial definitions exist, and there are practical reasons for being interested in them.  I cannot find any literature about them, and this post is my first attempt at dealing with partial definitions.

The only conceptualization of a partial definition that I have figured out in any detail can be summarized by the formula:

Partial Definition = Name of Concept System + Type of Relation in Concept System

E.g., for "Wristwatch"

Definition of "Wristwatch" = "A type of timepiece"

Obviously, this parallels the Aristoteialan formula of Definiton = Genus + Specific Difference.  However, I think that Aristotle commits definitions to being only in a Concept System of generic relations (supertype-subtype to our data modeling friends).  Other types of Concept System exist, e.g. partative (part-whole), and associative. 

In a partial definition we provide information by locating the concept to be defined within a particular Concept System, giving context to the minds we are communicating with.  Of course, we must expect that these minds know about the Concept System we name in the partial definition.

The Concept System does not have to be a proximate Genus, as Aristotle would like.  It could be a much higher level generic concept, though this may broaden the context too much.  In the above example, locating "Wristwatch" in the concept system "Timepiece" provides more precise context than if I said "A type of instrument", "instrument being a more generic concept containing "Timepiece".  Obviously, there is skill required to choose the level appropriate to the mind being communicated with.

There is also the choice of Concept System to locate the concept in.  For "Wristwatch" I could have alternative partial definitions such as "A fashion accessory", or "An item of jewelery".  These identify different Concept Systems within which I wish to locate "Wristwatch" for whatever my purposes may be.

The Type of Relation in the Concept System in my formula above (e.g. "type", "part", "item") is one level of abstraction up from a description of the Concept System itself.  I think it serves to reinforce the essence of the Concept System.

While full definitons are not something we work on every day, I think partial definitions are very common in everyday communication. 

That's enough for now.  To summarize (and these points may need further proof): 

• Partial Definitions exist
• A common kind of Partial Definition is to locate a concept in a Concept System
• The Partial Defintion also describes the type of relation that predominates in the Concept System
• There is skill in selecting the Concept System as one concept can belong to many Concept Systems
• There is skill in selecting the level of generalization of the Concept System
• Partial Definitions are very common in everyday language (does that mean that everyone is an ontologist?)