|
|
OAI-ORE |
On Aug 18, 5:28 pm, "Robert Sanderson" <azarot...@gmail.com> wrote:
My intuition is telling me that ORE Atom serialization problems are
At least some concepts in ORE appear to be tunneled over HTTP that
Jeff
> [1]http://foresite-toolkit.googlecode.com/
> On Mon, Aug 18, 2008 at 9:48 PM, Peter Keane <pke...@mail.utexas.edu> wrote:
> > That probably sounds heretical, but too much emphasis on "modeling" as
> - Show quoted text -
> As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else
If you are saying that ORE has passed the Rubicon, I can accept that.
> walks".
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
I trust that ORE is easy to implement. It's just not clear to me yet
> very readily implementable.
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
I am reluctant to share my suspicion about this since I haven't earned
> hardest part, to the point of total nightmare to get right.
the right yet. I encourage everyone to hit the delete button before
reading any farther.
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
Since ORE doesn't recognize the resource/representation model defined
> 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.
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
Again, I encourage everyone to hit the delete button before reading
> 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.
farther. Chances are good that I am merely displaying my ignorance of
ORE.
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.
> > 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.
> > 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 -