Re: A parable about RFC 3986.

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:50:28 UTC