untitled

314 12 Building Bioinformatics Ontologies

4. Check that the formal ontology is consistent.

The fulfillment of the purpose is verified by examining the design ratio-

nales. Every design decision should be supported by a design rationale, and

each rationale should be complete and convincing. A rationale is complete if

all design alternatives have been considered.

Checking that the usage examples are expressible is done by expressing

them in the ontology language that has been chosen. For example, in the

medical chart ontology, the usage examples would look like the following:

<Patient rdf:ID="p08639" name="George"/>

<Admission patient="#p08639"

ward="#InfectiousDiseaseWard">

<date rdf:datatype="xsd:date">2004-09-02</date>

</Admission>

<Note patient="#p08639" author="#Lenz"

classification="#S00034">

Patient is experiencing nausea

</Note>

<Test patient="#p08639">

<temperature

rdf:datatype="xsd:decimal">38.9</temperature>

</Test>

Creating examples from the ontology is the reverse of the process above.

Instead of starting with meaningful usage examples and expressing them,

one expresses examples and checks that they are meaningful. The examples

can be either specific or generic. Some of the issues one should consider are

the following:

1. Disjointness.Can an instance belong to two different classes? This is test-
   ing the disjointness property discussed in subsection 12.6.4. For example,
   can an event be both a prescription and a test?


2. Cardinality. Can a property be left unspecified? Can a property have
   more than one value? This kind of example tests whether the cardinality
   constraints are valid and whether cardinality constraints should be added
   (see subsection 12.7.3). For example, could a test not include a measure-
   ment of body temperature? Could a test have two measurements of body
   temperature?