Business Maps: Topic Maps Go B2B
by Marc de Graauw | Pages: 1, 2

The Knowledge in Mappings

The model above shows the knowledge that exists in ontology mappings. First we must distinguish the documents which are exchanged in B2B exchanges and the items which make up those documents. Items can belong to domains (data types) which in turn can be specializations of other domains (domains are represented here as items which generalize other items). In the left-hand classes we would store the information on the business documents in use by relevant business partners. There is no need to store the full definitions of the data; it is sufficient to store identifiers that uniquely identify the documents, items therein, and domains in use. After all, the full definitions are probably already stored somewhere; simply copying them would only introduce unnecessary redundancy.

On the right-hand side of the model we have the actual mappings. First, the fact that some (usually two) documents are mapped onto each other is stored in the class document-mapping. The document-mapping is related to one or more item-mappings. The item-mappings store not only the identifiers of the mapped items, but also the kind of mapping: is this an equivalence relationship, which is potentially bidirectional? Or is it a unidirectional mapping, i.e., is it a subset-superset relationship?

We can also store conversions. For instance, if the destination document allows last names of only 25 characters, but the source allows last names of indefinite length, we could specify that names need to be truncated to 25 characters. We could also store more complex transformations. They should, however, be readable for ordinary humans, which would rule out XSLT "as is". The intended users of a tool based on this model are business analysts, not XML programmers. (An intelligent tool could of course store XSLT for a large class of transformations and show the results in natural language.) Last, we can store domain conversions, so we wouldn't have to store the same MM/DD/CCYY to CCYY-MM-DD conversion for every date in the document.

The central class is context. This is context in the broadest sense; this class could store information on B2B vocabulary, region, country, company, business unit, timeframe and whatever is necessary for the mapping under scrutiny. Context would apply to all other classes. If unspecified, an item mapping would usually inherit its context from the document mapping in which it is contained. Context also applies to the left-hand side, though maybe we would only want to store the vocabulary involved here. Of course, the work done on Context Drivers of ebXML would constitute a good starting point for defining context.

Business Maps

The data model maps quite nicely onto core Topic Map constructs, to yield what I will call "Business Maps".

Mapping Model	Example	Topic Map construct
document	Invoice	topic
item	CustomerName	topic
document composition	CustomerName is part of Invoice	association
document-to-document mapping	Invoice maps to invoice_document	association
item-to-item mapping	CustomerName maps to company_name	association
context	Vocabulary, Company, Region, Industry, ...	scope
external document description	http://www.bizwords.org/invoice	occurrence (type: business document description)
external item definition	http://www.bizwords.org/amount	occurrence (type: definition)
external item datatype	http://www.bizwords.org/date	occurrence (type: datatype)
external item example	http://www.bizwords.org/amount/example	occurrence (type: example)

To see how this works consider the following fragment of code, taking from the Topic Map definition of "Bizwords!", a B2B vocabulary:

<topic id="name">
  <instanceOf>
    <topicRef xlink:href="itm.xtm#item"/>
  </instanceOf>
  <baseName>
    <scope>
    <subjectIndicatorRef xlink:href="http://www.bizwords.com"/>
    </scope>
    <baseNameString>CustomerName</baseNameString>
  </baseName>
  <occurrence>
    <instanceOf>
      <topicRef xlink:href="itm.xtm#definition"/>
    </instanceOf>
    <resourceRef xlink:href=
	    "http://www.bizwords.com/definitions#CustomerName"/>
  </occurrence>
</topic>

Here a single data item is defined. It is an instance of topic type "item" (which is defined elsewhere). The topic has "CustomerName" as a name. This name is scoped by the B2B vocabulary to avoid name-based merging with topics from other B2B vocabularies which might conceivably have the same name. The topic would merge with other topics which have the name "CustomerName" within scope "http://www.bizwords.com", which is desirable since these topics would represent the same data item in the same vocabulary. The topic also has an occurrence which is a definition of "CustomerName" somewhere on the www.bizwords.com site. Note that the actual definition of "CustomerName" does not have to be repeated here. Topic Maps are indexes which only link to external data sources.

Besides topics representing data items, the Topic Map of Bizwords! would also contain definitions of business documents and their composition. A code fragment:

