Representing Classes as Property Values on the Semantic Web

W3C Note 29 May 2004

This version:: ...
Latest version:: ...
Previous versions:: This is the first public version
Editor:: Natasha Noy, Stanford University

Abstract

This document addresses the issue of using classes as property values on the semantic web. Some semantic web languages, such as OWL Full and RDF Schema allow properties to have values that are classes, whereas the description logic subsets of these languages, OWL DL and OWL Lite do not generally allow this. This document proposes a design pattern that allows the natural expression of classes as values using the unrestricted languages and a simple transformation to a preferred equivalent expression supported by the description logic subsets. It also discusses other equivalent expressions support by description logic subsets.

Status of this Document

This version of this document is a draft attempt to illustrate the value of reframing the original document to broaded its scope from how to solve a problem in Owl DL to a recommendation on how to do something in the semantic web.

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 working draft and is expected to change.

We encourage public comments. Please send comments to public-swbp-wg@w3.org

Open issues, todo items:

The discussion of whether Approach 2 and Approach 4 are really different [1] [2]
The use of architecture diagrams to give examples of use cases [3]
The scope of the note to address more general use-case scenarios [4][5]
Contacting Dublin Core developers to verify the use of dc:subject (or changing the example not to include subjects) [6]

Publication as a draft 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.

Introduction

@@ As an experiment, I have switched the example from one that overlaps with the work of the thesaurus task force, to another that avoids general concerning the interpretation of dublic core. I have not worked through the implications in the examples developed by Natasha, but those should be pretty mechanical. Consider this as a suggested changed, which if found appealing can be readily deployed through the document. Note that I have chosen an example based on digital publishing involving printers. Whilst this was chosen from familiarity, it might be considered to be a parochial attempt at promotion of my employers wares. I am happy to substitute any other type of device, e.g. mobile phone or video production device, if this is considered to be a problem.

It is often useful to have properties whose values are classes. For example, consider an application implementing a digital publishing workflow. Jobs in the workflow are usually called tickets. The designer of such a system may need to indicate the class of printer that is suitable for a ticket. The obvious and natural approach is to define a property, say pub:printerType, that takes values that are classes of printer. A ticket might be represented thus:

@@this should be a picture but I don't have a MAC and the really nice graphics editor that Natasha has been using. Hence I'll show the RDF to illustrate what I mean.

  <pub:Ticket>
    <pub:printerType rdf:resource="&pub;SomePrinterClass"/>
    ...
  </pub:Ticket>

A problem arises however with this natural approach in that some of the semantic web languauges, the description logic subsets of OWL@@ref, OWL Lite@@ref and OWL DL@@ref, do not allow properties (other than rdf:type and its subproperities) to take values that are classes. Within a closed system, that is one under the control of a single design authority, this is not a problem, as 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.

One goal of the web publisher, however, is to enable maximum reuse of pubished information. She cannot know in advance what kind of reasoner will be applied to the information she publishes. Even within a closed system, the designer should have an eye on unforseeable future requirements. What is she to do?

To aid designers who simply want a recommended design pattern, we recommend that, in the general case, the natural representation be used. We show how this may be readily transformed into our recommended description logic compatible representation for processing by description logic reasoners. We also discuss a number of other description logic compatible representations that may be more appropriate in specific cases.

Use case example

We use the digital pubishing system mentioned above as our use case. We use the following simple ontology of printers. Various classes of device including Printer, MonochromePrinter, ColourPrinter, SingleSidedPrinter, DoubleSidedPrinter, MediumFormatPrinter, LargeFormatPrinter, LoVolumePrinter and HiVolumePrinter are predefined. Specific models of printer are defined as subclasses of these generic classes, so for example, BigPlotter is a subclass of ColourPrinter, LargeFormatPrinter and LoVolumePrinter, and BigRun is a subclass of ColourPrinter, DoubleSidedPrinter, MediumFormatPrinter and HiVolumePrinter. @@This should be a diagrem.

