Skip to main content
Skip table of contents

Working with resource identifiers

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"

Resource identifiers and linked data

W3C documents

This section lists a variety of documents from the W3C related to resource identifiers and linked data.

  • “Best Practice Recipes for Publishing RDF Vocabularies”:

  • “Cool URIs for the Semantic Web”:

  • “Ontology IRI and Version IRI”, in “OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax”:

  • "Linked Data":

    • https://www.w3.org/DesignIssues/LinkedData.html

    • 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”:

    • http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14

    • 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

Some real-world examples

SISSVoc

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close