Enhancing Data Interoperability with Ontologies, Canonical Forms, and Include Files

Executive Summary

1. Declaratively expressing relationships between entities is good. Relationship information can be used to enhance application interoperability.
2. RDF Schema (RDFS) and OWL are ontology languages designed for declaratively expressing relationships
3. There are many important relationships that cannot be captured by RDFS or OWL. Namely, relationships which involve transformation between entities. Here are some examples:
   1. Length: A physical length can be expressed in many different forms - as miles, kilometers, furlongs, etc. Relating one form to another requires a transformation. For example, a distance expressed in miles is related to a distance expressed in kilometers by this transformation: kilometer = mile * 1.609344
   2. Location: A location can be expressed in may different forms - as cartesian coordinates, polar coordinates, etc. Relating one form to another requires a transformation.
   3. Speed: A physical speed can be expressed in many different forms - as miles per hour, meters per second, etc. Relating one form to another requires a transformation.
   4. Rate of Fuel Consumption: The rate at which an object consumes fuel can be expressed in many different forms - as miles per gallon, kilometers per liter, etc. Relating one form to another requires a transformation.
4. Interoperability will be further enhanced if we can find a good approach for expressing these important transformation relationships.
5. The approach proposed in this paper is:
   1. With an ontology language (OWL) declaratively express the canonical form. For example, here are the canonical forms of the above:
      1. Length: The canonical form of a physical length is a value with Meter units.
      2. Location: The canonical form of a location is a value in cartesian coordinates.
      3. Speed: The canonical form of a speed is a value with Meters/Second units.
      4. Rate of Fuel Consumption: The canonical form of a rate of fuel consumption is a value with Meters/Liter units.
   2. As well as declaratively expressing the canonical form, the ontology also identifies the location of an include file.
   3. With a programming language create an include file that codes the transformation from non-canonical forms to the canonical form.
   4. Applications use the ontology and include file as follows:
      1. Applications include the include file.
      2. Applications receiving data that is not in canonical form invokes a function in the include file. The function returns the data in canonical form. The application processes the canonical form.
         • Applications are required to understand only one form - the canonical form. (They may understand other forms, but are not required.)
         • Applications can interoperate with trading partners regardless of the form their data is expressed in!

Enhancing Interoperability with Ontologies

• SLR (Single Lens Reflex) is a type of Camera

• focal-length is synonymous with aperture

Lesson Learned: Declaratively expressing relationships is good! It helps applications dynamically understand data. Interoperability is enhanced.

Corollary: Ontologies are languages intended for declaratively expressing relationships. Ontologies are good! They promote interoperability. Use ontologies!

Ontologies can't State Relationships which Involve Transformations

Example 1: Same Length, Different Units

    <River id="Yangtze">
        <length units="kilometer">6300</length>
    </River>

    <River id="Yangtze">
        <length units="mile">3914</length>
    </River>

    kilometer = mile * 1.609344

Example 2: Same Location, Different Coordinate Systems

    <Map id="M1">
        <location>
            <cartesian-coordinate>
                <x units="kilometer">100</x>
                <y units="kilometer">100</y>
            </cartesian-coordinate>
        </location>
    </Map>

    <Map id="M2">
        <location>
            <polar-coordinate> 
                <r units="kilometer">141.421</x>
                <theta units="radian">0.7341</theta>
            </polar-coordinate>
        </location>
    </Map>

    x = r cos theta
    y = r sin theta

Example 3: Same Speed, Different Units

    <Comet id="Hale-Bopp">
        <avg-speed units="miles-per-hour">93951.3</avg-speed>
    </Comet>

    <Comet id="Hale-Bopp">
        <avg-speed units="kilometers-per-second">42.0</avg-speed>
    </Comet>

    miles-per-hour = kilometers-per-sec * 3600 / 1.609344

Example 4: Same Rate of Fuel Consumption, Different Units

    <Toyota id="Tercel-95">
        <mileage units="miles-per-gallon">29.0</mileage>
    </Toyota>

    <Toyota id="Tercel-95">
        <mileage units="kilometers-per-liter">12.3</mileage>
    </Toyota>

    miles-per-gallon = kilometers-per-liter * 1.609344 / 3.785

Lesson Learned: There are many important relationships that cannot be expressed using the current ontology languages RDFS and OWL. Thus, the full potential for interoperability cannot be realized with the current form of RDFS and OWL.

Purpose of this Document

How can relationships involving transformations be expressed? The purpose of this document is to provide a concrete approach to expressing these relationships, and for using these relationships.

State the Relationship Between Each Pair of Units-of-Measure?

State the Relationship to the Canonical Form

Above we looked at the problem of stating the relationship of every possible pair. A better approach is to simply state the relationship to the canonical form. This reduces the complexity greatly (for "n" units, the complexity is n).

How do Applications Execute the Transformations?

Further, even if it were possible to extend the languages to express the mathematical relationships there still remains the problem of executing the transformation. For example, suppose that an ontology declaratively expressed the formula to convert a polar coordinate to cartesian coordinate. And suppose an application received input data in polar coordinates, but needs it in cartesian coordinates. Suppose the ontology provides the conversion formula, and suppose the application dynamically retrieves the formula. The application may not be smart enough to dynamically convert the polar coordinates to cartesian coordinates. (In the general case, the problem for the application is to be able to dynamically convert an arbitrary coordinate system to another by using formulas that are dynamically provided. This is very difficult indeed.)

Lesson Learned: Simply expressing a mathematical formula in an ontology may not be very helpful to applications.

A Better Approach: Use Ontologies, Canonical Forms and Include Files

The approach is very simple:

1. With an ontology language state the canonical form.
2. With a programming language create code to convert non-canonical forms to the canonical form.

    <River rdf:ID="Yangtze">
        <length>
            <Length>
                <value>6300000</value>
                <units rdf:resource="#Meter"/>
            </Length>
        </length>
    </River>

• a value property with a range of xsd:decimal in canonical form
• a units property with a range of len:Units-of-Measure in canonical form

Expressing the Canonical Form of the Length Class in an Ontology

    <owl:Class rdf:ID="Length">
        <owlx:canonicalForm>
            <owl:Class>
                <owl:unionOf rdf:parseType="Collection">
                    <owl:Restriction>
                        <owl:onProperty rdf:resource="#value"/>
                        <owl:hasValue rdf:resource="http://www.w3.org/2001/XMLSchema#decimal"/>
                    </owl:Restriction>
                    <owl:Restriction>
                        <owl:onProperty rdf:resource="#units"/>
                        <owl:hasValue rdf:resource="#Length-Unit-of-Measure"/>
                    </owl:Restriction>
                </owl:unionOf>
            </owl:Class>
            <owlx:IncludeFile>
                <rdf:type rdf:resource="XSLT2.0"/>
                <owlx:location rdf:resource="Length-Include-File.xsl"/>
            </owlx:IncludeFile>
        </owlx:canonicalForm>
    </owl:Class>

The canonical form of xsd:decimal is defined by the XML Schema specification.

Expressing the Canonical Form of Length-Unit-of-Measure

    <owl:Class rdf:ID="Length-Unit-of-Measure">
        <owlx:canonicalForm rdf:resource="#Meter"/>
    </owl:Class>

Meter, Kilometer, Mile, etc are all subclasses of Length-Unit-of-Measure:

    <owl:Class rdf:ID="Meter">
        <rdfs:subClassOf rdf:resource="#Length-Unit-of-Measure"/>
    </owl:Class>

    <owl:Class rdf:ID="Kilometer">
        <rdfs:subClassOf rdf:resource="#Length-Unit-of-Measure"/>
    </owl:Class>

    <owl:Class rdf:ID="Mile">
        <rdfs:subClassOf rdf:resource="#Length-Unit-of-Measure"/>
    </owl:Class>

    <owl:ObjectProperty rdf:ID="units">
        <rdfs:range rdf:resource="#Length-Unit-of-Measure"/>
    </owl:ObjectProperty>

    <River rdf:ID="Yangtze">
        <length>
            <Length>
                <value>6300</value>
                <units rdf:resource="#Kilometer"/>
            </Length>
        </length>
    </River>

Applications can Process any Length, Regardless of the Units

