E-Government Registry / Repository for Data Dictionary & XML Schema

1. E-Government Registry / Repository for Data Dictionary & XML Schema • Proof of Concept UK Office of eEnvoy & MOD • Leverage e-GIF & e-GMS metadata • e-Government Interoperability Framework • ebXML = Recommended • e-GMS Content Management incorporates Dublin Core • Joint Project e-Government & ebXML Registry TCs • Paul Spencer @ Boynings • Farrukh Najmi @ Sun / FreebXML Registry • Maewyn Cumming @ UK Government Cabinet Office • Carl Mattocks @ CHECKMi E-Government Registry

2. Carl Mattocks @ CHECKMi.com • Co-Chair (ISO/TS 15000) ebXMLRegistry Semantic Content SC • Co-Chair Business Centric Methodology TC • CEO CHECKMi • Multiple Agent Training Engine binding 1000 databases • Federation of Vendor Repositories • CA AllFusion, Logidex, Unicorn, Tivoli (OPC, Maestro) • BCM Compendium (.Net open source code) • Crosswalk UDDI / ebXML Registry / Local DataStore • Multiple Taxonomies, Z39.50 SRW Gateway, XACML E-Government Registry

3. e-Business Service Needs • Support communities of users – locally, regionally, nationally, internationally. • Enable industries, services and government to create service processes that support internationally agreed business process definitions, trust mechanisms and process control methods • Neutral approach not tied to specific middleware or transport systems • Use natural knowledge models suitable for wide audience not just IT support specialists • Ability to mitigate business vocabularies and multi-lingual challenges • Provide the process details to direct implementation systems E-Government Registry

4. ebXML Registry One interface (HTTP, SwA, ebMS) • Electronic Forms • Web Services / WSRP • Collaboration Agreements • Business Process Requirements, Objects, Data • Domain specific Semantics and Relationships between Assets & Artifacts • SQL queries and APIs E-Government Registry

5. Business Centric Methodology • Enables precise communication between business users and technical experts & enterprise applications and their respective business partner systems • Involves a layered approach for strategically managing artifacts and constraints while achieving semantic interoperability E-Government Registry

6. Registry D Registry E Registry B Registry A Registry C Federated e-Business Registries • BCM exploits the discovery & collaboration capabilities of Registries to ensure that assets are controlled, made visible, and shared with partners for integration. • BCM uses Registry / Repository to securely store XML artifacts (e.g. XSDs, data elements) and non-XML artifacts (e.g. Templates) E-Government Registry

7. ebXML Registry Information Model (RIM) - Classification Classificationtrees constructed with ClassificationNodes are used to define the structure of Classification schemes or ontologies RegistryObject ClassificationNode Classification RegistryEntry Association A Classification instance identifies a ClassificationScheme instance and taxonomy value defined within the classification scheme ClassificationScheme RegistryPackage ExtrinsicObject Service The structure of the classification scheme may be defined internal or external to the registry Person E-Government Registry

8. Federated Content Management Needs • A Federated Registry not only acts as an interface to a Repository of stored content, it formalizes how information is to be registered and shared beyond a single enterprise or agency. • Specifically, a federated content management capability is required when there is a need for managing and accessing metadata across physical boundaries in a secure manner. Those physical boundaries might be the result of community-of-interest, line of business, system, department, or enterprise separation. • Irrespective of the boundary type, a Federated Registry must enable information users to seamlessly access, share and perform analysis on information, including : • map of the critical path of information flowing across a business value chain; • quality indicators such as statements of information integrity, authentication and certification; and • policies supporting security and privacy requirements. E-Government Registry

9. Federated XML Schema Management Needs • Interacting organizations need re-usable data items with known semantics • These items are required as XML Schema components • The Schema (document) and the Components must be shared within and often outside the organization • Components may use external components such as code lists • Domain Components must be managed cooperatively • Core components must be common • Data definition arbitration agreements are essential • Data types must be standardized E-Government Registry

10. Registry / Repository Assemble, Populate, Use, Import / Export, Manage E-Government Registry

11. Simplex XML Government Requirements ¿ reconcile data elements that are common across lines of business ? • Enter XML Schema representations and their definitions • Manage multiple versions of schemas & associated metadata into the registry / repository • multiple collaborators e.g. UK OeE & MOD ¿ collaborate to specify elements that are truly unique and, thus, distinguish a LOB from others? • Perform a "what-if" analysis, impact of a planned change ¿suggest XML names that comport with guidance, such as that issued by DON? • Create schema documents from components E-Government Registry

12. MOD Data Dictionary - ACCORD E-Government Registry

13. Government Data Standards Catalogue E-Government Registry

14. Not-So-Simple XML Government Requirements ¿ given the "data object definitions" relate them to each other in terms of semantics, and facilitate the specification of XML tags for each element? • Present Naming Convention rules that embed International / Regional / Local concepts in Component names • Core Components Naming Convention rules (mostly based on ISO/IEC 11179 Part 5) has 3 major parts . For example, Object Class(Abstract), Property Term (valid values), Representation Term (form) • UBL Naming and Design Rules Subcommitteehave an XSD module demonstrating how to construct datatypes for code lists http://www.oasis-open.org/committees/ubl/ndrsc/current/CodeListModuleTemplate.xsd Note : Expect to discover common structures across e-Government Service Schemas E-Government Registry

15. Core Components have NO Context independent of Use – Need Business Aggregation E-Government Registry

16. Context :Core Component Classification E-Government Registry

17. Complex XML Government Requirement -Semantic Analysis of Schema and / or Components • Isomorphic meaning comparison consider if all components are the same • Domain meaning the components have same class of relationship with other components, per namespace • Standard meaning in context, as in a data dictionary • Axiomatic meaning the precondition & post condition of schema (as an abstract data type ) after a component change (axioms insert, delete) • Denotational meaning the (valuation) function e.g. two provide same result • Operational meaning the rules e.g. requires certain input to provide specific output E-Government Registry

18. Semantic Spectrum : Layers of Wisdom Business Usage Semantics System Interoperability OWL-S Ontology + Business Agreement Templates RDFS / UML / Topic Map / UNSPSC DTD / XML Schema / Dublin Core Object Oriented Model / Thesaurus Info Engineering Model Data Dictionary Data Usage Semantics Service Quality E-Government Registry

19. Registry Metadata, Repository Artifacts - Phase 1 • Enter schemas and the associated metadata • Enter schema components (global data types, elements and attributes) and associated metadata • Enter other document types with associated metadata • Hold schema definitions in a syntax-independent manner - sufficient information must be held in the registry to create the component from metadata • Metadata to be supported will vary according to the three document types (schema, schema component or other) and will be a subset of that defined in the UK e-GMS • Search on certain metadata information and extract all matching schemas, components or other documents • Construct schemas from components E-Government Registry

20. Registry / Repository Artifacts- Later Phases • Phase 2 • The ability to interoperate between Registries. • The ability to add MOD-specific metadata. • Mapping metadata via the CCRIM • Phase 3 • Incorporate Digital Signature Services E-Government Registry

21. With thankful links to : Members of ebXMLRegistry Semantic Content SC http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=regrep-semantic Members of Business Centric Methodology TC http://www.oasis-open.org/committees/download.php/5931/BCM%20Executive%20Brochure.pdf Contact: CarlMattocks@CHECKMi.com E-Government Registry