Dr Glenda Hayes MITRE/DISA PEO-GES 9 Oct 2008

Dr Glenda Hayes ghayes@mitre.org MITRE/DISA PEO-GES 9 Oct 2008
DoD Metadata Registry Presentation to Federal Data Architecture Subcommittee Dr Glenda Hayes MITRE/DISA PEO-GES 9 Oct 2008

DoD Metadata Registry and Clearinghouse (DoD MDR)
Agenda Net-Centricity DoD Net-Centric Data Strategy What is Metadata? Structural and Semantic Metadata Discovery Metadata DoD Metadata Registry and Clearinghouse (DoD MDR)

Net-Centric Tenets Recipe for Agility DoD Net-Centric Data Strategy
Information Assurance Strategy Core Enterprise Services (NCES) Global Connectivity (Transformational Communications) The DoD has identified 4 net-centric tenets that facilitate agility – the ability to more rapidly respond to known and unknown threats and opportunities. Today’s presentation will focus on the DoD Net-Centric Data Strategy and NCES (a DoD program for providing common Core Enterprise Services). Recipe for Agility

DoD Net-Centric Data Strategy
JA0074C.4 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom DoD Net-Centric Data Strategy The DoD Net-Centric Data Strategy, issued by the DoD CIO May 9, 2003, is the plan to make the Department’s information resources: Visible Is an information resource discoverable by most users? Is it available on the network, and are tools readily available to use it? Accessible Can it be intelligibly used? Are the semantics well documented? Understandable Are the source, security level and access controls of the data available to users? Trusted The Department’s approach to net-centricity has been set forth in a documented called the DoD Net-Centric Data Strategy. It was signed out by ASD NII on 9 May This strategy lays out the six clear-cut actionable goals shown here. The questions beside each goal clarify the intent of each goal. Interoperable Can it be combined or compared with other information? Can it be mediated? Responsive Is the data what users need? Are robust user feedback mechanisms in place to improve it? CC/S/As must institutionalize processes to accomplish these goals 4

Quiz: Which of these is Metadata?
 An XML Schema? A WSDL? A database structure? A picklist? An index card in the library? MS-Office product’s properties? classification and release conditions? Notes on the back of a photo? iPod playlist? Date and reviewer for a taxonomy? Product ratings & comments on Amazon?       Metadata is key to accomplishing these goals. However, one person’s metadata is another person’s data. Most people would agree that the black check marks represent metadata. However, the gray check marks can be argued either way (data or metadata). The DoD Net-Centric Data Strategy specifically discusses 3 types of metadata: structural, semantic, and discovery.   

Metadata Supports NCDS Goals
Analogy Structural & Semantic Resource Topical Assertions Visible a Accessible Understandable Trusted Interoperable Responsive book Information Resource = index card Title: ~~~~~~~~~~ Description: ~~~~ ~~~ ~~~ Author: ~~~ ~~ ~~~~~~ Subject: ~~~ ~~~ ~~~~ Resource Metadata = template, dictionary, thesaurus The NCDS specifically addresses Resource (or discovery) Metadata and Structural and Semantic Metadata. The library analogy helps us get on common ground for understanding these terms. As shown on the right, these 3 types of metadata support each of the 6 NCDS goals. (click) Understand that there are other types of metadata and they also contribute to the NCDS goals. These other types of metadata will not be discussed in this brief. Structural & Semantic Metadata =

PEO – GES Data Services Office
JA0074C.7 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom PEO – GES Data Services Office Mission Provide tools, techniques, and performance standards to enable the DoD Data Strategy Support DISA DoD Data Strategy compliance effort Products & Services Chair DoD Metadata Working Group Provide NCES Metadata Services support Oversee operation of the DoD Metadata Registry Develop and promote Data Strategy Enablers for Communities of Interest (COIs) Provide Data Strategy input to NCES Acquisition Milestone Documents Support NCES Product Branch, Testing & Evaluation, Operations, Sustainment, and NetOps activities Support DISA CIO in extending the Enterprise Information Environment (EIE) technical procedures and standards for DISA internal systems I support DISA PEO-GES as the Tech Lead for the Data Services Office. Ken Fagan is the Branch Chief for Data Services. The mission, products, and services are oriented to enabling the NCDS. I want to call attention to the terms in blue. These will be discussed in detail. Additional questions, please use the Comments and Feedback link at

