A parable about RFC 3986.

Speaking loosely below, do not imagine I take this completely seriously...

Suppose there is a person P, and two fixed documents
("representations") A and B.  Alice says that A is a representation of
the state of P and B isn't, while Bob says the opposite.  Alice mints
a URI U "identifying" P and serves A as a retrieval result (200
response to a GET request), while Bob mints a URI V also "identifying"
P but serves B as a retrieval result.  (The HTTP spec says that an
HTTP retrieval result gives a representation of the state of the
identified resource.)  Now A is a representation of the state of the
referent of U, while B isn't; and vice versa for B.  Since the two
referents have different properties / classes / theories, they can't
be the same.  But this is a contradiction, since then A would be both
a representation of the state of P, and not a representation of the
state of P (and similarly for B).

What assumption might we want to discard in order to remove the
contradiction?  I would suggest that the state of a person does not
have representations.  Let's define a class of resources called "fiat
resources".  What distinguishes a fiat resource is that the
representations of its states are *constitutive* of the resource -
they are not subject to debate, reason, opinion, and so on, but are
rather part of the resource's identity.  So a person is not a fiat
resource, since Alice and Bob can argue about whether A and B are
representations of its states; while the referents of U and V are fiat
resources, since Alice and Bob get to decide what their states'
representations are.  [Unless the explicitly adbicate this privilege.]

A fiat resource bears the same relationship to its states'
representations as a set bears to its members.  If you don't know what
the members of a set are, you don't know what the set is.  If you
don't know a fiat resource's representations, you don't know what fiat
resource you're talking about.

How this relates to the debate:

  - Information resources (generic resources) are fiat resources, but
    there could be fiat resources that are not information resources.

  - Fielding's REST resources come in two flavors, formal and
    informal.  His formal definition (mapping from time to sets of
    representations) is only the fiat aspect of the resource, not other
    aspects of the resource.  Those other aspects are captured in the
    informal discussion.  So a fiat resource could be considered to be
    a pair of a Fielding-formal-REST-resource and a
    Fielding-informal-REST-resource.

This suggests a position intermediate between a free-for-all where a
retrieval-enabled hashless HTTP URI (REHHU) can refer to anything at
all, and where it has to refer to an information resource: say that
a REHHU has to refer to a fiat resource. We have proven the latter,
while the more restrictive (and useful) information resource rule is
wishful thinking.

I suspect that my "fiat resource" is much more similar to David's
"information resource" than my "information resource" is, if for no
other reason that David's "information resource" is so much like Roy's
formal REST resource.

This idea doesn't help the cause of metadata (Tim's and my cause), but it
at least explains the relationship between resources and HTTP in a way
that is consistent with the specs and with Fielding's world view - and it says
that the REHHU situation is not a free for all, it is constrained, so you can't
name a person with a 200-yielding URI (since people aren't fiat resources).

Jonathan

Received on Wednesday, 25 January 2012 16:14:10 UTC