Semantic Interoperability for ESA

Transcription

1 Enterprise Interoperability Cluster Workshop on Semantic technologies in EAI , Bruxelles Semantic Interoperability for ESA - A3 Semantic Suite - ATHENA Consortium

2 Summary Why Interoperability is so problematic? Four steps to Semantic Interoperability Athena Semantic Suite: an Overview Reference Ontology: Athos Semantic Annotation: A* Transformation Rules: Argos Reconciliation execution: Ares 2

3 Enterprise Interoperability and Ontologies Enterprise Interoperability Research Roadmap 4 Grand Challenges 1) an Interoperability Service Utility (ISU) to provide interoperability as a commoditised technical functionality, delivered as services to enterprises, independent of particular IT deployment 2) leveraging Web Technologies for Enterprise Interoperability, with the focus on value creation through the delivery of novel and improved services in next-generation Enterprise Interoperability solutions 3) Knowledge-Oriented Collaboration to enable enterprises, through the sharing and use of knowledge, to successfully form and exploit Virtual Organisations, to the mutual benefit of the VO partners 4) a Science Base for Enterprise Interoperability that comprises a new set of concepts, theories and principles derived from established and emerging sciences, with a view to long-term problem solving as opposed to short-term solution provisioning. 3

4 Why Interoperability is so problematic? Primary problem of ESA interoperability: Diversity Organization models and Business Processes Working styles Financial and controlling methods HR Management All that is reflected in the Enterprise Software Applications (ESA): Database schemas and data organization Software architectures [e.g., MDA-MDD: CIM/PIM/PSM, SOA] Message structures (sent/received) [e.g., SOAP] Workflow models (e.g., BPEL) Rules and constraints (e.g., SWRL) 4

5 Enterprise Interoperability: easy and hard problems Easy problems: technological (e.g., TCP/IP) and syntactic Information Structures Coding transformation Hard problems: Semantics, Organization, Culture, Religion, DeliveryDate = 30d Do you mean: F.O.B.? Or Door-delivery? 30d: 30 days, after? After month end? First Problem in ESA Information and message exchange mismatch In Athena we identified a dozen of Message Interoperability Mismatch, characterised by: Lossless Reconciliation Lossy Reconciliation 5

6 Athos Ontology Mgt System A* Semantic Annotation Sys Four Steps to Semantic Interoperability Argos Semantic Rule Gen Sys Preparation Steps Step 1: Reach a consensual representation of the Application Domain Reference Ontology Step 2: give an explicit, shareable, unambiguous, meaning to your exchanged rmation Semantic Annotation Step 3: use Semantic Annotations to derive rules that cast your into ontological Semantic Transformation Rules ARES Rule Exec System Do Business Step Step 4: seamless exchange of diverse messages, from Ent1 to Ent2, by transparent semantic morphing Semantic Runtime Reconciliaiton Rules Executions 6

7 Semantic Reconciliation streamline AppA Doc Instance Doc A Instance Doc A Instance A Athos Reference Ontology A* Annotation Repository Argos Transformation Rules Repository Ares Reconciliation Engine Ontology Management System Semantic Annotation Tool Transformation Rules Building Tool Doc Instance Doc B Instance Doc B Instance B Doc Schema A Themis AppB Doc Schema B RDFS Models Repository Design phase Run-time phase 7

8 Semantic Suite components Athos, the Athena Ontology System. an ontology is an agreed and shared representation of a given domain. in Athos ontologies are represented according to OPAL A*, the Semantic annotation tool. Semantic annotation aims at giving a non ambiguous meaning to digital resources represents a conceptual correspondence between resources and concepts in the ontology ARGOS, the Transformation Rules building tool: based on the Semantic annotation, the transformation rules represent a procedural way of transforming ground resources (i.e., data) into ontology instances (foreward transf.) and viceversa (backward transf.) ARES, the runtime reconciliation engine the actual reconciliation is the result of the composition of a forward and a backward transformation Themis, the RDFS models repository contains schema documents on which semantic annotation and transformation rules are built 8

9 Step 1 - Reference Ontology The first key element of the proposed approach Used to describe the domain of interest and to give meaning to the structure of business documents to be reconciled Based on definition of concepts and relationships OPAL is the used representation method The contruction of the ontology is supported by the Athos tool 9

