Semantic mediation for standard-based B2B interoperability

Inte

rope

rabi

lity

52 Published by the IEEE Computer Society 1089-7801/10/$26.00 © 2010 IEEE IEEE INTERNET COMPUTING

E xisting business software applica-tions aren’t interoperable because they use proprietary data models

and message sets for business-to-busi-ness (B2B) communication. Industry consortia and standards development organizations (SDOs), such as the Auto-motive Industry Action Group (AIAG; www.aiag.org), have responded to this problem by publishing standard mes-sages for interoperable B2B data exchanges. Traditionally, this method unfolds at three levels:

• Business process and data modeling. An SDO defines a business process model and a conceptual model of the data being exchanged, which, in turn, support the development of

standard message schemas, called business object documents (BODs).

• BOD adoption and mapping. An industry consortium adopts or extends the BODs for industry- specific business processes. Appli-cation providers then interpret these BODs and define design-time map-pings between them and proprietary application interfaces.

• Runtime execution. Providers use the proprietary-to-BOD interface map-pings to implement message content transformations. These transforma-tions effectively implement standard- conformant message interfaces.

This approach has several shortcomings that impede standards adoption. First,

A semantic-mediation architecture advances traditional approaches for

standard-based business-to-business interoperability. The architecture formally

models a business domain in a reference ontology and annotates domain

message schemas to define public and proprietary reconciliation rule sets.

Enterprises can use the rule sets to implement standard-based message

interfaces and to translate message content between their proprietary message

forms. An implementation of the semantic-mediation architecture augments a

general applications-integration toolset developed for the Athena European FP

6 project. The implementation demonstrates the architecture’s feasibility and

suggests directions for future tool enhancements.

Marko Vujasinovic, Nenad Ivezic, Boonserm Kulvatunyou, and Edward BarkmeyerUS National Institute of Standards and Technology

Michele Missikoff and Francesco TaglinoConsiglio Nazionale delle Ricerche

Zoran Marjanovic and Igor MileticUniversity of Belgrade

Semantic Mediation for Standard-Based B2B Interoperability

JANUARY/FEBRUARY 2010 53

Semantic Mediation

specifying business domain concepts infor-mally (by using syntactic notations to convey data exchange requirements and their business meanings) leads to ambiguity and misinter-pretation.1 Second, informally annotating the meaning of the standard or proprietary-message elements in nonmachine-processable form leads to misinterpreted message semantics and appli-cation integration problems.2 Third, manual and hard-coded mappings between proprietary and standard message elements lead to error-prone and labor-intensive implementations.3 Finally, high interdependence between proprietary and standard message interfaces at many levels — execution platform, technology, terminol-ogy, message standard, and message syntax — implies inflexible, tightly coupled integrations.

To address these shortcomings, we propose a novel semantic-mediation architecture for standard- based interoperability. To demonstrate its feasibility, we describe a small-scale indus-trial message-exchange pilot implementation.

Semantic-Mediation ArchitectureOur proposed semantic-mediation architecture builds on the traditional approach but intro-duces new activities at each level, which we rename as follows:

• Business domain ontology modeling. An SDO captures the data exchange’s intended mean-ing and creates a reference ontology (the “create” activity in Figure 1) based on the business process model and data exchange requirements. The reference ontology speci-fies, formalizes, and explicates domain busi-ness concepts and their relationships; it’s publicly available to application providers.

• Design-time semantic-mediation specifi-cation. Following BOD adoption, the SDO annotates the BOD semantics (step B1 in Fig-ure 1) by relating each BOD element to the corresponding reference-ontology concept. The SDO then uses the BOD annotations to define publicly available reconciliation rule sets (step C1 in Figure 1) for transforming a BOD-conformant message to a reference-ontology instance, and vice versa. Appli-cation providers annotate the semantics of their proprietary-message interfaces (typi-cally XML schemas; step B2 in Figure 1) by using their respective interface annotations to define proprietary reconciliation rule sets

(step C2 in Figure 1). Effectively, the propri-etary and public rule sets define transfor-mations between proprietary messages and BOD- conformant messages via the refer-ence ontology.

• Runtime semantic-mediation execution. When an application sends a message, the semantic mediator executes the appropriate reconcilia-tion rule sets, first to translate the proprietary message to the reference-ontology instances and then to translate the reference-ontology instances to the BOD-conformant message. When an application receives a message, the semantic mediator translates from the BOD-conformant messages to the reference-ontology instance and then to the proprietary message. Effectively, the semantic mediator implements the standard-conformant mes-sage interface for the application.

Our proposed architecture addresses the traditional approach’s shortcomings through several advances. First, the reference ontology formally specifies business domain concepts, providing a basis for unambiguous interpre-tation of data exchange artifacts. Second, message schemas are annotated with the refer-ence ontology, providing machine-processable ex pressions that formally describe message ele-ments’ meaning; such annotation also enables precise specification of semantic reconciliation rules. The automated and consistent implemen-tation of a standard-based interface — enabled by executing the reconciliation rules — moves the engineering effort from implementation to modeling and design time. Finally, the archi-tecture reconciles terminological, structural, semantic, and representational differences between message specifications.

Ultimately, our semantic-mediation architec-ture achieves standard-based interoperability in three steps: reference-ontology devel opment, semantic annotation of message elements, and definition of reconciliation rules. The total effort is distributed between application providers and the SDO. Initially, the SDO creates the ontology, annotates the BODs, and defines reconciliation for BOD-conformant messages; it must perform these tasks only once. To implement an applica-tion’s standard- conformant message interface, each provider annotates its proprietary- message interface using the reference ontology, defines reconciliation for its proprietary messages, and

