Business Semantic Interoperability – Part 1

The latest buzz phrase in the technology world is Interoperability, everyone wants it! The one of special interest to me is business semantic interoperability (BSI). Over the last 20 years lots of resources have been spend on a number of BSI solutions, mostly at the technical layer. Sadly the results have not achieve what was envisioned, nor were the real world interoperability problem ever addressed.

Let me start with the technical solutions which are all about creating a framework of interoperability at the interchange level. In this context, semantic interoperability addresses how to best facilitate the coding, transmission and use of meaning across systems and their services in the Information and Communication Technology (ICT) world.

There is no question that with the introduction of computers businesses and governmental organizations wanted to exchange business documents electronically to eliminate paper. However, since the introduction of EDI way back, the interoperability of electronic documents exchanged has been a huge challenge.

Since the early 1990’s many industry specific specifications were created to address that problem, but none rally were successful to solve it, especially cross industry interoperability. Data interoperability, not only in cross industry document exchanges,  is still handled by the mapping and/or data experts/consultants who understand the underlying business semantic meaning for each piece of information in order to define the mappings among different standardized documents.

In 1999 the ebXML initiative, sponsored by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS), was created to define a framework that uses XML globally for electronic transactions and networking. Part of the project was  the ebXML Core Components Project tasked to define a process, by which information components can be discovered, catalogued in sufficient detail and analyzed to identify which components are core components. It was envision that the creation of such a library would enable interoperability across industries that utilize electronic commerce. It was not until years after the conclusion of the ebXML project that UN/CEFACT completed the work on the ebXML Core Component Technical Specification (CCTS) which later was adopted by ISO as part of the ebXML set called ISO TS 15000.

OASIS (UBL), OAG, GS1 (formally EAN-UCC), SWIFT, UN/CEFACT, ASC X12, and a host of other organizations started to use the CCTS as the basis for building interoperable XML business standards.

Core components have unique identifiers and a neutral syntax that makes them interchangeable, machine readable, and independent of any vendor’s software or network. They not only include the identification of these interchangeable parts in business documents, but the systematic and consistent definition of the business context that gives the components their precise meaning in business documents. The systematic combination of core components with context allows for the automatic assembly of electronic business documents exchanged with trading partners.

There is no question that using core components provides a solid technical solution for electronic business messages to identify the underlying common data items, and to relate them to counterparts in other related business documents. In theory it should  also work across documents exchanged globally and cross-sectorial defined by different groups.

The critical issue is that if semantic data is interpreted differently, computerized collaboration is extremely limited. Assuming that message developers, globally and cross-sectorial, use the same standardized core component library (CCL), such as the UN/CEFACT CCL, would result in eliminating this issue. However, there is still the implementation phase, mapping the message content to user’s back-end system. And here is where the problem with with the current core component library (CCL) lies, trying to align the user’s domestic system into a one-size-fits-all approach.

Each core component’s name is based on a strict naming convention, outlined in the CCTS, resulting in a perfect technical name. Within the message development arena this is not a issue since most participants have either been part of the CCL community or have been using the CCL for sometime. However, implementers are using their own domain specific naming, which is in most cases very different from the perfect technical name. What is needed is a bridge between the standardized semantics and the domain specific everyday semantic. I will address this topic part 2. So stay tuned, there is more to come early next year.