10 Ontology building The ontology chestnut: Upper Domain Ontology (generic concepts common for many domains) UDO Specialization PurchaseOrder Document ISA Product Application Domain Ontology (concept specific for the business domain) Lower Domain Ontology (elementary concepts) ADO LDO Aggregation FurniturePurchaseOrder Wardrobe StreetName Quantity Price CBO UDO LDO = CBO 10

11 OPAL meta-concepts Actor_kind aimed at modelling any relevant entity of the domain that is able to activate or perform a process. (e.g. Chamber of Commerce, Company,...) Object_kind aimed at modelling a passive entity, on which a process operates, typically to modify its state. (e.g., Certificate of existence, Quality Certification, Safety Certification) Process_kind aimed at modelling an activity that is performed by an actor to achieve a given goal. (e.g. Negotiating, e-invoicing, Verifying Legal Status...) The complete picture includes other Complementary concepts, such as: Atomic Attribute, Complex Attribute Message Business Object Document (represents the content of a message The OPAL concepts are connected by conceptual relations 11

12 Step 2 - Semantic Annotation Invoice RFQ RO (OPAL) Annotated resource ( RDFS) ACME VAT Total NetPrice ItemPrice Building an annotation expression: 1. Using an existing concept of RO or 2. Creating a new concept by composing elements of RO Linking the annotation expression to the resource Annotation expression Build an annotation expression { x 9y(Invoice(x) ^hastotal(x,y)^total(y)) } Link 12

13 Requirements for the Athena semantic annotation Annotation criteria: Kind of annotated resources: RDF(S)), XMI light Used by: Human / Computer Positioning: attached annotation (without modifying the resource, multiple annotation of the same resource) Level of formality: progressive approach (from rmal to formal) Terminology restriction: ontology-based annotation Abstraction level: annotation by concepts derived from RO Structured annotation expression annotation linked to resource by using specific operators Annotation beyond exact matching: SAX can be more or less general than the annotated resource Level of automation: automatic support to annotation building 13

14 A progressive approach SA methodology defined as a stepwise approach L=4 Full SA (FSA), The annotation is an OWL expression. L=3 L=2 L=1 Simple SA (SSA), Paths from the PSA level are combined to build simple expressions by using abstract operators (, binary operator; φ, unary operator). Identification of the covered mismatch Path SA (PSA), the annotation is represented by a set of paths from the RO Terminological SA (TSA), The annotation is represented by a set of terms taken from the definition of concepts in the RO 14

15 Simple SAX an example Paths from the PSA level are combined to build simple expressions by using abstract operators (, binary operator; φ, unary operator) Possibility to specify the kind of covered mismatch This level will be taken as specification for the Transformation Rules definition AIDIMA header products buyerordernumber supplier buyer product record org orgname contact person address details productcode description quantity name RO BOD BA Supplier ID Product Description FirstName Name BOD PurchaseOrder Contact BA Person Buyer OrderLine Quantity BOD BA Year LinePrice Surname IssueDate Month CA.has_Header.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name >: SSA PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName Expression PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname (Granularity/ Splitting) 15

16 Two Categories of Mismatches Lossless mismatches can be solved without loss of rmation Naming: different labels for the same content Attribute granularity: the same rmation is splitted in a different number of attributes Structure Organization: different structures and organization of the same content Subclass-Attribute: an attribute with predefined value set is represented by a set of subclasses Schema-Instance: data hold schema rmation Encoding: different format of data or unit of measure Lossy mismatches any (faithful) transformation will cause a loss of rmation Content: different content denoted by the same concept (typically expressed by enumeration) Coverage: the presence/absence of rmation Precision: the accuracy of rmation Abstraction: level of specialisation refinement of the rmation 16

17 Step 3 - Tansformation Rules Semantic Annotation as specifications for mismatches solution a conceptual correspondence between resources and concepts in the ontology Tansformation Rules as a procedural way for transforming ground resources (i.e., data) into ontology instances (foreward transf.) and viceversa (backward transf.) In Athena, the reconciliation platform is based on the Jena2 suite (an open-source reasoning platform produced by HP) Rules are written in accordance with the Jena2 rules syntax The transformation Rules building is supported by the Argos tool 17

18 Jena2 rule structure Name: Antecedents Consequents The rule specification comprises: a name (optional), the rule s identifier a list of antecendents, the rule s body a list of consequents, the rule s head In forward-chaining: A rule is satisfied if the body is true Facts in the head of a satisfied rule are inferred Example [Uncle: (?a fatherof?b) (?a brotherof?c) -> (?c uncleof?b)] 18

