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:
- SLR is a type of Camera
- f-stop is synonymous with aperture
- focal-length is synonymous with lens size
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:
Here's another physical expression:
Note that the first physical expression uses this terminology (tags):
While the second physical expression uses this terminology (tags):
These represent two (of many) physical expressions for the
same logical model (the Camera OWL Ontology).
Strategy Objective
- Allow flexibility of physical expression.
- Allow (and encourage!) diversity of physical expression.
That is, create instance documents in a style
which meets your needs/desires.
- Liberate from requiring every application to use the
same terminology (i.e., the same tag names).
- Truly realize XML's flexibility.
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:
My trading partner has taken advantage of XML's flexibility and has
elected to use this terminology:
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:
The Ontology returns:
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:
The Ontology returns:
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:
- An OWL Ontology
- Physical expressions
- OWL Parser
- 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:
Physical Expression #2:
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}
versus>
focal-length versus (lens) size
f-stop versus aperture
versus
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.