Jeremy Warren Federal Co-lead: UCore Development Jeremy.Warren@usdoj

1. Overview Presented to: Federal CIO Council Architecture and Infrastructure Committee Data Architecture Subcommittee 13 November 2008 Dan Green Federal Co-lead: UCore Development dan.green@navy.mil Jeremy Warren Federal Co-lead: UCore Development Jeremy.Warren@usdoj.gov

2. 9/11/2001 Attacks Need for Information Sharing • The need for improved information sharing was derived from operational requirements and lessons learned • 9/11 • Hurricane Katrina • Asian Tsunami • DOD and IC Information Sharing Initiatives • DOJ / DHS experience in Federal, State, Local and Tribal interoperability A small set of universally understood concepts can be applied across all federal agencies to achieve some level of interoperability

3. What is the Universal Core (UCore)? One functional element of the National Information Sharing Strategy An information exchange specification and Implementation profile Vocabulary of most commonly exchanged concepts Who, What, When, Where XML representation of the concepts Extension rules to allow tailoring to specific mission areas Security markings to permit controlled access, electronic tear lines Messaging framework to package and unpackage the content consistently Metadata Messaging Framework When What Who Where UCore V2.0 Conceptual Data Model

4. UCore Value UCore design excels in three areas Simplicity, context and packaging Leverage existing XML code Rapidly ported to a Web 2.0 enterprise mashup High ROI (Use in legacy or new starts) Can be implemented without a rip-and-replace strategy XML developer can have working code in a matter of days and a fully tested interface live in a matter of weeks State Local Coalition ULEX (iAlliesn) What When Where Who • Improved information sharing Reference: Government Computer News article written by Michael Daconta (http://mobile.gcn.com/articles/27_20/46900-1.html)

5. UCore Alignment with DRM

6. UCore is Driving Governace / Implementation Discussions C2 Common Core Strike CJCS Training New Policy NCES Vessel Notice of Arrival Binary – XML conversions • The UCore effort is stimulating exploratory implementations between DoD and its sister departments / agencies. • UCore is the product of highly collaborative partnering between teams such as NIEM, LEX, Strike COI, Maritime Domain Awareness and CoT.

7. Implementation Define your info sharing requirements What information do I want to exchange? Who are my data sharing partners? What level of interoperability do I desire to have? What already exists? Can UCore contribute to my materiel solution? Specific Implementation Considerations Design Considerations Data Item Structure Metadata Types Naming and Design Rules (NDR) Relationships Extensions Website Validation and Verification

8. Example UCore Implementation Approach: mule ESB Data sources: Vessel positions from the MDA DS COI City Vehicle Positions from the City of Colorado Springs Air Tracks from an FAA Archive 8

9. Extension Strategy 9

10. UCore Implementation Approach: SeaHawk What When Where Who 1 3 2 UCORE MESSAGE Vessel Activity Report (VAR) UCORE MESSAGE UCORE MESSAGE SEAHAWK SERVER NCES M2M MESSAGING SERVER UCORE MESSAGE SEAHAWK Multi-agency Intermodal Task Force Insertion of VAR into MIEM conformant UCore Structured Payload NCES distributes message to user community subscribers 4 • DoJ • DoD • DHS • State • Local User Community Subscribers • SEAHAWK multi-agency intermodal task force develops Vessel Activity Report through inputs received from Port of Charleston • VAR is sent to the SEAHAWK server for dissemination • SEAHAWK server inserts VAR into the Maritime Information Exchange Model conformant structured payload of a UCore message and enables publishing message • NCES messaging server takes UCore message, distributes to subscribers • UCore subscribers to the VAR-UCore message receive it from the NCES server 10

11. Graphical Demonstration of one UCore Implementation Approach: mule ESB • Data Sources • Automatic Identification System (AIS) – Live, 6/24 channels • City of Colorado Springs Vehicle Positions – Live, 6 agencies • FAA Aircraft Situational Display to Industry (ASDI) – Archive • Visualization Tools • Google Earth • ESRI ArcGIS Explorer • NASA World Wind • FalconView • Backend • Mule ESB • PostgreSQL • XML/XSLT 11

12. Conformance profile Levels of interoperability Semantic Representational Runtime Validation Rules and Tools UCore Validation and Conformance • Aligns with existing interagency interoperability strategies, policy, and guidance

13. Two-Pass Validation Two-pass tool to validate contents of payload and digest separately First pass: Digest portion of message validated against UCore schemas Second pass: Content of structured payload validated against the payload schema On-line tool currently in development Schematron rules may be incorporated into the tool to validate and enforce business rules

14. UCore On-line Resources Available: https://ucore.gov On line resources available: https://ucore.gov Augments DoD Metadata Registry (MDR)

15. FY09 Way Ahead • Two phased approach • Stabilization • Implementation • Pilots leading to best practices • Governance established at federal level • End-to-End processes in place • Requirements analysis through conformance validation • Identify new partners for implementation phase NOV Apr-Sep Oct-Mar FY-10 FY-09 Beta Implementation

16. DOD IM & IT Strategic Plan 2008-2009 • Ensure all semantic vocabularies, taxonomies and ontologies are developed through COIs, utilize the Universal Core, and are registered with the enterprise for visibility, re-use and understandability in the DoD Metadata Registry

17. Interagency Endorsements Value is being defined by customers and stakeholders

18. Backups

19. Design Considerations Messaging Framework Metadata DDMS ICISM UCore Core Types Major Concepts What, When, Where, Who Definitions Taxonomy Relationships Attributes Roles Message Framework Metadata When What Messaging Framework Where Who 19

20. ULEX Data Item Structure Package Package Metadata Identification, contact information, etc. Digest Standardized structured entities, roles, and associations Foundation of run-time interoperability Structured Payload Based on independently created schemas Can be ignored if not recognized/understood/implemented by consumers Provides framework for extensibility Narrative Unstructured (text) data XSLT or pre-rendered (e.g., PDF) attachments Rendering Instructions Can reference content in un-recognized structured payloads Foundation of interoperable display (human understanding) Attachment Link Semantically rich associations (e.g., facial image, SMT image) Package Package Metadata Digest Structured Payload Narrative Rendering Instructions Attachment Link Message Framework 20

21. Metadata Metadata Can be applied to anything in the framework / model Message Package Element UCore draws distinction between content metadata and resource metadata Resource metadata is captured via DoD Discovery Metadata Specification (DDMS) Useful for automated search and discovery Security Tear-line security markings via ICISM Metadata 21

22. UCore Core Types Captures “who”, “what”, “when” and “where” These are the constructs that reside within the Digest These constructs capture key entities, events, locations, and relationships/roles between them for an information exchange What When Where Who 22

23. Naming and Design Rules Simple set of naming and design rules These rules do not necessarily hold for types imported from namespaces that are not controlled by the UCore development team (e.g., ULEX, DDMS, ICISM, or StructuredPayload extensions) All simple and complex XSD types are UpperCamelCase All elements are UpperCamelCase All attributes are lowerCamelCase xs:ID attribute for UCore elements is intended as a referencing mechanism and is not to be used as an information-bearing attribute nor is it unique across UCore Message instances UCore Digest is fixed and should not be changed under any circumstances. Extensions can be created that extend from the UCore core types, all extensions should be placed in the StructuredPayload. 23

24. Relationships RelationshipType serves as the base type for all relationships in UCore Substitution groups used throughout Defines a series of abstract relationship types from which the concrete UCore relationships inherit For each relationship: Time and Metadata are both optional Each participant can specify a role Number of participants is limited to two References are performed via IDREFS UCore has the following relationship type hierarchy: Abstract types Concrete implementations Note: Not all of the abstract relationship types have concrete implementations. 24

25. Example Instance 25

26. UCore Extensions UCore is designed to facilitate extensions More detailed and complex exchanges can be created within the StructuredPayload while still maintaining the ability to share information with the wider UCore community As an example, the StructuredPayload above augments the Digest from the previous slide using the Maritime Information Exchange Model (MIEM) Extended information should always reside in the StructuredPayload, not the Digest 26