Re: Roy's definition of a REST resource as a "Curried" form of ftrr:IR

On Fri, 2011-03-04 at 16:19 -0500, Jonathan Rees wrote:
> On Fri, Mar 4, 2011 at 4:09 PM, David Booth <david@dbooth.org> wrote:
> > On Fri, 2011-03-04 at 13:40 -0500, Jonathan Rees wrote:
> >> On Fri, Mar 4, 2011 at 1:18 PM, David Booth <david@dbooth.org> wrote:
> >> > Nathan,
> >> >
> >> > Have you looked at the definition of IR that I proposed a while back?
> >> > http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0046.html
> >> > It is logically equivalent to Roy's definition of a REST resource, ...
> >>
> >> I would not call either of these definitions. They are models, or
> >> theories, or formalisms - they predict certain properties of IRs. But
> >> they are not a good match to any plausible ontology of IRs since they
> >> entail ridiculous conclusions such as "Moby Dick is a function" and
> >> "the domain of the Declaration of Independence is time".
> >
> > I do not consider those to be ridiculous entailments at all.  Those
> > entailments may be perfectly fine in an application that has no need to
> > distinguish between Moby Dick and a function.
> >
> >>
> >> I'm not saying it's a useless idea, or not predictive, or that we
> >> shouldn't talk about it. I'm just asking everyone to stop calling
> >> these things definitions and start calling them what they are. As
> >> Nathan has pointed out, Roy's paper has three mutually inconsistent
> >> "definitions" of "resource". The paper makes much more sense if you
> >> just treat the function "definition" as a mistake: He should have said
> >> something like "We can model resources as functions ..." and you
> >> (David) should do something similar.
> >
> > It sounds like you're using the word "definition" in a highly
> > specialized way.  I was using it in the generic English sense.  I think
> > you may need to cut me (and others) some slack here if we're not using
> > the term in the specialized sense that you want.  Or at least tell us
> > exactly how you want the term used.
> 
> I'm not being the least bit technical. Take the following two
> statements to the common man in the street, T. C. Mits:
> 
>   An information resource is a kind of function.
>   The novel _Moby Dick_ is an information resource.
> 
> If they know what a function is, they will think you're talking
> nonsense. I'd be happy to perform the experiment if you like. I'm at
> MIT and many people here know what a function is and have at least
> some idea of what _Moby Dick_ is.

Sure, most humans will think I am talking nonsense, because most humans
*care* about the difference between a novel and a function.

But my point is that many applications do *not* care.  If an RDF graph
with the Moby Dick URI is being used by an application that merely needs
to differentiate between novels and autobiographies (for example),
putting novels in one bin and autobiographies in another, then the fact
that (by entailment) Moby Dick is also a function (w.r.t. that graph) is
completely harmless and irrelevant.  This is a key point that I've been
trying to make for the past few years.  

RDF semantics is *not* universal, with one giant, global graph.  The
semantics only applies to a *given* graph.  And different applications
use different graphs.  That's my whole point in dispelling Myth #2:
http://dbooth.org/2010/ambiguity/paper.html#myth2

What's distinct (enough) for one application may be ambiguous to another
application, and that's okay, because each application *chooses* what
RDF graph to use.  The identity of each resource only needs to be
unambiguous enough within *that* graph for the purposes of *that*
application.  



-- 
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 Friday, 4 March 2011 22:37:17 UTC