Length Include File

    <xsl:function name="len:Length" as="element()">
        <xsl:param name="length" as="item()"/>

        <xsl:choose>
            <xsl:when test="$length/len:units/@rdf:resource='http://www.xfront.com/owl/ontologies/Length/#Kilometer'">
                <Length xmlns="http://www.xfront.com/owl/ontologies/Length/#">
                    <value><xsl:value-of select="$length/len:value * 1000"/></value>
                    <units rdf:resource="http://www.xfront.com/owl/ontologies/Length/#Meter"/>
                </Length>
            </xsl:when>
            <xsl:when test="$length/len:units/@rdf:resource='http://www.xfront.com/owl/ontologies/Length/#Mile'">
                <Length xmlns="http://www.xfront.com/owl/ontologies/Length/#">
                    <value><xsl:value-of select="$length/len:value * 1609.344"/></value>
                    <units rdf:resource="http://www.xfront.com/owl/ontologies/Length/#Meter"/>
                </Length>
            </xsl:when>
            <xsl:when test="$length/len:units/@rdf:resource='http://www.xfront.com/owl/ontologies/Length/#Furlong'">
                <Length xmlns="http://www.xfront.com/owl/ontologies/Length/#">
                    <value><xsl:value-of select="$length/len:value * 201.168"/></value>
                    <units rdf:resource="http://www.xfront.com/owl/ontologies/Length/#Meter"/>
                </Length>
            </xsl:when>
            <xsl:otherwise>
                <xsl:sequence select="$length"/>
            </xsl:otherwise>
        </xsl:choose>
    </xsl:function>

    <Length>
        <value>6300</value>
        <units rdf:resource="#Kilometer"/>
    </Length>

For example, if the function is invoked with the above Length it will return:

    <Length>
        <value>6300000</value>
        <units rdf:resource="#Meter"/>
    </Length>

A complete version of this function would have code to convert any length unit-of-measure into canonical form.

The above function is written in XSLT 2.0. However, it could also be written in Java, C++, etc. In fact, there could be several implementations, each in a different programming language. For each implementation there will be an <IncludeFile> element in the ontology.

Designing Applications for Interoperability

The application processes input data as follows: it checks the data to determine if it is in the "preferred" format. If so, then it processes the data directly. If not, it invokes the include file function. The function returns the data in canonical form, and the application then processes the canonical version.

This strategy enables applications to process any length data, regardless of the units-of-measure that are used!

Sample Application

    <xsl:include href="Length-Include-File.xsl"/>

    <xsl:template match="len:Length[len:units/@rdf:resource!='http://www.xfront.com/owl/ontologies/Length/#Kilometer']
                                   [len:units/@rdf:resource!='http://www.xfront.com/owl/ontologies/Length/#Meter']">
        <xsl:variable name="canonical-Length" select="len:Length(.)"/>
        <xsl:apply-templates select="$canonical-Length"/>
    </xsl:template>

    <xsl:template match="len:Length[len:units/@rdf:resource='http://www.xfront.com/owl/ontologies/Length/#Kilometer']">
        <xsl:text>The input data is in the preferred Kilometer format</xsl:text>
    </xsl:template>

    <xsl:template match="len:Length[len:units/@rdf:resource='http://www.xfront.com/owl/ontologies/Length/#Meter']">
        <xsl:text>Either the input data was originally in the canonical format, or it was converted to the canonical format</xsl:text>
    </xsl:template>

Summary of the Approach

