Dictionary based interchanges for iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple Domains David Webber.

  • Published on
    18-Jan-2016

  • View
    217

  • Download
    0

Transcript

<ul><li><p>Dictionary based interchanges for iSURF -An Interoperability Service Utility for Collaborative Supply Chain Planning across Multiple DomainsDavid WebberOASIS SET TC / CAM TC(with excerpts and summary from main presentation by Prof. Dr. Asuman DogacMETU-SRDCTurkey)OASIS SET TC Use Case - iSURF</p></li><li><p>METU OASIS SET TC Use CasePart I: iSURF - Document Interoperability RequirementsPart II: Using Dictionary based approach and SET Tools for aligning structure components across syntax vocabularies</p></li><li><p>Part I: iSURF Document Interoperability Requirements</p></li><li><p>Research Objectives: Public Domain Tools Supporting SMEs for Collaborative Supply Chain Planning</p><p>iSURF Semantic Interoperability Service Utility</p><p>iSURF Global Data Synchronization and Transitory Collaboration Service Utility for dynamic transient supply chain relationships for the SMEs </p></li><li><p>Existing iSURF Domain Syntax Format Alignment</p></li><li><p>Dictionary approach summaryIf the document components of two different CCTS based standard share the same semantic properties: Use this as an indication that they may be similarSome explicitly defined semantic properties may imply further implicit semantic relationships:Use a reasoner to obtain implicit relationshipsAlign to dictionary definitions allowing crosswalkCreate harmonized dictionary lookupUse abstract UID as common reference (linkage between language specific named types/objects)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 semanticsDetermine similar/match relationships and rules for constraint alignment and compound component relationships (e.g. date-time vice date and time)Provide dictionary structure format for managing relationshipsLeverage existing OASIS CAM and ebXML Registry TC work</p></li><li><p>The current SET Harmonized OntologyThe current version of the harmonized ontology contains the ontological representations of:All of the CCs and BIEs in CCL 07BAll of the BIEs in the common library of UBL 2.0All of the OAGIS 9.1 Common Components and FieldsAll of the elements in the common library of GS1 XML</p><p>For supply chain applications these can be exactly related to existing well established UN/CEFACT dictionary objects (also foundation for CCTS)Each UN/CEFACT dictionary object has explicit unique element designator UID (any new items well be assigned their own domain UID).</p></li><li><p>Part II: Using dictionary based approach as SET Tools for aligning iSURF documents in different syntax</p></li><li><p>Semantic Properties of UN/CEFACT CCTS based StandardsThe Core Components have the following semantic properties: Core Component Data TypesContextCode ListsObject Class TermRepresentation TermThe semantics that a BIE is based on a Core Component UID labelling mechanism</p></li><li><p>The Upper Ontology for the Semantics Exposed by the CCTS Framework</p></li><li><p>A Specific Instance of the Problem How to transformUBL 2.0 Forecast Instance, toGS1 XML Forecast Instance?</p></li><li><p>The first stepConvert the XSDs of these document instances to CAM templates (forms abstraction layer for inspection by XSLT tools)Extract dictionary definitions from templates into domain dictionaries; assign UID designators.Merge dictionaries into one master dictionaryCombination of name, type and OWL ontology matchingCompare to UN/CEFACT dictionary align UID designatorsAssign similar / match rules for constraints/componentsCAM xslt tool can be used to generate the dictionariesStore results in harmonized dictionary formathttp://camprocessor.sourceforge.net</p></li><li><p>CAM dictionary generation overviewXSD schemasCAM TemplatesXSLTscriptMaster DictionaryCompare &amp;MergeComponents:NameDescriptionTypeRestrictionsUID</p></li><li><p>Dictionary ToolsGenerate a dictionary of core components from a set of exchange templatesSeparate dictionary content by namespaceMerges annotations and type definitions from exchange template into dictionaryCompare each exchange template to the master domain dictionaryProduce spreadsheet workbooksUpdate spreadsheet and export back to dictionary core components</p></li><li><p>Create Dictionary CAM processSelect Dictionary; empty for new create, or existing for mergeOutput dictionary filenameSelect template content namespace to match withMerge mode; use true to combine content</p></li><li><p>Compare to DictionaryPick dictionary to compare withName of result cross-reference file</p></li><li><p>Open Cross-Reference as Spreadsheet</p></li><li><p>Explicate semantics related with the different usages of document data typesDifferent 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 standardThis knowledge in real world is expressed through class equivalences so that not only the humans but also the reasoner knows about itCode.Type Text.TypeName.Type Text.TypeIdentier.Type Text.TypeCan cross-reference via UID as well as type</p></li><li><p>Second StepHuman / OWL inspectorsDictionary alignment report produces known equivalents listing (confidence 100%), and then lesser equivalence rankings based on matching factorsComponent compound relationships resolved using CAM template structure layoutsHuman inspection then reviews and resolves and updates dictionary (using Excel spreadsheet workbook format)New dictionary producedIterative refinement over time can enhance alignment along with common practices through industry agreements</p></li><li><p>Addressing Structural Differences in Document SchemasThe harmonized ontology is effective only to discover equivalence of both semantically and structurally similar document artifacts</p><p>However Different document standards use core components in different structures</p><p>A problem in finding the similar artifacts in two different document schemas is that the semantically similar artifacts may appear at structurally different positions</p><p>This is solved using CAM templates and dictionary crosswalks on UID values along with match/similar designators and associated crosswalk rules</p></li><li><p>Example &amp; UID alignmentCAM templates + UID lookup in dictionary resolve structurally different schemas</p></li><li><p>MethodologyCAM TemplateGeneratorStructure Maps+ XPathsDictionary XMLSpreadsheet</p></li><li><p>CAM template / Dictionary / OWLSource XMLInstanceSource OWLInstanceDATA LEVELKNOWLEDGE LEVELDATA LEVELTarget XMLInstanceTarget/SourceXSD Document SchemasKnowledge BaseRule Engine &amp; ReasonerRULESXSLT ScriptSubsumptionRelationsCAM TemplateDictionary</p></li><li><p>Back to our problem: Translating iSURF Planning Documents Conforming to Different CCTS based Standards</p></li><li><p>A Specific Instance of the Problem How to transformUBL 2.0 Forecast Instance, toGS1 XML Forecast Instance?</p></li><li><p>The above equivalences are discovered through the UID dictionary cross-references and can be stored back into CAM templates section for runtime crosswalk use.</p><p>GS1.XMLUIDUBL 2.0Forecast.Indicator.IndicatorA1034Forecast.BasedOnConsensus_Indicator.IndicatorPartyIdentification.DetailsC3401PartyIdentification.DetailsPartyIdentification.Primary_Identification.GLN_IdentifierC3402PartyIdentification.IdentifierNonGLN_PartyIdentification.DetailsC3451PartyIdentification.DetailsNonGLN_PartyIdentification.Identification.TextC3452PartyIdentification.IdentifierElectronicDocument.Status.IdentifierD4310Forecast.DocumentStateCode.CodeAbstract_Forecast.Purpose.ForecastPurposeCriteriaType_CodeE0010Forecast.PurposeCode.CodeMulti_unitMeasure.Measure.MeasureF0301Dimension.MeasureAbstract_Forecast_TimeStampedTradeItemQuantity.Association.CodeE0451Forecast.Identifier.IdentiferDate_TimePeriod.EndDate.Date_DateTimeT0012Period.EndDate.Date, Period.EndTime.Time Date_TimePeriod.BeginDate.Date_DateTimeT0013Period.StartDate.Date, Period.StartTime.Time TimePeriod.DetailsT0009Period.DetailsTimePeriod.Length.Duration_MeasureT0008Period.Duration.MeasureTimePeriod.Type.CodeT0021Period.DescriptionCode.CodeTradeItemIdentification.DetailsF0340ItemIdentification.DetailsTradeItemIdentification.Primary_Identification.GTIN_IdentifierF0341ItemIdentification.IdentifierNonGTIN_TradeItemIdentification.DetailsF0342ItemIdentification.DetailsNonGTIN_TradeItemIdentification.Identification.Type_CodeItemIdentification.Extended_Identifier.Identifier</p></li><li><p>Runtime crosswalks between template structure member items</p></li><li><p>SummaryDevelop crosswalks:Convert XSD schema to CAM templatesLeverage template structure and XPath rules to build dictionaries with UID labelsBuild OWL relationships from schemaCompare each dictionary to master dictionary and reference OWL and type knowledge bases to alignProduce spreadsheet for manual reviewSave final results back to master dictionaryBuild runtime templates:Compare individual CAM templates to master dictionary, generate cross-walk section between componentsCross-walk can contain alignment rules in XPath for content handling (e.g. code values and re-formatting)</p><p>*****Given these two document artifacts, the DL reasoner rst discovers the similarities of the semantic properties of the following BBIEs: the UBL "Party-Identication.Identier" BBIE and the CCL "Buyer Party.Primary Identication.Identier" as shown in Table 1. Note that the subsumtion relationship between"PrimaryIdentication" and "Party" classes is in the opposite direction of the subsumtion relationship between "Context" and "Trade". However since theclass equivalence coming from the "Rule BBIE" is already in the harmonized ontology, the DL reasoner establishes the relationship between the UBL "Party-Identication.Identier" BBIE and the CCL "Buyer Party.Primary Identication.-Identier" BBIE as being equivalent. Furthermore, the reasoner using the class equivalence inferred by the "Rule ASBIE-BBIE", establishes the fact that the "Buyer Party.Primary Identication.Identier" BBIE is equivalent to the "Party.-PartyIdentication" ASBIE.Similarly, for the UBL "Party.Postal Address.Address" ASBIE and the CCL "Buyer Party.Postal.Structured Address" ASBIE, the reasoner discovers the equiv-alences and subsumtions among the document artifacts as shown in Table 2 in the harmonized ontology.In Table 2, the direction of the subsumtion relationship between the UBL "Address.Details" and the CCL "Structured Address.Details" classes is in theopposite direction of the subsumtion relationship between the "Context" and the "Trade". However since the class equivalence relationship coming from the "Rule ASBIE" are already in the harmonized ontology, the DL reasoner establishes the relationship between the UBL "Party.Postal Address.Address" ASBIE and the CCL "Buyer Party.Postal.Structured Address" ASBIE as being equivalent. In Figure 12, for the sake of simplicity some of the BBIEs and ASBIEs of the document artifacts, namely, the UBL "Party.Details" and the CCL "Buyer -Party.Details" are not shown. When the DL reasoner considers these extra BBIE and ASBIEs, the equivalence among the semantic properties becomes as shown in Figure 13. In other words, the BIEs (the set of BBIEs and ASBIEs) of the UBL "Party.Details" are a superset of BIEs of CCL "Buyer Party.Details".</p><p>Heuristics to Discover Structurally Dierent BBIEs: If the semantic properties of two BBIEs are pair wise equivalent or subclasses of each other,these BBIEs are considered to be similar. The rule in Figure 7 expresses this heuristics. When this rule res, it establishes an "owl:equivalentClass"property between these two BBIEs.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 issemantically equivalent to the BBIE2. The rule given in Figure 9 states this heuristics and when this rule res, it establishes an "owl:equivalentClass"property between the ASBIE1 and BBIE2.</p><p>*For discovering the similarities of structurally dierent but semantically equivalent document artifacts, we provide further heuristics. This heuristicsis 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 class equivalences in the ontology.Finally, the similarities discovered among the document artifacts are then used to automate the mapping process by generating the XSLT rules.-From XSD Document Schemas of CCTS based documents corresponding OWL Documents are created and inserted to KBHarmonized Ontology is computed and new equality/subsumption inferences are produced by means of reasoner and rule engines.The equality/subsumption definitions are mapped to the XSLT definitionsThe XSLTs are used to transform to XML Instances conforming to different standards</p><p>*</p></li></ul>

Recommended

View more >