Representing Classes As Property Values on the Semantic Web

W3C Working Draft 13 January 2005

This version:: ...
Latest version:: ...
Previous versions:: This is the second public version
Editor:: Natasha Noy, Stanford University, Stanford, US
Contributors:: See Acknowledgements.

Abstract

This document addresses the issue of using classes as property values in OWL. 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. In OWL DL and OWL Lite, most properties cannot have classes as their values. The document examines different approaches to representing this ontological pattern in OWL DL and discusses considerations that the users should keep in mind when choosing one of the approaches.

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 compaible 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]

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 want to annotate each book with its subject, which a particular species or class of animal (or animals) that it talks 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 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 classes of animals to be subjects of the books and would like to use the Dublin Core property dc:subject for this annotation.

We discuss a number of approaches for representing this pattern in OWL DL and their implications.

One goal of the web publisher, however, is to enable maximum reuse of published information. Furthermore, it will be common on the Semantic Web to import and reuse other published ontologies. In doing so, it is important for web developers to preserve original semantics of imported resources. Therefore, an important consideration in choosing a representation pattern in this case is the following: If the pattern requires a different interpretation of classes to be used as values, does the designer "own" the definitions of these classes (in this case, the hierarchy of animals) to change them according to the new interpretation? Are others already using this hierarchy of animals in their applications and will this change affect those applications?

Other use case scenarios

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. Consider using a hierarchy of different 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).

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 annotation properties.

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.

Using classes directly as 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 class of animals):

: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.
We may want to define a class of all books about animals --BookAboutAnimals -- that our lion books will be instances of. If we need to restrict the range of values for the dc:subject property for the BookAboutAnimals class to the class Animal and its subclasses, we will need to create another class of classes (a metaclass) that will have the class Animal and its subclasses as instances:
- The class AnimalClass is a class, which is a subclass of owl:Class (In OWL, any class that has other classes as instances must be a subclass of owl:Class)
```
:AnimalClass
      a       owl:Class ;
      rdfs:subClassOf owl:Class .
```
- The class Lion (and other subclasses of the Animal class) have AnimalClass as its type:
```
:Lion
      a       :AnimalClass ;
      rdfs:subClassOf :Animal .
```
- The class BookAboutAnimals has AnimalClass as a someValuesFrom range restriction for the dc:subject property:
```
  :BookAboutAnimals
      a       owl:Class ;
      rdfs:subClassOf
              [ a       owl:Restriction ;
                owl:someValuesFrom :AnimalClass ;
                owl:onProperty dc:subject
              ] .
	   
```

OWL code for approach 1

[N3] [RDF/XML]

Summary for 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 subjects and a parallel set of subject 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. Thus, we will have, for example, an individual LionSubject that will be an instance of the Lion class.

Creating 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 serve as type for 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, a 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 individuals. 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
This approach explicitly separates the terminology from the ontology of corresponding concepts

Defining a range restriction for the dc:subject property for the class BookAboutAnimals is straightforward. We define an someValuesFrom 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: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:

 :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 .

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)
Most DL reasoners will be able to infer transitive relations between subjects, such as the fact that AnimalSubject is a parentSubject of LionSubject. 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 terminology from the ontology of corresponding concepts. 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.

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
              ] .

There is 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.

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

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 or lions:

using members of a class as values for the property

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, LionsLifeInThePrideBook can be defined as

: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 RDF Schema and OWL DL
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.
There can be a maintenance penalty if you do not need to create classes for books on various subjects anyway.You will either have to define anonymous types for the individuals or create a hierarchy of classes with corresponding subjects. In many cases however, the concepts or individuals that you need to annotate with subjects or other properties that may require classes as values, are independent of the hierarchy of the classes used for annotation. For instance, you can have a hierarchy of diseases and use one of the properties to describe drugs used to treat each disease. In this case, defining a 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.

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:

  dc:subject
      a       owl:AnnotationProperty .

using classes as values for annotation properties

: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."
Minor fixes throughout the document

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, and Bernard Vatant. 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.

Representing Classes As Property Values on the Semantic Web

W3C Working Draft 13 January 2005

Abstract

Status of this Document

General issue

Use case example

Other use case scenarios

Notations

Approaches

Approach 1: using classes directly as values

Considerations when choosing approach 1:

OWL code for approach 1

Summary for approach 1

Approach 2: Creating a hierarchy of subjects and a parallel set of subject individuals

Considerations when choosing approach 2:

OWL code for approach 2

Summary of approach 2

Approach 3: using a property other than rdfs:subClassOf to organize the subject hierarchy

Considerations when choosing Approach 3

OWL code for approach 3

Summary of Approach 3

Approach 4: using members of a class as values for the property

Considerations when choosing Approach 4

OWL code for approach 4

Summary of Approach 4

Approach 5: using classes as values for annotation properties

Considerations when choosing Approach 5

OWL code for approach 5

Summary of Approach 5

References

Changes from the previous version

Acknowledgements

Approach 3: using a property other than `rdfs:subClassOf` to organize the subject hierarchy