Strategy Objective

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:

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:

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:

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:

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:

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.,

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.