I really think so … the SWORD AtomPub Profile [SWORD] Version 1.3. has been translated into Japanese by Sugita Shigeki and colleagues.

http://www.swordapp.org/sword/specifications

Andy Powell has had a blog-writing explosion over the last few days, and a couple of his posts made me both smile and think a bit.  Particularly ‘What Web 2.0 teaches us…‘ where Andy talks about how “Web 2.0 technology democratises production but creative talent and presentation skills remain rare commodities”.  This is interesting, particularly as we had a similar conversation in the Digital Library team recently, about ways of avoiding the copyright and licencing hoops that we have to jump through to deliver images to our History of Art Department.  We talked about art historians, and the Department, maybe investing in a high-quality digital camera to capture images in situ, of architecture, of original paintings in galleries and so forth … wouldn’t that be great for building a collection of useful images for scholars?  Erm, well no, and in saying that I mean no disrespect to members of the Department but our academic staff aren’t professional photographers (in the main) and I doubt that any of them would want to carry all the photographic kit necessary to capture the kind of quality images they want to use.  Nor would they have time to wait for the perfect lighting, or probably have the skills to get all of the necessary fine-tunings and balances right.  We could get a nice collection of ’snaps’ this way and there could be some real value in this kind of lightweight collection, but for serious use, for presentation, study and analysis, we need images of a high and professional quality.  And I’m sure we can apply the same logic to our Music and Theatre, Film and Television Departments.  Yes, there might be value in a performance recorded on an inexpensive device – it may be the only recording we have, but for serious research we need a quality that such devices, and amateurs, simply cannot deliver.  So, I can only agree with Andy’s post, that “there is always a place for do-it-yourselfness”, but we can’t meet all of our needs without the right equipment, skill and professionalism, and we have to accept that one way or another we’re going to have to pay for that.

I’d also argue the same about metadata, that you can only get so far with user-created tags, but that the real value comes when effort is putting into both the creation and the mechanisms for creating metadata.

Following on from the latest OAI-ORE specs being released, Richard Jones and Rob Sanderson have just announced the outputs of their Foresite project:

“The Foresite [1] project is pleased to announce the initial code of two software libraries for constructing, parsing, manipulating and serialising OAI-ORE [2] Resource Maps. These libraries are being written in Java and Python, and can be used generically to provide advanced functionality to OAI-ORE aware applications, and are compliant with the latest release (0.9) of the specification. The software is open source, released under a BSD licence, and is available from a Google Code repository:

http://code.google.com/p/foresite-toolkit/

You will find that the implementations are not absolutely complete yet, and are lacking good documentation for this early release, but we will be continuing to develop this software throughout the project and hope that it will be of use to the community immediately and beyond the end of the project.

Both libraries support parsing and serialising in: ATOM, RDF/XML, N3, N-Triples, Turtle and RDFa

Foresite is a JISC [3] funded project which aims to produce a demonstrator and test of the OAI-ORE standard by creating Resource Maps of journals and their contents held in JSTOR [4], and delivering them as ATOM documents via the SWORD [5] interface to DSpace [6]. DSpace will ingest these resource maps, and convert them into repository items which reference content which continues to reside in JSTOR. The Python library is being used to generate the resource maps from JSTOR and the Java library is being used to provide all the ingest, transformation and dissemination support required in DSpace.

Please feel free to download and play with the source code, and let us have your feedback via the Google group:

foresite@googlegroups.com

All the best,

Richard Jones & Rob Sanderson

[1] Foresite project page: http://foresite.cheshire3.org/
[2] OAI-ORE specification: http://www.openarchives.org/ore/0.9/toc
[3] Joint Information Systems Committee (JISC): http://www.jisc.ac.uk/
[4] JSTOR: http://www.jstor.org/
[5] Simple Web Service Offering Repository Deposit (SWORD):
http://www.ukoln.ac.uk/repositories/digirep/index/SWORD

[6] DSpace: http://www.dspace.org/“

