I've only just come to appreciate OAI-ORE - thanks a lot for a great
format!
Even though I'm a newbie, I thought I'd post one of my thoughts here.
Maybe it helps explaining ORE in future tutorials, etc.
In short: in ORE Atom, the approach of pushing each Resource Map into
an Atom <entry> element seemed unintuitive to me at first.
Why is that?, What is my background?
Rather than publication repositories, we are working with research
data (digitised books, transcriptions). This means that
a) the research data is versioned with a varying rate of about one new
version per week.
b) I'd like to model both datastreams and behaviors (i.e. re-
representation services) as ORE Resources, which means that we can end
up with quite a number of Resouces and their metadata. For example, an
object containing a digitised image (80 megs) offers a thumbnail image
(500k) - the user does not care whether the thumbnail is stored as a
separate datastream or whether it is created on the fly by a behavior,
so it is exposed as a Resource.
With such rather large objects, pushing Resource Maps into a single
Atom entry element can become dense. Also, the environment consists of
multiple federated repositories, so an individual repository is not as
important as (1) the individual object and (2) cross-repository
collections.
With that background, it would be more intuitive to me, to model
* each Resource as an individual <entry> element,
* each Resource Map as an individual Atom feed (that grows over time
as new versions are added),
* for each collection there is a Sitemap (http://sitemaps.org/) that
indexes all the Atom feeds of its objects.
Ok, this is just a thought experiment. Also, you may argue that we
should decompose and work with smaller objects. Granted, there are
arguments both ways. - But maybe the thought experiment helps in
better connecting to people with such a background.
> I've only just come to appreciate OAI-ORE - thanks a lot for a great
> format!
> Even though I'm a newbie, I thought I'd post one of my thoughts here.
> Maybe it helps explaining ORE in future tutorials, etc.
> In short: in ORE Atom, the approach of pushing each Resource Map into
> an Atom <entry> element seemed unintuitive to me at first.
> Why is that?, What is my background?
> Rather than publication repositories, we are working with research
> data (digitised books, transcriptions). This means that
> a) the research data is versioned with a varying rate of about one new
> version per week.
> b) I'd like to model both datastreams and behaviors (i.e. re-
> representation services) as ORE Resources, which means that we can end
> up with quite a number of Resouces and their metadata. For example, an
> object containing a digitised image (80 megs) offers a thumbnail image
> (500k) - the user does not care whether the thumbnail is stored as a
> separate datastream or whether it is created on the fly by a behavior,
> so it is exposed as a Resource.
> With such rather large objects, pushing Resource Maps into a single
> Atom entry element can become dense. Also, the environment consists of
> multiple federated repositories, so an individual repository is not as
> important as (1) the individual object and (2) cross-repository
> collections.
> With that background, it would be more intuitive to me, to model
> * each Resource as an individual <entry> element,
> * each Resource Map as an individual Atom feed (that grows over time
> as new versions are added),
> * for each collection there is a Sitemap (http://sitemaps.org/) that
> indexes all the Atom feeds of its objects.
> Ok, this is just a thought experiment. Also, you may argue that we
> should decompose and work with smaller objects. Granted, there are
> arguments both ways. - But maybe the thought experiment helps in
> better connecting to people with such a background.
|
