Re: Difference between generic resource and REST resource

I think we need to get clear on the classes and relationships first,
before considering  questions such as mapping onto protocols.

It is clear to me that as ontological entities (classes), generic
resource, REST resource, and response source are simply distinct. As
classes they are disjoint; the individuals have very different
identity criteria. Each can be taken to be a model of the other, in
the sense that if an A is a model for a B, then you can work with an A
as a substitute or proxy for a B for some purposes, such as inference
or implementation. This is what makes the whole scenario so confusing.
Some people for some purposes want an A, while others for other
purposes want a B. This means that when we give names to these things,
the temptation to overload the names (URIs) in RDF is powerful, and it
always seems like we're on the edge of inconsistency.

The HTTP protocol pretty clearly uses URIs to name response sources
(maybe with exceptions in 4xx/5xx land): what actually happens. But
when we talk about Dublin Core, the generic resource model seems more
natural: what is *specified* to happen, what is supposed to happen if
the server does the right thing and ICANN is uncorrupt, is what we
care about and want to talk about. These two subjects have completely
different nature and implications.

On Fri, Mar 13, 2009 at 10:38 AM, Booth, David (HP Software - Boston)
<dbooth@hp.com> wrote:
> It sounds like the key difference that you are describing is whether a particular representation must be available: with a "generic resource"[3] the URI http://example/bible can denote the Bible (comprising all possible translations) even if no representation is currently available for Mandarin.  But is this difference observable?

Availability of anything in the real world is a completely orthogonal
question to what the generic resource is. The world could be gobbled
by a supernova and the generic resource would remain. When building a
logical model there is no need for observable differences - you can
model complex numbers, for example, without being able to obtain one
as a measurement of anything. Whether such a model is good for
anything is another story, but the purpose of this scenario is not to
overinterpret, but rather to play out the full consequences of each
separate story.

The modeling issue of thing-with-all-possible-representations vs.
thing-with-no-representations is not interesting since these two
classes would be in 1-1 correspondence. That's why I introduced the
example of REST resources that were both implementations of the same
generic resource, but distinct because they chose to incorporate
distinct subsets of the space-of-possible-representations. (And the
notion of "all possible representations" is not a very useful one, I
think.) The fact you can make distinctions in one class that can't be
made in another tells you that these are very different beasts.

> Suppose we do a GET on http://example/bible at time t, specifying Mandarin as the Accept-Language, but that language is not currently available.  What should be the response?  A 406[6] seems like the natural choice:
> [[
> 10.4.7 406 Not Acceptable
>
>   The resource identified by the request is only capable of generating
>   response entities which have content characteristics not acceptable
>   according to the accept headers sent in the request.
> ]]
>
> However, if http://example/bible denotes a generic resource, then a 406 response would be wrong (misleading), because in theory the generic resource *is* capable of generating

Generic resources are passive - it would be wrong to think that Moby
Dick can generate a Swahili representation of itself. "Generation" has
to be left up to physical things such as people and servers.

> a Mandarin response, even though the server

There is no server in sight here. You are making assumptions I am
being very careful not to. You have to assume an entity is named by a
tag: or info: URI, if at all, unless stated otherwise.

> cannot produce one at the moment.  So to be strictly correct under this interpretation, perhaps the server should hang, never returning a response when Mandarin is requested.  Clearly that would be rather anti-social.  Fortunately, in practice a 406 *would* be returned in this situation.

Alternatively, you could just avoid using the HTTP protocol to try to
learn anything about
this thing - as if we could anyhow, since we haven't set up any
correspondence between
HTTP and RDF yet - we're just doing the groundwork for that now.
>
> This suggests that either:
>
> (a) the notion of "resource" used in RFC2616 is *not* the same as the TimBL notion of generic resource[3], but the behavior that we can observe and use corresponds to the notion of a REST[3] resource or ftrr:IR[4], and thus the notion of generic resource is not really needed; or

That response source ("network resource") and generic resource are
different seems like a no-brainer to me.

> (b) the notion of "resource" used in RFC2616 *is* the same as the TimBL notion of generic resource[3], but the particular generic resource that http://example/bible denotes happens to exclude the Mandarin representation at time t, and thus there is no observable difference between this and a REST[4] resource or ftrr:IR[5].

I don't see how you can read that into his memo. Seems to me the
intent is clearly to say that the resource is something like Moby
Dick. Moby Dick doesn't have an appendix that lays out what all its
representations will be over all time. It just is what it is. If it
has REST-representations they come about through some external
process, such as a person doing a translation that is then served by a
server.

