OAI-ORE & SWORD

[pkeane]

Does anyone here have any thoughts/observations/opinions about the
(potential?) relationship between OAI-ORE (spec. the Atom profile) and
SWORD [1] (and AtomPub profile)?

[1] http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_APP_Profile_1.1

--peter keane

[Simeon Warner]

On Fri, May 16, 2008 at 09:00:55AM -0700, pkeane wrote:
> Does anyone here have any thoughts/observations/opinions about the
> (potential?) relationship between OAI-ORE (spec. the Atom profile) and
> SWORD [1] (and AtomPub profile)?

I have an opinion, even based on a few thoughts, about SWORD and ORE:
I think there is great potential for the two to play together nicely.
We (arXiv.org) have implemented [2] SWORD as a way to automate ingest of
conference proceedings from conference management systems and are
looking at personal use too (e.g. a plugin for your word processor).
The particular place I see ORE coming in is in the description of
the article (or collection) as a whole. One can upload files and
APP/SWORD gives back a URI (media entry id) for each. The final stage
of providing a list of all the media entries for an "article" (perhaps
with semantics between resources, associated data or media indicated
as such, etc.) and seems to be an excellent match for an ORE Resource Map.

At OR08 there was talk that SWORD had additional funding to continue
development. I hope that arXiv will be somewhat involved but I haven't
heard anything since.

Cheers,
Simeon

> [1] http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_APP_Profile_1.1
Note most recent is:
http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_APP_Profile_1.2
current from
http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_APP_Profile

[2] Case study of arXiv implementation:
http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_case_studies#Case_study_1_:_arXiv

[Sean Gillies]

I think they should be compatible, though both are a bit underdeveloped
at the place where they might meet -- it's not clear whether resource
maps are or should be appendable AtomPub collections, and SWORD doesn't
concern itself with feed representations of its collections. Does
anybody know the motivation for that decision in SWORD (section 10)?

Sean

[Robert Sanderson]

Hi Peter,

Richard Jones at HP and I have a project which includes the use of ORE and SWORD together (at OR'08 I coined the term SW-ORE-D :D )

Our thoughts so far have been along the following possibilities:

* Simply send the Resource Map as the payload for SWORD in the same way that you would send anything else and let the server do what it wishes.
* Send a Resource Map as a 'manifest' or object description in a zip with the resources.
* Allow SW-ORE-D to manipulate the hierarchies within the repository via ORE nested aggregations.  Eg, to create a new Collection you would post a resource map for it. The server would then create a new deposit target for that collection against which you could post more collections recursively.
* Allow SW-ORE-D to manipulate the aggregations and aggregated resources themselves by depositing resources against Entries (possibly via the Proxy URI or something derivable from it).

We've not yet started this phase, but will report back on what happens when we do. (July or so)

Hope that helps,

Rob

[scottw]

Looking at the possibilities:

1. This looks the easiest, and sounds very tempting if you are only
depositing "virtual" packages or are expecting the target to pull in
any referenced media if and when needed.
2. Probably the most flexible; this is then a potential relatively
simple replacement for METS/MODS aka "interoperability hell". Could
have some gnarly aspects.
3. Interesting...what would this imply? </xkcd>
4. See above

For (1) & (2) how does the service document express support for this
method? For (1) there needs to be a resource map content-type (for
both Atom and RDF-XML serializations); for (2) a way of
differentiating this from plain application/zip.

Having experienced working with IMS CP, SCORM, MPEG21 and METS over
the past 8 years I'd vote strongly in favour of locking the options
down rather than opening them out...

S

On May 17, 12:09 pm, "Robert Sanderson" <azarot...@gmail.com> wrote:
> Hi Peter,
>
> Richard Jones at HP and I have a project which includes the use of ORE and
> SWORD together (at OR'08 I coined the term SW-ORE-D :D )
>
> Our thoughts so far have been along the following possibilities:
>
> * Simply send the Resource Map as the payload for SWORD in the same way that
> you would send anything else and let the server do what it wishes.
> * Send a Resource Map as a 'manifest' or object description in a zip with
> the resources.
> * Allow SW-ORE-D to manipulate the hierarchies within the repository via ORE
> nested aggregations. Eg, to create a new Collection you would post a
> resource map for it. The server would then create a new deposit target for
> that collection against which you could post more collections recursively.
> * Allow SW-ORE-D to manipulate the aggregations and aggregated resources
> themselves by depositing resources against Entries (possibly via the Proxy
> URI or something derivable from it).
>
> We've not yet started this phase, but will report back on what happens when
> we do. (July or so)
>
> Hope that helps,
>
> Rob
>