Natasha Noy, Stanford
University
Last revised: May 3d, 2004
[Note: 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]
Comments, suggestions and modifications suggested by Pat Hayes shown in yellow. Comments are in monospace type, suggested modifications to text in normal font. Comments written May 14 2004
When and how to use classes as values for properties? Why only values? Why not as having properties applied to them i.e. more generally as individuals? What are advantages and drawbacks? What are different approaches and workarounds? Which solutions are in OWL DL (and hence OWL Lite) and which solutions are in OWL Full but not in OWL DL require us to move outside OWL DL?
Suppose we have a set of books about animals and want to annotate each book with its subject, which is a particular species class? That is, does it have to be a species? of animal (or animals) that it talks about. This emphasis on books is unfortunate since it gets the issue mixed up with issues of symbol vs. symbolised, class vs. concept, etc.. Further, we want to be able to say 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 described the animal species of Lions, and the second describes a species of African Lion. However, we also want to retrieve the second book when a query is about Lions, not just African Lions.
We consider animals classes of animals? to
be subjects of the books and would like to use the Dublin Core property
dc:subject
for this annotation.
This issue arises in general when we have a hierarchy of concepts and would like to use it as a terminology to annotate other classes or individuals. Terminology?? This reads oddly to me, and seems on a tangent. The classes as individuals issue arises in many cases which have nothing particularly to do with terminology. Consider using a hierarchy of different genre genres? to annotate music CDs, or linking classes or individuals in an ontology to the corresponding concepts in a standard reference terminology (e.g., UMLS is such standard reference terminology for many medical applications).
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.
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 BookAboutAnimals
of all books
about animals. Suggest omit this as it plays no role
in the example. For simplicity, we omit classes for other animals, such
as mammals and felines.
Here is a definition of an individual (a specific book that we are annotating)
that is an instance of the BookAboutAnimals
class with the corresponding subject (for simplicity, we assume that
each book discusses only one class of animals):
:LionsLifeInThePrideBook
a :BookAboutAnimals ;
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life in the Pride" ;
dc:subject :Lion .
The book "The African Lion" will be represented as:
:TheAfricanLionBookAnd the class
a :BookAboutAnimals ;
rdfs:seeAlso <http://isbn.nu/089686328X> ;
:bookTitle "The African Lion" ;
dc:subject :AfricanLion .
AfricanLion
is a subclass of the class Lion
:
:AfricanLion
a owl:Class;
rdfs:subClassOf :Lion .
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
. And also, for example, that
if Joe is an African Lion then Joe is one of the things that the book is about.
dc:subject
property for the BookAboutAnimals
class to the class Animal
and its subclasses, we will need to create another class
(a metaclass) of classes that will have
the class Animal
and its subclasses as instances:
AnimalClass
is a class, which is a subclass of
owl:Class
(In OWL, any Any
class that has other classes as instances must be a subclass of owl:Class
)
You could add that this also goes outside the
DL case, and also that in RDFS it is not required to be an rdfs:subClassOf
owl:Class; this is an artifact of the special OWL extensional semantic
conditions. Or just add the qualification suggested. . :AnimalClass
a owl:Class ;
rdfs:subClassOf owl:Class .
Lion
(and other subclasses of the Animal
class) have AnimalClass
as its type::Lion
a :AnimalClass ;
rdfs:subClassOf :Animal .
BookAboutAnimals
has AnimalClass
as an allValuesFrom
1 range
restriction for the dc:subject
property::BookAboutAnimals
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:allValuesFrom :AnimalClass ;
owl:onProperty dc:subject
] .
[N3] [RDF/XML abbrev] [Abstract syntax]
dc:subject
values or do not care that you need to also use classes as
subjects in order have subjects as instances of
a subclass of owl:Class
to implement this restriction.
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. Thus, we will have, for example, an individual LionSubject
that will be an instance of the Lion
class.
Why did you use rdf:type as the link? On the face of it, that seems clearly broken, and does not seem necessary. There is a perfectly rational approach which would be like this but using a different property to connect to the classes, say 'ex:referenceClass', thereby avoiding the need to include the subject in the class (and making a clear distinction between this case and your case 4, which currently there is no distinction as far as I can see.) Of course this would not be in DL, but it still makes perfect sense as an option in Full.
As this would help to make clear, many of the problems arise because in DL, the ONLY property that can have a class as a value is rdf:type. (It might be worth saying this explicitly somewhere.) If this restriction is lifted, many options are opened up.
Suggestion: make this modification to this example, and say clearly what the merits of it are but that it is not in DL. Then treat your example 4 as being what you get when you 'squeeze' this style into DL, and so force the subjects to be actual lions. That has the merit of making the disticntion clear and also showing clearly the reason for having to introduce "prototypical lions".
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 :BookAboutAnimals ;
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life in the Pride" ;
dc:subject :LionSubject .
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 serve as type for lions
at the zoo. This is wrong. It is not INCONSISTENT
with this interpretation: it merely creates a somewhat unusual instance of
the class. One could have a class of lions which included imaginary lions
(such as the hero of a CSLewis novel) and also an 'archetypical lion', which
corresponds to a common NL usage where a class is singularized by a prototype,
as in "The African lion is a magnificent beast". No inconsistency
here, just a need to be a little careful when selecting from the class.Still,
it might be good to give a warning, eg by coninuing with the wording: would
create a class containing a mixture or real lions and imaginary or virtual
lions. LionSubject
individual defined above and, for example, a AfricanLionSubject
individual, which is an instance of AfricanLion
::AfricanLionSubjectAn 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 individuals. A general-purpose reasoner will not be able to use this information directly. Note however that the individual
a :AfricanLion .
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
.dc:subject
property for the class BookAboutAnimals
is straightforward. We
define an allValuesFrom
1 restriction
that states that all values of the dc:subject
property are instances
of the class Animal
::BookAboutAnimals
a owl:Class ;
rdfs:subClassOf
[ a owl:Restriction ;
owl:allValuesFrom :Animal ;
owl:onProperty dc:subject
] .
[N3] [RDF/XML abbrev] [Abstract syntax]
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. You need to maintain consistency between the set of classes representing subjects and the set of corresponding individuals. If the subject hierarchy is not solely a terminology (e.g., you need to represent specific animals), you will need to create a separate class hierarchy for that.
rdfs:subclassOf
to organize the subject hierarchyThere is something weird about this, since it makes no reference to classes as values at all. So why are you even talking about it?
I'd suggest making this the last 'appraoch', almost as an afterthought, along the lines of :of course, you can just ignore the class heirarchy altogether and describe your own heirarchy. That is ALWAYS an option, after all, and it is one very reliable strategy for staying in the DL space, at an obvious cost.
We can create a single class Subject
and make all the subjects
to be individuals that are instances of this class Subject
:
:LionSubject
a :Subject ;
:parentSubject :AnimalSubject .
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 ;
:parentSubject :LionSubject .
AnimalSubject
is a parentSubject
of LionSubject
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:allValuesFrom :Subject ;
owl:onProperty dc:subject
] .
parentSubject
property—are consistent
with each other Why must they be consistent?[N3] [RDF/XML abbrev][Abstract syntax]
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."
This seems to me to be identical to # 2.
We can approximate the interpretation that we used in the previous
approaches by using unspecified members of a class rather than the class itself
as property values. We can define the class BookAboutAnimals
as
a class of books where the subject is some animal. Correspondingly,
a BookAboutLions
class will be a class of books where a subject
is some (unidentified) lion:
For example, we can define the class BookAboutLions
as follows:
: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" .
Alternatively, MyLionBook
can be defined as
:MyLionBookA DL classifier will be able to classify
a :Book; [ a owl:Restriction ;
owl:onProperty dc:subject ;
owl:someValuesFrom :Lion
]
MyLionBook
as an instance
of the class BookAboutLions
Lion
class -- rather than the Lion
class itself .
If you had meant the new individuals in #2 to be the classes, you should have
said so. That would be coherent in RDFS: the classes could belong to themselves.
We can consider this lion to be simply a prototypical representative of the
class.MyLionBook
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 BookAboutAninmals
(defined in
a similar way).someValuesFrom
drugX
restriction for each disease will be more natural and will
not incur a maintenance penalty. In the example of books and subjects however,
the hierarchy of books with specific subjects defined through someValuesFrom
restrictions is essentially parallel to the hierarchy of subjects (animals,
in this case) itself. This paragraph reads rather
confusingly (to me). Why were these techniques using a restriction not available
in the previous cases?[N3] [RDF/XML abbrev][Abstract syntax]
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.
This is not an 'approach'; it is a refusal to solve the problem. Another way to stay in OWL DL is to use classes as values for annotation properties:
dc:subject
a owl:AnnotationProperty .
:LionsLifeInThePrideBook
a :BookAboutAnimals ;
rdfs:seeAlso <http://isbn.nu/0736809643> ;
:bookTitle "Lions: Life In The Pride" ;
dc:subject :Lion .
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.BookAboutAnimals
must all
be subclasses of the Animal
class.[N3] [RDF/XML abbrev] [Abstract syntax]
This approach allows you to use classes directly as property values while staying in OWL DL. No, it doesn't in any real sense. 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.
[1] Using allValuesFrom
restriction for the
book's subject implies that instances of the class BookAboutAnimals
can
have only animals as values for the dc:subject
property. If we
want to allow other terms to be listed as subjects, a someValuesFrom
restriction will be appropriate.