Guidelines for Placing Concepts

Ask the following questions:

1. Is it a concept or an instance? If it is an instance, it perhaps belongs in the onomasticon, not the ontology. If it is an instance, simply add it as an instance of the appropriate concept.

   In order to decide when something is an instance or when it is a concept, there are a couple of rules of thumb:

   • Instance-Rule1: See if the thing can have its own instance. If yes, it is a concept. If not, it is an instance. Instances do not have their own instances. By looking at the hierarchy from its leaves (i.e., instances) this way, we can easily figure out if something is an instance or not.

   • Instance-Rule2: See if the thing has a fixed position in time and/or space in the world. If yes, it is an instance. If not, it is a concept. For example, Sunday is a concept, not an instance, because it is not a fixed position in time (last Sunday, the first Sunday of the month, etc.). On the other hand, Paris-France is an instance because it is a fixed position in space.

2. Is it an OBJECT, an EVENT, or a Property? Place it in the appropriate part of the ontology.

   The following criteria might help decide if something is an OBJECT or an EVENT:

   • Causation
   • Agency
   • Persistence in time

   For example, ``flood'' is an EVENT, not an OBJECT because it is caused by something else and is not persistent in time (relative to a river, say).

   It is not a simple matter to determine if something is an OBJECT, EVENT, or Property. Looking at the source text helps sometimes. Also, this problem may have already been solved by the lexicographers when they define the lexical mappings. If they have specified case roles as slots for the concept, then it is definitely an EVENT.

   A major source of problems in determining if something is an OBJECT or an EVENT or a Property is that we have inherent dualities between Properties and EVENTs and Properties and OBJECTs, and between OBJECTs and EVENTs too, as described above.

3. If it is an OBJECT, determine if it is a physical, mental, or social OBJECT. If it is an EVENT, determine if it is a physical, mental, or social EVENT. For a Property, determine if it is a Relation or an Attribute.

   Some characteristics of physical, mental, and social OBJECTs:

4. Do not make changes to the top-level hierarchies to place a new concept. Concepts in the higher levels of the ontology (i.e., closer to ALL) tend to be better understood and more stable than those at the lower ends. Changes to the upper levels of the ontology are expected to be rare and to involve significant debating before they are agreed upon.

   The example of force: In the ontology we inherited, ``force'' was a concept directly under ALL, a sibling of OBJECT, EVENT, and Property. If force can be there, why not energy and momentum as well? We should resist adding such concepts at the highest levels of the ontology. This has now been rectified by making force a child under INTANGIBLE-OBJECTs, a type of OBJECT.

5. If you are not sure how to define an intermediate parent between a child concept and its parent, do not define one. On the other hand, if a parent has many children and if there is a good way to partition the children into equivalent classes, introduce those classes at an intermediate level between the parent and the children nodes.

6. Emphasize depth.

7. Concepts should have 2 to 4 Subclasses. More than 5 children is perhaps a signal for further organization.

   For example, a number of concepts may have been added directly under material. At a later point, it might become clear that some of the them (such as leather, silk, etc.) can be put under an intermediate concept called animal-derived-substance (a subclass of material) and so on. They can now be reorganized appropriately.

   Other examples of reorganization.

   the reorganization of FINANCIAL-EVENT be a good example

8. Before adding an Is-A to a second (or nth) parent, check to see if the first (or one of the first) parent(s) is already a subclass or descendent of the second (or nth) parent. If so, do not add a link to that additional parent. Remember that Is-A links are not inherited (see below under general guidelines); as such, the node will not have an inherited link to that second (or nth) parent, though it is a descendent of it. Moreover, the graph we see cannot be trusted since the tool sometimes does not display links to multiple parent appropriately.

   For example, in adding the concept ANNOUNCE as a child of ASSERTIVE-ACT, one might consider that announce is also a mental-EVENT. We may be seeing only the link up to the social-EVENT at this time in the graph. However, before adding a link from announce to mental-EVENT, one must verify if mental-EVENT is already an ancestor of announce. It in fact is, since a communicative-EVENT (an ancestor of announce) is both a mental and a social EVENT. NOTE once again that we cannot trust utilities such as Ancestry in the tool. It sometimes does not show multiple parents though a node has more than one parent.