[ Team LiB ] Previous Section Next Section

12.6 Bits of Knowledge: More Complex OWL Constructs

The example in the last section that allowed us to define a more complex data type for a specific property begins to demonstrate the divergence between RDFS and OWL—this ability to attach more nuances of meaning to the data being modeled, beyond nuances defined in RDF. Rightfully so—the relational data model provides the structure necessary to build generic data types that can manage all data; complex business models such as SAP and PeopleSoft use the relational model as a base for more complex models representing more specific business models. The two layers of relational data are complementary rather than competitive, just as the two layers of RDF/RDFS and OWL are complimentary rather than competitive.

The OWL elements we'll cover in this section are:

  • owl:allValuesFrom

  • owl:cardinality

  • owl:complementOf

  • owl:differentFrom

  • owl:disjointWith

  • owl:FunctionalProperty

  • owl:hasValue

  • owl:intersectionOf

  • owl:InverseFunctionalProperty

  • owl:inverseOf

  • owl:maxCardinality

  • owl:minCardinality

  • owl:ObjectRestriction

  • owl:oneOf

  • owl:onProperty

  • owl:Restriction

  • owl:someValuesFrom

  • owl:SymmetricProperty

  • owl:TransitiveProperty

  • owl:unionOf

The element names themselves indicate their functional value within OWL.

12.6.1 Increasing the Power of the Property

A property in RDF provides information about the entity it's describing, but the information tends to be somewhat linear. There are two types of information properties in an RDF record: an actual instance of data, such as a string containing a name or another resource, continuing the node-arc-node-arc-node path within the model.

In ontologies, properties can be much more active in their description of the knowledge described in the ontology with the aid of some enhancements built directly into the ontology language. OWL categorizes these property enhancements into characteristics and restrictions.

12.6.1.1 Property characteristics

Property characteristics increase our ability to record our understanding about the data we're describing in such a way that automated tools can infer much more of the reasoning we used when we pulled all this data together. In any model, there's a reason why we included this property or that entity, and not all of these reasons can be determined with the constructs supported in RDF or even with other data models such as the relational or object-oriented models.

To demonstrate the property characteristics, some new assumptions and additions to the existing PostCon ontology are made. In the current understanding of PostCon, a resource within the system would also exist as one resource on the server. However, there's nothing in the system that enforces this—a single web resource doesn't have to exist in one physical entity. For instance, an "article" such as the one used throughout the book, "Tale of Two Monsters: Legends" could be separated across many pages, but still be treated as a single entity within the system. To capture this information, a new property, partOf, can be defined and used as follows within the PostCon ontology: 

<Resource rdf:ID="Section1">
  <partOf rdf:resource="#monsters1" />
</Resource>
<Resource rdf:ID="monsters1">
</Resource>

With the new property, sections of an article can be split into further sections and so on, with each child section attached to the parent section through partOf.

This is an effective way to manage larger resources, but one thing lost with this structure is the fact that all of the sections ultimately roll up into one document, with each child section rolling up into the parent section, which may then roll up into another section and so on. However, OWL property characteristics provide a way to capture this type of information.

One property characteristic is the TransitiveProperty. The logic associated with this property is: 

P(x,y) and P(y,z) implies P(x,z)

Using TransitiveProperty in PostCon would result in something similar to the following: 

<owl:ObjectProperty rdf:ID="partOf">
  <rdf:type rdf:resource="owl:TransitiveProperty" />
  <rdfs:domain rdf:resource="&owl;Thing" />
  <rdfs:range rdf:resource="#Resource" />
</owl:ObjectProperty>

<Resource rdf:ID="sectionHeader1a">
  <partOf rdf:resource="sectionHeader1" />
</Resource>

<Region rdf:ID="sectionHeader1">
  <partOf rdf:resource="#monsters1" />
</Region>

The TransitiveProperty characteristic is attached to the property partOf. This property is used to attach the "sectionHeader1a" section to the parent section, "sectionHeader1". When the parent section is then attached to the main article, "monsters1", by the use of TransitiveProperty, the "sectionHeader1a" is also defined to be "part of" the top-level document. No special processing or understanding of the domain would be necessary to intuit this information because it's provided with the characteristic.

A second property characteristic is the SymmetricProperty. The logic for it is: 

P(x,y) iff P(y,x)

With the new PostCon property, sections can be marked as peers to each other through the use of SymmetricProperty applied to a new predicate, sectionPeer: 

<owl:ObjectProperty rdf:ID="sectionPeer">
  <rdf:type rdf:resource="&owl;SymmetricProperty" />
  <rdfs:domain rdf:resource="#Resource" />
  <rdfs:range rdf:resource="#Resource" />
</owl:ObjectProperty>

<Resource rdf:ID="sectionHeader1a">
  <partOf rdf:resource="#sectionHeader1" />
  <sectionPeer rdf:resource="#sectionHeader1b" />
</Resource>

<Resource rdf:ID="sectionHeader1b">
  <partOf rdf:resource="#sectionHeader1" />
  <sectionPeer rdf:resource="#sectionHeader1a" />
