Before I comment, I just want to summarise my understanding because
http-range-14 is a weird term;
I understand it as the range-14 issue that when you use 302 to redirect
from a URI-A to a URL-B we have a convention that URL-B has some
relationship to URI-A but it's not defined, we don't treat this as
semantic information and tend to throw it away.
(stated to make sure I've understood correctly)
This bit a chap working with some of my data;
* he loaded some data from <URI-A> using a library
* URI-A did a nice content-negotiated 302 to URL-B (and RDF document)
* URL-B had a description of <URI-A>
* The problem was he also wanted to auto extract the license for this
data, but the triples gave the license as a relation to <URL-B>, but the
system treated the data as loaded from <URI-A>
At the most simple level, we could add some triples when loading a graph
via redirection...
<URI-A> myprefix:http302redirect <URL-B>
or something richer with dates, http options etc.
You could do something even fussier with http headers stating an
explicit relationship with the 302, but all of this is very nice but the
main problem seems to be that it's hard and doesn't benefit someone who
just wants to knock something up quickly.
The real problem seems to me that making resolvable, HTTP URIs for real
world things was a clever but dirty hack and does not make any semantic
sense. We should use thing://data.totl.net/scooby to refer to the dog
and have a convention that http://data.totl.net/scooby will refer to
some content about my dog. This URL can of course then content negotiate
as normal. You could also use this in reverse.
*thing*://www.imdb.com/title/tt0910554/ is the primary topic of
http://www.imdb.com/title/tt0910554/
Yes, you could end up with a whole bunch of URIs for the same thing;
thing://data.totl.net/scooby thing://data.totl.net/scooby.html
thing://data.totl.net/scooby.pdf thing://data.totl.net/scooby.csv all
are the same thing, but big deal.
The only tricky thing would be people may get confused about the "thing"
URI related to a document. For example, given a document in pdf, word
and html, you might need a separate thing:// URI to describe the
abstract concept of the document, but that's not the primary topic of
any of the documents. Such fiddling details are more the province of
people with experience, so I'm not too worried. What we should be doing
is making the common garden data really easy to produce.
I've spent a lot of time trying to teach these concepts to people at
hackdays & barcamps, plus in a professional context. http:// URIs for
real world things clearly make it harder to learn. The follow-you-nose
gimick is cool, but we could do that with a change convention, and a
trivial update to existing libraries (just resolve thing:// via http://)
I expect the answer is "it's too late to change now". To which I am
tempted to say "change or die".
(again, another Monday morning ranty mail! but I feel like someone
should be commenting on the emperors URI convention. If there's a cheat
sheet I should read before continuing commenting on these subject,
please point me to it.)
Kingsley Idehen wrote:
On 6/13/11 1:28 AM, Pat Hayes wrote:
But I don't think all this is really germane to the http-range-14
issue. The point there is, does the URI refer to something like a
representation (information resource, website, document, RDF graph,
whatever) or something which definitely canNOT be sent over a wire?
The Referent of a URI re., http-range-14 is the observation (or
description) subject. In this context the subject may or may not be a
real world object or entity.
In the context of Linked Data, the observation (or description)
subject URI resolves to a Representation of its Referent. Actual
representation is accessible via an Address. Data representation
formats are *optionally* negotiable e.g., via content negotiation, and
ultimately varied i.e., many serialization formats for byte stream
that actually transmits data from its source to its consumers.
--
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248
You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/
