Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question

Peter Keane

More options Aug 19 2008, 7:53 am

From: "Peter Keane" <pke...@mail.utexas.edu>

Date: Mon, 18 Aug 2008 16:53:33 -0500

Local: Tues, Aug 19 2008 7:53 am

Subject: Re: Aggregation/Resource Map relationship question

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

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.

Reply to author Forward