Status

This vocabulary has the status SEMIC Recommendation published at 2024-02-01.

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

History

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.

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 main classes adms:AssetRepository, adms:Asset and adms:AssetDistribution correspond to respectively dcat:Catalog, dcat:Dataset and dcat:Distribution. Depending on the scope of the profile this correspondenance can be expressed as a subclass statement in the context of that profile.
• Use the relations dcat:dataset (or the more generic dcat:resource) and dcat:distribution to interconnect adms:AssetRepository, adms:Asset and adms:AssetDistibution.
• The properties adms:last, adms:next, adms:prev have dcat:last, dcat:next, dcat:prev counterparts. It is recommended to use the DCAT ones in favour of the ADMS counterparts.

Example profile specification

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

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:

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

• apples
• pears
• oranges
• peaches

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:

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: