Using OWL to Avoid Syntactic Rigor Mortis

by Roger L. Costello

Below is outlined a strategy for realizing the full flexibility of XML through the use of OWL ontologies.

Prior to outlining the strategy we need to define some terminology that will be used.

Logical Design

An OWL Ontology defines the (perceived) fundamental data items and their logical relationships. That is, an OWL Ontology defines a "logical design".

Example of fundamental relationships for Camera data:

Physical Expression

An instance document is a "physical expression" of the logical design. For a given logical design there are many possible physical expressions.

Example of a physical expression for Camera data:

<SLR rdf:ID="Olympus-OM-10">
        <viewFinder>twin mirror</viewFinder>
        <optics>
               <Lens>
                   <focal-length>75-300mm zoom</focal-length>
                   <f-stop>4.0-4.5</f-stop>
               </Lens>
        </optics>
        <shutter-speed>1/2000 sec. to 10 sec.</shutter-speed>
</SLR>
Here's another physical expression:
<Camera rdf:ID="Olympus-OM-10">
        <viewFinder>twin mirror</viewFinder>
        <optics>
               <Lens>
                   <size>300mm zoom</size>
                   <aperture>4.5</aperture>
               </Lens>
        </optics>
        <shutter-speed>1/2000 sec. to 10 sec.</shutter-speed>
</Camera>
Note that the first physical expression uses this terminology (tags):

SLR, f-stop, focal-length  
While the second physical expression uses this terminology (tags):

Camera, aperture, (lens) size  
These represent two (of many) physical expressions for the same logical model (the Camera OWL Ontology).

Strategy Objective

Strategy

The strategy is quite simple: all parties participating in an exchange of data can compose any physical expression, provided the physical expression does not violate the fundamental data relationships defined in the logical design.

Thus, one person can create a Camera document like the first one shown above. Another person can compose a Camera document like the second one shown above. Using the unifying logical design (i.e., the OWL Ontology) the two people can interoperate seamlessly.

Concept of Operation

Here's the concept of operation: Let's take the Camera example. Suppose that my application receives a physical expression (i.e., an instance document) from a trading partner. Further, suppose that my application has been coded to understand this terminology:
Camera, aperture, (lens) size  
My trading partner has taken advantage of XML's flexibility and has elected to use this terminology:
SLR, f-stop, focal-length  
As my application parses the XML document that it received from the trading partner it encounters <SLR>. It doesn't "understand" SLR so it "consults" the Camera Ontology:
"What do you know about SLR?"
The Ontology returns:
"SLR is a type of Camera."
This knowledge provides the link for my application to understand the relationship between something it doesn't know (SLR) to something it does know (Camera).

My application continues parsing...

It encounters <f-stop>. Again, my application was not coded to understand f-stop, so it consults the Camera Ontology:

"What do you know about f-stop?"
The Ontology returns:
"f-stop is synonymous with aperture."
Once again, this knowledge serves to bridge the terminology gap between something my application doesn't know to something my application does know.

Ditto for focal-length...

Summary

Interoperability despite terminology differences! There can be many different physical expressions (i.e., instance documents can be in various forms). The flexibility of XML is being realized!

When an application processes a physical expression (i.e., an instance document) it "consults" an Ontology for terminology it is not knowledgeable about.

Performance

One point of using an Ontology is that it allows for near linear semantic integration rather than n**2 integration. Each application/database maps to the "lingua franca" of the Ontology, rather than to each other.

Ingredients of Interoperability

Here are the ingredients for achieving interoperability:
  1. An OWL Ontology
  2. Physical expressions
  3. OWL Parser
  4. OWL Query Tool
With this collection of tools you will be able to exchange documents with your trading partners, using physical expression that make sense to you. Let's briefly examine each ingredient:

1. An OWL Ontology: An OWL Ontology expresses the fundamental relationships of your data. To view an example of a Camera Ontology see here:

Nice graphical view

Camera.owl

2. Physical Expressions: The OWL Ontology defines terms and their relationships. A physical expression is an instance of an Ontology. There can be many different physical expressions of an OWL Ontology. For example, below are two physical expressions for the Camera OWL Ontology:

Physical Expression #1:

<?xml version="1.0" encoding="UTF-8"?>
<SLR xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns="http://www.Camera.org">
    <optics>
         <Lens>
               <focal-length>75-300mm zoom</focal-length>
               <f-stop>4.5-5.6</f-stop>
         </Lens>
    </optics>
    <carriage>
         <Body>
              <shutter-speed rdf:parseType="Resource">
                   <min>0.002</min>
                   <max>1.0</max>
                   <units>seconds</units>
              </shutter-speed>
         </Body>
    </carriage>
    <cost rdf:parseType="Resource">
        <rdf:value>325</rdf:value>
        <currency>USD</currency>
    </cost>
</SLR>

Physical Expression #2:

<?xml version="1.0" encoding="UTF-8"?>
<Camera xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns="http://www.Camera.org">
      <viewFinder rdf:resource="ThroughTheLens"/>
      <carriage>
           <Body>
                <shutter-speed rdf:parseType="Resource">
                     <min>0.002</min>
                     <max>1.0</max>
                     <units>seconds</units>
                </shutter-speed>
           </Body>
      </carriage>
      <optics>
           <Lens>
                <aperture>4.5-5.6</aperture>
                <size>75-300mm zoom</size>
           </Lens>
      </optics>
</Camera>
In fact, both physical expressions are talking about SLRs. The viewFinder property in Physical Expression #2 identifies that it is a SLR Camera (only SLR's have a view finder that is through the lens). Note the many differences between the two physical expressions:

SLR versus {Camera, viewFinder}

<SLR>
   <optics>...</optics>
   <carriage>...</carriage>
   <cost>...</cost>
</SLR>
versus>
<Camera>
   <viewFinder rdf:resource="ThroughTheLens"/>
   <carriage>...</carriage>
   <optics>...</optics>
</Camera>
focal-length versus (lens) size

f-stop versus aperture

<Lens>
    <focal-length>75-300mm zoom</focal-length>
    <f-stop>4.5-5.6</f-stop>
</Lens>
versus
<Lens>
    <aperture>4.5-5.6</aperture>
    <size>75-300mm zoom</size>
</Lens>
Quite a few differences in the two physical expressions. Lots of flexibility of expression, I'd say!

3. An OWL Parser: An OWL Parser is used to check that your physical expression does not violate any fundamental data relationships. That is, an OWL Parser checks your physical expression against an OWL Ontology.

4. An OWL Query Tool: An OWL Query Tool is used by your application when it receives a physical expression which contains unexpected terminology. Thus, the application "consults" the OWL Ontology by using the query tool, e.g.,

Use the query tool to ask the Ontology: "What do you know about SLR?"

The query tool responds with: "SLR is a type of Camera"

...

Here's the URL to a query tool that we are currently using:

Stanford Query Tool

Okay, that's it! With this small collection of items you are able to seamlessly interoperate. Further, there is no need for all parties to agree to a common message format. Each party can create physical expressions in a manner that best meets their needs and desires.