The Problem of Pluto: What Is being Defined?

I wanted to return to the issue of Pluto, which has already been the subject of a number of posts.  The International Astronomical Union (IAU) created a rich array of issues and problems when it undertook a definitional change that resulted in the demotion of Pluto to the class of "dwarf planets".

The topic this time is what exactly did the IAU define?

I was watching a PBS special on the status of Pluto a few days ago.  It included scenes from a diner where the genial Neil deGrasse Tyson was asking customers what they thought about the new status of Pluto.  The reponses varied, but the issue at hand was about whether Pluto was "a planet".  The diners all thought that they were dealing with the general concept signfied by the term "planet".  Yet there is reason to think they were mistaken.

The IAU resolved (see http://www.iau.org/public_press/news/detail/iau0603/) concerning the following:

"The IAU therefore resolves that planets and other bodies in our Solar System, except satellites, be defined into three distinct categories in the following way:"

So what is being defined? Answer: "planets and other bodies in our Solar System, except satellites". 

Not planets in general.  But wait a moment - on the web page referred to, it also says "Resolution 5A is the principal definition for the IAU usage of 'planet' and related terms."  Yet this is not part of the text of Resolution 5A.  It seems to be some extraneous comment of uncertain provenance.  It certainly appears to be in conflict with the text of Resolution 5A, which, again, is only dealing with the situation in the Solar System.

So we have: a lot of people thinking that the IAU defined "planet"; and the text of Resolution 5A which is defining "planets and other bodies in our Solar System, except satellites"; and a statement on the IAU web site saying that Resolution 5A is to be used for planets in general. 

This is contradictory.  The definition is for a "planet in the Solar System" but somehow can be used for a planet not in the Solar System also.  In other words, we can substitute the definition for both A and Not-A. 

Let's try that with the proposition about one of the extrasolar planets:

"51 Pegasi b is a planet that orbits the star 51 Pegasi". 

Substituting the definition presented in Resolution 5A for the term "planet" we get:

"51 Pegasi b is a celestial body that (a) is in orbit around the Sun, (b) has sufficient mass for its self-gravity to overcome rigid body forces so that it assumes a hydrostatic equilibrium (nearly round) shape, and (c) has cleared the neighbourhood around its orbit that orbits the star 51 Pegasi."

So we have a contradiction.  51 Pegasi b apparently orbits both the Sun and 51 Pegasi.

This contradiction arises from the IAU restricting the definition of "planet" to the Solar System, but pretending that it can be used for any planet.  It also shows how Natural Science is dependent on Logic, which is part of Philosophy.  But that is a far more controversial topic.

Three Classes of Identification in a Definition

Stijn commented on my earlier post "What is an Identifying Characteristic?" (http://definitionsinsemantics.blogspot.com/2011/11/what-is-identifying-characteristic.html) raising the point that "identification of a thing is dependent on the application".  He lists out things that identify him, and notes that one cannot always be substituted for another.  E.g. a passport cannot always be substituted for a driving license.  It depends on the application, and each application has rules about what can be used as identification.  Stijn asserts that trying to capture all such rules in a definition will create conflict between the parties representing the applications.  So he advises us to separate a definition from capturing such rules.

There are a lot of topics compressed into this comment, so I am only going to pick one here.  It is the different classes of identification that should be captured in a definition.  I suggest that these are:

• Characteristics of the concept being defined that set it apart from other related concepts.  These are the classic specific differences (differentia)
• Characteristics that can be used to recognize an instance of the concept.  This is what I was trying to highlight in the original post when I stated that an exit row in an airplane could be recognized by a sign saying "no children in this row".  There is no reason for these characteristics to be specific differences.
• Characteristics that can be used to identify an instance of the concept.  This is what Stijn was talking about, saying his passport could be used to identify him.  Identifying an instance is not the same as identifying or recognizing a concept. 

So it turns out that identification is quite complex in definition work.  Simply talking about "identifying characteristics" as I did, does not take this richness into account.

The per-application rules that Stijn mentions add more complexity, but that will require another post.

Role versus Relationship - What Does it Mean for Definitions?

A couple of days ago I was reading some material on a semantics product and came upon the term "role".  We see role used in data modeling where a primary key migrated into a child entity can be assigned a "role name".  This is the name by which the attribute is known in the child entity, and is useful to disambiguate the same attribute migrated for other relationships between the same two entities.

You also hear about "role" in the party model.  Rather than say that Unindicted Broker is a client of Overleveraged Bank, and that Unindicted Broker is a prime broker for Overleveraged Bank, we can say that Unindicted Broker is a party that plays two roles with Overleveraged Bank: (a) client; and (b) prime broker.

I think that there are deeper issues here.  We think of a relationship in a data model as a line between two entities.  We cannot allocate attributes to the relationship as we can to entities.  Our notations, methodologies, and tools will not allows it (at least the commonly used ones).  Furthermore, it is relatively rare to find multiple relationships between the same entities.  When we do find quite different relationships between the same two entities we seem to start thinking of roles.

Now, a relationship is a concept, and therefore must have a description and hopefully a definition.  If a relationship can have a definition, it must have characteristics (qualities, i.e. attributes). This worries me somewhat as relation and quality are two Aristotelian categories and one should not be reducible to the other.  However, I cannot find the theoretical foundation for what I am describing.

A further issue is that what we are calling a relationship such as "Unindicted Broker is a client of Overleveraged Bank" is a generalization about a lot of processes.  Unindicted Broker had to be solicited to be a client, then onboarded as a client, and then assessed in terms of how the relationship would be managed.  All of these processes come under the umbrella of "Unindicted Broker is a client of Overleveraged Bank" but break down to many more detailed entities and relationships. So "Unindicted Broker is a client of Overleveraged Bank" is a generalization, although it is valid.

So where does this leave us?  Not very far I am afraid, but we can begin to see the outlines of the problem.  The term "role" is used in semantics, but it is not clear if it is used technically or informally.  "Role" exists in data modeling, but is for refining names of attributes associated with relations.  And "role" exists in the party model, for "high-level" relationships.  There is some evidence that relations can be broken down into more detailed entities and relations that may serve to describe a role.  Ultimately it does seem that roles can be resolved into sets of entities and relationships at the data model level.  However, at the level of semantics it is not clear how they can be treated as other than relationships.

A role does seem to demand a definition that is greater than what is to be supplied for a "regular" relationship.  A role must be distinct from other roles, or you could argue it should be collapsed with its sibling roles into one role. So at least we can conclude that if we have identified a role we need to provide it with a good enough definition to provide such distinction.  Obviously, there is a lot more to this, but that is enough for now. 

Is A Data Model An Abstraction?

Rob brings up a good point in his comment on The Problem of Abstraction in Definitions of Data (http://definitionsinsemantics.blogspot.com/2011/12/problem-of-abstraction-in-definitions.html).  He notes that what I am describing is not really abstraction but really a number of different things.
Today it seems the term "abstraction" is used in all kinds of situations when talking about data.  For me, it is often difficult to figure out what "abstraction" is supposed to mean in any one of these situations.  I strongly suspect that at least sometimes it does not really mean anything.  Sometimes I suspect it is even used for marketing hype.

The entry for "abstraction" in Baldwin's Dictionary of Philosophy and Psychology describes how abstraction is filtering out of attributes from an instance or a concept to achieve a particular view of the instance or concept.  Rather poetically the entry describes how a child looks at a body of water and becomes fascinated by the lustre caused by the play of sunlight on the surface of the water, to the exclusion of all the other qualities (attibutes) of the water.

This traditional understanding of abstraction as creating a view by filtering out attributes can be used in a special way to create the generalization hierarchies of genus and species (a.k.a. supertype and subtype, or general concept and specific concept).  The particular attributes of a group of specific concepts are left behind and attributes that the concepts have in common remain.  These are used to form the general concepts that include the specific concepts. 

However, abstraction as filtering out of attibutes can generate other perspectives.  Abstraction does not always have to lead to the traditional generalization hierarchy.  I can understand a man's watch as a timepiece, or a piece of jewelery, or as a fashion accessory.

Now, Rob is right in that I was not using "abstraction" in the above senses.  However, I do not have a better term to use for what I was trying to describe.  The main idea I was trying to get across is that one concept system can describe or specify another - such as how a  data model describes a physical database.  The relationship of "description" here is different to every other kind of relationship because the concepts present in the concept system being described have to have some kind of presence in the concept system doing the the describing.  This is not the same class of relationship we see in e.g. "I own a car".

So we somehow have the presence of a concept being described (e.g. a column of a physical database table) in a concept system doing the describing (e.g. an attribute of an entity type in a data model).
Rob terms this "representation" (If I understand his comment correctly).  This has to be right.  However, a representation can often be a picture - a mere image.  Technically, this is called a "phantasm" because it does not have the attributes differentiated from the whole.  Unfortunately, the process of recognizing and separating the attributes from a phantasm is also called abstraction.  It gets more complicated.  we cannot take a photograph of a physical database and produce anything like a data model.  A database has to be conceieved, not imagined.

Obviously, we are getting into a whole lot of other issues here.  I cannot really defend myself against Rob's criticism of my having overloaded (or over-abstracted?) the term "abstraction".  However, I do not have a commonly accepted set of terms that I can use to convey the idea of one concept system describing another.  More of an excuse than a reason, but it will have to do for now.

On Levels of Definitions and the Semantic Web

Stijn made a couple of sharp points in a comment on the post How is a Definition Different from an Explanation? (Part 1) (http://definitionsinsemantics.blogspot.com/2011/11/how-is-definition-different-from.html). 

He notes that there is a need for definitions to be short in certain circumstances, as when a user is scanning through a list.  I think this is a good point.  Users may be more in search mode when they are doing something like this.  They want to know if the definition is close to some target they have in mind.  Obviously, a full definition is not fit for such a purpose.

So we might have three levels of definition: (a) a one-liner, suitable for lists; (b) a one-paragraph, suitable for a quick read with some detail - and display on a screen with scarce real estate; and (c) the full definition, as an authoritative reference.  I have no problem with the last one being very long and including pictures - certainly more than half a page.   

The second point Stijn makes is about the Semantic Web, where there is a need for a "general purpose" description.  I agree with Stijn that there is a problem here.  The definition of a concept must include something about the concept system the concept is located in - such as relationships to proximate concepts. So if one concept can be placed in different concept systems, then the definition will change.  A mortgage loan in a servicing system is not the same as in a loan origination system, and is not the same as in a securitization system.  The Semantic Web may have an unspoken assumption of a single model of reality.  This will cause problems if, as I maintain, one concept can be placed in many concept systems.  It will lead to the frustration Stijn describes.  

Where I disagree with Stijn is his equating explanation with description.  These are quite distinct.  There can certainly be descriptive definitions, and these are very common in natural science.  But explanations are different.

George Orwell on The Advantages of Abbreviation

The issue of the emotive power of terms and definitions is a difficult one.  However, it is never far away, even in data management.  With the recent passing of Kim Jong Il, it seems appropriate to reflect on the political application of terminology.  Below is an excerpt taken from George Orwell's novel "1984" which can be found at the Newspeak Dictionary site www.newspeakdictionary.com.  It deals with how abbreviations can be constructed to achieve certain ends. Admittedly, these are terminological rather than definitional principles, but they are not without interest and certainly have their place. 

So far as it could be contrived, everything that had or might have political significance of any kind was fitted into the B vocabulary. The name of every organization, or body of people, or doctrine, or country, or institution, or public building, was invariably cut down into the familiar shape; that is, a single easily pronounced word with the smallest number of syllables that would preserve the original derivation. In the Ministry of Truth, for example, the Records Department, in which Winston Smith worked, was called Recdep, the Fiction Department was called Ficdep, the Teleprogrammes Department was called Teledep, and so on. This was not done solely with the object of saving time. Even in the early decades of the twentieth century, telescoped words and phrases had been one of the characteristic features of political language; and it had been noticed that the tendency to use abbreviations of this kind was most marked in totalitarian countries and totalitarian organizations. Examples were such words as Nazi, Gestapo, Comintern, Inprecorr, Agitprop. In the beginning the practice had been adopted as it were instinctively, but in Newspeak it was used with a conscious purpose. It was perceived that in thus abbreviating a name one narrowed and subtly altered its meaning, by cutting out most of the associations that would otherwise cling to it.

The words Communist International, for instance, call up a composite picture of universal human brotherhood, red flags, barricades, Karl Marx, and the Paris Commune. The word Comintern, on the other hand, suggests merely a tightly-knit organization and a well-defined body of doctrine. It refers to something almost as easily recognized, and as limited in purpose, as a chair or a table. Comintern is a word that can be uttered almost without taking thought, whereas Communist International is a phrase over which one is obliged to linger at least momentarily. In the same way, the associations called up by a word like Minitrue are fewer and more controllable than those called up by Ministry of Truth. This accounted not only for the habit of abbreviating whenever possible, but also for the almost exaggerated care that was taken to make every word easily pronounceable.

In Newspeak, euphony outweighed every consideration other than exactitude of meaning. Regularity of grammar was always sacrificed to it when it seemed necessary. And rightly so, since what was required, above all for political purposes, was short clipped words of unmistakable meaning which could be uttered rapidly and which roused the minimum of echoes in the speaker's mind. 

When it comes to Newspeak, my favorite word is Prolefeed, which is defined as Rubbishy "entertainment" and spurious news which The Party hands out to the masses.  But I'm going to have to cut this post short tonight - it's time for Dancing With The Stars.

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.