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.
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 Library http://public.lanl.gov/herbertv/
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:
> 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.
> 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/
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?
> 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.
>> 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/
(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):
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.
> >> 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/
-- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/
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.
> (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):
> 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.
>>>> -- >>>> Herbert Van de Sompel >>>> Digital Library Research & Prototyping >>>> Los Alamos National Laboratory, Research Libraryhttp:// >> public.lanl.gov/herbertv/
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
On Thu, Aug 7, 2008 at 10:40 AM, Sean Gillies <sean.gill...@gmail.com>wrote:
> 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 wrote: > > 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):
> > 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/
-- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/
