Re: Change Proposal for HttpRange-14

Jonathan,

I'm aiming here to clarify the proposal as if the points aren't clear from the Change Proposal, we should reword it. Of course technical discussion of the merits of the proposal should wait until it is submitted to www-tag, discussed by the community and assessed by the TAG according to the process that you have set in motion.

On 23 Mar 2012, at 17:47, Jonathan A Rees wrote:
> This looks like infinite regress to me.
> 
> You have <U> describedby <V>. You want to find the description <V> so
> that you can figure out what <U> means. So you need to know what
> content <V> refers to, so that you can obtain and read it.
> 
> According to the proposal, to do this, you dereference V, and need to
> find some RDF of the form
> 
> <V> property object.

You do not need to find any RDF in the form <V> property object, but you might do. In the same way, if you have U->303->V, V does not need to contain triples about V, but it might do.

Could you identify the part of the proposal that makes you think that V needs to contain RDF of the form <V> property object?

> What does this RDF look like, such that you can know that the
> description is what is retrieved from V, as opposed to some other
> resource?

Didn't you just retrieve it from V? I don't understand the question.

> In practice I very much doubt that any such triples are deployed at
> present. If you GET V, you will find information about <U>, but not
> about <V>.

If you get V you might get triples about U and you might get triples about V. If someone has cared enough to set up a separate resource V to describe U then you are likely to find triples about V as well as some about U. But yes, there is no requirement that V contain any triples about V. I don't think this is a change from your document, do you think it is?

> Most likely nothing will be said about <V> at all. And the
> proposal says nothing can be inferred in this case.

No, the proposal says that if as an application you have seen a statement like <U> describedby <V> then you can infer that V is an information resource. Given that you found V through a statement <U> describedby <V>, you can make this inference, as you could if V was located through a 303 redirection from U or from the 'describedby' Link: header.

This was the intention of the replacement to the first paragraph of Section 4.2. Which part do you think isn't clear?

> Then there's the question of what RDF to write. It doesn't work to say
> <V> describedby <W>, since we get an infinite regress.

Yes it does, that's fine. W may well contain triples about V, or about U or indeed about any other resource, this being how linked data works.

Which part of the proposal or your original document makes you think that this wouldn't work and in what way does it fail?

> <V> describedby
> <V> is uninformative, since many documents are self-describing - this
> doesn't tell you that the intended document is the particular
> self-describing document you get from V.

Assuming that you have retrieved the document through a 200 response from V, <V> describedby <V> is informative because it enables you to infer that the document is a current representation of the resource identified by V and that
V is an information resource (since it is the object of a describedby statement). (As above.)

Of course you knew these two facts already since you got to V through <U> describedby <V>, but it wouldn't *hurt* to include it, in case someone came to V without going via U. V could also contain other describedby statements of which it is the subject, pointing to more documents that contain information about V. It could also contain other describedby statements of which it is the object, and if it contained such statements you could make the inferences described above.

> I think you need something like
> 
> <V> w:instanceURI "V".
> 
> in order to be able to specify the "location" of information that is
> identified by a URI. Otherwise there is just no telling where it might
> be. (See http://www.w3.org/2001/tag/2011/09/referential-use.html)
> 
> Of course httpRange-14(a) as written doesn't solve this problem
> either, so this complaint is not really specific to your proposal. (I
> think it was *meant* to solve the problem, and just let you use <V> to
> refer to the content at V, without having to write any extra
> metadata.) But by relying much more heavily than at present on
> metadata such as describedby to understand what is going on, I think
> it makes the problem that much more prominent.


I'm afraid I don't understand the problem you're describing sufficiently to be able to comment.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 23 March 2012 18:59:02 UTC