Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question

Jeff Young

More options Aug 19 2008, 10:16 am

From: Jeff Young <jyoung.o...@gmail.com>

Date: Mon, 18 Aug 2008 17:16:24 -0700 (PDT)

Local: Tues, Aug 19 2008 10:16 am

Subject: Re: Aggregation/Resource Map relationship question

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On Aug 18, 2:57 pm, MichaelNelson <RhodeWarri...@gmail.com> wrote:

> That is where there is a discrepancy between RFC 2616 and AWW. In
> the http RFC, representations can have their own URIs. The AWWW
> seems to tip-toe around this. Consider:

> http://foo.edu/bar.abc

> That certainly appears to be a resource: it has a URI and when
> dereferenced it returns a representation (or, more likely, a
> "variant" in RFC-2616 terms).

As far as I can tell, the terms "representation" and "variant" are
interchangeable in HTTP.

variant
A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these
representations is termed a `varriant'. (http://tools.ietf.org/
html/rfc2616#section-1.3)

> Now I show you these URIs:

> http://foo.edu/bar
> http://foo.edu/bar.abc
> http://foo.edu/bar.xyz

> and tell that the last two URIs identify possible representations
> for the 1st URI. That means "http://foo.edu/bar.abc" is both a
> resource in its own right *and* a representation for another
> resource. Effectively, its both a 1st and 2nd class citizen. RFC
> 2616 doesn't directly address this apparent inconsistency of URIs
> identifying both a resource and representation.

As I've been suggesting, this situation isn't as confusing as it
appears. HTTP defines mechanisms for the *server* to make these
assertions (e.g. HTTP headers or a 300 Multiple Choice entity body).
The fact that others may disagree with these assertions is a different
matter where an application/rdf+xml representation could clearly play
a role. We can also admit that servers frequently fail to use these
mechanisms, but it seems better to educate people about this oversight
than to invent a tunneled solution that involves a host of extraneous
concepts.

> Its perfectly
> obvious and reasonable from an implementation point of view, but
> its really non-sensical from a modeling point of view.

It's only non-sensical if you ignore the features of HTTP that are
designed to model it.

> The AWWW + friends introduce the concepts of "information resource"
> (i.e., web things like html and pdf) and "non-information resource"
> (i.e., real world things like cars and sandwiches) and 303 redirects
> (which can be thought of as a generalized version of http content
> negotiation as defined in RFC-2295). IMO, this is the opposite of
> the above: it makes sense from a modeling point of view but is silly
> from an implementation point of view ("so the only thing this URI
> will *ever* do is redirect me to this other URI? ok...")

From the modeling POV, the AWWW "information resource" concept is
being tunneled through HTTP despite the fact that HTTP already has a
model to deal with this particular situation. This seems to account
for the silliness you mention.

Note that I'm not saying that AWWW's purported concept of an
information resource without a representation doesn't have merit.
"info" URIs appear to be an example of this. What I'm suggesting is
that this AWWW concept can apparently be factored out in this case. If
it's too late to do that, that's one thing. OTOH, if there is a real
need for it that I'm not seeing, I would like to understand it.

Jeff

> regards,

> Michael

> > The domain model for ORE is still unclear to me, but on this one point
> > it seems like some heavyweight sources are being cited to work around
> > a relatively simple confusion. Somehow this workaround has come full-
> > circle and produced a resource without a representation that resolves
> > to a response that is indistinguishable from a representation. This
> > circularity implies that there are some concepts in ORE that can be
> > factored out.

> > Jeff

Reply to author Forward