You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1 lines
44 KiB
1 lines
44 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Representing Classes As Property Values on the Semantic Web </title>
<link rel="stylesheet" type="text/css"
href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css">
</head>
<body>
<div class="head"> <a href="http://www.w3.org/"><img
src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48"
width="72"></a>
<h1>Representing Classes As Property Values on the Semantic Web</h1>
<h2> W3C Working Group Note 5 April 2005</h2>
<dl>
<dt>This version:</dt>
<dd><a href="http://www.w3.org/TR/2005/NOTE-swbp-classes-as-values-20050405">http://www.w3.org/TR/2005/NOTE-swbp-classes-as-values-20050405</a><br />
<dt>Latest version:</dt>
<dd><a href="http://www.w3.org/TR/swbp-classes-as-values">http://www.w3.org/TR/swbp-classes-as-values</a></dd>
<dt>Previous version:</dt>
<dd><a href="http://www.w3.org/TR/2004/WD-swbp-classes-as-values-20040721">http://www.w3.org/TR/2004/WD-swbp-classes-as-values-20040721</a></dd>
<dt>Editor:</dt>
<dd><a href="http://smi.stanford.edu/people/noy">Natasha Noy</a>, Stanford
University</dd>
<dt>Contributors:</dt>
<dd><a href="mailto:michael.f.uschold@boeing.com">Michael Uschold</a>, Boeing</dd>
<dd><a href="http://www.research.ibm.com/people/w/welty/">Chris Welty</a>,
IBM Research</dd>
<dt> </dt>
<dd>Also see <a href="#acknowledgements">Acknowledgements</a>.</dd>
</dl>
<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">
Copyright</a> ©2005 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
(<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts
Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.org/"><acronym title="European Research
Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
<!-- end copyright -->
<hr></div>
<!-- end of head -->
<h2 class="notoc"><a name="abstract" id="abstract"></a>Abstract</h2>
This document addresses the issue of using classes as property values in OWL and
RDF Schema. It is often convenient to put a class (e.g., <code>Animal</code>)
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, in OWL DL and OWL Lite most properties cannot have classes as their values. We
illustrate the direct approach for representing classes as property values in
OWL-Full and RDF Schema. We present various alternative mechanisms for representing
the required information 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.
<h2 id="Status">Status of this Document</h2>
<p><em>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 <a href="http://www.w3.org/TR/">W3C
technical reports index</a> at http://www.w3.org/TR/.</em></p>
<p>This document is a <a href="http://www.w3.org/2004/02/Process-20040205/tr.html#WGNote">Working
Group Note</a>, produced by the <a href="http://www.w3.org/2001/sw/BestPractices/OEP/">Ontology
Engineering and Patterns Task Force</a> in the <a href="http://www.w3.org/2001/sw/BestPractices/">Semantic
Web Best Practices and Deployment Working Group</a>, part of the
<a href="http://www.w3.org/2001/sw/">W3C Semantic Web Activity</a>.
This document is one of a series of documents that is produced by the
task force. Comments on this document may be sent to
<a href="mailto:public-swbp-wg@w3.org">public-swbp-wg@w3.org</a>,
a mailing list with a
<a href="http://lists.w3.org/Archives/Public/public-swbp-wg/"
>public archive</a>.</p>
<p>Publication as a Working Group Note does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.</p>
<hr>
<h2 id="general">General issue</h2>
It is often convenient to put a class (e.g., <code>Animal</code>) as a property
value (e.g., topic or book subject) when building an ontology. While OWL Full
[<a href="#ref-OWL-Overview">OWL Overview</a>] and RDF Schema [<a href="#RDFS">RDFS</a>]
do not put any restriction on using classes as property values, in OWL DL
and OWL Lite most properties cannot have classes as their values.
<h2 id="useCase">Use case example</h2>
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.
<p>More specifically, consider two book examples: (1) <a href="http://isbn.nu/0736809643">"Lions:
Life in the Pride"</a>, which is a book that "presents an introduction to lions
describing their physical characteristics, habitat, young, food, predators,
and relationship to people"; and (2) <a href="http://isbn.nu/089686328X">"The
African Lion</a>," 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 lion, 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. </p>
<p>We consider species of animals to be <i>subjects</i> of the books
and
would like to use the Dublin Core property <code><a
href="http://purl.org/dc/elements/1.1/subject">dc:subject</a></code>
for this annotation. Furthermore, we would like to use as our
subjects
various species from an existing class hierarchy of different animal
species.
</p>
<p>We examine representation of this information in OWL and RDF Schema and suggest
different ways of capturing this information in OWL DL and OWL Lite. </p>
<p>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 will be adversely
affected by such re-interpretation. </p>
<h2 id="scenarios">Other use case scenarios</h2>
<p>This issue arises in general when we have a hierarchy of classes and would
like to use it as a <i>terminology</i> 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. For example, <a
href="http://www.nlm.nih.gov/research/umls/">UMLS</a> is a standard reference
terminology for many medical applications. One may want to have a <code>hasDiagnosis</code>
relation from an instance of a patient to a class representing a disease indicating
the patient was diagnosed with that disease. Other use cases for using
classes as property values include meta-modeling and semantic interoperability
between systems. </p>
<p>This note uses a particular example (classes as the subjects of books) to illustrate
a more general representation issue: using classes as property values.
<span
style="font-weight: bold;">This note should not be interpreted as a general discussion
of how to represent subject hierarchies or terminologies on the semantic web</span>.
</p>
<h2 id="notations">Notations</h2>
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 <a
href="http://www.w3.org/TR/owl-ref/#Annotations">OWL annotation properties</a>.
We use <a href="#ref-n3">N3 syntax</a> to represent the examples.
<h2 id="approaches">Approaches</h2>
<h3> <a name="1"></a>Approach 1: Use classes directly as property values</h3>
In the first approach, we can simply use classes from the subject
hierarchy
as values for properties (in our example, as values for the <code>dc:subject</code>
property). We can define a class <code>Book</code> to represent all books.
For simplicity, in the hierarchy of animals, we omit classes for other
animals, such as mammals and felines (<a href="#figure1">Figure 1</a>).
<p><img src="fig1.jpg" alt="Using classes directly as values"></p>
<p><a name="figure1"></a><b>Figure 1</b>. Using classes directly as
property
values.
</p>
<p>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):
</p>
<div class="exampleOuter">
<div class="exampleInner">
<pre>:LionsLifeInThePrideBook<br> a :Book ;<br> rdfs:seeAlso <http://isbn.nu/0736809643> ;<br> :bookTitle "Lions: Life in the Pride" ;<br> dc:subject :Lion .</pre>
</div>
</div>
The book "The African Lion" will be represented as:
<pre>:TheAfricanLionBook<br> a :Book ;<br> rdfs:seeAlso <http://isbn.nu/089686328X> ;<br> :bookTitle "The African Lion" ;<br> dc:subject :AfricanLion .</pre>
And the class <code>AfricanLion</code> is a subclass of the class <code>Lion</code>:
<pre>:AfricanLion<br> a owl:Class;<br> rdfs:subClassOf :Lion .</pre>
<h4 id="considerations1">
Considerations when choosing approach 1:</h4>
<ul>
<li>The resulting ontology is compatible with RDF Schema and OWL
Full, but
it is <i>outside OWL
DL and OWL Lite</i>.</li>
<li>This approach is probably the most succinct and intuitive among
all the
approaches proposed here.</li>
<li>Applications using this representation can directly access the
information
needed to infer that <code>Lion</code> (the subject of the <code>LionsLifeInThePrideBook</code>
individual) is a subclass of <code>Animal</code> and that <code>AfricanLion</code>
(the subject of the <code>TheAfricanLionBook</code> individual) is a
subclass
of <code>Lion</code>.</li>
<li>If we need to restrict the range of values for the <code>dc:subject</code>
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—<code>BookAboutAnimals</code>—that
our animal books will be instances of and we want to restrict the range of
values for the <code>dc:subject</code> property for the <code>BookAboutAnimals</code>
class to the class <code>Animal</code> and its subclasses. One way to define
such restriction is as follows:
<pre>:BookAboutAnimals<br> a owl:Class ;<br> rdfs:subClassOf :Book ;<br> rdfs:subClassOf<br> [ a owl:Class ;<br> owl:unionOf ([ a owl:Restriction ;<br> owl:onProperty dc:subject ;<br> owl:hasValue Animal<br> ] <br> [ a owl:Restriction ;<br> owl:onProperty dc:subject ;<br> owl:someValuesFrom<br> [ a owl:Restriction ;<br> owl:onProperty rdfs:subClassOf;<br> owl:hasValue Animal <br> ]<br> ])<br> ] .</pre>
Here we say that the class <code>BookAboutAnimals</code> is a subclass of
the
class <code>Book</code>. The class <code>BookAboutAnimals</code> is also a
subclass
of the class of all things that must have either the class <code>Animal</code>
itself, or any class that is a subclass of <code>Animal</code> as one of
the
values of the <code>dc:subject</code> property.</li>
</ul>
<h4 id="owlcode1">
OWL code for approach 1</h4>
[<a href="books1.n3">N3</a>] [<a href="books1.owl">RDF/XML</a>]
<h4 id="summary1">Summary of approach 1</h4>
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 <code><a href="http://purl.org/dc/elements/1.1/subject">dc:subject</a></code>
values or do not care that you also need to use classes as subjects to implement
this restriction.
<h3><a name="2"></a>Approach 2: Create special instances of the class to be used
as property values</h3>
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 <code><a href="http://purl.org/dc/elements/1.1/subject">dc:subject</a></code>
property (<a href="#figure2">Figure 2</a>).
<p><img src="fig2.jpg"
alt="Creating a hierarchy of subjects and a parallel set of subject individuals"></p>
<p><a name="figure2"></a><b>Figure 2.</b> Using a hierarchy of subjects
and a parallel set of subject individuals.
</p>
<p>Thus, we will have, for example, an individual <code>LionSubject</code> that
will be an instance of the <code>Lion</code> class:</p>
<pre> :LionSubject<br> a :Lion .</pre>
We can then use the <code>LionSubject</code> as the value of the property <code><a href="http://purl.org/dc/elements/1.1/subject">dc:subject</a></code>
for the <code>LionsLifeInThePrideBook</code> individual:
<pre>:LionsLifeInThePrideBook<br> a :Book ;<br> rdfs:seeAlso <http://isbn.nu/0736809643> ;<br> :bookTitle "Lions: Life in the Pride" ;<br> dc:subject :LionSubject .</pre>
<h4 id="considerations2">
Considerations when choosing approach 2:</h4>
<ul>
<li>The resulting ontology is compatible with <em>RDF Schema</em> and <i>OWL
Lite </i>(and hence <i>OWL DL</i>)</li>
<li>The class <code>Lion</code> has an instance that is the <i>subject</i> lion.
Creating an instance of the <code>Lion</code> 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 consideration is not a problem when interoperability
is not an issue.</li>
<li>In this approach, there is no explicit direct relation (i.e.,
a relation that a general-purpose reasoner can
readily identify) between the <code>LionSubject</code> individual defined
above
and, for example, an <code>AfricanLionSubject</code> individual, which is
an
instance of <code>AfricanLion</code>:
<pre>:AfricanLionSubject<br> a :AfricanLion .</pre>
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 <code>AfricanLionSubject</code>
is also an instance of the <code>Lion</code> class. Therefore, if we ask
for
all books where <code>dc:subject</code> is an instance of the <code>Lion</code>
class we <i>will</i> get the books that are annotated with <code>AfricanLionSubject</code>.</li>
<li>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.</li>
<li>Some may consider this approach to be "too messy" for the simple
task
at
hand</li>
<li>Defining a range restriction for the <code><a
href="http://purl.org/dc/elements/1.1/subject">dc:subject</a></code>
property for the class <code>BookAboutAnimals</code> is straightforward.
We
define a <code>someValuesFrom</code> restriction that states that some
values
of the <code>dc:subject</code> property are instances of the class <code>Animal</code>:
<pre> :BookAboutAnimals<br> a owl:Class ;<br> rdfs:subClassOf<br> [ a owl:Restriction ;<br> owl:someValuesFrom :Animal ;<br> owl:onProperty dc:subject<br> ] .</pre></li>
</ul>
<h4 id="owlcode2">
OWL code for approach 2</h4>
[<a href="books2.n3">N3</a>] [<a href="books2.owl">RDF/XML</a>]
<h4 id="summary2">Summary of approach 2</h4>
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.
<h3><a name="3"></a>Approach 3: Create a parallel hierarchy of instances as property
values</h3>
We can create a single class <code>Subject</code> and make all the subjects to
be individuals that are instances of this class <code>Subject</code> (<a
href="#figure3">Figure 3</a>):
<pre> :LionSubject<br> a :Subject ;<br> rdfs:seeAlso :Lion .</pre>
<img src="fig3.jpg"
alt="using a property other than rdfs:subclassOf to organize the subject hierarchy">
<p><a name="figure3"></a><b>Figure 3. </b>Using a property other than <code>rdfs:subClassOf</code>
to organize the subject hierarchy </p>
We can use the annotation property <code>rdfs:seeAlso</code> to link the <code>LionSubject</code>
individual to the <code>Lion</code> class. Note that <code>rdfs:seeAlso</code>
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.
<p>We can then create explicit relations between different subjects, which will
re-create the hierarchy for animals that we have in mind. </p>
<pre> :parentSubject<br> a owl:TransitiveProperty , owl:ObjectProperty ;<br> rdfs:domain :Subject ;<br> rdfs:range :Subject ;<br> rdfs:seeAlso <http://www.w3.org/2004/02/skos/core#broader> .<br><br>:AfricanLionSubject<br> a :Subject ;<br> rdfs:seeAlso :AfricanLion ;<br> :parentSubject :LionSubject .</pre>
While we
create our own property <code>parentSubject</code>, we can also use the
corresponding
properties from the <a href="http://www.w3.org/2004/02/skos/core/">SKOS-Core
1.0 schema</a>, which is an RDF schema for representing thesauri and
similar
types of knowledge organization systems. So, for example <code>parentSubject</code>
is similar to <code>skos:broader</code>. The SKOS schema provides a rich
vocabulary
for handling subject hierarchy, with additional properties such as <code>skos:narrower</code>,
<code>skos:related</code>,
and so on.
<h4 id="considerations3">Considerations when choosing Approach 3</h4>
<ul>
<li>The resulting ontology is compatible with RDF Schema and <i>OWL
Lite </i>(and
hence <i>OWL DL</i>). However, note that RDF Schema does not have
transitive
properties, thus we will not be able to express the transitivity of the
<code>parentSubject</code>
property in RDF Schema.</li>
<li>Most DL reasoners will be able to infer transitive relations between
subjects, such as the fact that <code>AnimalSubject</code> is a <code>parentSubject</code>
of <code>AfricanLionSubject</code>. However, a DL reasoner will
not be able to infer that a book that has <code>LionSubject</code> as the
value
for <code>dc:subject</code> is also about Animals. More specialized
reasoners
may be able to infer this information.</li>
<li>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 <code>rdfs:seeAlso</code>. Annotation properties
however, are usually ignored by inference engines.</li>
<li>Some may consider the approach of having two parallel hierarchies representing
essentially the same information to be too complicated and difficult to maintain
for the simple task at hand</li>
<li>This approach explicitly separates the subject terminology from
the
corresponding
ontology. Many consider this separation a good modeling practice: the
semantics
of a subject <code>Lion</code> 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 <code>Africa</code> is a parent subject of
the
subject <code>AfricanLion</code>.</li>
<li>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 <code>parentSubject</code>
property—are consistent with each other. However, developers can
instrument
tools that would maintain this consistency automatically.</li>
<li>Defining a range restriction for the <code><a
href="http://purl.org/dc/elements/1.1/subject">dc:subject</a></code>
property for the class <code>BookAboutAnimals</code> is straightforward.
We
restrict the values of the <code>dc:subject</code> property to the
instances
of the class <code>Subject</code>:
<pre> :BookAboutAnimals<br> a owl:Class ;<br> rdfs:subClassOf<br> [ a owl:Restriction ;<br> owl:someValuesFrom :Subject ;<br> owl:onProperty dc:subject<br> ] .</pre></li>
</ul>
<h4 id="owlcode3">
OWL code for approach 3</h4>
[<a href="books3.n3">N3</a>] [<a href="books3.owl">RDF/XML</a>]
<h4 id="summary3">Summary of approach 3</h4>
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."
<h3><a name="4"></a>Approach 4: Create a special restriction in lieu of using
a specific value</h3>
<p>This approach enables us to use a DL reasoner to infer, for example, that a
book that has <code>Lion</code> as a subject also has <code>Animal</code> as
its subject. In this approach, we create a new class to represent a class of
all books with a particular subject. For example, we create a class <code>BookAboutLions</code>
to represent all books that have <code>Lion</code> as one of their subjects.
We then assign a subject to a specific book by making the book an instance of
one of these classes, instead of explicitly setting a property value for the
instance. Thus, for example the individual <code>LionsLifeInThePrideBook</code>
will be an instance of the class <code>BookAboutLions</code> (<a
href="#figure4">Figure 4</a>). We create similar classes for any subject category
of books that we are interested in, such as <code>BookAboutAnimals</code>, <code>BookAboutAfricanLions</code>
. </p>
<p><img src="fig4.jpg"
alt="using members of a class as values for the property"></p>
<p><a name="figure4"></a><b>Figure 4. </b>Using members of a class as values for
properties. </p>
<p>The key in this pattern is the definition of the new book classes. Because
these classes represent all the books about a particular subject, we include
subject in the definition. The following, for example, is the definition of
the class <code>BookAboutLions</code>: </p>
<pre>:BookAboutLions<br> a owl:Class ;<br> owl:equivalentClass<br> [ a owl:Class ;<br> owl:intersectionOf ([ a owl:Restriction ;<br> owl:onProperty dc:subject ;<br> owl:someValuesFrom :Lion<br> ] <br> :Book)<br> ] .</pre>
A specific instance of this class <code>LionsLifeInThePrideBook</code>
would
then be defined as follows:
<pre>:LionsLifeInThePrideBook<br> a :BookAboutLions ;<br> rdfs:seeAlso <http://isbn.nu/0736809643> ;<br> :bookTitle "Lions: Life in the Pride" .</pre>
<p>The code above says, literally, that this book instance (<code>LionsLifeInThePrideBook</code>)
is an instance of a class, all of whose members have at least one instance of
the class <code>Lion</code> as the value for the <code>dc:subject</code> property.
In OWL, it is not necessary to create any explicit instances of these classes
that we use in the <code>someValuesFrom</code> restriction (e.g., <code>Lion</code>
above). In <a
href="#figure4">Figure 4</a>, we include these instances in the diagram as if
they were explicit, and use dotted lines to denote that they may not actually
exist. </p>
<p>This approach <i>approximates</i> the interpretation that we used in the previous
approaches by using unspecified members of a class rather than the class itself
as property values (<a
href="#figure4">Figure 4</a>). We define the class <code>BookAboutAnimals</code>
as a class of books where the subject is <i>some</i> (unidentified) animal or
animals. Similarly, a <code>BookAboutLions</code> class will be a class of books
where a subject is <i>some</i> (unidentified) lion or lions.</p>
<p>A DL reasoner will be able to classify <code>LionsLifeInThePrideBook</code>
as an instance of the class <code>BookAboutAnimals.</code> </p>
<p>Note that there a correspondence between the hierarchy of classes of books
on specific subjects (such as <code>BookAboutAnimals</code>, <code>BookAboutLions</code>,
and <code>BookAboutAfricanLions</code>) and the classes in the species hierarchy
that we use as subjects (<code>Animal</code>, <code>Lion</code>, <code>AfricanLion</code>).
The hierarchy of books essentially parallels the hierarchy of subjects, although
it does not have to have a book class corresponding to each subjects—only
the subjects that we are interested in. If the book classes are defined as above,
a DL reasoner will be able to infer automatically the hierarchy of book classes,
based on the hierarchy of subjects.</p>
<p>There is a variant to this approach in which we merge the two steps into one.
Instead of creating an explicit named class, <code>BookAboutLions</code>, and
then creating an instance of this class, we create the instance and assign its
type to be an anonymous class of type <code>owl:Restriction</code>. In this
variant, there is no explicitly named class corresponding to <code>BookAboutLions</code>.
For example, we can define <code>LionsLifeInThePrideBook</code> as follows:</p>
<pre>:LionsLifeInThePrideBook<br> a :Book;<br> [ a owl:Restriction ;<br> owl:onProperty dc:subject ;<br> owl:someValuesFrom :Lion<br> ];<br> rdfs:seeAlso <http://isbn.nu/0736809643> ;<br> :bookTitle "Lions: Life in the Pride" .</pre>
<h4 id="considerations4">Considerations when choosing Approach 4</h4>
<ul>
<li>The resulting ontology is compatible with <i>OWL DL. </i>Since
this
approach
uses restrictions, which do not have any semantics in RDF Schema, we
cannot
use this approach for RDF Schema.</li>
<li>The <em>interpretation</em> 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 <code>Lion</code> class—rather than
the <code>Lion</code> class itself . In this case, a book about lions is a book
about <i>some</i> lions, even if that happens to be all lions.</li>
<li>A Description Logic reasoner will be able to classify automatically the
individual <code>LionsLifeInThePrideBook</code> that has an instance of a <code>Lion</code>
class as its subject as an instance of both the class <code>BookAboutLions</code>
and <code>BookAboutAnimals</code>. It will also be able to classify the class
<code>BookAboutLions</code> defined above as a subclass of the class <code>BookAboutAnimals</code>
(defined in a similar way).</li>
<li>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.</li>
<li>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.</li>
</ul>
<h4 id="owlcode4">
OWL code for approach 4</h4>
[<a href="books4.n3">N3</a>] [<a href="books4.owl">RDF/XML</a>]
<h4 id="summary4">Summary of approach 4</h4>
This approach can make the most use of DL reasoners. 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.
<h3><a name="5"></a>Approach 5: Use classes directly as annotation property values</h3>
Another way to stay in OWL DL is to use classes as values for <a
href="http://www.w3.org/TR/owl-ref/#Annotations">annotation</a> properties (<a href="#figure5">Figure
5</a>). This approach is very similar to approach 1, but it treats <code>dc:subject</code>
as an annotation property:
<p> </p>
<pre>dc:subject<br> a owl:AnnotationProperty .</pre>
<pre>:LionsLifeInThePrideBook<br> a :Book ;<br> rdfs:seeAlso <http://isbn.nu/0736809643> ;<br> :bookTitle "Lions: Life In The Pride" ;<br> dc:subject :Lion .</pre>
<p></p>
<p><img src="fig5.jpg"
alt="Using classes as values for annotation properties" height="302"
width="468"></p>
<p><a name="figure5"></a><b>Figure 5.</b> Using classes as values for annotation
properties. </p>
<h4 id="considerations5">Considerations when choosing Approach 5</h4>
<ul>
<li>In OWL DL, annotation properties cannot at the same time be
defined
either
object properties or datatype properties. Thus, if <code>dc:subject</code>
(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.</li>
<li>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 <code>BookAboutAnimals</code>
must all be subclasses of the <code>Animal</code> class.</li>
<li>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.</li>
</ul>
<h4 id="owlcode5">
OWL code for approach 5</h4>
[<a href="books5.n3">N3</a>] [<a href="books5.owl">RDF/XML</a>]
<h4 id="summary5">Summary of approach 5</h4>
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.
<hr>
<h2><a name="References" id="References"></a>References</h2>
<dl>
<dt><a name="ref-n3" id="ref-n3"></a>[N3]</dt>
<dd><i><a href="http://www.w3.org/2000/10/swap/Primer">Primer:
Getting into
RDF and Semantic Web using N3</a></i>,
http://www.w3.org/2000/10/swap/Primer
.</dd>
<dt><a name="ref-OWL-Overview" id="ref-OWL-Overview"></a>[OWL
Overview]</dt>
<dd><i><a href="http://www.w3.org/TR/2004/REC-owl-features-20040210/">OWL
Web
Ontology Language Overview</a></i>, Deborah L. McGuinness and Frank van
Harmelen, Editors, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-features-20040210/
. <a href="http://www.w3.org/TR/owl-features/">Latest version</a>
available
at http://www.w3.org/TR/owl-features/ .</dd>
<dt><a name="ref-owl-guide" id="ref-owl-guide"></a>[OWL Guide]</dt>
<dd><i><a href="http://www.w3.org/TR/2004/REC-owl-guide-20040210/">OWL
Web
Ontology Language Guide</a></i>, 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/
. <a href="http://www.w3.org/TR/owl-guide/">Latest version</a>
available
at http://www.w3.org/TR/owl-guide/ .</dd>
<dt><a name="ref-owl-abstract-syntax" id="ref-owl-abstract-syntax"></a>[OWL
Semantics and Abstract Syntax]</dt>
<dd><i><a href="http://www.w3.org/TR/2004/REC-owl-semantics-20040210/">OWL
Web Ontology Language Semantics and Abstract Syntax</a></i>, 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/ . <a
href="http://www.w3.org/TR/owl-semantics/">Latest
version</a> available at http://www.w3.org/TR/owl-semantics/ .</dd>
<dt><a id="RDF" name="RDF">[RDF]</a></dt>
<dd>
<a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">
<cite>Resource Description Framework (RDF) Model and Syntax Specification</cite>
</a>,
Ora Lassila, Ralph R. Swick, Editors.
World Wide Web Consortium Recommendation, 1999, <br />
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.<br />
<a href="http://www.w3.org/TR/REC-rdf-syntax/">Latest version</a>
available at http://www.w3.org/TR/REC-rdf-syntax/.
</dd>
<dt>
<a id="RDFS" name="RDFS">[RDFS]</a>
</dt>
<dd>
<a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/">
<cite>RDF Vocabulary Description Language 1.0: RDF Schema</cite>
</a>,
Dan Brickley and R.V. Guha, Editors.
W3C Recommendation, 10 February 2004,<br />
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .<br />
<a href="http://www.w3.org/TR/rdf-schema/">Latest version</a>
available at http://www.w3.org/TR/rdf-schema/.
</dd>
<dt><a name="ref-RDF-Semantics" id="ref-RDF-Semantics"></a>[RDF
Semantics]</dt>
<dd><i><a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/">RDF
Semantics</a></i>,
Pat Hayes, Editor, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
. <a href="http://www.w3.org/TR/rdf-mt/">Latest version</a> available
at
http://www.w3.org/TR/rdf-mt/ .</dd>
<dt><a name="ref-rdf-vocabulary" id="ref-rdf-vocabulary"></a>[RDF
Vocabulary]</dt>
<dd><i><a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210/">RDF
Vocabulary
Description Language 1.0: RDF Schema</a></i>, Dan Brickley and R. V.
Guha,
Editors, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/
. <a href="http://www.w3.org/TR/rdf-schema/">Latest version</a>
available
at http://www.w3.org/TR/rdf-schema/ .</dd>
</dl>
<hr>
<h3><a name="acknowledgements"></a>Acknowledgements</h3>
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, Bernard Vatant. Atanas Kiryakov, Peter Mika, and York Sure have also contributed
to the document.
<p>This document is a product of the Ontology Engineering and Patterns Task Force
of the Semantic Web Best Practices and Deployment Working Group.</p>
<hr>
<p>
<a href="http://validator.w3.org/check?uri=referer"><img border="0"
src="http://www.w3.org/Icons/valid-html401"
alt="Valid HTML 4.01!" height="31" width="88"></a>
<a href="http://jigsaw.w3.org/css-validator/">
<img style="border:0;width:88px;height:31px"
src="http://jigsaw.w3.org/css-validator/images/vcss"
alt="Valid CSS!">
</a>
</p>
</body>
</html>
|