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

[Jim D. <oj...@ca...>]

Hi Scott,

Thanks for the responses and questions.

2008/8/27 Scott Yeadon <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