SC4 Future Architecture Workshop

1. SC4 Future Architecture Workshop Second PWI Workshop London, UK October 18-19, 2009 David Price David Leal Co-Chairs

2. Agenda • Day 1 • Welcome and Introductions • Walkthrough of Overview Presentation • Day 2 • Input to/Review of IT Framework Components • Input to/Review of SC4 Methods and Guidelines • Input to/Review of Examples • Plan for Rotterdam

3. SC4 Future Architecture Introduction A Brief Introduction to the Proposed SC4 Future Architecture October 2009 David Price

4. Background • For several years participants from ISO TC184 SC4 “STEP” have been migrating to OMG, OASIS and other standards bodies • For several years various SC4 people have made presentations on why … basically that SC4 is stuck in the mid-1990s and the rest of the world has moved on • 2009 NIST funded a “STEP for Engineering Enterprise Integration”

5. NIST “Future STEP” Project Goals • To enable enterprise integration based on inter-related data exchange, ontology and service specifications • To enable the selective harvesting of ISO 10303 (aka STEP) standards into ontologies and other widespread modeling languages via OMG Model Driven Architecture ™ approach • ISO TC184 SC4 STEP community has been creating data exchange information models for 20 years – lots of knowledge, lessons learned and capability there • With possibility of ISO STEP harvesting improvements made in OMG and W3C back into its standards • May lead ISO STEP to adopt OMG & W3C technology

6. Near-Term Goal - Harvesting STEP Industry OMG Future STEP Project ISO OMG EXPRESS STEP EXPRESS Schemas ODM/OWL Reasoner Harvesting Process, Specs & Tools OWL Reference Data UML Profile for EXPRESS STEP as UML UML 2 Tool & Executable UML Data APIs & Services Inter-related suite of stds Software Systems Integration XML Schema

7. End Goal – New ISO STEP Approach Industry Extensions Reasoning SOA Standardized Core Ontologies And Mapping Data Exchange Processes

8. SC4 Future Arch PWI • In May 2009 SC4 initiated a project to propose an SC4 future architecture • Deliverables • A proposed architecture for SC4 standards • An example done using the proposed architecture • A paper/report on making SC4 standard content freely available • Deadline : November 2009

9. resource parts Today’s choice of technology 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

10. Project goals • Better • Put SC4 standards on a sound, formal, semantic foundation • Enable wider coverage of SC4 customer information and communication technology needs • 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

11. Approach • Enable a suite of SC4 standards taking a knowledge-based approach with formal, semantic models at its core • A “green field” approach to the architecture and standards • Not just re-implementing STEP architecture using UML tools • ISO 10303, ISO 15926, etc. can continue to be extended if industry so chooses • i.e. Not “the only” architecture used in SC4, instead it's “the new and improved” additional architecture • Evolve and grow over time, do not have to migrate every thing in SC4 at once (or ever, for that matter)

12. The SC4 Architecture Elements • An SC4 IT Framework in which to create standards • SC4 Methods and Procedures that specify how to populate the SC4 IT Framework • An SC4 Framework of Concepts that is the basis of the formal models

13. IT Framework Components • Library of Natural Language Dictionaries • Formal models of general and discipline-specific concepts • Process models and implementation bindings • Data models and implementation bindings • Service models and implementation bindings • Mapping and Traces between elements within and across components

15. Library of Natural Language Dictionaries • Libraries of dictionaries, largely sources published elsewhere, augmented by SC4 as required (e.g IEC IEV) • Terms and related definitions for human consumption • Not definitions of specific model elements • Relationships between terms • Usages and users of 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

16. Logic-based Models • Specified using languages with formal semantics • Concepts and their relationships which begin at a generic level with a series of levels of increasing specificity • Specializations and extensions to general models to support discipline-specific requirements • Can address some industry use cases directly • e.g. Semantic Web-style uses, data aggregation or federation, reasoning • Need not be decidable (e.g. OWL Full) • The SC4 Conceptual Model Framework • With lessons learned from 10303,15926, etc. applied • Example : A quantities and units ontology

17. Process Models and Bindings • Models of the processes that act on the world (e.g. create or consume data) • Not models of services like SOA • Two main purposes • scoping and providing context for 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

18. Data Models/Bindings • Logical data models (e.g. EXPRESS, UML) • Data models (e.g. XML Schema) • Purpose is to support interchange, integration, archiving and preservation, content of services, databases, etc. • ISO 10303 is an example • Typically scoped using a process model • Bindings are to text files, XML files, etc., including from logical data models • ‘Closing world’; Adding constraints about data shall be recorded

19. Service Models and Bindings • Models of services and their relationships such as choreography or orchestration • Service Oriented Architecture • Web Oriented Architecture • Resource Oriented Architecture • Bindings are to Web services, SOAP, WSDL, REST, etc. • Often support a process model and have a formal model or data model defining their content

20. Mappings and Traces • 'Mapping' was too strong a name as the relationship semantics may only be human-interpretable, so now ‘Mapping and Trace’ • Specifications of the relationships between • model elements in different IT architecture components (e.g. data model element represents formal model element) • model elements within an IT architecture component (e.g. data model element A can be transformed to data model element B or can be represented by XML binding for A) • references to terms, dependencies, etc. • May be formal or informal, but always computer navigable • Example of formal : EXPRESS-X, QVT, XSLT, SQL, STEP Mapping Tables, Graph Transformation Languages • E.g. MEXICO stuff is example (EXPRESS->UML) • Profiles of UML (e.g. SOAML, SysML) • Examples of informal : 'source' or 'seeAlso' annotations

21. Technologies • Approach is to be “inclusive” with respect to technologies, particularly for implementation • Need to allow elements to be glued together as required for mapping, migration, source, etc. • OMG MDA identified as strong candidate, particularly for the more detailed components • The core Dictionary and Formal Model technologies are the first priority as the more detailed components will likely require a support for a wide variety of technologies

22. Initial Candidate technologies • Dictionary : Natural language, SKOS, Concept Maps, Topic Maps, Controlled Natural Language, ISO 11179 Metadata Registry, ISO 22745 • Formal models : OWL, ODM, Common Logic, Controlled Natural Language • Data models : EXPRESS, UML, E/R, MOF DSL, ORM • Serialization bindings : XML Schema, XML, P21, JSON, YAML, HDF5, RDFa, SQL • Process models/bindings : UML, BPMN, UPDM, BPEL • Service models/bindings : UML, SOAML, WSDL, REST • Mapping : Controlled Natural Language, EXPRESS-X, QVT, TGG, XSLT, OWL

23. Initial IT Recommendations • List for initial report, not final SC4 suite of IT • Library – Decision not final • Formal Models – OWL and ISO Common Logic • Data Models – UML, XML-related languages and EXPRESS • Service Models – UML, and perhaps soaml • Process Models – UML, and perhaps BPMN • Mapping and Trace • Trace – Specific technology for each component that can be processed into a common form for navigation and query (e.g Dublin Core, SKOS, SAWSDL)

24. Concluding questions • Are we missing any architecture components? • Are we missing good candidate technologies for use in any architecture components? • What criteria should we use to evaluate candidate technologies? • e.g. maturity, cost, tool availability • How does SC4 publish standards for various components now? Is the model as the standard sufficient? • For example, is OWL with annotation properties enough or must we also publish a document?

25. Contacts • Public Future Architecture Wiki • http://FutureArch.wikispaces.com • SC4 Sharepoint • http://sp.tc184-sc4.org/SC4Projects/FutureSC4Arch/default.aspx • SC4 Email Exploder: • SC4_FutureArch@tc184-sc4.org