Interoperability

54 www.computer.org/internet/ IEEE INTERNET COMPUTING

deploys the semantic mediator. The providers must do this once for each proprietary interface to a specific reference ontology. Obviously, the scale of effort will depend on the complexity of the proprietary messages and the ontology. (The SDO and providers transform their respective standard and proprietary-message schemas into tool-specific forms when annotation or recon-ciliation tools require it — steps A1 and A2 in Figure 1.)

Supporting ToolsWe implemented our proposed architecture using the Athena (Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications) tool suite that was developed as part of an FP 6 Euro-pean Integrated Project.4 The Athena tools sup-

port semantics-based reconciliation of Resource Description Framework (RDF) documents (see Figure 1).

At design time, our architecture uses three Athena tools:

• Athos ontology-development tool (http://leks-pub.iasi.cnr.it/Athos). Athos relies on the Object-Model-Actor Language (Opal)5 to construct ontologies through predefined business categories and inherent constraints. Opal is built on top of the Web Ontology Language (OWL), which gives a formal basis to Athos-developed ontologies.

• Astar semantic-annotation tool (http://leks-pub.iasi.cnr.it/Astar). Astar lets us set up semantic correspondences (that is, semantic annotation expressions) between

Proprietarytool

Standard-conformantapplication

Standard XML message

Athenatool

Semantic elementrepository

ApplicationPrivatearea

Publicarea

Artifact

Annotate

Argos Argos

Astar

Data �ow

Application provider effort Standards development group effort

XSD2RDFStransformation XSD2RDFS

transformationRDFS modelRDFS model

Ares

Coordinatorgateway

Coordinatorwork�ow engine

XML2RDF RDF2XML

JohnsonWS engine

Orchestrate

Step

Standard-basedruntime data

exchange

Ontology modeling

Interface modeling(standard)

Semanticannotations

B2

Proprietaryreconciliation

rules

Standardreconciliation

rules

ProprietaryXML message

Proprietary XML schema

Semanticannotations

Reference ontology(business concepts and relationships) AthosCreate

Astar

A1

De�ne reconciliationC1

De�ne reconciliationC2

B2

A2

AnnotateB1

RDF message

BOD RDF message

Internet

WS call

Standard XML schemaBOD

Interface modeling(proprietary)

Reference-ontology

RDF

Business objectdocument (BOD)

RDFS model

Run

time

sem

antic

med

iatio

nD

esig

n-tim

ese

man

tic-m

edia

tion

spec

i�ca

tion

Figure 1. Semantic-mediation architecture for standard-based interoperability. Interface-standard and message-exchange efforts are distributed between application providers and standards development organizations, moving implementation to modeling and design time.


Semantic Mediation

RDF Schema (RDFS) model concepts and reference- ontology concepts. It provides a graphical annotation environment, RDFS model visualization, and semiautomatic sup-port for defining annotation expressions.

• Argos reconciliation-specification tool (http://leks-pub.iasi.cnr.it/Sinergia_Athos). Argos pro-vides a graphical environment for specify-ing reconciliation rules. It visualizes RDFS models and the reference ontology and assists in creating forward and backward reconciliation rule sets that transform RDF documents, respectively, to and from a reference- ontology instance. Astar anno-tation expressions drive the reconciliation rules creation in Argos.

At runtime, our proposed architecture supports Web services (WS) messaging through the Ares reconciliation execution engine and the John-son WS execution engine.6 Ares performs the actual RDF-to-RDF document reconciliation by executing declared forward and backward rule sets on RDF documents.

The Athena tool requirements for supporting general applications integration were similar to our B2B integration requirements. However, specific characteristics of the B2B integration revealed a need for additional support. First, to enable semantic mediation of XML messages, we built

• XSD2RDFS,7 a design-time tool that trans-forms message-element XML schema defini-tions (XSD) to the corresponding conceptual RDFS model (that is, to a conceptual mes-sage model), and

• XML2RDF and RDF2XML,7 runtime tools that transform XML messages to and from the corresponding RDF documents.

Second, to integrate the runtime tools, we developed the coordinator gateway, which orchestrates all runtime support for transform-ing a proprietary message into a standard- conformant message.

eKanban Experimental Pilot ImplementationTo assess our architecture’s representational capabilities, we executed an experimental pilot project.8 We based the pilot implementation on the electronic Kanban (eKanban) inventory vis-

ibility and interoperability (IV&I) business pro-cess that AIAG developed to regulate the flow of goods from suppliers to match actual customer usage. AIAG defined a standard BOD message set for the eKanban process, which we used in our project.

We employed two independently developed applications that could send and receive only their proprietary AuthorizeKanban messages and one standard-conformant application that could receive the standard BOD AuthorizeKanban message:

• The Apolon open source IV&I application with an RDFS-based proprietary-message interface.9

• A General Motors (GM) experimental appli-cation with an XML Schema-based proprie-tary-message interface.

• The Ford Test Harness (FTH) with an XML Schema-based BOD-conformant message interface.

We adopted the following scenario: Apolon (running in Serbia) exchanges a message with the FTH (running in Maryland), and the GM application (running in Michigan) exchanges a message with the FTH and Apolon.

First, we used the Athos tool to develop the eKanban Reference Ontology,10 which formally captured the business conceptual model for the eKanban process. Next, we performed the design-time steps. We completed the XSD2RDFS transformation of the BOD and GM AuthorizeKanban XML schemas to the corresponding RDFS conceptual message models (steps A1 and A2 in Figure 1), as required by Athena tooling. Then we used Astar to annotate the BOD, GM, and Apolon AuthorizeKanban RDFS conceptual message models (steps B1 and B2 in Figure 1). We used Argos to complete the reconciliation speci-fication (steps C1 and C2 in Figure 1), creating forward rules to transform data from the GM, Apolon, and BOD AuthorizeKanban RDF docu-ments into the reference-ontology instances, and backward rules into transform data from reference-ontology instances to Apolon and BOD AuthorizeKanban RDF documents.

At runtime, the coordinator gateway orches-trated a sequence of transformations and reconciliations, as shown in Figure 2. Each application had its own appropriately config-ured coordinator gateway. The semantic media-tion was successful — that is, applications sent

Interoperability


and received messages in their proprietary for-mats and, moreover, conformed to the adopted exchange standard.

We give details for the integration steps from a provider’s perspective, along with exam-ple annotation expressions, reconciliation rules, and implementation details elsewhere.8 Here we concentrate on key architectural and functional challenges in the pilot and recommendations for future tool enhancements.

Key Implementation FindingsThree functions are central to successful use of our proposed architecture in realistically complex B2B integration cases: message- representation transformation, message- semantics annotation, and message-reconciliation specification.

Message-Representation TransformationThe semantic-mediation tools require trans-formation of a message schema or message instance — typically to a form that’s aligned with the ontology representation language. A key challenge in the message-representation transformation is to develop a general and flex-ible solution that abstracts from the unneces-sary message syntax details while maintaining the essential schema or instance information.

Approach. We designed the XSD2RDFS, XML-2RDF, and RDF2XML message-representation transformations to meet the Astar and Argos tool requirements — specifically, requirements for a message-schema abstraction in the form of an RDFS conceptual message model and for messages in the form of RDF documents.

To transform an XML message schema to an RDFS conceptual message model, XSD2RDFS builds an internal tree that reflects the XML message structure. Tree nodes represent XML element and attribute definitions, and each node encapsulates the name, data type, and namespace for the corresponding element or attribute. The tool then transforms the tree into an RDFS conceptual message model through pre-defined transformation rules and the “extended names” naming convention.7 Figure 3 shows sample XSD2RDFS transformation. It trans-forms xsd:elements into corresponding RDFS classes — for example, gmSyncShipmentSchedule is transformed to gmSyncShipmentSchedule_sender. Also, each simple xsd:element is transformed into a corresponding RDFS data property — for example, the DUNS element is transformed into gmSyncShipmentSchedule_sender_DUNS_sValue. Each XML parent-child relation is transformed into an RDFS object

Scenario

GM sendsto

Apolon

(continuedfrom above)

Apolonsends to

FTH

GMsends to

FTH

GM General MotorsFTH Ford Test HarnessBOD Business object documentRO Reference ontology

Message

XMLGM

StandardXMLBOD

RDFApolon

XMLGM

Message

RDFGM

RDFBOD

RDFApolon

RDFGM

Reconciledmessage

in ontology(RO) form

RDFRO

RDFRO

RDFRO

RDFRO

Reconciliation

BODBackward

ApolonBackward

BODBackward

BOD_Backward

Reconciliation

GMForward

BODForward

ApolonForward

GMForward

Message

RDFBOD

RDFApolon

RDFBOD

RDFBOD

Output

RDF2XML

not needed

RDF2XML BOD

RDF2XML

Input(relative to RO)

messagetransformation

XML2RDF

XML2RDF

not needed

XML2RDF

Message

StandardXMLBOD

RDFApolon

Standard XML

StandardXMLBOD

Figure 2. Message flow and executed transformation inside the coordinator gateway. Blue font indicates the sender and the messages sent. Red font indicates the receiver and the messages received. Black font indicates the intermediate transformations and data formats.


Semantic Mediation

property — the sender-DUNS parent-child XML relation becomes the gmSyncShipmentSchedule_sender_DUNS_PROP RDFS property.

Even though specific Astar and Argos requirements drive XSD2RDFS’s functionality, the tool is general. It can transform any given XML schema into a corresponding RDFS con-ceptual message model.

For the runtime message-representation transformations, we defined the XML2RDF and RDF2XML transformation-naming convention.7

The transformation algorithms use this conven-tion to create RDFS-conformant RDF documents for the reconciliation input and XML schema-conformant XML documents from the reconcili-ation output. This approach makes the RDF2XML and XML2RDF transformations flexible enough to eliminate the need for runtime presence of the corresponding XML schema and RDFS con-ceptual message model. Figure 4 shows sample XML2RDF and RDF2XML transformations.

Findings. Our pilot implementation uncovered the need to preserve message-structure and

message-representation rules (originally spec-ified in the message schema) in order to trans form RDF documents to XML schema- conformant XML messages. Particularly, to pro-duce an XML schema-conformant message from reconciliation output, you must maintain defi-nitions for at least the following information:

• message structure,• message concept granularity (element versus

attribute),• message concept names including name spaces,• message concepts’ order, and • formatting rules.

A conceptual message model doesn’t cap-ture this information. However, we were able to maintain it, first, by embedding the struc-tural and granularity characteristics in naming conventions. For example, the extended-name convention for concepts maintained the mes-sage-structure definition and the elements ver-sus attributes distinction with the _ATTR suffix. Second, we created reconciliation rules to gen-

<?xml version="1.0" encoding="UTF-8"?><xsd:schema xmlns:tns="http://gm.com/gmSyncShipmentSchedule/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="gmSyncShipmentSchedule" targetNamespace= "http://gm.com/gmSyncShipmentSchedule/">

<xsd:element name="gmSyncShipmentSchedule"> <xsd:complexType> <xsd:sequence> … <xsd:element name="sender“ type="tns:partner"/> …. </xsd:sequence> </xsd:complexType> </xsd:element>

<xsd:complexType name="partner"> <xsd:sequence> <xsd:element name="DUNS" type="xsd:string"/> </xsd:sequence> </xsd:complexType> …..</xsd:schema>

<rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"xmlns="http://gm.com/gmSyncShipmentSchedule/rdfs"xmlns:xsd="http://www.w3.org/2001/XMLSchema#">

<rdfs:Class rdf:about="http://gmSyncShipmentSchedule/rdfs#gmSyncShipmentSchedule"></rdfs:Class>...<rdfs:Class rdf:about="http://gm.com/gmSyncShipmentSchedule/rdfs#gmSyncShipmentSchedule_sender"></rdfs:Class><rdfs:Class rdf:about=" http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender_DUNS"></rdfs:Class> ....<rdf:Property rdf:about=" http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender_DUNS_sValue"> <rdfs:domain rdf:resource= http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender_DUNS"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/></rdf:Property>...<rdf:Property rdf:about=" http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender_PROP"> <rdfs:domain rdf:resource=" http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule"/> <rdfs:range rdf:resource="http:// http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender"/></rdf:Property><rdf:Property rdf:about=" http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender_DUNS_PROP"> <rdfs:domain rdf:resource=" http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender"/> <rdfs:range rdf:resource=" http://gm.com/gmSyncShipmentSchedule /rdfs#gmSyncShipmentSchedule_sender_DUNS"/></rdf:Property>...</rdf:RDF>

XSD2RDFS

Figure 3. Portion of the XSD2RDFS transformation for the General Motors (GM) schema. All xsd:elements transform to a corresponding RDFS class, each simple xsd:element transforms to a corresponding RDFS data property, and each XML parent-child relation transforms to an RDFS object property.

Interoperability


erate additional target-RDF-document state-ments to carry the XML-message-representation rules through the entire semantic mediation. For example, additional RDF statements carried the namespace and element order definitions.

Creating additional reconciliation rules required undesired effort on behalf of a rule expert and additional knowledge about mes-sage representation and formatting rules, beyond understanding the message structure and semantics. Neither our approach nor other similar transformation approaches (surveyed elsewhere7) can transform message schemas to a form that sufficiently captures the five mini-mum schema definitions listed earlier while aligning with an ontology representation lan-guage, such as OWL or RDFS. (Also, see the sidebar for more information on related work in semantic mediation.)

Future direction: abstract message model. To rectify this behavior and, furthermore, to medi-ate messages other than those in XML syntax, such as messages in Electronic Data Interchange (EDI) syntax, we believe that a semantic media-tion needs an abstract message model that, when instantiated, represents a syntax-neutral model of both the schema and the message of some concrete syntax.

An abstract message model doesn’t capture certain syntax-specific constructs of message schemas or messages. However, it faithfully captures message-schema concepts, such as element and attribute definitions, complex ver-sus simple type definitions, and the mandatory

message schema information we listed under “Findings.” It also captures message concepts such as elements, attributes, content, and val-ues. These capabilities will allow the message-representation transformation to instantiate and populate the abstract message model with information from an actual message schema or message. This approach further implies that the forward reconciliation must come from — and the backward reconciliation go to — the abstract message model instance (for example, GM and BOD abstract message model instances). The abstract message model instance, as an output from a reconciliation engine, will then contain enough information for the specific message-representation transformation to produce the schema-conformant message from it.

Message-Semantics AnnotationTo clarify message semantics, the message-semantics annotation activity associates each message element definition with a machine-processable expression that represents its busi-ness meaning in terms of reference- ontology concepts. The significant challenge is to have an annotation method that reduces human effort, detects semantic correspondences, provides suf-ficient expressivity, and allows multipurpose usability of semantic annotation expressions.

Approach. The Astar annotation method is orga-nized in two phases:

• The diagnostic phase identifies mismatches between a conceptual message model and

<?xml version="1.0" encoding="UTF-8"?> <gmSyncShipmentSchedule xmlns="http://gm.com/gmSyncShipmentSchedule/"> ... <sender> <DUNS>General Motors</DUNS> </sender> .. </gmSyncShipmentSchedule>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://gm.com/gmSyncShipmentSchedule/rdfs"> <gmSyncShipmentSchedule> ... <gmSyncShipmentSchedule_sender_PROP> <gmSyncShipmentSchedule_sender rdf:ID="X2"> <gmSyncShipmentSchedule_sender_DUNS_PROP> <gmSyncShipmentSchedule_sender_DUNS rdf:ID="X3"> <gmSyncShipmentSchedule_sender_DUNS_sValue rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> General Motors </gmSyncShipmentSchedule_sender_DUNS_sValue> </gmSyncShipmentSchedule_sender_DUNS> </gmSyncShipmentSchedule_sender_DUNS_PROP> </gmSyncShipmentSchedule_sender> </gmSyncShipmentSchedule_sender_PROP> .... </gmSyncShipmentSchedule></rdf:RDF>

XSD2RDFS

RDF2XML

Figure 4. Portion of the XML2RDF and RDF2XML transformation output for the General Motors message. XML2RDF transforms its output (GM’s XML message on the left) to the RDF document that contains GM’s message data on the right. RDF2XML makes the opposite tranformation.


Semantic Mediation

the reference ontology. These include ter-minological mismatches, such as different terms labeling the same concepts; structural mismatches, such as different structural relationships among concepts; and semantic mismatches, such as the generalization and specialization of concepts.

• The remedial phase associates the concep-tual message-model concepts with expres-sions representing their semantics in terms of the reference ontology.

The remedial phase has four steps: terminologi-

cal semantic annotation (TSA), path semantic annotation (PSA), simple semantic annotation (SSA), and full semantic annotation (FSA):

• TSA step. Astar contrasts the terms of the conceptual message-model concepts with the reference-ontology terminology and auto-matically detects lexical-terminological simi-larities among them. The user then manually establishes correspondences between the terms, which resolves mismatches and assists the identification of structural path matches in the PSA.

Related Work in Semantic Mediation

Researchers have explored and demonstrated several dif-ferent architectural models for semantic mediation.1

Nenad Anicic and his colleagues demonstrated an any-to-any mapping model, in which local OWL ontologies (that is, OWL conceptual message models) are merged and source ontology individuals classified and transformed into target ontology individuals by automated reasoners.2 The Artemis message-exchange framework uses the OWLmt ontology mapping tool (http://sourceforge.net/projects/owlmt) to dem-onstrate crosswise mappings among local OWL ontologies.3

The any-to-any model employs no reference ontology as the mediation point. For this reason, when the semantic medi-ation involves many local ontologies, this model increases the number of crosswise mappings or the merged ontology’s size and complexity. On the other hand, an architectural model that employs a reference ontology as the central mapping point — the any-to-one mapping model — reduces the number of mappings.

The European Harmonise project demonstrated an any-to-one mapping model, developed a reference Tourism RDFS Ontology, and used RDF as an interchange format.4 Harmonise used the Mafra toolkit (http://sourceforge.net/projects/mafra -toolkit) for mappings between RDFS ontologies. Yu Ye and his colleagues at Shanghai Jiao Tong University developed a similar semantic-mediation architecture for supply-chain applications.5 Their architecture introduced a general supply-chain ontology (SCO) and used the Semantic Web Rule Language for mappings between the SCO and local ontologies.6

Our work leans on the Automated Methods for Integrated Systems (AMIS) project, which also discussed an any-to-one mapping model for semantic mediation.7 We applied the AMIS model to address the lack of formal and machine-processable message semantics in schemas and to correct time-consuming and error-prone practice of hard-coding mappings between proprietary and standard interfaces.

Besides the Athena toolset, other tools that application integrators could use in our proposed architecture include

Protege (http://protege.stanford.edu) for ontology develop-ment and Mafra, OWLmt, or Snoggle (http://snoggle.projects. semwebcentral.org) for specifying mappings. Tools for message semantics annotation are missing. SAWSDL (Semantic Anno-tations for WSDL and XML Schema) is an emerging standard that defines a set of extensional attributes by which seman-tic annotations can be added to Web service description and XML schemas.7 However, no tools can yet generate mapping rules from SAWSDL annotations. So far, only Athena provides a design and runtime toolset to enable the proposed semantic mediation of XML messages.

Semantic Web services have also become a key technology for semantic integration of supply chains.8 Our work, however, is concerned with the semantic integration of supply-chain applications in traditional Web service environments.

References1. G. Vetere and M. Lenzerini, “Models for Semantic Interoperability in

Service-Oriented Architectures,” IBM Systems J., vol. 44, no. 4, 2005, pp.

887–903.

2. N. Anicic et al., “Semantic Enterprise Application Integration Standards,”

Int’l J. Manufacturing and Technology, vol. 10, nos. 2–3, 2007, pp. 205–226.

3. V. Bicer et al., “Artemis Message Exchange Framework: Semantic Interoper-

ability of Exchanged Messages in the Healthcare Domain,” SIGMOD Record,

vol. 34, no. 3, 2005, pp. 71–76.

4. M. Dell’Erbaa et al., “HARMONISE: A Solution for Data Interoperability,”

Proc. 2nd IFIP Conf. E-Commerce, E-Business, E-Government (I3E 02), Kluwer,

2002, pp. 114–127.

5. Y. Ye et al., “An Ontology-Based Architecture for Implementing Semantic

Integration of Supply-Chain Management,” Int’l J. Computer Integrated Manu-

facturing, vol. 21, no. 1, 2007, pp. 1–18.

6. D. Libes et al., “The AMIS Approach to Systems Integration,” NIST Inter-

agency/Internal Report 7101, May 2004.

7. J. Kopecký et al., “SAWSDL: Semantic Annotations for WSDL and XML

Schema,” IEEE Internet Computing, vol. 11, no. 6, 2007, pp. 60–6.7

8. S.A. McIlraith et al., “Semantic Web Services,” IEEE Intelligent Systems, vol.

16, no. 2, 2001, pp. 46–53.

Interoperability


• PSA step. To resolve structural mismatches, the user considers the conceptual message-model and reference-ontology structures and associates one or more conceptual message-model structural paths to one or more matching reference-ontology struc-tural paths.

• SSA step. The user composes all the path matches into path expressions by using abstract operators, which denote a data transformation template needed at runtime. The abstract operators can also note other semantic mismatches in this step, such as the different data encoding and data repre-sentation choices.

• FSA step. Path expressions are translated into OWL DL (description logics) semantic annotation expressions. OWL allows encod-ing of the actual relationships between the semantic concepts — for example, equiva-lence, subsumption, and overlap.

Table 1 shows an example of the mismatches and the four-step annotation for a portion of the GM conceptual message model.

Findings. Path matching required significant human effort because Astar a priori gener-ated and showed users all path combinations through the reference ontology graph. This led to overwhelming complexity in the annotation activity. A semantic-annotation tool should let users steer the path development rather than presenting a long list of all possible paths. Nev-ertheless, we used Astar successfully to anno-tate all the conceptual message models.

Astar uses OWL as an internal representa-tion language for semantic annotation expres-sions. However, OWL has shortcomings, such as interpretation-framework dependence, com-plexity, limited expressivity, and nonexecut-ability.11 Annotating message semantics needs an interchangeable, executable, expressive, but simple expression representation format.

Significantly, Astar doesn’t provide for semantics annotation of the actual (XML/EDI) message-schema components and message ele-ments — only annotation of conceptual mes-sage-model concepts and their properties. This directly affects the annotation usability in the reconciliation that generates message-schema-conformant messages. A message- representation transformation tool can’t engineer important

information about message element definitions, message structure, and data representation from conceptual message models. It also rules out the possible reuse of such annotations for other purposes, such as semantic querying over XML/EDI messages and discovery and reuse of schema components.

Future direction: semantics annotation through abstract message models. We need a novel annotation method that works with abstract message model instances (conformant with actual message schemas) rather than concep-tual message models. Annotations based on the abstract message model instances should improve our architecture’s reconciliation run-time capabilities and multipurpose usability of the annotation expressions. Furthermore, the annotation method must support reuse of anno-tation expressions on at least three levels.

The first is message component reuse. For example, annotation of context-specific aggre-gated message components, such as SenderParty and ReceiverParty (in Open Application Group BODs; www.oagi.org), requires the capa-bility to reuse annotation expressions of the message components’ base-element type defi-nitions (such as the PartyType base type) or of their base context-free aggregated elements’ definition (such as Party) along with the con-taining elements.

The second level is reuse across different but overlapping message types. The third is reuse of an entire annotation set for a message set.

Message-Reconciliation SpecificationTo specify message reconciliation, we must define the forward- or backward-executable message content transformation rules. Forward rules describe how to transform the content of one or more message elements into instances of reference-ontology concepts that match the content. Backward rules describe how to trans-form the content of one or more instances of the reference-ontology concepts to message ele-ments that match the content.

Several transformation patterns might exist, such as one-to-one, many-to-one, one-to-many, or more complex patterns including conversion functions. The significant challenge is to auto-mate rule generation.

Approach. Argos provides semiautomatic speci-


Semantic Mediation

fication of reconciliation rules based on seman-tic annotation expressions. A user manually selects and instantiates an appropriate pre-defined rule template for one or more concep-tual message-model paths leading to the content to be transformed or populated. Argos rule tem-plates include one-to-one, one-to-many, and many-to-one maps, as well as sum, set value, and conversion functions. The tool then cre-ates a declarative runtime rule by substituting

the conceptual message- model path (or paths) and the matching reference-ontology path (or paths) into the template, based on the annota-tion expressions.

Argos uses Jena as an executable rule repre-sentation language (http://jena.sourceforge.net). Figure 5 shows a Jena rule that specifies a one-to-one mapping between GM’s Sender.DUNS and the reference ontology’s senderParty.PartyId.identifier concepts.

Table 1. Portion of General Motor’s RDFS conceptual message-model annotation.

Terminological semantic annotation (TSA)

GM’s RDFS concept Mismatch Reference-ontology concept

gmSyncShipmentSchedule

naming

ShipmentSchedule, SyncShipmentSchedule_Message

gmSyncShipmentSchedule_sender SenderParty

gmSyncShipmentSchedule_sender_DUNS PartyId

gmSyncShipmentSchedule_sender_PROP relTo_SyncShipmentSchedule_Message_SenderParty

gmSyncShipmentSchedule_sender_DUNS_PROP relTo_SyncShipmentSchedule_Message_ SenderParty_PartyId

gmSyncShipmentSchedule_sender_DUNS_sValue has_identifier

Path semantic annotation (PSA)

GM’s RDFS path Mismatch Reference-ontology path

gmSyncShipmentSchedule.gmSyncShipmentSchedule_sender_PROP.

gmSyncShipmentSchedule_sender.gmSyncShipmentSchedule_sender_DUNS_PROP.gmSyncShipmentSchedule_sender_DUNS.gmSyncShipmentSchedule_sender_DUNS_ sValue:STRING

structuring

ShipmentSchedule.relTo_ShipmentSchedule_message_SyncShipment Schedule. SyncShipmentSchedule_Message.relTo_SyncShipmentSchedule_Message_SenderParty.SenderParty.relTo_SyncShipmentSchedule_Message_SenderParty _PartyId.PartyId.has_identified:STRING

Simple semantic annotation (SSA)

GM’s RDFS path Abstract operator Reference-ontology path

gmSyncShipmentSchedule.gmSyncShipmentSchedule_sender_PROP.

gmSyncShipmentSchedule_sender.gmSyncShipmentSchedule_sender_DUNS_PROP. gmSyncShipmentSchedule_sender_DUNS.gmSyncShipmentSchedule_sender_DUNS_ sValue:STRING

=

ShipmentSchedule.relTo_ShipmentSchedule_message_ SyncShipmentSchedule. SyncShipmentSchedule_Message.relTo_SyncShipmentSchedule_Message_SenderParty.SenderParty.relTo_SyncShipmentSchedule_Message_ SenderParty_PartyId.PartyId.has_identified:STRING

Full semantic annotation (FSA) - Web Ontology Language Description Logics (OWL DL) semantic annotation expressions

GM’s RDFS path in DL OWL axiom Reference-ontology path in DL

STRING ∩(∃ inverseOf_gmSyncShipmentSchedule_ sender_DUNS.(gmSyncShipmentSchedule_ sender_DUNS ∩(∃ inverseOf_ gmSyncShipmentSchedule_sender_ DUNS_PROP.(gmSyncShipmentSchedule_sender ∩(∃ inverseOf_gmSyncShipmentSchedule_sender_ PROP(gmSyncShipmentSchedule))))))

owl:equivalentClass

STRING ∩ (∃ inverseOf_has_Id_identified.(PartyId ∩ (∃ inverseOf_ relTo_SyncShipmentSchedule_ Message_SenderParty_PartyId.(SenderParty ∩(∃ inverseOf_relTo_SyncShipmentSchedule_Message _SenderParty.(SyncShipmentSchedule_Message ∩(∃ inverseOf_relTo_ShipmentSchedule message_SyncShipmentSchedule (ShipmentSchedule))))))))

Interoperability


Findings. Although Argos is a semiautomatic tool, we instantiated all rules manually. Argos could have automated this process if it had fully used annotation expressions and abstract oper-ators as mapping directives. In fact, the instan-tiations of the one-to-one map template could be completely automated, which would have reduced the time needed for reconciliation spec-ification because 85 percent of the pilot rules were one-to-one maps.

Despite that unnecessary manual effort, we used Argos successfully to create all the required reconciliation rules.

Future approach: automated reconciliation. We need a reconciliation rules generator that fully uses the semantic annotation expressions to derive most reconciliation rules automatically. This means the semantic annotation tool must capture nontrivial semantic correspondences, such as value-to-value map tables, conversions, and default values. Special cases, such as com-plex conversion functions, might still require an application expert, but they will come up only a fraction of the time.

O ur approach moves syntactic, informal spec-ification of business intent to formal, seman-

tic-based specification. Several implementation tasks associated with standards compliance therefore move to a model-based approach, which makes actual implementation much more straightforward.

The experimental scenario we report here

was small-scale, involving three participants, but it involved a real standard-based message exchange. Thus, the AuthorizeKanban BOD annotation and reconciliation requirements we present would appear in large-scale sce-narios, too. Our pilot showed that most map-pings between elements of either actual BOD or proprietary-message interfaces and reference-ontology concepts were one-to-one (86, 92, and 96 percent, respectively, of BOD, GM, and Apo-lon rules). One-to-one maps are simple and easy to establish, and would represent most business participants’ mappings to the reference ontol-ogy in a real industrial case. Nevertheless, in any mapping case, the reconciliation specifi-cation shouldn’t require a large annotation or rule engineering effort if the supporting toolset is optimized to realistically handle industrial B2B messaging solutions, such as XML sche-mas or EDI.

The Athena toolset supported our pilot sce-nario, but the current Semantic Web technolo-gies for semantic data management need new tools that are engineered for realistic integration requirements and can take advantage of these technologies. Our pilot study findings are the basis for ongoing work in developing an abstract message model, semantic annotation based on that model, automated reconciliation support, and new supporting tooling. These tools could largely eliminate problems in handling realisti-cally complex integration artifacts.

DisclaimerThis article identifies certain commercial and open source

software products. We used these products only for dem-

onstration purposes. This use doesn’t imply approval or

endorsement by the US National Institute of Standards and

Technology, nor does it imply that these products are nec-

essarily the best available for the purpose.

References1. P. Snack, “Standards-Based Interoperability: The Road

Ahead,” AIAG Actionline, July/Aug. 2007, pp. 21–29.

2. J. Heflin and J. Hendler, “Semantic Interoperability on

the Web,” Proc. Extreme Markup Languages, Graphics

Communications Assoc., 2000, pp. 111–120.

3. S. Decker et al., “The Semantic Web: The Roles of XML

and RDF,” IEEE Internet Computing, vol. 15, no. 3,

2000, pp. 63–74.

4. A.-J. Berre et al., “The Athena Interoperability Frame-

work,” Enterprise Interoperability II, pt. VI, Springer,

2007, pp. 569–680.

[rule:(?x rdf:type a:gmSyncShipmentSchedule) (?x a:gmSyncShipmentSchedule_sender_PROP ?y) (?y rdf:type a:gmSyncShipmentSchedule_sender) (?y a:gmSyncShipmentSchedule_sender_DUNS_PROP ?z) (?z rdf:type a:gmSyncShipmentSchedule_sender_DUNS) (?z a:gmSyncShipmentSchedule_sender_DUNS_PROP ?t) (?t rdf:type a:gmSyncShipmentSchedule_sender_DUNS) (?t a:gmSyncShipmentSchedule_sender_DUNS_sValue ?value) -> (?x rdf:type refOnt:ShipmentSchedule) (?x refOnt:relTo_ShipmentSchedule_message_SyncShipmentSchedule ?y) (?y rdf:type refOnt:SyncShipmentSchedule_Message) (?y refOnt:relTo_SyncShipmentSchedule_Message_SenderParty ?z) (?z rdf:type refOnt:SenderParty) (?z refOnt:relTo_SyncShipmentSchedule_Message_SenderParty_PartyId ?t) (?t ref:type refOnt:PartyId) (?t refOnt:has_identified ?value)

Figure 5. Jena example of a one-to-one map rule. Argos uses Jena for operational transformation of message content from RDF documents into instances of the reference-ontology concepts, and vice versa. GM’s Sender.DUNS concept maps to and its literal value transforms to the reference ontology’s senderParty.PartyId.identifier concept and instance, respectively.


Semantic Mediation

5. F. D’Antonio et al., “Formalizing the OPAL eBusiness

Ontology Design Patterns with OWL,” Enterprise

Interoperability II, pt. IV, Springer, 2007, pp. 345–357.

6. E. Coscia et al., “A Reconciliation and Mediation

Engine, Capable to Efficiently Process Semantic Media-

tion and Reconciliation Rules,” ATHENA Integrated

Project, internal deliverable D.A3.5, 2006.

7. I. Miletic et al., “Enabling Semantic-Mediation for

Business Applications: XML-RDF, RDF-XML, and

XSD-RDFS Transformation,” Enterprise Interoperabil-

ity II, pt. V, Springer, 2007, pp. 483–494.

8. M. Vujasinovic et al., “A Semantic-Mediation Architec-

ture for Interoperable Supply-Chain Applications,” Int’l

J. Computer Integrated Manufacturing, vol. 22, no. 6,

2008, pp. 549–561.

9. I. Novicic et al., “A Case Study in Business Application

Development Using Open Source and Semantic Web

Technologies,” Enterprise Interoperability II, pt. VIII,

Springer, 2007, pp. 721–724.

10. E. Barkmeyer and B. Kulvatunyou, “An Ontology for

the e-Kanban Business Process,” NIST Interagency/

Internal Report 7404, June 2007.

11. J. Euzenat and P. Shvaiko, Ontology Matching, Springer,

2007.

Marko Vujasinovic is a PhD candidate in the University of

Belgrade’s Department of Information Systems, Fac-

ulty of Organizational Sciences (FOS). He’s also a guest

researcher at the US National Institute of Standards

and Technology’s Manufacturing Systems Integration

Division. His research interests include business-to-

business systems integration, semantic interoperabil-

ity, and Semantic Web technologies. Vujasinovic has

an MSc in information systems from FOS. Contact him

at [email protected].

Nenad Ivezic is a research staff member of the Enterprise

Systems Group at the US National Institute of Stan-

dards and Technology’s Manufacturing Engineering

Laboratory. His research interests include integration

and testing of business-to-business systems, semantic

technologies, and standards development for interop-

erability. Ivezic has a PhD in computer-aided engineer-

ing from Carnegie Mellon University. Contact him at

[email protected].

Boonserm Kulvatunyou is a standards and product archi-

tect in Oracle’s Adaptive Business Solutions division.

His research interests are enterprise data models for

interoperable service-oriented architecture. Kulvatu-

nyou has a PhD in industrial engineering from Penn-

sylvania State University. Contact him at kbserm@

psualum.com.

Edward Barkmeyer is a senior computer scientist at the

US National Institute of Standards and Technology’s

Manufacturing Engineering Laboratory. His research

interests include the analysis and architecture of

information interchange among manufacturing soft-

ware systems for engineering, planning, control, and

supply-chain operations. Barkmeyer has an MS in

applied mathematics from the University of Maryland.

Contact him at [email protected].

Michele Missikoff is a professor at the University of

Rome La Sapienza and research director of the Italian

National Research Council, where he manages the Lab

for Enterprise Knowledge and Systems. He’s also the

scientific director of the European Interop-VLab. His

research interests are in knowledge bases, knowledge

representation, and semantic technologies with a focus

on ontologies for interoperability in e-government

and e-business. Missikoff has a Laurea in physics

from University of Rome La Sapienza. Contact him at

[email protected].

Francesco Taglino is a researcher at the Italian National

Research Council’s Lab for Enterprise Knowledge

and Systems. His research interests include semantic

interoperability and ontology management systems.

Taglino graduated information science from the Uni-

versity of Rome La Sapienza. Contact him at francesco.

[email protected].

Zoran Marjanovic is a full professor in the University of


ulty of Organizational Sciences (FOS), and a president

of Breza Software Engineering. His research interests

are IS development methodologies, databases, semantic

enterprise application interoperability, and informa-

tion systems development. Marjanovic has a PhD in

information systems from the University of Belgrade.

He’s a member of the ACM and the IEEE. Contact him

at [email protected].

Igor Miletic is a postgraduate student in the University of


ulty of Organizational Sciences (FOS). His research

interests are the development and integration of

business applications systems, Semantic Web tech-

nologies, and applying Semantic Web concepts to

business applications. Contact him at igor.miletic@

brezasoftware.com.

Selected CS articles and columns are also available

for free at http://ComputingNow.computer.org.

Documents

Semantic mediation for standard-based B2B interoperability