Make Data Understandable
JA0074C.8 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom Make Data Understandable One reason Government Agencies and Military Services have trouble operating jointly is that they speak different languages. “I need a tank” What does it mean? Registering and using taxonomies improves precision search and recall Register Terms, Definitions, & Relationships

DoD Metadata Mgmt Engineering-level Processes
JA0074C.9 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom DoD Metadata Mgmt Engineering-level Processes Namespace Managers & WGs DISA Data Services Office Namespace Managers & WGs Namespace Managers & WGs Governs/Coordinates Within Namespace Operates, Maintains DoD Metadata Registry Hosts Participates in Consults, Subscribes to & Submits to/Downloads from Metadata Registry Discusses This graphic illustrates shows the engineering-level processes the DSO is involved in to support the DoD Net-Centric Data Strategy. I will elaborate on each of these in the remainder of the brief. Participates in DoD Metadata WG DOD Developer DoD MDR Focus Group DDMS Focus Group Taxonomy Focus Group

MDR Governance Namespaces
Distributed Configuration Management 7 “Super” Namespaces

DoD MDR v7.0 Public areas Public areas

Advanced Search

Search Results ratings Add to Briefcase

Information Resource Details
User-defined URLs

Navigate through Relationships
JA0074C.16 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom

MDR Support for Mediation
JA0074C.17 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom MDR Support for Mediation tacrep.xml ebXML Registry Query service schemaLocation=“.../tacrep.xsd” tacrep.xsd (schema) HasXSLT tacrep-2-kml.xsl (stylesheet) MDR Organizes Components for Mediation notional tacrep.kml Leverage Registered Components & Associations 17

DoD Metadata Registry (MDR) https://metadata.dod.mil
Purpose Provide an on-line repository which enables developers to reuse, understand, integrate with, and share existing data assets (metadata) Targeting web services, databases, and vocabularies Mandated for the publishing of semantic and structural metadata DOD Directive Provides a portal for developer access and web services for machine-to-machine access Key Facts Over 8,000 users and 180,000 assets registered Over 900 Programs of Record supported Serving the DoD, DHS, IC, NASA and NATO Hosted on NIPR, SIPR, and JWICS (in progress) User driven via DoD Metadata Working Group and Feedback links Implements the ebXML standard for Metadata Registries (in DISR) User Name/Password or Single Sign-On through DKO Governance structure provided by Joint Enterprise Services ERB Primary Benefits Enables reuse and governance of data assets Foundation for other services; e.g. mediation Allows the COI data assets to exist after the COI disbands Primary Audience DoD Capability Developers, COIs The DoD Metadata Registry is the Department’s electronic marketplace for structural metadata components. It provides enterprise-wide visibility and access for developers, configuration controllers and program overseers to register, use, subscribe, and manage structural metadata. The purpose of the Registry is not to publish broadly applicable standards, but to provide visibility into the Department’s ongoing structural metadata investment, and to encourage reuse of existing metadata components that are both developmental and operational. While each registered component is identified with its status and distinguished by a namespace, the Registry’s purpose is to allow developers to pull whatever they need; not to try and mandate usage of any particular metadata collection. The benefits to the developer, reductions in cost, time savings and interoperability have proven to be sufficient incentive. The public may access a portion of the DoD Metadata Registry via the Internet. To examine metadata artifacts, users must be sponsored by a government employee. The contents of the Metadata Registry are organized by governance namespaces within various metadata type “galleries.” Communities of Interest (COIs) should align with and leverage collections within one or more namespaces that intersect their concerns. Top Secret instance is run in conjunction with the Intelligence Community.

DoD MDR History DoD XML Registration Memo
MDR Implements ebXML RIM & RS DoD Metadata Registry MDR on SIPR COE XML Registry v6.1 v2.1 v5.0 v7.0 v3.1 v4.1 v1.0 2000 2002 2004 2006 2008 = COE XML Registry IOC = Name Change: DoD MDR = DoD XML Registration Memo = SIPR MDR = INT Namespace Established = ICISM v1 registered = JWICS MDR (planned start) = JWICS MDR (actual start) = ICISM v2 registered = MDR v6.1 = MDR v7.0 IC Info Sharing Data Standards Coordination Activity (DSCA )