19 19 From Semantic Annotation to Transformation Rules.has_Header.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson. haspart _FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart _Surname >: AIDIMA RO header header products products supplier supplier buyer buyer org org contact person contact person name name orgname orgname address details address details product record product record description description productcode productcode quantity quantity buyerordernumber buyerordernumber header header buyer buyer org org contact person contact person name name header header buyer buyer org org contact person contact person name name PurchaseOrder PurchaseOrder OrderLine OrderLine ID ID IssueDate IssueDate Buyer Buyer Supplier Supplier Contact Person Contact Person Surname Surname FirstName FirstName Product Product LinePrice LinePrice Quantity Quantity BOD BOD BOD BA CA BA BA Description Description Name Name Year Year Month Month PurchaseOrder PurchaseOrder Buyer Buyer Contact Person Contact Person Surname Surname FirstName FirstName PurchaseOrder PurchaseOrder Buyer Buyer Contact Person Contact Person Surname Surname FirstName FirstName Split SSAX SPLIT.has_Header.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name INTO PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname Foreward Transf Rule

20 An example of Transformation Rule in the Jena2 syntax SPLIT.has_Header.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name INTO PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname Forward Transf Rule NameSplitting: [(?x0 rdf:type ai:) (?x0 ai:has_header?x1) (?x1 rdf:type ai:header) (?x1 ai:has_buyerinfo?x2) (?x2 rdf:type ai:buyerinfo) (?x2 ai:has_organizationinfo?x3) (?x3 rdf:type ai:organizationinfo) (?x3 ai:has_contactperson?x4) (?x4 rdf:type ai:contactperson) (?x4 ai:has_name?x5)] [(?x0 rdf:type ro:purchaseorder_bod) (?x0 ro:relto_buyer?x2) (?x2 rdf:type ro:buyer_ba) (?x2 ro:relto_contactperson?x4) (?x4 rdf:type ro:contactperson_ba) Split(?x4,,?y1,?y2, ' (?x4 ro:haspart_firstname?y1) (?x4 ro:haspart_surname?y2)] Rule in the Jena2 syntax 20

21 Step 4 - Reconciliation execution Actual document reconciliation from A to B is performed by Ares, applying the previous defined Transformation Rules Two transformation: Forward, from the A format into the Ontology format (FWD rules) Backward, from the Ontology format into the B format (BWD rules) A Message A Message B B Message payload in the A format A Forward Transform Rules FWD transf BWD transf B Backward Transform Rules Message payload in the B format ARES Ontology format 21

22 An example of forward transformation SPLIT.has_Header.has_buyerInfo.has_organisationInfo.has_contactPerson.has_name INTO PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_FirstName PurchaseOrder_BOD.relTo_Buyer.relTo_ContactPerson.hasPart_Surname NameSplitting Transform Rule An instance of the AIDIMA <ai: rdf:id="ex_aidima 1"> <ai:has_header> <ai:header rdf:id="ordhea_id1"> <ai:has_buyerinfo> <ai:buyerinfo rdf:id="buyinf_id1"> <ai:has_organisationinfo> <ai:organisationinfo rdf:id="orginf_id1"> <ai:has_contactperson> <ai:contactperson rdf:id="conper_id1"> <ai:has_name>john Smith</has_name> </ai:contactperson> </ai:has_contactperson> Name Splitting Rule Application The AIDIMA in the Ontology format <ro:purchaseorder_bod rdf:id="ex_aidima 1 > <ro:relto_buyer> <ro:buyer_ba rdf:id= buyinf_id1 > <ro:relto_contactperson> <ro:contactperson_ba rdf:id= conper_id1 > <ro:haspart_firstname>john</ro:haspart_firstname> <ro:haspart_surname>smith</ro:haspart_surname> </ro:contactperson_ba 22

23 Order Processing (inspired by the AIDIMA scenario) Buyer Process Sending RFQ Evaluating Quotation Issuing PO RFQ Quot. Purchase Order Supplier Process Processing RFQ Processing PO Fulfilling PO Receiving Goods OrdConf Delivering Goods Paying Invoice Invoice Invoicing BUYER SUPPLIER 23

24 Conclusions The A3 Semantic suite is organized with the following tools Athos, ontology management system A*, semantic annotation tool Argos, reconciliation rules building environment Ares, message reconciliation engine Themis, the schema documents repository We presented a concrete example inspired by the AIDIMA scenario 24