1. Create an ontology that declaratively expresses the canonical form, and provide a link to an include file.
2. Using your favorite programming language, create in include file that transforms any non-canonical form into canonical form.
3. Include the include file into your application.
4. Design your application to be able to process the data in the canonical form (your application may also be coded to process data that is in the application's "preferred" form). For any data not in the canonical form call the include file function to transform it to canonical form.

Conclusion

Second Example: Coordinate System Expressed in Different Forms

Step 1: Create an ontology that defines the canonical coordinate system

    <owl:Class rdf:ID="Coordinate-System">
        <owlx:canonicalForm>
            <rdfs:Class rdf:resource="#Cartesian-Coordinate-System"/>
            <owlx:IncludeFile>
                <rdf:type rdf:resource="XSLT2.0"/>
                <owlx:location rdf:resource="CoordinateSystem-Include-File.xsl"/>
            </owlx:IncludeFile>
        </owlx:canonicalForm>
    </owl:Class>

Here is the definition of the cartesian coordinate system as well as the polar coordinate system:

    <owl:Class rdf:ID="Cartesian-Coordinate-System">
        <rdfs:subClassOf rdf:resource="#CoordinateSystem"/>
    </owl:Class>

    <owl:Class rdf:ID="Polar-Coordinate-System">
        <rdfs:subClassOf rdf:resource="#CoordinateSystem"/>
    </owl:Class>

Step 2: Create an include file to transform non-canonical forms to the canonical form

    <xsl:include href="Length-Include-File.xsl"/>

    <xsl:function name="cs:CoordinateSystem" as="element()">
        <xsl:param name="coordinateSystem" as="item()"/>

        <xsl:choose>
            <xsl:when test="local-name($coordinateSystem)='Polar-Coordinate-System'">
                <Cartesian-Coordinate-System xmlns="http://www.xfront.com/owl/ontologies/CoordinateSystem/#">
                    <xsl:variable name="canonical-r-length" select="len:Length($coordinateSystem/cs:r/len:Length)"/>
                    <xsl:variable name="canonical-theta-angle" select="cs:Angle($coordinateSystem/cs:theta/cs:Angle)"/>
                    <x>
                        <Length xmlns="http://www.xfront.com/owl/ontologies/Length/#">
                            <value>
                                <!-- x = r cos theta -->
                                <xsl:value-of select="$canonical-r-length/len:value * exslt:cos($canonical-theta-angle/cs:value)"/>
                            </value>
                            <units rdf:resource="http://www.xfront.com/owl/ontologies/Length/#Meter"/>
                        </Length>
                    </x>
                    <y>
                        <Length xmlns="http://www.xfront.com/owl/ontologies/Length/#">
                            <value>
                                <!-- y = r sin theta -->
                                <xsl:value-of select="$canonical-r-length/len:value * exslt:sin($canonical-theta-angle/cs:value)"/>
                            </value>
                            <units rdf:resource="http://www.xfront.com/owl/ontologies/Length/#Meter"/>
                        </Length>
                    </y>
                </Cartesian-Coordinate-System>
            </xsl:when>
            ...
        </xsl:choose>
    </xsl:function>

Again, the full version of this may be seen by following the link at the bottom of this document.

Step 3: The application includes the "include file"

    <xsl:include href="CoordinateSystem-Include-File.xsl"/>

Step 4: Design the application to process any "foreign" data by converting to canonical form

    <xsl:template match="*[local-name(.) != 'Cartesian-Coordinate-System']">
        <xsl:text>The input data is not in the canonical coordinate system. Converting ...
        <xsl:variable name="canonical-CoordinateSystem" select="cs:CoordinateSystem(.)"/>
        <xsl:apply-templates select="$canonical-CoordinateSystem"/>
    </xsl:template>

    <xsl:template match="cs:Cartesian-Coordinate-System[(cs:x/len:Length/len:units/@rdf:resource != 'http://www.xfront.com/owl/ontologies/Length/#Meter') or
                                                        (cs:y/len:Length/len:units/@rdf:resource != 'http://www.xfront.com/owl/ontologies/Length/#Meter')]">
        <xsl:text>The input data is in the canonical coordinate system, but the Length of x and/or y is not in canonical form. Converting ...
        <xsl:variable name="canonicalForm" select="cs:CoordinateSystem(.)"/>
        <xsl:apply-templates select="$canonicalForm"/>
    </xsl:template>

    <xsl:template match="cs:Cartesian-Coordinate-System[(cs:x/len:Length/len:units/@rdf:resource = 'http://www.xfront.com/owl/ontologies/Length/#Meter') and
                                                        (cs:y/len:Length/len:units/@rdf:resource = 'http://www.xfront.com/owl/ontologies/Length/#Meter')]">
        <xsl:text>The input data is in the canonical coordinate system, and it is in canonical form.

    </xsl:template>

Acknowlegements

• Tom Passin
• John Cowan
• Benja Fallenstein
• Manos Batsis
• Pete Kirkham
• David Carlisle
• Jon Hanna
• Ken Laskey
• Paul Swett
• Bob Foster
• John DeCarlo
• Terry Alford
• Kit Lueder
• Frank Manola
• Jeff Grief
• Richard McCullough
• Nikki Rogers
• Joe Chiusano
• Bill de hOra

References

Links to the Complete Version of the Above Examples

Example 1: Length Example

Example 2: Coordinate System Example