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
mistakenly interpret my old posts as new ones. If ORE uses atom:id for
to a new URI-A, which may lead to duplicate entries on the client side.
> 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
> (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
> <atom:category scheme="http://www.openarchives.org/ore/terms/"
> label="Aggregation" />
> On Tue, Aug 5, 2008 at 3:34 PM, Sean Gillies <sean.gill...@gmail.com> wrote:
>> 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?
>> pkeane wrote:
>>> 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
>>>> this list, in private communications, and via the blogosphere, we have
>>>> a bold move to compile a Discussion Document that outlines a proposal
>> for a
>>>> significantly different ORE Atom serialization.
>>>> The Discussion Document is at <
>>>> 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
>>>> Group <http://groups.google.com/group/oai-ore> to share your insights.
>>>> Thanks! Greetings.
>>>> Herbert Van de Sompel
>>>> Herbert Van de Sompel
>>>> Digital Library Research & Prototyping
>>>> Los Alamos National Laboratory, Research Libraryhttp://