[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: In Search of XML Interoperability: XLink + XML Schema = Interoperabi

• From: David Wang <dwang@m...>
• To: xml-dev@x...
• Date: Mon, 14 Feb 2000 15:05:42 -0500

Hi everyone,

In following up costello@m...'s thoughts about XML Interoperability,
I've thought about some ways to achieve that same goal and would like to
kick around some ideas/thoughts with everyone.

Recall that XML Interoperability was defined as "the ability of an
application to make effective use of an XML document that it receives"

It was suggested that perhaps:
XLink(modified) + XML Schema =? XML Interoperability.  

Namely, in order for an application to effectively use an XML document that
conforms to a foreign schema, it has to have a way of relating elements in
a foreign schema to elements in a familiar schema, possibly
through transitive relations.

For example, here are two XML schemas that are capable of being
interoperable:
Schema_1:
Weight (kg)
SSN
First_Name

Schema_2:
Weight (lb)
Social_Security_Number
Full_Name

There ought to be a way to describe the following notions:
- "Schema_1:weight is equivalent(or at least similar) to Schema_2:weight,
barring a constant factor"
- "Schema_1:SSN is equivalent to Schema_2:Social_Security_#"
- "Schema_1:First_Name is a part of Schema_2:Full_Name"

So, why not hijack a bit of the machinery XLink already provides to create
a "XML Semantic Modeling Language" to draw semantic links between elements
of different schemas?  The new language can harness XLink's ability to link
XML instance documents (i.e. XSD) and refine/restrict XLink's descriptive
notions to purely relationship notions.

Here are some of my thoughts:
- extend XLink's type attribute to also contain "semantic"
- reinterpret XLink's role attribute when type=semantic as a relation
definition
- use XLink's from/to attributes to define the endpoints of the relation,
possibly in XPointer/XPath fashion so that semantic links can be drawn
between element definitions
- define some standard relations such as isA, hasA, equiv, isLike, partOf

For those of us that like formal notation:  :-)
type = simple | extended | locator | arc | resource | title | semantic |
none
role = standard-relations | extended-relations
from = resource locator
to = resource locator
standard-relations = isA | hasA | equiv | isLike | partOf
extended-relations = *

Now, armed with this new language, let's see how it expresses the notions
we desired between Schema_1 and Schema_2:

<link xlink:type="extended">
  <resource xlink:type="locator"
            xlink:href="http://www.somewhere.org/Schema_1.xsd"
            xlink:role="Schema_1">
  <resource xlink:type="locator"
            xlink:href="http://www.somewhere.org/Schema_2.xsd"
            xlink:role="Schema_2">
  <semantic-linking-rule xlink:type="semantic"
                         xlink:from="Schema_1#xpointer(//Weight)"
                         xlink:to="Schema_2#xpointer(//Weight)"
                         xlink:role="isLike">  #perhaps also conversion
factors??
  <semantic-linking-rule xlink:type="semantic"
                         xlink:from="Schema_1#xpointer(//SSN)"
                        
xlink:to="Schema_2#xpointer(//Social_Security_Number)"
                         xlink:role="equiv">
  <semantic-linking-rule xlink:type="semantic"
                         xlink:from="Schema_1#xpointer(//First_Name)"
                         xlink:to="Schema_2#xpointer(//Full_Name)"
                         xlink:role="partOf">
</link>

There would have to be an appropriate way of defining the locators and
XPointer/XPath elements.  Also, for isLike relations, it should have an
accompanying "similarity transformation function" -- i.e. conversion
from kg to lb.

For certain, XSML is more effective when defined out-of-line, but like
XLink, it does not need to require that possibility.  Also, a XSML can
piggy back on XLink's discovery process for out-of-line definitions, so
it's extendable.

Other questions:
- We've described relations in a positive manner; would negative relations
be useful (i.e. notIsA, notHasA, notEquiv, notIsLike, notPartOf)
- Should the set of primitive relations be dynamically extendable, or
should it be fixed?
- What about circular relations?
- 'hasA' denotes that one object "contains" another object; is it
reasonable to have its converse 'partOf' denote one object is contained by
another object?

Any comments, suggestions?

/David

