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

Harry,

Just looking at the proposal and putting off the important question of
venue (which the TAG agreed to postpone considering until after I've
finished action-691 - which causes me to write this message to you), I
don't see how your proposal supports the use case you gave last year.

I've tried to write up your use case here:
http://www.w3.org/wiki/HTTPURIUseCases#J.29_Naive_linked_data
If I've made the case too strongly let me know and I'll be happy to
revise it, but I've just tried to write down what I thought you and
Manu were saying.

Isn't the overhead of deploying a second URI going to put off a lot of
people in the constituency you were trying to represent?

Don't you want the RDF in the content, and/or the RDF that's in the
message near the use of the URI, to bear on what the sender and
receiver think the URI means? Isn't that a requirement for your
"otherwise linked data will die" use case?

If it's just left unspecified, you don't rule out the possibility of
senders who think the URI refers to the content miscommunicating with
receivers who think the URI refers to what the content says the URI
refers to, or vice versa. This distinction will be important in most
cases (except of course for self-describing documents, where they're
the same), if only because the message or content or the combination
of the two is nonsensical if the sender or receiver gets it wrong.

There are three sources of information that the sender and receiver
might agree to use to decide what's meant: prior agreement (a
'standard' or community practice of the sort we've been discussing),
the sender's message context as in "punning" or "just be clear" type
solutions, and the retrieved content as in "just read what it says"
solutions. Just saying that there is no agreement doesn't work;
senders and receivers have to agree to something, if only to look at
the message and/or content, if there's going to be effective
communication using the URIs in question.

I think I'm just asking all the proposal writers to state what is
obvious to them, because nothing having to do with this issue is
obvious to someone who tries to think logically about it. Of course
stating the obvious is very hard.

Best
Jonathan

On Mon, Apr 2, 2012 at 4:55 AM, Harry Halpin <hhalpin@ibiblio.org> wrote:
> 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, 23 April 2012 19:15:33 UTC