 | Level: Introductory Uche Ogbuji (uche@ogbuji.net), CEO and principal consultant, Fourthought, Inc.
01 Feb 2001 This discussion of XML and semantics kicks off a column by Uche Ogbuji on knowledge management aspects of XML, including metadata, semantics, Resource Description Framework (RDF), Topic Maps, and autonomous agents. Approaching the topic from a practical perspective, the column aims to reach programmers rather than philosophers. This new column, Thinking XML, will cover the intersection of XML and knowledge architecture (KA). Knowledge architecture sounds like something tossed out by a jargon bot, but it's really just an umbrella term for some very useful technologies that are emerging now that XML is entering its adolescence. Metadata management, semantic transparency, and autonomous agents are hardly concepts unique to XML, but the promise of XML to unify the syntax of structured and semistructured data helps turn the next-to-impossible into the feasible. The key feature that will distinguish this column from much of the discussion of such topics is that I'll address programmers, not philosophers. I'll focus on development tools and techniques that allow developers to use XML to better collect and navigate the knowledge latent in data, whether in corporate databases or on the Web itself. This sounds quite grandiose, but the column installments will really be an incremental procession, never leaving common sense too far behind. This first column and the next set the scene, so they will diverge a bit from my ground rule of "lots of code, little philosophy." These first two columns cover the semantics of XML and related vocabularies. I'll discuss only initiatives with existing work products for the developer to take a look at, but I won't be presenting a lot of hands-on code and techniques just yet. What's all the fuss about semantics?
What are semantics, anyway? Because of the dreaded curse of the "s-word," no two people would likely agree on a definition of semantics. In general, semantics are a layer of specification of XML data in a system that builds on top of common syntax. This suggests some of the many concepts that have been tagged XML semantics.
These include:
- The interpretation of element type names, attribute names, and, in some cases, content terms
- The processing rules (also known as business rules) for conducting transactions with valid documents
- The relationship between structured elements of one document and those of another
Of course there is some overlap among the three concepts. Semantics through the looking glass
Two years ago I wrote an article in Sunworld (now Unix Insider: see Resources) exploring how the new XML might fit in the world of Electronic Data Interchange (EDI). One of the things that motivated EDI back in the '70s was the promise of unifying the vocabulary of business transactions to improve the automation of electronic communications between the information systems of different organizations. EDI defines a particular syntax and a particular set of semantics -- some generic, and some highly specialized -- for particular industries. XML currently has a well-defined syntax and structure, but it does not provide what is known as semantic transparency. That is the ability of the XML machine to establish the relationship between, say, a PurchaseOrder or PO element and the higher-order processing that performs specialized operations based on that element. In short, it means that the expressions in the data faithfully represent the meaning of the corresponding concepts. The ultimate test of semantic transparency is whether a human, using only the mechanisms available to the XML processing software, can correctly understand the meaning of the XML data. Clearly XML alone doesn't meet the threshold for semantic transparency, and that is why semantics preoccupy so many XML technologists. If XML systems cannot achieve semantic transparency, those systems may fall short even of the three-decades-old EDI as a means of automating electronic transactions. There is little controversy over the need for XML to achieve semantic transparency. Even before the XML 1.0 specification was completed, various groups began looking to develop mechanisms for semantic transparency. In fact, some of those initiatives were not even born with XML in mind; they were (and still are) intended as generalized authorities for terminology across SGML, XML, EDI, tabular reports, and any other machine format.
Hacking with ISO BSR
The elder statesman of machine-readable semantics has its roots in EDI: The ISO Basic Semantics Register (BSR) has been in development since 1998 with a charter "[to] act as a central reference to assist in the universal, multilingual understanding of data across commerce, industry and administration." An ambitious goal, such as probably none but the ISO could undertake, the BSR has been dogged with delays. So far the ground rules have been established (publication ISO 16668:2000), and the ISO has collected a preliminary set of a few thousand entries, for example AccountsPayables, ContactParty.CustomerAssigned.Identifier, and Contract. Once completed, the BSR will allow programmers to come up with a syntactic XML schema such as the following DTD fragment: <!ELEMENT AccountsPayables.Contact (ContactParty.CustomerAssigned.Identifier)>
<!ELEMENT ContactParty.CustomerAssigned.Identifier (#PCDATA)>
|
Let's say those elements are included in a report format used by a manufacturing firm that outsources its accounting to another firm. Then the developers of the XML vocabulary would gain the benefits of semantic transparency in these ways:
- The developers make sure that the element type names used correspond to the equivalent concepts in the BSR to minimize ambiguity in the meanings of the elements. The manufacturer can communicate with the accountancy about the data and be sure that both parties agree on what is being expressed.
- Because the meaning of the terms is clear, mapping this format to the standard format of the accountancy is far more straightforward than usual for such tasks, and it might even be entirely automated. Straightforward mapping might be feasible even if the manufacturer uses EDI while the accountancy uses XML.
- The meaning ascribed in the BSR gives some indication of the relationship between, say, the
ContactParty.CustomerAssigned.Identifier element and a Contract element elsewhere in the report -- or in a different document.
Even at this preliminary stage, you can experiment with the BSR because the Global Information Locator Service (GILS) has made available RDF Schema and XML Schema compilations of the preliminary BSR entries. GILS is a U.S. government initiative that covers techniques and resources for seeking structured information. A valuable resource, the GILS BSR compilation already covers much of the common terminology used in general government and private intercourse. |
UN/CEFACT: United Nations Centre for Trade Facilitation and Electronic
Business
CEN/ISSS: European Committee for Standardization / Information Society
Standardization System
DISA: Data Interchange Standards Association
|
|
However, take care that this initial collection is experimental. Not
only are the descriptions still very sketchy, but there are actually
syntax errors in the XSchema and RDFS representations. I recommend watching the BSR because it influences important groups such as UN/CEFACT (worldwide), CEN/ISSS (Europe), and DISA (USA).
Uniform Europe and an American juggernaut
Speaking of the CEN/ISSS, this group has done a lot of work in the area of XML/EDI. The CEN/ISSS is a committee charged with promoting standardization among information systems within the European community. Though its XML/EDI work is officially still a pilot program, CEN/ISSS has put together a comprehensive framework for translating the UN/EDIFACT flavor of EDI to XML. The conversion framework includes DTD-generation rules and samples that any developer familiar with EDI can try out. The result is undoubtedly complex, but EDI's long history makes sure that both the fields and the message flow used in XML/EDI are very well defined. Clearly, the EDI folks got quite a jump on the handling of semantics of XML. One significant player that came without an EDI badge of honor is Microsoft. In 1999 Microsoft announced the BizTalk framework. BizTalk is a repository for Microsoft, its partners, and industry groups to register schemas, process descriptions, and sample XML files. It is intended to serve as a clearinghouse of XML formats and related processes, which would make it a significant force for semantic transparency. Partly because it springs from a single company, and partly because of the usual industry politics, BizTalk has been the subject of great controversy. Some bill it as an attempt by Microsoft to hijack XML by building a hegemony over semantic matters. Regardless of the politics, tools have trickled out for working within the BizTalk framework. Many of the tools are mapping software by the likes of XML Solutions, which provides GUIs for mapping one vocabulary to another. Also, developers can begin using the published specification of the BizTalk XML messaging format, which is based on SOAP. Unfortunately, if you want to do serious BizTalk messaging work, you need Microsoft's commercial BizTalk Server product.
On to the new kids on the block
I didn't cover partially relevant work such as the OMG's XML Metadata Interchange (XMI), or Unisys's Universal Repository (UREP) because their main purpose is the exchange of application development models (although both XMI and UREP have some relationship to XML). In this column I have discussed some of the more senior players on the XML semantics stage. However, a lot of the activity in the area now comes from newcomers such as ebXML, UDDI, and eCo, along with work by vertical industry groups. In the next column I'll take a look at the more practical aspects of these entrants.
Resources
About the author | 
| | Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management applications. Fourthought develops 4Suite, an open source platform for XML middleware. Mr. Ogbuji is a computer engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can reach him at uche@ogbuji.net. |
Rate this page
| |
