This document describes a vocabulary, in this case ADMS Vocabulary. A vocabulary is a semantic data specification designed so that the included terms are highly reusable. The included classes and properties come with a limited set of constraints.

ADMS, the Asset Description Metadata Schema, is a vocabulary for describing 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).

Motivation for this vocabulary

Someone searching for a Semantic Asset is likely to have different needs, priorities and expectations than someone searching for a dataset in a data catalogue 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 generalisation. If a code list is published as a SKOS Concept scheme [[skos-reference]] then it is both an Asset and a dataset offered to be exploited in a data exchange. As a vocabulary ADMS focusses on the nature of the Assets, rather than on the organisation of the Assets in a catalogue.

Although ADMS has been designed with the use case above in mind, some terms are used beyond that use case and operate in a broader context. For instance adms:identifier has received wide adoption in various vocabularies such as DCAT-AP [[dcat-ap]] and the SEMIC Core Vocabularies. In this new release of ADMS this usage has been made more visible, by decoupling ADMS in a formal sense from DCAT and restricting the specification to the classes and properties defined in the ADMS namespace. The historic connection with DCAT has been reformulated an as usage example of ADMS.

The namespace for ADMS is .

The vocabulary is also provided in different RDF serialisations [ turtle | ntriples | rdf/xml ].

Meeting minutes


This vocabulary has the status Candidate Recommendation published at 2023-06-21.

Information about the process and the decisions involved in the creation of this specification are consultable at the Changelog.


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, standardisation bodies and independent experts whose work was published in April 2012 [[ADMS1]]. That document includes the original history and motivation behind the development of ADMS, as well as the business needs and usage scenario for it.

Further development and review was undertaken by the Government Linked Data Working Group [[WG-GLD]]. 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. Under supervision of the Government Linked Data Working Group a minor update has been published, which did not include any substantial changes compared to the first published version by the Working Group. The latest document was published as a W3C Working Group Note [[vocab-adms]] on 1 August 2013 and has not been revised since then.

Motivation for this version

In the light of providing the semantic data community, and thus especially the SEMIC community, a coherent and trusted collection of maintained vocabularies, the European Commission ( Interoperable Europe ) engaged itself to take up the active maintenance of the ADMS vocabulary. In the past decade the SEMIC community of the European Commission was supporting ADMS by taking up the management of the associated controlled vocabularies and the management of an application profile, independently from the W3C note. Given that initiative for this vocabulary has been taken by the European Commission and this vocabulary was not adopted as W3C recommendation, W3C and the European Commission collaborate together to provide an active maintenance of this vocabulary. --This new release of ADMS decouples ADMS from DCAT for the terms in the vocabulary.

With the active development of DCAT and its profiles, the status of ADMS as a profile of DCAT becomes unclear. The impact of DCAT on the ADMS vocabulary as a profile of DCAT is not only on its relationship, but also on how the profile is constructed and on the adoption of some terminology. For instance, ADMS has some versioning navigation properties, but those are not adopted by DCAT but replaced by similar properties in the DCAT namespace. All these changes to the base vocabulary DCAT, of which ADMS declared itself originally a profile, force an modification of ADMS. Such alignment is necessary each time DCAT is updated.

With this new release, ADMS is decoupled to the furthest extent possible from DCAT (no formal ties), while maintaining its original definitions. In essence one can consider this as a broadening of the ADMS terms. Doing so, the lifecycle of ADMS is no longer bound to the lifecycle of DCAT.

While this independence offers new potential for reuse, the goal is not to create a parallel universe to DCAT. When cataloguing Semantic Assets is the target use case, it is highly recommended to first create a DCAT profile with the ADMS terms included. The historic dependency should easily facilitate the creation of such profile.


Copyright © 2023 European Union. All material in this repository is published under the license CC-BY 4.0, unless explicitly otherwise mentioned.

ADMS is a vocabulary that defines a collection of terms while having minimal usage restrictions. Usage of the terms is considered conformant with ADMS if the terms from ADMS (classes and properties) are utilised in a manner that aligns with their semantics as specified in the ADMS vocabulary specification. That means the usage is conformant to

In this vocabulary the rdfs:Resource class is used to denote any possible resource. Thus meaning no restriction in usage.


Used Prefixes

PrefixNamespace IRI

Vocabulary Overview

This specification describes the following classes:
| Asset | Asset Distribution | Asset repository | Identifier |

and the following properties:
| identifier | included asset | interoperability level | last | next | prev | representation technique | sample | schema agency | status | supported schema | translation | version notes |


This section lists the classes matching the base namespace of this vocabulary.


(create issue) Class Asset
label Asset
definition 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).

Asset Distribution

(create issue) Class Asset Distribution
label Asset Distribution
definition 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).

Asset repository

(create issue) Class Asset repository
label Asset repository
definition 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.


(create issue) Class Identifier
label Identifier
definition This is based on the UN/CEFACT Identifier class.
usage An identifier in a particular context, consisting of the
  • content string that 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.


This section lists the properties matching the base namespace of this vocabulary.


(create issue) Property identifier
label identifier
definition Links a resource to an adms:Identifier class.

included asset

