ADMS - Asset Description Metadata Schema

ADMS defines:

• Elements and attributes of a repository content (asset)
• semantic statements and
• (simple) data types for a subset of metadata used to describe contents (assets) in a repository.
• Multiplicity of elements (optional, mandatory, multiple occurrence allowed)
• Relation between elements

In terms of lifecycle of an asset in a repository, ADMS will be directly relevant for the aspects marked up in bold font style. In addition, ADMS might have an indirect side-effect for the first 3 phases marked up in italic text:

1. Concept development
2. Creation
3. Improvement
4. Implementation
5. (Accidental) Discovery
6. Search and
7. Finding
8. Access
9. Retrieval

Figure 1 points out the scope of ADMS within a typical technology stack. ADMS defines administrative and descriptive metadata of repository content. As a consequence of defining RDF as the technical representation of an ADMS compliant dataset, ADMS additionally involves aspects on the protocol layer (http), or for instance has to care for character sets and URIs.

Figure 1: ADMS in the technology stack

ADMS does not define:

1. how repositories will expose information like
   • assets they contain
   • the ways of accessing the content it supports (beside an accessURL)
   • the ownership of the repository (not of the content)
   • the ADMS version they support
2. legal issues like "What data am I allowed to share?" (data protection issues, concerns on personal data)
3. organisational issues in terms of maintenance processes like
   • how to add, modify or delete a repository with regards to connected federation partners
   • how to declare yourself a "ADMS-featured" repository
   • how to test the ADMS-ability of your repository
   • how to add, modify or delete an asset with regards to connected federation partners
4. technical (protocol) issues like
   • Verbs for REST-API queries (similar to OAI: List, Identify, GetRecord, etc.)
   • Representation of repository content in other formats than RDF or derived RDF-usage (RDFa)

The following list describes main criteria to be considered by ADMS development.

1. ADMS has to be clearly defined to access the federation with low barriers of entry.
2. ADMS has to be flexible enough to cover various types of repositories and future requirements.
3. ADMS has to enclose metadata to describe different types of artefacts (assets).
4. ADMS has to contain a small number of elements and attributes to enable a mapping for almost any existing repository.
5. ADMS has to define sufficient elements and attributes to enable mappings to other available repositories’ description schemas.
6. ADMS development has to be based on existing metadata standards and vocabularies like DC, DCT, FOAF, GEONAMES, DOAP, voiD, DCAT etc.
7. ADMS is a semantic concept with different ways of technical implementations. Technical implementations of the semantic concept may comprise RDF-Schema, XML-Schema and a UML class diagram representation.
8. ADMS has to be designed in a way that changes (if necessary) will not affect current state of integration and the functionality of the federated search. Costs of maintenance and change have to be minimized.
9. Future modifications to ADMS take place guided and documented by an open and transparent change management process.
10. In a common spirit of willingness to share results and deliverables of this work, the Asset Development Metadata Schema will be published free to use by anyone under the European Union Public Licence version 1.1.

The guidelines of ADMS development have to give clear advice how to set up the initial concept of the metadata schema and to make clear how to proceed with further development and maintenance.

11. The documentation of ADMS has to be well maintained to promote consistency in its application.
12. Names of elements and attributes have to be as intelligible as possible to a general audience.
13. Provide an option to include elements from other schemas where appropriate.
14. ADMS has to document and publicize mappings to other metadata standards and implemented metadata schema from the federation of repositories
15. Define options for coded or natural language information. Allow options to specify language for certain attributes like "Title", "Description" etc.
16. ADMS should contain unrestricted value options for attributes (such as "display-Label") and elements that are likely to have local or customization needs.

At the moment we see the use case of "federated search". Please feel free to provide further use cases.

ADMS derived from the business need of being able to do a "federated search" in existing repositories.

The scenario can be described as follows:

Working on a new eGovernment project, a user is in the need of a specific code list on - let’s say - a list of delicts for the European Arrest Warrant project.

Without ADMS:
The user will perform a search engine query and/or visit the Danish, Greek and European Repository scouting for "Internal Security", "Justice", "Codelist", "authority table", or "name value pairs".

While browsing the different repositories, the user will be faced with a variety of

1. different user interface designs,
2. different classification schemas for domains
3. different user logins, passwords and usage rights
4. different metadata

With ADMS:
The user enters one of the federated ADMS-enabled repositories. He will use the commonly agreed taxonomy to navigate to the "Justice" domain. He then defines the artefact he is looking for - e.g. "codelist".

After a few seconds, the repository of his choice provides a result list, based on findings due to a local and a federated search in participating repositories.

The user will be able to do with one initial effort several queries into a number of repositories

1. using the same domain taxonomies
2. getting back a standardised set of results

ADMS hereby defines

1. what to expose to federation partners as a predefined subset of metadata (what is the commonly agreed core?)
2. how to expose the metadata (which vocabularies to choose).

Metadata that will form the ADMS minimum subset, the so called ADMS Core will only contain elements (classes and attributes) that are needed for most frequent search cases.

Figure 4 visualises the initial choice of vocabularies that are elaborated more in detail in the tables in the following sections.

Figure 4: Visualisation of ADMS Asset and Release

Taking into account the draft status and the feedback provided so far by the ADMS community, only a few elements lack of coverage by already existing vocabularies. Currently we think that the ADMS community will be in charge of developing the following vocabularies:

• adms:ArtefactType
  The type of artefact included in an assets' release
  Examples might be "UML Specification", "Ontology", "Taxonomy", "Codelist", etc.
• adms:Status
  The current status of an asset or release
  Examples might be "under development", "published", or "withdrawn"
• adms:Domain
  Domain(s) which are covered by the asset
  Examples might be "Justice", "Internal Security", "Economy->Trade", "Social Affairs->Education", etc.
• adms:QualityLevel
  The quality level achieved by the asset
  Examples might be "draft", "registered", "final", etc.

For some elements an appropriate vocabulary could not yet be found, needs your initial suggestions or cannot be represented by existing vocabularies:

• RepositoryOrigin
  The name of the repository this asset is stored in
• ReleaseNotes
  Information regarding a specific release (changes to previous versions, etc.)
• FileFormat
  The file extension / file format files of a release are containing e.g. XML, PDF, OWL, etc.
• AssetImage
  An image to represent the asset (something like an icon or logo)
• Tags
  comma-separated keywords to make the asset traceable

The following sections are used to define the elements of ADMS and its assignments towards existing or to-be-built vocabularies.

The following defines on a conceptual level

1. Metadata of repositories to be exposed for federation in general,
2. their definition (semantic statement) and
3. Its suggested assignment to ADMS Core and ADMS Extension.
4. Multiplicity of elements (optional, mandatory, multiple occurrences allowed?)

The element order within the ADMS specification follows the logic:

1. mandatory Core elements
2. optional Core elements
3. Extension elements

Additional information is given for each element

1. Whether it will be designed as an attribute (A) or a class (C)
2. What vocabulary the metadata element can be assigned to
   1. Name of the vocabulary
   2. Definition of the term as defined in its vocabulary
   3. URI (if applicable)
3. What values for this metadata element may be allowed (value vocabulary)
   1. Name of the value vocabulary
   2. Definition of the term as defined in its vocabulary
   3. Data type: URI (if applicable) / Literal / Code list

LOD vocabularies that will be reused in ADMS: