Using a metadata registry for e-Document engineering

1. Using a metadata registry for e-Document engineering PilotActivity Registration OriolBausàPeris – Invinet Natacha Dewyngaert – PwC EU Services Stijn Goedertier – PwC EU Services Vianney le Clément de Saint Marcq – PwC EU Services

2. “Standards are like toothbrushes, a good idea but no one wants to use anyone else's” - Anita Golderba

3. e-Documents are used in message-based application integration • File transfer: Applications are capable of exporting and importing files in a format that other applications can consume; • Shared database: Applications are integrated by having them produce and consume their data in a single shared database; • Remote procedure invocation: Applications have procedures that encapsulate data and that provide an interface to allow other applications to interact with the running application and exchange information. • Messaging: Applications exchange messages (e-Documents) using a common messaging system and using common formats. Source: Hohpe & Woolf, 2003

4. Definitions • e-Document:any document in electronic format containing structured data (and possibly also unstructured data) exchanged in the context of an administrative process. • e-Document format: is a specification that lays down the syntax (structure) and semantics of a particular type of e-Document. • e-Document engineering method: a discipline for specifying, designing and implementing the documents that serve as the interfaces to business processes (Glushko & McGrath, 2005).

5. Mapping Core Person to UN/CEFACT CCL and UBL 8 of the 20 properties are a close match for the three vocabularies. The Core Person Vocabulary reuses only 1 element from the UBL (familyName), although Core Person has been generated according to the UBL Naming and Design rules.  Libraries of standardisation bodies still incomplete.  It is not clear how different libraries could be reused.

6. Do we need to create a common library now? • PROS • Cross-sector interoperability: one library of data elements is the Holy Grail… it allows for the reuse of harmonised e-Document formats in different contexts (e.g. eHealth and social security context). • CONS • Legacy: we cannot go against 40 years of standardisation. Each domain has its own standard method and library of data elements. • Maintenance: creating a new library would not be sustainable and is not likely to be used.  ALTERNATIVE: Metadata Registry of data elements (based on ISO 11179-3)… to bridge different libraries.

7. Metadata Registry: use cases • Library of data elements: • Publish libraries of data elements and create links between them. • Search for data elements... and explore the use of data elements in different contexts. • Functional specifications of e-Document formats: • Publish the requirements, information model, and business rules in the context of an e-Document specification and create links between them • Facilitate syntax binding / schema creation... (this will be implemented as a SPARQL select query on the triple store). • Facilitate the creation of documentation on a particular XML Schema (e-Document specification) http://mdr.testproject.eu

8. Generic blueprint of an e-Document engineering method Metadata Registry Library of data elements (ISO11179-3) Functional specifications of e-Document formats (CEN/BII templates)

9. 1. Requirement gathering The first step is to precisely define the objective of the business process. • Goals: describe specific goals to be achieved with the exchange of e-Documents • Scope: describe the scope derived from the goals • Key examples: describe key examples as real-life scenarios to depict the business process flow • Specific requirements: gather specific requirements that e-Documents must fulfil linked to the goals http://mdr.testproject.eu

10. 1. Requirement gathering • Goals http://mdr.testproject.eu

11. 1. Requirement gathering • Scope http://mdr.testproject.eu

12. 1. Requirement gathering • Key example http://mdr.testproject.eu

13. 1. Requirement gathering • High level requirements http://mdr.testproject.eu

14. 2. Information modelling This phase identifies and describes the information to be exchanged in e-Documents according to the requirements specified in the first step. • Capture business terms in an information model describing the explicit semantics of every data element: attributesand cardinalities • Describe the relationships between information components and requirements • Depict information model requirements using a conceptual modelling language (ISO11179 MDR) • Identify and reuse semantics and concepts from standard vocabularies where possible http://mdr.testproject.eu

15. 2. Information modelling

16. Data element concept Registered Organization Legal Name Conceptual domain Text has Conceptual level expresses Representational level represents 2. Information modelling Data element Registered Organization Legal Name String Value domain Text as a Unicode string represented by • The ISO 11179-3 meta-model http://mdr.testproject.eu