</Resource>

A third property characteristic is FunctionalProperty, with the logic: 

P(x,y) and P(x,z) implies y = z

Earlier in the section on data types, we created a custom data type, MovementType, to specify that allowable values be within a given set. The data type was attached to a specific property, movementType, which then became functional (noted by FunctionalProperty) in that all movement types can be assigned only one value, and the value must be from the allowable types: 

<owl:Class rdf:ID="MovementType" />

<owl:ObjectProperty rdf:ID="movementType">
   <rdf:type rdf:resource="&owl;FunctionalProperty" />
   <rdfs:domain rdf:resource="#ResourceMovement" />
   <rdf:range rdf:resource="#MovementType" />
</owl:ObjectProperty>

The inverseOf characteristic is pretty straightforward: a new property can be defined as the inverse of an existing property. The logic for it is: 

P1(x,y) iff P2(y,x)

If partOf shows a child section's relationship to a parent section, then the property hasChild would define a parent section's relationship to one of its children: 

<owl:ObjectProperty rdf:ID="hasChild">
  <owl:inverseOf rdf:resource="#partOf" />
</owl:ObjectProperty>

Finally, the last property characteristic is InverseFunctionalProperty, which combines the logic of both the inverse and the FunctionalProperty: 

P(y,x) and P(z,x) implies y = z

We can consider partOf as functional (as defined by FunctionalProperty), because a section is part of another section, and that other section only (a functional constraint). And if partOf is functional, then the inverse functional equivalent of partOf would be the hasChild property: 

<owl:ObjectProperty rdf:ID="partOf">
  <rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>
  
<owl:ObjectProperty rdf:ID="childOf">
  <rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
  <owl:inverseOf rdf:resource="#partOf" />
</owl:ObjectProperty>

Properties can be further refined through restrictions, discussed next.

12.6.1.2 Property restrictions

If property characteristics enhance reasoning by extending the meaning behind element relationships with each other, than property restrictions fine-tune the reasoning by restricting properties within specific contexts.

Returning to PostCon, the Resource class has two subclasses, ResourceMovement and RelatedResource: 

<owl:Class rdf:ID="Resource" />
<owl:Class rdf:ID="RelatedResource">
   <owl:subClassOf rdf:resource="#Resource" />
</owl:Class>
<owl:Class rdf:ID="ResourceMovement">
   <owl:subClassOf rdf:resource="#Resource" />
</owl:Class>

In the RDF Schema for PostCon, both of these classes would have "reason" as a predicate, explaining the association between the classes. In addition, ResourceMovement also has movementType.

Instead of having two different properties, we could have just the one — reason — and then attach a property restriction — allValuesFrom — to it, restricting values for this property to MovementType values only. The use of this restriction is demonstrated in the following code: 

<owl:Class rdf:ID="ResourceMovement">
   <owl:subClassOf rdf:resource="#Resource" />
   <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#reason" />
      <owl:allValuesFrom rdf:resource="#MovementType" />
    </owl:Restriction>
   </rdfs:subClassOf>
</owl:Class>

Restrictions differ from characteristics in that restrictions apply to a sub-set of the data, rather than globally to all data. In this use of allValuesFrom, the restriction applies to the reason property only when it's used within the ResourceMovement class, not when its used in the RelatedResource class.

A less restricted version of allValuesFrom is someValuesFrom, used to specify that at least one of the properties restricted, in this case reason, must point to a specific MovementType.

Another restriction is cardinality. Cardinality indicates the exact number of individual instances of a property allowed within a class — not the maximum or minimum number, but the exact number that must exist.

Returning to PostCon, each individual ResourceMovement can have one and only one movementType property. This restriction would be modeled in OWL with the following: 

<owl:Class rdf:ID="ResourceMovement"> 
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#movementType"/>  
      <owl:cardinality>1</owl:cardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

According to the OWL Guide, OWL Lite can specify values of only 0 or 1 for the cardinality restriction. However, for OWL Full, in addition to the use of the cardinality restriction, owl:maxCardinality can be used to set an upper cardinality, while owl:minCardinality can be used to set the lower. Setting both defines a range.

The last property restriction is hasValue, used with a class to differentiate those with properties from a specific range. Again returning to ResourceMovement, the use of hasValue could be used to differentiate ResourceMovement from RelatedResource, by adding the restriction that ResourceMovement classes have a movementType pointing to the MovementType class: 

<owl:Class rdf:ID="ResourceMovement"> 
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#movementType"/>  
      <owl:hasValue rdf:resource="#MovementType" />
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

The more uses of property characteristics and restrictions placed on objects in the ontology, the better able tools are to make strong inferences about the true meaning of the data being defined.

12.6.2 Complex Classes

More complex class relationships exist than just the simple hierarchy defined through the use of subClassOf. These relationships are managed through a set of properties that controls how one class relates to another. These class expressions, as OWL defines them, are based on typical set operations used elsewhere, such as in logic or math. All classes constructed using set operations, such as intersectionOf, are closed, explicitly stating the parameters of class membership for a specific class.

