W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2005

Re: URIs in examples

From: Thomas Baker <thomas.baker@bi.fhg.de>
Date: Thu, 27 Jan 2005 15:33:33 +0100
To: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>
Cc: "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>
Message-ID: <20050127143333.GB1788@Octavius>

On Mon, Jan 24, 2005 at 01:42:22PM -0000, Alistair Miles wrote:
> 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').
..
> What do we think about this?

Alistair,

This is a very helpful explanation; I suspected there
was some such reasoning behind the choice.  

Still, it feels to me like an odd compromise position
between the notion that URIs are OPAQUE -- with no implied
semantics (ergo http://foo.org/bananas#concept is as good
as http://foo.org/xyz.310001.211 or anything else) --
and the notion that URIrefs are NOT OPAQUE because the hash
semantically implies a document and what follows the hash is,
also by semantic implication, a concept.  (Hmm, does it really
imply "a concept" -- or by analogy to [1], which implies the
concept "personal title", does it actually imply the concept
"concept"?)

The argument you make is plausible, but in the end, the URIrefs
still look really broken, at least to me!  It is not clear
to me that the concept of "bananas" [2] is any more or less
abstract than the concept of "personal title" [1].  It is
therefore not clear to me on what criteria the SKOS concepts
would require special treatment as "abstract components".

The naming style does, however, seem to imply the existence of
documents such as a "banana" document.  At the same time, as
you point out, the style does involve sacrificing the notion
of "namespace" as a device with convenient syntactic uses.
Between the banana document and the missing namespace,
moreover, there is no implied identifier for the SKOS Core
vocabulary itself.  This may actually be a good thing if the
object of interest is less "the SKOS vocabulary" and more
"the SKOS model" (as I argued in my review).  However, this
all feels really confusing!

Unless "#concept URIs" are being used elsewhere (and for the
same reasons!), and there is evidence that the idea is really
getting traction, the approach would seem to be dangerously
experimental for something as fundamental and (hopefully)
persistent as a URI.  It seems like the sort of issue that
ideally would be thoroughly hashed out on the list before
making such a commitment.

FWIW, DCMI opted a long time ago for "slash URIs", though
a strong movement to "hash URIs" for the future would not
necessarily have any negative practical consequences, as I
understand it, because DCMI's vocabularies are relatively
small.

> 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.

I agree with that position, though I wonder whether the
dereferencing problem needs to be handled in HTTP itself
as opposed to being handled by the networked resource being
referenced.

Bottom line (for the finalization of the SKOS documents): I
would like to suggest a pause for reflection about the form
of the URIrefs.  If it is too late for such a pause (e.g.,
because the notion of "#concept URI" is being implemented and
getting traction), then I would suggest that the rationale
for this naming style be captured in a "Naming Policy" for
SKOS -- something like [3] and [4].  This policy could be as
simple as a paragraph or two in the core spec.

Tom

[1] http://www.example.com/bananas#concept
[2] http://www.w3.org/2000/10/swap/pim/contact#personalTitle
[3] http://dublincore.org/documents/dcmi-namespace/
[4] http://dublincore.org/documents/naming-policy/





> > 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
> 

-- 
Dr. Thomas Baker                        Thomas.Baker@izb.fraunhofer.de
Institutszentrum Schloss Birlinghoven         mobile +49-160-9664-2129
Fraunhofer-Gesellschaft                          work +49-30-8109-9027
53754 Sankt Augustin, Germany                    fax +49-2241-144-2352
Personal email: thbaker79@alumni.amherst.edu
Received on Thursday, 27 January 2005 14:31:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:53 GMT