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 firstname.lastname@example.org 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 email@example.com 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 firstname.lastname@example.org
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.
A new copy of the proposed SWORD v2 specification has been posted based on recent feedback from the Technical Advisory Panel:
The main changes that were made are as follows:
1/ Changed all relevant instances of URI to IRI.
2/ Provided a better introduction with text from the business case/technical approach document.
3/ Corrected the identifiers to which 6.6.2 and 6.6.3 referred.
4/ Added 2 new sections covering overwriting metadata or overwriting with Atom Multipart (sections 6.5.2 and 6.5.3), which were missing from the previous version.
6/ Removed the use of 202 (Accepted) as an HTTP response code to any request.
7/ Better introduction to the Metadata Handling section.
8/ Removed usage of In-Progress header on IRIs which do not represent the container (i.e. the Atom Entry).
9/ Better introduction to the Continued Deposit section, and the addition of a section on how to complete an In-Progress deposit.
10/ Added a new IRI type which is called the SE-IRI (SWORD Edit IRI) which is identified by the @rel value “http://purl.net/org/sword/terms/add”, and is used to identify the IRI which can be used to do HTTP POST against for adding content to a container. I updated all the references for HTTP POST operations to refer to this IRI, and added it and an explanation of its relation to Edit-IRI near the top of the document. Note this doesn’t strictly add a new IRI to be maintained, the atom:link can still point to the Edit-IRI, but their usage is distinguished as per the previous discussions on this list.
11/ Changed the rules for default packaging so that in the event that a server does not announce any packaging, the client will assume that none is supported. I believe this means that SWORD now fully simplifies to plain old AtomPub without confusion.
12/ Changed the old IRI which represented the zip package to be http://purl.net/org/sword/package/SimpleZip, which is more descriptive.
There are still some comments on the list which haven’t been addressed. These will be looked at next in tandem with an effort to
start the development of the clients and servers, as we feel that there’s not a lot more we can get out without first having a go at the implementations.
There are just a couple of questions regarding the latest changes:
a/ Are there any obstacles in the spec to using another APP based protocol in parallel. We are thinking CMIS and GData, obviously, but
also perhaps others like OData. It’s important that SWORD not prove an obstacle to them.
b/ Are there any other @rel values that we need to create to accurately describe SWORD specific operations which aren’t purely APP operations? Looking over the profile when writing this version of the spec, it was only the SE-IRI that we picked up. Have we missed anything?