1 / 42

Prof. Dr. Asuman Dogac METU-SRDC Turkey

METU OASIS SET TC Use Case. iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains. Prof. Dr. Asuman Dogac METU-SRDC Turkey. METU OASIS SET TC Use Case.

serena
Download Presentation

Prof. Dr. Asuman Dogac METU-SRDC Turkey

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. METU OASIS SET TC Use Case iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains Prof. Dr. Asuman Dogac METU-SRDC Turkey

  2. METU OASIS SET TC Use Case • Part I: iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains and the Document Interoperability Requirements of iSURF Interoperability Service Utility • Part II: Using SET Tools for translating iSURF Planning Documents Conforming to Different Standards

  3. Part I: iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains and the Document Interoperability Requirements of iSURF Interoperability Service Utility

  4. Research Objectives: Public Domain Tools Supporting SMEs for Collaborative Supply Chain Planning • iSURF open Smart product Infrastructure for SMEs to collect real-time supply chain visibility data • iSURF Service Oriented Collaborative Supply Chain Planning Process Definition and Execution Platform for the SMEs • iSURF Semantic Interoperability Service Utility • iSURF Global Data Synchronization and Transitory Collaboration Service Utility for dynamic transient supply chain relationships for the SMEs

  5. iSURF Overview

  6. Part II: Using SET Tools for translating iSURF Planning Documents Conforming to Different CCTS based Standards

  7. The Main Ideas of the SET Framework • If the document components of two different CCTS based standard share the same semantic properties: • Use this as an indication that they may be similar • Some explicitly defined semantic properties may imply further implicit semantic relationships: • Use a reasoner to obtain implicit relationships • Explicate semantics related with the different usages of document data types in different document schemas to obtain some desired interpretations by means of such informal semantics • For discovering the similarities of structurally different but semantically similar document artifacts, we provide further heuristics • About possible ways of organizing core components into compound artifacts

  8. Semantic Properties of UN/CEFACT CCTS based Standards • The Core Components have the following semantic properties: • Core Component Data Types • Context • Code Lists • Object Class Term • Representation Term • The semantics that a BIE is based on a “Core Component”

  9. The Upper Ontology for the Semantics Exposed by the CCTS Framework

  10. Upper Ontologies of Some of the CCTS based Standards and their Relationships to CCTS Ontology

  11. The current SET Harmonized Ontology • The current version of the harmonized ontology contains the ontological representations of: • All of the CCs and BIEs in CCL 07B • All of the BIEs in the common library of UBL 2.0 • All of the OAGIS 9.1 Common Components and Fields • All of the elements in the common library of GS1 XML • There are about 4758 Named OWL Classes and 16122 Restriction Definitions in the current version of the harmonized ontology

  12. Upper Ontologies and their Relationship to the Document Schema Ontologies

  13. A Specific Instance of the Problem • How to transform • UBL 2.0 Forecast Instance, to • GS1 XML Forecast Instance?

  14. The first step… • Convert the XSDs of these document instances to OWL conforming to SET specifications • SET XSD-OWL Converter tool can be used to generate the OWL definitions of the XSDs conforming to SET Specifications • http://www.srdc.metu.edu.tr/iSURF/OASIS-SET-TC/tools/OASISSET.zip

  15. OWL Definition of UBL Forecast Document

  16. OWL Definition of GS1 XML Forecast Document

  17. Explicate semantics related with the different usages of document data types • Different document standards use CCTS Data Types differently • For example, “Code.Type" in one standard is represented by “Text.Type" in another standard and yet with “Identier.Type" in another standard • This knowledge in real world is expressed through class equivalences so that not only the humans but also the reasoner knows about it • Code.Type ≡ Text.Type • Name.Type ≡ Text.Type • Identier.Type ≡ Text.Type

  18. The Above equivalences are discovered through the SET Harmonized Ontology

  19. The Above equivalences are discovered through the SET Harmonized Ontology

  20. The Above equivalences are discovered through the SET Harmonized Ontology

  21. Addressing Structural Differences in Document Schemas • The harmonized ontology is effective only to discover equivalence of both semantically and structurally similar document artifacts • However Different document standards use core components in different structures • A problem in finding the similar artifacts in two different document schemas is that the semantically similar artifacts may appear at structurally different positions • SET proposes heuristic rules for this

  22. Heuristics to Address Structural Differences in Semantically Equivalent Document Artifacts • This heuristics is about possible ways of organizing core components into compound artifacts and are given in terms of predicate logic rules • Note that a DL reasoner by itself cannot process predicate logic rules and we resort to a well accepted practice of using a rule engine to execute the more generic rules and carry the results back to the DL reasoner through wrappers developed • The results involve declaring further class equivalences in the harmonized ontology

  23. A Heuristic to Help Finding the Equivalent BBIEs at Different Structural Levels • A BBIE, that directly appears under an ABIE in one schema, may be referred through an ASBIE (at any depth) in an another document schema • To give a hint to the reasoner of such possibilities, we developed a piece of software that automatically asserts a subsumtion hierarchy among the “Object Class Terms” of such document artifacts • More specifically, when an “ABIE A1" refers to a "BBIE B" in an "ABIE A2" through an "ASBIE AS" in one document schema, the Object Class Term of the "BBIE B" is made a subclass of "ABIE A1" • Note that once such an assertion is made, then the reasoner can recursively trace the ASBIEs at any depth

  24. Heuristics to Discover Structurally Different BBIEs • A very common structural difference in semantically similar document artifacts is that although some of the semantic properties of a document artifact “A” is the subclass of the corresponding properties of the document artifact “B”, some other properties of “A” are the super classes of the corresponding attributes of “B” • Heuristics to Discover Structurally Different BBIEs: • If the semantic properties of two BBIEs are pair wise equivalent or subclasses of each other, these BBIEs are considered to be similar

  25. Heuristics to Discover Structurally Different ASBIEs • Heuristics to Discover Structurally Different ASBIEs: • If the semantic properties of two ASBIEs are pair wise equivalent or subclasses of one another, we consider these ASBIEs to be equivalent

  26. Heuristics to Discover Structurally Different ASBIE-BBIE Pairs • Consider two semantically equivalent BBIEs, BBIE1 and BBIE2: • If BBIE1 is in ABIE1 and ASBIE1 is referring to ABIE1, there is a possibility that ASBIE1 is semantically equivalent to the BBIE2

  27. Heuristics to Discover Structurally Different ABIEs • When it comes to ABIEs, the structural differences that can occur are more complex because each ABIE may contain different number of BBIEs some of which may be semantically equivalent, some may not • Therefore while testing whether two ABIEs are semantically equivalent, the set of BIEs (the set of BBIEs and ASBIEs) they contain is considered • We define the “ContainsSet" of an ABIE to be the set of all of its BIEs just to simplify the explanation • The “ContainsSet" is in fact the set of BIEs in the range of the “contains" property of an ABIE • The “ContainsSet"s of two ABIEs may be equal; may have a nonnul intersection; may be in subset relationships or may be disjoint of each other • If the “ContainsSet"s are not disjoint, we provide heuristics to discover their similarity

  28. The “ContainsSet”s of two ABIEs are equivalent or in subset relationship • Consider all the semantic properties of two ABIEs: • If each of them is pair wise equivalent or subclasses of one another, and their “ContainsSet"s are the same, for our purposes we consider these ABIEs to be equivalent

  29. The "ContainsSet"s of two ABIEs have a nonnul intersection • The semantic properties of two ABIEs may be equivalent and their "ContainsSet" may have a nonnul intersection • How to classify these ABIEs is for its user to decide • What we provide is a "similarityConstant" that the user may set • As an example, if the user considers that when 60% of the BIEs of two ABIEs are the same, they may be considered similar, then he can set the "similarityConstant" to "0.6" • When all the semantic properties of two ABIEs are either pair wise equivalent or subclasses of one another, and the BIEs in their "ContainsSet" sets are "similarityConstant" percent equivalent, we consider these ABIEs to be similar

  30. Example & Heuristic Rules Heuristic Rules help to find the semantically equivalent but structurally different schemas

  31. SET Framework R U L E S Source OWL Instance Target/Source XSD Document Schemas Upper Ontologies Harmonized Ontology Equality Relations Subsumption Relations Knowledge Base Rule Engine & Reasoner Source XML Instance Target XML Instance XSLT Definition DATA LEVEL KNOWLEDGE LEVEL DATA LEVEL

  32. Back to our problem: Translating iSURF Planning Documents Conforming to Different CCTS based Standards

  33. A Specific Instance of the Problem • How to transform • UBL 2.0 Forecast Instance, to • GS1 XML Forecast Instance?

  34. The Above equivalences are discovered through the SET Heuristic Rules Provided

  35. Transforming UBL Forecast to GS1 XML Forecast • UBL Forecast document is converted to GS1 XML Forecast (and vice versa) through OASIS SET TC methodology • For the Example Planning Documents, SET TC Semantic Tools were able to find: • The semantic equivalences of 15 BBIEs out of 22 BBIEs (68%) • The semantic equivalences of 7 ABIEs out of 15 ABIEs (46%) • The Information on this slide is WRONG!!! • System behaves much, much better than this! We will provide detailed statistics later!

  36. Generating XSLTs through Altova’s MapForce Tool

  37. Thank you for your attention…

More Related