Mapping of Core Components based e-Business ... - Semantic Scholar

Mapping of Core Components based e-Business Standards into Ontology Ivan Magdalani´c, Boris Vrdoljak, and Markus Schatten University of Zagreb [email protected] Faculty of Organization and Informatics Pavlinska 2, HR-42000 Varaˇzdin, Croatia [email protected] Faculty of Electrical Engineering and Computing Unska 3, HR-10000 Zagreb, Croatia [email protected] Faculty of Organization and Informatics Pavlinska 2, HR-42000 Varaˇzdin, Croatia

Abstract. A mapping of Core Components specification based e-business standards to an ontology is presented. The Web Ontology Language (OWL) is used for ontology development. In order to preserve the existing hierarchy of the standards, an emphasis is put on the mapping of Core Components elements to specific constructs in OWL. The main purpose of developing an e-business standards’ ontology is to create a foundation for an automated mapping system that would be able to convert concepts from various standards in an independent fashion. The practical applicability and verification of the presented mappings is tested on the mapping of Universal Business Language version 2.0 and Cross Industry Invoice version 2.0 to OWL. Keywords: e-business standards, ontology mapping, Core Components, UBL, CII

1

Introduction

There are dozens of standards that describe business documents today. While each standard has emerged due to the need in particular areas of business, these standards are often overlapping. It is often the case that the interests of various stakeholders result with standards that largely cover identical areas of operations. The exchange of business documents in such a case requires the conversion of the elements from one standard to another. Though there are tools that help in such a document conversion, there is always a need for an expert in the field who will be able to decide upon the meaning of each element. The process of deciding which elements will be mapped into another one is done manually by the expert. Our intention is to speed up that process by building a system that

2

Mapping of Core Components based e-Business Standards into Ontology

will perform this task automatically. If unable to fully automate the process, due to various factors, the system should at least suggest which element should be mapped into another, and wait for confirmation of the experts. Several ways can be used to compare and synchronize business documents and they are presented later in this paper. In our research we decided to make the mapping of electronic business standards by developing individual ontologies and then create mappings between them. The representation of standards into ontology allows automation of mutual mapping process by using different computational algorithms. The first step in this process is to create a mapping of e-business standards into ontologies and this paper shows the achieved results. E-business standards used in procurement which are based on Core Components Technical Specification 2.01. (CCTS) [14] are in the focus of our research. CCTS is accepted as ISO/TS 15000-5:2005 and several e-business standards are based on it, such as Universal Business Language (UBL) [12], Cross Industry Invoice (CII) Version 2.0 [15], GS1 XML [4] and OAGIS 9.x [10]. All of these standards cover the area of electronic procurement and a mapping between them is a real and practical need. This paper presents a mapping from e-Business standards based on CCTS to the Web Ontology Language (OWL). OWL is chosen because it is a well accepted standard for writing ontologies to use it in the Internet. The verification of the proposed mapping is done by building ontologies of UBL and CII. The rest of this article is organized as follows: An overview of business documents standards is given in section 2. The mapping of e-business standards to ontologies is presented in section 3. In section 4 the related work is presented. The conclusion is given in section 5.

2

An overview of business documents standards

The area of electronic business document standards is an extremely active one, and abounds with standards that define the content and meaning of their elements. Fig 1 gives a non-exhaustive overview of the most important standard definitions in a timescale [7]. There are two major groups of business document standards: delimiter-based standards and markup-based standards. Delimiter-based approaches use standard ASCII characters to separate different data elements, segments, and messages. All definitions of used elements in delimiter-based standards are outside of documents and messages. Markup-based standard use some of the markup languages to mark document elements and to give them proper semantics. The most accepted markup languages are Standard Generalized Markup Language (SGML), Hypertext Markup Language (HTML) and eXtensible Markup Language (XML). We have recognized that the tendency of acceptance of standards is in favor of the standards based on XML and Core Components (an acronym of Core Components Technical Specification). The Core Components concept defines a new paradigm in the design and implementation of reusable syntactically neutral

Mapping of Core Components based e-Business standards to ontology

