12.6 Designing the Concept Hierarchy 299
<rdfs:Class rdf:ID="Prescription">
<rdfs:subClassOf rdf:resource="#Event"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Operation">
<rdfs:subClassOf rdf:resource="#Event"/>
</rdfs:Class>
<rdfs:Class rdf:ID="Category"/>
<rdfs:Class rdf:ID="Note"/>When discussing concepts it is important to distinguish the concept from
the instances belonging to the concept. In the case of charts and events, the
same words are used for the concept and for an instance of the concept. To
make the distinction clear one can use the word “concept” or “class” when
one is referring to the concept. Thus “the chart class” refers to the concept
while “a chart” or “George’s chart” refer to instances. Capitalization is an-
other common technique for distinguishing concepts from instances. Thus
“Chart” refers to the chart concept, while “chart” refers to an instance chart.
However, capitalization is used for other purposes in many languages, so it
is not very reliable.
As we discussed in section 1.5, there are several ways to develop a concept
hierarchy. One can begin with the most general concepts and then succes-
sively specialize them. This is calledtop-downdevelopment. The XML DTD
for the medical chart ontology was developed by starting with the Chart con-
cept and then specializing it. Conversely, one can start with the most specific
concepts and successively group them in progressively larger classes. This
is calledbottom-updevelopment. Neither development technique is intrinsi-
cally better than the other. In practice, one uses a combination of top-down
and bottom-up techniques. In fact, there is evidence that human beings tend
to start in the middle of the hierarchy, generalizing and specializing from
there (Rosch and Lloyd 1978). This middle level is called thebasiclevel.
If a concept hierarchy is large or is going to be in use for a relatively long
time, then one should make an effort to have a design of as high a quality
as possible. The hierarchy should be as uniform as possible, classes must be
distinguished from instances, concepts should be elaborated to the appropri-
ate level of detail, and one should specify whether classes can overlap one
another. For the rest of this section, we discuss these criteria in more detail.