ADMS is a profile of DCAT, used to describe
semantic 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 the W3C technical reports index at http://www.w3.org/TR/.
The only changes made since the previous version
of this document concern the acknowledgement 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-called
Semantic 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 Asset
and a dataset and it can be argued that all Assets are datasets. Therefore the difference in
user 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 is
designed 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 words
must
,
must not
,
required
,
should
,
should not
,
recommended
,
may
, and
optional
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 does
not
use terms from other vocabularies
instead
of ones defined
in this vocabulary that could reasonably be used (use of such terms in
addition
to ADMS is permissible)..
A conforming data interchange:
may
include terms from other vocabularies;
may
use only a subset of ADMS terms.
An
ADMS profile
is a specification for data interchange that adds additional constraints. Such additional
constraints in a profile
may
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 is
http://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 possible
and 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.
Prefix
Namespace
adms
http://www.w3.org/ns/adms#
dcat
http://www.w3.org/ns/dcat#
dcterms
http://purl.org/dc/terms/
foaf
http://xmlns.com/foaf/0.1/
schema
http://schema.org/
rdfs
http://www.w3.org/2000/01/rdf-schema#
skos
http://www.w3.org/2004/02/skos/core#
v
http://www.w3.org/2006/vcard/ns#
wdrs
http://www.w3.org/2007/05/powder-s#
xhv
http://www.w3.org/1999/xhtml/vocab#
4.
Vocabulary Overview
This section is non-normative.
ADMS is intended as a model that facilitates federation and co-operation.
Like DCAT, ADMS has the concepts of a repository (catalog), assets within the repository
that are often conceptual in nature, and accessible realizations of those assets, known
as distributions. An asset may have zero or multiple distributions. As an example, a
W3C
namespace document
can be considered to be a Semantic Asset that is typically available in multiple distributions, typically one
or more machine processable versions and one in HTML for human consumption. An asset without any distributions
is effectively a concept with no tangible realization, such as a planned output of a working group that has not yet been drafted.
ADMS is an RDF vocabulary with an RDF schema available at its namespace
http://www.w3.org/ns/adms
.
The original ADMS specification published by the European Commission [
ADMS1
] includes an XML schema that also defines
all 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 in
Turtle
.
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 at
http://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 ADMS
specification [
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 its
description, format, and license. In this example we've used Ed Summers' media types application to
provide 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 of
dcat: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 entities
work
(a distinct
intellectual or artistic creation) and
expression
(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 of
dcat:Dataset
Assets are included in Repositories using DCAT's
dcat:dataset
property.
5.1.3
Asset Distribution
adms:AssetDistribution
A particular physical embodiment of an Asset, which is an example of
the FRBR
entity 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 of
dcat:Distribution
Assets are linked to Asset Distributions using DCAT's
dcat: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 is
both
an Asset
and
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. Use
dcterms: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. Use
dcat:contactPoint
to link an Asset to a VCard.
dcterms:Location
The country or region to which an Asset or Repository applies, linked using
dcterms: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 the
adms:Identifier
class with the following properties:
the content string should be provided using
skos:notation
, datatyped with
the identifier scheme (including the version number if appropriate);
use
dcterms:creator
to link to a class that represents the agency that manages the identifier scheme and/or
adms:schemaAgency
to provide the name of the agency as a literal;
it may also be useful to provide further properties such as
dcterms:issued
to provide the
date on which the identifier was issued.
An important point to note is that properties of
adms: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 using
adms: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 using
dcterms: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 using
dcterms: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 using
dcterms:temporal
. The time period can be specified
using
schema:startDate
and
schema:endDate
.
5.2.11
Publisher
dcterms:Agent
The organization making a Repository, Asset or Distribution available, linked using
dcterms: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 using
adms: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 using
dcat: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 using
dcat: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 this
purpose 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 link
should
be duplicated as accessURL on a distribution (see also
dcat: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 IRI
should
be used; if no ISO 639-1 code is defined, then IRI corresponding to the ISO 639-2 (three-letter) code
should
be used.
5.3.19
adms:last
A link to the current or latest version of the Asset.
This property
should
be used when the media type of the distribution is defined in
IANA
, e.g.
text/csv
otherwise
dcterms:formatmay
be used with different values.
See also
adms: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 case
the type should be provided using a controlled vocabulary encoded as a SKOS Concept.
ADMS was first developed by and published
by the European Commission ISA 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 the
Government 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 original
version made as a result of implementation experience, particularly on the
European Commission's Joinup 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