3

Fig. 1. Overview of different business standards [7]

and semantically correct and meaningful building blocks. Therefore, we bring a detailed description of the metamodel of Core Components and Business Information Entities (BIE), which simplified version is shown in Fig 2. The Core Components elements (CCs) are: Aggregation Core Component (ACC), Basic Core Component (BCC), Association Core Component (ASCC), and Data Type (DT). The ACC is a set of connected components of business information that carry a unique business meaning, independent of any business context. The BCC specifies a distinct business characteristic of the ACC. The ASCC specify a complex business characteristic of the ACC. The BCCs and ASCCs are properties of the ACCs. DT provides a restriction on content. When the Core Components elements are put in a Business Context, they represent the foundation on which Business Information Entities (BIE) are build. BIEs are part of business data or a group of pieces of business data with a unique business semantic definition. CCs serve as a controlled vocabulary to build a BIE. There are three different categories of BIEs: Basic Business Information Entity (BBIE), Association Business Information Entity (ASBIE), and Aggregate Business Information Entity (ABIE). The BBIE represents a single business characteristic of a specific object class in a specific business context. The ASBIE is a complex business characteristic of a specific object class in a specific business context. The ABIE is a set of related pieces of business information that together carry a unique business meaning in a specific business context. Syntax neutral Core Components are intended to form the basis of business information standardization efforts and to be realized in syntactically specific instances. This could be done in delimiter-based standard such as UN/EDIFACT, but most implementations are done using XML syntax. The first implementation of Core Components is UBL and it is followed by the implementation in other electronic business standards: GS1 XML, OAGIS 9.X and recently CII 2.0.

4

Mapping of Core Components based e-Business Standards into Ontology

Fig. 2. Simplified metamodel of Core Components and Business Information Entities [7]

Special documents define mappings from Core Components definitions to XML Schema definitions. In UBL the corresponding document is UBL-Naming and Design Rules-2.0 [11], while UN/CEFACT brings its own roles in XMLNaming-and-Design-Rules-V2.0 for Version 2.0 [17] and UNCEFACT + XML + NDR + V3p0 [16] for Version 3.0. The basic idea of mapping of Core Components BIE definitions into XML Schema is shown in Fig 3. The ABIE structure is mapped into xsd:complexType and its name into xsd:element. The ASBIE is mapped into xsd:element and is used in ABIE to refer to other ABIE. The BBIE is mapped into xsd:complexType where it extends or makes a restriction on a qualified or unqualified Data Type. DT is mapped into xsd:complexType od xsd:simpleType. The following section shows a similar process of mapping e-business standards into an ontology.

3

Mapping of e-business standards to ontology

As already mentioned, our goal is the automation of mapping between different e-business standards, and an important step towards its achievement is the map-

Mapping of Core Components based e-Business standards to ontology

5

Fig. 3. Mapping of Core Components BIE definitions into XML Schema

ping e-business standards to ontologies. In Fig 4 the possible ways of mappings between the various e-business standards are presented. The Case A shows a direct mapping between e-business standards. The drawback of this mapping method is the need for experts who know both standards. Such a mapping is also difficult to make because of various syntaxes used in different standards. The Case B shows a mapping of the two standards using a common ontology. The lack of this kind of mapping is the lack of a shared common ontology of the e-business domain. Such an ontology should have all the elements of all e-business standards. Although such a top-down approach is cost-effective in long-term, it is difficult to expect that such ontology of the e-business domain will soon be developed. The Case C shows a variant of B with the difference that the e-business standards are first mapped to a local ontology and then mapped to each other using a common ontology. The advantage of this case with respect to the previous one, lies in the use of ontology in a mutual mapping. The main disadvantage is the same as in B, i.e. the lack of a common ontology. The Case D shows the mapping of e-business standards to local ontologies. The representation of standards in the common language allows automation of

6

Mapping of Core Components based e-Business Standards into Ontology

