This section provides an informal description of the modeling primitives, an example in OIL, its tool environment, and a discussion of future extensions of OIL.
In this section we will give an informal description of the OIL language. An example is provided in Section 3.2 and a formal specification and semantics (both of the language and of the common inference problems) will be given in Appendix C. To improve readability we will use a more compact pseudo XML syntax where opening tags are indicated by bold faced text, grouping of sub-content is indicated by indentation and closing tags are omitted.
An OIL ontology is a structure made up of several components, some of which may themselves be structures, some of which are optional, and some of which may be repeated. We will write component ? to indicate an optional component, component + to indicate a component that may be repeated one or more times (i.e., that must occur at least once) and component * to indicate a component that may be repeated zero or more times (i.e., that may be completely omitted).
When describing ontologies in OIL we have to distinguish three different layers:
OIL is concerned with the first and second meta-levels. The former is called the ontology definition and the latter is called the ontology container . We will discuss both elements of an ontology specification in OIL. We start with the ontology container and will then discuss the backbone of OIL, the ontology definition.
We adopt the components as defined by the Dublin Core Metadata Element Set, Version 1.1 for the ontology container part of OIL. Although every element in the Dublin Core set is optional and repeatable, in OIL some elements are required or have a predefined value. Required elements are written as element + . Some of the elements can be specialized with a qualifier which refines the meaning of that element. In our shorthand notation we will write element.qualifier. The precise syntax based on RDF is given in [Miller et al., 1999] , and in the appendix. Here we provide our pseudo-XML syntax explained above.
Note that class expressions are recursively defined, so that arbitrarily complex expressions can be formed. For example
NOT (Meat OR Fish)defines the class whose instances are all those individuals that are not an instances of either the class Meat or the class Fish.
slot-constraint eats
has-value zebra, wildebeestdefines the class each instance of which eats some instance of the class zebra and some instance of the class wildebeest. Note that this does not mean that instances of the slot-constraint eat only zebra and wildebeest: they may also be partial to a little gazelle when they can get it. has-value expresses the existential quantifier of Predicate logic : for each instance of the class, there exists at least one value for this slot that fulfils the range restriction.
The following example of
an OIL ontology illustrates some of the key features of the language.
The ontology is intended purely for didactic purposes and is not to be
taken as an example of good modeling practice.
Some points to note in the above ontology are:
Our starting point was to define a core language with the intention that additional (and possibly important) features be defined as a set of extensions (still with clearly defined semantics). Modelers will be free to use these language extensions, but it must be clear that this may compromise reasoning support. This seems to us a better solution than trying to define a single "all things to all men" language like Ontolingua. In this section we briefly discuss a number of features which are available in other ontology modeling languages and which are not, or not yet, included in OIL. For each of these features we briefly explain why we chose them, and mention future prospects where relevant.
Default reasoning: Although OIL does provide a mechanism for inheriting values from super-classes, such values cannot be overwritten. As a result, such values cannot be used for the purpose of modeling default values. If an attempt is made at "overwriting" an inherited attribute value, this will simply result in inconsistent class definitions which have an empty extension. For example, if we define the class "CS professor" with attribute "gender" and value "male", and we subsequently define a subclass for which we define the gender attribute as "female", this subclass will be inconsistent and have an empty extension (assuming that "male" and "female" are disjoint).
Rules/Axioms: As discussed above, only a fixed number of algebraic properties of slots can be expressed in OIL. There is no facility for describing arbitrary axioms that must hold for the items in the ontology. Such a powerful feature is undoubtedly useful. The use of OIL as an exchange language further justifies a more powerful axiom-language as you might need such axioms to enforce the correct interpretation of the source ontology when mapping into OIL. The lack of such an axiom-language is somewhat mitigated in OIL by the fact that we have a powerful concept and slot definition language. The main limitation is that we do not have composite definitions of relations. However, there is currently no broad support for any particular choice in this matter. The main problems in this area are first, that it is difficult to identify a common set of rule/axiom expressions that can be standardized, and second, that you have to define properly how these axioms can be integrated with the other modeling primitives of OIL.
Further algebraic properties: The lack of an axiom language can also be compensated for some-what by extending the set of properties that can be specified for relations in OIL. Currently this set contains inverse, transitivity and symmetry. Other reasonable candidates are reflexivity, irreflexivity, antisymmetry, asymmetry, linearity (aRb bRa for any pair a,b), connectivity (aRb or a=b or bRa for any pair a,b), partial order and total order. (Notice that some of these can be defined in terms of each other), cf. [Staab & Mädche, 2000].
Modules: Section 3.1 presented a very simple construction to modularize ontologies in OIL. In fact, this mechanism is identical to the namespace mechanism in XML and XML schema. It amounts to a textual inclusion of the imported module, where name-clashes are avoided by prefixing every imported symbol with a unique prefix indicating its original location. However, much more elaborate mechanisms would be required for the structured representation of large ontologies. Means of renaming, restructuring, and redefining imported ontologies must be available. Future extensions will cover parameterized modules, signature mappings between modules, and restricted export interfaces for modules. We will use the generic adapter concept of UPML (cf. [Fensel et al., 1999a] ) specialized to the fixed set of language primitives of OIL as [Gennari et al., 1994] , [Park et al., 1997] have developed for the fixed set of language primitives of Protégé.
Using instances in class definitions: Results from research in description and modal logics show that the computational complexity of such logics changes dramatically for the worse when domain-instances are allowed in class definitions [Schaerf, 1994] , [Blackburn & Seligman, 1998] , [Areces et al., 1999] . For this reason, OIL currently does not allow the use of instances in slot-values, or extensional definitions of classes (i.e., class definitions by enumerating the class instances). It is not clear how serious a restriction this is for an ontology language, as ontologies should, in general, be independent of specific instantiations--it may be that in many cases, "individuals" can more correctly be replaced with a primitive class or classes.
Concrete domains: OIL currently does not support concrete domains (e.g., integers, strings, etc.). This would seem to be a serious limitation for a realistic ontology language, and extensions of OIL in this direction are probably required. The theory of concrete domains is well understood [Baader & Hanschke, 1991] , and it should be possible to add some restricted form of concrete domains (but still with greater expressive power than XOL's numeric-minimum and numeric-maximum slot constraints) to OIL's core language without compromising its decidability (but a corresponding extension to the FaCT system would also be required if reasoning support is to be provided).
Limited Second-order expressivity: Many existing languages for ontologies (KIF, CycL [Lenat & Guha, 1990] , Ontolingua) include some form of reification mechanism, which allows the treatment of statements of the language as objects in their own right, thereby making it possible to express statements over these statements. A full second order extension would be clearly undesirable (even unification is un-decidable in full 2nd order logic). However, much weaker second order constructions already provide much if not all of the required expressivity without causing any computational problems (in effect, they are simply 2nd order syntactic sugar for what are essentially first order constructions). A precise characterization of such expressivity is required in a future extension of OIL. OIL is currently very restricted. Only classes are provided, not meta-classes or individuals.