Thanks very much Herbert! This is quite helpful. I"ll make a few
comments below.
On Jun 30, 6:05 pm, "Herbert van de Sompel" <
hvds...@gmail.com> wrote:
> Peter,
>
> First, I need to state that I can not look at the problem in the way you
> formulate it, i.e. what is the value that ORE adds to Atom? ORE is not an
> effort about profiling Atom, it is an effort about devising a way to deal
> with aggregations of web resources. And in order to tackle that problem, ORE
> has not started by selecting a specific serialization. Instead, it has
The web is awash now with documents in Atom format. Likewise, there
are numerous tools for managing content that already speak Atom
(notably, DSpace is not among them). I could see great utility in
starting with Atom and working out from there to express the sorts of
relationships that ORE aims to express.
> worked on a data model that builds, among others, on the web architecture.
I guess I would have to ask "which web?" As Erik Wilde pointed out in
a comment on his blog posting (
http://www.oreillynet.com/xml/blog/2008/06/oaiore_compound_documents_draf.html),
the "web" and the "semantic web" are two *very* different things. I
await the day that the semantic web brings its promised benefits.
Meanwhile, I find myself in the current iteration of the web (I'm told
we are up to 2.0 at this point ;-)), getting lots done with stuff that
has a just a URI and a MIME Type.
> With the data model in place, serializations have been devised. Atom is one
> such serialization, and we have proposed a way to express the ORE data model
> using Atom serializations. We have attempted:
> - to make the Atom documents human friendly
> - to make the Atom documents understandable for regular Atom processors
> (both semantic and syntactic)
I'd have to ask for what value of "understandable?" That's really the
core point of my last message. I don't think that an ORE Atom
serialization would be any *more* understandable than my wget
+autogenerated Atom to any Atom processor I am aware of. I just do
not see the use. Surely web browsers are more ubiquitous than feed
readers. Why not just focus on XHTML+RDFa for the "human-friendly"
version or ORE? I find it misleading to suggest that an Atom
serialization of an ORE aggregation offers any "semantic" richness at
all, since the RDF-kind of richness was explicitly rejected by the
Atom WG.
> - to allow ORE-Atom processors to understand the "deeper" ORE meaning
> expressed in the Atom documents
Surely an ORE-Atom processor would require RDF-capable tools, which,
as Erik Wilde pointed out, is a whole other kettle of fish than XML.
>
> We very much understand the need for e.g. interoperable categorizations of
> aggregations, aggregated resources, etc but hoped this would be a problem
> that would be tackled by other community efforts. Interestingly enough,
> there was an indication earlier today that the joint DSpace/Fedora effort
> might be looking into parts of that problem space (seehttp://
wiki.dspace.org/index.php/DSpace_Fedora_Collaboration). ORE has
I fear that OAI-ORE is at its essence a DSpace<->Fedora<->ePrints
solution. That's really unfortunate, since the de facto world of
"institutional repositories" spans far beyond those applications.
Undoubtedly, the big 3 IRs were developed without the same eye towards
interoperability that newer applications and standards (Atom, JCR,
Flickr, Drupal, Wordpress, Google Docs) adopt as a matter of course.
I'd hate to see all of this work being done simply to compensate for
an inadequate content/interop model in a few applications. I am
correct in thinking that OAI-ORE would be useful for preserving and
making useful assertions about a set of documents a faculty member put
on Google Docs or a bunch of photos they put on Flickr? Obviously,
herein lies the the need for concrete use cases and scenarios.
> limited itself to specifying a very limited ORE-specific vocabulary, and
> recommending the use of some general purpose other vocabulary terms (seehttp://
www.openarchives.org/ore/0.9/vocabulary). We felt that beyond this,
> things became a matter of community profiling. We hope to see efforts
> emerging inr this realm via the ORE Cookbook wiki (seehttp://
foresite.cheshire3.org/wiki/).
>
> I don't have time to go into a lot of detail about your example, but I would
> like to indicate that it illustrates why ORE has defined a model that
> contains an Aggregation (conceptual) and a Resource Map describing the
> Aggregation (concrete). Here is a snippet from your example, in which the
> Atom feed is supposed to represent the aggregation of all resources for a
> specific D-Lib magazine article:
>
> <feed xmlns="
http://www.w3.org/2005/Atom">
> <id>
http://oreproxy.org/r?what=http://www.dlib.org/dlib/february06/smith/...</id>
Most decidedly not. The atom:title is the title of the aggregation-as-
feed (as per RFC 4287). Sorry, I thought I made that obvious.
> - the content of <author> is the author of the Atom document, i.e. you. It
again, as per RFC 4287.
> is not the author of the D-Lib article.
>
> So, there is some discrepancy involved.
Sorry, but there is not. The sample is pure, valid RFC 4287 (Atom),
with no more and no less semantic richness than the spec allows.
By which I merely want to illustrate
> that, in the ORE context, there are 2 resources involved, each of which can
> have their own properties and relationships: the Resource Map (~Atom
> document) and the Aggregation described by the Resource Map. The Atom ORE
> Profile document (seehttp://
www.openarchives.org/ore/0.9/atom) details how
> to express this 2 resource ORE model in Atom serilaizations.
>
> Oh, and one more detail: Proxy URIs were introduced in ORE to allow
> referencing an aggregated resource the way it exists in the context of an
> aggregation. It's quite bizar to use them to identify an aggregation as you
> do with:
>
>
http://oreproxy.org/r?what=http://www.dlib.org/dlib/february06/smith/...
>
Yes indeed. I left the "&where=..." off of that atom:id. My
mistake.
I will note that stuffing all of this semantics into the id seems way
beyond being a proper use of Atom. The fact is, Atom provides a much
cleaner alternative with "atom:category," which is exactly the place
to express the meaning of this resource's "aggregatedness" in the
context of this specific aggregation. The problem (well, for Atom) is
that the ORE abstract model (5.3) states that a "URI-AR is not
specific to the Aggregation." Well, in Atom there is no such thing as
a relationship outside of that expressed in the Atom document. Thus,
category works just fine. It's the classic tension between an
"essentialist" world view, and an "existentialist" world view. That's
the semantic web vs. human web dichotomy all over again. Both valid,
of course, but awfully hard to reconcile.
> For one, using this approach one can't follow its nose from the URI of the
> Aggregation (the URI above here) to the URI of the Resource Map (the URI in
> <link rel="self"> in your exaample ). That ability is required in ORE.
Ultimately, though, I find myself far more interested in doing some
useful & interesting things (moving an electronic journal from one
system to another, archiving a scholar's set of images they have
posted on Flickr, "porting" a set of Google Docs into an institutional
repository, creating a re-usable XML export of a FileMaker database,
etc.) than meeting the requirements of the OAI-ORE spec. Of course in
the best-world scenario, the latter enables the former. And I truly
hope that'll be the case.
I suspect my comments are not terribly helpful at this point (and
perhaps they strike most readers here as utterly irrelevant! :-)), so
I will certainly not press the point. It is likely the case that I am
wanting OAI-ORE to be something it is not. In my work as a librarian/
content manager/archivist, I have found very real benefit in looking
for analogs to my work outside the typical library/archive sphere.
It's been enlightening and also a bit frightening as I realize that
much (perhaps the vast majority) of intellectual "product" is born,
lives, and thrives outside of this more traditional sphere. I would
hate to see the library world not take the opportunity to join in.
best regards-
Peter
>
> cheers
>
> herbert
> ...
>
> read more »