Re: Digression on URI patterns (was Re: Library data diagram)

Hi Jeff,

On Sat, Sep 04, 2010 at 10:49:54PM -0400, Jeff Young wrote:
> > Picking up on this point...  The examples given for
> > "303 URIs forwarding to One Generic Document" show
> > 
> >
> > 
> > redirecting to
> > 
> >
> >
> Sorry for the nitpick, but the 1st URI identifies the "generic document"
> and doesn't do a redirect in this Linked Data pattern (note the /doc vs.
> /id path segment). Here's the diagram we can refer to if the situation
> is somehow unclear:

Right - I was not precise enough.  In [1], it is the URI
ending in "/id/alice" that _redirects_ to "/doc/alice",
which in turn _content_negotiates_ to "/doc/alice.rdf" and

However, the URI cited above [2] is from the previous section on 
Hash URIs.  I believe you mean to refer to the diagram in the 303
section [3].


> > If one were to retrieve these files using HTTP (e.g., with "wget"), the
> > files would be called:
> > 
> >     alice.rdf
> >     alice.html
> The concept of "file" is problematic and may be worth discussing. The
> Cool URIs document actually makes a point about this:
> 	"Note that a Web document is not the same as a file:"

The point in Cool URIs was that on the Web, a Web Document
is not necessarily a file but can be served up in multiple
languages, and that "a single file, for example a PHP script,
may be responsible for generating a large number of Web
documents with different URIs".

My point was that when I dereference the URIs using HTTP GET,
the download results are two files in my local filesystem,
alice.rdf and alice.html...

> I would argue that the URI pattern that appears in the Cool URIs
> document is only useful for toy examples. 

Tom points to the example:
> > which Jeff comments:
> Light alteration to fit my preferred pattern would result in something like this:

Tom points to the example:
> > which Jeff comments:
> the URI pattern I prefer would have looked something like:

You are calling into question the pattern outlined in Cool URIs
and followed by BBC and LoC - a bigger issue indeed...! :-)

> Ultimately, the value of Linked Data boils down to unexpected reuse of
> well-modeled resources suitable for use from diverse perspectives.
> Regrettable URI patterns limit the domain's ability to reuse these
> resources unexpectedly themselves. Take any of the URI examples you've
> given and ask yourself how they could be enhanced to support mobile
> browsers without crippling desktop browsers or separating themselves
> from the Semantic Web in the process.
> There's more to this URI pattern's story, but this seems like a good
> start. The $64 question is whether people think URI patterns are the
> latter-day equivalent of angels on the head of a pin?

_Before_ creating millions of new URIs based on a pattern
is an excellent time to review the pattern, and I do not
think it is like theorizing about angels on the head of a
pin because the behavior of real applications dereferencing
real URIs is at stake.  

We could continue to discuss this on public-lld; it is very
relevant to the topic "library linked data"!  We can also flag
it as an issue (and possible candidate for follow-up actions)
in the LLD Incubator Group.  However in my view, detailed
technical discussion should be out of scope for the Incubator
Group per se.  Since this is relevant to more than libraries,
this would be a great issue to raise on the Pedantic Web list



Thomas Baker <>

Received on Sunday, 5 September 2010 15:04:50 UTC