|
|
OAI-ORE |
On Mon, Aug 18, 2008 at 4:28 PM, Robert Sanderson <azarot...@gmail.com>wrote: > 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/ > 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 >> That probably sounds heretical, but too much emphasis on "modeling" as
But would some or all of that difficulty be cleared up by the new Atom
> walks".
> very readily implementable. In fact the Atom serialisation was by FAR the
> hardest part, to the point of total nightmare to get right.
serialization proposal (
http://www.openarchives.org/ore/documents/atom_revision_20080801.html)? The
new serialization seems like it would be easy to implement and from the
client side easier to make use of (in many cases) than an RDF-based
serialization.
What I meant is that I fear a tight coupling between servers and clients
> 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.
vis-a-vis what is a representation and what is a resource instead of
sticking with MIME types and hypermedia as the basis for the "contract" --
therein I see the benefit of a set of specifications in which
atom:link@reland atom:category and such like are critical.
>> 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.