Home > Uncategorized > When “identification” and “representation” fight, who wins?

When “identification” and “representation” fight, who wins?

Let’s now enter the fantasy world where “resource”, “identification”, and “representation of” have meanings consonant with what is found in the Web architecture documents RFC 3986, the HTTPbis draft (I’m looking at version 18), and AWWW. To make any sense of these documents the words have to be assumed to have something close to their ordinary language meanings (which are rather squishy), since they are otherwise effectively undefined.

Now observe:

1. Web architecture suggests that a URI owner is an authority for what is identified by its URIs (AWWW 2.2.2.1 bullet #2).

2. The HTTP protocol suggests the URI owner is an authority for what is a representation of what is identified (HTTPbis v.18 part 2 section 5.1 bullet 1 taken together with part 1 section 2.7.1).

If both kinds of authority hold, then Jabberwocky is a representation of the Magna Carta, since a URI owner can say both that the URI identifies the Magna Carta and that Jabberwocky is a representation of what is identified. But this is not true. How to resolve this paradox?

There are (at least) three solutions, based on modifying either of the two authority axioms.

1. We can say the URI owner is an authority for what is identified, but not for what is a representation of it. [2/11 I.e. solution = what the URI owner said was a representation is not a representation of what is identified.] In this case a 200 response only says that the payload is a rep, its arrival does not imply that it is a rep.

Accepting this would require modifying the HTTP protocol to say that the payload is only said to be a representation of the resource, not that it is. It is only nominally so.

2. We can say that the URI owner is an authority for representation, but that it is only an authority for identification to the extent that the identified resource is represented by any HTTP 200 responses that have been issued recently. [2/11 I.e. solution = the URI does not identify what the URI owner determined it to. It's not clear what identity authority would consist of independent of asserting representations, anyhow.]

Accepting solution 2 requires modifying the http: URI scheme to impose this limit on identification when representations are asserted, as this limit is otherwise not entailed by the URI scheme.

This could easily lead to the URI identifying nothing at all, which would be a problem.

2a. We can say that “representation” is redefined as a term of art, not used in an ordinary language sense. The URI owner has authority over representation, but the authority over identification is limited to having a URI identify mysterious sorts of things whose very nature allows some URI owner to have authority over their representations.

Accepting solution 2a also requires modifying the http: URI scheme, to restrict identification to these mysterious things when there are nominal representations. You might call these mysterious things, say, “information resources” (although this would run afoul of AWWW a bit).

Although I haven’t heard from him yet, my suspicion is that Roy Fielding would either insist on option 1, or insist that the problem doesn’t exist, while Tim Berners-Lee would either prefer option 2a or insist that the problem doesn’t exist. I want to get them into a room together to fight this one out, but I need to be there to make sure they don’t decide together that there is no paradox.

Further reading: speech acts

About these ads
Categories: Uncategorized Tags:
  1. 2012-02-11 at 14:23

    To: Amos Jeffries
    Re: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0464.html

    You misunderstood what I wrote, but that’s OK, your setup just helps me make the point. Suppose there is a URI, and two retrieved representations, one of which carries Jabberwocky and the other carries the Magna Carta. You say that those are *definitely* representations of the identified resource – you know so because the URI owner told you so via HTTP.

    Now suppose you meet the URI owner herself in the street, and she tells you that the URI identifies the Magna Carta. You say: “That’s ridiculous, it doesn’t represent the Magna Carta, because look here, one of the representations carries Jabberwocky; you are no authority on what the URI identifies, regardless of what some old W3C spec says!” That puts you squarely in the solution 2 or 2a camp.

    If she is in camp 1, she says it’s her URI and it will identify what she wants it to. Maybe she just made a mistake in delivering Jabberwocky, or maybe she just decided that Jabberwocky *was* a perfectly fine representation of the Magna Carta, and she thinks that’s her prerogative.

  2. 2012-05-28 at 05:02

    My .02 (only) – there seems to be an underlying requirement here that truth only be spoken. That’s out of scope for HTTP, URIs and AWWW.

    In other words, forget HTTP. Let’s do a telephone-based protocol, where I call you and tell you that I’m George Bush. I can perform that experiment right now, if you’d like; it’s possible. The phone will not blow up in my hand, and the call will not even disconnect (usually). It’s possible to lie over that protocol, just as it is over HTTP.

    Likewise, the fact that I can lie over a telephone doesn’t change how we talk about connections, handsets, telephone numbers or sound waves; they’re just the infrastructure that the conversation occurs over.

    So, it’s true that the owner of a resource is authoritative about it, as well as its representations; it’s just that its authority and reality (whatever that is) might not be well-aligned.

    • 2012-05-30 at 20:35

      I want the RFC itself to be entirely true, or else acceptable as truth. I am willing to let it make fiat statements about whether or not a given octet sequence is a syntactically well formed HTTP message – once the RFC has done that, and I agree to the RFC (as I will be asked to), then propositions of well-formedness will be true or not, according to what the RFC says. There is no way a server can lie about things like that.

      And right now the draft says “If the response status code is 200 or 203 and the request method
      was GET, the response payload is a representation of the target
      resource” and I’m asking myself, if I agree to this, what exactly what will I be agreeing with? Suppose this language comes into force and we all agree with it. I get a 200 response to a GET request addressed to some compliant (but otherwise possibly dishonest) server, and then you (Mark) ask me, is the payload that you (JAR) just got a representation of the target resource? I can respond to you in one of two ways: (1) Well, I don’t know, Mark – the server told me that it was, because we’ve all agreed that this is what GET/200 means, but I don’t know whether I can trust the server to tell me the truth, so I can’t honestly tell you. Or, (2) Well, Mark, I’m quite sure of it, because I read the spec and the spec told me, quite literally, that if the response status code is 200 or 203 and the request method
      was GET, then the response payload is a representation of the target
      resource. The response status code was 200, so I know for sure that the payload *is* a representation, regardless of how dishonest the server might be, since the spec tells me so.

      All I’m saying is that I’m not clear on whether (1) or (2) is meant. Because you invoke the question of trustworthiness of the server, you seem to be saying (1), but a literal reading is (2). From where I stand all of this resource/representation/identification story sounds pretty much like gibberish – there is some kind of speech-act-like business going on here, but there is no documentation of any theory of authority or truth regarding these relationships (except in AWWW, which I don’t trust), and my understanding of ordinary language doesn’t seem to be of any help in interpreting this aspect of the specs. But I’m willing to take the specs at face value, as long as they’re internally coherent. All I’m asking is for HTTPbis to make logical sense to me. That doesn’t even require a change to the draft; all I really want to know right now is what the editors’ intent is.

      The phone analogy in this situation would work as follows: Suppose that it is part of a communication standard that a short beep every 15 seconds means that a recording session is in progress. If “recording session” is a term of art in the standard, and I hear the beeps, then it could be true *by definition* that this part of the session is a recording session, regardless of whether the device on the other end is actually recording (is “telling the truth” in beeping). On the other hand, if we take “recording session” in its ordinary language sense, the standard could be true in a different way: it is just telling me what the beeps [are supposed to] *mean* [to the users of the devices], regardless of whether what it means is true or not (i.e. whether the other end is actually recording).

      • mnot
        2012-05-31 at 00:16

        A 200 indicates a representation of a resource; the spec is crystal-clear about that. You’ve seemed to want to derive some idea of what’s “true” from that in the past, which is why I responded as I did.

        Whether the content of that representation matches your reality is a problem for you to work out; HTTP doesn’t help there.

        Cheers,

      • 2012-05-31 at 14:24

        I don’t understand why you didn’t answer my question directly. I’m trying to be very clear, and it seems like a simple question. Let me repeat:

        “I get a 200 response to a GET request addressed to some compliant (but otherwise possibly dishonest) server, and then you (Mark) ask me, is the payload that you (JAR) just got a representation of the target resource? I can respond to you in one of two ways: (1) Well, I don’t know, Mark – the server told me that it was, because we’ve all agreed that this is what GET/200 means, but I don’t know whether I can trust the server to tell me the truth, so I can’t honestly tell you. Or, (2) Well, Mark, I’m quite sure of it, because I read the spec and the spec told me, quite literally, that if the response status code is 200 or 203 and the request method
        was GET, then the response payload is a representation of the target
        resource. The response status code was 200, so I know for sure that the payload *is* a representation, regardless of how dishonest the server might be, since the spec tells me so.”

        Your answer is (1), right? That’s why you say “indicates” rather than “implies”. (My word was “means” but “indicates” is the same.) Or are you saying my question is ill-formed or nonsensical? If so can you tell me how?

      • mnot
        2012-05-31 at 23:50

        (2)

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: