1 / 39

IDIOM Introduction

IDIOM Introduction. Industrial Data Integrated Ontologies and Models March 2010. Agenda. Tiny bit of background Overview of IT Framework Example Methodologies and Guidelines Impacts and Recommendations Examples Issues. May 2009 Project Resolution.

mab
Download Presentation

IDIOM Introduction

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. IDIOM Introduction Industrial Data Integrated Ontologies and Models March 2010

  2. Agenda • Tiny bit of background • Overview of IT Framework • Example Methodologies and Guidelines • Impacts and Recommendations • Examples • Issues

  3. May 2009 Project Resolution • Introduction: The PPC convened a workshop at the Parksville meeting to identify options and strategies for future SC 4 architectures. • Objective: To define the terms of reference and launch a PWI to develop a proposal for the future SC 4 architecture • Resolution: SC 4 approves a PWI on “Future SC 4 Architecture” to: • Explore the range of options for exploiting new technologies to support interoperability between SC 4 standards, and the work of other committees, operating across a range of platforms • Recommend an overall architecture for future use by SC 4 standards • Define migration paths for existing SC 4 capabilities • Identify specific licensing, commercial or other administrative barriers • Illustrate and validate any conclusions against a representative example.

  4. Today’s choice of technology resource parts OED, normative scientific and engineering references terms and definitions for people constrained exchange subsets web service definitions domain extensions XML schema + schematron OWL + named graphs OWL + SWRL CL, and other dictionary languages WSDL

  5. Underlying Objective • Propose a future architecture for SC 4 that • greatly reduces the barriers to the use of SC 4 standards in industry • reduces barriers to the use of SC 4 standards in conjunction with standards from other bodies such as the OMG and OASIS • increases the utility of SC 4 standards to industry

  6. Project Goals • Better • Put SC4 standards on a sound, logic-based, semantic foundation • Enable wider coverage of SC4 customer information and communication technology needs • Not just re-implementing STEP architecture using UML • Make knowledge and capability of existing SC4 standards more accessible • Faster and cheaper • Use widespread technologies, methodologies and approaches • Maintain/extend reuse/modularity • Support lightweight usage scenarios • Legacy • Provide migration/mapping for existing SC4 standards

  7. Put Clear Semantics at the Core Industry Extensions Reasoning SOA Standardized Core Ontologies And Mapping Data Exchange Processes

  8. Separate What from How • Specify IT Framework in which to create standards, independent of methodology • If successful, this might be used by others outside SC4 • Separately develop SC4 Methods, Guidelines and Procedures that specify how to create standards in SC4 using the IT Framework

  9. IT Framework High Level

  10. Catalogue of Natural Language Dictionaries • Catalogue of dictionaries, largely sources published elsewhere, augmented by SC4 as required (e.g IEC IEV) • Natural Language Terms and related definitions for human consumption • Not definitions of specific model elements • Relationships between natural language terms • Usages and users of natural language terms in the dictionary • Analysts deciding if an SC4 standard covers their scenario • Guides, reports, presentations, etc. explaining SC4 standards • Use cases, Activity models, concept maps, etc. used to scope, introduce or overview SC4 standards • Referenced as a 'source' from the major elements in the standard models

  11. Ontologies • 'Strong' ontologies specified using logic-based languages • Ontologies are where the semantics of concepts are defined, even if implemented in other components • Play a role similar to a 10303 ARM, only across a suite of inter-related standards, and/or role of OMG MDA Computation Independent Model • For some industry use cases, can be directly used in implementations • Modular approach, not one monolithic ontology • Contains ontological patterns, general, and domain-specific content

  12. What is a Strong Ontology? • See The Ontology Spectrum & Semantic Models, Dr. Leo Orbst MITRE

  13. Process Models • Models of industrial data processes • Not models of services like SOA • Includes more abstract models and executable models • Main purposes • scoping and providing context for service- and data-related standards • standardizing processes, or adding detail to standard processes from other organizations • These may be directly executable via bindings to execution engines (e.g. BPMN → BPEL) • using process to record provenance

  14. Simple Process Model Example

  15. Data Models • Data Models, including Weak Ontologies • support specific process such as interchange, integration, archiving and preservation, content of services, databases, etc. • More abstract models specify more general concepts • see OMG MDA PIM • More specific models specify more specific concepts and implementable models/protocols • see OMG MDA PSM • Typically scoped using a Process Model • Useful for ‘Closing world’ vs. Ontologies • Useful for specifying constraints about what data shall be recorded or is required for a specific process

  16. Service Models • Models of services and their relationships such as choreography or orchestration • Service Oriented Architecture • Web Oriented Architecture • Resource Oriented Architecture • Includes more abstract specifications • Includes Web services, SOAP, WSDL, REST, etc. • Often support a Process Model and have a Data Model (or perhaps Ontology) defining their content

  17. What’s a Service Model? • a model of the mechanisms that enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. • A service is provided by an entity – the service provider – for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider • from the OASIS Reference Model for Service Oriented Architectures

  18. Mappings and Traces • Specify and/or record the relationships between elements with and across the IT Framework components • The lines between elements in the IT Framework figure • Trace is a weaker form of relationship • Interpreted by a human in most cases • E.g. Dublin Core ‘source’ or OWL ‘seeAlso’ annotations • Mappings are a stronger form of relationship, such as a transformation • E.g. EXPRESS-X

  19. Technologies • The team developed recommendations on initial technologies to support each IT Framework component • These are just the initial recommendations • The intent is to be inclusive and the set of technologies will grow and evolve over time

  20. IT Framework More Detail

  21. IT Framework More Detail (2)

  22. Relation to OMG MDA : Terms • Computation Independent Viewpoint • The computation independent viewpoint focuses on the on the environment of the system, and the requirements for the system; the details of the structure and processing of the system are hidden or as yet undetermined. • Platform Independent Viewpoint (PIM) • The platform independent viewpoint focuses on the operation of a system while hiding the details necessary for a particular platform. A platform independent view shows that part of the complete specification that does not change from one platform to another. A platform independent view may use a general purpose modeling language, or a language specific to the area in which the system will be used. • Platform Specific Viewpoint (PSM) • The platform specific viewpoint combines the platform independent viewpoint with an additional focus on the detail of the use of a specific platform by a system.

  23. Relation to OMG MDA : Roughly

  24. Example MDA/IDIOM Overlays Natural Language Dictionary Computation Independent Computation Independent OWL Ontology OWL Ontology Platform Independent Platform Independent UML Class Diagram BPMN Model Platform Specific Platform Specific EXPRESS model BPEL Platform Specific ISO 10303-28 E2 XSD Traces or maps from

  25. Initial NLD Technology Recommendations • Since most will be non-SC4 dictionaries, no need to (i.e. cannot) mandate a technology • If NLD specifies URI, use it as NLD/NLT identifier, if not create URI for SC4 use • need to agree convention(s) for new URIs • Need agreement on computer-navigable summary/list of NLTs and which IT elements reference them (e.g. Traces to NLTs) • Default Trace is Dublin Core annotation, which can be processed to produce catalogue and term list • Catalogue technology decision not finalized yet

  26. Initial Strong Ontology Technology Recommendations • OWL, in all its flavours and versions • Based in RDF Schema and RDF • RDF/XML for exchange • Note the Semantic Web rule languages are not quite standards yet, but are an expected addition • UML Profile for OWL (or UML) for diagrams • ISO Common Logic • First Order Logic • Common Logic Interchange Format (CLIF)

  27. Initial Process Model Technology Recommendations • Abstract specifications • Similar to OMG MDA PIM • UML Activity, State Machine, Sequence etc • Business Process Modeling Notation (BPMN) • Concrete/executable • Similar to OMG MDA PSM • Business Process Execution Language (BPEL) • Foundational Subset of UML (FUML), based on PSL, is ‘executable UML activity diagrams’

  28. Initial Service ModelTechnology Recommendations • Abstract specifications • Similar to OMG MDA PIM • UML Activity, Use Case, Class/Interface • UML Profile for Service Oriented Architecture (SOAML) • Potential additional technologies • SOA Choreography, etc. • Semantic Web Service standards • Concrete/executable • Similar to OMG MDA PSM • WSDL/SOAP • RESTful services/HTTP

  29. Initial Data ModelTechnology Recommendations • Abstract specifications • Similar to OMG MDA PIM • UML Package and Class diagrams • Need to specify subset to ensure clean UML/EXPRESS mapping • Concrete/implementable • Similar to OMG MDA PSM • EXPRESS • And related 10303-20s series • XML Schema • HDF5 • Other data encoding protocols

  30. Data ModelTechnology Rationale • Use right language for right job • Abstract specification as UML because Trace from UML Process/Service Models simpler and better integrated if Concrete is UML too • EXPRESS > UML for nested aggregates so specify simple UML property in abstract and detailed EXPRESS attribute of nested aggregate in implementable • Business Object/ARM concepts appear in Ontology, not Data Model, for better semantic precision • Can have multiple data model representations for same Ontology concept, for example: • Full EXPRESS + any 20s series part for data exchange • XML Schema-only for WSDL/SOAP content

  31. Initial Mappings and TraceTechnology Recommendations • Traces • UML Trace capability • Trace is part of UML language, so part of ‘the models’ • Convention for annotation usages (e.g. Dublin Core ‘source’) • UML Comments • EXPRESS 2 Remark Tags • OWL annotations (e.g. seeAlso and DC source as RDF) • SAWSDL – Semantic Annotations for WSDL and XML • E.g. modelReference attributes • Mappings • EXPRESS-X and OMG Query\View\Transform as specifications • XSLT as an option for implementation • SPARQL and RDFS/OWL for OWL ontologies • Other computer interpretable mappings can be added

  32. IT Framework Summary • No single component is particularly interesting • IDIOM added value is how to use them together and having a strong modular set of ontologies as the core • The architecture is not yet complete • Plenty of work do to if we want to deploy this in SC4 • However, no individual component is really anything new, all have industry-proven tools and methodologies we can reuse • The component technologies are what industry uses today, in each case the following is true • For making standards, the majority of industry uses <T> to specify <C>, where <T> = technology or language and <C> = IT Framework component

  33. Methodologies and Guidelines • Where possible model elements shall have their basis in NL Terms rather than modeling artifacts • the closer the model is to real-world things the more easily it is understood • a computer navigable Trace shall be made to the NL term • Best practice is ontology as core semantics • However, encapsulation or abstraction may appear in ontology with detail in data model • E.g. matrix of measurement values modeled using EXPRESS Data Model which is ‘representation of’ simple OWL Class where concept is defined

  34. Scenarios Drive Methods • A set of possible scenarios discussed in London workshop, many are possible • Each can be driven out to produce a best practices guideline or methodology • Two examples follow

  35. Scenario : Create new and improved Ontology based on existing Data Model • Analysis of data model to determine • element are not useful in the ontology (e.g. are data modeling artifacts) • elements resulting in classes, subclass of, relationships, and/or datatype properties • Use an analysis technique to make explicit any implicit meaning in the data model (e.g. is the data model a snapshot in time, is the context of any element explicit or implicit in the model) • ‘Place’ elements with respect to existing elements in the ontology • Identify where resulting properties are subproperties • Identify any cardinality constraints that can be mapped and those that cannot • Take care of examples where moving to open world assumption causes an issue • Result is new model that does not throw away value in the existing model

  36. Scenario : Create new Ontology based on existing engineering reference manual • Create a Concept Map of the topic • This is simple enough to explain the domain back to experts • Clarify boundary of topic by including relationships to items outside that boundary in the concept map • Add definitions for implicit areas to be included in the concept map • Treat concept map as a data model and follow methodology for creating ontology from data model

  37. Practical Impacts on SC4 • Create a group/team to own and continue development and deployment into SC4 • Close down IDW as IDIOM address requirements • Methods and guides should be SC4 standing documents • No immediate impact on 15926, 10303, 18629, 13584, 22745, 15531, 29002 or any other SC4 (suite of) standards • if projects/industry are happy with ‘as-is’, no need to change • More projects using tools/languages supporting OWL/RDF and UML/XMI • Need work on tools and skills

  38. Marketing Impacts on SC4 • To sell IDIOM to industry as something ‘new and improved’, get new ISO number(s) • Framework could be Part 1 of this suite • Does not mean 15926-n or 10303-m cannot be considered as part of suite of standards under the IDIOM banner • Not just marketing, IDIOM is a different architecture from 10303, 15926, etc. • SC4 ‘press release’ on acceptance of new approaches? • Need one or more potential NWIs willing to use the new architecture in parallel to its being completed • Agreement on name - IDIOM : Industrial Data Integrated Ontologies and Models

  39. Examples • OMG PLM Service 2.0 adaptation • Common Logic for features • Ontology for Materials • Product Modeling Ontology

More Related