Talk:SWORD

Implementation Steps[edit]

Step 1:

Implement SWORD level 0
Provide Service document for PubMan
Enable deposit for PEER Project

Step 2:

Implement SWORD level 1
Provide Service document for PubMan
Enable deposit to all collections
Enable edit
Enable delete (withdraw)

Step 3:

Provide SWORD client functionality (submit escidoc items to other repositories)

Would like to propose a bit different staging in here. There is an article from D-Lib that provides information on the level of compliances, see D-Lib article figures . However in latest version of the SWORD APP the notion of level of compliance is removed, therefore, the level of compliance is 1.

Would propose to implement the following for Step1 (see Proposal for service settings) document:

Provide service document for PubMan, that returns information depending on user credentials
Enable deposit to all collections
Do verbose
Do not allow mediated deposit on behalf of other user
Allow METS (or 1 other format) as accepted format (ps. here is an ongoing discussion in PEER, tbd.)

Question: Do you consider to adapt the current PubMan submission masks to use the SWORD API as well? According to our experiences with other software, it's often hard to maintain APIs (i.e. to ensure that they are full functional) if they are not used by a mature service --Inga 22:01, 5 April 2009 (UTC)

SWORD server API is mapped to pubman depositing component (and later on transformation service) to my understanding. Present implementation actually only works with eSciDoc item xml format and publication metadata. This will be extended. --Natasa 16:17, 7 April 2009 (UTC)

Supported Use cases[edit]

What is the concrete use case, PubMan/eSciDoc would like to support?

SWORD server[edit]

The scenarios (and the first in particular) are not clear to me because PEER is not a project which will create any content to be deposited in PubMan. Are you considering a work flow where a publisher deposits content published under a specific model (e.g. Springer Open Choice) to the institutional repository? In that case it might be a good idea to talk to the other department though --Inga 13:10, 10 March 2009 (UTC)

In fact PEER will create a lot of content that is to be deposited in PubMan and in special Peer context. The workflow of PEER project is: Publishers deposit to main PEER Depot, Half of these are pushed into all PEER participating repositories (e.g. MPG, SUB-Göttingen, others). For the other half, authors themselves receive email from publishers and are invited to submit data either to own repositories or to one of Peer participating repositories. --Natasa 08:37, 11 March 2009 (UTC)

Natasa, thanks a lot for providing further information. This kind of MPDL engagement is not described under Third_Party_Funded_Projects#PEER_.28Publishing_and_the_Ecology_of_European_Research.29, but I'm happy to hear that the content aggregated within the PEER project will become available in the MPDL environment... that will provide me with access as well :D --Inga 12:52, 11 March 2009 (UTC)

Is not in, because the list of participating repositories was not known until recently. Now it is known and MPDL is one of them. However, most probably we will set-up separate PubMan instance and repository, as long as it is not clear which publications (MPG scope or wider is in pubman). These articles are not only from MPG authors, but any European authors. --Natasa 09:07, 12 March 2009 (UTC)

Meanwhile, the Peer project published a draft report on the provision of usage data and manuscript procedures which includes some additional information on the scenario, --Inga 17:39, 23 April 2009 (UTC)

SWORD client[edit]

In any case, if scenarios for automatic submission to discipline-specific repositories could be supported, of great value within MPG...but still have not understood how different privileges and workflows are solved. --Ulla 12:52, 26 February 2009 (UTC)

There is nothing special upon this issue, SWORD is only a protocol. The actions of this protocol are actually mapped (and executed) to actions of our standard depositing workflow. --Natasa 08:42, 11 March 2009 (UTC)

Inbound deposits and privileges[edit]

For inbound deposits: How to solve different privileges, workflows and validation rules?

User/Client need to authenticate and this defines the set of allowed actions, e.g. in which context new resources can be created or which resources can be modified. The SWORD server returns an HTTP error code (+ optional: human-readable explanation of the error) if the request action can't be executed. --Inga 22:19, 2 March 2009 (UTC)