mutual mapping process by using different computational algorithms. The advantage of this method is independent mapping of each standard into a common language. This requires that an expert is familiar only with domain of one particular area compared to the Case B and Case C where the expert have to have the knowledge of all e-business standards. This approach was chosen in our study. The first step necessary is to make the mapping of e-business standards to local ontologies. Because we believe that standards based on CCTS take a leadership role, we decided to do their mapping first.

Fig. 4. Mappings between the various e-business standards

The implemented mapping rules from BIE to OWL are presented on Fig. 5. All instances of Core Components ABIE, BBIE, DT, and Business Context are mapped to OWL Class. The name of the class is of type Internationalized Resource Identifiers (IRI). Each IRI is defined by its name and namespace. We use the same namespaces as defined by the mapping of Core Components to

Mapping of Core Components based e-Business standards to ontology

7

XML Schema. If it exists, the definition of Core Component is stored as an rdfs:comment. ASBIE instances are not mapped to OWL Classes, but to OWL Object Properties. If a hierarchy between Core Components elements exists, it is mapped by using the rdfs:subClassOf property. The ABIE consists of set components which are the ASBIE or the BBIE. They are called properties of ABIE and are mapped into OWL as OWL Object Properties. The OWL Class to which a particular property belongs, is mapped by using rdfs:domain. The ASBIE and the BBIE are mapped as rdfs:range. The name of the object property is formed as an IRI, where the name has the prefix “has”. This kind of naming convention is the standard for OWL Object Properties.

Fig. 5. BIE to OWL mapping

Data Type in Core Components consists of Content Component and Supplementary Component. The Content Component contains the actual value and the Supplementary Component defines the description of value like units of measure. Content Component and Supplementary Component are mapped as OWL Datatype Properties. The OWL Class to which particular data type belongs, is

8

Mapping of Core Components based e-Business Standards into Ontology

mapped by using rdfs:domain. rdfs:range is used for defining primitive data types like built-in data types of XML Schema or code list identifiers. If some components are related with certain business context, this property is mapped as OWL Object Property. Each business context is mapped as OWL class. The proposed mapping process is shown in the example of mapping from OWL to UBL. Fig 6 presents the definition of the total tax in UBL. For simplicity of presentation, definition of the total tax presented in Fig 6 does not include all the elements from the original definition. The total tax component is of type ABIE and contains two properties: the amount of tax and subtotals. The amount of tax is a component of type BBIE, a subtotal is component of type ASBIE. Further, the BBIE Tax Amount is of type AmountType. The ASBIE Subtotal is of type ABIE TaxSubtotal.

Fig. 6. The definition of total tax in UBL – short example

A mapping of the described definition of the total tax is presented in Fig 7 by using OWL syntax. Lines 1-7 define the TaxTotal class, which corresponds to the TaxTotal in UBL. The presented IRI in line 2, http://ubl2_0/cac#TaxTotal, is shortened from the original for the presentation purposes. The short name of the class is defined in line 3, whilst lines 4-6 give a full definition of the class. For class TaxTotal there are two Object Properties defined: hasTaxAmount (lines 9-15) and hasTaxSubtotal (lines 24-30). Lines 11-12 define to which OWL class this property belongs, which in this case is the class TaxTotal. Lines 13-14 define the range of the allowed contents in this property, which in this case are instances of the class TaxAmount. The OWL class TaxAmount is defined in lines 17-22 and is a subclass of an OWL class Amount (definition in lines 20-21). The OWL class Amount is defined in lines 40-46. The restriction on content of the class Amount is made by OWL Datatype Property hasAmountValue (lines 48-54), where it is defined that content is of type xsd:decimal. We used the presented mapping to produce ontologies of invoice from UBL 2.0 and Cross Industry Invoice version 2.0. These ontologies are available at [5] and [6]. The made ontologies were created using the OWL API open source

Mapping of Core Components based e-Business standards to ontology

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

< r d f s : l a b e l>TaxTotal I n f o r m a t i o n about a t o t a l amount o f a p a r t i c u l a r t y p e o f t a x . < r d f s : l a b e l>TaxAmount < r d f s : l a b e l>T a x S u b t o t a l I n f o r m a t i o n about t h e s u b t o t a l f o r a p a r t i c u l a r t a x c a t e g o r y < r d f s : l a b e l>Amount A number o f monetary u n i t s s p e c i f i e d

