URI Pattern Strategy Planning

This section contains the general information about URIs and efficient URI pattern configuration in PoolParty.

URIs: Universal Resource Identifiers

Basically Universal Resource Identifiers (URI), as the name implies, are meant to identify one resource in a digital context as unique.

In the Semantic Web World the following design criteria are important for setting up a URI scheme:

  • 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

Three different types of scheme are to be distinguished:

  • data: for named graphs

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

  • controlled vocabularies: for controlled vocabularies or taxonomies created in PoolParty: describing the content of your resources and providing controlled metadata.

  • ontologies and schemes: for those created in PoolParty: defining 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:

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:

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 settings of the project.

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: Please use the Advanced tab of the dialogue.

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.