# Presentation: 586260

## 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**

## 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-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**

## 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**

## 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**

## 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)**

## ebXML Registry Information Model (RIM) - Classification

**RegistryObject**

**ClassificationNode**

**Classification**

**RegistryPackage**

**ExtrinsicObject**

**Service**

**Association**

**RegistryEntry**

**ClassificationScheme**

**The structure of the classification scheme may be defined internal or external to the registry**

**A Classification instance identifies a ClassificationScheme instance and taxonomy value defined within the classification scheme**

**Classification***** *****trees constructed with ClassificationNodes are used to define the structure of Classification schemes or ontologies**

**Person**

## 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 that 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****.**

## 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**

## Registry / Repository Assemble, Populate, Use, Import / Export, Manage

## 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**

## MOD Data Dictionary - ACCORD

## Government Data Standards Catalogue 

## 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)  h****as 3 major parts . For example, ****Object Class(Abstract), Property Term (valid values), Representation Term (form)**
**UBL Naming and Design Rules Subcommittee**** ****have an XSD module demonstrating how to construct datatypes for code lists according **
_**[http://www.oasis-open.org/committees/ubl/ndrsc/current/CodeListModuleTemplate.xsd](http://www.oasis-open.org/committees/ubl/ndrsc/current/CodeListModuleTemplate.xsd)**_
**Note :**
***Expect to discover common structures across e-Government Service Schemas***

## Core Components have NO Context independent of Use – Need Business Aggregation

## Context :Core Component Classification

## 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

## Semantic Spectrum : Layers of Wisdom

*Business Usage Semantics*

*Data Usage Semantics*

**System Interoperability**

**Service Quality**

- Data Dictionary

- Info Engineering Model

- Object Oriented Model / Thesaurus

- DTD / XML Schema / Dublin Core

- RDFS / UML / Topic Map / UNSPSC

- OWL-S Ontology + Business Agreement Templates

## 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 **

## 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**

## With thankful links to :

**Members of ebXMLRegistry Semantic Content SC**
- _[http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=regrep-semantic](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***