JA0074C.20 BM6710 AL 3/28/2017 12:37:02 AM3/28/2017 12:37:02 AM Marcom
MDR Users Developers Re-use and subscribe to registered data components, and/or register new ones they have created Community of Interest (COI) Metadata Governors Configuration Manage (CM) registered component (e.g., posting new metadata versions, version change notification etc.) Acquisition Policy Makers Use Metadata Registry metrics for acquisition oversight (e.g., reflecting program participation, specific data component re-use etc.) Applications Interface with registered components via Metadata Registry Web Service (ebXML) to exploit reference tables, transformations, and XML schemas at Run Time First the Build-Time. Who specifically are Players, (producers and consumers who are using GES information market services? ) This is the way we taking care of our information system builders and maintainers. We provide sharable data components under a configuration control process that’s broader than just one system. We provide our systems acquisition oversight at various levels with some “hard facts” about who’s doing what with the various sponsors’ monies. From a system builders point of view, the incentives for being in this market are: (1) reductions in risk, cost and schedule with respect to fielding interoperable capabilities (2) the possibility of having some of his data components gain market share and become key infrastructure that sponsors are willing to sustain. We’ve seen COTS vendors respond to these pressures where Oracle, SyBase and Microsoft have all segmented products to become viable in the COE infrastructure market.

Unclassified MDR Inventory
MDR Size and Scope Instances on 2 security enclaves Unclassified and Secret Users – 10,186 Information Resources Submission Package – 1,263 Schemas (e.g., DTD, XSD, etc) – 4,814 Translations (i.e., XSL, XSLT) – 180 Services (i.e., WSDL) – 555 XML samples – 251 Taxonomies (i.e., OWL) – 178 Reference Data Sets – 5,709 Amplifying Documents (e.g., DOC, ER1, etc) – 5,268 900 Programs of Record, 700 Organizations Unclassified MDR Inventory as of 8 Oct 2008

Making Data Visible, Accessible, and Understandable through Metadata
JA0074C.22 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom Making Data Visible, Accessible, and Understandable through Metadata Federated Search Interface NCES Enterprise Catalog Defense Online 3 Register discovery metadata IAW DDMS in Federated Search-enabled Catalog warfighter Audience: warfighter, intelligence, business user Audience: developer, application program NCES Service Registry 2 Register service metadata & endpoints Uses registered resources developer Web Interface (HCI) Lately, we’ve conducted some training sessions to assist COIs in their efforts to use the NCES capabilities. These training sessions start with a notional web service that has been created and goes through the steps necessary to make the data visible, accessible, and understandable. We are taking the lessons learned from these training sessions to produce training documentation that DISA will publish and maintain. 1 Construct & Submit Package to MDR. Contains WSDL, schemas, stylesheets, taxonomies & any other pertinent information DoD Metadata Registry Data Store Web Service MDR Submission Pkg

Net-Centric Publisher
Service Endpoint DDMS WSDL XSD For more info: Simplifies Metadata Publishing

Practical Utility for Taxonomies
JA0074C.24 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom Practical Utility for Taxonomies Applicable for Content Services Structural Metadata Aid precision search via DoD Discovery Metadata Specification (DDMS) Country.sql ISO.xsd FIPS.xsd As is observed in 11179, Part 2, classification schemes have utility for organizing. In DoD, we are using vocabularies/taxonomies for organizing content (via OWL in DDMS), services (currently via tModels), and structural metadata (via the MDR processes). The terms in blue are actual terms from the DoD Core Taxonomy. The items in the 3 yellow boxes are representative of some of the components registered in the DoD MDR. In the next few slides, I’ll show screen captures for associating these registered artifacts using the taxonomies registered in the MDR. <ddms> : <Subject>…/DoDCore#Terrorist_Event</Subject> </ddms>

MDR Support for Taxonomies
JA0074C.25 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom MDR Support for Taxonomies DoD Core taxonomy Organization PoliticalOrganization MyCOI taxonomy UrCOI taxonomy Group TerroristOrganization equals ForeignTerroristOrganization TerroristGroup Since we know that producers and consumers will not always share a common vocabulary, we’ve developed a strategy for filling in the Subject slot. We’ve selected OWL as the syntax for taxonomies and their cross-references. We’ve also added a Taxonomy Gallery to the Metadata Registry for COIs to register their taxonomies. The Taxonomy Gallery will provide the plumbing for search processes to match consumer requests to producer offerings. Using this strategy, we hope consumers will able to find information resources that were published using terms from a different taxonomy. equals AlQaida al-Qaeda Producer View Consumer View <ddms> : <Subject>…/MyCOI.owl#AlQaida</Subject> </ddms> 25

