International Handbooks on Information Systems

ion: level of specialisation refinement of the information Granularitv: level of decomposition refinement ofthe information Field length: number of bytes of the attribute field It is important to note that there are situations where it is not possible to tell in advance if a transformation will give rise to a loss or not and consequently if a communication between two SAs will be successful or not. Only for two SAs that have both lossless clashes a safe communication is fully guaranteed. Indeed, also an exchange of information between two "lossy" sites may result in a lossless exchange. In fact, if the two LCSs have the same lossy clash with respect to the ontology, the information coming from the sender and lost during the transformation, could not be used by the receiver. Then, the loss of information will not affect the communication between the two SAs. Another example is the transmission of an information structure that is richer (and matching the ontology) on the sender side than on the receiver side. In sending, the information is fully encoded and transferred, but the loss takes place at the destination (however, the information actually received is "complete" with respect to the receiver). 31 An Ontology-based Platforrn for Semantic Interoperability 625 The identification of the above classes of interoperability clashes required a careful study, mainly carried out analysing a significant number of proposed standards. Having considered published standards, we were guaranteed to avoid peculiar interoperability problems caused by (marginal) applications solutions, with unusual design characteristics. Below in Table 2 an example is reported, where we have a fragment of a LCS, and in particular the information conceming a hotel, and the corresponding fragment ofthe reference ontology. Following the two concepts specifications, here is an analysis of the interoperability clashes emerging from the comparison ofthe two structures. Table 2. Example of Local Conceptual Schema vs Ontology Local Hotel Schema (LHS) Denomination: String Address: String Telephonel: String Telephone2: String Fax:String Ontology Hotel Schema (OHS) Name: String Address [ Street: String City: String ContacUnfo [ Phone: String Fax: String Email: String Distancejrom_airport: enum('at airLocation [ port', 'next to', 'near') Distancejrom_airport(km): Integer Distance _ from _ cityCentre(km): Integer Category: enum('*', '**', '***', '****') Prices [ Min: Integer Max : Integer Category: enum('&', '&&', '&&&') Rates [ Single [ ] Min: Integer Max: Integer Double [ Min: Integer Max: Integer Hotel_Services: enum('shuttle', 'security Services: enum('pool', 'parking', 'gym', box', 'disco') 'safe', 'discotheque') Fig. 4 shows the interoperability clashes that can be identified analyzing the two schemas in Table 2. 626 Micheie Missikoff and Francesco Taglino Path-Naming Clashes (lossless clashes) LHS.Denomination vs OHS.Name LHS.Prices vs OHS.Rates LHS. Telephone vs OHS. Contact_Info. Phone LHS. Hotel_Services vs OHS.Services LHS. Distancejrom_airport vs OHS.Location. Distance_from_airport Structural Clashes (lossless c1ashes) (LHS. Telephone 1 & Telephone2) vs OHS. ContacUnfo.Phone LHS.Address vs (OHS.Address.Street &.City) LHS.Prices vs OHS. Rates OHS.Email vs LHS. Content Clashes (lossy clashes) LHS.HotetServices vs OHS.Services Precision Clashes (lOS5Y c1ashes) LHS. Distance_from_airport vs OHS. Location. Distancejrom_airport LHS.Prices vs OHS.Rates Fig. 4. A clashes analysis Note that different kinds of clashes may appear on the same information item; prices and rates exhibit 3 different conflicts on the same information. 31.2. 3 The Semantic Annotation In the proposed approach to interoperability, the primary goal ofthe ontology is to provide a unique semantic reference for each application that wishes to expose a given interface (referred to as Local Conceptual Schema: LCS), both for exporting and importing information. In essence, every piece of information in the LCS will be annotated by using the ontology content and the Semantic Mediation and Application Interoperability Language (SMAlL) illustrated below. For a given application entity (represented as a data structure in the LCS), the annotation process consists in identifying the Lower Domain Ontology elements present in 31 An Ontology-based Platforrn for Semantic Interoperability 627 the referenee ontology; then the meaning of the LCS data strueture is defined by eomposing a SMAIL expression that uses these elements of the ontology. These SMAIL expressions are used to generate reeoneiliation rules, at extensionallevel, that essentially represent a mapping between the loeal eoneeptual struetures and the interehange representation. Therefore we will have one eustom reeonciliation rules set for eaeh applieation entering in the Harmonise spaee. sa::= 1es3! lem con se con::=<: 1=: se::= to(oe, eond) I to(oe, eond) , se I to(oe, eond) j se