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.