-
For concepts in the ontology, only the following slots have their
Value facets filled:
Subclasses, Is-A, Instances, and Definition for OBJECTs and EVENTs;
Inverse for Relations.
All other slots have their Sem facets filled (if anything is filled at
all). Default facets may also be filled, but are rarely used in the
current ontology.
-
For Properties, specify the DOMAIN and the RANGE. The only
exception is if the filler of (the Sem facets of) these slots are
going to be just ALL, do not mention the filler.
-
If you add a slot name, that probably is already a Property in the
ontology. Verify this and consider adding the Property to the ontology.
-
When you add a slot to a concept, consider adding the Inverse link
from the filler back to the concept. Add the Inverse Property if it
does not exist already.
Exception: If the filler is a very generic OBJECT, then do not add the
reverse link. For example, we do not want THEME-OF links from
PHYSICAL-OBJECT to a zillion EVENTs. Such information serves no useful
purpose in language processing. The Inverse link should perhaps be
added between corresponding ancestors at a higher level in the trees.
-
Keep inheritance in mind. If most siblings have a common slot and
filler, that piece of information belongs in their parent. However,
note that only Value and Sem facets are inherited. Also, these slots
are not inherited: Is-A, Subclasses, instances, instance-of,
definition, and comments.
``IT IS THE RESPONSIBILITY OF THE ONTOLOGY BUILDER TO MAKE SURE THAT
NO AMBIGUITIES ARISE FROM MULTIPLE INHERITANCE - in other words, that
the same Property with incompatible values is not inherited by a node
from different parents of that node.
-
It helps to keep our ultimate objective in mind. We are building
the ontology for knowledge-based machine translation. If a concept or
its further decomposition does not seem necessary for KBMT, let us not
spend time adding it. We are not a building a CyC for the sake of
building it; we have a goal: to get our programs to translate language.
-
Keep generation in mind. Though we are mostly driven by the needs
of language interpretation in our current efforts, we must strive to
keep the needs of language generation in mind. At this time, it is not
even clear whether or how the generator will access the ontology. As
such, we can only appeal to intuitive ideas of how the generator may
function and use them in making ontological choices.
-
Keep other languages in mind. Just because English names are used
for the concepts in the ontology, we must not forget that the ontology
must be equally useful for interpreting or generating any natural
language.
-
Do any change at the highest level possible in the
hierarchy so that it propagates through inheritance to all the desired
places. For example, to block a slot using *nothing* do it at the
highest level appropriate.
-
Never ever have multiple parent links to more than one of OBJECT, EVENT,
RELATION, or ATTRIBUTE. Once it has been determined where the concept
should be placed, it should have only one of the parent links mentioned
above.
-
Make children concepts if you can clearly classify instances of a
concept. If it is a continuous difference, use an ATTRIBUTE. For
example, to work with concepts concerning aesthetic artifacts, such as
paintings, we do not create a concept "aesthetic-artifact." Instead, we
create AESTHETIC-ATTRIBUTE, which can mapped to any ARTIFACT.
-
If more than half of the siblings have a slot filler that doesn't apply
to the concept, then NOT may be used.
