Dec 232010
 

This is the third in a series of blog posts outlining the SWORDv2 project plan.  This blog post details the proposed timeline of when each work package will take place.

The project is split into two phases, an initial research and specification phase, followed by a development and test phase.  During this time a second stream of advocacy and general community management will be undertaken.  There will also be a stream of work for project support.

Phase One: November 2010 – January 2011

  • Technical
    • Work package 1: Compile use cases
    • Work package 2: Analysis of white paper
    • Work package 4: Creation of prototype SWORD v2 specification
  • Community
    • Work package 3: Initial community formation
  • Project support
    • Work package 10: Project dissemination
    • Work package 11: Project administration

Phase Two: February 2011 – April 2011

  • Technical
    • Work package 5: Server implementations
    • Work package 6: Client implementations
  • Community
    • Work package 7: Instructional documentation and ongoing community management
    • Work package 9: Support the JISCDepo projects
  • Project support
    • Work package 8: Develop a sustainability plan
    • Work package 10: Project dissemination
    • Work package 11: Project administration
Dec 232010
 

This is the second in a series of blog posts that is outlining the project plan for the SWORDv2 project.  This post will describe the work packages that will be undertaken over the next 6 months to complete the project.

Work package 1: Compile use cases

  • The project will work with the SONEX group to gather, document, and publicise relevant use cases that fit with the overarching principles of SWORD v2. These use cases will be used to ensure that the SWORD v2 standard meets the requirements of the repository community.  In addition the community manager will ensure that the repository manager community is made aware of the project, and is encouraged to participate in the collection use cases.