One of the critical operations of the publishing system will be to query the available information about tickets and printers, for example to find the waiting tickets for which a newly free printer is suitable. This will involve finding tickets for which the free printer is a member of the class indicated by the pub:printerType property of the ticket and will involve reasoning about subclass relationships.

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. @@suggest using elipses for individuals too, as that is consistent with normal rdf practice.

Approaches

Approach 1: the natural approach - using classes directly as values

This is our recommended approach. We use classes of printer as values for properties.

Using classes as values

Considerations when choosing approach 1:

This approach is the most succinct and intuitive among all the approaches proposed here. It is our recommended approach.
Applications using this representation can directly access the information needed to infer that PosterPrinter is a subclass of ColorPrinter. In practise this inference will normally be performed automatically by tools used by the application, so that for example, queries for tickets requiring a colour printer will find both Ticket1 and Ticket2.
This approach is compatible with RDF Schema and OWL Full, but not OWL DL. However, as can be seen in Approach 3@@ref, it can be easily transformed into a form that can be processed by a description logic reasoners.

OWL code for approach 1 @@needs updating

[N3] [RDF/XML abbrev] [Abstract syntax]

Summary for approach 1

This is our recommended approach in general. We show helow how ontologies and instance data can be extended where they need to be processed by description logic reasoners.

This is the original approach 3 that I have moved up in the document by not renumbered.

Approach 3: the recommended DL approach - using individuals as surrogates for classes

As we have said, Approach 1@@ref does not work in OWL DL and OWL Lite since they do not allow classes as property values. We solve this problem by creating an individual to act as a surrogate for each class in our ontology. Those individuals are then effectively used as the value of the pub:printerType property.

using surrogates for classes

Rather than using the pub:printerType property, we recommend the use of a different property, say pub:printerTypeSur when the value of the property is a class surrogate. A surrogate individual is related to its associated class by the annotation property bpd:surrogateFor, so that:

  _:t  pub:printerTypeSur _:ps .
  _:ps bpd:surrogateFor _:printerClass .

entails

  _:t  pub:printerType _:printerClass .

@@the above can be generalized and needs some more working out. Is surrogateFor inverse functional? Do we define the inverse bpd:hasClassSurrogate? Do we define a relationship between the properties taking classes as values and the properties taking surrogates as values. Can we get a general set of rules that can be built into rules systems so that tools can have built in support for the transformation. I have an uneasy feeling the math will go wrong, but that's just my natural pessimism.

Thus the use of classes as values directly and the use of surrogate individuals are equivalent and this entailment gives rules for transforming betwwen RDFS and DL compatible representations. @@not yet

To be equivalent, we must ensure that there is an equivalent of the subsumption reasoning found in the RDFS case. We define a transitive property bpd:subClassOfSur that relates surrogates exactly as rdfs:subPropertyOf relates classes, so that:


  _:c1 rdfs:subClassOf _:c2 .
  _c1s bpd:surrogateFor _:c1 .
  _c2s bpd:surrogateFor _:c2 .

entails

  _c1s bpd:subClassOfSur _c2s .

The resulting ontology is in OWL DL
Most DL reasoners will be able to infer transitive relations between subjects, such as the fact that BigRunSur is a bpd:subClassOfSur of HiVolumePrinter
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. However, the simple definition of a bpd:hasClassSurrogate property for classes with surrogates will enable automatic generation of the surrogate structure.

OWL code for approach 3

[N3] [RDF/XML abbrev][Abstract syntax]

Summary of Approach 3

This is our recommended approach where description logic compatibility is required. Ontologies and instance data can be automatically transformed between Approach 1@@ref and this approach.

No changes by BWM after this point

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 in 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.
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.)
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 abbrev] [Abstract syntax]

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

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 in OWL DL
The interpretation of this pattern is different from interpretations of the other patterns in this note: the subject of the book is a 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 abbrev][Abstract syntax]

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 abbrev] [Abstract syntax]

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/0098.html

[2]http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0111.html

[3]http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0138.html

[4]http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0105.html

[5]http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0124.html

[6]http://lists.w3.org/Archives/Public/public-swbp-wg/2004May/0113.html