I’ve been at the Open Repositories 2008 conference in Southampton this week, where I gave a presentation on the first day on the SWORD project. The day before the conference, SWORD had already been discussed very positively at a Microsoft-sponsored meeting – Stuart Lewis, one the developers on the project was at that meeting a gave a presentation on SWORD. Throughout the conference, there seems to have been something of a buzz around SWORD and many people are interested in implementing it in their own repositories to support a wide range of use cases. This is very positive, especially as SWORD is about to receive a small amount of additional funding which might allow us to do some of the things people are pressing about.

What seems to have captured people is the lightweight, simplicity and web-focus of SWORD. This is pleasing, since this was our aim from the start – not to create a walled-garden standard for repositories, but something that could be used anywhere and by any system – this is a powerful thing. Sandy Payette described this as “low-barrier deposit” which I think sums this up very well.

Among ideas for what SWORD should usefully do now, are:

• improvements to the SWORD profile and code
• extend SWORD profile to full APP support, in particular to support update/delete
• additional code libraries
• extend, develop deposit tools
• testing with ORE Resource Maps
• … ideas?

At the very least the SWORD development team, led by UKOLN, has an opportunity to get some talented innovators together and to come up with some recommendations for the future of SWORD and deposit interoperability more generally, and of how this might be supported by JISC and the repositories community.

Last week I attended the first meeting of the Research Data Management Forum, jointly organised by the Digital Curation Centre (DCC) and the Research Information Network (RIN). The general aim of the forum is to “improve the quality, reliability, processing, management and accessibility of data of importance to science, technology and society”. The emphasis was on practical collaboration and the assembled group came from a wide variety of places including institutions, data centres and funders. The event kicked off with an opening keynote from Michael Jubb (RIN) which analysed some of the key issues and questions – what are the different types of collection? (research data, community-focussed collections, reference data for larger audiences) Who manages them? (institutions, funders, national services … ) Who uses them? (researchers, data curators, the public … ) What do we mean by data? (computational, experimental, observational … ). He also considered the importance of records management practices in relation to data and asked whether the cost of managing and disposing of data actually outweighs the cost of keeping all of it, and what that means for future usability. Issues of availability, accessibility and usability were seen as paramount. The presentation closed with an examination of notions of citation, credit and reward – Michael asked whether there is any concrete evidence of the value of storing data for re-use and sharing? There need to be real demonstrations of these benefits.

The second day was a mixture of presentation and breakout discussion. Martin Lewis (Sheffield) talked about forthcoming work on an analysis of the research data management community, and Mark Thorley (National Environment Research Council) focussed on providing appropriate skills and effort for data curation activities. I attended a breakout group on the latter where the 5 recommendations coming out of our discussions were broadly:
- understanding the data curation skills gap
- providing education at grass roots for researchers to improve data management practice from the ground-up
- raising awareness
- changing the mindset and culture of researchers by answering the question – what’s in it for me?
- considering industry drivers and government initiatives

Unfortunately I missed the recommendations from the other breakout and final summary, but overall my feeling is that the meeting was successful in bringing together interested parties and from this, generating further focus on strategies for solving the various specific issues raised.

Neil Jacobs, from JISC has also written a very useful summary: http://infteam.jiscinvolve.org/2008/03/21/the-research-data-management-forum/

Stuart Lewis, Sebastien François and I have an article in this month’s Ariadne.

SWORD: Simple Web-service Offering Repository Deposit

It’s a cracking read! Well, hopefully it will offer people a pretty accessible overview of the SWORD project.

After 8 months of work by a fantastic bunch of developers, I am able to announce the launch of the main technical outputs from the SWORD project, which I will do after a bit of introductory preamble … skip to the end if you’ve heard it all before.

SWORD is a six-month JISC-funded project to define and develop a standard mechanism for depositing into repositories and other systems. Why? because currently there is no standard way of doing this. A standard deposit interface to repositories will allow more services to be built which can offer functionality such as deposit from multiple locations, e.g. disparate repositories, desktop drag&drop tools or from within standard office applications. SWORD can also facilitate deposit to multiple repositories, increasingly important for depositors who wish to deposit to funder, institutional or subject repositories. Other possibilities include migration of content between repositories, transfer to preservation services and many more.

