"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

URI Patterns for vocabulary services and resources

Vocabulary interfaces

In order to satisfy a range of vocabulary users, you will usually provide four different interfaces to your vocabulary, as follows (with example URIs):
  1. For each item in the vocabulary, HTTP GET {URI} should resolve to a description of the item. This is suitable for direct reference to vocabulary items, and in-line links within datasets.
  2. A SISSvoc interface to the vocabulary, supporting queries on properties of the vocabulary items, with various options for how the result is formatted and what is included. This is for general users who want to explore a vocabulary without having to know RDF or SPARQL.
  3. A SPARQL endpoint for the vocabulary. This is for researchers who want live access through the SPARQL API.
  4. The vocabulary bundled as a single document (file) delivered from the "Ontology URI". This is for users and services who wish to harvest the whole vocabulary in one transaction.
These interfaces are distinct from the end-users point of view. However, internally each interface uses the next one down either for its configuration or real-time operation.

... at Cool URIs

The examples above use "Cool URIs" in the sense that
  1. they are reasonably intuitive,
  2. the URIs identify the resource rather than the specific technology. The terms in the path indicate what (i.e. a SISSvoc service, a SPARQL endpoint, an ontology document), rather than how (elda, sesame, apache).
This latter concern means that a real deployment may require redirections and proxies, to turn technology-centric URIs into technology-neutral URIs.The Cool URIs should be more persistent, since the same resource can be delivered from the same URI, even if the choice of specific technology changes.

Relation to Semantic Web URIs

The W3C note Cool URIs for the Semantic Web describes some URI patterns and use of HTTP response codes to match semantic web expectations. There is a particular focus on keeping the distinction between Information Resources and Non-information resources clear.

SISSvoc is an LDA configuration designed to deliver descriptions of things
  • as known to the SISSvoc instance, and
  • where the URI for the thing is not directly related to the SISSvoc URI.
The general SISSvoc URI pattern is
  • http://example.org/sissvoc/{type}[/{relation}][?{selection-parameters}[&view-parameters]]
and the way to request SISSvoc to deliver the description of a resource whose URI is known is The semantics of the resource identified by this URI are The owner of {resourceURI} may choose to redirect requests for the URI to a SISSvoc service. In that scenario the complete system could be considered to effectively implement a variant ĎCoolURIí pattern which says
  • you asked for {resourceURI} which is a non-information resource or else just something I canít tell you anything about myself, so Iím sending you to http://example.org/sissvoc to provide a description instead
This is arguably a more explicit rendering of the semantics than any of the classic CoolURI patterns, which all require you to have read, understood and obeyed some reasonably obscure documents, and which as Jeni Tennison blogged has not been widely achieved in practice.

N.B. If you configured the LDA service to be http://example.org/doc][http://example.org/doc instead of http://example.org/sissvoc][http://example.org/sissvoc it all would be closer to one of the classic CoolURI patterns.

URI versioning?

We generally recommend that URI for a concept is not versioned, since the abstract concept itself does not change. What we know about the concept may change over time, so the URI for a document or graph may be versioned. Furthermore, a concept may be included in different concept-schemes or ontologies, so the URI for the container may be versioned. Finally, for completeness we can note that different services may know different things about a concept, and each service will have a different URI. But it is helpful if all these different resources (descriptions, collections, services) refer to a concept using the same unversioned URI.

'Concepts' are usually considered to be non-information resources (NIRs), for which a SKOS document is a related description. A SKOS description is a set of RDF triples or 'graph', and therefore an Information Resource (IR). A graph may be versioned, but the node in the graph that is the subject of the RDF statements that describe the concept does not have a version.

-- SimonCox - 28 Feb 2012
Topic revision: r4 - 28 Feb 2012, SimonCox
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).