A proposal involving my original reason for commenting on httpRange-14

First, to be honest - I've been so busy with work that I have not had
the time to read the 100+ emails on the topic in the last few days, or
the associated documentation. But given the TAG is meeting in a few
minutes over this subject I think...

I just want to clarify one thing - I'm not expecting perfect
philosophical clarity from the TAG, but to solve a mundane engineering
problem. The required use of 303 HTTP Redirection for Linked Data
simply raises the barrier of deployment too high and causes excessive
redirects. While the Linked Data Cloud is impressive, it is only the
first step. I want the ability to simply upload a RDF file to a
website, add some links, and call that "linked data". Using 303
redirection is simply too hard and out of the ability of many people,
particularly those not using specialized Linked Data Software. Lastly,
anything done on the level of HTTP codes *should* be possible to do
via a RDF statement in a RDF file itself. There should be no "HTTP
Magic".

My proposal has two parts:

First, I suggest we add a "DescribedBy" RDF statement and its inverse
"Describes". "Describes" allows one to state that one's URI in an
uploaded RDF file describes (is "metadata about") another URI, and
vice versa for "DescribedBy". This can also be done by a Link Header,
but I would think the Link Header would have the same issues as 303.

Second, I suggest that we *not* require the use of 303 or any
"DescribedBy/Describes" RDF assertion (or even HTTP Link Header). The
reason is that separating the URI of a "thing-of-itself" from the URI
of "data-about-the-thing" is simply *not* necessary for all use-cases.
It can be necessary and useful though, which is why I suggest we give
"semantically equivalent" options of using 303, a Link Header, and a
RDF statement.

I'd suggest one way out is also to punt this problem to the Linked
Data-ish REST-ish WG. However, a quick and clear - even if only
tentative - answer from TAG  makes sense.

     cheers,
          harry

Received on Monday, 2 April 2012 08:55:39 UTC