Figure 1: The subclass-of hierarchy of modeling primitives in RDFS.
Many definitions of ontologies have been given in the last decade, but one that, in our opinion, best characterizes the essence of an ontology is based on the related definitions by [8]: An ontology is a formal, explicit specification of a shared conceptualisation. A conceptualisation refers to an abstract model of some phenomenon in the world which identifies the relevant concepts of that phenomenon. Explicit means that the type of concepts used and the constraints on their use are explicitly defined. Formal refers to the fact that the ontology should be machine understandable, i.e. the machine should be able to interpret the semantics of the information provided. Shared reflects the notion that an ontology captures consensual knowledge, that is, it is not restricted to some individual, but accepted by a group.
Ontologies will allow structural and semantic definitions of documents, providing completely new possibilities: intelligent search instead of keyword matching, query answering instead of information retrieval, document exchange via ontology mappings, and definition of views on documents.
RDF Schema [3] provides means to define vocabulary, structure and constraints for expressing metadata about Web resources. However, formal semantics for the primitives defined in RDF Schema are not provided, and the expressivity of these primitives is not enough for full-fledged ontological modeling and reasoning. To perform these tasks, an additional layer on top of RDF Schema is needed. Tim Berners-Lee calls this layered architecture the Semantic Web [2].
At the lowest level of the Semantic Web a generic mechanism for expressing machine readable semantics of data is required. The Resource Description Framework (RDF) [12] is this foundation for processing metadata, providing a simple data model and a standardized syntax for metadata. Basically, it provides the language for writing down factual statements. The next layer is the schema layer (provided by the RDF Schema specification [3]). We will show how a formal knowledge representation language can be used as the third, logical, layer. We will illustrate this by defining the ontology language OIL [6,10] as an extension of RDF Schema.
OIL (Ontology Inference Layer), a major spin-off from the IST project On-To-Knowledge1 [7], is a Web-based representation and inference layer for ontologies, which unifies three important aspects provided by different communities: formal semantics and efficient reasoning support as provided by Description Logics, epistemological rich modeling primitives as provided by the Frame community, and a standard proposal for syntactical exchange notations as provided by the Web community.
The content of the paper is organized as follows. In section 2 we provide a short introduction to RDF and RDF Schema. Section 3 provides a very brief introduction into OIL. Section 4 illustrates in detail how RDF Schema can be extended, using OIL as an example knowledge representation language. The result is an RDF Schema definition of OIL primitives, which allows one to express any OIL ontology in RDF syntax. In section 5 we discuss how our approach enables the added benefits of OIL, such as reasoning support and formal semantics, to be used on the Web, while retaining maximal compatibility with `pure' RDF(S). Finally, we provide our conclusions in section 6.
<rdf:RDF>
<rdf:Description about="http://www.w3.org">
<Publisher>World Wide Web Consortium</Publisher>
</rdf:Description>
</rdf:RDF>
states that http://www.w3.org (the subject) has as publisher (the
predicate) the W3C (the object). Since both the subject and the
object of a statement can be resources, these statements can be
linked in a chain:
<rdf:RDF>
<rdf:Description about="http://www.w3.org/Home/Lassila">
<Creator rdf:resource="http://www.w3.org/staffId/85740"/>
</rdf:Description>
<rdf:Description about="http://www.w3.org/staffId/85740">
<Email>lassila@w3.org</v:Email>
</rdf:Description>
</rdf:RDF>
States that http://www.w3.org/Home/Lassila (the subject) is created
by staff member no. 85740 (the object). In the next statement, this
same resource (staff member 85740) plays the role of subject to
state that his email address is lassila@w3.org. Finally, RDF
statements are also resources, so that statements can be applied
recursively to statements, allowing their nesting.
All this leads to the underlying datamodel being a labelled hyper-graph, with each statement being a predicate-labelled link between object and subject. The graph is a hyper-graph since each node can itself again contain an entire graph.
Despite the similarity in their names, RDF Schema fulfills a different role than XML Schema does. XML Schema, and also DTDs, prescribes the order and combination of tags in an XML document. In contrast, RDF Schema only provides information about the interpretation of the statements given in an RDF data model, but it does not constrain the syntactical appearance of an RDF description. Therefore, the definition of OIL in RDFS that will be presented in this document will not provide constraints on the structure of an actual OIL ontology.
In this section we will briefly discuss the overall structure of RDFS and its main modeling primitives.
| ontology-container title African Animals creator Ian Horrocks subject animal, food, vegetarians description A didactic example ontology describing African animals and plants description.release 2.0 publisher I. Horrocks type ontology format pdf identifier http://.../oil-rdfs.pdf source http://www.africa.com/ language en-uk ontology-definitions slot-def eats inverse is-eaten-by slot-def has-part inverse is-part-of properties transitive slot-def weight range (min 0) properties functional slot-def colour |
range string properties functional class-def animal class-def plant disjoint animal plant class-def tree subclass-of plant class-def branch slot-constraint is-part-of has-value tree class-def leaf slot-constraint is-part-of has-value branch class-def defined carnivore subclass-of animal slot-constraint eats value-type animal class-def defined herbivore subclass-of animal slot-constraint eats value-type (plant or (slot-constraint is-part-of has-value plant)) |
disjoint carnivore herbivore class-def mammal subclass-of animal class-def elephant subclass-of herbivore mammmal slot-constraint eats value-type plant slot-constraint colour has-filler grey class-def defined african-elephant subclass-of elephant slot-constraint comes-from has-filler Africa class-def defined indian-elephant subclass-of elephant slot-constraint comes-from has-filler India disjoint-covered elephant by african-elephant indian-elephant - instance information - instance-of Africa continent |
Figure 3: An example OIL ontology, modelling the animal kingdom
This language has been designed so that:
An ontology in OIL is represented via an ontology container and an ontology definition part. For the container, we adopt the components defined by Dublin Core Metadata Element Set, Version 1.15.
The ontology-definition part consists of an optional import statement, an optional rule-base and class, slot and axiom definitions.
A class definition (class-def) associates a class name with a class description. This class description in turn consists of the type of the definition (either primitive, which means that the stated conditions for class membership are necessary but not sufficient, or defined, which means that these conditions are both necessary and sufficient), a subclass-of statement and zero or more slot-constraints.
The value of a subclass-of statement is a (list of) class-expression(s). This can be either a class name, a slot-constraint, or a boolean combination of class expressions using the operators and, or and not, with the standard DL semantics.
In some situations it is possible to use a concrete-type-expression instead of a class expression. A concrete-type-expression defines a range over some data type. Two data types that are currently supported in OIL are integer and string. Ranges can be defined using the expressions (min X), (max X)), (greater-than X), (less-than X), (equal X) and (range X Y). For example, (min 21) defines the data type consisting of all the integers greater than or equal to 21. As another example, (equal "xyz") defines the data-type consisting of the string "xyz".
A slot-constraint (or property restriction) is a list of one or more constraints (restrictions) applied to a slot (property). Typical constraints are:
An axiom asserts some additional facts about the classes in the ontology, for example, that the classes carnivore and herbivore are disjoint (that is, have no instances in common). Valid axioms are:
<?xml version='1.0' encoding='ISO-8859-1'?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:oil="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcq="http://purl.org/dc/qualifiers/1.1/"
<!-- The ontology defined in OIL with RDFS syntax-->
</rdf:RDF>
It is important to notice that namespace definitions are not import
statements, and are therefore not transitive. An actual ontology
also has to define the namespaces for RDF and RDFS via ?xmlns:rdf?
and ?xmlns:rdfs?, otherwise, all elements of OIL that directly
correspond to RDF and RDFS elements would not be available.
The ontology-container of OIL provides metadata describing an OIL ontology. Because the structure and RDF-format of the Dublin Core element set is used, it is enough to import the namespace of the Dublin Core element set. Note that the fact that an OIL ontology should provide a container definition is an informal guideline in its RDFS syntax, because it is not possible to enforce this in the schema definition.
Apart from the container, an OIL ontology consists of a set of definitions. The import definition is a simple list of references to other OIL modules that are to be included in this ontology. We make use of the XML namespace mechanism to incorporate this mechanism in our RDFS specification. Notice again that, in contrast to the import statement in OIL, ?inclusion? via the namespace definition is not transitive.
Figure 4: The OIL extensions to RDFS in the subsumption
hierarchy.
To illustrate the use of these extensions, we will walk through them by means of some example OIL class definitions that need to be represented in RDFS syntax:
class-def defined herbivore
subclass-of animal
slot-constraint eats
value-type
(plant or (slot-constraint is-part-of
has-value plant))
class-def elephant
subclass-of herbivore mammmal
slot-constraint eats
value-type
plant
slot-constraint colour
has-filler
grey
The first defines a class ``herbivore'', a subclass of animal, whose instances eat plants or parts of plants. The second defines a class ``elephant'', which is a subclass of both herbivore and mammal.
<rdfs:Class rdf:ID="herbivore"> </rdfs:Class>From this definition it is not yet clear that this class is a defined class. We chose to introduce two extra classes in the OIL namespace, named PrimitiveClass and DefinedClass. In a particular class definition, we can use one of these two ways to express that a class is a defined class:
<rdfs:Class rdf:ID="herbivore"> <rdf:type rdf:resource="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#DefinedClass"/> </rdfs:Class>or:
<oil:DefinedClass rdf:ID="herbivore"> </oil:DefinedClass>We will use the first method of serialization throughout this article, but it is important to realize that both model exactly the same.
This way of making an actual class an instance of either DefinedClass or PrimitiveClass introduces a nice object-meta distinction between the OIL RDFS schema and the actual ontology: using rdf:type you can consider the class ``herbivore'' to be an instance of DefinedClass. In OIL in general, if it is not explicitly stated that a class is defined, the class is assumed to be primitive.
<rdfs:Class rdf:ID="herbivore"> <rdf:type rdf:resource="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#DefinedClass"/> <rdfs:subClassOf rdf:resource="#animal"/> </rdfs:Class>However, if one wants to define a class as a subclass of a class expression, one should use the oil:subClassOf property.
To overcome this problem, we introduce the oil:hasPropertyRestriction property, which is an rdf:type of rdfs:ConstraintProperty (analogous to rdfs:domain and rdfs:range). Here we take full advantage of the intended extensibility of RDFS. We also introduce oil:PropertyRestriction as a placeholder class6 for specific classes of slot constraints, such as has-value, value-type, cardinality and so on. These are all modeled in the OIL namespace as subclasses of oil:PropertyRestriction:
<rdfs:Class rdf:ID="ValueType"> <rdfs:subClassOf rdf:resource="#PropertyRestriction"/> </rdfs:Class>and similar for the other slot constraints. For the three cardinality constraints, an extra property ``number'' is introduced, which is used to assign a concrete value to the cardinality constraints.
To connect a ValueType slot constraint with its actual values, such as the property it refers to and the class it restricts that property to, we introduce a pair of helper properties. These helper properties have no direct counterpart in terms of OIL primitives, but they serve to connect two classes. We define a property oil:onProperty to connect a property restriction with the subject property, and a property oil:toClass to connect the property restriction to the its class restriction.
In our example ontology, the first part of the slot constraint would be serialized using the primitives introduced above as follows:
<rdfs:Class rdf:ID="herbivore">
<rdf:type rdf:resource="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#DefinedClass"/>
<rdfs:subClassOf rdf:resource="#animal"/>
<oil:hasPropertyRestriction>
<oil:ValueType>
<oil:onProperty rdf:resource="#eats"/>
<oil:toClass> </oil:toClass>
</oil:ValueType>
</oil:hasPropertyRestriction>
</rdfs:Class>
If we would want to restrict the value type of a property to a
string or an integer, we could use the toConcreteType property:
...
<oil:ValueType>
<oil:onProperty rdf:resource="#age"/>
<oil:toConcreteType
rdf:resource="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#Integer"/>
</oil:ValueType>
...
We introduce oil:Expression as a common placeholder, with oil:ConcreteTypeExpression and oil:ClassExpression as specialization placeholders. oil:BooleanExpression is introduced as a sibling of these two, since we want to be able to construct boolean expressions with either kind of expression. The specific boolean operators, `and', `or' and `not', are introduced as subclasses. Also, notice that since a single class is essentially a simple kind of class expression, rdfs:Class itself should be a subclass of oil:ClassExpression (see figure 4).
The `and', `or' and `not' operators are connected to operands using the oil:hasOperand property. This property again has no direct equivalent in OIL primitive terms, but is a helper to connect two class expressions, because in the RDF data model one can only relate two classes by means of a Property.
In our example, we need to serialize a boolean `or'. The RDF Schema definition of the operator looks like this:
<rdfs:Class rdf:ID="Or"> <rdfs:subClassOf rdf:resource="#BooleanExpression"/> </rdfs:Class>and the helper property is defined as follows:
<rdf:Property rdf:ID="hasOperand"> <rdfs:domain rdf:resource="#BooleanExpression"/> <rdfs:range rdf:resource="#ClassExpression"/> </rdf:Property>The fact that hasOperand is only to be used on boolean class expressions is expressed using the rdfs:domain construction. This type of modeling stems directly from the RDF property-centric approach.
Now we apply what we defined above to the example:
<rdfs:Class rdf:ID="herbivore">
<rdf:type rdf:resource="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#DefinedClass"/>
<rdfs:subClassOf rdf:resource="#animal"/>
<oil:hasPropertyRestriction>
<oil:ValueType>
<oil:onProperty rdf:resource="#eats"/>
<oil:toClass>
<oil:Or>
<oil:hasOperand rdf:resource="#plant"/>
<oil:hasOperand>
<HasValue>
<oil:onProperty rdf:resource="#is-part-of"/>
<oil:toClass rdf:resource="#plant"/>
</HasValue>
</oil:hasOperand>
</oil:Or>
</oil:toClass>
</oil:ValueType>
</oil:hasPropertyRestriction>
</rdfs:Class>
Observe that the HasValue property restriction is not related to
the class by a hasPropertyRestriction property, but by a hasOperand
property. This stems from the fact that the property restriction
plays the role of a boolean operand here.
The first bit is trivial:
<rdfs:Class rdf:ID="elephant"> </rdfs:Class>Next, we need to translate the OIL subsumption statement to RDFS. In this statement, a list of superclasses is given. In the RDFS syntax, we model these as seperate subClassOf statements:
<rdfs:Class rdf:ID="elephant"> <rdfs:subClassOf rdf:resource="#mammal"/> <rdfs:subClassOf rdf:resource="#herbivore"/> </rdfs:Class>Next, we have two slot constraints. The first of these is a value-type restriction, and it is serialized in the same manner as we showed in the "herbivore" example:
<rdfs:Class rdf:ID="elephant">
<rdfs:subClassOf rdf:resource="#mammal"/>
<rdfs:subClassOf rdf:resource="#herbivore"/>
<oil:hasPropertyRestriction>
<oil:ValueType>
<oil:onProperty rdf:resource="#eats"/>
<oil:toClass rdf:resource="#plant"/>
</oil:ValueType>
</oil:hasPropertyRestriction>
</rdfs:Class>
<oil:HasFiller> <oil:onProperty rdf:resource="#colour"/> <oil:stringFiller>grey</oil:stringFiller> </oil:HasFiller>In RDF(S), there is unfortunately no direct way to constrain the value of a property to a particular datatype. Therefore, the range value of oil:stringFiller can not be constrained to contain only strings. Only for clarity we created two subclasses of rdfs:Literal, named oil:String and oil:Integer.
<rdfs:Class rdf:ID="String">
<rdfs:comment>
The subset of Literals that are strings.
</rdfs:comment>
<rdfs:subClassOf
rdf:resource="http://www.w3.org/2000/01/rdf-schema#Literal"/>
</rdfs:Class>
The range of the filler properties can now be set to the
appropriate class, although it is still possible to use any type of
Literal. The semantics of rdfs:Literal are only that anything of
this type is atomic, i.e. it will not be processed further by an
RDF processor. The fact that in this case it should be a string
value can only be made an informal guideline.
<rdf:Property ID="stringFiller"> <rdfs:domain rdf:resource="#HasFiller"/> <rdfs:range rdf:resource="#String"/> </rdf:Property>Using all this, we get the following complete translation of the class ëlephant":
<rdfs:Class rdf:ID="elephant">
<rdfs:subClassOf rdf:resource="#mammal"/>
<rdfs:subClassOf rdf:resource="#herbivore"/>
<oil:hasPropertyRestriction>
<oil:ValueType>
<oil:onProperty rdf:resource="#eats"/>
<oil:toClass rdf:resource="#plant"/>
</oil:ValueType>
<oil:HasFiller>
<oil:onProperty rdf:resource="#colour"/>
<oil:stringFiller>grey</oil:stringFiller>
</oil:HasFiller>
</oil:hasPropertyRestriction>
</rdfs:Class>
Observe that it is allowed to have more than one property
restriction within the hasPropertyRestriction element.
| OIL primitive | RDFS syntax | type |
| class-def | rdfs:Class | class |
| subclass-of | rdfs:subClassOf | property |
| class-expression | oil:ClassExpression | class |
| (placeholder only) | ||
| and | oil:And | class |
| (subclass of BooleanExpression) | ||
| or | oil:Or | class |
| (subclass of BooleanExpression) | ||
| not | oil:Not | class |
| (subclass of BooleanExpression) | ||
| slot-constraint | oil:PropertyRestriction | class |
| (placeholder only) | ||
| oil:hasPropertyRestriction | property | |
| (rdf:type of rdfs:ConstraintProperty) | ||
| oil:CardinalityRestriction | class | |
| (placeholder only) | ||
| (subclass of oil:PropertyRestriction) | ||
| has-value | oil:HasValue | class |
| (subclass of oil:PropertyRestriction) | ||
| has-filler | oil:HasFiller | class |
| (subclass of oil:PropertyRestriction) | ||
| value-type | oil:ValueType | class |
| (subclass of oil:PropertyRestriction) | ||
| max-cardinality | oil:MaxCardinality | class |
| (subclass of oil:CardinalityRestriction) | ||
| min-cardinality | oil:MinCardinality | class |
| (subclass of oil:CardinalityRestriction) | ||
| cardinality | oil:Cardinality | class |
| (subclass of oil:CardinalityRestriction) | ||
In the next section, we will examine how to serialize global slot definitions.
There are a few subtle differences between domain and range restrictions in OIL and their equivalents in RDFS. First, the specification of OIL is very clear on multiple domain and range restriction: these are allowed, and the semantic is the intersection of the individual statements (conjunctive semantics). In RDFS, multiple domain statements are allowed, but their interpretation is the union of the classes in the statements (disjunctive semantics). This limits the reasoning capabilities of RDFS drastically7.
Despite these semantics for domain, a Property can have at most one range restriction in RDFS. However, according to discussions on the rdf-interest mailinglist the semantics of domain and range will very likely change in the next release of RDFS. We already anticipated on such a change, and interpret both multiple domain and multiple range restrictions with conjunctive semantics.
Secondly, in contrast to RDFS, OIL not only allows classes as range and domain of properties, but also class-expressions, and - for range - concrete-type expressions. It is not possible to reuse rdfs:range and rdfs:domain for these sophisticated expressions, because of the conjunctive semantics of multiple range statements: we cannot extend the range of rdfs:range or rdfs:domain, we can only restrict it.
Therefore, we introduced two new ConstraintProperties oil:domain and oil:range. They have the same domain as their RDFS equivalent (i.e., rdf:Property), but have a broader range. For domain, class expressions are valid fillers, for range both class expressions and concrete type expressions may be used:
<rdfs:ConstraintProperty rdf:ID="domain"> <rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdfs:range rdf:resource="#ClassExpression"/> </rdfs:ConstraintProperty> <rdfs:ConstraintProperty rdf:ID="range"> <rdfs:domain rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/> <rdfs:range rdf:resource="#Expression"/> </rdfs:ConstraintProperty>When translating a slot definition, rdfs:domain and rdfs:range should be used for simple (one class) domain and range restrictions. For example:
slot-def gnaws
subslot-of
eats
domain Rodent
will be translated into:
<rdf:Property rdf:ID="gnaws"> <rdfs:subPropertyOf rdf:resource="#eats"/> <rdfs:domain rdf:resource="#Rodent"/> </rdf:Property>For more complicated statements the oil:range or oil:domain properties should be used:
slot-def age
domain (elephant
or lion)
range
(range 0 70)
is in the RDFS representation:
<rdf:Property rdf:ID="age">
<oil:domain>
<oil:Or>
<oil:hasOperand rdf:resource="#elephant"/>
<oil:hasOperand rdf:resource="#lion"/>
</oil:Or>
</oil:domain>
<oil:range>
<oil:Range>
<oil:integerValue>0</oil:integerValue>
<oil:integerValue>70</oil:integerValue>
</oil:Range>
</oil:range>
</rdf:Property>
To specify that the range of a property is string or integer, we
use our definitions of oil:String and oil:Integer as subclasses of
rdfs:Literal. For example, to state that the range of age is
integer, one could say:
<rdf:Property ID="age">
<rdfs:range rdf:resource="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#Integer">
</rdf:Property>
However, global slot-definitions in OIL allow specification of more
aspects of a slot than property definitions in RDFS do. Besides the
domain and range restrictions, OIL slots can also have an
``inverse'' attribute and qualities like ``transitive'' and
``symmetric''.
We therefore added a property ``inverseRelationOf'' with ``rdf:Property'' as domain and range. We also added the classes ``TransitiveProperty'', ``FunctionalProperty'' and ``SymmetricProperty'' to reflect the different qualities of a slot. In the RDFS-serialization of OIL, the rdf:type property can be used to add a quality to a property. For example, the OIL definition of:
slot-def has-part
inverse
is-part-of
properties
transitive
is in RDFS:
<rdf:Property rdf:ID="has-part">
<rdf:type rdf:resource=
"http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#TransitiveProperty"/>
<oil:inverseRelationOf rdf:resource="#is-part-of"/>
</rdf:Property>
or, in the abbreviated syntax:
<oil:TransitiveProperty rdf:ID="has-part"> <oil:inverseRelationOf rdf:resource="#is-part-of"/> </oil:TransitiveProperty>This way of translating the qualities of properties features the same nice object-meta distinction between the OIL RDFS schema and the actual ontology as the translation of the ``type'' of a class (see section 4.2). In an actual ontology, the property ``has-part'' can be considered as an instance of a TransitiveProperty. Note that it is allowed to make a property an instance of more than one class, and thus giving it multiple qualities. Note that this way of representing qualities of properties in RDFS follows the proposed general approach of modeling axioms in RDFS, presented in [15]. In this approach, the same distinction between language-level constructs and schema-level constructs is made.
One alternative way of serializing the attributes of properties would be to define the qualities ``transitive'' and ``symmetric'' as subproperties of rdf:Property. Properties in the actual ontology (e.g. ``has-part'') would in their turn be defined as subProperties of these qualities (e.g. transitiveProperty). However, this would mix up the use of properties at the OIL-specification level and at the actual ontology level.
A third way would be to model the qualities as subproperties of rdf:Property again, but to define properties in the actual ontology as instances (rdf:type) of such qualities. In this approach, the object-meta level distinction is preserved. However, we dislike the use of rdfs:subPropertyOf at the meta-level, because then rdfs:subPropertyOf has two meanings, at the meta-level and at the object-level.
We therefore prefer the first solution because of the clean distinction between the meta and object level.
| OIL primitive | RDFS syntax | type |
| slot-def | rdf:Property | class |
| subslot-of | rdfs:subPropertyOf | property |
| domain | rdfs:domain | property |
| oil:domain | property | |
| range | rdfs:range | property |
| oil:range | property | |
| inverse | oil:inverseRelationOf | property |
| transitive | oil:TransitiveProperty | class |
| functional | oil:FunctionalProperty | class |
| symmetric | oil:SymmetricProperty | class |
RDF only knows binary relations (properties). Therefore, we cannot simply map OIL axioms to RDF properties. Instead, we chose to model axioms as classes, with helper properties connecting them to the class expressions involved in the relation. Since axioms can be considered objects, this is a very natural approach towards modeling them in RDF (see also [16,15]). Observe also that binary relations (properties) are modeled as objects in RDFS as well (i.e., any property is an instance of the class rdf:Property). We simply introduce a new primitive alongside rdf:Property for relations with higher arity (see figure 4).
We introduce a placeholder class oil:Axiom, and model specific types of axioms as subclasses:
<rdfs:Class ID="Disjoint"> <rdfs:subClassOf rdf:resource="#Axiom"/> </rdfs:Class>and likewise for Equivalent.
We also introduce a property to connect the axiom object with the class expressions it relates to each other: oil:hasObject is a property connecting an axiom with an object class expression. For example, to serialize the axiom that herbivores, omnivores and carnivores are (pairwise) disjoint:
<oil:Disjoint> <oil:hasObject rdf:resource="#herbivore"/> <oil:hasObject rdf:resource="#carnivore"/> <oil:hasObject rdf:resource="#omnivore"/> </oil:Disjoint>Since in a disjointness axiom (or an equivalence axiom) the relation between the class expressions is bidirectional, we can connect all class expressions to the axiom object using the same type of property.
However, in a covering axiom (like cover or disjoint-cover), the relation between class expressions is not bidirectional: one class expression plays the role of covering, several other class expressions play the role of being part of that covering.
For modeling covering axioms, we introduce a seperate placeholder class, oil:Covering, which is a subclass of oil:Axiom. The specific types of coverings available are modeled as subclasses of oil:Covering again:
<rdfs:Class ID="Cover"> <rdfs:subClassOf rdf:resource="#Covering"/> </rdfs:Class> <rdfs:Class ID="DisjointCover"> <rdfs:subClassOf rdf:resource="#Covering"/> </rdfs:Class>Furthermore, two additional properties are introduced: oil:hasSubject, to connect a covering axiom with its subject, and oil:isCoveredBy, which is a subproperty of oil:hasObject, to connect a covering axiom with the classes that cover the subject.
For example, we serialize the axiom that the class animal is covered by carnivore, herbivore, omnivore, and mammal (i.e. every instance of animal is also an instance of at least one of the other classes).
<oil:Cover> <oil:hasSubject rdf:resource="#animal"/> <oil:isCoveredBy rdf:resource="#carnivore"/> <oil:isCoveredBy rdf:resource="#herbivore"/> <oil:isCoveredBy rdf:resource="#omnivore"/> <oil:isCoveredBy rdf:resource="#mammal"/> </oil:Cover>
First, there is a problem with datatypes. It cannot be enforced that instances of oil:String are really strings or that instances of oil:Integer are really integers. Consequently, it is syntactically possible to state:
<rdf:Property rdf:ID="weight">
<rdf:range>
<oil:Min>
<oil:integerValue>nonsense</oil:integerValue>
</oil:Min>
</rdf:range>
</rdf:Property>
This is due to the fact that the RDF Schema specification has
(intentionally) not specified any primitive datatypes. According to
the specification, the work on data typing in XML itself should be
the foundation for such a capability.
Second, the RDF Schema specification of OIL does not prevent the intertwining of boolean expressions of classes with boolean expressions of concrete data types. Although a statement like (dog and (min 0)) is not allowed in OIL, it is syntactically possible to state:
<oil:And>
<oil:hasOperand rdf:resource="#Dog">
<oil:hasOperand>
<oil:Min>
<oil:integerValue>0</oil:integerValue>
</oil:Min>
</oil:hasOperand>
</oil:And>
To prevent this kind of mixing, we could have introduced separate
boolean operators for class expressions and concrete type
expressions, but in our opinion, this would have made the schema
too convoluted.
Finally, another kind of problem is that the schema cannot prevent the unnecessary use of the OIL variants of standard RDF Schema constructs, like oil:subClassOf, oil:range and oil:domain. Although this unnecessary use does not affect the semantics of the ontology, it limits the compatibility of ontologies with plain RDF Schema.
As for any ontology language, we can distinguish three levels: First, the ontology language, the language in which to state for example class-definitions, subclass-relations, attribute-definitions etc. In our case, RDF Schema and OIL. Second, the ontological classes, for example the classes "giraffe" or "herbivore", their subclass relationships, and their properties (such as eats). These are of course expressed in the language of the first level. Third, the instances of the ontology, such as individual giraffes or lions that belong to classes defined at the second level.
If we look at the existing W3C RDF/RDF Schema recommendation, these levels have the following form:
<rdfs:Class rdf:ID="herbivore"> <rdfs:subClassOf rdf:resource="#animal"> </rdfs:Class> <rdf:Property rdf:ID="eats"/>
<rdf:Description about="http://www.cs.vu.nl/~frankh"> <rdf:type rdf:resource="#herbivore"/> </rdf:Description>
<rdfs:Class rdf:ID="herbivore">
<rdfs:subClassOf rdf:resource="#animal"/>
<oil:hasPropertyRestriction>
<oil:ValueType>
<oil:onProperty rdf:resource="#eats"/>
<oil:toClass>
<oil:Or>
<oil:hasOperand rdf:resource="#plant"/>
<oil:hasOperand>
<oil:HasValue>
<oil:onProperty rdf:resource="#is-part-of"/>
<oil:toClass rdf:resource="#plant"/>
</oil:HasValue>
</oil:hasOperand>
</oil:Or>
</oil:toClass>
</oil:ValueType>
</oil:hasPropertyRestriction>
</rdfs:Class>
the semantics of the hasPropertyRestriction statement will not be
interpretable by an RDF Schema processor. The entire state is legal
RDF syntax, so it can be parsed, but the intended semantics of the
property restriction itself can only be understood by an OIL-aware
application. Notice that the first subClassOf statement is still
fully interpretable even by an OIL-unaware RDF Schema
processor.First, we did not take into account a restriction on the rdfs:subClassOf statement, i.e. the restriction that no cycles are allowed in the subsumption hierarchy. We think that this restriction should be dropped: without cycles one cannot even represent equivalence between two classes - in our view this is an essential modeling primitive for any knowledge representation language. Moreover, these kinds of constraints significantly add to the complexity of parsing/validating RDF documents in a way which we think would be highly undesirable. This is because they are really semantic constraints rather than syntactic ones (they limit the kinds of models that can be represented), even if the reasoning required in order to detect constraint violation is of a very basic kind.
Second, in contrast with RDFS, OIL allows more than one range restriction on a property. Although this can be circumvented by defining a dummy superclass of all classes in the range restriction, we see no reason for this restriction in RDFS. From a modeling point of view, allowing more than one range restriction is a much cleaner solution.
During the process of extending RDFS, we encountered a couple of peculiarities in the RDFS definition itself. The most striking of these is the non-standard object-meta model, as already discussed in section 2.2.1. The main problem with this non-standard model is that some properties have a dual role in the RDFS specification, both at the schema level and instance level (cf. [14]). This makes it quite a challenge for modelers to understand the RDFS specification. We tried to make this distinction clear in our extensions by using the rdf:type relationship consistently as an object-meta relationship.
Furthermore, the semantics of several relationships are unclear. It is not obvious that the meaning of a list of domain (or range) restrictions is the union of the elements. Also, the meaning of the subPropertyOf relation with respect to the inheritance of the domain and range restrictions is unclear.
Of these, only the last three have been defined on top of RDF(S). Since DAML+OIL is essentially a merger between OIL and DAML-ONT, we will focus on the comparison of our own proposal (OIL) to DAML-ONT.
DAML-ONT shares with our own proposal the principle that an ontology language should maintain maximum backwards compatibility with existing web standard languages, and in particular RDF Schema. The difference between OIL and DAML-ONT lies in the degree to which the languages succeed in maximising the ontological content that can be understood by an ``RDF Schema agent'' (i.e. an application that understands RDF Schema but does not recognise the language specific extensions, OIL or DAML-ONT). Unlike OIL, DAML-ONT is built on top of RDFS in a way that allows little if any ontology content to be understood by an RDFS agent. In OIL, for example, stating simple subclass relationships between classes is done using the RDFS subClassOf property:
<rdfs:Class ID="Male"> <rdfs:subClassOf rdf:resource="#Animal"/> </rdfs:Class>This part of OIL ontologies is therefore accessible to any RDFS agent. In contrast, DAML-ONT uses its own locally defined ``subClassOf'' property, for example:
<daml:Class ID="Male"> <daml:subClassOf resource="#Animal"/> </daml:Class>The DAML-ONT subClassOf property is then defined to be ``equivalentTo'' rdfs:subClassOf, but the definition of ``daml:equivalentTo'' itself relies cyclicly on the definition of daml:sub-PropertyOf. Therefore even simple subclass relationships in a DAML ontology are inaccessible to an RDFS agent. The situation is even worse when it comes to more complex class definitions. For example, the definition of the class ``TallMan'' is the intersection of the classes ``Man'' and ``TallThing'' is expressed in DAML-ONT as:
<daml:Class ID="TallMan">
<daml:intersectionOf parseType="daml:collection">
<daml:Class about="#TallThing"/>
<daml:Class about="#Man"/>
</daml:intersectionOf>
</daml:Class>
This is completely opaque to an RDFS agent as it will not
understand the semantics of ``daml:intersectionOf'' In OIL, the
definition of TallMan would rely on the fact that intersection is
implicit in the semantics of rdfs:subClassOf:
<rdfs:Class ID="TallMan"> <rdf:type rdf:resource="http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard#DefinedClass"/> <rdfs:subClassOf rdf:resource="#TallThing"/> <rdfs:subClassOf rdf:resource="#Man"/> </rdfs:Class>making the sub-class relationships accessible to any RDF Schema agent. In conclusion, we argue that:
An important advantage of our approach is the maximization of the compatibility with RDFS: not only is every RDF Schema document a valid OIL ontology declaration, but every OIL ontology can be partially interpreted by a semantically poorer processing agent. This partial interpretation will of course be incomplete, but correct under the intented semantics of the ontology. We firmly believe that our way of extending is generally applicable across knowledge representation formalisms.
2Actually they correspond to binary predicates of ground terms, where, however, the predicates may be used as terms, as well.
3Note, that in this sense a property is an instance of a class.
4It is not really clear from the RDFS specification whether rdfs:subClassOf can be applied to rdf:Property. This seems possible because the latter is also an instance of rdfs:Class.
6A placeholder class in the OIL RDFS specification is only used to apply domain- and range restrictions to a group of classes, and will not be used in the actual OIL ontology.
7For example, it is never possible to derive class membership from a domain statement when union semantics are used.
8With ``valid'' we mean: not allowed by the BNF grammer of OIL. From the logical point of view, there's nothing wrong with a statement like (dog and (min 0)), it just happens to be equivalent to the empty class.
9DAML-ONT Initial Release, "http://www.daml.org/2000/10/daml-ont.html"
10DAML+OIL "http://www.daml.org/2000/12/daml+oil-index.html"
File translated from TEX by TTH, version
2.88.
On 19 Feb 2001, 14:11.