DoD Core Taxonomy v0.75c

UCore v2.0 Default Taxonomy

FEA-BRM as OWL-encoded Taxonomy

Framework for Registry Interoperability
JA0074C.29 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom Framework for Registry Interoperability   Inter-Registry Object References Federated Queries Enterprise Search Aggregator Service MDR UDDI MDR DDMS-based Query Service Architecture Products  Centralized Authority w/Local Caching Object Relocation More attention needed MDR We were also asked to discuss federations. Since that word has been overloaded and is now ambiguous, we have adopted the OASIS Cooperating Registries Model as our framework for registry interoperability. The model identifies 4 modalities that most registries must support. Although the model was developed to assist in the development and coordination for the OASIS ebXML Registry TC, we feel it can be used outside the context of any particular standard. In this diagram, we show the MDR in the context of each of the 4 modalities. Notice that although we do recognize that more attention is needed in the object relocation modality. Inter-registry Object References One registry contains an object that is associated with an object in another registry; e.g., a UID/key field/URL pointing to the actual object. Federated Queries A “federated” query is submitted to a registry. That registry then submits a “local” query to all of its confederates. A “local” query is not forwarded. Central Authority w/Local Caching Objects are “owned” by a single registry. However, replicas can be created in other registries; e.g., to improve access time or to distribute hotly contested objects. Replicas can only be created and deleted. All other life cycle operations must be performed upon the original object. Updates can either be propagated by event notification generated from the original registry, or by periodic polling by the replicas’ registries. Object Relocation An object in one registry can be relocated to another registry within or outside a federation. However, referential integrity then becomes an issue. References to the original object address must be updated to refer to the new object address. Example: US Post Office change of address form and process. The old registry will automatically forward requests for a while. The registry will also inform the requester to update their references. Eventually the requestor will get an “object not found” fault. (U) MDR Unclassified fully automated push  Online Package Registration (U) MDR (S) Secret (TS) (S) (U) MDR Top Secret USTRANSCOM USMTF Adapted from OASIS Cooperating Registries

Useful Links DoD CIO Data Strategy Homepage DoD Metadata Registry
DoD Metadata Registry DoD Discovery Metadata Specification NCES Techguide NCES Developer Community COI Toolkit Intellipedia

UNCLASSIFIED UNCLASSIFIED

Make Data Visible “Documents” Web Services Documented via
JA0074C.32 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom Make Data Visible “Documents” Documented via Keyword, Text, RSS/Atom, DDMS Metadata Cache (traditional) Search Index, OpenSearch (RSS/Atom) Syndication Feed, Google Data API (DDMS) Metadata Catalog, Federated Search Service Web Services Documented via WSDL + XSD(s) Metadata Cache ebXML Registry UDDI Registry Styles SOAP REST REST Goal 1 – Make Data Visible Visibility helps users become aware that data or service exists. It is completely reasonable that users may discover data or services that they will not be able to access. Data Access is treated separately. Generally speaking, data is accessible via a document or via a web service. For this discussion, a web service refers to a method for applications to talk with another application. The term ‘Documents’ is in quotes to reflect that data may appear to be stored on a file server as a static document, but in effect, be serialized (often from a db) on demand. When the data is serialized as XML and the transport protocol is HTTP or HTTPS, and the URL is used to pass parameters, this constitutes a REST-ful web service. Unlike SOAP applications that require a SOAP client specific to the particular SOAP service, a REST-ful web service can be called with a web browser (no special client is required). This blurs the distinction between the Documents and Web Services. The DoD will continue to pursue visibility using popular internet technologies like traditional search (think Google and Yahoo) and blog formats like RSS and Atom. DoD and IC are also pursuing a highly faceted search strategy based on the DoD Discovery Metadata Specification (DDMS). We’ll discuss this more on the next slide. Services will be visible to developers and applications through metadata and service registries. The WSDL and XSD that describe the service operations and request/response structures are visible via the DoD Metadata Registry. The endpoints (the URL that an application would call to execute the service) are visible via the Service Registry. REST = HTTP/HTTPS + URI + XML