in a currency

...



Fig. 7. OWL definition of tax – short example

...

9

10

Mapping of Core Components based e-Business Standards into Ontology

software [13] . The produced ontologies were loaded into Prot´eg´e for the purpose of syntax and structure verification.

4

Related work

Ontology building and its use for semantic description of data becomes a and more more important subject of research. In most scientific and industrial areas ontologies are made, whose purpose is to describe some or all areas of interest. Specific activity can be seen in recent years when ontologies are build in different domains such as fisheries [3], agriculture [2], and even music [1]. The main difference between such approaches and our approach lays in the planned usage of ontologies. In our case, we strive to create an ontology of individual e-business standards for later mapping. Therefore, our ontology include only certain segments of the e-business domain, which certain standard describes. Because the e-business standards are well defined we have created a software to extract the necessary data and to build an ontology in OWL. The problem of manual ontology development has already been observed and there is a tendency to develop software for the automated creation of ontologies, if possible. An example of such approach is the creation of ontologies from UML diagrams as shown in [19]. In this paper we present the creation of ontologies from e-business standards based on Core Components. The main emphasis in this paper is the process of mapping standards that are based on Core Components. These standards have a specific structure and it is important to map it to the ontology. Data for our ontologies were extracted mainly from the existing XML Schema, and partly from Excell documents. A similar process of creating an ontology from an XML schema is shown in [8]. A similar approach to ours is the construction of an ontology of UBL Version 1.0, which is presented in [9]. They introduced the following rules. CCT, DT, ACC, ABIE define concepts. BCC, ASCC, BBIE, ASBIE define properties. Qualification of CC to BIE is semantically similar as the subconcept relation between concepts and all instances of a BIE are also instances of the corresponding CC. Actually as at the qualification step in UBL/CCTS also the business context is explicitly specified, transforming it to a simple subconcept relation oses some information [9]. Differences to mappings presented in this paper are the following. We map only BIE, because BIE are based on CC and have a busines context. Rules presented in section 2 for mapping Core Components to XML schema also work with BIE. We define that concepts are ABIE, BBIE, DT, and Busines Context. We also use BBIE as a property of ABIE, but we declare them as concept too. We use BBIE to restrict content of property by using rdfs:range. In this way we preserve the hierarchy which goes from DT to BBIE. Mapping of BBIE as property of ASBIE is the same as in [9]. Further, in [9] the manually refined structure of the UBL ontology was aligned with the BULO ontology, i.e. the proper places for the topmost UBL concepts in the BULO taxonomy were identified. We have not aligned our ontologies to any upper ontology because the purpose of our work is not to create a common ontology of e-business domain,

Mapping of Core Components based e-Business standards to ontology

11

but to map different e-business standards to each other automatically. We consider that the alignment of only topmost concepts with an upper ontology will not give the advantage in mutual mapping of ontology. Instead of the alignment with the some upper ontology, we introduced mapping of business context. The knowledge of the business context of certain element can be helpful in identifying its semantic. Futher, UBL version 1.0 is significantly smaller the UBL Version 2.0. In [9] one namespace for all ontologies is used. We used more namespaces in order to avoid name collisions. In [18] construction of UBL ontology Version 2.0 is presented. In this approach like in ours, all elements of Core Compnents are concepts except ASBIE. Properties of concepts are defined by owl:intersectionOf, owl:Restriction, and owl:someValuesFrom. We and [9] use rdfs:range for the same functionality, which is better for the use in mutual ontology mapping. Further, in [9] and in [18] are presented mappings of UBL to OWL, while our approach is more general and deals with all mapping of all standards based on Core Components to OWL.

5

Conclusion

