Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question

Robert Sanderson

More options Aug 19 2008, 7:28 am

From: "Robert Sanderson" <azarot...@gmail.com>

Date: Mon, 18 Aug 2008 22:28:49 +0100

Local: Tues, Aug 19 2008 7:28 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
  

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.

Reply to author Forward