Rather than develop a new standard from scratch, SWORD choose to leverage the existing Atom Publishing Protocol (APP), “an application-level protocol for publishing and editing Web resources”. APP is based on the HTTP transfer of Atom-formatted representations yet SWORD has focussed on two key aspects of the protocol – the deposit of files, rather than Atom documents, and the extension mechanism for specifying additional deposit parameters. Also worth noting is that SWORD does not specify the implementation of all of the functionality of APP, rather it supports deposit only, but that shouldn’t constrain implementers who want to support the fullness of APP.

So, to the outputs:

1) a profile of APP which implementers can use to create SWORD deposit clients or SWORD interfaces into repositories, where the client will ‘do’ the deposit and the interface will accept it: SWORD Profile.

2) test implementations of the SWORD interface in DSpace, EPrints, IntraLibrary and Fedora to demonstrate the efficacy of the SWORD approach: SWORD Implementations

3) two demonstration clients which can be used to deposit into the implementations at 2) or into any other SWORD-compliant implementations: SWORD clients

4) code for use with DSpace, Fedora, EPrints and the demonstration client: SWORD downloads

There are still some things to follow from SWORD – case studies from repositories and clients intending to implement SWORD will be produced over the next few months, as well as a final report, but for now, I think that’s quite enough to be getting on with.

  |
Ooo:<sword/>
  |

On Monday this week I was at the kick-off meeting for a new piece of JISC-funded work to specify a Dublin Core Application Profile for images. This follows on from similar work on an application profile for scholarly works (SWAP) that I have been quite heavily involved in. Both pieces of work have been funded by JISC with a view to facilitating the exchange of richer, more consistent metadata between repositories and services, such as the Intute repository search project. In addition, work will be starting soon on an application profile for time-based media and geospatial data. What makes these three different from SWAP is that for each there already exist some pretty well-established metadata standards. For images, for example, there is the VRA Core and this might beg the question, do we really need another metadata profile? What makes this proposed application profile different from VRA is perhaps most significantly that VRA is heavily oriented towards art and cultural heritage images and the long standing services that deal with such images – such as the AHDS Visual Arts who are leading this piece of work. It hasn’t really been applied to images used across scientific and other disciplines and repositories will often have to deal with a mixture. Also, where institutional repositories are beginning to look at the SWAP model which has leveraged the multiple description possibilities of the Dublin Core Abstract Model, a new application profile that follows a similar structure and can describe multiple entities seems appropriate.

The meeting was very interesting and raised a *lot* of discussion points and questions, perhaps more than Polly and Mick from AHDS anticipated! What came through strongly is that it is essential that the requirements and use cases are fully explored before devising the application profile – draft documents were circulated before the meeting and were a good discussion-starter. It was also clear that for images subject is very very important, in fact, in many cases information about the image itself is very much a secondary entity – it is what the image is of that we are interested in. This means that when considering the entity-relationship model, there is an added layer of complexity. VRA deals well with this and there was some discussion about which, out of FRBR (as was used by SWAP) and VRA would prove a better model for basing this profile on. Thinking about this since, we only used some of the FRBR entities for our SWAP model and there are additional entities and relationships surround subject which might enable FRBR to describe image materials pretty well. It occurs to me that where another metadata record for the ’subject’ already exists, it might easily be referenced from a subject entity description, rather than capturing duplicate metadata from scratch. But that’s probably too much detail for now.
I haven’t had chance to digest all of the issues yet, but this work is very pertinent to me as the person responsible for setting up an image repository for the University of York and I anticipate the images application profile being of great use when I’m looking at our local metadata issues. Another this that is quite pleasing for me is that this piece of work takes repositories further into territory where arts subjects have specialist needs and, coming out of the AHDS, we can be sure that these will be fully considered. Where repositories are often seen as hosts for scientific papers and scientific data, it’s nice to see the arts well-represented.

I gave a little presentation about SWAP at the meeting (slides), following Pete Johnston, who has already beaten me to it with his post, who talked about the Dublin Core Abstract Model. Finding myself described by Pete as ‘ruthless’ was a little surprising, but the point being made at the time was very pertinent – figuring out what is out of scope is as important as tackling what is in.

From my corner of the world I’ve actually gone and achieved something this afternoon. I’ve released the official version 1.0 of the SWORD profile.

http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_APP_Profile_1.0

and I’ve done it with only one spelling message in my announcement!

