Presentation on theme: "Dr Glenda Hayes MITRE/DISA PEO-GES 9 Oct 2008"— Presentation transcript:
1 Dr Glenda Hayes firstname.lastname@example.org MITRE/DISA PEO-GES 9 Oct 2008 DoD Metadata RegistryPresentation toFederal Data Architecture SubcommitteeDr Glenda HayesMITRE/DISA PEO-GES9 Oct 2008
2 DoD Metadata Registry and Clearinghouse (DoD MDR) AgendaNet-CentricityDoD Net-Centric Data StrategyWhat is Metadata?Structural and Semantic MetadataDiscovery MetadataDoD Metadata Registry and Clearinghouse (DoD MDR)
3 Net-Centric Tenets Recipe for Agility DoD Net-Centric Data Strategy InformationAssuranceStrategyCore EnterpriseServices(NCES)Global Connectivity(TransformationalCommunications)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
4 DoD Net-Centric Data Strategy JA0074C.4 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomDoD Net-Centric Data StrategyThe DoD Net-Centric Data Strategy, issued by the DoD CIO May 9, 2003, is the plan to make the Department’s information resources:VisibleIs an information resource discoverable by most users?Is it available on the network, and are tools readily available to use it?AccessibleCan it be intelligibly used? Are the semantics well documented?UnderstandableAre the source, security level and access controls of the data available to users?TrustedThe 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.InteroperableCan it be combined or compared with other information? Can it be mediated?ResponsiveIs the data what users need? Are robust user feedback mechanisms in place to improve it?CC/S/As must institutionalize processes to accomplish these goals4
5 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.
6 Metadata Supports NCDS Goals AnalogyStructural & SemanticResourceTopical AssertionsVisibleaAccessibleUnderstandableTrustedInteroperableResponsivebookInformationResource=index cardTitle: ~~~~~~~~~~Description: ~~~~ ~~~ ~~~Author: ~~~ ~~ ~~~~~~Subject: ~~~ ~~~ ~~~~ResourceMetadata=template, dictionary, thesaurusThe 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 &SemanticMetadata=
7 PEO – GES Data Services Office JA0074C.7 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomPEO – GES Data Services OfficeMissionProvide tools, techniques, and performance standards to enable the DoD Data StrategySupport DISA DoD Data Strategy compliance effortProducts & ServicesChair DoD Metadata Working GroupProvide NCES Metadata Services supportOversee operation of the DoD Metadata RegistryDevelop and promote Data Strategy Enablers for Communities of Interest (COIs)Provide Data Strategy input to NCES Acquisition Milestone DocumentsSupport NCES Product Branch, Testing & Evaluation, Operations, Sustainment, and NetOps activitiesSupport DISA CIO in extending the Enterprise Information Environment (EIE) technical procedures and standards for DISA internal systemsI 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 theComments and Feedback link at
8 Make Data Understandable JA0074C.8 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomMake Data UnderstandableOne reason Government Agencies and Military Services havetrouble operating jointly is that they speak different languages.“I need a tank” What does it mean?Registering and using taxonomies improves precision search and recallRegister Terms, Definitions, & Relationships
9 DoD Metadata Mgmt Engineering-level Processes JA0074C.9 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomDoD Metadata Mgmt Engineering-level ProcessesNamespace Managers & WGsDISAData Services OfficeNamespace Managers & WGsNamespace Managers & WGsGoverns/CoordinatesWithin NamespaceOperates,MaintainsDoD Metadata RegistryHostsParticipates inConsults, Subscribes to & Submitsto/Downloads from Metadata RegistryDiscussesThis 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 inDoD Metadata WGDOD DeveloperDoD MDR Focus GroupDDMS Focus GroupTaxonomy Focus Group
16 Navigate through Relationships JA0074C.16 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM Marcom
17 MDR Support for Mediation JA0074C.17 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomMDR Support for Mediationtacrep.xmlebXML RegistryQuery serviceschemaLocation=“.../tacrep.xsd”tacrep.xsd(schema)HasXSLTtacrep-2-kml.xsl(stylesheet)MDR OrganizesComponents for Mediationnotionaltacrep.kmlLeverage Registered Components & Associations17
18 DoD Metadata Registry (MDR) https://metadata.dod.mil PurposeProvide an on-line repository which enables developers to reuse, understand, integrate with, and share existing data assets (metadata)Targeting web services, databases, and vocabulariesMandated for the publishing of semantic and structural metadataDOD DirectiveProvides a portal for developer access and web services for machine-to-machine accessKey FactsOver 8,000 users and 180,000 assets registeredOver 900 Programs of Record supportedServing the DoD, DHS, IC, NASA and NATOHosted on NIPR, SIPR, and JWICS (in progress)User driven via DoD Metadata Working Group and Feedback linksImplements the ebXML standard for Metadata Registries (in DISR)User Name/Password or Single Sign-On through DKOGovernance structure provided by Joint Enterprise Services ERBPrimary BenefitsEnables reuse and governance of data assetsFoundation for other services; e.g. mediationAllows the COI data assets to exist after the COI disbandsPrimary AudienceDoD Capability Developers, COIsThe 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.
19 DoD MDR History DoD XML Registration Memo MDR Implements ebXML RIM & RSDoD Metadata RegistryMDR on SIPRCOE XML Registryv6.1v2.1v5.0v7.0v3.1v4.1v1.020002002200420062008= 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.0IC Info SharingData Standards Coordination Activity (DSCA )
20 JA0074C.20 BM6710 AL 3/28/2017 12:37:02 AM3/28/2017 12:37:02 AM Marcom MDR UsersDevelopersRe-use and subscribe to registered data components, and/or register new ones they have createdCommunity of Interest (COI) Metadata GovernorsConfiguration Manage (CM) registered component (e.g., posting new metadata versions, version change notification etc.)Acquisition Policy MakersUse Metadata Registry metrics for acquisition oversight (e.g., reflecting program participation, specific data component re-use etc.)ApplicationsInterface with registered components via Metadata Registry Web Service (ebXML) to exploit reference tables, transformations, and XML schemas at Run TimeFirst 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.
21 Unclassified MDR Inventory MDR Size and ScopeInstances on 2 security enclavesUnclassified and SecretUsers – 10,186Information ResourcesSubmission Package – 1,263Schemas (e.g., DTD, XSD, etc) – 4,814Translations (i.e., XSL, XSLT) – 180Services (i.e., WSDL) – 555XML samples – 251Taxonomies (i.e., OWL) – 178Reference Data Sets – 5,709Amplifying Documents (e.g., DOC, ER1, etc) – 5,268900 Programs of Record, 700 OrganizationsUnclassified MDR Inventoryas of 8 Oct 2008
22 Making Data Visible, Accessible, and Understandable through Metadata JA0074C.22 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomMaking Data Visible, Accessible, and Understandable through MetadataFederatedSearchInterfaceNCESEnterpriseCatalogDefenseOnline3Register discovery metadata IAW DDMS in Federated Search-enabled CatalogwarfighterAudience: warfighter, intelligence, business userAudience: developer, application programNCES ServiceRegistry2Register service metadata & endpointsUses registered resourcesdeveloperWeb 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.1Construct & Submit Package to MDR. Contains WSDL, schemas, stylesheets, taxonomies & any other pertinent informationDoDMetadataRegistryDataStoreWeb ServiceMDR Submission Pkg
23 Net-Centric Publisher ServiceEndpointDDMSWSDLXSDFor more info: https://falcon.sspl.disa.mil/mdr/publisher.htmhttps://www.us.army.mil/suite/collaboration/GetDocument.do?doid=Simplifies Metadata Publishing
24 Practical Utility for Taxonomies JA0074C.24 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomPractical Utility for TaxonomiesApplicable forContentServicesStructural MetadataAid precision search via DoD Discovery Metadata Specification (DDMS)Country.sqlISO.xsdFIPS.xsdAs 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>
25 MDR Support for Taxonomies JA0074C.25 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomMDR Support for TaxonomiesDoD CoretaxonomyOrganizationPoliticalOrganizationMyCOItaxonomyUrCOItaxonomyGroupTerroristOrganizationequalsForeignTerroristOrganizationTerroristGroupSince 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.equalsAlQaidaal-QaedaProducerViewConsumerView<ddms>:<Subject>…/MyCOI.owl#AlQaida</Subject></ddms>25
29 Framework for Registry Interoperability JA0074C.29 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomFramework for Registry InteroperabilityInter-RegistryObject ReferencesFederated QueriesEnterprise SearchAggregatorServiceMDRUDDIMDRDDMS-basedQuery ServiceArchitecture ProductsCentralized Authorityw/Local CachingObject RelocationMore attention neededMDRWe 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 ReferencesOne 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 QueriesA “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 CachingObjects 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 RelocationAn 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) MDRUnclassifiedfullyautomatedpushOnlinePackageRegistration(U) MDR(S)Secret(TS)(S)(U) MDRTop SecretUSTRANSCOMUSMTFAdapted from OASIS Cooperating Registries
30 Useful Links DoD CIO Data Strategy Homepage DoD Metadata Registry DoD Metadata RegistryDoD Discovery Metadata SpecificationNCES TechguideNCES Developer Communityhttps://www.us.army.mil/suite/page/384284COI Toolkithttps://www.us.army.mil/suite/page/479547Intellipediahttps://www.intelink.gov/wiki
32 Make Data Visible “Documents” Web Services Documented via JA0074C.32 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomMake Data Visible“Documents”Documented viaKeyword, Text, RSS/Atom, DDMSMetadata Cache(traditional) Search Index, OpenSearch(RSS/Atom) Syndication Feed, Google Data API(DDMS) Metadata Catalog, Federated Search ServiceWeb ServicesDocumented viaWSDL + XSD(s)Metadata CacheebXML RegistryUDDI RegistryStylesSOAPRESTRESTGoal 1 – Make Data VisibleVisibility 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
33 DoD Discovery Metadata Specification (DDMS) JA0074C.33 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomDoD Discovery Metadata Specification (DDMS)IC: ISMConfiguration managed by DoD Metadata WGISO: Dublin Core*ISO: Dublin Core*ISO: Dublin Core*ISO: Dublin Core*ISO: Dublin CoreData Catalog(historical)W3C: Date & TimeISO: Dublin CoreISO: Dublin CoreISO: Dublin CoreISO: Dublin CoreW3C: OWLDDMS endorsed byExecutive Order 13388Before 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 ZIC ISM – Intelligence Community Information Security MetadataW3C – World Wide Web ConsortiumOWL – Web Ontology Language (W3C Recommendation)*OGC: GML“Further Strengthening The Sharing Of Terrorism Information To Protect Americans”W3C: Date & Time* mandatoryISO: Dublin CoreISO: Dublin CoreISO: Dublin CoreDDMS: Leverages Industry Standards
34 Utility Beyond “Make Data Visible” JA0074C.34 BM6710 AL 3/28/ :37:02 AM3/28/ :37:02 AM MarcomUtility Beyond “Make Data Visible”DoD Discovery Metadata Specification (DDMS)Configuration managed by DoD Metadata WGMake Data Accessible (responsibly)*IC: ISM*ISO: Dublin Core*ISO: Dublin CoreEnable Data to be TrustedEnable Data to be Trusted*ISO: Dublin CoreISO: Dublin CoreData Catalog(historical)ISO: Dublin CoreW3C: Date & TimeMake Data UnderstandableMake Data UnderstandableISO: Dublin CoreISO: Dublin CoreISO: Dublin CoreISO: Dublin CoreDDMS endorsed byExecutive Order 13388In 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: OWLOGC: GML“Further Strengthening The Sharing Of Terrorism Information To Protect Americans”Make Data Accessible (practically)Make Data Accessible (practically)W3C: Date & Time* mandatoryISO: Dublin CoreISO: Dublin CoreISO: Dublin CoreDDMS is enabler to multiple Data Strategy Goals34
35 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
36 Federated Search Use Case COI, POR, C/S/A Data Sources populated from applications, databases, web content, etc.Capabilities:Interfaces:Enterprise Services – DECC ColumbusCommunity of InterestProgram of RecordECEnterprise CatalogFSDSFSDSFSDSFSDSExternal Applications, Services, and Data SourcesFSFederated SearchFSDSFSDSFSDSFor immediate discoverability users may post metadata to the Enterprise CatalogQuery is federated and results returned.UsersFSDSData SourceFSECNCES Fed Search AggregatorEnterprise Web Content is crawled and indexedNCES Security ServiceNCES Service DiscoveryNCES Enterprise CatalogUser Authorized by NCES Security ServicesFed Search Aggregator discovers data sources from Service DiscoveryAggregated results returnedUser Submits Search QueryDECC Columbus & San AntonioDS(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 ApplicationResults viewed by userNCES Enterprise Services ManagementFederated Search enables information sharing within and between PORs and COIs
37 JA0074C.37 BM6710 AL 3/28/2017 12:37:02 AM3/28/2017 12:37:02 AM Marcom Make Data AccessibleConsiderationsPractical & ResponsibleApplication & BrowserDocuments & SystemsPracticalResponsibleDocumentsCommon FormatsICISM,RBAC,ABACSystemsWeb ServicesICISM, RBAC, ABACThere are many factors to consider in making data accessible.ICISM = IC Information Security MetadataRBAC = Role-based Access ControlABAC = Attribute-based Access Control
38 Attribute-Based Access Control Releasability Rulesclassification="TS" ownerProducer="USA GBR" SCIcontrols="SI TK" FGIsourceProtected="ISR" disseminationControls="OC REL PR" releasableTo="USA AUS CAN GBR" declassDate=" " derivedFrom="Source Document"NotionalExampleAttribute-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: SCitizenship: USRank: MajorAOR: AF
40 UCore V2.0 Vision, Scope and Governance DevelopmentandConfigurationManagement(DoD, DoJ Lead)PolicyImplementation(IC Lead)OutreachCommunications(DHS Lead)Executive Steering Council (ESC)(Rotating Chair between DoD, IC, DoJ, DHS and State/Local Representative)DoD CIO Initial ChairBusiness CaseDesign / BuildPilotTest and EvalConfig MgmtFor more info see:Briefing given at COI Forum (Jul 2008)https://www.us.army.mil/suite/collaboration/GetDocument.do?doid= (DKO login required)Briefing given at DoD Metadata Working Group (Jan 2008)https://metadata.dod.mil/mdr/download.htm?contentItemId=urn:uuid:3e4cd637-5c27-498c-b dc99a69bfMemo signed by DoD and IC
41 Automated Metadata Population Service (AMPS) Pilot Outcomes Annotators for DDMS elementsCreatorDescriptionDateFormatGeospatialIdentifierSecuritySubjectTitleTypeAnnotators for Asset TypesMicrosoft OfficePDFPosition-Location IndicatorsInformation Exchange SchemasHTMLID:Title: Cyber Awareness CampaignCreator: Jim SmithSubject: cyber warfare; information assurance; non-kinetic effect; security; cyber threat; infrastructureDescription: A campaign to increase awareness of cyber threats to the DoD information infrastructure.Security: U//FOUOType: Cyber COIDate:Format: Microsoft WordGeospatial: 35.8, -75.3For more info see:Status Briefing given at COI Forum (Apr 2008)https://www.us.army.mil/suite/collaboration/GetDocument.do?doid=Briefing given at DoD Metadata WG (Oct 2007)https://metadata.dod.mil/mdr/download.htm?contentItemId=urn:uuid:72ffb2bf-0cd ecbbeb15135fCOIVocabulariesAMPSInformationAsset
42 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 chunkArtifacts where structural metadata is described: XML schemas, RDBMS structures, taxonomiesRegister in DoD Metadata Registry, use submission pkgResource Metadata“Advertisement” - Terms to aid in the recall and retrieval of artifactsArtifacts that we collect resource metadata on: PPT, DOC, GIF, JPG, MPG, RDBMSRegister in “Data Catalog”, use DoD Discovery Metadata Specification (DDMS)
Your consent to our cookies if you continue to use this website.