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

2012/3/27 トーレ　エリクソン <tore.eriksson@po.rd.taisho.co.jp>:
>>>> 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.

*generically*. To just say what is retrieved or what you get is just
shorthand for the generic-resource story, which is tedious to repeat
over and over.

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

I have been campaining against this horrid definition since 2007. Any
application of it is a  matter of judgment, so it cannot be used
between people who don't trust one another to be reasonable.

> Since the message in
> question is supposed to be the retrieved representation,

That's a jump!  Not sure how you get that.

> this implies
> that the information resource and its representation share all essential
> characteristics.

No, the representations can have characteristics that the resource doesn't.

And the exact manner of "conveying" isn't spelled out. As I said
before it is more accurate that the representations "possess" the
resource's "essential characteristics" if you can convince yourself
that "e. c."s are like what I call metadata predicates, things like
dc:title and so on.

But really I think it's folly to microanalyze such a poorly articulated theory.

> Although not strict equivalence, I always thought that
> this sounded like they are constrained to be very similar.

The more generic the resource, the fewer similarities there will be.
It depends on the full range of representations. There will be very
little you can say about resources with highly variable
representations, even though there will be a lot to say about
individual representations.

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

The spec isn't as clear as all that. Also nobody says that
identification and representation are completely decoupled. But if you
are saying the foundations just don't make any sense, I agree.

I have raised this foolishness with the HTTP WG and am waiting back to
hear from them.

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

I'm not sure where you get that the URI refers to the representation.
I don't think people use them that way in RDF, and it's not implied by
anything I've said.

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

I didn't take personal offense, that doesn't matter, I just don't like
it when people draw unjustified conclusions, especially when it seems
to make someone else appear illogical.

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

Your proposal says, quote: "a representation retrieved
from a HTTP URI will [...] always be a description (of the state) of the
resource" - that's what I was triggered by. I can't conceive how a
representation retrieved from, say, http://www.yahoo.com/ could be
construed as a description of the identified resource. It's not a
description of anything. The representation is the content of the
resource, but not a description. I *can* imagine that what you're
saying is such URIs shouldn't be used in RDF, which is a coherent
position, but one that deprecates lots of URIs, as I said before.

I suspect you didn't mean what you said. You might have intended to
classify URIs as content-oriented vs. description-oriented (or
representations as content vs. description), which would be a better
match to current and desired practice, I think. Then representations
wouldn't *always* be descriptions. The question then would be where to
draw the line.

Jonathan

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

Received on Wednesday, 28 March 2012 00:48:31 UTC