ADMS is a profile of DCAT, used to describesemantic assets (or just 'Assets'), defined as highly reusable metadata (e.g. xml schemata,generic data models) and reference data (e.g. code lists, taxonomies, dictionaries,vocabularies) that are used for eGovernment system development.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in theW3C technical reports index at http://www.w3.org/TR/.
The only changes made since theprevious version of this document concern theacknowledgements section. No substantive changes have been made.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
ADMS, the Asset Description Metadata Schema, is a profile of DCAT [DCAT ] for describing so-calledSemantic Assets (or just 'Assets'), that is, highly reusable metadata (e.g. xml schemata,generic data models) and reference data (e.g. code lists, taxonomies, dictionaries,vocabularies) that are used for eGovernment system development [TOGD ]. Someone searching for an Asset is likely to have different needs, priorities and expectations than someone searching for a dataset in a data catalog and these differences are reflected in ADMS. In particular, users seeking an Asset are likely to be searching for a document — something they can open and read using familiar desktop software, as opposed to something that needs to be processed. Of course this is a very broad generalization. If a code list is published as a SKOS Concept scheme then it is both an Assetand a dataset and it can be argued that all Assets are datasets. Therefore the difference inuser expectation is at the heart of what distinguishes ADMS as a profile of DCAT. A further distinction between DCAT and ADMS can be made in that DCAT isdesigned to facilitate interoperability between data catalogs ,i.e. the catalog itself is at the heart of the vocabulary. ADMS is focused on the assets within a catalog.
2. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key wordsmust ,must not ,required ,should ,should not ,recommended ,may , andoptional in this specification are to be interpreted as described in [RFC2119 ].
A data interchange, however that interchange occurs, is conformant with ADMS if:
it uses terms (classes and properties) from ADMS in a way consistent with their semantics as defined in this specification;
it doesnot use terms from other vocabulariesinstead of ones defined in this vocabulary that could reasonably be used (use of such terms inaddition to ADMS is permissible)..
A conforming data interchange:
may include terms from other vocabularies;
may use only a subset of ADMS terms.
AnADMS profile is a specification for data interchange that adds additional constraints. Such additional constraints in a profilemay include (but are not limited to):
a minimum set of required terms;
classes and properties for additional terms not covered in ADMS;
controlled vocabularies or URI sets as acceptable values for properties;
specific concrete protocols, formats, and syntaxes.
ADMS is technology-neutral and a publisher may use any of the terms defined in this document encoded in any technology although RDF and XML are preferred.
3. Namespaces
This section is non-normative.
The namespace for ADMS ishttp://www.w3.org/ns/adms# . However,it should be noted that ADMS makes extensive use of terms from other vocabularies,in particular Dublin Core [DC11 ]. It re-uses and subclasses DCAT wherever possibleand therefore defines a minimal set of classes and properties of its own. A full set of namespaces and prefixes used in this document is shown in the table below.
ADMS is an RDF vocabulary with an RDF schema available at its namespacehttp://www.w3.org/ns/adms .The original ADMS specification published by the European Commission [ADMS1 ] includes an XML schema that also definesall the controlled vocabularies and cardinality constraints associated with the original document.
4.1 Example
This example provides a quick overview of how ADMS might be used to represent a Semantic Asset Repository and its assets.
Examples in this document are serialized inTurtle .
First, the repository description:
:Repository a adms:AssetRepository ; dcterms:created "1947-02-07"^^xsd:date ; dcterms:description "A complete catalog of code lists and standards created by the Exemplary Standards Body"@en ; dcterms:publisher <http://example.com/data#org> ; dcterms:title "The Exemplary Standards Body Catalog"@en .
This assumes that the Exemplary Standards Body is described athttp://example.com/data#org .
Next, an Asset. We'll create an imaginary code list called 'Fruit I like' for our example:
apples
pears
oranges
peaches
We might describe this Asset thus:
1 :Fruit_02 a adms:Asset ;2 dcterms:created "1999-05-24" ;3 dcterms:description "Fruits that are found to be generally liked by most people." ;4 dcterms:publisher <http://example.com/data#org> ;5 dcterms:title "Fruit I like"@en ;6 adms:status <http://purl.org/adms/status/Completed> ;7 dcterms:type <http://purl.org/adms/assettype/CodeList> ;8 adms:previous :Fruit_01 ;9 adms:last :Fruit ;10 dcat:distribution :Fruit_02.csv ;11 dcat:distribution :Fruit_02.xml .
This provides the creation date (line 2), description (line 3), publisher (line 4) and a title (line 5) for the Asset.The status of the Asset is given in line 6 using one of the values made available in the original ADMSspecification [ADMS1 ]. Likewise the type of Asset in line 7. In line 8 we can see that there was a previous version of this asset (Fruit_01) and that the latest version can be found by appending 'Fruit' to the data's root (line 9).
This Asset has two distributions linked in lines 11 and 12. One of these might be described thus:
:Fruit_02.xml a adms:AssetDistribution ; dcterms:description "XML encoding of Fruits that are found to be generally liked by most people." ; dcterms:license <http://creativecommons.org/licenses/by/3.0/> ; dcterms:format <http://purl.org/NET/mediatypes/application/xml> .
This is a very simple description of the Asset Distribution that just gives itsdescription, format, and license. In this example we've used Ed Summers' media types application toprovide a URI for the XML MIME type [EDSU ]
The missing triple from this example is the one that includes the Asset in the Repository. This is done with a simple triple:
:Repository dcat:dataset :Fruit_02 .
5. The ADMS Domain Model
UML model of ADMS classes and properties
The classes and properties are described in the following sub-sections
5.1 The Primary Concepts
5.1.1 Asset Repository
adms:AssetRepository A system or service that provides facilities for storage and maintenance of descriptions of Assets and Asset Distributions, and functionality that allows users to search and access these descriptions. An Asset Repository will typically contain descriptions of several Assets and related Asset Distributions.
adms:AssetRepository is a sub class ofdcat:Catalog
5.1.2 Asset
adms:Asset An abstract entity that reflects the intellectual content of the asset and represents those characteristics of the asset that are independent of its physical embodiment. This abstract entity combines the FRBR entitieswork (a distinct intellectual or artistic creation) andexpression (the intellectual or artistic realization of a work) [FRBR ].
Assets can be versioned. Every time the intellectual content of an asset changes, the result is considered to be a new asset that can be linked to previous and next versions of the Asset.
The physical embodiment of an Asset is called an Asset Distribution. A particular Asset may have zero or more Distributions.
adms:Asset is a sub class ofdcat:Dataset
Assets are included in Repositories using DCAT'sdcat:dataset property.
5.1.3 Asset Distribution
adms:AssetDistribution A particular physical embodiment of an Asset, which is an example of the FRBRentity manifestation (the physical embodiment of an expression of a work).
A Distribution is typically a downloadable computer file (but in principle it could also be a paper document or API response) that implements the intellectual content of an Asset.
A particular Distribution is associated with one and only one Asset, while all Distributions of an Asset share the same intellectual content in different physical formats.
Distributions themselves are not versioned. If Distribution 1A is the manifestation of Asset 1 and Distribution 2A is the manifestation of Asset 2, a version relationship will be expressed between Asset 1 and Asset 2, not between Distribution 1A and Distribution 2A. For an illustration of two Assets that each have two Distributions (representations in different formats) see the diagram below.
The relationship between versioned Assets and their Distributions
adms:AssetDistribution is a sub class ofdcat:Distribution
Assets are linked to Asset Distributions using DCAT'sdcat:distribution property.
Examples of the relationship between Assets and Asset Distributions are:
An Asset without an Asset Distribution
Even before an Asset is finalized, a description of what it will be can often be made; for example, a description of it can be written, the publisher is already known as is the language. A link to the distribution, the physical document, can only be made when the work is done; until that time, the Asset will have no Distribution associated with it.
An Asset and Asset Distribution embedded in a single file
Some Assets, such as technical specifications, have some characteristics that are related to the intellectual content such as its description, its language and its version, and some characteristics that are related to the file itself such as its location (if its identifier is not a URL), its format and the usage conditions. In such cases, a single entity isboth an Assetand an Asset Distribution. Even so, best practice is to assert the Asset → Asset Distribution relationship (i.e. to point to itself) so that queries looking for that relationship will still return a result.
An Asset with multiple Asset Distributions
It is common for a single work to be expressed in multiple formats. For example, RDF documents are often serialized in RDF/XML, Turtle and triples, each of which would be a discrete Distribution.
5.2 The Secondary Concepts
In addition to the primary concepts, ADMS includes a number of secondary or supporting concepts:
5.2.1 Asset Type
skos:Concept The classification of an Asset according to a controlled vocabulary, e.g. code list, metadata schema. Usedcterms:type to link an Asset to an Asset Type.
5.2.2 Contact Information
v:VCard A contact point for further information about an Asset. Usedcat:contactPoint to link an Asset to a VCard.
dcterms:Location The country or region to which an Asset or Repository applies, linked usingdcterms:spatial .
5.2.6 Identifier
adms:Identifier This is based on the UN/CEFACT Identifier class. [UNCEFACT ]) which consists of:
a content string which is the identifier;
an optional identifier for the identifier scheme;
an optional identifier for the version of the identifier scheme;
an optional identifier for the agency that manages the identifier scheme.
In ADMS this is expressed using theadms:Identifier class with the following properties:
the content string should be provided usingskos:notation , datatyped with the identifier scheme (including the version number if appropriate);
usedcterms:creator to link to a class that represents the agency that manages the identifier scheme and/oradms:schemaAgency to provide the name of the agency as a literal;
it may also be useful to provide further properties such asdcterms:issued to provide the date on which the identifier was issued.
An important point to note is that properties ofadms:Identifier are properties of the Identifier, not the resource that it identifies or the agency that issued it.
5.2.7 Interoperability Level
skos:Concept The interoperability level (e.g. legal, organizational, political etc.) of the Asset, linked usingadms:interoperabilityLevel . The interoperability level may be taken from a list of levels such as that of the European Interoperability Framework [EIF2 ].
5.2.8 Language
dcterms:LinguisticSystem The language of an Asset if it contains textual information, e.g. the language of the terms in a controlled vocabulary or the language in which a specification is written, linked usingdcterms:language
5.2.9 License
dcterms:LicenseDocument The conditions or restrictions that apply to the use of a Distribution, e.g. whether it is in the public domain, or that some restrictions apply such as attribution being required, or that it can only be used for non-commercial purposes etc. Linked usingdcterms:license
5.2.10 Period of time
dcterms:PeriodOfTime The time period relevant for an Asset, e.g. for its validity. Linked from a Semanmtic Asset usingdcterms:temporal . The time period can be specified usingschema:startDate andschema:endDate .
5.2.11 Publisher
dcterms:Agent The organization making a Repository, Asset or Distribution available, linked usingdcterms:publisher .
This concept indicates that one of the files in an Asset Distribution is expressed in the Representation Technique. There may also be other files in the Distribution that are expressed in other Representation Techniques or even files that are not representations at all.
5.2.13 Status
skos:Concept An indication of the maturity of an Asset or Distribution, linked usingadms:status .
5.2.14 Theme
skos:Concept The sector that an Asset applies to, e.g. "law" or "environment". Best practice is to use terms from a controlled vocabulary expressed as a SKOS Concept Scheme and linked from the Asset usingdcat:theme .
5.2.15 Theme Taxonomy
skos:ConceptScheme A controlled vocabulary that contains terms that are used as Themes for the Assets in a Repository, linked from the Repository usingdcat:themeTaxonomy .
NB The original ADMS specification supports the provision of a description of the metadata about an Asset, including its publisher and language (i.e. the human language in which the metadata is expressed,irrespective of the language used in the Asset itself). The DCAT concept of a Catalog Record can be used for thispurpose and so is not detailed in this document.
5.3 Properties and Relationships
In the following sub-sections, we set out the properties and relationships (object type properties) used in ADMS. These are listed in alphabetical order, irrespective of namespace.
5.3.1 dcat:accessURL
Any kind of URL that gives access to an Asset Repository or Asset Distribution, e.g. a landing page, download, feed URL, SPARQL endpoint etc. Use dcat:accessURL when you do not have information on which it is or when it is definitely not a download.
If the distribution(s) are accessible only through a landing page (i.e. direct download URLs are not known), then the landing page linkshould be duplicated as accessURL on a distribution (see alsodcat:landingPage ).
This is a direct link from an Asset Distribution to a downloadable file in a given format, e.g. CSV file or RDF file. The format is described by the distribution's dcterms:format and/or dcat:mediaType.
If the Asset Distribution(s) are accessible only through a landing page (i.e. direct download URLs are not known), then the landing page link should be duplicated as accessURL on a distribution.
rdfs:Resource Resources defined by the Library of Congress (1 ,2 )should be used. If an ISO 639-1 (two-letter) code is defined for language, then its corresponding IRIshould be used; if no ISO 639-1 code is defined, then IRI corresponding to the ISO 639-2 (three-letter) codeshould be used.
5.3.19 adms:last
A link to the current or latest version of the Asset.
This propertyshould be used when the media type of the distribution is defined inIANA , e.g.text/csv otherwisedcterms:formatmay be used with different values. See alsoadms:representationTechnique .
5.3.22 dcterms:modified
Date of the latest update of the Asset, Asset Repository or Asset Distribution.
More information about the format in which an Asset Distribution is released. This is different from the file format as, for example, a ZIP file (file format) could contain an XML schema (representation technique).
This property is used to point to the specific type of publisher, Asset and License Document. In each casethe type should be provided using a controlled vocabulary encoded as a SKOS Concept.
ADMS was first developed by andpublished by the European CommissionISA Programme. Contributors included representatives of Member States of the European Union, operators of national repositories, standardization bodies and independent experts whose work was published in April 2012 [ADMS1]. That document includes the history and motivation behind the development of ADMS, as well as the business need and usage scenario for it.
Further development and review has been undertaken by theGovernment Linked Data Working Group (GLD WG).This version of ADMS builds on the original work in a broader, global context. It also includes some changes to the originalversion made as a result of implementation experience, particularly on the European Commission'sJoinup Platform.
ADMS 1.0 European Commission ADMS (link is to a page offering various downloadable files in a variety of formats). URL: http://joinup.ec.europa.eu/asset/adms/release/100
[EDSU]
Media Types Application Ed Summers' work on providing URIs for media types URL: http://mediatypes.appspot.com/
Towards Open Government Metadata (PDF) European Commission Joinup e-Library. URL: http://joinup.ec.europa.eu/sites/default/files/towards_open_government_metadata_0.pdf
[UNCEFACT]
(PDF) Core Components Data Type Catalogue Version 3.1 UNECE United Nations Economic Commission for Europe. UN Centre for Trade Facilitation and Electronic Business (UN/CEFACT). URL: http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS-DTCatalogueVersion3p1.pdf