17. contains Value meaning Growing of rice DE concept Reg. Org. Activity Conceptual domain Economic Activity Value meaning Weaving of textiles Value meaning Construction of water projects has 2. Information modelling has Conceptual level Representational level Permissible value A01.12 has Permissible value C13.20 Data element Reg. Org. Activity NACE Code Value domain NACE Code Permissible value F42.91 contains http://mdr.testproject.eu

18. 3. Business rules definition In the previous step (information modelling) the business terms and facts were described. However, there are still action assertions, constraints and derivationsconcerning some aspects of the e-Document. These business rules are described according to the goals and requirements of the first step. • Identify integrity constraints on the information model and describe them as business rules • Define inferences and mathematical calculations that the e-Document elements must fulfil • Define conditional business rules and co-occurrence constraints that e-Document elements must fulfil • Define sets of allowed values for coded data elements

19. 3. Business rules definition http://mdr.testproject.eu

20. 4. Syntax binding (reuse) Syntax binding is one of the options to produce physical artefacts in order to help developers implement the e-Documents according to the e-Document format rules. With syntax binding, the information requirement model is mapped to an existing syntax model and the usage guidelines are specified. • Map the information model to a standard syntax when this syntax fulfils most of the goals and requirements of the project • Create a usage guideline on the syntax for implementers • Create validation artefacts for business rules and code lists • List minor gaps and/or requirements that cannot be fulfilled using the selected syntax http://mdr.testproject.eu

21. 5. Schema production (partial reuse) The second option is to produce a new e-Document format. This option should be followed when there are no recognized international standards for the industry and business process the project is targeting. • Map common information model components to available Common Vocabulary schemas (e.g. ISA Core Vocabularies, UBL common library, UN/CEFACT Core Components Library) • Create new e-Document formats using a standard NDR to automate the schema production • Create validation artefacts for business rules and code lists http://mdr.testproject.eu

22. 5. Schema production (partial reuse) • XSD Schema: BusinessActivityRegistrationRequest.xsd <?xml version="1.0" encoding="UTF-8"?> <!-- Library: Business Activity Registration Request document demonstration Module: xsd/mydoc/BusinessActivityRegistrationRequest.xsd Generated on: 2014-03-06 16:31z --> <xsd:schemaxmlns="urn:X-MyCompany:xsd:MyBusinessActivityRegistrationRequest" xmlns:mya="urn:X-MyCompany:xsd:MyRARequestResponse:AggregateComponents" xmlns:myb="urn:X-MyCompany:xsd:MyRARequestResponse:BasicComponents" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ccts="urn:un:unece:uncefact:documentation:2" targetNamespace="urn:X-MyCompany:xsd:MyBusinessActivityRegistrationRequest" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1"> <!-- ===== Imports ===== --> <xsd:import namespace="urn:X-MyCompany:xsd:MyRARequestResponse:AggregateComponents" schemaLocation="MyRARequestResponseAggregateComponents.xsd"/> <xsd:import namespace="urn:X-MyCompany:xsd:MyRARequestResponse:BasicComponents" schemaLocation="MyRARequestResponseBasicComponents.xsd"/> <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" schemaLocation="../../xsd/common/UBL-CommonAggregateComponents-2.1.xsd"/> <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" schemaLocation="../../xsd/common/UBL-CommonBasicComponents-2.1.xsd"/> <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" schemaLocation="../../xsd/common/UBL-CommonExtensionComponents-2.1.xsd"/> http://mdr.testproject.eu

23. e-Document engineering: tools

24. SEMIC 2014 – Athens, 9 April http://semic.eu

25. ISA Programme Action 2.15 – e-Documents and e-Files Project OfficerSuzanne.Wigard@ec.europa.eu • ContractorsStijn.Goedertier@be.pwc.com • Nikolaos.Loutas@be.pwc.com Visit our initiatives • Get involved Follow @SEMICeu on Twitter Join SEMIC group on LinkedIn Join SEMIC community on Joinup