DoD Discovery Metadata Specification (DDMS)
JA0074C.33 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom DoD Discovery Metadata Specification (DDMS) IC: ISM Configuration managed by DoD Metadata WG ISO: Dublin Core * ISO: Dublin Core * ISO: Dublin Core * ISO: Dublin Core * ISO: Dublin Core Data Catalog (historical) W3C: Date & Time ISO: Dublin Core ISO: Dublin Core ISO: Dublin Core ISO: Dublin Core W3C: OWL DDMS endorsed by Executive Order 13388 Before data can be shared, it must be visible. DoD has been working very closely with the IC to develop and configuration manage a profile of Dublin Core called the DDMS. The spec and the XSD reference implementation is managed by the DoD MWG. Think of this as the template for the index cards in the library – on steroids. We seek to identify relevant standards and import discrete versions, leaving the configuration mgmt to those organizations. For example, we have added security classification, adopting the Intelligence Security Metadata standard from the IC. We have added GeospatialCoverage, working with NGA to create a profile of GML. We have also adopted OWL as a method of identifying the subjectCoverage for the resource the index card, or metacard, points to. I’ll talk about that more later in the presentation. In the DoD, we have 2 conditions occurring concurrently – those that are rich with resource metadata and those that don’t have enough to meet our objectives. Regarding those that are rich in metadata, we have a number of programs that are mapping their resource metadata to this spec so their data catalogs can be federated. Regarding those that are resource metadata poor, we have an activity that is led by the AF to use text mining technologies to produce resource metadata IAW DDMS and put that metadata in data catalogs. Dublin Core - NISO Standard Z IC ISM – Intelligence Community Information Security Metadata W3C – World Wide Web Consortium OWL – Web Ontology Language (W3C Recommendation) * OGC: GML “Further Strengthening The Sharing Of Terrorism Information To Protect Americans” W3C: Date & Time * mandatory ISO: Dublin Core ISO: Dublin Core ISO: Dublin Core DDMS: Leverages Industry Standards

Utility Beyond “Make Data Visible”
JA0074C.34 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom Utility Beyond “Make Data Visible” DoD Discovery Metadata Specification (DDMS) Configuration managed by DoD Metadata WG Make Data Accessible (responsibly) * IC: ISM * ISO: Dublin Core * ISO: Dublin Core Enable Data to be Trusted Enable Data to be Trusted * ISO: Dublin Core ISO: Dublin Core Data Catalog (historical) ISO: Dublin Core W3C: Date & Time Make Data Understandable Make Data Understandable ISO: Dublin Core ISO: Dublin Core ISO: Dublin Core ISO: Dublin Core DDMS endorsed by Executive Order 13388 In addition to supporting discovery, DDMS addresses other NCDS goals, as noted on this slide. Notice that there are 2 dimensions to making data accessible: responsibly (access controls) and practically (via MIME formats). * W3C: OWL OGC: GML “Further Strengthening The Sharing Of Terrorism Information To Protect Americans” Make Data Accessible (practically) Make Data Accessible (practically) W3C: Date & Time * mandatory ISO: Dublin Core ISO: Dublin Core ISO: Dublin Core DDMS is enabler to multiple Data Strategy Goals 34

DDMS Home Page http://metadata.dod.mil/mdr/irs/DDMS
The DDMS is publicly accessible. At this URL, you’ll find the specification, the XSDs, conformant XML samples for all authorized versions. You’ll also find a change request form and a listing of all resolved and outstanding change requests. Current Version: 2.0

Federated Search Use Case
COI, POR, C/S/A Data Sources populated from applications, databases, web content, etc. Capabilities: Interfaces: Enterprise Services – DECC Columbus Community of Interest Program of Record EC Enterprise Catalog FS DS FS DS FS DS FS DS External Applications, Services, and Data Sources FS Federated Search FS DS FS DS FS DS For immediate discoverability users may post metadata to the Enterprise Catalog Query is federated and results returned. Users FS DS Data Source FS EC NCES Fed Search Aggregator Enterprise Web Content is crawled and indexed NCES Security Service NCES Service Discovery NCES Enterprise Catalog User Authorized by NCES Security Services Fed Search Aggregator discovers data sources from Service Discovery Aggregated results returned User Submits Search Query DECC Columbus & San Antonio DS (Web Enabled) DS (Web Enabled) The Data Stores contain indexed information collected by crawlers and DDMS that is pushed into a catalog or pulled by the aggregator. User Logs into DOL Portal, DKO, or COI Application Results viewed by user NCES Enterprise Services Management Federated Search enables information sharing within and between PORs and COIs

