Best Practices for registers and registries

The following best practices are extracted from "Best Practices for registers and registries & Technical Guidelines for the INSPIRE register federation".It describes best practices for setting up registers for INSPIRE, including for extended INSPIRE code lists. It also includes technical guidance for sharing national or community registers in the INSPIRE register federation and for using the federation’s access point (the “register of registers”) to search and browse through the registers included in the federation.

Based on the definition of a register from [ISO 19135-1], a basic register could already be created through a simple document (e.g. a text document or spreadsheet) that contains a list of items, each of which is mapped to an identifier.In this section, we add a number of best practices for the setting up and operation of registers that make them more useful in the context of a distributed spatial data infrastructure such as INSPIRE. Most of these recommendations are valid for any data being published on the web. Where relevant, we therefore include references to the relevant best practices in the Data on the Web Best Practices document [W3C DWBP] published by W3C.Typically, software packages or online services will be used for managing registers according to these guidelines / best practices.

The following list presents some best practices to follow in order to create/maintain registers/registries:

Best Practice 1: Use well-defined roles, responsibilities and procedures for register management

Clearly document roles, responsibilities and procedures for the management of a register and the registry through which it is made available.

Why

Having a set of roles and associated responsibilities helps to better understand the different parties involved in the registration and maintenance processes of a registry.

Intended Outcome

Register users will be able to understand who is responsible for managing a register and the registry through which it is made available and the processes for proposing and deciding about changes to register content.

Possible Approach to Implementation

The following roles and responsibilities are defined in [ISO19135-1] Chapter 5.

Register owner: a register owner is an organization that has established one or more registers, and has primary responsibility for the management, dissemination and intellectual content of those registers.

Register manager: a register owner may delegate the role of register manager to another organization. A register manager may manage multiple registers.

Submitting organisations: a submitting organization is an organization that is qualified under criteria determined by the register owner to propose changes to the content of a register.

Control body: a control body is a group of technical experts appointed by a register owner to decide on the acceptability of proposals for changes to the content of a register. A control body may not be required for simple registers.

Registry manager: a registry manager is a person or an organization responsible for the day-to-day management of a registry. A register manager may engage a third-party service provider to perform this service

Register user: Register users access a registry in order to use one or more of the registers held in that registry. Register users include any person or organization interested in accessing or influencing the content of a register.A possible list of procedures to manage the registration and maintenance process can be found in chapter 6 of [ISO19135-1].

Example

The following roles have been defined for the central INSPIRE registry:

Register owner: European Union

Register & registry manager: European Commission, Joint Research Centre

Submitting organisations: Each country represented in the MIG shall nominate a submitting organisation, typically an organisation representing the country in the MIG-T or another organisation involved in the coordination of the INSPIRE implementation in that country. In addition, the 2016.4 sub-group, the EEA, the JRC, and DG Environment shall be submitting organisations.

Control body: The members of the control body shall be selected by the INSPIRE MIG, in agreement with the Commission, from the INSPIRE pool of expert sand the representatives of the INSPIRE MIG.

Register user: anyone

Best Practice 2: Use resolvable HTTP(S) URIs as identifiers for registers and register items

Identify each register and register item by a carefully chosen, persistent and resolvable URI.

Why

Adopting a common identification system enables basic data identification and comparison processes by any stakeholder in a reliable way. They are an essential pre-condition for proper data management and reuse.
Developers may build URIs into their code and therefore it is important that those URIs persist and that they resolve to the same resource over time without the need for human intervention.

Intended Outcome

Registers and register items can be consistently referenced through time, regardless of the status, availability or format of the registers and register items.

Possible Approach to Implementation

To be persistent, URIs must be designed as such. A lot has been written on this topic, see, for example, the European Commission's Study on Persistent URIs [PURI] which in turn links to many other resources.
Where a data provider is unable or unwilling to manage a URI space (under a certain domain) directly for persistence, an alternative approach is to use a redirection service such as Permanent Identifiers for the Web or purl.org. These provide persistent URIs that can be redirected as required so that the eventual location can be ephemeral. The software behind such services is freely available so that it can be installed and managed locally if required.
Digital Object Identifiers (DOIs) offer a similar alternative. These identifiers are defined independently of any Web technology but can be appended to a 'URI stub.' DOIs are an important part of the digital infrastructure for research data and libraries.

Example

The INSPIRE themes register is identified by the following HTTP URI: http://inspire.ec.europa.eu/theme
The register item “Administrative Units” in the theme register is identified by the following HTTP URI: http://inspire.ec.europa.eu/theme/au

See also

  • Best Practice 9: Use persistent URIs as identifiers of datasets [W3C DWBP]
  • Best Practice 10: Use persistent URIs as identifiers within datasets [W3C DWBP]

Best Practice 3: Use item classes

Organize the different elements contained in a registry using item classes: an item class is a set of items with common properties (or attributes).

Why

Defining an item class, helps creating groups of items with the same set of properties. A register could contain items with different sets of properties (e.g. the INSPIRE code list register contains code lists and code list values which have different properties). Organizing the items contained inside the same register in item classes helps keeping items with the same set of properties grouped. In this way the item type can be easily distinguished inside a register.

Intended Outcome

Items with the same set of properties are organized under the same item class inside a register.
Possible Approach to Implementation
For each register, identify the group of items having the same set of properties. Each group is an item class. The item class can also contain a hierarchy.

Example

The hierarchical INSPIRE code list register contains two item classes, each with its own specific attributes:

  • Code list (containing e.g. information about the extensibility)
  • Code list value

