SWORD [1] has, since its inception in 2007, become a very high profile JISC [2] project which has had a huge impact on the repository community. It was set up to tackle the problem of how to allow repositories to interoperate, and how to enable them to be embedded into other information systems. This is not an insignificant challenge, and SWORD chose to tackle it by concerning itself with the simplest possible use case that was still of value: the deposit of a package of content, both files and metadata, into a repository system which would then acknowledge the deposit with a receipt.
To achieve this, SWORD has had to take into account, additionally:
• The fact that repositories often cluster their content into “collections”, into which deposited content must go [SWORD spec section B.8];
• How to indicate to the repository what the format and contents of a package are [SWORD spec section A.1];
• Authentication and authorisation, and specifically supporting the “On Behalf Of” deposit use case [SWORD spec section A.2].
It has been, therefore, a significant amount of work to take this first step along the road to
interoperability.
Using open standards, open source software development and an inclusive approach to the specification a community has been able to grow around SWORD. There are several open source client and server implementations: it is supported natively by DSpace[3], EPrints [4] and Fedora [5], arXiv [6] and a number of commercial systems such as Zentity [7] and IntraLibrary [8]. There is a Facebook deposit application [9], Microsoft have developed an addon to Word which will deposit your documents into your archive [10], and likewise the Open Journal System (OJS) [11].
The repository is no longer a standalone entity dependent on its own isolated architectural choices, but part of an increasingly complex and interconnected environment of scholarly infrastructure systems. To play their role appropriately in this environment it is necessary for repositories to offer sophisticated and appropriate APIs that can be used by their peers to utilise their services. Here, SWORD has a role to play, but there are some limitations in its current state which we will enumerate here in order to see where we must take it next.
[1] SWORD: Home page: http://www.swordapp.org/ ; Specification: http://www.swordapp.org/sword/specifications
[2] JISC: http://www.jisc.ac.uk/
[3] DSpace: http://www.dspace.org/
[4] EPrints: http://www.eprints.org/
[5] Fedora: http://www.fedoracommons.info/
[6] arXiv.org: http://arxiv.org/
[7] Microsoft Zentity: http://research.microsoft.com/en-us/projects/zentity/
[8] Intrallect IntraLibrary http://www.intrallect.com
[9] Facebook SWORD App by Stuart Lewis: http://fb.swordapp.org/
[10] Microsoft Word SWORD Add-in. Presentation from OR10: http://research.microsoft.com/en-us/um/redmond/projects/authoring/090518-pablofe-connecting%20authors%20and%20repositories%20through%20sword.pptx ; Video Tutorial: http://www.youtube.com/watch?v=2_M2gfUyVzU
[11] Open Journal System, SWORD plugin: http://pkp.sfu.ca/wiki/index.php/Ojs_plugins#SWORD_1.2_Repository_Deposit
I think rather than extend SWORD, standardise SWORD v1, and if you need these extra features, build on OASIS CMIS instead – which also extends Atom to support enterprise CMS and has all these other capabilities. So SWORD 1 = profile of AtomPub; SWORD 2 = profile of CMIS. Could save a lot of time and effort that way.
http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
The key limitation of SWORD is that v1.0 hasn’t been finished. Get the existing specification onto a sound footing with its governance and IP sorted out before going and adding new features or a new version. Complete the submission of SWORD as an IETF RFC for example.
If there is a need for a v2.0, address the governance and licensing issues before delving into the feature set.
#3: SWORD is a transport mechanism, it should not restrict itself to transport “for known user accounts”. Example [from the Article-centric World]: The publisher as a source of deposits – they won’t know the user ID for the authors of the item, so they cannot deposit “on behalf of”
Ok, so after reading the entire intro I still have no idea what use case or problem SWORD2 is trying to solve? I don’t doubt that it might be worthwhile… I just don’t know what “it” is.
In response to Ross. I concur, if more platforms simply implement CRUD via REST. Then shouldn’t SWORD simply recommend/specify supported packaging startards rather than the protocol itself?
SWORD – Simple Web-service Offering Repository Deposit. By this paragraph is SWORD now being touted as something else. Will it become full interoperability or remain about Simple Deposit with the added benefit of update/delete as outlined in the abstract.
Point [1] – Only valid for DSpace, and as far as I know this is a piece of metadata, not a “special” piece of metadata. Should still be viewed as a piece of metadata.
Point [2] – A useful extension which can be superceeded by ORE as long as you can locate the ORE document (manifest) in the “package”
Point [3] – No arguments there, that is useful however could also be viewed as a piece of metadata. e.g. deposited by an editor but the author can still view non-public info and make changes? Thus you could get this data from somewhere else allowing the repository to store content about users it doesn’t yet have knowledge about (an account)
Is SWORD applicable in the broader “deposit” space? That is, why is there a focus here on “repositories”?
Can this standard be usefully applied to other content spaces, e.g. Enterprise Content Management Systems?