This next version of SWORD is about giving the client the tools that it needs to give users a rich and compelling experience. It aims to introduce aspects which provide the client with a more certain understanding of what the repository has done with the content, with well defined identifiers allowing for follow-up action which improves the interactivity of the repository.
This paper has described the two major developments that the SWORD 4 project plans to undertake:
- To add stricter semantics to existing identifiers in the deposit receipt, and to add two further identifiers useful to repositories;
- To specify a default manifest serialisation which can describe the content of repository items and provide basic information about state.
We have still not answered all of the limitations we discussed at the start of this paper, although we have shown that these two additions to the standard lead us towards a more complete treatment of deposit lifecycle management. The things that we have explicitly missed out at this stage include: how authorisation and authentication works for operations other than deposit, and how it might work on modifying the parts of a package some time after deposit; how we explicitly bypass packaging and deal with single file deposits only; and how we more accurately describe or prescribe the package formats used for deposit. These are all issues which SWORD will be able to address in future versions.
The details and practical implementation of these developments are presented in this paper as a suggested approach, and by no means definitive; instead they are derived from apparent best practices already in use in the repository community, and in the perceived needs of the repository to play well in the ecosystem of information systems. The objective of this paper is to make these proposals to the community and to solicit feedback on improvements, alterations and limitations. By producing an open source reference implementation for general review by the community, it also will be possible to see what the consequences of these suggestions are, and how they can be used to improve the state of play in repository deposit.
Thanks for the feedback – we’re cleaning up all future docs to just talk about SWORD v2.0.
The SWORD 4 mention caught me off guard as well. It might be nice to standardize on the Spec version numbers or somehow clarify this. Unless you really understand the various numbering schemes, you end up confused when you see mention of SWORD 3 project and SWORD 4 project in a document about SWORD v2.
Sword 4?
Hi Ross, There are two numbering conventions used which is slightly confusing and we’ll need to be careful to differentiate between them. There is the numbering of the JISC-funded projects (1, 2, 3, and this would be the 4th), and the numbering of the SWORD standard (1.0, 1.1, 1.2, 1.3 (the current one) and 2.0 which is what this white paper describes).