Skip to main content

URI Pattern Strategy Planning

Abstract

You need to have a good URI Pattern Strategy Planning.

URIs: Universal Resource Identifiers

Universal Resource Identifiers (URI) are meant to identify one resource in a digital context as unique.

Follow the design criteria when setting up a URI scheme. For example, these are some of the criteria:

  • Simplicity

  • Stability

  • Manageability

To meet these criteria please observe the following details:

Below find our suggestion to establish a URI strategy in your linked data project and how it is supported in PoolParty.

Create a Unified Scheme with a baseURI

There are a few different scheme types that we can distinguish:

  • data: for named graphs

  • resources: for example documents, data sets, people.

  • controlled vocabularies: for controlled vocabularies or taxonomies created in PoolParty. It describes the content of your resources and provides the controlled metadata.

  • ontologies and schemes: for those created in PoolParty. It defines the structure of resources or extensions to vocabularies.

You can use the same domain for all types, but it is advisable to make them distinguishable by type in the domain name as well, like this:

  • https://resource.domain.org

  • https://vocab.domain.org

  • https://scheme.domain.org

To provide internationally readable URIs and avoid problems with special characters in URIs, we suggest to create URI patterns in English.

Resource

Resources are typically not created and maintained in PoolParty but rather extracted from different sources (for example documents, data bases, CMS, and more) based on an ontology and mapped to vocabularies.

URIs in that case are created as part of the transformation process.

For resources the base URI should be followed by the type of the resource, then by the ID of the individual resource.

Document types could be:

  • a document

  • a dataset

  • an author

  • an organisation

  • ...

Example:

https://resource.domain.org/document/<ID>

Note

If the ID cannot be created from the source the data is derived from (which could be a person code, document-no., etc.) the ID should be generic.

Vocabularies

Here it would be possible to have one baseURI or to distinguish between different types of vocabulary. Possible baseURIs would be for example:

  • baseURI = https://terminology.domain.org

  • baseURI = https://taxonomy.domain.org

  • baseURI = https://thesaurus.domain.org

  • baseURI = https://vocabulary.domain.org

The baseURI should be followed by an identifier for the vocabulary and the concepts in the vocabulary should get a generic ID.

The URI pattern for vocabularies is defined when creating the project in the Advanced Project Settings.

You have to set up two additional options:

Custom Schemes and Ontologies

The <baseURI> is followed by the name of the scheme and the name of the property, for example:

https://scheme.domain.org/<scheme>/<element>

The URI pattern for custom schemes and ontologies is defined when you create them: Define the URI Pattern for a Custom Ontology or Custom Scheme

Use dereferenceable URIs

To provide full linked data capabilities URIs created in an Enterprise Linked Data environment should be dereferenceable.

That means an HTTP client looking up a URI via the HTTP protocol as response should retrieve a description of the resource identified by the URI. The description should be provided as web document and offered in the respective format dependent on the client ("audience") requesting the information (e.g. HTML browser -> html, RDF client -> rdf).

To achieve this content negotiation should be part of the whole Enterprise Linked Data architecture. Therefore HTTP clients using the infrastructure (looking up an URI) should indicate in the HTTP header of their request what kind of document they prefer. Based on that information servers can provide the appropriate response.

In this section: