URIs in examples

> 4. Some of the URI references used in the examples of SKOS
>    Core Guide seem odd.  For example:
> 
>          http://www.example.com/bananas#concept
>          http://www.example.com/wetness#concept
> 
>    According to the RDF Primer, "#" indicates that what
>    follows is a fragment identifier. The Primer itself uses
>    URIrefs such as:
> 
>          http://www.w3.org/2000/10/swap/pim/contact#mailbox
>          http://www.w3.org/2000/10/swap/pim/contact#personalTitle
> 
>    meaning something like:
> 
>          the property "mailbox" in the "contact" vocabulary
>          the property "personalTitle" in the "contact" vocabulary.
> 
>    Never mind that URIrefs are in principle opaque...!
>    Following the RDF Primer example, one might take the
>    SKOS Core examples above to mean something like:
> 
>          the concept of "concept" in the "bananas" vocabulary
>          the concept of "concept" in the "wetness" vocabulary
> 
>    instead of what was probably intended:
> 
>          the concept of "bananas" in an example vocabulary
>          the concept of "wetness" in an example vocabulary.

For the SKOS Core Spec and Guide I chose URIs of the form

          http://www.example.com/bananas#concept
          http://www.example.com/wetness#concept

as a deliberate attempt to compromise between the divided opinion of the W3C
TAG (and the wider community) wrt the issue of whether HTTP URIs may be used
to identify abstract components.  

As I understand it, both Dan Connolly and TimBL (among others) assert that
HTTP URIs without frag IDs ('slash URIs') should be used only to refer to
documents.  However, HTTP URIs with a fragment identifier ('hash URIs') are
OK for abstract components.  This list has received a specific
recommendation from Dan C not to use slash URIs in SKOS Core examples [1].  

However, the main problem with 'hash URIs' such as 

>          http://www.w3.org/2000/10/swap/pim/contact#mailbox

is that all the URIs of the vocabulary must necessarily dereference to the
same document, if they dereference to anything.  This is problematic for
large vocabs, because the documents get big.

URIs such as 

>          http://www.example.com/bananas#concept
>          http://www.example.com/wetness#concept

represent a compromise, because they are hash URIs and therefore are on
slightly less shaky (?)philosophical ground wrt whether or not it is OK to
use them for abstract components.  And each concept URI can be set up to
dereference to a separate document, or not, depending on what is required.

So following DanC & TimBL's line on best practise, the URI
http://www.example.com/bananas would be used to identify a document (i.e.
information resource) that described a single concept, and the URI
http://www.example.com/bananas#concept would be used to identify the concept
itself (coming 'out of the plane of the document').

The only problem with these sorts of URIs (let's call them '#concept' URIs)
is that you can't have nice looking qname syntax in N3 or RDF/XML docs.  

My current personal view (fwiw) on this debate is that it should be fine to
use slash URIs to identify abstract components, and a new redirect code
should be introduced to HTTP to handle dereferencing of abstract components.
However, given that this issue is still unresolved, I thought it best to
choose the most 'neutral' ground for now (and point off to the VM TF note
for further reading - i.e. passing the buck :).

What do we think about this?

Cheers,

Al. 



[1] http://lists.w3.org/Archives/Public/public-esw-thes/2004Sep/0012.html

Received on Monday, 24 January 2005 13:42:56 UTC