Re: 200 response as conclusive evidence of an information resource

On Tue, Dec 2, 2008 at 5:40 PM, Booth, David (HP Software - Boston)
<dbooth@hp.com> wrote:
>> From: Jonathan Rees [mailto:jar@creativecommons.org]
>
> If you preferentially view the URI owner's other declarations about the resource as being intrinsically more reliable than the server's response code, then I can see how you would interpret the httpRange-14 finding this way.

I do.

> But I don't see a justification for treating the response code as less reliable than the owner's other statements, and as I pointed out in
> http://lists.w3.org/Archives/Public/public-awwsw/2008Dec/0000.html

I explained this in my message. Just because you want to interpret 200
this way doesn't mean either the sender of the request of the receiver
of the response wants to be, or can be, held to such an
interpretation.

> I think there are good, practical reasons for treating the 2xx response as irrefutable evidence of an AWWW information resource.

I am not convinced. We should take this up separately.

> I would characterize this part of the httpRange-14 finding as:
> "Please don't deliver a 2xx response, because a 2xx response means that the resource *is* an AWWW information resource.  Hence, delivering a 2xx response while also claiming that the resource is something other than an AWWW information resource would cause a URI collision
> http://www.w3.org/TR/webarch/#URI-collision
> which should be avoided."

I don't see how you can extract this from the resolution. As I said it
requires a long inference chain and some semantic slight of hand.This
is what you want it to say, but not what it says or implies.

>> and nothing could
>> justify imputing semantics to their 200 response.
>
> Sure.  We would be justified in imputing the semantics of the httpRange-14 rule: that their 200 response implies an AWWW IR, even though they claim the URI denotes a concept.

a property, actually. concepts are a different kind of thing.

Again, we disagree about whether someone not aware of the httpRange-14
rule would agree with you. You're holding them to a contract they
didn't sign.

> Both are correct: their current server configuration causes a URI collision, so they should fix their server to comply with the AWWW's advice not to cause URI collisions.  I.e., what such a Dublin Core URI denotes is ambiguous: it denotes both an AWWW information resource *and* it denotes the concept that the Dublin Core spec says it denotes.

Right, this is just the ambiguity mentioned in the rule (one binding
in one interpretation, another binding in another).

> BTW, I discussed this in "Splitting Identities in Semantic Web Archtitecture":
> http://dbooth.org/2007/splitting/#collision
> [[
> Multiple URI declarations and URI collision
> The Architecture of the World Wide Web defines URI collision as "Using the same URI to directly identify different resources".  URI collision may occur if a URI has more than one URI declaration.  However, different declarations of a URI do not necessarily cause URI collision, because the constraints they express could be equivalent even though they are written differently.
>
> How should multiple URI declarations for a URI be interpreted?  If one has a way to preferentially select one over another -- perhaps one is more recent (thus implicitly obsoleting others), or perhaps the evidence of the act of declaration is more compelling for one than another, or perhaps one can determine which URI declaration was intended when a statement author made a statement using the URI (see slide 2 at http://dbooth.org/2008/irsw/slides.ppt ) -- then it probably makes the most sense to use that URI declaration to interpret the meaning of the URI in an RDF statement.  Otherwise, one could think of the complete URI declaration for the URI as consisting of the disjunction of the individual URI declarations.
> ]]

I don't think you need to invent a new theory to account for URI
binding conflicts. The RDF semantics and Pat's other writings give a
satisfactory treatment. Each model does, indeed, assign only a single
resource to each defined URI. Different models are OK and inevitable
since there is nothing you can say that unambiguously nails down a
referent. If you have two definitions that are inconsistent with one
another (a collision), however, then you're in trouble because no
model satisfies both. So if you have a theory with one definition (set
of axioms for the URI), and I have a theory with an inconsistent one,
we are going to fight about what's true and what's not - and unless we
look carefully we may never even know why we are disagreeing.

A lot of the nonsense we're dealing with has to do with the mistaken
notion that reference is objective. If you account for the
interpretation step, as do RDF and OWL semantics, things get much
better.

>> This is not a criticism of the rule - I think the rule is a good
>> thing, for the reason stated (lowering the risk of misinterpretation),
>> and would like people to follow it. But when I connect to a server and
>> look at status codes, I can't count on the server (or those that
>> control it) being aware of the rule. If you know ahead of time that a
>> server has chosen to follow the rule, or does so by accident, then I
>> agree that its 200s imply something about the nature of the resource.
>> But lacking that I don't. Just because you can't count on everyone
>> following it doesn't mean it's a bad rule.
>
> You seem to be assuming that a URI can only denote one resource.

See above. This is true in any interpretation. If you mean it can
denote different resources in different interpretations, that's fine,
and is only a problem if there is a way to detect the difference and
you want to combine the theories.

> Clearly that is the *intent*: as the AWWW says,
> http://www.w3.org/TR/webarch/#URI-collision
> "By design, a URI identifies one resource".  But the whole idea of URI collision is that this is *not* always the case: sometimes a URI denotes *more* than one resource, i.e., sometimes the mapping from URI to resource is ambiguous, either because a single URI declaration was ambiguous or because there was more than one URI declaration for it.

Hidden in all of this "x identifies y" rhetoric is the idea that we
should strive for a common model by attempting to get as much
consistency as we can (without sacrificing the ability to say what
needs to be said). I think
this is a good ideal, even if it is unscalable and unachievable. I
don't object generally to "x identifies y" (except
that it should be "x names y") because I take it to be code for
striving for consistency. The illusion of objectivity is a nice
shorthand, but whenever you find an issue around what is bound to
what, you've got to deconstruct and go back to something like RDF or
OWL semantics.

>> A second problem is the dissonance between RFC 2616 and AWWW. You have
>> to do serious semantic gymnastics to make these align. I would forgive
>> anyone for saying (perhaps in RDF) that their network service, for
>> which a 200 is legitimately delivered according to RFC 2616, is NOT an
>> information resource in the AWWW sense.
>
> Well, if you are using the current (flawed) definition in AWWW,

I'm sorry? How can I be heard as saying anything else? The AWWW I'm
talking about is a static document.

> then I would also, because the current definition does not adequately cover the full variety of what can legitimately yield a 200.  That's why I've been advocating a definition of "information resource" as, essentially, a function from (Time x Requests) to Representations.

Our hypothetical RFC 2616 fossil have the same problem with these functions as
they would with AWWW IRs. They just don't seem to qualify as
"network data objects or services". A service is not a function.

> No, the problem is that that definition of "information resource" is wrong.  Try using the definition of ftrr:IR that I proposed and it should make more sense:
> http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0046.html

See above... I think that the only rescue is to make
a superclass containing both "network data object or service"
and AWWW IR, and make that be the domain of the
has-representation relation.

>> Or maybe it's obvious that RFC 2616 should be
>> ignored, or altered, where it is dissonant with AWWW (new covenant??)
>> - maybe replace its definition of "resource" with a more modern one
>> such as RDF's.
>
> No, one just needs to realize that, for historical reasons, when RFC 2616 says "resource", it means what AWWW calls "information resource" (except that the current AWWW definition needs correction).

This is absurd!  What evidence do you have for this?  Or are you
saying that RFC 2616 means what *you* call an information resource?
This is also unjustified - just something you would like to be true.

The proof would be in the ontology, if we were ever to write one.

>
>> Or maybe AWWW can be put aside or altered: redefine
>> "information resource" to mean not what the glossary says but what RFC
>> 2616 means by "resource" (or some superclass of it).
>
> Yes!  The AWWW definition of IR needs to be corrected.  And while we're at it, it would be good to point out that it corresponds to what RFC2616 calls simply "resource".

This would work except that I don't think Tim or the other authors of
AWWW would go for it (being Talmudic myself now)... and since I
think I understand how one comes to this view, I am not sure
I would agree either. This a definite point of non-consensus.

(should we take a survey on some of these questions?)

> I agree that in modeling HTTP interactions, there is not much need to talk about IRs.  However, this discussion about whether a URI that yields a 200 response can denote a non-IR does bring out some important issues of how semantic web architecture should work, and in particular, how a URI denotes a resource.

URI ownership seems a good enough story to me - it says that what the
URI owner says, goes.  Not that you should necessarily believe their
RDF, but you should listen and respect if you can. So this is my
answer: you talk to the URI owner somehow to get RDF (or prose, as a
substitute) that constrains permissible models, consider the
consequences of believing it, consider whether they're being
consistent with governing documents (such as RFCs and W3C recs), and
believe it, if you are willing to risk it. If you want to invent a
protocol for making such communication systematic - effectively what
you have done with URI declarations and what I'm doing with the Link
header - that's not a bad idea, but we don't yet have any such
protocol described anyplace other than private accounts (where there
are many) - no recommendation, no RFC, no finding. So I think this is
a subroutine that is outside of our current task.

Jonathan

Received on Wednesday, 3 December 2008 02:02:46 UTC