acteristics of properties. Besides being Transitive, a property can be Symmetric, Functional, or InverseFunctional; for example, the axioms

DisjointClasses: Owl Cat Toad
Property: isPetOf
Characteristics: Functional
state that Owl, Cat, and Toad are dis-
joint (that is, they have no instances in
common) and that isPetOf is func-
tional (that is, pets can have only one
owner).
These axioms describe constraints
on the structure of the domain and play
a role similar to the conceptual schema
in a database setting; in DLs, such a set
of axioms is called a terminology box
(TBox). OWL also allows for axioms
that assert facts about concrete situa-
tions, like data in a database setting;
in DLs, such a set of axioms is called
an assertion box (ABox). These axioms
might, for example, include the facts
Individual: HarryPotter
Types: HogwartsStudent
Individual: Fawkes

Types: Phoenix

Facts: isPetOf Dumbledore Basic facts, or those using only atomic classes, correspond directly to RDF triples; for example, the facts just discussed correspond to the following triples:

HarryPotter rdf:type, HogwartsStudent .

Fawkes rdf:type Phoenix .

Fawkes isPetOf Dumbledore .

The term “ontology” is often used to refer to a conceptual schema or TBox, but in OWL an ontology can consist of a mixture of both TBox and ABox axioms; in DLs, this combination is called a knowledge base.

DLs are fully fledged logics and so have a formal semantics. They can, in fact, be understood as decidable subsets of first-order logic, with individuals being equivalent to constants, concepts to unary predicates, and roles to binary predicates. Besides giving a precise and unambiguous meaning to descriptions of the domain, the formal semantics also allows for the development of reasoning algorithms that can be used to correctly answer arbitrarily complex queries about the domain. An important aspect of DL research is the design of such algorithms and their implementation in (highly optimized) reasoning systems that can be used

by applications to help them “ understand” the knowledge captured in a DL-based ontology.

ontology Reasoning

Though there are clear analogies between databases and OWL ontologies, there are also important differences. Unlike databases, OWL has a so-called open-world semantics in which missing information is treated as unknown rather than as false and OWL axioms behave like inference rules rather than as database constraints. For example, we have asserted that Fawkes is a Phoenix and a pet of Dumbledore and that only a Wizard can have a pet Phoenix. In OWL, this leads to the implication that Dumbledore is a Wizard; if we were to query the ontology for instances of Wizard, then Dumbledore would be part of the answer. In a database setting the schema could include a similar statement about the Phoenix class, but it would (in this case) be interpreted as a constraint on the data. Adding the fact that Fawkes isPetOf Dumbledore without Dumbledore being known to be a Wizard would lead to an invalid database state; such an update would be rejected by a database management system as a constraint violation.

Unlike databases, OWL makes no unique name assumption; for example, given that isPetOf is a functional property, then additionally asserting that Fawkes isPetOf AlbusDumbledore would imply that Dumbledore and AlbusDumbledore are two names for the same Wizard. In a database setting this would again be treated as a constraint violation. Note that in OWL it is possible to assert (or infer) that two different names do not refer to the same individual; if such an assertion were made about Dumbledore and AlbusDumbledore, then asserting that Fawkes isPetOf AlbusDumbledore would make the ontology inconsistent. Unlike database management systems, ontology tools typically don’t reject updates that result in the ontology becoming wholly or partly inconsistent; they simply provide a suitable warning.

The treatment of schema and constraints in a database setting means they can be ignored when answering queries; in a valid database instance, all schema constraints must already be satisfied. This treatment makes query

answering highly efficient; for example, in order to determine if Dumbledore is in the answer to a query for Wizards, it is sufficient to check if this fact is explicitly present in the database. In OWL, the schema plays a much more important role and is actively considered at query time. Considering both the schema and the data can be very powerful, making it possible to answer conceptual, as well as extensional, queries; for example, we can ask not only if Dumbledore is a Wizard but if anybody having a Phoenix for a pet is necessarily a Wizard. This power does, however, make query-answering much more difficult (at least in the worst case); for example, in order to determine if Dumbledore is in the answer to a query

 

for Wizards, it is necessary to check if Dumbledore would be an instance of Wizard in every possible state of the world that is consistent with the axioms in the ontology. Query answering in OWL is thus analogous to theorem proving, and a query answer is often referred to as an “entailment.” OWL is therefore most suited to applications where the schema plays an important role, where it is not reasonable to assume that complete information about the domain is available, and where information has high value.

Ontologies may be very large and complex; for example, the Systematized Nomenclature of Medicine– Clinical Terms (SNOMED CT) ontology includes more than 400,000 class names. Building and maintaining such an ontology is costly and time-consuming, so providing tools and services to support the ontology-engineering process is critical to both the cost and the quality of the resulting ontology. Ontol-