Best Practice 4: Use well-defined statuses

Define a list of statuses for the elements: items shall be individually managed, moving through a set of well-defined states.

Why

Items inside a register can change over time. These changes may include simple modifications, bigger changes involving semantic modifications or even the supersession by other item(s), the retirement or the end of the validity of a specific item.
Keeping the status of the item helps understanding its validity.

Intended Outcome

Register users can understand the status of each register item, e.g. whether it is valid (i.e. can be used), proposed (i.e. should be used with caution), deprecated or superseded (i.e. should no longer be used).
Possible Approach to Implementation
Add to the items a field to specify the status. The status should be an URI pointing to the defined status register.

Example

The central INSPIRE registry4 uses the following status values:

  • submitted: The item has been entered into the register, but the control body has not accepted the proposal to add it.
  • valid: The item has been accepted, is recommended for use, and has not been superseded or retired.
  • invalid: A decision has been made that a previously valid register item contains a substantial error and is invalid, and will normally have been replaced by a corrected item.
  • retired: A decision has been made that the item is no longer recommended for use. It has not been superseded by another item.
  • superseded: The item has been superseded by another item and is no longer recommended for use.

Best Practice 5: Do not delete items

Once the elements are entered in a registry/register, they shall not be deleted in order to maintain the consistency of the registry. Instead of deleting items, a status that states the element as retired or invalid shall be used.

Why

URI dereferencing is the primary interface to data on the Web. If dereferencing a URI leads to the infamous 404 response code (Not Found), the user will not know whether the lack of availability is permanent or temporary, planned or accidental. If the publisher, or a third party, has archived the data, that archived copy is much less likely to be found if the original URI is effectively broken.

Intended Outcome

The URI of an element inside a registry system will always dereference to the element or redirect to information about it.
Possible Approach to Implementation
Instead of deleting items, a status that states the element as retired or invalidated shall be used.

Example

An example item which is no longer valid but still has a resolvable URI is the “Gazetteer” (http://inspire.ec.europa.eu/featureconcept/Gazetteer) item in the INSPIRE feature concept dictionary.

See also

  •  Best Practice 7: Preserve identifiers [W3C DWBP]

Best Practice 6: Provide registers in different formats

Make registers available in multiple formats. HTML should be provided for human consumption, and at least one machine readable format should be provided in order to enable programmatic access and exchange of information. Machine-readable formats should re-used existing standard vocabularies, e.g. SKOS Simple Knowledge Organization System [SKOS] or the Data Catalog Vocabulary (DCAT) [DCAT].

Why

Providing data in more than one format reduces costs incurred in data transformation. It also minimizes the possibility of introducing errors in the process of transformation. If many users need to transform the data into a specific data format, publishing the data in that format from the beginning saves time and money and prevents errors many times over. Lastly it increases the number of tools and applications that can process the data.

Intended Outcome

As many users as possible will be able to use the register content without first having to transform it into their preferred format.

Possible Approach to Implementation

Consider the data formats most likely to be needed and consider alternatives that are likely to be useful in the future. Data publishers must balance the effort required to make the data available in many formats against the cost of not doing so, but providing at least one alternative will greatly increase the usability of the data. In order to serve data in more than one format you can use content negotiation as described in Best Practice 7.

Example

The central INSPIRE registry provides multiple formats, including (custom and ISO 19135-1) XML, RDF/XML, JSON, ATOM and CSV.
See also

  • Best Practice 14: Provide data in multiple formats [W3C DWBP]
  • Best Practice 15: Reuse vocabularies, preferably standardized ones [W3C DWBP]

Best Practice 7: Use content negotiation for serving registers available in multiple formats

Use content negotiation in addition to file extensions for serving data available in multiple formats.

Why

As the Architecture of the Web5 and DCAT [DCAT] make clear, a resource, such as a dataset, can have many representations. The same data might be available as JSON, XML, RDF, CSV and HTML (see Best Practice 6: Provide registers in different formats). These multiple representations can be made available via an API but should be made available from the same URL using content negotiation to return the appropriate representation (what DCAT calls a distribution). Specific URIs can be used to identify individual representations of the data directly, by-passing content negotiation.

Intended Outcome

Content negotiation will enable different resources or different representations of the same resource to be served according to the request made by the client.

Possible Approach to Implementation

A possible approach to implementation is to configure the Web server to deal with content negotiation of the requested resource.
The specific format of the resource's representation can be accessed by the URI or by the Content-type of the HTTP Request.

Example

The central INSPIRE registry supports content-negotiation. Different representations of the items can be served according to the content type specified in the Accept: header of the HTTP Request.
The example below shows the call to the same resource with two different formats (XML and RDF/XML). GET http://inspire.ec.europa.eu/theme/ad HTTP/1.1 Accept: application/xml ... GET http://inspire.ec.europa.eu/theme/ad HTTP/1.1 Accept: application/rdf+xml ...

See also

  • Best Practice 19: Use content negotiation for serving data available in multiple formats [W3C DWBP]

Best Practice 8: Provide registers in different languages

Provide registry and registers in all the languages that are available in the specific national context. In a European context, it may also be useful to provide the registry and register data in English.

Why

The availability of all the languages used in a national context will increase the usability of the registry system. In addition, the availability of a commonly used language such as English, will allow also foreign users to access the information available in the registry.

Intended Outcome

As many users as possible will be able to access the register content in their preferred language.

Possible Approach to Implementation

The registry system shall provide a mechanism to select the available languages and to provide the registry content in the selected language.

Example

The central INSPIRE registry is an example of a registry system that provide the information in multiple languages.