Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question
Received-SPF: neutral (google.com: 172.21.16.4 is neither permitted nor denied by domain of azarot...@gmail.com) client-ip=172.21.16.4;
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=XVyEKD7RsOZn/lWfk/SFuG86JEso1por8mJ+ZKlEG8Knv1dbqY9i1Ji4EaBztnHq3N
         IHmr5kWawA1D3ae1LJBrkBvrQPtRM7RYwjHr/40B7dBqZqG/lHJKSYIUYs0yhxj/X70v
         QTcDAGG/VxcGR18lAzsc4f+AJiMNQ924OWE0M=
Message-ID: <303afa280808190110v738c2ef7le31915077eebabc6@mail.gmail.com>
Date: Tue, 19 Aug 2008 09:10:49 +0100
From: "Robert Sanderson" <azarot...@gmail.com>
To: oai-ore@googlegroups.com
Subject: Re: Aggregation/Resource Map relationship question
In-Reply-To: <8158ad750808181453r30ae5c27l38cbd940dcf85...@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_1994_4312092.1219133449734"
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>
	 <8158ad750808181453r30ae5c27l38cbd940dcf85...@mail.gmail.com>

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

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

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


Yes, the new specification makes it much easier, and seems much more in line
with the way people actually *use* Atom.  From the client side, you can now
probably get by with a parser that only understands Atom, rather than one
that also understands ORE's Atom spec.

That said, the inherent difficulty comes from using an RDF model underneath
in order to serialise the RDF formats, and to allow for arbitrary triples,
and then layering what is effectively an object model over top (with
Aggregations, Resources, Resource Maps, Agents and so forth)



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


Yep.  I think the new spec does a better job of re-using Atom's linking
constructions appropriately (ob. disclaimer of authorship aside)

Rob

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

<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Aug 18, 2008 at 10:53 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 class="gmail_quote"><div class="Ih2E3d">On Mon, Aug 18, 2008 at 4:28 PM, Robert Sanderson <span dir="ltr">&lt;<a href="mailto:azarot...@gmail.com" target="_blank">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">As Dewitt Clinton of OpenSearch fame says, &quot;Code talks, everything else walks&quot;.<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><div dir="ltr"><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" target="_blank">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></div></div></blockquote><div dir="ltr"><br><br>Yes, the new specification makes it much easier, and seems much more in line with the way people actually *use* Atom.&nbsp; From the client side, you can now probably get by with a parser that only understands Atom, rather than one that also understands ORE&#39;s Atom spec.<br>
<br>That said, the inherent difficulty comes from using an RDF model underneath in order to serialise the RDF formats, and to allow for arbitrary triples, and then layering what is effectively an object model over top (with Aggregations, Resources, Resource Maps, Agents and so forth)<br>
&nbsp;<br><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"><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

</blockquote></div><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>
</div></div></div></blockquote></div><br><br>Yep.&nbsp; I think the new spec does a better job of re-using Atom&#39;s linking constructions appropriately (ob. disclaimer of authorship aside)<br><br>Rob<br><br></div>

------=_Part_1994_4312092.1219133449734--