Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question

Jeff Young

More options Aug 19 2008, 12:02 pm

From: Jeff Young <jyoung.o...@gmail.com>

Date: Mon, 18 Aug 2008 19:02:49 -0700 (PDT)

Local: Tues, Aug 19 2008 12:02 pm

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 Aug 18, 5:28 pm, "Robert Sanderson" <azarot...@gmail.com> wrote:

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

If you are saying that ORE has passed the Rubicon, I can accept that.
The fact that I am bogged down right out of the gate probably says
more about me than it does about ORE.

> Well ... in my implementation experience[1], the current specifications are
> very readily implementable.

I trust that ORE is easy to implement. It's just not clear to me yet
why it is necessary. I assume that this current thread is just me
stumbling out of the blocks. If my fumbling is a distraction, I will
understand and can try harder to work it out on my own.

> In fact the Atom serialisation was by FAR the
> hardest part, to the point of total nightmare to get right.

I am reluctant to share my suspicion about this since I haven't earned
the right yet. I encourage everyone to hit the delete button before
reading any farther.

My intuition is telling me that ORE Atom serialization problems are
related to the confusion about resource/representation, but I can't
back this up yet.

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

Since ORE doesn't recognize the resource/representation model defined
by HTTP, it shouldn't be surprising that content-negotiation is
tricky. Tunneling resource/representation relationships in RDF is
certainly one alternative, but it comes at a steep cost to HTTP
interoperability.

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

Again, I encourage everyone to hit the delete button before reading
farther. Chances are good that I am merely displaying my ignorance of
ORE.

At least some concepts in ORE appear to be tunneled over HTTP that
HTTP is capable of handling natively. The concepts of resource/
representation and content-negotiation appear to be likely candidates.
I would argue that tunneling generally reduces interoperability.

Jeff

> [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.- Hide quoted text -

> - Show quoted text -

Reply to author Forward