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

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

Hi Jim,

"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.


"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.

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?

In section 14, there's a typo: "SHOULD MUST"

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.

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.

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.

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.

Scott.