Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question
Received-SPF: pass (google.com: domain of pjke...@gmail.com designates 209.85.200.170 as permitted sender) client-ip=209.85.200.170;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:references:x-google-sender-auth;
        b=Jecsx30bqEHkTWfjochib+kMiwpANCaRQSnvLX28GmFvGtrYvzhwLZ/7yPeZpyoGHw
         YXFWLLk8Vo3bhkxcjVFCNJGeTgEOyQ5whlqgZ59k/BdJIvlBn0hBJm+cwjL5vSbgiX01
         BIldFEPMcwuUlCrCNRHPs3YKmNcdIC/AS6cAU=
Message-ID: <8158ad750808181348x6ec7bc26q4d1cec120c5ddfd@mail.gmail.com>
Date: Mon, 18 Aug 2008 15:48:58 -0500
From: "Peter Keane" <pke...@mail.utexas.edu>
Sender: pjke...@gmail.com
To: oai-ore@googlegroups.com
Subject: Re: Aggregation/Resource Map relationship question
In-Reply-To: <28cdedfa-9b77-4e07-be18-4ad4d403b...@k7g2000hsd.googlegroups.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_95499_23075633.1219092538173"
References: <15c4095c-12ba-4ef4-9865-db0d234d1...@79g2000hsk.googlegroups.com>
	 <20080814194905.GA1...@ice.cs.cornell.edu>
	 <028312c8-afeb-4826-ac62-9d1a4ddd1...@f63g2000hsf.googlegroups.com>
	 <84d06a7b-b4b9-4b2e-870c-06ad72015...@79g2000hsk.googlegroups.com>
	 <20080818130229.GA13...@ice.cs.cornell.edu>
	 <763f270a-2210-4f7a-8576-a4774250a...@k7g2000hsd.googlegroups.com>
	 <28cdedfa-9b77-4e07-be18-4ad4d403b...@k7g2000hsd.googlegroups.com>

------=_Part_95499_23075633.1219092538173
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 18, 2008 at 1:57 PM, MichaelNelson <RhodeWarri...@gmail.com>wrote:

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

There are numerous circumstances when making a distinction between a
resource and a representation is simply not all that useful, and thus the
idea that "it is perfectly obvious and reasonable from an implementation
point of view" ought to win the day.  I fear that drawing the line between
those too strongly (especially since content negotiation is by no means
always practical or operational) may be dangerous.

That probably sounds heretical, but too much emphasis on "modeling" as
opposed to implementation may put too much emphasis on the producer and not
enough on the consumer.  A consumer (i.e., implementation) ought to be able
to decide for itself, thus allowing for evolution, serendipitious reuse,
etc.  The "contract" that a resource map producer asserts ought to be as
"secular" as possible -- "hypermedia as the engine of state" -- as the REST
principles state.  ORE is really about asserting the "state" of a set of
resources, as embodied in each resource's relationship with other resources
and all of it described by links.

--peter keane



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

------=_Part_95499_23075633.1219092538173
Content-Type: text/html; charset=UTF-8

