Approaches to Extending the Semantics of a Community's Self-Interested XML Vocabulary

Contents:

• Purpose of this Article
• Example
• Interoperating With Other Communities
• Five Approaches to Extending the Semantics of a Community's Self-Interested XML Vocabulary
  • Decentralized Approaches
    • Out-of-Band Translation
    • Mimic the (X)HTML Model for Extending Semantics
  • Centralized Approaches
    • Universal XML Vocabulary
    • Common Data Exchange Format
    • Consult an Ontology or Abstract Structure
• Acknowledgements
• Tags

Purpose of this Article

The purpose of this article is to document the different approaches for extending the semantics of a Community's tag-set.

Let's start with an example to illustrate what is meant by "extending the semantics of a Community's tag-set."

Example

Community #1 has defined a set of tags for expressing a person's contact information. Here's a sample XML document that shows the Community's XML vocabulary:

<?xml version="1.0" encoding="UTF-8"?>
<Point-of-Contact>
    <Name>John Smith</Name>
    <Address>
        <Street>10 Tremont St.</Street>
        <City>Boston</City>
        <State>MA</State>
    </Address>
    <Telephone>617-123-4567</Telephone>
</Point-of-Contact>

Everyone in Community #1 understands the semantics of these tags, so within their Community they merrily interoperate.

Interoperating With Other Communities

At some point in time, Community #1 recognizes that to grow and thrive they must extend beyond their island and share their information with other Communities and use information from other Communities.

Unfortunately for Community #1, those other Communities use different tags to represent a person's contact information.

Below are five approaches that Community #1 may take to bridge the gap with the other Communities.

1. Out-of-Band Translation

The first approach is for Community #1 to leave their XML documents intact and to bridge the gap by building a translator — for example, an XSLT stylesheet that maps Community #1's tag-set to Community #2's tag-set (and a translator to Community #3, #4, and so forth)

Advantages:

• Each Community can continue to use their existing XML vocabulary and investments.
• It may be possible to translate even widely different data requirements, e.g. the Communities may express "location" in different ways; translation between them may be possible
• The evolution of the Communities is decentralized; each Community locally controls what translators they build and how they build them.

Disadvantages:

• Lots of translators may need to be built and maintained ($$).
• Each Community must understand what tag-sets the other Communities use; further, it must keep abreast of any changes they make to their tag-sets.

2. Mimic the (X)HTML Model for Extending Semantics

The HTML specification says that the class attribute may be used for "general user agent processing". So, by adding class names to elements, authors of an HTML or XHTML document are empowered to expand the semantics of their documents.

Let's see how Community #1 can exploit this idea of using class attributes to extend the semantics of their documents. Suppose that Community #1 knows that some other Communities use the vcard specification for representing a person's contact information. Thus, Community #1 extends the semantics of their XML vocabulary as follows:

<?xml version="1.0" encoding="UTF-8"?>
<Point-of-Contact class="vcard">
    <Name class="fn">John Smith</Name>
    <Address class="adr">
        <Street class="street-address">10 Tremont St.</Street>
        <City class="locality">Boston</City>
        <State class="region">MA</State>
    </Address>
    <Telephone class="tel">617-123-4567</Telephone>
</Point-of-Contact>

Note that a class attribute has been added to each element, and the value of each class is a vcard term.

Now Community #1 can interoperate with any Community that understands vcards. And, of course, within Community #1 they simply ignore the class attributes, since the semantics of the elements are already understood.

The HTML specification also says: "Multiple class names must be separated by white space characters." So, the class attributes can be used in a polymorphic fashion to support other Communities. For example, suppose some other Communities use the EDI terminology to represent a person's contact information. Community #1 can accommodate those Communities as well:

<?xml version="1.0" encoding="UTF-8"?>
<Point-of-Contact class="vcard contact">
    <Name class="fn contact-name">John Smith</Name>
    <Address class="adr location">
        <Street class="street-address mailing-address">10 Tremont St.</Street>
        <City class="locality district">Boston</City>
        <State class="region province">MA</State>
    </Address>
    <Telephone class="tel phone">617-123-4567</Telephone>
</Point-of-Contact>