I.e. the representation need not be inherent in the resource, not part
of its identity; it could be an aspect of the way it's served.

> In summary, if the notion of generic resource is going to be viewed as different from the notions of REST resource[3] or ftrr:IR, then we would need something like a "partiallyImplements" relation between them.

Yes.  Usually called a "projection" or "forgetful functor". But I
don't see the "partially" part; a REST resource implements a generic
resource, whenever its REST representations are all
generic-resource-representations of the generic resource.

> However, note that if you're talking about what inferences you can make based on a 200 or 406 response,

I'm not. If we get an ontology that makes sense, then we might be able
to think about translating (modeling) HTTP in RDF or OWL. We're not
there yet.

> you are only directly making observations about the REST resource or ftrr:IR, because the implementation of the corresponding generic resource may only be partial.  For this reason, if we're going to be writing an ontology and rules, the REST or ftrr:IR notions seem more relevant than the notion of generic resource.

You can't observe much of anything without some physical means of
access.  If a response source correctly implements a REST resource,
then you can observe representations of the REST resource by obtaining
200 responses from the response source.

This is just like a calculator that can be used to observe sums such
as 2+3 assuming it correctly implements addition on the numbers to be
added. 2+3 is not physical and therefore can't be observed directly;
you look at the calculator, not at 5.
>
>
> [1] http://www.w3.org/2001/tag/awwsw/jar-diagram-3.pdf
> [2] http://esw.w3.org/topic/AwwswHome?action=AttachFile&do=get&target=URI-representation-resource-unified.pdf
> [3] http://www.w3.org/DesignIssues/Generic.html
> [4] http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf
> [5] http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0046.html
> [6] http://www.ietf.org/rfc/rfc2616.txt
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.
>
>
>> -----Original Message-----
>> From: public-awwsw-request@w3.org
>> [mailto:public-awwsw-request@w3.org] On Behalf Of Jonathan Rees
>> Sent: Tuesday, March 10, 2009 12:07 PM
>> To: AWWSW TF
>> Subject: Difference between generic resource and REST resource
>>
>> Attempting to write down what I had thought was obvious
>> during today's
>> call, but wasn't....
>>
>> Forget about time, for now, for the purposes of this story.
>>
>> Tim gives the Bible as an example of a generic resource. My claim is
>> that while there is only one Bible, there can be many REST resources
>> that "implement" it, because each selection of
>> representations of the
>> generic resource leads to a different REST resource.
>>
>> A REST resource is in general a "time varying membership function".
>> Since I said forget about time, we can simplify that to "membership
>> function" which really just means "set" (of representations).
>>
>> Each generic resource might induce a REST resource consisting of the
>> set (possibly infinite) of all possible representations, whether
>> "realized" or not, of the generic resource. So for the Bible, the
>> corresponding REST resource would contain translations into all
>> languages, including extinct languages and languages not yet
>> invented.
>> I'm not sure this is what Roy had in mind; my guess is that
>> for him a
>> REST resource is something you could actually serve. So there
>> would be
>> no REST resource corresponding to the Bible generically, since we
>> can't collect all translations into one place, but only particular
>> REST resources, each possessing some finite (and probably small) set
>> of representations.
>>
>> The point is that a generic resource doesn't know what its
>> representations are, except to the extent it knows with complete
>> generality. If R1 is a REST resource possessing
>> representations A and
>> B, and R2 is a REST resource possessing representations B and
>> C, then
>> there may be a generic resource G possessing representations
>> A, B, and
>> C (and others), but G, R1, and R2 are definitely three distinct
>> entities - none can be identified with another.
>>
>> Alternatively: a REST resource is always "specific" (to some
>> definite
>> set of representations, a subset of all those that are "possible" or
>> "correct") in a way that generic resources are not.
>>
>> As the definitions are all sort of squishy it might be possible to
>> force them to line up; e.g. one could define a generic resource by
>> fiat as one that has a particular small specified set of
>> representations and no others, but I don't think that is the intent
>> behind the generic resources memo.
>>
>> Introducing time now: You could have a REST resource
>> providing, today,
>> two representations of the Bible, and then later add a third
>> representation. This is a simple time-varying REST resource. But the
>> generic resource, the Bible, is not time-varying. If you
>> access it via
>> some URI, you are simply experiencing enriched provision - it's the
>> server for that URI (or something) that has changed, not the
>> resource
>> itself.
>>
>> I'm not saying I like any of this; I'm just chasing the consequences
>> of the two theories.
>>
>> Jonathan

Received on Friday, 13 March 2009 16:03:54 UTC