<association>
  <instanceOf>
    <topicRef xlink:href="itm.xtm#composition"/>
  </instanceOf>
  <member>
    <roleSpec>
      <topicRef xlink:href="itm.xtm#containing-document"/>
    </roleSpec>
    <topicRef xlink:href="#invoice"/>
  </member>
  <member>
    <roleSpec>
      <topicRef xlink:href="itm.xtm#required-item"/>
    </roleSpec>
    <topicRef xlink:href="#name"/>
  </member>
  ... members omitted ...
</association>

This is an association of type "composition" (defined elsewhere) which says that the topic "invoice" (not shown) plays a role "containing-document", and the topic "name" (which was discussed above) plays the role of "required-item" in this document. The association effectively describes a business document composition. Other members of the association are omitted for brevity, but would include at least "CustomerAddress" and "TotalAmount" in the GigaSellers example.

Now suppose GigaSellers uses the Bizwords! B2B vocabulary, but Print & Send uses a competitor, the Galactic Business Language (GBL). GigaSellers and Print & Send could then make a Business Map using the above defined data items. For example:

<association>
  <instanceOf>
    <topicRef xlink:href="itm.xtm#unidirectional_mapping"/>
  </instanceOf>
  <scope>
    <topicRef xlink:href="context.xtm#gigasellers"/>
    <topicRef xlink:href="context.xtm#sales"/>
    <topicRef xlink:href="context.xtm#europe"/>
  </scope>
  <member>
    <roleSpec>
      <topicRef xlink:href="itm.xtm#source_item"/>
    </roleSpec>
    <topicRef xlink:href="bizwords.xtm#name"/>
  </member>
  <member>
    <roleSpec>
      <topicRef xlink:href="itm.xtm#destination_item"/>
    </roleSpec>
    <topicRef xlink:href="gbl.xtm#name"/>
  </member>
</association>

This association is of association type "unidirectional_mapping". It links two data items in scope "GigaSellers, Sales, Europe" (The scope is restricted to the GigaSellers point of view for simplicity here.). This says this unidirectional mapping is found to be valid in the GigaSellers European Sales department. Of course the Business Map will contain many more such associations. It would also be possible to have associations of other types than "unidirectional_mapping". We could have a derived association type which indicates a transformation, for instance of date format MM/DD/CCYY to CCYY-MM-DD. We could also have bidirectional mappings. So Business Maps can be a very powerful tool to capture the knowledge in mappings for later reuse.

What's more, Topic Maps offer the facility to merge two distinct Topic Maps. This is an excellent way to compare separate, portable B2B-mappings. When we have two Business Maps, say one from "Sales Europe" and one from "Sales Asia", and we want to make a new Map for "Sales America" or "Marketing Europe", we can merge the existing maps. Any references to external message items will be merged. Once the Business Maps are merged, we can use the scope to filter the business processes we are interested in. Business analysts will have quick access to all relevant mapping information from prior mappings in related areas. So Business Maps can provide an easy and flexible way to reuse knowledge stored in mappings: they are portable, reusable mappings come true.

Quite a few things need to happen before this vision is realized. The best thing of course would be an accepted standard for Business Maps. Having this, we would be able to exchange mappings with all companies using this standard. Note that this a far less ambitious and more tenable goal than establishing a single unifying B2B ontology. This approach could also prove to be a viable way to achieve intra-company interoperability, still a big problem in the world of ever-merging large companies. We would need tools to support the Business Maps -- querying, filtering, importing and exporting, creating and editing them. And we would need a description of the properties of applications processing Business Maps, especially on context and scope. The Topic Map standards do not say a lot about what scope means, and the current notion of scope does not support what Business Maps would need. Scope is without doubt the most hotly debated issue in the Topic Map community at the moment, and there are several proposals to extend scope. All in all, Business Maps could provide for a huge facilitation of human-mediated ontology mapping.

Conclusion

Interoperability between ontologies is one of the most important problems in B2B data exchange. For the time being, making mappings will mainly be a human job. Therefore we need a way to leverage human intelligence to make all the required B2B mappings. Portable, reusable mappings would accomplish this. Those mappings would need to store information on business document mappings and the context that applies to those mappings. Topic Maps are an excellent vehicle to store such information, thus yielding Business Maps.

The complete samples of Business Maps are available at http://www.marcdegraauw.com/itm/

Related links

The original ISO Topic Map standard: ISO/IEC 13250 Topic Maps

The XTM standard: XML Topic Maps (XTM) 1.0

The XTM standard contains a good introduction on Topic Maps: 2.1 A Gentle Introduction to Topic Maps

Alan Kotok on the current status of interoperability initiatives: Interoperability Summit: Good Intentions, Little Action

---