Re: URIs, used in RDF, that do not have associated documentation

>>> Remember that I've stated my dismay that httpRange-14(a) says "is an
>>> information resource" rather than addressing the ambiguity mentioned
>>> in Fielding's email (as illustrated by the Flickr and Jamendo cases).
>>> httpRange-14(a) as written doesn't really help, except that its
>>> authors and nearly everyone else have interpreted it to resolve the
>>> ambiguity in a particular way - that the URI refers to what you
>>> retrieve (generically if you will), not to what is described by what
>>> you retrieve. This interpretation *has* been helpful because it lets
>>> you use these RDF-less URIs in RDF and be understood. That the
>>> resolution didn't say what was meant was a colossal screwup IMO. But
>>> let's set that aside and just look at the question.
>>
>> Saying that the URI refers to what you retreive is not consistent with
>> the HTTP specification, in which resources and representations are
>> clearly seprate entities. Saying that they are equivalent confounds them,
>> and one of the axioms of RDF is that two things should not use the same
>> URI.
> 
> Nobody who has followed this discussion is saying this. Not me, not
> Tim, not anyone. (I think Ian Hickson said it once, but he's not
> involved in this discussion.) If this is what you think then I'm not
> sure how we can discuss this matter.

I'm sorry it this came across the wrong way. In hindsight, "equivalent"
was not the right word to use. You wrote that the common interpretation
of httpRange-14 is that the URI refers to what is retrieved. A lot of the
messages on the mailing list are describing a GET/200 as a URI returning
content, and as it returning instances the resource. Add to this the
fact that the URI also denotes an information resource, and that the
definition of information resources is that all of their essential
characteristics can be conveyed in a message. Since the message in
question is supposed to be the retrieved representation, this implies
that the information resource and its representation share all essential
characteristics. Although not strict equivalence, I always thought that
this sounded like they are constrained to be very similar. On the other
hand, the HTTP specification says that what is used a representation of
an URI is something the URI owner defines. If he defines them not to
share their essential characteristics, then httpRange-14 fails.

In a theoretical sense, no one (excluding Ian Hickson for now) says that
they share the same URI. But one hand the URI *denotes* the resource,
on the other hand the URI *refers* to the representation. If you can
point me at a precise definition of these two verbs, that would be
very helpful, but even if they mean different things, there is ample
room for misunderstandings.

> My views on the matter are put down here:
> http://www.w3.org/2001/tag/awwsw/ir/latest/
> Tim has written about this as well:
> http://www.w3.org/DesignIssues/Generic.html
> 
> I have never claimed that the generic resource idea follows from the
> HTTP spec. I have just said that, empirically speaking, many people
> writing metadata assume that this is how things work. It would
> therefore be a good idea to codify the practice, or at least avoid
> making statements that discourage it.
> 
> You may disagree with the ideas, but don't claim I'm not aware of how
> HTTP or Web architecture work.

I am profoundly sorry it this is how it came across. I have the uttermost
trust in your knowledge of this area and am grateful for all the hours
you are putting in trying to clarify these issues. My response was not
directed at you personally, it was more of a comment on how httpRange-14
is applied. The content of your original mail was also used as a reply
to my proposal, which due to a mistake on my behalf ended up off list.
Thank you very much for re-posting it, by the way. The offending
paragraph was meant as a short introduction to my position in this
matter for new readers, that is all.

Speaking of which, I am really interested in your reply to the subsequent
part of the mail since you argued that my propsal would break deployed
RDF, which certainly is not my intention. Acknowledging that I was the
one who put it in there in the first place, I would really appreciate if
the discussion don't get side-tracked by the IR issue, and instead
continues with the interesting stuff.

Tore

_______________________________________________________________
Tore Eriksson [tore.eriksson at po.rd.taisho.co.jp]

Received on Tuesday, 27 March 2012 23:37:19 UTC