Note that each class attribute now has two values: a vcard term and an EDI term.

Now Community #1 can interoperate with any Community that understands vcards, as well as any Community that understands EDI. And, of course, within Community #1 they still ignore the class attributes, since the semantics of the elements are already understood.

Additional extensions can be made to the class attributes to support other Communities.

Advantages:

• The semantic extensions are embedded within the document (in-band); no translators needed; the gap between Communities is bridged by information, not code.
• The evolution of the Communities is decentralized; each Community locally controls what semantic enhancements they add (i.e. what class values they add).
• Over time, some tags in different Communities never get used and some get used a lot; assuming the content is published on the Web, we can track usage statistics (http://code.google.com/webstats/). Eventually, based on these statistics, every XML editor incorporates the most widely used tags from other vocabularies and we reach organically and chaotically the goal of a single vocabulary, at least for the most common concepts.

Disadvantages:

• Community #1 must extend its XML vocabulary to support the class attribute on each element, and define its semantics similar to how HTML defines it.
• Community #2, #3, and so forth must understand that Community #1 is using the class attribute to extend semantics.
• In the above example the relationships between one Community's terminology and another was simple, e.g. "Point-of-Contact" is synonymous with "vcard". Where the relationship is not 1:1 problems may arise, e.g. Community #1 expresses location using latitude and longitude whereas Community #2 uses easting and northing.

3. Universal XML Vocabulary

The third approach is for all the Communities to get together, throw out their existing tag-set, and get everyone to agree to use one, standard, universal tag set.

Advantages:

• No interoperability problems.

Disadvantages:

• Difficult to get disparate groups with their own self-interests to forego their investments and agree to adopt a single, universal tag-set.
• This is a centralized approach — the universal tag-set must be agreed upon by all the Communities.
• A change in the universal tag-set may impact every Community.

4. Common Data Exchange Format

The fourth approach is for all the Communities to agree to a common data exchange format. Thus, when Community #2 fetches data from Community #1, Community #1 will translate its information into the common data format. Community #2 will translate the data that it receives (which is in the common data format) into its own format. Data exchanges within Community #1 is unchanged.

Advantages:

• The N-squared translation problem of approach 1 (above) is reduced to N. That is, instead of every Community creating a translator to every other Community ( N * N-1 translators total), each Community creates just two translators — one translator to convert their Community-specific XML vocabulary into the common data format, and a second translator to convert the common data format into their Community-specific format (2N translators total).
• Each Community can continue to use their existing XML vocabulary and investments.

Disadvantages:

• Difficult to get disparate groups with their own self-interests to reach a consensus on a common data format.
• This is a centralized approach — the common data format must be agreed upon by all the Communities.
• A change in the common data format may impact every Community.

5. Consult an Ontology or Abstract Structure

The fifth approach is to create an ontology or abstract structure (e.g. UML models or XML Schema complexTypes) that specifies the relationships between the "concepts" used by the various Communities. When a Community #1 application processes the XML document that it has just fetched from Community #2, it consults the ontology or abstract structure to determine how to map the Community #2 tags and data into a form that it can understand and process.

Advantages:

• Relationships are expressed abstractly, in terms of semantic relationships rather than syntactic relationships. This gives improved flexibility — data exchanges may be in the form of the XML syntax or some other syntax; the ontology or abstract structure frees you from coupling to a particular syntax.
• Each Community can continue to use their existing XML vocabulary and investments.

Disadvantages:

• This is a centralized approach — the ontology or abstract structure must be agreed upon by all the Communities and each Community must implement software to map another Community's concepts into their concepts via the ontology or abstract structure.
• A change in the central ontology or abstract structures may impact every Community.

Acknowledgements

The following people contributed to the creation of this document:

• Joel Bender
• Len Bullard
• Marcus Carr
• Cheryl Connors
• Roger Costello
• Fraser Goffin
• Stephen Green
• Lueder Kit
• Guillaume Lebleu
• Leo Obrst
• Marwan Sabbouh
• Rob Simmons
• Paul Tyson

Tags

• XML
• Community of Interest
• Ontology
• UML
• Decentralization
• Centralized
• Evolution
• Chaos
• Complex_Systems