This paper presented a mapping of e-business standards based on Core Components specification into ontology using OWL. We gave an overview of e-business standards to point to the complexity of the e-business domain and to show a need for mutual mapping of standards by mapping them in a common ontology founded language. The emphasis is put on mapping of Core Components elements to specific constructs in OWL in such a way that the existing hierarchy of e-business standard is preserved. The purpose of building an ontology out of e-business standards is the building of a system that will be able to do mappings between e-business standards automatically using its ontology representation. This goal differs from ours mapping with other approaches presented in related work. The advantage of our mapping is in more general approach, which deals with mapping of all standards base on Core Components to OWL. We introduced mapping of business context which can be helpful in identifying of semantic of some elements. The practical applicability and verification of the presented mappings is tested on the mapping of Universal Business Language version 2.0 and Cross Industry Invoice version 2.0 to OWL. Our future work is focused on developing an ontology from the delimiterbased e-business standards. In parallel, we are building a system for automatic mapping of ontologies to each other.

References 1. Albuquerque, M.O., Siqueira, S.V.M., Lanzelotte, R.S.G., and Braz M.H.L.B: An Ontology for Musical Phonographic Records: Contributing with a Representation Model, Best Practices for the Knowledge Society. Knowledge, Learning, Development and Technology for All, Volume 49, pp. 495-502, Springer, Heidelberg (2009)

12

Mapping of Core Components based e-Business Standards into Ontology

2. Athanasiadis, I.N., Rizzoli, A.E., Janssen, S., Andersen E., and Villa F.: Ontology for Seamless Integration of Agricultural Data and Models, Metadata and Semantic Research, Volume 46, pp. 282-293, Springer, Heidelberg (2009) 3. Caracciolo, C., Heguiabehere, J., Sini, M., and Keizer, J.: Networked Ontologies from the Fisheries Domain. Metadata and Semantic Research, Volume 46, pp. 306311, Springer, Heidelberg (2009) 4. GS1: GS1 XML, http://www.gs1.org/ecom/xml 5. http://barok.foi.hr/~ivmagdal/ontologies/ubl2_0.owl 6. http://barok.foi.hr/~ivmagdal/ontologies/cii2_0.owl 7. Liegl, P.: Business Documents for Inter-Organizational Business Processes, Ph.D. Thesis, Vienna University of Technology, 2009. 8. Lowe, B.: DataStaR: Bridging XML and OWL in Science Metadata Management. Metadata and Semantic Research, Volume 46, pp. 141-150, Springer, Heidelberg (2009) 9. Nagypal, G., Lemcke, J.: A business data ontology. Deliverables of project: Service Ontologies and Service Description, http://dip.semanticweb.org/documents/D3. 3-Business-data-ontology.pdf (2004) 10. OAGi: OAGIS 9.X, http://www.oagi.org/ 11. OASIS: UBL-Naming and Design Rules-2.0, UBL http://www.oasis-open.org/ committees/download.php/10323/cd-UBL-NDR-1.0Rev1c.pdf 12. OASIS: Universal Business Language (UBL) Naming and Design Rules 2.0, http: //docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html 13. OWL API, http://owlapi.sourceforge.net 14. UN/CEFACT: Core Components Technical Specification ver.2.01 - Part 8 of the ebXML Framework, http://www.unece.org/cefact/ebxml/CCTS_V2-01_ Final.pdf 15. UN/CEFACT: Cross Industry Invoice Version 2.0, http://www1.unece.org/ cefact/platform/display/TBG/Cross+Industry+Invoice+Process 16. UN/CEFACT: UNCEFACT+XML+NDR+V3p0, http://www.unece.org/ cefact/xml/UNCEFACT+XML+NDR+V3p0.pdf 17. UN/CEFACT: XML-Naming-and-Design-Rules-V2.0, http://www.unece.org/ cefact/xml/XML-Naming-and-Design-Rules-V2.0.pdf 18. Yarimagan, Y., Dogac, A.: A Semantic-Based Solution for UBL Schema Interoperability. IEEE Internet Computing , pp 64-71, May (2009) 19. Zhuoming Xu, Yuyan Ni, Lili Lin and Huajian Gu: A Semantics-Preserving Approach for Extracting OWL Ontologies from UML Class Diagrams. Database Theory and Application, Volume 64, pp 122-136, Springer, Heidelberg (2009)