Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

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/