Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question
MIME-Version: 1.0
Date: Mon, 18 Aug 2008 19:02:49 -0700 (PDT)
In-Reply-To: <303afa280808181428m1591a1f8i7991761a6ad2d0bd@mail.gmail.com>
References: <15c4095c-12ba-4ef4-9865-db0d234d184c@79g2000hsk.googlegroups.com> 
	<20080814194905.GA1749@ice.cs.cornell.edu> <028312c8-afeb-4826-ac62-9d1a4ddd198e@f63g2000hsf.googlegroups.com> 
	<84d06a7b-b4b9-4b2e-870c-06ad72015ef3@79g2000hsk.googlegroups.com> 
	<20080818130229.GA13804@ice.cs.cornell.edu> <763f270a-2210-4f7a-8576-a4774250a132@k7g2000hsd.googlegroups.com> 
	<28cdedfa-9b77-4e07-be18-4ad4d403bf41@k7g2000hsd.googlegroups.com> 
	<8158ad750808181348x6ec7bc26q4d1cec120c5ddfd@mail.gmail.com> 
	<303afa280808181428m1591a1f8i7991761a6ad2d0bd@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <a95d4d73-7e4e-4531-8cc8-1bad9376f6de@k37g2000hsf.googlegroups.com>
Subject: Re: Aggregation/Resource Map relationship question
From: Jeff Young <jyoung.o...@gmail.com>
To: OAI-ORE <oai-ore@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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