> Hi Folks,
> 
> I have a few thoughts about XML Interoperability that I would like to
> kick around with ya'll.
> 
> First, a definition of XML Interoperability:
> 
> Definition.
>    XML Interoperability: the ability of an application to make effective
>                          use of an XML document that it receives.
> 
> There are two ends of the XML Interoperability spectrum:
> [1] At one end of the spectrum an application is coded for a specific
> schema and this is able to make effective use of only XML documents that
> conform to that schema.
> [2] At the other end of the spectrum the application is able to make
> effective use of any XML document that it receives, regardless of the
> schema that the XML document conforms to.
> 
> I contend that [2] is the desired goal, but [1] is where we are at
> currently.  So, how do we get to [2]?  That's what I wish to explore.
> 
> Question.
> If an application receives an XML document that conforms to a schema for
> which the application has no familiarity, how does the application "make
> effective use" of it?
> 
> Answer.
> From my own life, when I am exposed to a new idea I learn best by
> relating the new idea to something that I already know.  Similarly, if
> an application receives an XML document that contains new, unfamiliar
> elements/attributes then it may be able to still make use of them (the
> unfamiliar elements/attributes) if it can relate them to
> elements/attributes that it knows about.  For example, suppose that the
> XML Document contains an element <metro>, and <metro> is an element for
> which the application has not been coded to understand.  In other words,
> <metro> is an unfamiliar element to the application.  Now let's suppose
> that there is some way for the application to discover relationships.
> Suppose that the application looks into a "relationship database" and
> discovers that <metro> is exactly equivalent to <train>.  Let's further
> suppose that the element <train> is something that the application is
> familiar with.  The application is now able to "make effective use" of
> the <metro> element.
> 
> So, what are the key components of XML Interoperability?  There are two
> components:
> (1) Describing Relationships: there must be a language for describing
> the relationships between things.  In the above example we saw the need
> to describing the relationship "the <metro> element is exactly
> equivalent to the <train> element".  This is, of course, a very simple
> relationship.  There are many other types of relationships that we would
> like to be able to express.
> (2) Discovering Relationships: the relationships that are described must
> be physically put somewhere.  Typically, these relationships will relate
> elements/attributes/element groups/attribute groups from two or more XML
> Schemas.  Intuitively, it seems to me that these relationships belong in
> some kind of "relationship database".
> 
> If you are familiar with the XLink working draft, the previous
> description may sound a lot like XLink. I agree.  Let's take a look at
> linking in general and XLink in particular.
> 
> Link.
> A link is a means for expressing relationships between two or more
> items.  The items could be a document or an element or an attribute, or
> anything.
> 
> XLink.
> XLink has the notion of putting link expressions into a separate link
> database document (called a linkbase).  Something analogous is needed to
> support XML Interoperability.  I am calling the repository of
> relationships a "relationship database".
> 
> However, there are differences between an XLink linkbase and a
> relationship database.  Whereas XLink is intended for linking XML
> instance documents, the "relationship links" described above is intended
> for relating (linking) XML Schema definitions.  Further, the purpose of
> the "relationship link" is different from an XLink link.  The
> "relationship link" characterizes the relationship between two items,
> such as "isA", "equivalence", etc.  Contrast that with an XLink link
> whose purpose is to describe things like "should I traverse the link on
> activation, should I create a new window, etc".
> 
> Thus, I see a modified form of XLink playing with XML Schemas to enable
> XML Interoperability:
> 
> XLink(modified) + XML Schema = XML Interoperability
> 
> Some other, random thoughts
> - discovering a relationship may involve several "hops"; e.g., "A is
> related to B, and B is related to C. The application knows about C.
> Therefore, the application has an understanding of A."
> - we need to characterize the possible relationships - isA, equivalence,
> what else?
> - need to consider transitivity, commutativity of relationships.
> - currently, XML Schemas has some support for expressing relationships,
> namely we can express that element A is exactly equivalent is element
> B.  This is good.  However, I would argue that this expression of
> equivalence relationships belongs more appropriately in a separate
> document, in a "relationship database", as described above.
> 
> Okay, this message is long enough.  Any comments?  /Roger

• References:
  • Frontline report from the Desperate Fgrep Hacker
    • From: John Cowan <cowan@l...>

• Prev by Date: Re: (Pre)Announce: Gutenberg at HWG
• Next by Date: Data Representation and Processing Model [Was: Frontline report from the Desperate Fgrep Hacker]
• Previous by thread: Re: (Pre)Announce: Gutenberg at HWG
• Next by thread: Re: Frontline report from the Desperate Fgrep Hacker
• Index(es):
  • Date
  • Thread