The document is a profile of the Atom Publishing Protocol (APP) . APP is an application-level protocol for publishing and editing Web resources which is based on HTTP transfer of ATOM-formatted representations. It’s currently an Internet Draft but nearing standard status and has generated quite a bit of interest, for example from Google who have defined their own GDATA profile of it.

The SWORD Profile specifies a subset of elements from the APP for use in depositing content into information systems, such as repositories. The Profile also specifies a number of element extensions to APP, defined to adhere to the extensions mechanism outlined in APP. This profile also makes use of the Atom Syndication Format (ATOM) as used in APP, with extensions.

The SWORD project is testing implementation of this profile within Eprints, DSpace, Fedora and IntraLibrary and developing a reference client to demonstrate remote deposit. This work is nearing completion and outputs will be released soon …

Phew. Much credit to the team of developers I’ve been working with on SWORD.

For three days in August I was at Cornell University in Ithaca, New York attending a meeting of the Object Reuse and Exchange acceleration project (ORE). This meeting followed on from the two-day technical committee meeting in New York City in May and means that I have now spent 5 full days discussing this ORE stuff face-to-face alongside a bunch of hours reading, discussing by phone and trying to explain the project to other people. The main ORE project has been running since October last year and I don’t think it would be unkind to say that the technical committee has been struggling with defining the scope of the project and answering the question “just what is it that you are trying to do here?”. The acceleration project, funded by Microsoft and coming at the project’s mid-way point, is probably best described as an injection of steroids to kick start the real technical work that will occupy the next 12 months. Its aim is to produce an alpha set of technical documentation by the end of September which will then be used. The focussed effort of these three days, following on from the two technical meetings beforehand, has been successful in coming up with some concrete use cases, requirements, agreements about the ORE abstract model and ideas about how to serialise this model. Over the next few weeks, a small group will be working very hard to put the results of this meeting into a set of documents that will be ratified by the technical committee.

My take on what ORE is trying to do is that it is creating a bridge between the document-centric scholarly digital library world and the data-centric semantic web community. It’s primary aim from the start has been to provide a mechanism for describing compound information objects, in particular to provide a mechanism for describing their boundaries and identifying the types and relationships of their components on the Web, in a way that can facilitate re-use and exchange in a machine-to-machine way. After much discussion ORE is coming towards consensus on a layered approach that will allow a range of implementers with different requirements and different levels of technical skill to describe and share their resources in more meaningful ways. These range from from creating a simple manifest listing of information components, to a rich description that expresses the types of components, relationships between them and other resources, alongside essential metadata to aid discovery and re-use. Examples of use cases include a digitized book with a hierarchy of chapters, sections and individual pages made available in different document formats; a scholarly paper with a range of different versions available; and a youtube page containing an embedded video clip, user comments and references to related resources. What was gratifying about the meeting was that the discussions and disagreements ultimately helped all of us reach a point of tentative consensus, understanding and agreement. Some of the main agreements that I think could be usefully summarised – as a minimum a resource map should list the components of a compound object in a simple manifest; HTTP URIs should be used to identify the resource map and the compound object; where ‘good’ URIs already exist these can and should be used, but where new URIs are needed these should be created; the resource map may provide richer information about resource types, relationships and other metadata. One thing I was particularly pleased about was the movement away from re-invention, towards using existing standards and formats as much as possible, such as ATOM, RDF/XML, XHTML and Dublin Core.

After so much time spent involved in the detail of this project I find that I’m more excited about what it can offer than ever. I’ve heard various questions – what is it going to do for scholarly communication, really? is it offering anything new? isn’t this just RDF? but I think what is key for ORE is more about the focus it brings to the ‘compound objects’ (or whatever the chosen terminology is in the end!) issue than what it will ‘produce’. Of particular importance, for me, is the need for making resources available via the Web using pre-existing standards and formats, for encouraging adoption of standard mechanisms for sharing, describing and re-using objects, and doing this in way that allows traditional ‘documents’ and semantic ‘data’ to co-exist and benefit each other. This fits well with the work we’re doing with SWORD and with the wide use of RSS/ATOM. Once the lightweight bootstrap ORE specification is available, it will be up to repositories and other scholarly communications tools and systems to enrich and profile ORE for their own communities.