Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question
MIME-Version: 1.0
Date: Mon, 18 Aug 2008 11:57:00 -0700 (PDT)
In-Reply-To: <763f270a-2210-4f7a-8576-a4774250a132@k7g2000hsd.googlegroups.com>
References: <15c4095c-12ba-4ef4-9865-db0d234d184c@79g2000hsk.googlegroups.com> 
	<20080814194905.GA1749@ice.cs.cornell.edu> <028312c8-afeb-4826-ac62-9d1a4ddd198e@f63g2000hsf.googlegroups.com> 
	<84d06a7b-b4b9-4b2e-870c-06ad72015ef3@79g2000hsk.googlegroups.com> 
	<20080818130229.GA13804@ice.cs.cornell.edu> <763f270a-2210-4f7a-8576-a4774250a132@k7g2000hsd.googlegroups.com>
User-Agent: G2/1.0
Message-ID: <28cdedfa-9b77-4e07-be18-4ad4d403bf41@k7g2000hsd.googlegroups.com>
Subject: Re: Aggregation/Resource Map relationship question
From: MichaelNelson <RhodeWarri...@gmail.com>
To: OAI-ORE <oai-ore@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


> The belief that "representations don't have their own id" seems to be
> the root of the problem here. In HTTP, representations CAN have their
> own identifiers (URIs) and thus can be addressed individually. As
> evidence, the Content-Location header exists to notify a client of
> this fact (http://tools.ietf.org/html/rfc2616#section-14.14). The
> possibility of representation identifiers is even clearer in the case
> of 300 Multiple Choices (http://tools.ietf.org/html/
> rfc2616#section-10.3.1).

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).

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.  Its perfectly
obvious and reasonable from an implementation point of view, but
its really non-sensical from a modeling point of view.

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...")

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.
>