BTW, the SWORD profile refers to Oauth protocol as potential mechanism for authorization: "The mediation technique described by SWORD is not intrinsically secure - it is assumed that trust between the owning user and the mediating user will be established by extending SWORD, or outside the scope of a resource creation, using a mechanism such as that described by [OAUTH]", see http://www.swordapp.org/docs/sword-profile-1.3.html

The workflow and validation rules are anyway bound to the collection, therefore we will not have problems, as the user defines in which collection he wants to deposit. Additionally due to authentication he can only deposit to collections where he has privileges for--Friederike 14:55, 9 March 2009 (UTC)

Fedora support of SWORD[edit]

Fedora already supports SWORD, to what extent?

to extent of creating single Fedora objects imho. In our case we can not use it directly. --Natasa 08:12, 1 April 2009 (UTC)

Implementation of SWORD server[edit]

Is this part of syndication manager, as it supports atom anyway?

atom as syndication format is only half of the atom publishing protocol.--Robert 22:02, 2 March 2009 (UTC)

Where to implement this protocol? new service?

Decided in AB meeting that every solution will implement its own SWORD Server--Friederike 14:55, 9 March 2009 (UTC)

I would like to make a small correction. The SWORD server implementation is one single server implementation, each solution may provide different SWORD service documents - thus the internal depositing logic will be dependent on the service documents. --Natasa 08:40, 11 March 2009 (UTC)

Is the SWORD protocol we would like to implement something that can come as solution-independent, or each solution needs to have own service document (instance) to support solution-specific workflows?
- As i understood we implement the atom publishing protocol which should be equal for all solutions and then write transformations to actually import data (atom publishing protocol to escidoc pubItem).

was thinking on different workflows and collection (context) policies primarily. But by more careful checking it is possible to have separate service document description for each solution in fact. --Natasa 12:34, 4 March 2009 (UTC)

Edit/Delete are optional operations for implementing SWORD. Even if we allow Edit, we should not allow for Delete (or Delete should actually do Withdraw?, as my understanding is "Deposit" will make immediate release --Natasa 16:10, 3 March 2009 (UTC)

Added action mapping according to your ideas--Friederike 16:05, 9 March 2009 (UTC)

Alternative proposal for service settings[edit]

After some reading on SWORD
- first stage we could integrate it to actually support our import metadata formats
- second stage we could integrate it to support SWAP (Scholarly Works Application Profile)
- use-case to check for arXiv
two-folded implementation of SWORD
- for deposits to PubMan
- for deposits from PubMan to Target repositories e.g. arXiv

Proposal for supported service document[edit]

SWORD Element	Description	Proposed setting
sword:collectionPolicy	Used for a human-readable description of collection policy. Include either a text description or a URI.	can come from collection description, or SVM as fixed
sword:treatment	Used for a human-readable statement about what treatment the deposited resource will receive	"Zip archives recognised as content packages are opened and the individual files contained in them are stored. All other files are stored as is."
sword:formatNamespace	Used to identify the content packaging types supported by this collection. SHOULD be a URI from SWORD-TYPES	SWORD-TYPES we can focus on METS as XML (with base64 encoded content), or METS as zip package
sword:verbose	If a server has support for verbose output (detailed description of internal processing).	Yes
sword:mediation	If the the SWORD server supports on-behalf-deposits	No
sword:noOp	No
sword:userAgent	client identification
sword:acceptPackaging		METS ... not sure if should be stated as http://purl.org/net/sword-types/METS
sword:packaging		see docu, i think in this case will be same as acceptPackaging?
sword:version	Version of implemented protocol	1.3
sword:error	The description of the error can be found in the href attribute	http://purl.org/net/sword/error/ErrorContent http://purl.org/net/sword/error/ErrorChecksumMismatch http://purl.org/net/sword/error/ErrorBadRequest http://purl.org/net/sword/error/TargetOwnerUnknown http://purl.org/net/sword/error/MediationNotAllowed
sword:maxUploadSize	5MB (FIZ recommendation if we use inline binary data in METS, otherwise no limit for files, limit for MD record only