Work package 2: Analysis of white paper

  • As a concluding part to the SWORD 3 project, the Technical Lead wrote a white paper that outlined the potential requirements of the SWORD v2 standard. This white paper was given wide publicity at the Open Repositories 2010 conference and was placed online on the JISCPress site (http://sword2depositlifecycle.jiscpress.org/) for comment by the community.The feedback received from the community needs to be analysed, and once combined with the use cases from the SONEX group it will be written-up to create a document that will define the use cases, requirements, and outputs of the SWORD v2 project. The document will be used to describe to the community what the standard will do and why it will do it, and will give rise to the standard itself in work package 4.

Work package 3: Initial community formation

  • While the analysis of the white paper is being undertaken the Community Manager will need to perform work to start to form an initial community around the SWORD v2 work. This first phase of community building will be centered around publicity of the project including a project web site and blog (to supplement the current swordapp.org site), an elevator pitch to explain the aims of the project to the community, and the creation of an effective communications channel to allow dissemination, discussion and feedback to easily take place.A technical advisory panel will be created that consists of project staff members, and developers and repository managers from the worldwide repository community. They will come from a cross section the different repository platforms and user types. Whilst all aspects of the project will be open for comment by any interested party, the technical advisory panel will be consulted closely at all times to ensure the project is meeting the requirements of the repository community.

Work package 4: Creation of prototype SWORD v2 specification

  • Following the analysis of the white paper, the creation of the report and the formation of the initial community, a prototype SWORD v2 specification will be written. The specification will detail the SWORD v2 protocol to a level where it can be discussed, evaluated, and implemented.The specification will be considered a draft as it is envisaged that during the later implementation phase that the specification will change in light of user experience and evaluation.

Work package 5: Server implementations

  • Once the prototype specification has been written, a server implementation will be required. This will be used in conjunction with the client implementations (work package 6) to test the specification and evaluation it against the use cases and requirements as specified earlier in the project.  The server implementations should attempt to provide some mechanism by which client requests can be validated.  All resultant code will be released with a suitable open source licence.Three server implementations will be created, one each for DSpace, EPrints, and Fedora.  If appropriate and possible, other server implementations will be encouraged with technical support from the project.

Work package 6: Client implementations

  • Once the prototype specification has been written, client implementation will be required. This will be used in conjunction with the server implementations (work package 5) to test the specification and evaluation it against the use cases and requirements as specified earlier in the project.  The client implementations should attempt to provide some mechanism by which they can be used to validate a sword endpoint.There will be 4 client implementations created, to offer a highly heterogeneous environment within which to test the use cases and requirements.  They are also designed to offer a series of multi-language software libraries for easy use within other systems not dealt with here. All resultant code will be released with a suitable open source licence.  The clients will include Java, PHP, Ruby and Phython code.

Work package 7: Instructional documentation and ongoing community management

  • In order to be empowered to interact with the SWORD v2 standard the community will require instructional documentation to make use of the proposed new standard. This will take the form of code examples, training materials, and support.The community will need facilitation to ensure it interacts with the standard and the demonstration implementations. This will be achieved through the provision of support, advocacy and publicity of the standard the implementations.As well as ensuring the user and developer communities adopt SWORD v2 and feel ownership of it, the work of advocating, educating and promoting SWORD v1. This will be achieved by maintaining the SWORD v1 website, and by seeking further opportunities to teach ‘The SWORD Course’ at suitable events.

Work package 8: Develop a sustainability plan

  • A viable sustainability plan is required to ensure the ongoing development and maintenance of the SWORD protocol standard,the implementations, and the advocacy.

Work package 9: Support the JISCDepo projects

  • The JISCDepo programme (#jiscdepo) is a suite of projects that work in the area of repository deposit. This work package will support the JISCDepo projects to use SWORD v2 where applicable, and ensure the SWORD v2 standard meets any suitable requirements that they have.The work will be undertaken by UKOLN through the DevCSI infrastructure. In addition to supporting the JISCDepo programme, they will support the use of SWORD in the wider repository programme of projects funded by JISC. If appropriate, the involvement of DevCSI will be used to run a community development event to bring together developers to experiment and develop with the SWORD v2 standard.

Work package 10: Project dissemination

  • In addition to the advocacy and community development of SWORD v2 through the use of the project website, blog, and other activities, the project will also disseminate its findings, the developments it has created, and encourage community interaction by attending major repository events.  Additionally the project will seek to work with existing support networks such as the RSP to deliver training and and advocacy through their programmes of events.

Work package 11: Project administration

  • The project will require standard JISC project management activities to take place. These include formal project plans, reports, budgets, and attendance at relevant programme meetings. Overheads and administration costs will be required for UKOLN to support these activities and the general running of the project.
Dec 222010
 

The SWORDv2 project is now underway.  The next few blog posts will outline the project plan that is being followed.  The first of these blog posts introduces the core team members.  There are three people leading the project, each with a different area of responsibility.  If you ever have any questions about the project, please feel free to contact these people directly:

Technical Lead: Richard Jones
The technical lead is responsible for leading the development of the SWORDv2 standard.  This involves analysing the current standard and its shortfalls, looking at how the standard should evolve, and surveying the technical landscape to ensure that the proposed solution fits with other systems.

Richard has been involved with the technical specification of all the past SWORD versions, and was joint creator of the current DSpace implementation of the SWORD standard.  He has worked extensively with the SWORD and AtomPub standards, and in the area of repository interoperability, particularly between research information systems such as Symplectic Elements and Frida (the Norwegian national research system).  Richard is also a member of the Scholarly Output Notification and Exchange (SONEX) working group, which works in collecting and analysing use-cases surrounding repository deposit.  He is also chair of the DevCSI Developer Focus group, and a founder member of the DSpace Committer group.

Community Manager: Stuart Lewis
The role of the community manager is to foster a community around the SWORD v2 standard to help it evolve, meet the user requirements, encourage implementations and uptake, perform advocacy and training, and create a cohesive community that will take ownership of the standard allowing it to develop in a sustainable fashion.

Stuart Lewis works for The University of Auckland Library in New Zealand as their Digital Development Manager. He has played a major part of all the past SWORD projects, initially by being the joint creator of the DSpace and Fedora implementations, but also by writing clients such as the Java web client, the PHP API, and the Facebook client. More recently he has contributed by creating the EasyDeposit SWORD client creation tookit, and for writing ‘The SWORD Course’ that was first delivered at the Open Repositories 2010 conference to an audience of 55 international participants.

Stuart blogs regularly about SWORD developments (http://blog.stuartlewis.com/tag/sword/) and has co-authored two papers concerning SWORD:
- Allinson, J., François, S., Lewis, S. SWORD: Simple Web-service Offering Repository Deposit, Ariadne, Issue 54, January 2008. Online at http://www.ariadne.ac.uk/issue54/allinson-et-al/
- Lewis, S., Hayes, L., Newton-Wade, V., Corfield, A., Davis, R., Donohue, T., Wilson, S., (2009) If SWORD is the answer, what is the question?: Use of the Simple Web-service Offering Repository Deposit protocol, Program: electronic library and information systems, Vol. 43 Issue 4, pp.407 – 418. Online at http://hdl.handle.net/2292/5315

Project Director: Paul Walk
The project director is responsible for directing the overall direction of the project, and acting as a contact point between the project funder and the project itself.

Paul Walk has worked predominately in Higher Education in the UK since the early nineties. Starting in the academic library service at the University of North London, he went on to develop Web and intranet systems and take the technical lead in establishing the University’s VLE service in 1997. Paul has been involved in many community and standards activities, notably with JA-SIG, the International DOI Foundation and IMS Enterprise, and was one of the founders of the XCRI specification for course descriptions which has been adopted widely across Europe. Paul joined UKOLN at the University of Bath in 2006 and became Deputy Director in 2010, in which role he has oversight of research and development. He has guided the development of UKOLN as a JISC Innovation Support Centre and the founding of a sustainable community of developers in HE through the JISC-funded DevCSI project.

As well as the three core project staff, there is a small team of technical experts who will perform implementations of the SWORDv2 standard, and a Technical Advisory Panel who will help guide the development of the standard.  More introductions will take place in future blog posts…

Dec 092010
 

As part of the ongoing SWORD development process, we’re hoping to bring you a set of short case studies demonstrating the wide variety of different resource deposit use cases that SWORD enables.  In the first of these case studies, we have a quick chat with the technical architect for the Public Knowledge Project, Alec Smecher.

Alec is the lead developer of Open Journal Systems (OJS), Open Conference Systems (OCS), Open Harvester Systems (OHS), and the PKP Web Application Library (WAL).

SWORD: Alec, could you give us a bit of background about what OJS is, and why it was developed?
Alec: Open Journal Systems is a journal management and publishing system that has been developed by the Public Knowledge Project through its federally funded efforts to expand and improve access to research.  OJS assists with every stage of the refereed publishing process, from submissions through to online publication and indexing.  Through its management systems, its finely grained indexing of research, and the context it provides for research, OJS seeks to improve both the scholarly and public quality of refereed research.

OJS is open source software made freely available to journals worldwide for the purpose of making open access publishing a viable option for more journals, as open access can increase a journal’s readership as well as its contribution to the public good on a global scale.

SWORD: How and why did you decide to use SWORD with OJS?
Alec:
Our SWORD support came about via a bit of proof of concept funding from the Committee on Institutional Cooperation (CIC) for a project called the Big Digital Machine (BDM).  We worked with DuraSpace and cnx.org on interoperability so that the apps could feed each other data via SWORD. For example, OJS can deposit to Fedora or DSpace for archiving, or into cnx.org as a way of spinning a journal article into textbook content.

SWORD: What different options do OJS administrators have for making use of the OJS SWORD functionality?
Alec:
We implemented a number of ways for SWORD deposits to work, in the interests of giving users the flexibility to experiment with different models:

  • Administrators can deposit articles at any time
  • Authors can deposit pre-prints into their own institution’s repository when they’re accepted by the journal (green road open access)
  • Authors can deposit into Journal Manager-specified deposit points
  • Automatic deposits can be configured so that articles are deposited on acceptance, e.g. for journals backed by a repository for archival purposes

SWORD: And how about the future, where do you think OJS and SWORD interoperability could go in the future?
Alec: Ideologically, one of our primary interests is open access (OA), including so-called “green road”, whereby authors are free to deposit articles into their institution’s repository for public consumption, even though the journal might be subscription-based. This is a good idea but authors often don’t follow through, because they don’t trust OA, or don’t have the initiative, etc.  We thought that semi-automating the process might push them towards green OA — when they receive an acceptance email from a journal, they also receive one from the SWORD facility within OJS prompting them to follow a link to specify their repository’s deposit point and complete the deposit.

Of course, authors will almost certainly have no idea what their deposit point is, so a typical thing to do would be to involve their institution’s librarian — a common practice might be for the journal prepare the email that the author receives automatically to include instructions for them simply to forward it to their librarian.

We just write the software, and are at best at arms’ length from the journals themselves, so we typically have to follow an iterative process with new and experimental tools like this — we’ll make some assumptions, some will turn out to be incorrect, and with feedback from users, we’ll refine things from there. By providing tools without prescribing a workflow, we also ensure that journals will have the freedom to try things that we haven’t foreseen.

If you would like to know more about OJS and its SWORD interface, please visit http://pkp.sfu.ca/?q=ojs.  For further information about SWORD, please explore the rest of the SWORD website: http://swordapp.org/