(create issue) Property included asset
label included asset
definition An Asset that is contained in the Asset being described, e.g. when there are several vocabularies defined in a single document.

interoperability level

(create issue) Property interoperability level
label interoperability level
definition The interoperability level for which the Asset is relevant.


(create issue) Property last
label last
definition A link to the current or latest version of the Asset.
subproperty of


(create issue) Property next
label next
definition A link to the next version of the Asset.
subproperty of


(create issue) Property prev
label prev
definition A link to the previous version of the Asset.
subproperty of

representation technique

(create issue) Property representation technique
label representation technique
definition 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).


(create issue) Property sample
label sample
definition Links to a sample of an Asset (which is itself an Asset).

schema agency

(create issue) Property schema agency
label schema agency
definition The name of the agency that issued the identifier.


(create issue) Property status
label status
definition The status of the Asset in the context of a particular workflow process.

supported schema

(create issue) Property supported schema
label supported schema
definition A schema according to which the Asset Repository can provide data about its content, e.g. ADMS.


(create issue) Property translation
label translation
definition Links Assets that are translations of each other.

version notes

(create issue) Property version notes
label version notes
definition A description of changes between this version and the previous version of the Asset.

Interpretation of ADMS in the context of DCAT.

ADMS was originally very tightly integrated with DCAT. As motivated in [[[#specintro]]], this version decouples ADMS from DCAT. Nevertheless, this historic connection is important. This section, therefore, provides the base principles for building an ADMS-based profile of DCAT.

The principles are:

The last principle formulates that if the objective is to create a profile of DCAT, it is recommended to align, to the best extent, with the DCAT specification. ADMS terminology should only be adopted in the profile when it precisely captures the needs.

Example profile specification

Using these principles, the original profile of DCAT for ADMS can be constructed. The original picture is depicted below.
ADMS as DCAT profile

The table below illustrates the usage of many properties that are included in this context.

Label URI Usage Note
access URL
A URL that gives access to the AssetDistribution content.
alternative label
An alternative name for the Asset.
contact point
Contact information that can be used for sending comments about the Asset.
An entity responsible for making the resource.
Used to link an Asset Repository to an Asset.
dataset distribution
Links an Asset to an implementation in a particular format.
A free-text account of the resource (AssetRespository, Asset or AssetDistribution).
download URL
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.
A word, phrase or tag to describe the Asset.
landing page
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.
The language of the Asset.
modification date
Most recent date of change for the resource (AssetRepository, Asset or AssetDistribution)
A string that is an identifier in the context of the identifier scheme referenced by its datatype.
A related Asset.
release date
Date of formal issuance of the resource (AssetRepository, Asset or AssetDistribution).
A category of the Asset.
A string that is an identifier in the context of the identifier scheme referenced by its datatype.
A version number or other designation of the Asset.

Data examples

This example illustrates the use of ADMS in the original context of a DCAT profile. Examples in this document are serialised in Turtle [[turtle]] and JSON-LD [[json-ld]].

First, the repository description:

Example 1 - ADMS as DCAT profile

This assumes that the Exemplary Standards Body is described at . Next, an Asset. We'll create an imaginary code list called 'Fruit I like' for our example:

We might describe this Asset as:

Example 2 - Fruit Asset

This provides the creation date (line 8), description (line 9), publisher (line 10) and a title (line 11) for the Asset. The status of the Asset is given in line 12 using one of the values made available in the codelists, created in the context of the first version of ADMS [[codelist-adms]] . Likewise the type of Asset in line 13. In line 14 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 15). This Asset has two distributions linked in lines 16 and 17. One of these might be described as:

Example 3 - Fruit Asset Distibution

This is a very simple description of the Asset Distribution that just gives its description, format, and license. In this example we've used the NAL File Type [[NAL-FileType]] to provide a URI for the XML MIME type. The missing triple from this example is the one that includes the Asset in the Repository. This is done with a simple triple:

Example 4 - Fruit Asset in Repository


The editors gratefully acknowledge the contributions made to this document by all members of the working group.

This work was elaborated by a Working Group under SEMIC by Interoperable Europe. Interoperable Europe of the European Commission was represented by Pavlina Fragkou and Seth Van Hooland. Bert Van Nuffelen was the editor of this specification.

Past and current contributors are : Alberto Abella , Riitta Alkula , Peter Bruhn Andersen , Ales Cernivec , Eugeniu Costetchi , Jitse De Cock , Pascal Derycke , Ilias Dimopoulos , Petro Dudi , Ana Rosa Guzmán , Irène Kesisoglou , Touré Lanciné , Giorgia Lodi , Peter Lubrich , Italo Mairo , Thies Mesdag , Joachim Nielandt , Geraldine Nolf , Csongor Nyulas , Hans Overbeeck , Matthias Palmér , Mihai Paunescu , Hector Rico Lorenzo , Ludger Rinsche , Fidel Santiago , Mantas Sekmokas , Enric Staromiejski , Kees Trautwein , Willem van Gemert , William Verbeeck , Jim Yang .

Special thanks goes to the former editors Phil Archer, Gofran Shukair and Makx Dekkers, for their contributions to the former versions of ADMS. Additionally the editors and authors like to thank the assistence of W3C, especially Pierre-Antoine Champin, to make this version possible.