Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question
Received-SPF: pass (google.com: domain of azarot...@gmail.com designates 209.85.217.13 as permitted sender) client-ip=209.85.217.13;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=oKJA+PtErIFewHMHhwcqGtb5zOy2AT7WbPtO7c+hLUw433EdDwZ/nf+s1uOOdvSbVO
         13/AFNFZBwbG6e7i9rC15qcDBvsKtVVILLoQ8fpJYFfEpmZ0Hc1pxn9ZvAkynelED+/o
         uvYM5oduDg+UZ0+4pyujCr0Eh7/8NupTJDQEU=
Message-ID: <303afa280808181428m1591a1f8i7991761a6ad2d0bd@mail.gmail.com>
Date: Mon, 18 Aug 2008 22:28:49 +0100
From: "Robert Sanderson" <azarot...@gmail.com>
To: oai-ore@googlegroups.com
Subject: Re: Aggregation/Resource Map relationship question
In-Reply-To: <8158ad750808181348x6ec7bc26q4d1cec120c5d...@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_150318_4486153.1219094929807"
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>
	 <8158ad750808181348x6ec7bc26q4d1cec120c5d...@mail.gmail.com>

------=_Part_150318_4486153.1219094929807
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else
walks".

Well ... in my implementation experience[1], the current specifications are
very readily implementable.  In fact the Atom serialisation was by FAR the
hardest part, to the point of total nightmare to get right.

The difference between URI-A and URI-R is very easy to implement, and
redirects in most environments are pretty trivial.  Actual content
negotiation is trickier (both client and server), which is why we can also
have ore:isDescribedBy to point at other resource maps.

The problem with implementations deciding things for themselves rather than
faithfully following a clear and easy to code set of specifications is a
*lack* of interoperability when two implementers have very clear and
different intuitions.

[1] http://foresite-toolkit.googlecode.com/

On Mon, Aug 18, 2008 at 9:48 PM, Peter Keane <pke...@mail.utexas.edu> wrote:

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

------=_Part_150318_4486153.1219094929807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div dir="ltr"><br>As Dewitt Clinton of OpenSearch fame says, &quot;Code talks, everything else walks&quot;.<br><br>Well ... in my implementation experience[1], the current specifications are very readily implementable.&nbsp; In fact the Atom serialisation was by FAR the hardest part, to the point of total nightmare to get right.<br>
<br>The difference between URI-A and URI-R is very easy to implement, and redirects in most environments are pretty trivial.&nbsp; Actual content negotiation is trickier (both client and server), which is why we can also have ore:isDescribedBy to point at other resource maps.&nbsp; <br>
<br>The problem with implementations deciding things for themselves rather than faithfully following a clear and easy to code set of specifications is a *lack* of interoperability when two implementers have very clear and different intuitions.<br>
<br>[1] <a href="http://foresite-toolkit.googlecode.com/">http://foresite-toolkit.googlecode.com/</a><br><br><div class="gmail_quote">On Mon, Aug 18, 2008 at 9:48 PM, Peter Keane <span dir="ltr">&lt;<a href="mailto:pke...@mail.utexas.edu">pke...@mail.utexas.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div>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>
<font color="#888888">
<br></font></div></div><div><div class="Wj3C7c"></div></div></blockquote></div></div>

------=_Part_150318_4486153.1219094929807--