Step 4: Define a naming scheme

Versie door Seckartz (overleg | bijdragen) op 9 dec 2014 om 13:39 (→‎Name things with URIs)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Name things with URIs[bewerken]

This step will provide guidelines on how to use URIs (Universal Resource Identifier) in order to identify your data. One of the principles of linked data is that each object and relation is uniquely identifiable with a URI, both on set and element level. The use of persistent and unique identifiers, such as URIs, URLs and DOIs is an important quality aspect. As a linked data publisher you should therefore give careful consideration to the selection and consistent application of your URI strategy, i.e., the scheme used for assigning URIs to data elements. We propose to use national and international best practices whenever possible.

The W3C lists the following as best-practice:

  • Use URIs as names for things.
  • Use http-URIs, so that people can look up those names.
  • When someone looks up a URI, provide useful information, using standards (RDF, SPARQL)
  • Include links to other URIs, so that they can discover more things.


Based on more practical experience the SEMIC project identified rules that should be taken into account.

  • Take data changes over time into account
  • Use clean, stable URIs
  • Use natural keys
  • Follow the pattern
  • Re-use existing identifiers
  • Link multiple representations
  • Implement 303 redirects for real-world objects
  • Use a dedicated service
  • Avoid stating ownership
  • Avoid version numbers
  • Avoid using auto-increment
  • Avoid query strings
  • Avoid file extensions


In this step we define a scheme for assigning URIs to the dataset. We propose to use national and international best practices whenever possible. link up with international best practices by e.g. largely following the proposed Dutch national URI-strategy. We propose the following structure:

In the Netherlands the working group: “URI-strategy” (as part of the PiLOD project) has formulated a number of starting points that should be observed upon drawing up a URI strategy:

  • Link up with international best-practices. You can go faster on your own, but you will go farther by working together. By linking up with international developments, you benefit from solutions that are devised on a global scale. In addition, European regulations are becoming increasingly important to the Dutch government.
  • Link up with existing developments. The strategy concerns many parties and systems and cannot be implemented all at once as something new. And so it is wise to assess what is already taking place in the sphere of standardisation and authentic registrations and to reuse that as much as possible.
  • Anticipate deviating systems. Even if systems are developed that, for whatever reason, do not observe the national strategy, it must still be possible to link to these systems.
  • Keep it as simple as possible, but not simpler. If the approach is too complex, then the strategy will not be adequately applied, or not applied at all. If the approach is too simple, then the strategy will not yield sufficient results.


The “URI Strategy” working group is working towards a Dutch national URI strategy. They currently propose the following structure:

http://{domain}/{type}/{concept}/{reference}

where

  • {domain} should be an internet domain (URL) that the data owner controls where the data will be published and the URIs can be dereferenced. Optionally, this includes a path within that domain: {domain} = {internet domain}/{path}.
  • {type} is either ‘id’ if the URI is an identifier of an object (individual/instance), ‘doc’ if it refers to the metadata about an object, or ‘def’ if it refers to the definition of a concept in an ontology.
  • {concept} is the name of the concept to which the object identified by the URI refers.
  • {reference} should be a unique number or code identifying the object within the namespace. It can be a name or a number, as long as they are unique and not too long.


Go back to overview