Proposal to revise ORE Atom serialization

[Herbert van de Sompel]

hi all,

As a result of feedback that was provided over the past few weeks, both via this list, in private communications, and via the blogosphere, we have made a bold move to compile a Discussion Document that outlines a proposal for a significantly different ORE Atom serialization.

The Discussion Document is at <http://www.openarchives.org/ore/documents/atom_revision_20080801.html>.

We understand this proposal comes very late in the ORE process that is expected to deliver 1.0 specification by the end of September 2008. Your feedback to this proposal is absolutely crucial. Please use the ORE Google Group to share your insights.

Thanks! Greetings.

Herbert Van de Sompel

--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

[pkeane]

Herbert, et. al. -

This revised ORE Atom serialization looks very good. It seems to
leverage the power/elegance of the Atom protocol and to be a genuine
value add for the use cases described. It is indeed "readily
understandable," as noted in the "5. General Discussion," and these
ORE Atom Entries make perfect sense *as* Atom and *as* ORE. It seems
appropriately extensible, pending further discussion of the Atom
Triples work (I certainly appreciate the approach you are taking
there), and given the fact, as noted, that other general Atom
extension work just fine in this context. I look forward to hearing
other opinions. As far as I am concerned, I would give a very
enthusiastic +1 to this approach.

--peter keane

On Aug 1, 2:57 pm, "Herbert van de Sompel" <hvds...@gmail.com> wrote:
> hi all,
>
> As a result of feedback that was provided over the past few weeks, both via
> this list, in private communications, and via the blogosphere, we have made
> a bold move to compile a Discussion Document that outlines a proposal for a
> significantly different ORE Atom serialization.
>
> The Discussion Document is at <http://www.openarchives.org/ore/documents/atom_revision_20080801.html>.
>
> We understand this proposal comes very late in the ORE process that is
> expected to deliver 1.0 specification by the end of September 2008. Your

> feedback to this proposal is absolutely crucial. *Please use the ORE Google
> Group <http://groups.google.com/group/oai-ore> to share your insights.

>
> Thanks! Greetings.
>
> Herbert Van de Sompel

> *

[Sean Gillies]

Looks good to me too, but I wonder if using the atom:id element (value
of which must never change) to specify the URI-A doesn't prevent the
resources from evolving. Unless there is already a link relation type
out there specifically for non-information resources, maybe ORE could
mint one for the URI-A?

Sean

[Herbert van de Sompel]

Thanks for this, Sean.

2 comments:

(1) In Atom, as far as I understand, an /entry/id can remain constant as the Entry identified by that /entry/id evolves. The distinction between the various versions of an Entry is made by means of different values for the /entry/updated element. Presuming an Aggregation (mapped to Entry) evolves over time, one would expect the Entry that represents it to evolve over time, and hence, the URI-A (/entry/id) to remain constant, but the /entry/updated to change. A question arises as to which kind of changes to the Aggregation should be reflected by a changed /entry/updated. In general, Atom is very open ended about when /entry/updated should change and says s/t like "when the change to the Entry is deemed relevant to the publisher". Bringing that back to ORE, I think /entry/updated could change when e.g. Entry metadata is changed, when Aggregated Resources are added/removed, when an Aggregated Resource has changed (and the publisher of the Aggregation is actually aware of that happening), ...

Note also that the evolution of Aggregations over time (and archiving them) is something that I explored with my team in an experiment for which a movie recording is available at <http://www.ctwatch.org/quarterly/multimedia/11/ORE_prototype-demo/>. The experiment was done in Spring 2007, so some of the language and concepts used in the voice-over are dated, but the essence still stands. Or so I think.

(2) We propose to express the following category in the Entry to indicate that the Entry represents an ORE Aggregation (and hence a non-information resource):

<atom:category scheme="http://www.openarchives.org/ore/terms/"

   term="http://www.openarchives.org/ore/terms/Aggregation"

   label="Aggregation" />

Cheers

Herbert

[Sean Gillies]

I was thinking of a different kind of evolution. Recently I moved my
blog to a new domain. I modified all URLs in my feeds, but preserved the
original atom:id of every so that feed reading software wouldn't
mistakenly interpret my old posts as new ones. If ORE uses atom:id for
URI-A then the id must change if you ever need to move your Aggregations
to a new URI-A, which may lead to duplicate entries on the client side.

Sean

[Herbert van de Sompel]

Sean,

We were not ignoring you. Just biting our nails ...

So, a few of us discussed the issue you brought up. And we found that the broader issue is really that our proposal to stuff URI-A into /entry/id is an "overloading" similar to stuffing a Proxy URI into /entry/id (in ORE Atom 0.9) was an overloading.  Add to that the weirdness (definitely for RDF hardliners) that URI-A would at the same time identify an Aggregation and an Atom Entry. And add to that the relocation issue you brought up. Now, you kind of have to reach the conclusion that one should leave those core Atom elements (/entry/id ; /entry/updated ; /entry/published) to the Atom world an not re-interpret them for ORE.

To cut a long story short, we thought of the following proposal to deal with all of this:

1. Express URI-A in a special-purpose ORE <link>, i.e.
<link rel="ore:describes" href="URI-A">. Which really states that this Entry describes an ORE Aggregation.

2. Populate /entry/id in a manner that is sensible to the environment that generates the Atom Entries that describes the Aggregation. Possibilities include:
a. tag URI
b. urn:uuid
c. URI-R (the value of /entry/link@rel="self") as, for example, Google does
d. URI-A

In the case of (c) and (d), your relocation problem would still exist. And our specs should make people aware of that.

Please let us know what you all think about this.

cheers

herbert

[Robert Sanderson]

The subversion codebase for the python foresite library now implements the latest thinking in atom serialization.

svn checkout http://foresite-toolkit.googlecode.com/svn/foresite-python/trunk

If people would like to try it out and compare to the old version:

>>> newsrlz = AtomSerializer()
>>> oldsrlz = OldAtomSerializer()

and then use as expected.  Feedback about the serialization here, about the code to foresite's google group please!

Thanks :)

On Tue, Aug 19, 2008 at 6:15 PM, Herbert van de Sompel <hvd...@gmail.com> wrote:

We were not ignoring you. Just biting our nails ... [...]