JA0074C.37 BM6710 AL 3/28/2017 12:37:02 AM3/28/2017 12:37:02 AM Marcom
Make Data Accessible Considerations Practical & Responsible Application & Browser Documents & Systems Practical Responsible Documents Common Formats ICISM, RBAC, ABAC Systems Web Services ICISM, RBAC, ABAC There are many factors to consider in making data accessible. ICISM = IC Information Security Metadata RBAC = Role-based Access Control ABAC = Attribute-based Access Control

Attribute-Based Access Control
Releasability Rules classification="TS" ownerProducer="USA GBR" SCIcontrols="SI TK" FGIsourceProtected="ISR" disseminationControls="OC REL PR" releasableTo="USA AUS CAN GBR" declassDate=" " derivedFrom="Source Document" Notional Example Attribute-based access control enables access control to be based on 3 factors: person attributes, data attributes, and releasability rules. This facilitates dynamic data access for the unanticipated, but properly authenticated and authorized consumer. The security attributes for the book were adopted from the IC. The IC ISDSCA configuration manages an XSD implementation of the CAPCO Registry. The DDMS imports that ICISM XSD. The person attributes are obtained from the PKI card and via a JEDS that can obtain additional attributes. The releasability rules provide the conditions to give the resource to the requestor. Security Clearance: S Citizenship: US Rank: Major AOR: AF

Enterprise Metadata Initiatives
Senior Enterprise Services Governance Group (SESGG) [DoD & IC] DoD Metadata WG DoD Metadata Registry (DoD MDR) DoD Discovery Metadata Spec (DDMS) Service Registry & Governance WG (SR&G WG) Content Discovery IPT Ucore v2.0 [DoD, IC, DHS, DoJ] Automated Metadata Population Service (AMPS) [AF lead] XML Cross Domain Services [DISA-NSA] Controlled Unclassified Information (CUI) – [Federal]

UCore V2.0 Vision, Scope and Governance
Development and Configuration Management (DoD, DoJ Lead) Policy Implementation (IC Lead) Outreach Communications (DHS Lead) Executive Steering Council (ESC) (Rotating Chair between DoD, IC, DoJ, DHS and State/Local Representative) DoD CIO Initial Chair Business Case Design / Build Pilot Test and Eval Config Mgmt For more info see: Briefing given at COI Forum (Jul 2008) (DKO login required) Briefing given at DoD Metadata Working Group (Jan 2008) Memo signed by DoD and IC

Automated Metadata Population Service (AMPS) Pilot Outcomes
Annotators for DDMS elements Creator Description Date Format Geospatial Identifier Security Subject Title Type Annotators for Asset Types Microsoft Office PDF Position-Location Indicators Information Exchange Schemas HTML ID: Title: Cyber Awareness Campaign Creator: Jim Smith Subject: cyber warfare; information assurance; non-kinetic effect; security; cyber threat; infrastructure Description: A campaign to increase awareness of cyber threats to the DoD information infrastructure. Security: U//FOUO Type: Cyber COI Date: Format: Microsoft Word Geospatial: 35.8, -75.3 For more info see: Status Briefing given at COI Forum (Apr 2008) Briefing given at DoD Metadata WG (Oct 2007) COI Vocabularies AMPS Information Asset

Differentiating Types of Metadata
Structural & Semantic Metadata “Rules governing a chunk” - Name, description, data constraints, and relationships of tags used in information resources to delimit one chunk of data from another chunk Artifacts where structural metadata is described: XML schemas, RDBMS structures, taxonomies Register in DoD Metadata Registry, use submission pkg Resource Metadata “Advertisement” - Terms to aid in the recall and retrieval of artifacts Artifacts that we collect resource metadata on: PPT, DOC, GIF, JPG, MPG, RDBMS Register in “Data Catalog”, use DoD Discovery Metadata Specification (DDMS)

Dr Glenda Hayes MITRE/DISA PEO-GES 9 Oct 2008

Similar presentations

Presentation on theme: "Dr Glenda Hayes MITRE/DISA PEO-GES 9 Oct 2008"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Dr Glenda Hayes MITRE/DISA PEO-GES 9 Oct 2008

Similar presentations

Presentation on theme: "Dr Glenda Hayes MITRE/DISA PEO-GES 9 Oct 2008"— Presentation transcript:

Similar presentations

About project

Feedback