Have you wondered how the SWORD v2 development process has taken place, from humble beginnings in 2010 to the standard today? Richard Jones (SWORD v2 Technical Lead) from CottageLabs explains during a Pecha Kucha session at the 2011 Repository Fringe event #rfringe11
We recently announced one of the clients that the SWORD v2 project has been able to fund (the ‘right-click deposit‘ project). This blog post describes the other project that was funded: “A SWORD-V2 Client for Publishing Open Education Resources (OER) to Connexions”.
Kathi Fletcher is a Shuttleworth Fellow who is focusing on how to foster an ecosystem of innovative tools and services around an education highway (metaphorically) made of open education resources (OER). Part of this involves implementing a SWORD v2 deposit interface for the Connexions repository of OERs. Connexions (cnx.org) is a globally available repository of educational materials that can be freely shared, reused, and adapted.
In order to make the deposit of new OERs into the repository even easier this project has been funded to create a deposit tool that will load and convert word document files into CNX-compatible packages, and then deposit them using SWORD v2. The SWORD interface will then be able to be used to update, augment, and make new versions of the OER modules contained within the repository.
This project will be a good showcase of the applicability of SWORD for all types of content repositories, not just traditional ‘Institutional Repositories’.
We’ll post updates on this blog as the project develops.
This blog post introduces the first of the two: Right-click deposit by Kim Shepherd. The project proposal aims to:
Create a configurable Windows SWORD v2 client which offers quick access to repository deposit via the Windows right-click context menu.
It would be developed with a focus on easy and non-intrusive installation to allow easy large-scale deployments. It will be designed to take advantage of the familiarity most Windows users have with right-click menus and actions, so that users do not have to learn how to use “yet another app”.
Some usage examples include:
- Pre-configure repository/collection settings and deposit any file with one click
- Configure repository settings and select collection at time of deposit
- No configuration, select all options at time of deposit
- Configure a range of deposit profiles which can be selected via the context menu
We’ll post updates on this blog as the project develops.
The JISC funded SWORD v2 project has been working to extend the original SWORD protocol that facilitates the deposit of materials into repositories. Based on the Atom-Pub protocol, SWORD v2 enhances the power of SWORD by taking the existing ability of deposit, and adding the ability to retrieve, update, or delete deposits as they pass through the deposit lifecycle.
In order to increase the number of SWORD v2 client implementations, the JISC have donated over £5,000 to fund new SWORD v2 clients. The majority of this money is being made available in a contested request for projects. We are seeking developers or development teams to submit ideas for creating new SWORD v2 clients, either by upgrading existing SWORD clients, building SWORD functionality into other scholarly communications tools, or developing entirely new deposit tools. In addition a small amount of the money will be used to provide technical support to the winning developers by the original SWORD v2 team ensuring that the projects have access to all the help and support they need.
Entrants are encouraged to make use of the existing SWORD v2 client code libraries. Using the existing client code libraries will lower the development effort needed, enabling rapid, efficient, and cost-effective development. Proposals to add SWORD v2 into existing well-adopted and mature systems are particularly welcome.
To enter, please tell us the following, in no more than 3 pages:
- What you plan to develop
- How this will have a positive impact on repository deposit rates
- Who will be part of the development team, and some information about their skills
- How much money you request to perform this development
- Contact details for the developer(s), including any institutional affiliations
Entries will be judged by a panel of staff from the SWORD v2 project, UKOLN, and JISC. It is anticipated that 2 to 5 projects will be funded, depending upon the quality of submissions, and the amount of money that each submission requests. The decision of the judges is final, and the project reserves the right not to spend the whole amount of money if not enough entries of sufficient quality are received.
By submitting a proposal you additionally agree to the following:
- The completed project will be delivered within 3 months of being notified of their success.
- The code created will be licenced with an appropriate Open Source licence (to be discussed and agreed with the project), and the source code published online.
- All liability for tax, local or foreign on the money is the responsibility of the developers.
To enter, submit your proposal to email@example.com by 5:00pm Friday 12th August BST. Winners should be announced by the end of August. Proposals are welcome from any country.
We’re glad to announce that the SWORD v2 project has been granted extension funding by JISC. The original SWORD v2 project has been extending the current SWORD standard from its current model of ‘fire and forget’ deposits, to a full CRUD model where items can be updated, replaced, or deleted too. The project will deliver the new draft standard, server implementations for DSpace, EPrints and Fedora, along with client libraries in Java, PHP, Ruby, and Python.
For this extension to the project, the SWORD team is joining up with the SONEX team. SONEX (Scholarly Output Notification and EXchange) have spent the past couple of years undertaking various activities, one of which has been identifying deposit opportunities within the scholarly communications environment. The SWORD and SONEX teams have worked closely together in the past on exploring how SWORD can facilitate the deposit use cases identified by the SONEX work.
The extension project will be split into two halves:
- Explore the applicability of SWORD for dataset deposit
- Develop further clients to increase the adoption of SWORD v2
The first part of the extension project has already started. Projects and researchers who have been working with dataset deposit into repositories are being contacted in order to find out more about the way that data transfer takes place, to see where SWORD could fit in. In particular, projects of the JISC MRD (Managing Research Data) programme are being targeted. Once this work has been completed, a gap analysis of their use cases and requirements will be compared with the functionality offered by SWORD.
Further details of the second part of the project will given in other blog posts in the near future – stay tuned: we’re looking for input in the form of ideas, possible systems to be enhanced with SWORD v2 functionality, and we’ll be seeking funded development parters.
Everyone is home from Open Repositories 2011 now. As usual it was a great conference, and we were once again surprised by how often SWORD is referred to in different presentations.
SWORD was promoted by the team twice at the conference:
- The SWORD Course: The course was presented by Stuart Lewis and Richard Jones. The slides from the course are available online. This year saw the addition of a new module, ‘An introduction to SWORD v2′.
- SWORD v2 debut presentation: This was the first time that SWORD v2 has been presented at a large conference. The presentation was delivered by Stuart Lewis and Richard Jones, and showed the evolution of SWORD v1 to v2, demonstrated the benefits and use cases of the new version, and looked at the implementations that are under development. The slides can be viewed on slideshare.
SWORD also played a part of the Developer Challenge, with a special prize being offered to the the most innovative use of SWORD in an open-repositories context. The prize was won by a group made up of DSpace developers from New Zealand (The University of Auckland Library, and the Library Consortium of New Zealand) and an EPrints developer from the UK, currently living in Korea. Part of their submission involved an Android mobile application they had created that could deposit geo-tagged photos directly into a repository using SWORD.
“Show us the future of repositories!”
This competition will be fascinating, as it will allow repository users, managers, and developers to team up in order to show us glimpses of the future, and how repositories will be playing a role in that future.
This year there is an extra prize for the most innovative use of SWORD in an open-repositories context. In order for repositories to be successful, they need to solicit content. How do you see SWORD fitting into that?
Many of the SWORD team members, past and present, including a lot of the current SWORD v2 project developers will be at the conference. If you’d like to talk about SWORD, get a bit of advice about how to prototype with SWORD, or how SWORD could feature in your ‘developers challenge’ submission, come and find one of us for a chat.
Finally, if you’ve not signed up yet but want to come, we’ll be running ‘The SWORD Course‘ again at the conference, between 8am and 12noon on Tuesday June 7th. Email firstname.lastname@example.org if you’d like to join us.
The Open Repositories 2011 conference is less than 5 weeks away now, so we thought it would be a good time to tell you about about what the SWORD team will be up to at the conference.
SWORD will be represented at two different parts of the conference:
The SWORD Course
If you would like a general introduction to SWORD, then come to ‘The SWORD Course‘ which will take place during the pre-conference tutorials day on Tuesday 7th June. The course will run for half a day, from 8am until 12 noon. This half-day course presents an overview of SWORD from the basics such as use cases and an introduction to web services, to the specifics such as packaging format issues and deposit URLs, to hands-on exercises to create new and customized SWORD clients using a web-based toolkit and the reference implementation Simple SWORD Server. The course is suitable for people from all backgrounds, whether you are a repository manager, repository developer, or interested party.
To book a place on the course, please email email@example.com
Introducing SWORD v2: The Next Generation of Repository Deposit
This presentation will be given during the main track of the conference, and will provide an overview of the exciting work around SWORD v2, why it has been developed, what it will do, and hopefully some demonstrations.
See you in Austin, Texas!
Following a meeting of the SWORD v2 developers earlier this week, development work to implement the proposed SWORD v2 standard has now started. Our aim is to have things to show by the time of the Open Repositories 2011 conference in June this year.
The SWORD v2 standard is not yet finalised, however it is hoped that lessons learned during the implementations will allow the final wrinkles to be ironed out and agreed upon.
Thanks to generous funding from JISC, the project is able to fund multiple repository and client implementations. Each of these will be made openly available, and are listed below. Once development locations or code repositories for these become available, links will be added to this post.
- Client toolkits:
In addition, a Python Simple SWORD Server (http://sword-app.svn.sourceforge.net/viewvc/sword-app/sss/trunk/) has been developed to aid initial testing, and a further automated validation test suite will be developed.
As part of the SWORD v2 developments, the Technical Advisory Panel have been busy discussing many aspects of the proposed new version of the standard. This has been a lively and engaging process. If you would like to read these discussions and contribute any feedback, you would be very welcome!
One particularly interesting thread came from the project’s technical lead. The message concerns the scope of SWORD v2 (what areas it should contribute to, ans which it should not):
There’s been some great discussion on the list this past week or two, and I thought it might be time for a summary of what looks to me to be a key sticking point: the scope of sword.
There are two distinct sides to this argument as it’s been articulated on this list:
a) That we should adopt the approach of content management API like CMIS or more likely GData
b) That SWORD should be not say anything about what happens to the content once it is sent to the server.
In general, I am against (a) for a number of reasons. First, I am concerned that the idioms that are associated with GData are not /necessarily/ appropriate. The hierarchical file system is a common idiom but an idiom nonetheless, and it wouldn’t be SWORD’s place to therefore build itself over the top of it. CMIS I have a harder time refuting or accepting, so am open to persuasion either way. Secondly, I don’t see a reason to re-create a content management standard, since they already exist. SWORD should, instead, provide support for the things that these standards don’t provide for our sector/use cases, while not preventing the use of them.
From a purists perspective of (b) the main thing that SWORD offers, then, is support for Packaging (with a capital P). This is a valuable addition to the community since it is both common in our sector and expressly not covered at least by GData and I believe not by CMIS (though again, open to correction). The support for packaging, though, needs to extend to a full CRUD implementation of AtomPub, which is a large part of what the profile attempts to do. I think we have had some good technical discussion which which will allow the next draft of the profile to do better at that.
In the mean time, there are some grey area parts of the profile, particularly In Progress and Suppress Metadata which are more content management than they are deposit. I, personally, think these are important; they are light touch, the profile doesn’t mandate the server to obey them, and they help fulfill known use cases. Likewise the Statement could be viewed as more content management than not, although we have tried to pitch that as more an informational resource rather than an operational one (i.e. read but not write).
What I’m going to suggest for the next draft is as follows: we’ll put some more time into analysing the appropriate ways of updating and overwriting deposit packages using the feedback on this list. And we will extend the profile to cover how you would use the SWORD headers to be used in content management operations /if that’s what your implementation wants/ (e.g. how you might use Suppress Metadata or In Progress with GData). There will, obviously, be plenty of time for comment.
In conclusion: we must constrain the scope of sword to something which doesn’t tread on anyone’s toes and is of value to the community. Too far one way or the other and we’ll either be superseded or of no value.