Re: [sword-app-tech] [sword] Fwd: SWORD 1.3

[Scott Y. <sco...@an...>]

Hi Jim,

I think if (referring to Stuart's mail) the User-Agent HTTP header was 
adopted as a means of allowing the server to identify the client, the 
formatNamespace/X-Packaging clarified, and examples of structured 
deposit responses added to the spec that provides much of what we need. 
It would be good to have provision additional context info but we may be 
able to work around that depending on the repository implementations, 
which leads to my next question...

Is development for ePrints/Fedora/DSpace implementations of the APP 1.3 
updates planned as part of SWORD 2? If so, I can help with some of the 
DSpace development if help is needed, else if the developer(s) assigned 
to DSpace could look at providing configurable/pluggable Service 
Document and Deposit Response generators that would go a long way to 
assisting our current and future use cases where the context of the 
deposit will govern these responses. (There are also some notes on other 
changes we would like to see changed in the current DSpace 
implementation at http://pilot.apsr.edu.au/wiki/index.php/SWORD_Report, 
mainly directed at the collection-centric implementation). Happy to help 
with some of the coding if needed.

Scott.

Jim Downing wrote:
> Hi Scott,
>
> Thanks for the responses and questions.
>
> 2008/8/27 Scott Yeadon <sco...@an... 
> <mailto:sco...@an...>>
>
>     "1/ sword:formatNamespace and X-Formatnamespace aren't
>     particularly well
>     named; sword:acceptPackaging X-Packaging seem more appropriate. I
>     erred on
>     the side of not changing things."
>
>     I like your idea of changing the formatNamespace header/element to
>     X-Packaging/acceptPackaging, it's much clearer in its meaning. I
>     think it should be changed in the SWORD APP.
>
>  
> We'd have to either require 1.3 implementations to understand both 
> forms, or lose the forward compatibility.
>
>
>     "6/ Pablo at MS requested a "preferred format" feature in the
>     collection
>     element of the service document, or alternatively a @preference
>     attribute
>     containing an ordinal number. Would others find this useful?"
>
>     I think support for a list of package formats and order of
>     preference may be a useful feature, I'd support its inclusion in
>     the spec.
>
>
> I'll come up with a proposal for discussion unless anyone else wants to?
>  
>
>
>     In section 3.2 is there a typo with the source/generator - the
>     example represents a server response but the generator value still
>     points to the client; should the generator in the response be the
>     server?
>
>
> Yes, it's an error. I'm not happy with the use of atom:source as in 
> 1.2: Atom uses this when entries are copied between feeds, not to 
> record user agent data.  
>  
>
>
>     In section 14, there's a typo: "SHOULD MUST"
>
>
> Noted, thanks.
>  
>
>
>     Some additional comments (others on the list feel free to offer
>     opinions!):
>
>     We have run a pilot project which developed a SWORD plugin for OJS
>     for depositing journals to a repository (report at
>     http://pilot.apsr.edu.au/wiki/index.php/SWORD_Report). The issues
>     I see which are still unresolved in the 1.3 draft are:
>
>     1) A mechanism for communicating deposit contextual information in
>     SWORD requests.
>     To take our journal example - in order for a repository to expose
>     appropriate deposit targets in a service document it needs to know
>     the source application (OJS + version), the content type of the
>     packaged object (journal, issue, article, etc) and the package
>     format (particular flavour of METS). While X-Packaging can tell us
>     the package format I'd like guidance on the appropriate place to
>     indicate the source app (currently we are using the User-Agent
>     HTTP header) and content type (no workaround at the moment).
>     Implementors may also require further information which I suspect
>     would typically be satisfied by using key-value pairs within a
>     context header, e.g. X-Context-Object: type=custom;<key-value
>     pairs> where "type" specifies a URL or string representing the
>     class of context object and "<key-value pairs>" is a set of
>     implementation-dependent key/value pairings which may be used by a
>     SWORD Server implementation for purposes such as constructing more
>     targetted service documents. So in our OJS deposit we get, for
>     example, X-Content-Object: type=journal;source=Open Journal
>     Systems SWORD Plugin v2.2 build 0;content-type=issue
>
>     For implementors the context information is also extremely useful
>     for assisting in decision-making in workflow paths as well as
>     low-level operations such as determining which ingestion/service
>     document/deposit classes to instantiate. So while I appreciate
>     workflows are outside the scope of the spec, I think there still
>     needs to be some mechanism to allow SWORD to integrate with
>     workflows and, at least for our purposes, provision of a context
>     header would go a long way in meeting this need.
>
>
> My gut feeling is that this is a good candidate for an extension, 
> especially if we adopt the AtomPub multipart extension in this / a 
> future revision.
>
>  
>
>
>     2) Support (or maybe just guidance) on supporting structured
>     deposit responses.
>     By this I mean consideration of situations where the depositing
>     app and target repository need to communicate metadata such as the
>     ids/urls of the deposited material, especially where the deposit
>     resulted in a package being unpacked into multiple repository
>     objects. In our OJS example, when I archive a journal issue in
>     DSpace it is unpacked into a single DSpace collection consisting
>     of multiple DSpace items (the issue articles). OJS needs to know
>     what objects were created for auditing, avoiding duplicate
>     deposits and even linking back from the app to the repository
>     versions of the deposited material. The SWORD spec *could*
>     recommend by example a couple of ways of obtaining this
>     information on deposit. For example two sample responses, one
>     showing a single entry pointing to an OAI-ORE resource map (from
>     which the appropriate information could be derived/extracted) and
>     another showing a feed document containing entries for created
>     entities (e.g. http://pilot.apsr.edu.au/public/sword/atom.xml) may
>     satisfy this requirement.
>
>     While technically this is probably outside the scope of the spec,
>     it gives implementors some guidance on how to achieve this in a
>     SWORD context and may provide some consistency in implementations.
>
>
> I think a user guide on this would be very valuable.
>  
>
>
>
>     3) Is it worth considering explicit support for Collection Listings
>     I'm wondering if the issue in point 2) above could be addressed
>     through SWORD including aspects of section 10 (Listing
>     Collections) and section 5.2 (Listing Collection Members) of the
>     APP spec (http://www.ietf.org/rfc/rfc5023.txt). For example, if
>     after a deposit the requestor sent a List Collection Members GET
>     along with an atom:id, a repository (assuming they stored the
>     atom:id) could respond with a feed structure containing entries
>     representing created objects (e.g. see
>     http://pilot.apsr.edu.au/public/sword/atom.xml). This is a
>     slightly longer process than returning a feed structure or link to
>     aggregation resource direct from the deposit but could be an option.
>
>
> I've strengthened the advice to SHOULD from MAY on this. The original 
> motivation for not requiring entry documents and collection listings 
> was to make server implementation as simple as possible. I don't know 
> how important that motivation is now.
>  
>
>     4) Governance of the SWORD Content Package Types (ownership, how
>     to get formats added/registered/etc). Again probably outside the
>     scope of the spec but worth considering.
>
>
> Agree.
>
> Best regards,
> jim
>