12.6.2.1 Intersection

An intersection of a class and one or more properties is created using the intersectionOf property. All members of a class defined with intersectionOf are explicitly defined by the intersection of the class membership and the property or properties specified.

One change that could be made to PostCon is to differentiate between types of resources, based on the assumption that different types of resources have different information associated with them. If we do classify resources in this manner, then we'll also want to explicitly state without equivocation which class each resource would belong in. In the following OWL definition, the new resource class, XMLResource, is restricted to members that belong to the Resource class and also belong to all things that are based on XML: 

<owl:Class rdf:ID="XMLResource">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Resource" />
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasFormat" />
      <owl:hasValue rdf:resource="#XML" />
    </owl:Restriction>
  </owl:intersectionOf>
</owl:Class>

The XMLResource class consists of a class defining a set of properties, all of which can be used to describe something formatted as XML. The intersection would then be "Resource" and "things formatted as XML." The Collection parseType is a required attribute in the class definition because the class is being constructed to define a collection of like material.

Rather than base the intersection on a specific property, you can also just specify an intersection of classes. In the following, a new class, RSSXMLResource, is defined as the intersection between XMLResource and another new complex class, RSSResource: 

<owl:Class rdf:ID="RSSXMLResource">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#XMLResource" />
    <owl:Class rdf:about="#RSSResource" />
  </owl:intersectionOf> 
</owl:Class>

Members of RSSXMLResource would be resources formatted as XML but based on some RSS vocabulary; RSS documents that are not XML formatted wouldn't be included, and neither would XML documents that aren't based on RSS. RSS 1.0 (RDF/RSS) would be a member of this class.

12.6.2.2 Union

The unionOf construct creates a class whose members combine the properties of both classes being joined. A demonstration of this is the following, which defines a new class, called WebpageResource. This combines the properties of XMLResource and a new class, HTMLResource: 

<owl:Class rdf:ID="WebpageResource">
  <owl:unionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#XMLResource" />
    <owl:Class rdf:about="#HTMLResouce" />
  </owl:unionOf>
</owl:Class>

XML, XHTML, and HTML pages would all be members of this class.

As the guide notes, defining a class to be a subclass of two classes results in an intersection of the two classes. With XMLResource and HTMLResource, this would be an empty class because HTML, by its nature, is not an XML document.

12.6.2.3 Complement

A class that consists of all members of a specific domain that do not belong to a specific class can be created using the complementOf construct. Continuing our classification of PostCon resources, all web resources that aren't HTML, XML, or XHTML can be lumped into one class membership using a class definition like the following: 

<owl:Class rdf:ID="WebResource" />
  <owl:Class rdf:ID="NotWebPage">
    <owl:complementOf rdf:resource="#WebpageResource" />
  </owl:Class>

According to the OWL documentation, complementOf is usually used with other set operations. With PostCon, this increasingly complex construct could be used to define a class that contains all members of resources that are not XML-formatted RSS with the following definition: 

<owl:Class rdf:ID="NotRSSXMLResource">
  <owl:intersectionOf rdf:parseType="Collection">
    <owl:Class rdf:about="#Resource"/>
    <owl:Class>
      <owl:complementOf>
        <owl:Class rdf:ID="RSSXMLResource">
          <owl:intersectionOf rdf:parseType="Collection">
            <owl:Class rdf:about="#XMLResource" />
            <owl:Class rdf:about="#RSSResource" />
          </owl:intersectionOf> 
         </owl:Class>
      </owl:complementOf>
    </owl:Class>
  </owl:intersectionOf>
</owl:Class>

If a circle were drawn around XML-formatted RSS files, everything outside of this circle that is a Resource would belong to NotRSSXMLResource.

12.6.2.4 Enumeration

An enumeration is a class with a predetermined, closed set of members. Applied to web resources, this could be an enumeration of graphics types supported at a particular web site, as shown in the following, using the OWL enumeration operator, oneOf: 

<owl:Class rdf:ID="GraphicResource">
  <rdfs:subClassOf rdf:resource="#Resource"/>
  <owl:oneOf rdf:parseType="Collection">
    <owl:Thing rdf:about="#JPEG"/>
    <owl:Thing rdf:about="#PNG"/>
    <owl:Thing rdf:about="#GIF"/>
  </owl:oneOf>
</owl:Class>

The list could, of course, be extended to include other graphics types. A member of an enumerated class belongs to one, and only one, of the collection members.

12.6.2.5 Disjoint

Finally, the last complex class construction is the disjoint construct, which lists all of the classes that a particular class is guaranteed not to be a member of. As an example, the following defines a new class, TextFile, guaranteed not to be a member of the GraphicResource and VideoResource classes: 

<owl:Class rdf:ID="TextFile">
  <rdfs:subClassOf rdf:resource="#Resource"/>
  <owl:disjointWith rdf:resource="#GraphicResource"/>
  <owl:disjointWith rdf:resource="#VideoResource"/>
</owl:Class>
    [ Team LiB ] Previous Section Next Section