Re: Change Proposal for HttpRange-14

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.

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?

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>. Most likely nothing will be said about <V> at all. And the
proposal says nothing can be inferred in this case.

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. <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.

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.

Jonathan

Received on Friday, 23 March 2012 17:47:58 UTC