This is a placeholder page for describing good practices for the assigning of identifiers (IRIs) to vocabulary resources.
On topic are:
- Links to relevant W3C documentation
- Suggestions for IRI hierarchies
- How PoolParty can assign identifiers
- How to "work around" how PoolParty assigns identifiers, if you want to tweak it
- Information about persistent identifier services (purl.org, w3id.org, etc.)
Persistent identifier "services"
- Like the w3id approach, but redirect configs are written in YAML and then converted by script to RewriteRules for Apache HTTP Server
Resource identifiers and linked data
This section lists a variety of documents from the W3C related to resource identifiers and linked data.
- “Best Practice Recipes for Publishing RDF Vocabularies”:
- This covers:
- URI namespaces
- Content negotiation
- Hashes “versus” slashes
- The use of PURLs
- “Cool URIs for the Semantic Web”:
- “Ontology IRI and Version IRI”, in “OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax”:
- This explains how an ontology can have an “ontology IRI” and multiple “version IRIs”, and how these are to be managed.
- "Linked Data":
- This is Tim Berners-Lee's definition/description/rationale of the term "Linked Data" (i.e., with a capital "L" and "D"). Much of this is captured/elucidated in the "Best Practice Recipes" document listed above.
- “Dereferencing HTTP URIs”:
- This is a “thought bubble” document that raises the issues of:
- expectations of “users” in regards to how URIs “behave” (e.g., should they always resolve?)
- content negotiation
- representing associations between resource views using response codes (the meaning of 200, 303, 4xx, 5xx)
- 200 means “this is an information resource”; 303 means “this is not an information resource”, with the forwarding URI a “related” resource, which could be an information resource (returned using a 200 code)
- the use of fragment identifiers (#xxx), especially in combination with response code 303
- “Handling of fragment identifiers in redirected URLs”:
Note that when sending a request via HTTP, fragment identifiers (#xxx) are stripped from the URI. They are applied by the browser (or whatever issued the request). But what about if the server returns a 3xx status code?
Here’s the explanation of how fragment identifiers work in the presence of response codes 300, 301, 302, and 303:
“If the server returns a response code of 300 ("multiple choice"), 301 ("moved permanently"), 302 ("moved temporarily") or 303 ("see other"), and if the server also returns one or more URIs where the resource can be found, then the client SHOULD treat the new URIs as if the fragment identifier of the original URI was added at the end.
The exception is when a returned URI already has a fragment identifier. In that case the original fragment identifier MUST NOT be not added to it.
If the client retrieves the resource using the new URI and the resource turns out to be of a type that doesn't allow fragments to be identified, then the client SHOULD silently ignore the fragment ID and not issue an error message.
The response codes 304 ("not modified") and 305 ("use proxy") both indicate that the resource can be found in a different way, but do not specify a new URI. The resource is still identified by the original URI with the original fragment identifier.”
- UK Government Linked Data Working Group's URI Patterns: https://github.com/UKGovLD/URI-patterns-core/blob/master/URI%20Patterns.md.
Some real-world examples
- Simon Cox’s excellent collection of best practices for the formalization of vocabularies in SKOS:
- Covers assigning IRIs, ontology documents, versioning, collections and concept schemes, metadata, concept descriptions, etc.
- See also https://www.seegrid.csiro.au/wiki/Siss/SKOSandSISSvoc for SISSVoc-specific stuff.
- See also https://www.seegrid.csiro.au/wiki/Siss/SISSvoc30URIPatterns for more specific information about IRI patterns, Cool URIs, etc.