The lack of support for numeric ranges such as "age > 18" is arguably the most frequently mentioned show stopper for (potential) OWL users. While OWL has cardinality restrictions, allowing you to state that a property has a certain number of values, you cannot further restrict datatype values. One of the main reasons why this feature hasn't made it into the OWL specification is that the language designers hope to reuse the mechanisms for user-defined datatypes in the XML Schema specification. These user-defined datatypes can, among others, restrict the range of numeric types by minimum and maximum values, and to specify the length of string values. Here is an example XML Schema datatype declaration, defining the type int >= 18:

    <simpleType name='adultAge'>
      <restriction base='int'>
        <minInclusive value='18'/>
      </restriction>
    </simpleType>

The XML Schema specification defines a collection of so-called facets, such as minInclusive, which can be used to restrict a base datatype. The idea for the OWL community is that such XML Schema declarations can be used in conjunction with rdfs:range statements or qualified restrictions on a datatype property. For example, you could define a class AdultPerson using a code similar to:

    <owl:Class rdf:ID="Person"/>
    <owl:Class rdf:ID="AdultPerson">
      <rdfs:subClassOf rdf:resource="#Person"/>
      <rdfs:subClassOf>
        <owl:Restriction>
          <owl:onProperty rdf:resource="#hasAge"/>
          <owl:allValuesFrom rdf:resource="adultAge"/>  <!-- How??? -->
        </owl:Restriction>
      </rdfs:subClassOf>
    </owl:Class>

    <owl:DatatypeProperty rdf:ID="hasAge">
        <rdf:type rdf:resource="&owl;FunctionalProperty"/>
        <rdfs:domain rdf:resource="#Person"/>
        <rdfs:range rdf:resource="&xsd;int"/>
    </owl:DatatypeProperty>

Unfortunately the above does not work easily, because adultAge is not a valid URI inside the OWL file. The XML Schema blocks are not in RDF format, and therefore cannot easily be integrated. There is an ongoing discussion on how to best integrate the XML Schema types into an OWL ontology. A draft outlining options has been made available recently, but no decision has been made on how to proceed with the standardization efforts. Any solution in the current draft seems to point at a solution in which OWL files can be extended with URI references into an (external) XML Schema file. This means that people will have to maintain a separate XML Schema file together with the OWL file. Our experience with the problems that user have with the imports mechanism indicates that having to work with two files is not the best option.

Since there is no standard on this yet and since the solution with two files does not look promising, we are experimenting with an alternative representation mechanism for user-defined XML Schema datatypes in OWL (or RDF Schema). For that purpose we have defined a small extension ontology xsp.owl, which defines RDF properties (currently annotation properties) that can be used to represent XML Schema facets. This extension ontology can be imported and should get the prefix xsp (p for Protege). As of the first 3.2 beta, Protege users will get it automatically when they import the Protege metadata ontology. Once imported, user-defined datatypes can at least be embedded into the same file, and used consistently:

    <rdfs:Datatype rdf:ID="adultAge">
      <xsp:base rdf:resource="&xsd;int"/>
      <xsp:minInclusive rdf:datatype="&xsd;int">18</xsp:minInclusive>
    </rdfs:Datatype>

Such named datatypes can then be used in range restrictions and shared between properties. However, in many cases it would be more convenient to simply define such types on-the-fly as anonymous resources. An example would look like:

    <owl:Class rdf:ID="AdultPerson">
      <rdfs:subClassOf rdf:resource="#Person"/>
      <rdfs:subClassOf>
        <owl:Restriction>
          <owl:onProperty>
            <owl:DatatypeProperty rdf:ID="hasAge"/>
          </owl:onProperty>
          <owl:allValuesFrom>
            <rdfs:Datatype>
              <xsp:base rdf:resource="&xsd;int"/>
              <xsp:minInclusive rdf:datatype="&xsd;int">18</xsp:minInclusive>
            </rdfs:Datatype>
          </owl:allValuesFrom>
        </owl:Restriction>
      </rdfs:subClassOf>
    </owl:Class>

An example for a range definition is

    <owl:DatatypeProperty rdf:ID="hasBodyTemperature">
      <rdfs:range>
        <rdfs:Datatype>
          <xsp:base rdf:resource="&xsd;float"/>
          <xsp:minInclusive rdf:datatype="&xsd;float">34.0</xsp:minInclusive>
          <xsp:maxInclusive rdf:datatype="&xsd;float">43.0</xsp:maxInclusive>
        </rdfs:Datatype>
      </rdfs:range>
    </owl:DatatypeProperty>

Both examples have been created with Protege. The user interface for defining such ranges looks like the following screenshot. Note that the rather ugly range interval syntax is used to allow to distinguish between open and closed intervals. Open intervals (xxxExclusive) are represented by round braces, while closed intervals (xxxInclusive) are displayed as shown.

Additional facets are available to constrain string datatypes. The following example uses the pattern facet of XML Schema to express a regular expression for US zip codes:

Resulting in the following OWL snippet:

   <owl:DatatypeProperty rdf:ID="hasZipCode">
     <rdfs:range>
       <rdfs:Datatype>
         <xsp:base rdf:resource="&xsd;string"/>
         <xsp:pattern rdf:datatype="&xsd;string">[0-9]{5}(-[0-9]{4})?</xsp:pattern>
       </rdfs:Datatype>
     </rdfs:range>
   </owl:DatatypeProperty>

These constraining facets can be used to validate user input (a red border is shown as long as the entered value does not fulfill all restrictions. In the future, such information may also be used for reasoning.

The main problem of this approach is - of course - that it's not a standard solution. If files in the above format are given to tools that are not aware of these conventions, then the tools will not be able to make any sense of them. Therefore, Protege will provide an export facility to save these information in a "standard" format, whatever this will be in the future.

Author: Holger Knublauch (last updated: August 19th, 2005)