W3C home > Mailing lists > Public > public-awwsw@w3.org > March 2011

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

From: Nathan <nathan@webr3.org>
Date: Fri, 04 Mar 2011 23:49:49 +0000
Message-ID: <4D717A9D.7090801@webr3.org>
To: David Booth <david@dbooth.org>
CC: Jonathan Rees <jar@creativecommons.org>, AWWSW TF <public-awwsw@w3.org>
David Booth wrote:
> 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.  

universe of interpretation (!?)

i.e. yes all statements are open to interpretation
Received on Friday, 4 March 2011 23:52:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:22 UTC