SWORD telephone meeting 2007-05-11

From DigiRepWiki

SWORD Home | SWORD Wiki | SWORD Project Background

Contents

[edit]

SWORD Project telephone meeting 11th May 2007

[edit]

Attendees

  • Julie Allinson (JA)
  • Stuart Lewis (SL)
  • Martin Morrey (MM)
  • Neil Taylor (NT)
  • David Flanders (DF)
  • Jim Downing (JD)
[edit]

Notes

The aim of the meeting was to go through the evaluation of the Atom Publishing Protocol and its applicability for the SWORD project.

VOTE: At the start of the meeting all five technical attendees were neutral about the use of APP, none were entirely against or for it.

MM mentioned that tools and projects would support its use (e.g. https://rome.dev.java.net/ and http://incubator.apache.org/abdera/).

Discussion covered the following topics:

  • Authentication - agreed that HTTP authentication is feasible and it would be up to the developers to expose existing authentication solutions to this. Shibboleth may be problematic as it requires a user and browser, but could be flagged as a future issue, e.g. for the depot (this kind of multiple deposit is not in their current scope). onBehalfOf would also be encrypted under https.
  • Mediation - this would be possible by using a parameter in the HTTP header (see examples supplied by MM: Examples). It might be possible to model the user as having collections of their own, that others could have permission to deposit to.
  • Workspace - agreed that the workspace should be an arbitrary grouping, for any kind of aggregation. Agreed that it should not be used for repository-level metadata, which would be supplied only as part of a collection element. Agreed to drop the suggested use of extensions within the <app:workplace> element.
  • Collections/categories - there might be some crossover with oai-pmh sets. Agreed that it would not be the case that members of a collection identified by foo/collection/ would inherit the foo/collection/ semantics. Any implementation would be expected to offer one or more collection. Deposits would be made into one collection only. Deposit to multiple collections (within the same repository) or use of virtual collections are out of scope for this project, but should be flagged. Categories might be used in future for classifications or similar.
  • Developer extensions - agreed that these should be an optional extension.
  • Checksum support - agreed that we do need to support checksums, some question over how to do this (there is facility for supplying MD5 checksums in the http header).
  • Identifiers - app would push repositories towards using URIs, this could be a good thing, although there may be resistance to those who have committed to other kinds of identifiers. It is also the direction that ORE are taking at the moment and it works. URI is 'expected' to resolve.
  • APP 'Media Resource' (9.6) or 'Comment' (9.3) - the assumption has been to use 9.6 for the deposit, although there is potential for using 9.3. 9.6 includes a mandatory 'media link entry' supplied as the Location in the http header, although there is no explicit statement that this must persist, certainly this couldn't be the case for Level ) implementations. Agreed that the SWORD profile would need to provide a recommendation for what this URI should pint to, jump-off page, user workflow page?. Receipt metadata passed as part of the transport layer.
  • Status and error codes - Agreed to work with existing http codes at present.
  • Formats - is it enough to use mime types? in time, the packaging standards (ims, didl etc.) may define their own mime types, but there is currently no scheme for this. This may come out of ORE or related work. There is also an issue of local profiles for didl, mets and, to an extent, ims. Agreed that an extension along the lines of the oai-pmh metadataPrefix may be useful. For level 1 implementation is it crucial to know whether a repository can accept what is being pushed at it? Agreed that this is an issue. Noted that Ramlet and possibly some DRIVER activity are looking at mappings, but aren't providing a service at present.
  • Metadata - agreed that metadata will be part of the deposited package and kept entirely separate from any transport metadata.
  • General comments - agreed that using something that is 'popular' can be a good thing and app has the benefit of being in line with the web architecture, in a way that oai-pmh is not. Google are also very interested in it. Might be useful to recommend use of foo/atom as a service entry point.

Agreed that we need to create a domain-specific profile of atom, a deposit subset. This might be attractive for others who only want to deposit. This profile needs to be well-documented and our use and non-use of atom elements clearly stated, with examples.

VOTE: At the end of the meeting all five technical attendees were in favour of using a profile of APP.

[edit]

Actions

  • Create new document for the SWORD APP Profile 0.1 (JA - done)
  • Create stubs for different sections, assign responsibilities; sections to include examples.
  • Popular the SWORD APP Profile 0.1.
  • Produce an annotated version of the app rfc document, indicating SWORD usage and extensions.
Retrieved from "/repositories/digirep/index/SWORD_telephone_meeting_2007-05-11.html"