Using Classes As Property Values

General issue

When and how to use classes as values for properties? What are advantages and drawbacks? What are different approachs and workarounds? Which solutions are in OWL DL (and hence OWL Lite) and which solutions are in OWL Full?

Use case example

Suppose we want to annotate animal images with the classes describing the animal species. We want to be able to say that an image of a Lion is also an image of a Mammal (For example, when retrieving all images of mammals from a repository, we want images of lions to be included in the results). We consider animals to be subjects of the images 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 book subjects to annotate books 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 AnimalImage of all images of animals. Here is a definition of an individual that is an instance of the AnimalImage class with the corresponding subject:

  <AnimalImage rdf:ID="LionImage">
 
<dc:subject rdf:resource="#Lion"/>
 
</Image>

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.
• 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 LionImage individual) is a subclass of Mammal.
• If we need to restrict the range of values for the dc:subject property for the AnimalImage 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 AnimalImage has AnimalClass as a range restriction for the dc:subject property:
    

      <owl:Class rdf:ID="AnimalImage">
     
    <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>
    	   

Summary for Approach 1

Approach 2: using individuals for subjects

One of the ways to avoid having the resulting ontology in OWL Full, is to create a set of individuals to represent the subjects. There are a couple of possible options.

1. We can 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 LionImage individual:

  <Lion rdf:ID="LionSubject"/>



2. Alternatively, we can create a single class Subject and make all the subjects to be individuals that are instances of this class Concept:
   
   

     <Concept rdf:ID="LionSubject"/>

   We can link these subjects to the classes in the hierarchy of Animal classes using rdf:isDefinedBy property:
   
   

   <Subject rdf:ID="LionSubject">
    
   <rdfs:isDefinedBy 
   rdf:resource="#Lion"/>
   </Subject>

   
   

In both cases, the definition of the LionImage refers to the LionSubject individual (which will have a different rdf:type depending on which option of the two above you choose)

 <AnimalImage rdf:ID="LionImage">
 
<dc:subject rdf:resource="#LionSubject"/>
 
</AnimalImage> 

Considerations when choosing approach 2:

• The resulting ontology is in OWL DL
• 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"/>

  (or rdfs:isDefinedBy Mammal:
  

  <Subject rdf:ID="MammalSubject">
   
  <rdfs:isDefinedBy 
  rdf:resource="#Mammal"/>
  </Subject>

  )
  An application trying to utilize this relation (for example, to extract all images of lions when asked about images of mammals), will need to be aware of this specific approach and know to trace back to the corresponding classes, their subclasses, and respective individuals or to look at rdfs:isDefinedBy definitions. A general-purpose reasoner will not be able to use this information directly. Note however that with option 1, the individual LionSubject is also an instance of the Mammal class. Therefore, if we ask for all images where dc:subject is an instance of the Mammal class we will get the images that are annotated with LionSubject.
• In the first option above, 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. Similarly, even with the second option, creating an individual LionIndividual representing a specific lion at the zoo as an instance of the Lion class, will be inconsistent with most interpretations of rdfs:isDefinedBy.
• 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 AnimalImage is straightforward. For the first option, we define a restriction that states that all values of the dc:subject property are instances of the class Animal:
  

      <owl:Class rdf:ID="AnimalImage">
   
  <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>
  	

  For the second option, we restrict the values of the dc:subject property to the instances of the class Subject:

      <owl:Class rdf:ID="AnimalImage">
   
  <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>
  	

Summary of Approach 2

Both options for this approach are in OWL DL and may be good ones 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 images of mammals to images of lions, for example. 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 take the second option in Approach 2, and take it one step further, creating 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 this approach

• 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 directly 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
• 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

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"/>

   <AnimalImage rdf:ID="LionImage">
 
<dc:subject rdf:resource="#Lion"/>
 
</AnimalImage>

Considerations when choosing this approach

• 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 image should have at least one subject for example or that individuals that are instances of AnimalImage 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 an image of a lion when queried for animal images, one would need to use special-purpose reasoning that uses annotation properties and can perform reasoning with them.

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.