Message from discussion Aggregation/Resource Map relationship question

MIME-Version: 1.0
Received: by 10.90.69.15 with SMTP id r15mr245285aga.28.1219073184249; Mon, 18 
	Aug 2008 08:26:24 -0700 (PDT)
Date: Mon, 18 Aug 2008 08:26:24 -0700 (PDT)
In-Reply-To: <20080818130229.GA13804@ice.cs.cornell.edu>
X-IP: 132.174.124.40
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>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GoogleT5; 
	.NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1),gzip(gfe),gzip(gfe)
Message-ID: <763f270a-2210-4f7a-8576-a4774250a132@k7g2000hsd.googlegroups.com>
Subject: Re: Aggregation/Resource Map relationship question
From: Jeff Young <jyoung.o...@gmail.com>
To: OAI-ORE <oai-ore@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Aug 18, 9:02=A0am, Simeon Warner <sim...@cs.cornell.edu> wrote:
> I think this is why we (try to) avoid use of the word "representation"
> in the ORE docs except in the strict web architecture sense, e.g when
> describing the whe web architecture athttp://www.openarchives.org/ore/0.9=
/primer.html#Web_Arch.
>
> The fundamental reason why we don't have Aggregation =3D=3D resource and
> Resource Map =3D=3D representation is that we think they both need to hav=
e
> identifiers so that we can talk about them. In the web architecture,
> resources have URIs as identifiers but representions don't have have
> their own id (they are determined/"identified" by the resource URI,
> time, request info, phase of moon, etc.).

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

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.