|
|
OAI-ORE |
As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else Well ... in my implementation experience[1], the current specifications are The difference between URI-A and URI-R is very easy to implement, and The problem with implementations deciding things for themselves rather than [1] http://foresite-toolkit.googlecode.com/ > That probably sounds heretical, but too much emphasis on "modeling" as
walks".
very readily implementable. In fact the Atom serialisation was by FAR the
hardest part, to the point of total nightmare to get right.
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.
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.
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.
> 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.