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.173 as permitted sender) client-ip=209.85.200.173;
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=sQu8P7DNIXYRdrBa5Rdr98k0qLQ2o/cHyIaLPBLSfEqiU0HFZhYmiKkW9sySCyl0sl
         2bWPUcAq75YGIXlMnUcIE/hxn24kGDVuYEeD28bkQOP/OPAx56ToXtugkPVv3X7oYNIx
         zKAU6ZnP9cnwzqzOqAt4wCipKHS5kcco33jNg=
Message-ID: <8158ad750808181453r30ae5c27l38cbd940dcf8576c@mail.gmail.com>
Date: Mon, 18 Aug 2008 16:53:33 -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: <303afa280808181428m1591a1f8i7991761a6ad2d...@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_96341_22514113.1219096413651"
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>
	 <303afa280808181428m1591a1f8i7991761a6ad2d...@mail.gmail.com>

------=_Part_96341_22514113.1219096413651
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 18, 2008 at 4:28 PM, Robert Sanderson <azarot...@gmail.com>wrote:

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

But would some or all of that difficulty be cleared up by the new Atom
serialization proposal (
http://www.openarchives.org/ore/documents/atom_revision_20080801.html)?  The
new serialization seems like it would be easy to implement and from the
client side easier to make use of (in many cases) than an RDF-based
serialization.

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

What I meant is that  I fear a tight coupling between servers and clients
vis-a-vis what is a representation and what is a resource instead of
sticking with MIME types and hypermedia as the basis for the "contract" --
therein I see the benefit of a set of specifications in which
atom:link@reland atom:category and such like are critical.


>
>
> [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_96341_22514113.1219096413651
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Aug 18, 2008 at 4:28 PM, Robert Sanderson <span dir="ltr">&lt;<a href="mailto:azarot...@gmail.com">azarot...@gmail.com</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"><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.</div>
</blockquote><div><br>But would some or all of that difficulty be cleared up by the new Atom serialization proposal (<a href="http://www.openarchives.org/ore/documents/atom_revision_20080801.html">http://www.openarchives.org/ore/documents/atom_revision_20080801.html</a>)?&nbsp; The new serialization seems like it would be easy to implement and from the client side easier to make use of (in many cases) than an RDF-based serialization.<br>
</div><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"><br><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.</div>
</blockquote><div><br>What I meant is that&nbsp; I fear a tight coupling between servers and clients vis-a-vis what is a representation and what is a resource instead of sticking with MIME types and hypermedia as the basis for the &quot;contract&quot; -- therein I see the benefit of a set of specifications in which atom:link@rel and atom:category and such like are critical.<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;"><div dir="ltr"><br>
<br>[1] <a href="http://foresite-toolkit.googlecode.com/" target="_blank">http://foresite-toolkit.googlecode.com/</a><div class="Ih2E3d"><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" target="_blank">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></div></div></blockquote></div></div></div><div><div></div><div class="Wj3C7c"><br>
<br>
</div></div></blockquote></div><br></div>

------=_Part_96341_22514113.1219096413651--