|
|
OAI-ORE |
On Mon, Aug 18, 2008 at 10:53 PM, Peter Keane <pke...@mail.utexas.edu>wrote: >> As Dewitt Clinton of OpenSearch fame says, "Code talks, everything else > But would some or all of that difficulty be cleared up by the new Atom That said, the inherent difficulty comes from using an RDF model underneath Rob
> On Mon, Aug 18, 2008 at 4:28 PM, Robert Sanderson <azarot...@gmail.com>wrote: Yes, the new specification makes it much easier, and seems much more in line
>> walks".
>> Well ... in my implementation experience[1], the current specifications
>> are 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.
with the way people actually *use* Atom. From the client side, you can now
probably get by with a parser that only understands Atom, rather than one
that also understands ORE's Atom spec.
in order to serialise the RDF formats, and to allow for arbitrary triples,
and then layering what is effectively an object model over top (with
Aggregations, Resources, Resource Maps, Agents and so forth)
> What I meant is that I fear a tight coupling between servers and clients Yep. I think the new spec does a better job of re-using Atom's linking
> 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.
constructions appropriately (ob. disclaimer of authorship aside)