<div dir="ltr">On Mon, Aug 18, 2008 at 1:57 PM, MichaelNelson <span dir="ltr">&lt;<a href="mailto:RhodeWarri...@gmail.com">RhodeWarri...@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
&gt; The belief that &quot;representations don&#39;t have their own id&quot; seems to be<br>
&gt; the root of the problem here. In HTTP, representations CAN have their<br>
&gt; own identifiers (URIs) and thus can be addressed individually. As<br>
&gt; evidence, the Content-Location header exists to notify a client of<br>
&gt; this fact (<a href="http://tools.ietf.org/html/rfc2616#section-14.14" target="_blank">http://tools.ietf.org/html/rfc2616#section-14.14</a>). The<br>
&gt; possibility of representation identifiers is even clearer in the case<br>
&gt; of 300 Multiple Choices (<a href="http://tools.ietf.org/html/" target="_blank">http://tools.ietf.org/html/</a><br>
&gt; rfc2616#section-10.3.1).<br>
<br>
</div>That is where there is a discrepancy between RFC 2616 and AWW. &nbsp;In<br>
the http RFC, representations can have their own URIs. &nbsp;The AWWW<br>
seems to tip-toe around this. &nbsp;Consider:<br>
<br>
<a href="http://foo.edu/bar.abc" target="_blank">http://foo.edu/bar.abc</a><br>
<br>
That certainly appears to be a resource: it has a URI and when<br>
dereferenced it returns a representation (or, more likely, a<br>
&quot;variant&quot; in RFC-2616 terms).<br>
<br>
Now I show you these URIs:<br>
<br>
<a href="http://foo.edu/bar" target="_blank">http://foo.edu/bar</a><br>
<a href="http://foo.edu/bar.abc" target="_blank">http://foo.edu/bar.abc</a><br>
<a href="http://foo.edu/bar.xyz" target="_blank">http://foo.edu/bar.xyz</a><br>
<br>
and tell that the last two URIs identify possible representations<br>
for the 1st URI. &nbsp;That means &quot;<a href="http://foo.edu/bar.abc" target="_blank">http://foo.edu/bar.abc</a>&quot; is both a<br>
resource in its own right *and* a representation for another<br>
resource. &nbsp;Effectively, its both a 1st and 2nd class citizen. &nbsp;RFC<br>
2616 doesn&#39;t directly address this apparent inconsistency of URIs<br>
identifying both a resource and representation. &nbsp;Its perfectly<br>
obvious and reasonable from an implementation point of view, but<br>
its really non-sensical from a modeling point of view.<br>
<br>
The AWWW + friends introduce the concepts of &quot;information resource&quot;<br>
(i.e., web things like html and pdf) and &quot;non-information resource&quot;<br>
(i.e., real world things like cars and sandwiches) and 303 redirects<br>
(which can be thought of as a generalized version of http content<br>
negotiation as defined in RFC-2295). &nbsp;IMO, this is the opposite of<br>
the above: it makes sense from a modeling point of view but is silly<br>
from an implementation point of view (&quot;so the only thing this URI<br>
will *ever* do is redirect me to this other URI? &nbsp;ok...&quot;)<br>
</blockquote><div><br>There are numerous circumstances when making a distinction between a resource and a representation is simply not all that useful, and thus the idea that &quot;it is perfectly obvious and reasonable from an implementation point of view&quot; ought to win the day.&nbsp; I fear that drawing the line between those too strongly (especially since content negotiation is by no means always practical or operational) may be dangerous.&nbsp; <br>
<br>That probably sounds heretical, but too much emphasis on &quot;modeling&quot; as opposed to implementation may put too much emphasis on the producer and not enough on the consumer.&nbsp; A consumer (i.e., implementation) ought to be able to decide for itself, thus allowing for evolution, serendipitious reuse, etc.&nbsp; The &quot;contract&quot; that a resource map producer asserts ought to be as &quot;secular&quot; as possible -- &quot;hypermedia as the engine of state&quot; -- as the REST principles state.&nbsp; ORE is really about asserting the &quot;state&quot; of a set of resources, as embodied in each resource&#39;s relationship with other resources and all of it described by links.&nbsp; <br>
<br>--peter keane<br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
regards,<br>
<br>
Michael<br>
<div><div></div><div class="Wj3C7c"><br>
&gt;<br>
&gt; The domain model for ORE is still unclear to me, but on this one point<br>
&gt; it seems like some heavyweight sources are being cited to work around<br>
&gt; a relatively simple confusion. Somehow this workaround has come full-<br>
&gt; circle and produced a resource without a representation that resolves<br>
&gt; to a response that is indistinguishable from a representation. This<br>
&gt; circularity implies that there are some concepts in ORE that can be<br>
&gt; factored out.<br>
&gt;<br>
&gt; Jeff<br>
<br>
</div></div></blockquote></div><br></div>

------=_Part_95499_23075633.1219092538173--