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 setting up and operating 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:
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 understand better 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 registered 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 experts and the representatives of the INSPIRE MIG.
Register user: anyone.
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 following HTTP URI identifies the INSPIRE themes register: 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]
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 to create 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 to keep 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 items with 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
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 another item (s), the retirement or the end of the validity of a specific item.
Keeping the status of the item helps in 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 a 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.
Once the elements are entered into 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 in the original URI and 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]
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-use 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 to 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 will likely 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]
Use content negotiation in addition to file extensions for serving data available in multiple formats.
Why
As the Architecture of Web 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. Still, they 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]
Provide a 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 registered 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 provides information in multiple languages.