Re: A parable about RFC 3986.

Sorry, please ignore my garbled message (below) that I just sent by
mistake.  It was sent by accident.

On Wed, 2012-01-25 at 20:50 -0500, David Booth wrote:
> On Wed, 2012-01-25 at 16:07 -0500, Jonathan A Rees wrote:
> > I think my epiphany is something that may be obvious to everyone else,
> > but there are THREE competing architectures here, not two. All this
> > time I've been trying to push three pins into two holes. They are:
> > 
> >   A. The Ian Davis architecture - a GET/200 URI can identify anything.
> >   B. The Roy Fielding architecture - a GET/200 URI identifies a "fiat"
> > (REST) resource.
> >   C. The TimBL architecture - a GET/200 URI identifies a "generic" resource.
> > 
> > (n.b. generic implies fiat.)
> > 
> > These architectures are distinguished by what can be a representation.
> >  In A, any rep. can be a representation of anything. In B, any rep.
> > can be a representation of anything, but only by fiat. In C, only
> > instances of a generic resource (representations that share some
> > properties with it) are representations.
> > 
> > My conjecture is that B is a theorem based on what the RFCs say
> > (ignoring the REST articles and webarch). Until now I thought the RFCs
> > has nothing to say at all.
> > 
> > My claim is that C is both useful for knowledge representation and
> > inference, A is useful for linked data, and B isn't useful for either,
> > or any other purpose of which I'm aware.
> > 
> > My claim about history is that when Tim agreed to httpRange-14(a), he
> > thought that everyone was talking about C, while when Roy was agreed
> > to httpRange-14(a), he thought the everyone was talking about B.  That
> > is, they had different definitions of "information resource" in mind
> > (fiat vs. generic, in my terminology).
> > 
> > If HR14(a) means B, then it is a theorem, but if it means C, then it
> > is a recommendation (or plea).
> > 
> > Maybe the linked data world can live with B, even if they can't accept
> > C (which some certainly can't). But since B is useless I don't really
> > care if they revert to A, if they won't do C.
> > 
> > With that in mind...
> > 
> > On Wed, Jan 25, 2012 at 2:17 PM, Pat Hayes <phayes@ihmc.us> wrote:
> > >
> > > On Jan 25, 2012, at 8:00 AM, Jonathan A Rees wrote:
> > >
> > >> 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.
> > >
> > > Um. OK, but that usage of "representation" can't be the one used in Roy's thesis and the HTTP specs.
> > 
> > But that's exactly what I meant - "representation" as in the RFCs.
> > Wonder what I did wrong?
> > 
> > >>  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.
> > >
> > > Whoa. That does not follow. One thing - in the case where 'they' are
> > the same - can satisfy two different descriptions without any
> > contradiction arising. This happens all the time, eg consider current
> > political debates in the USA. I think that the proper conclusion to
> > draw here is that Alice and Bob have different notions of what
> > constitutes a "state".
> > >
> > 
> > The contradiction is that A both is and isn't a representation of P.
> > Alice and Bob can't both be right if they say a statement and its
> > negation respectively. (Should I spell this out? Alice says deref(U)
> > has rep A but not has rep B, Bob says deref(V) has rep B but not rep
> > A, they are both authoritative, so deref(U) not= deref(V),
> > contradiction since P = deref(U) = deref(V).)
> 
> Thanks, that's a *little* more helpful, but there are still some crucial
> pieces left out.  
> 
> If I'm understanding you correctly, Alice asserts (through her server)
> that A is a representation of <U>, because dereferencing U yields A.
> I'm not sure how she is asserting that deref(U) does *not* have rep B,
> but maybe she wrote that assertion somewhere.  Similarly Bob has
> asserted (through his server) that B is a representation of <V>.  And
> somehow -- though you haven't said how, so I don't know if the "how" is
> relevant -- Alice and Bob have also asserted that <U> and <V> are
> owl:sameAs P (or some such).
> 
> So?  Alice and Bob have made contradictory assertions via their servers.
> What's the big deal?  Nobody has to believe them.  And where, in this,
> is there any relevance of the previously stated fact that P is a person?
> 
> To cut to the chase, it looks to me like the following is what is going
> on.  
> 
> 1. Alice has effectively declared that U identifies a resource such that
> <U> owl:sameAs <P> .  Alice has the authority to make this declaration,
> because she is the URI owner of U.  Furthermore, she has the authority
> to configure her server to serve representation A, in effect asserting
> something like <U> :hasRepresentation A.  
> 
> Similarly, Bob has effectively declared that <V> owl:sameAs <P>, and he
> has the authority to make that declaration, as the URI owner of V.
> But the fact that she has the authority to make these assertions does
> *not* magically make them true.  It just means that that is what <U>
> should normally be taken to "mean", in statements involving <U>.
> 
> 
> 
> None of that means that those assertions are necessarily true.  It just
> means that statements involving <U> or <V> 
> 
> Alice, 
> 
> 
> 
> There is a critical chain:
> 
>  - As the URI owner of U, Alice has the authority to say what resource
> it identifies.  She does this by (effectively) providing a set of
> assertions about <U>.  These assertions may or may not be written in
> RDF, but for simplicity (and to avoid any "magic happens here" steps) we
> can assume that they are, and they might look something like this:
> 
>   # Graph GA:
>   <U> owl:sameAs <P> .
>   <U> :color :RED .
> 
>  - This does *not* automatically make these assertions "true".  It
> merely means that any RDF statement involving <U> should be understood
> as including these assertions.  Colloquially, this means that <U> should
> be understood as identifying the resource that Alice said (via those
> assertions) that it identifies.  However . . . 
> 
> - It is not possible (in general) to uniquely determine the resource
> that a URI identifies.  The best we can say is do is to constrain the
> satisfying interpretations.  Thus, there is a crucial difference between
> the assumption that <U> uniquely identifies a particular resource, and
> the reality that the identity is inherently ambiguous.  This difference
> matters, because it explains why different authors can make
> contradictory statements about <U>, and -- in isolation -- they can both
> be "right".
> 
>  - These assertions are not necessarily satisfiable.
> 
> 
> 
>  - Alice (as URI owner) has the authority to issue increasingly 
> 
> 
> 
> 
> A resource 
> 
> You need to look at the roles
> 
> > 
> > Bob has no way to come out and *say* that A isn't a representation of
> > P, but by him never being disposed to say that it *is* we conclude
> > that he says it isn't. Anyhow this is what "authoritative" means, yes?
> 
> It sounds like you are talking about whether a particular
> *representation* is authoritative, i.e., whether the URI owner
> authorized it.  That is necessary, but it is not the most important
> notion of "authoritative" that is going on here.  
> 
> The more important notion is that Alice -- as URI owner -- is
> "authoritative" about the resource to which U is bound.  I.e., she is
> the one who is entitled to authoritatively say what resource U
> identifies.  But this doesn't magically make all of her statements true
> or consistent with anyone else's statements.  It just means that, when
> using <U> to mean something, we should (normally) take it as meaning
> what Alice said it means.  Indeed, Alice may define <U> in a way that is
> self contradictory, in which case it 
> 
> 
> 
> in the absence of "community expropriation"
> http://dbooth.org/2009/lifecycle/#expropriation
> an RDF author should use Alice's notion 
> 
> 
> > 
> > >> 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".
> > >
> > > I like that idea and even the name, although in my font it looks awfully like "FLAT resource"
> > >
> > >> 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.
> > >
> > > I think that is pretty much what TimBL had in mind when he coined the 'information resource' terminology: a resource which can be *completely* described by its representations. No?
> > 
> > Hmm, no, I meant just that the representations are inherent, not that
> > they alone determine the resource. There is no way to get "completely"
> > from TimBL and in fact he flatly denies it. We've had this discussion
> > already on this list...
> > 
> > >> 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.
> > >
> > > Why not, then, *define* it to be the set of its states representations? And come to think of it, isnt that exactly what Roy did, when he *defined* a resource to be a function from times to representations?
> > 
> > I think Roy was wrong. Even if this is what he wanted, you can't
> > conclude it from the RFCs, so making this the definition introduces an
> > ad hoc and, I think, unnecessary axiom.
> > 
> > >>  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.
> > >
> > > Slightly too strong. You might know things about a set without knowing all its members. I know that the set of irrational numbers is uncountably infinite, but I dont claim to be intimate with every irrational number.
> > 
> > ok but I think you know what I mean.
> > 
> > >> How this relates to the debate:
> > >>
> > >>  - Information resources (generic resources) are fiat resources, but
> > >>    there could be fiat resources that are not information resources.
> > >
> > > Example? And is it really worth making this distinction?
> > 
> > In TimBL's view a photograph of a person is not a representation of
> > the person, but in Roy's view it is. But Roy really means to talk
> > about "fiat people", not people... sorry to put so many words in his
> > mouth but there is no other way to make sense of what he's saying. The
> > only way to make a resource be both a mapping and a person is to make
> > it a pair of the two.
> > 
> > A fiat person has representations that are photographs, biographies,
> > etc. It has no representations that are instances
> > (TimBL-representations).
> > 
> > Anyhow the fiat/generic distinction is IMO the heart of the matter and
> > possibly the key to a resolution.
> > 
> > >>  - 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.
> > >
> > > Fiat ASPECT seems like a new idea. You need to elucidate this more. If I am non-fiat but have fiat aspects, does this mean there is another thing, a fiat-thing corresponding to me in some way? What way?
> > 
> > I'm not sure, I'm just trying to make sense of linked data. I think
> > that when they say "person" they really mean "fiat person" which is a
> > formal construct consisting of an ordered pair of a person and a
> > formal-REST mapping, where properties of the person leak through to
> > the pair (i.e. the fiat person has the same name, address, phone
> > number etc. as the person).
> > 
> > >>  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).
> > >
> > > True. But I dont see this as very different from the http-range-14
> > that we all know and love.
> > 
> > Ah, that's my point, the B architecture is the same as httpRange-14 as
> > stated, where you take "information resource" to be fiat resource,
> > which is what the RFCs and Roy meant. Which I think is sort of useless
> > and therefore idiotic - but also redundant, since it follows from the
> > RFCs. All this time I've been advocating for C, TimBL's architecture,
> > which is useful since it tells you what the properties (metadata) of
> > the resource are. But C seems to be a lost cause, and if you give up
> > on C you might as well retreat to A and at least make Ian happy.
> > 
> > Jonathan
> > 
> > > Pat
> > >
> > >>
> > >> Jonathan
> > >>
> > >>
> > >
> > > ------------------------------------------------------------
> > > IHMC                                     (850)434 8903 or (650)494 3973
> > > 40 South Alcaniz St.           (850)202 4416   office
> > > Pensacola                            (850)202 4440   fax
> > > FL 32502                              (850)291 0667   mobile
> > > phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> > >
> > >
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Thursday, 26 January 2012 01:54:00 UTC