Using Classes As Property Values (version 2)

General issue

When and how to use classes as values for properties? 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?

Use case example

Suppose we have a set of books about animals and want to annotate each book with its subject, which a particular animal (or animals) that it talks about. Further, we want to be able to say that a book about lions is also a book about mammals (For example, when retrieving all books about mammals from a repository, we want books about lions to be included in the results). We consider animals to be subjects of the books and would like to use the Dublin Core property dc:subject for this annotation.

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

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 AnimalBook of all books about animals.

Here is a definition of an individual (a specific book that we are annotating) that is an instance of the AnimalBook class with the corresponding subject (for simplicity, we assume that each book discusses only one class of animals):

  <AnimalBook rdf:ID="LionBook">
    <dc:subject rdf:resource="#Lion"/>
  </AnimalBook>

where the class Lion is defined in the following way:

 <owl:Class rdf:ID="Lion">
    <rdfs:subClassOf>
      <owl:Class rdf:about="#Mammal"/>
    </rdfs:subClassOf>
  </owl:Class>

Considerations when choosing approach 1:

• The resulting ontology is in OWL Full, but not in OWL DL.
• 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 LionBook individual) is a subclass of Mammal.
• If we need to restrict the range of values for the dc:subject property for the AnimalBook class to the class Animal and its subclasses, we will need to create another class (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 (Any class that has other classes as instances must be a subclass of owl:Class)
    

    <owl:Class rdf:ID="AnimalClass">
        <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
    </owl:Class> 

  • The class Lion (and other subclasses of the Animal class) have AnimalClass as its type:
    

     <AnimalClass rdf:ID="Lion">
        <rdfs:subClassOf>
          <AnimalClass rdf:about="#Mammal"/>
        </rdfs:subClassOf>
      </AnimalClass>
          

  • The class AnimalBook has AnimalClass as an allValuesFrom¹ range restriction for the dc:subject property:
    

      <owl:Class rdf:ID="AnimalBook">
        <rdfs:subClassOf>
          <owl:Restriction>
            <owl:allValuesFrom rdf:resource="#AnimalClass"/>
            <owl:onProperty>
              <owl:ObjectProperty rdf:about="dc:subject"/>
            </owl:onProperty>
          </owl:Restriction>
        </rdfs:subClassOf>
      </owl:Class>
    	   

OWL code for approach 1

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

Summary for approach 1

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.

We can then use the LionSubject as the value of the property dc:subject for the LionBook individual:

  <Lion rdf:ID="LionSubject"/>

In this case, the definition of the LionBook refers to the LionSubject individual

 <AnimalBook rdf:ID="LionBook">
    <dc:subject rdf:resource="#LionSubject"/>
  </AnimalBook> 

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 MammalSubject individual, which is an instance of Mammal:
  

  <Mammal rdf:ID="MammalSubject"/>

  An application trying to utilize this relation (for example, to extract all books about lions when asked for books about mammals), 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 LionSubject is also an instance of the Mammal class. Therefore, if we ask for all books where dc:subject is an instance of the Mammal class we will get the books that are annotated with LionSubject.
• 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 AnimalBook is straightforward. We define an allValuesFrom¹ restriction that states that all values of the dc:subject property are instances of the class Animal:
  

      <owl:Class rdf:ID="AnimalBook">
      <rdfs:subClassOf>
        <owl:Restriction>
          <owl:allValuesFrom rdf:resource="#Animal"/>
          <owl:onProperty>
            <owl:ObjectProperty rdf:about="dc:subject"/>
          </owl:onProperty>
        </owl:Restriction>
      </rdfs:subClassOf>
    </owl:Class>
  

OWL code for approach 2

[RDF/XML abbrev] [N3] [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 mammal to books with a subject 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 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:

  <Subject rdf:ID="LionSubject"/>

We can then create explicit relations between different subjects, which will re-create the hierarchy for animals that we have in mind:

  <owl:TransitiveProperty rdf:ID="parentSubject">
    <rdfs:range rdf:resource="#Subject"/>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
    <rdfs:domain rdf:resource="#Subject"/>
  </owl:TransitiveProperty>

  <Subject rdf:ID="LionSubject">
     <parentSubject rdf:resource="#MammalSubject"/>
  </Subject>

Considerations when choosing Approach 3

• The resulting ontology is in 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
• The resulting hierarchy of subjects is not related to or dependent on the class hierarchy representing the same topics (in this case, animals).
• 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
• Defining a range restriction for the dc:subject property for the class AnimalBook is straightforward. We restrict the values of the dc:subject property to the instances of the class Subject:

      <owl:Class rdf:ID="AnimalBook">
      <rdfs:subClassOf>
        <owl:Restriction>
          <owl:allValuesFrom rdf:resource="#Subject"/>
          <owl:onProperty>
            <owl:ObjectProperty rdf:about="dc:subject"/>
          </owl:onProperty>
        </owl:Restriction>
      </rdfs:subClassOf>
    </owl:Class>

• There is a serious 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 and values for the parentSubject property—are consistent with each other

OWL code for approach 3

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

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 classes as values for annotation properties

Another way to stay in OWL DL is to use classes as values for annotation properties:

  <owl:AnnotationProperty rdf:about="&dc;subject"/> 

  <AnimalBook rdf:ID="LionBook">
    <dc:subject rdf:resource="#Lion"/>
  </AnimalBook>

Considerations when choosing Approach 4

• 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 AnimalBook 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 4

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

Summary of Approach 4

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.

Notes

[1] Using allValuesFrom restriction for the book's subject implies that instances of the class AnimalBook 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.