> 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

> 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?

>> Sean

>> 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
>> 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
>>>> *

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