Adding Semantics to RosettaNet Specifications

Paavo Kotinurmi

Helsinki University of Technology
Helsinki, Finland

Tomas Vitvar

Digital Enterprise Research Institute
Galway, Ireland


The use of Semantic Web Service (SWS) technologies have been suggested to enable more dynamic B2B integration of heterogeneous systems and partners. We present how we add semantics to RosettaNet specifications to enable the WSMX SWS environment to automate mediation of messages. The benefits of applying SWS technologies include flexibility in accepting heterogeneity in B2B integrations.

Categories & Subject Descriptors

K.4.4 [Electronic Commerce]: Electronic data interchange

General Terms

Management, Design.


RosettaNet, ontologysing, XML, B2B integration


RosettaNet ( is one widely used XML-based e-business framework. Due to the flexibility in RosettaNet regarding e.g message details means that considerable effort is required to ensure the B2B integration details match [5]. Therefore, B2B integrations suffer from long setup times and high costs.

SemanticWeb Services (SWS) have been proposed to achieve more dynamic partnerships [1]. The SWS approach based on e.g. OWL-S [4] orWeb Service Modeling Ontology (WSMO) [6] enables annotation of the B2B integration interfaces with semantic information. This allows automatic or semi-automated mediation. In addition, SWS enables powerful discovery, composition, and selection capabilities of services.

RosettaNet is widely used in B2B integration, but it is not yet based on SWS technologies. We believe that SWS technologies are introduced stepwise to integration rather than in a big bang. So to support integration we want to use SWS with the current RosettaNet. This SWS solution proposal is based on the Web Service Modelling eXecution environment (WSMX) [3]. WSMX is a reference implementation of WSMO and operates on the Web Service Modeling Language (WSML) [2]. In this paper, we concentrate on how we lift existing RosettaNet information to WSML and discuss its expected benefits. We further position our approach to other related work.


RosettaNet defines Partner Interface Process (PIP) messages using either DTDs and additional message guidelines or XML Schemas. WSMX operates only onWSML language and therefor translating XML used in RosettaNet from/to WSML is needed.

Domain ontologies are needed for the RosettaNet PIP messages used. We call this ontologising. Specific tools can be used to allow semi-automated translation e.g. from XML Schemas to WSML, but it also requires an expert who understands RosettaNet and the capabilities of ontology languages to be able to capture information in messages semantically.

As an example of ontologising, the RosettaNet Partner Interface Process (PIP) 3A1 supports two different kinds of product identifiers. Global Trade Identification Number (GTIN) is recommended by RosettaNet for product identifiers, but also the use of company-specific identifiers is allowed. The extract in listing 1 shows the definition of product identifiers in the PIP 3A1.

<!ELEMENT ProductIdentification
(GlobalProductIdentifier?, PartnerProductIdentification )>
<!ELEMENT GlobalProductIdentifier(#PCDATA)>
<!ELEMENT PartnerProductIdentification
(GlobalPartnerClassificationCode, ProprietaryProductIdentifier,
<!ELEMENT ProprietaryProductIdentifier (#PCDATA)> 

Listing 1: PIP 3A1 DTD extract

RosettaNet message guidelines for PIP 3A1 contain a natural language constraint for ProductIdentification that the DTD's expressive power does not capture: Constraint: One instance of either "GlobalProductIdentifier" or "PartnerProductIdentification" is mandatory. Without this constraint, a valid ProductIdentification could be without any identifiers as both identifications are optional. There are newer XML Schema based PIPs, e.g. 3A4, which contain the same information and can express the cardinality constraint. However, XML Schema uses different element names to the ones in DTDs as shown in listing 2.

<xs:choice><xs:element ref="ulc:AlternativeIdentifier" maxOccurs="
<xs:element ref="udt:GTIN"></xs:element></xs:choice>

Listing 2: PIP 3A4 XML Schema extract

The product identifier information in WSML is presented in listing 3. Here the GTIN is handled as any other identification qualifier (qualificationAgency) and thus both the RosettaNet DTD and XML can be represented in the ontology including the cardinality constraints. The qualification agency can be e.g. buyer's, seller's or manufacturer's identifier or some other identification scheme used. This qualification agency reflects the way that other standards, such as EDI X12, address product identifiers making it easier to use the same product ontology in other B2B integrations. The axiom in listing makes sure that the value of qualificationAgency is among the known.

concept productIdentification
		dc#description hasValue "The collection of business properties
that describe identifier information regarding products."
	productIdentifier ofType (1 1) string
	qualificationAgency ofType (1 1) string
axiom qualificationAgencyConstraint
		dc#description hasValue "The valid list of agencies who have
defined product identifiers. Can be companies or name of
global idenfitifications e.g. EN=European Article Number (
	definedBy !− ?x[qualificationAgency hasValue ?type]
	and (?type = "GTIN" or ?type = "Manufacturer"
	or ?type = "Buyer" or ?type = "EN").

Listing 3: Product ontology extract in WSML

The mapping rules should be defined for run-time mediation of ontologies. By knowing that a GTIN identifier and company specific identifiers point to the same product, the mediation can perform the required transformation to an identifier understood by the given partner. Finding the mappings is facilitated by the data mediation tool included in the Web Services Modeling Toolkit (


As WSML is more expressive language than the schema languages used currently, the lifting of PIPs to ontologies can contain more information. As a simple example, we provided the mapping of product information to ontologies that captured also current natural language constraints. The use of formal ontologies enables using common conversion functions to mediate some differences with logical dependencies. RosettaNet currently defines more than 300 GlobalProductUnitOfMeasureCodes as a list without any relations to each other. With help of logical relationships, automatic transformations between e.g. "25 Kilogram Bulk Bag" and "50 Pound Bag" can be done. Currently matching all the details related to PIP messages is a long process without any automation and any small differences can cause additional system development. SWS techniques can be used to describe how companies use the PIPs messages and this can be used for automatic message compatibility matching and making integration processes quicker. The resulting integration is also more flexible to slightly varying use of messages. Furthermore, the ontologies provide the basis for discovery, composition and selection of services.


Preist et al. [5] presented a concept of mediating between EDI (EDIFACT) and RosettaNet messages but did not provide details on the benefits of ontologysing of messages. Trastour et al. [8] augment RosettaNet PIPs with partnerspecific DAML+OIL constraints to determine if parties have compatible messages, and automatically propose modifications if not. Trastour et al. [7] have also presented how to use agent communication to help in negotiation and contract forming processes for making B2B integration faster. These papers discussed similar benefits for B2B integration but where more about the matching the B2B interfaces rather than showing the benefits of ontologysing the messages used.


We presented how we add semantics to existing RosettaNet messages to enable automated mediation of the differences in B2B integrations. The existing RosettaNet XML messages are lifted to WSML ontology language that can capture the meaning of RosettaNet messages and later use that for making the automated mediation.

This ontologysing is a part of the scenario that we are implementing based on WSMX Semantic Web service environment. We also plan to pinpoint more benefits of using formal ontology languages and provide formal partner interface descriptions that could be used for automatically matching the compatibility of two companies. Furthermore, real data from existing B2B integrations will be used to validate our approach.


This work is partly supported by the Finnish Funding Agency for Technology and Innovation (Tekes) and the Graduate School for Electronic Business and Software Industry. This material is also based upon works supported by the Science Foundation Ireland under Grant No. SFI/02/CE1/I131 and the EU funded Knowledge Web project (FP6 - 507482).


[1] C. Bussler, D. Fensel, and A. Maedche. A conceptual architecture for semantic web enabled web services. SIGMOD Record, 31(4):24–29, 2002.

[2] J. de Bruijn, H. Lausen, et al. The Web Service Modeling Language WSML. Available from WSMO Working Draft v021, 2005.

[3] A. Haller, E. Cimpian, A. Mocan, E. Oren, and C. Bussler. WSMX – a semantic service-oriented architecture. In Proceedings of the 3rd International Conference on Web Services, pages 321 – 328, Orlando, Florida, USA, 2005. IEEE Computer Society.

[4] D. Martin. OWL-S: Semantic Markup for Web Services. Technical report, 2004.

[5] C. Preist, J. E. Cuadrado, S. Battle, S. Williams, and S. Grimm. Automated business-to-business integration of a logistics supply chain using semantic web services technology. In ISWC 05: Proceedings of 4th International Semantic Web Conference, 2005.

[6] D. Roman, U. Keller, H. Lausen, J. de Bruijn, R. Lara, M. Stollberg, A. Polleres, C. Feier, C. Bussler, and D. Fensel. Web service modeling ontology. Applied Ontologies, 1(1):77 – 106, 2005.

[7] D. Trastour, C. Bartolini, and C. Preist. Semantic web support for the business-to-business e-commerce pre-contractual lifecycle. Computer Networks, 42(5):661–673, 2003.

[8] D. Trastour, C. Preist, and D. Coleman. Using semantic web technology to enhance current business-to-business integration approaches. In Proceedings of 7th International Enterprise Distributed Object Computing Conference, pages 222–231. IEEE Computer Society, 2003.