Abstract
This document addresses the issue of using classes as property
values in OWL. It is often convenient to put a class (e.g., Lion)
as a property value (e.g., topic or book subject) when building an ontology.
While OWL Full and RDF Schema do not put any restriction on using classes
as property values,
OWL DL and OWL Lite do not generally allow this use. We present various
use cases to motivate the need for representing classes as values. We examine
several different approaches using OWL and RDF Schema, and suggest how
we might achieve the desired effect of representing classes as values
in OWL DL and OWL Lite. For each approach, we discuss various considerations
that the users should keep in mind when choosing the best approach for
their purposes.
Status of this Document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current
W3C publications and the latest revision of this technical report can be
found in the W3C technical reports index
at http://www.w3.org/TR/.
This document will be a part of a larger document that will provide
an introduction and overview of all ontology design patterns produced by
the Semantic Web Best
Practices and Deployment Working Group.
This document is a W3C Working Draft and is expected to change. The
SWBPD WG does not expect this document to become a Recommendation. Rather,
after further development, review and refinement, it will be published
and maintained as a WG Note.
This document is the First Public Working Draft. We encourage public
comments. Please send comments to public-swbp-wg@w3.org
Open issues, todo items:
-
We identify several OWL DL compatible approaches in this document. The
WG seeks to determine whether there is consensus on a single preferred
approach. The WG therefore seeks input and feedback from the community
on this question. [1]
-
The terms highlighted in blue
will be defined in a dictionary that the OEP task force will produce at
a later date.
Publication as a draft does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or made obsolete
by other documents at any time. It is inappropriate to cite this document
as other than work in progress.
General issue
It is often useful to use classes as values
for properties. While OWL Full and RDF Schema do not put any restriction
on using classes as property
values, OWL DL and OWL Lite do not generally allow such use. In
OWL DL and OWL Lite, most properties cannot have classes as their values.
Use case example
Suppose we have a set of books about animals, and a catalog of these books.
We want to annotate each catalog entry with its subject, which is a particular
species or class of animal that the book is about. Further, we want to
be able to infer that a book about African lions is also a book about lions
(for example, when retrieving all books about lions from a repository,
we want books that are annotated as books about african lions to be included
in the results).
More specifically, consider two book examples: (1) "Lions:
Life in the Pride", which is a book that "presents an introduction
to lions describing their physical characteristics, habitat, young, food,
predators, and relationship to people"; and (2) "The
African Lion," which "describes the physical characteristics, habitat,
and behavior of the" african lions. We would like to specify that the first
book describes the animal species of Lions, and the second describes a
species of African Lion. We also want to retrieve the second book when
a query is about Lions, not just African Lions.
We consider species of animals to be subjects of the books and
would like to use the Dublin Core property dc:subject
for this annotation. Furthermore, we would like to use as our subjects
various species from an existing class hierarchy of different animal species.
We discuss a number of approaches for representing this pattern in OWL
DL and OWL Lite and their implications.
One goal of the web publisher is to enable maximum reuse of published
information. It will be common on the Semantic Web to import and reuse
other published ontologies. Any reuse of existing ontologies on the Semantic
Web (in our case, a hierarchy of animal species) should preserve the original
intended semantics in the new context. If the semantics changes, other
applications already using the ontology may be adversely affected. Interoperation
with existing applications using this ontology will also be error-prone
(since there will be two different interpretations of the same ontology).
Some of the patterns that we suggest below change the interpretation of
the hierarchy of classes used for property values. We suggest that users
take this approach only if they know that no one else is using their ontology
and no one will be adversely affected by such re-interpretation.
Other use case scenarios
This issue arises in general when we have a hierarchy of classes and would
like to use it as a terminology to annotate other classes or individuals.
Consider using a hierarchy of different genres to annotate music CDs, or
linking classes or individuals in an ontology to the corresponding terms
in a standard reference terminology (e.g., UMLS
is such standard reference terminology for many medical applications).
Other use cases for using classes as property values include meta-modeling
and semantic interoperability between systems. This note uses a particular
example (classes as the subjects of books) to illustrate a more general
representation pattern: using classes as property values. This note
should not be interpreted as a general discussion of how to represent subject
hierarchies or terminologies on the semantic web.
Issues for Consideration
In choosing the right approach for a given context, a user must consider
various issues and questions that may impact their abilitly to achieve
their goals. For example, Are there any specific kinds of inferences
that need to be supported? If inferencing is going to feature in
a big way, this may require the use of OWL-Lite or OWL-DL. Is the approach
natural, succinct and easy to understand or is it technically complex?
This could impact on ease of maintenance. Does the approach entail changing
the semantic interpretation of an ontology that is being reused?
If so, this can limit interoperability with systems using the original
meaning. After each approach given below, we address these and other
considerations to assist the reader in making the best choice under their
circumstances..There are many tradeoffs to be considered. For example,
the potential downside of a technically complex or less natural solution
that is required to fit into OWL-DL might be offset by getting the needed
inferences performed efficiently.
Notations
In all the figures below, ovals represent classes and rectangles represent
individuals. The orange color signifies classes or individuals that are
specific to a particular approach. Green arrows with green labels are OWL
annotation properties.We use N3 syntax to represent
the examples.
Approaches
Approach 1: using classes directly as values
In the first approach, we can simply use classes from the subject hierarchy
as values for
properties (in our example, as values for the dc:subject
property). We can define a class Book to represent all books.
For simplicity, in the hierarchy of animals, we omit classes for other
animals, such as mammals and felines (Figure 1).
Figure 1. Using classes directly as property
values.
Here is a definition of an individual (a specific book that we are annotating)
with the corresponding subject (for simplicity, we assume that each book
discusses only one species of animal):
:LionsLifeInThePrideBook
a :Book ;
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life in the Pride" ;
dc:subject :Lion .
The book "The African Lion" will be represented as:
:TheAfricanLionBook
a :Book ;
rdfs:seeAlso <http://isbn.nu/089686328X> ;
:bookTitle "The African Lion" ;
dc:subject :AfricanLion .
And the class AfricanLion is a subclass of the class Lion:
:AfricanLion
a owl:Class;
rdfs:subClassOf :Lion .
Considerations when choosing approach 1:
-
The resulting ontology is compatible with RDF Schema and OWL Full, but
it is outside OWL
DL and OWL Lite.
-
This approach is probably the most succinct and intuitive among all the
approaches proposed here.
-
Applications using this representation can directly access the information
needed to infer that Lion (the subject of the LionsLifeInThePrideBook
individual) is a subclass of Animal and that AfricanLion
(the subject of the TheAfricanLionBook individual) is a subclass
of Lion.
-
If we need to restrict the range of values for the dc:subject
property, then we need to create an additional class for such a restriction.
For instance, we may want to define a class of all books about animals
—BookAboutAnimals—that our lion books will be instances of and
we want to restrict the range of values for the dc:subject property
for the BookAboutAnimals class to the class Animal and
its subclasses. One way to define such restriction is as follows:
:BookAboutAnimals
a owl:Class ;
rdfs:subClassOf :Book ;
rdfs:subClassOf
[ a owl:Class ;
owl:unionOf ([ a owl:Restriction ;
owl:onProperty dc:subject ;
owl:hasValue Animal
]
[ a owl:Restriction ;
owl:onProperty dc:subject ;
owl:someValuesFrom
[ a owl:Restriction ;
owl:onProperty rdfs:subClassOf;
owl:hasValue Animal
]
])
] .
Here we say that the class BookAboutAnimals is a subclass of the
class Book. The class BookAboutAnimals is also a subclass
of the class of all things that must have either the class Animal
itself, or any class that is a subclass of Animal as one of the
values of the dc:subject property.
OWL code for approach 1
[N3] [RDF/XML]
Summary of approach 1
This approach is a good one to use if you care about simplicity, do not
have to be in OWL DL, and either do not need to limit the range of the
dc:subject
values or do not care that you also need to use classes as subjects to
implement this restriction.
Approach 2: Creating a hierarchy of classes to be used
as property values and a parallel set of individuals
We can treat the hierarchy of animal species as a hierarchy of subjects,
create individuals corresponding to all the subjects and use these individuals
as values for the dc:subject
property (Figure 2). Thus, we will have, for example,
an individual LionSubject that will be an instance of the Lion
class.
Figure 2. Using a hierarchy of subjects
and a parallel set of subject individuals.
We can then use the LionSubject as the value of the property
dc:subject
for the LionsLifeInThePrideBook individual:
:LionSubject
a :Lion .
In this case, the definition of the LionsLifeInThePrideBook refers
to the LionSubject individual
:LionsLifeInThePrideBook
a :Book ;
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life in the Pride" ;
dc:subject :LionSubject .
Considerations when choosing approach 2:
-
The resulting ontology is compatible with
RDF Schema and OWL Lite (and hence OWL DL)
-
The class Lion has an instance that is the subject lion.
Creating an instance of the Lion class to represent a specific
lion at the zoo would be inconsistent with this interpretation. Therefore,
we will need to have a different class to represent lions at the
zoo. This change has important implications if the hierarchy of animals
is not created by us, but we imported it from somewhere else. Applications
will interpret the reference to imported classes according to their original
definitions. Other ontologies importing the same hierarchy of animals will
in fact use the original definition. Therefore, there may be inconsistency
not only in our own interpretation but also when our ontology is integrated
with others importing the same resource. This issue is not a problem when
we created our own hierarchy of animals and interoperation is not an issue.
-
In this approach, there is no explicit direct relation (i.e.,
a relation that
a general-purpose reasoner can
readily identify) between the LionSubject individual defined above
and, for example, an AfricanLionSubject individual, which is an
instance of AfricanLion:
:AfricanLionSubject
a :AfricanLion .
An application trying to utilize this relation
(for example, to extract books about african lions when asked for
books about lions), will need to be aware of this specific approach and
know to trace back to the corresponding classes, their subclasses, and
respective instances. A general-purpose reasoner will
not be able to use this information directly. Note however that the individual
AfricanLionSubject
is also an instance of the Lion class. Therefore, if we ask for
all books where dc:subject is an instance of the Lion
class we will get the books that are annotated with AfricanLionSubject.
There is a maintenance penalty: We need to maintain a set of instances
for all subjects in addition to the hierarchy of subjects and ensure that
the two sets—classes representing subjects and corresponding individuals—are
consistent with each other (e.g., that they have the same names, etc.).
However, developers can instrument tools that would maintain this consistency
automatically.
Some may consider this approach to be "too messy" for the simple task at
hand
Defining a range restriction for the dc:subject
property for the class BookAboutAnimals is straightforward. We
define a someValuesFrom restriction that states that some values
of the dc:subject property are instances of the class Animal:
:BookAboutAnimals
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:someValuesFrom :Animal ;
owl:onProperty dc:subject
] .
OWL code for approach 2
[N3] [RDF/XML]
Summary of approach 2
This approach results in an OWL DL ontology and may be a good one to use
if staying in OWL DL is important. The approach has a potential disadvantage
of having actual subject values be unrelated to one another and hence not
allowing a general-purpose reasoner to relate books with a subject "lion"
to books with a subject "african lions", for example. Furthermore, if the
hierarchy of animals is imported and the source uses the hierarchy to describe
actual animals, using this approach is inconsistent with this interpretation.
You need to maintain consistency between the set of classes representing
subjects and the set of corresponding individuals.
Approach 3: using a property other than rdfs:subClassOf
to organize the subject hierarchy
We can create a single class Subject and make all the subjects
to be individuals that are instances of this class Subject (Figure
3):
:LionSubject
a :Subject ;
rdfs:seeAlso :Lion .
We can use the annotation property rdfs:seeAlso to link the LionSubject
individual to the Lion class. Note that rdfs:seeAlso
is an annotation property and hence giving it a value that is a class does
not take us out of OWL DL. In this approach, we are essentially using individuals
as surrogates for classes.
We can then create explicit relations between different subjects, which
will re-create the hierarchy for animals that we have in mind. While we
create our own property parentSubject, we can also use the corresponding
properties from the SKOS-Core
1.0 schema, which is an RDF schema for representing thesauri and similar
types of knowledge organization systems. So, for example parentSubject
is similar to skos:broader. The SKOS schema provides a rich vocabulary
for handling subject hierarchy, with additional properties such as skos:narrower,
skos:related,
and so on.
:parentSubject
a owl:TransitiveProperty , owl:ObjectProperty ;
rdfs:domain :Subject ;
rdfs:range :Subject ;
rdfs:seeAlso <http://www.w3.org/2004/02/skos/core/broader> .
:AfricanLionSubject
a :Subject ;
rdfs:seeAlso :AfricanLion ;
:parentSubject :LionSubject .
Figure 3. Using a property other than rdfs:subClassOf
to organize the subject hierarchy
Considerations when choosing Approach 3
-
The resulting ontology is compatible with RDF Schema and OWL Lite (and
hence OWL DL). However, note that RDF Schema does not have transitive
properties, thus we will not be able to express the transitivity of the
parentSubject
property in RDF Schema.
-
Most DL reasoners will
be able to infer transitive relations between
subjects, such as the fact that AnimalSubject is a parentSubject
of AfricanLionSubject. However, a DL reasoner will
not be able to infer that a book that has LionSubject as the value
for dc:subject is also about Animals. More specialized reasoners
may be able to infer this information.
-
The resulting hierarchy of subjects is not related to or dependent on the
class hierarchy representing the same topics (in this case, animals), except
through an annotation property rdfs:seeAlso. Annotation properties
however, are usually ignored by inference engine.
-
Some may consider a approach having two parallel hierarchies of essentially
the same data to be too complicated and difficult to maintain for the simple
task at hand
-
This approach explicitly separates the subject terminology from the corresponding
ontology. Many consider this separation a good modeling practice: the semantics
of a subject Lion can be different from the semantics of the class
of lions. Having subjects in a separate hierarchy, would allow us to define
for example that the subject Africa is a parent subject of the
subject AfricanLion.
-
The separation of the subject terminology from the corresponding ontology
incurs a serious maintenance penalty: We need to maintain a set of instances
for all subjects in addition to the hierarchy of subjects. In many applications,
we may also need to ensure that the two sets—classes representing subjects
and corresponding individuals and values for the parentSubject
property—are consistent with each other. However, developers can instrument
tools that would maintain this consistency automatically.
-
Defining a range restriction for the dc:subject
property for the class BookAboutAnimals is straightforward. We
restrict the values of the dc:subject property to the instances
of the class Subject:
:BookAboutAnimals
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:someValuesFrom :Subject ;
owl:onProperty dc:subject
] .
OWL code for approach 3
[N3] [RDF/XML]
Summary of approach 3
This approach may be a good one to use if staying within OWL DL is important.
It also allows you to use a DL reasoner to infer transitive relationships
between subjects. It does carry the penalty of having two parallel "hierarchies."
Approach 4: using members of a class as values for the
property
This approach is designed to make it easy to leverage a DL reasoner to
infer, for example, that a book whose subject is Lion is also a book whose
subject is Animal. In this approach, we create a class such as BookAboutLions
which [in effect] represents the set of all books whose subject is Lions.
We assign a subject to a specific book by making the book an instance of
one of these classes (e.g. LionsLifeInThePrideBook). We create similar
classes for any subject category of books that we are interested in (e.g.
BookAboutAnimals, BookAboutAfricanLions). There is a correspondence between
each of these subject-specific classes of books and the class in the species
hierarchy being used as the subject.
The key to making this work is the manner in which we define the new
book classes. Becuase these classes represent all the books about a particular
subject, we include subject in the definition as in the following definition
of BookAboutLions:
:BookAboutLions
a owl:Class ;
owl:equivalentClass
[ a owl:Class ;
owl:intersectionOf ([ a owl:Restriction ;
owl:onProperty dc:subject ;
owl:someValuesFrom :Lion
]
:Book)
] .
A specific instance of this class LionsLifeInThePrideBook would
then be defined as follows:
:LionsLifeInThePrideBook
a :BookAboutLions ;
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life in the Pride" .
This is how we achieve the effect of saying that subject of the book, LionsLifeInThePrideBook
is lions. What this is saying, literally, is that this book is a member
of a class, all of whose members have at least one instance of the class
Lion
as the value for the dc:subject property. In OWL, it is
not necessary to create any explicit instances of these classes. In the
figure, we list them as if the were explicit, and use dotted lines to denote
that they may not actually exist.
Figure 4. Using members of a class as values
for properties.
Put another way, this approach is approximating the interpretation
that we used in the previous approaches by using unspecified members of
a class rather than the class itself as property values (Figure
4). We define the class BookAboutAnimals as a class of books
where the subject is some (unidentified) animal or animals. Similarly,
a BookAboutLions class will be a class of books where a subject
is some (unidentified) lion or lions:
There is a variant to this approach in which we create merge the two
steps into one. Instead of creating an explicit named class, BookAboutLions,
and then creating an instance of this class, we create the instance and
assign its type to be an anonymous class defined using owl:Restriction.
In this variant, there is no explicit class corresponding to BookAboutLions.
This variant is illustrated by following alternative definition of
LionsLifeInThePrideBook.
:LionsLifeInThePrideBook
a :Book;
[ a owl:Restriction ;
owl:onProperty dc:subject ;
owl:someValuesFrom :Lion
];
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life in the Pride" .
A DL classifier will be able to classify LionsLifeInThePrideBook
as an instance of the class BookAboutLions
Considerations when choosing Approach 4
-
The resulting ontology is compatible with OWL DL. Since this approach
uses restrictions, which do not have any semantics in RDF Schema, we cannot
use this approach for RDF Schema.
-
The interpretation of this pattern is
different
from interpretations of the other patterns in this note: the subject of
the book is one or more specific lions—individuals in the
Lion
class—rather than the Lion class itself . In this case, a book
about lions is a book about some lions, even if that happens to
be all lions.
-
A Description Logic reasoner will be able to classify automatically the
individual LionsLifeInThePrideBook that has an instance of a Lion
class as its subject as an instance of the class BookAboutLions.
It will also be able to classify the class BookAboutLions defined
above as a subclass of the class BookAboutAnimals (defined in
a similar way).
-
This approach is likely to be the easiest approach to use if you would
like to employ DL reasoning to classify books based on their subjects.
-
Many would consider it more cumbersome to express a simple fact that the
subject of a book is "lions" by creating a new (usually, anonymous) restriction
class and making that class to be the type of the book.
OWL code for approach 4
[N3] [RDF/XML]
Summary of approach 4
This approach can make the most use of DL classifiers. It represents a
different interpretation of the subject as being a prototypical instance
of a class rather than a whole class of things or a specific subject corresponding
to that class. With the understanding that you are using a different interpretation,
this approach may be a good one to use if using DL reasoners to classify
individuals based on their subjects (or another property used in its place)
is important.
Approach 5: using classes as values for annotation properties
Another way to stay in OWL DL is to use classes as values for annotation
properties (Figure 5). This approach is very similar
to approach 1, but it treats dc:subject as an annotation property:
Figure 5. Using classes as values for annotation
properties.
dc:subject
a owl:AnnotationProperty .
:LionsLifeInThePrideBook
a :Book ;
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life In The Pride" ;
dc:subject :Lion .
Considerations when choosing Approach 5
-
In OWL DL, annotation properties cannot at the same time be defined either
object properties or datatype properties. Thus, if dc:subject
(or another property you want to use) is defined elsewhere as an object
property or a datatype property, it cannot be used as an annotation property.
-
In OWL DL, annotation properties cannot have any restrictions, such as
cardinality or domain/range restrictions, or subproperties. Thus, if you
use this approach, you cannot specify that each book should have at least
one subject for example or that individuals that are instances of BookAboutAnimals
must all be subclasses of the Animal class.
-
Even if the ontology is in OWL DL (i.e., the annotation properties are
used consistent with OWL DL restrictions), DL reasoners will not use the
information in annotation properties for reasoning. Thus, in order to extract
a book about lions when queried for animal books, one would need to use
special-purpose reasoning that uses annotation properties and can perform
reasoning with them.
OWL code for approach 5
[N3] [RDF/XML]
Summary of approach 5
This approach allows you to use classes directly as property
values while staying in OWL DL. However, the properties that will
have classes as values will have to be defined as annotations and therefore
cannot have any additional restrictions defined on them (and should not
be declared as object or datatype properties elsewhere). DL reasoners will
not use values of annotation properties.
References
[1]http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0152.html
Changes from the previous version
-
Throughout the document, fixed the wording that said that rdf:type is the
only property that can have class as its value in OWL DL. Replaced it with
"In OWL DL and OWL Lite, most properties cannot have classes as their values.
"
-
In Approach 3, second bullet added the following: "However, a DL reasoner
will not be able to infer that a book that has LionSubject as the value
for dc:subject is also about Animals. More specialized reasoners may be
able to infer this information."
-
Removed examples using abstract syntax
-
In General issues, removed the following sentence: "Within a closed system
that is under the control of a single design authority, this is not a problem,
since the designer can use the natural pattern if the system is not restricted
to using Description Logic reasoners, or use a different pattern if using
Description Logic reasoners is required."
-
Noted that approaches 4 and 5 don't make sense in RDF Schema
-
Added figure numbers
-
Added references
-
Changed abstract to reflect better what the document is about
-
Minor fixes throughout the document
References
-
[N3]
-
Primer: Getting into
RDF and Semantic Web using N3, http://www.w3.org/2000/10/swap/Primer
.
-
[OWL Overview]
-
OWL Web
Ontology Language Overview, Deborah L. McGuinness and Frank van
Harmelen, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/
. Latest version available
at http://www.w3.org/TR/owl-features/ .
-
[OWL Guide]
-
OWL Web
Ontology Language Guide, Michael K. Smith, Chris Welty, and Deborah
L. McGuinness, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-guide-20040210/
. Latest version available
at http://www.w3.org/TR/owl-guide/ .
-
[OWL
Semantics and Abstract Syntax]
-
OWL
Web Ontology Language Semantics and Abstract Syntax, Peter F. Patel-Schneider,
Patrick Hayes, and Ian Horrocks, Editors, W3C Recommendation, 10 February
2004, http://www.w3.org/TR/2004/REC-owl-semantics-20040210/ . Latest
version available at http://www.w3.org/TR/owl-semantics/ .
-
[RDF Primer]
-
RDF Primer,
Frank Manola and Eric Miller, Editors, W3C Recommendation, 10 February
2004, http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ . Latest
version available at http://www.w3.org/TR/rdf-primer/ .
-
[RDF Semantics]
-
RDF Semantics,
Pat Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
. Latest version available at
http://www.w3.org/TR/rdf-mt/ .
-
[RDF Vocabulary]
-
RDF Vocabulary
Description Language 1.0: RDF Schema, Dan Brickley and R. V. Guha,
Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/
. Latest version available
at http://www.w3.org/TR/rdf-schema/ .
Acknowledgements
The editor would like to thank the following Working Group members for
their contributions to this document: Aldo Gangemi, Pat Hayes, Aditya Kalyanpur,
Brian McBride, Alan Rector, Michael Uschold, Bernard Vatant, and Chris
Welty. Atanas Kiryakov, Peter Mika, and York Sure have also contributed
to the document.
This document is a product of the Ontology Engineering and Patterns
Task Force of the Semantic Web Best Practices and Deployment Working Group.
