Stuart Lewis’ Blog

Within the repositories community we often talk about how to encourage faculty to self-archive their works. We also talk about the problems with repositories, and how repositories are not yet part of the daily toolkit of faculty. In an attempt to see whether bringing these two problems together by allowing faculty to deposit from within a tool that many do use on a daily basis, as part of the JISC funded ‘SWORD 2‘ project I have now created a Facebook repository deposit application.

For the uninitiated, Facebook is a social networking site, where users add other users as ‘friends’, congregate in groups based on their activities and interests, and update the site with small parts of their daily life (uploading photos, saying what they have been up to that day, sending messages to old class mates etc). Snippets of updates from friends are aggregated on the home page of a user so that they can see what their friends have been up to recently. Users are also able to comment on the activities of their friends. Facebook has for some become a site with as much importance as email when it comes to checking messages and updates and interacting with friends and colleagues.

Should we and could we try to leverage this type of system to help populate our repositories?

Being able to deposit from within a site such as Facebook would enable what I’m going to call the Social Deposit. What does a social deposit look like? Well, it has the following characteristics:

• It takes place within a social networking type site such as Facebook.
• The deposit is performed by the author of a work, not a third party.
• Once the deposit has taken place, messages and updates are provided stating that the user has performed the deposit.
• Friends and colleagues of the depositor will see that a deposit has taken place, and can read what has been deposited if they want to.
• Friends and colleagues of the depositor can comment on the deposit.

So the social deposit takes place within the online social surroundings of a depositor, rather than from within a repository. By doing so, the depositor can leverage the power of their social networks so that their friends and colleagues can be informed about the deposit.

One of the features of social networking sites that encourages their use is the ability for third parties to write applications that can be used from within them. So it seemed an obvious place to start an investigation into the potential of the social deposit. Hence the SWORDAPP Facebook Repository Deposit Tool was born. So how does it work? I’ll talk you through a deposit in Facebook:

1) Ensure you have a Facebook account, and that you are logged in.

2) Open the SWORDAPP application by visiting http://fb.swordapp.org/ If you are prompted to grant the SWORDAPP access to your information, do so. This allows the application to know who you are, and who your friends are. By granting this, the application can show your deposits to your friends, and allow you to see the deposits of your friends.

3) Start a deposit! You can start this process by clicking on the ‘Deposit an item’ tab.

4) The first stage of the deposit requires you to select your repository, and to enter your repository username and password. If you don’t have a SWORD compliant repository, but want to try out the application, sign up for an account on our test DSpace installation. If you do so, select the ‘DSpace test server’ as your repository, and then enter your username and password.

5) Once you press ‘Next >’ the application will talk to your repository and find out a list of collections that you are allowed to deposit into. Select one of these by clicking on the relevant ‘Deposit into this collection’ link.

6) The next stage is to enter the metadata for the item you have. The user is required to enter a title, abstract, author, type of publication and whether it has been peer reviewed or not. They can optionally add another two authors, a bibliographic citation, and a link.

7) Pressing ‘Next >’ will take you to the file upload page. Use the file chooser to select the file you wish to deposit.

To complete the deposit, press the ‘Deposit’ button. Your file and the metadata will be zipped up into a deposit package, and deposited into the repository. This may take a little while depending upon the size of the file. Once the deposit has finished, you will be told what the URL of the deposited item is.

If you visit the URL, you will see your deposited item. Congratulations on performing your first social deposit!

In addition to being informed about the deposit, a message will be added to your feed stating that the deposit has taken place. Your friends and colleagues will see this in their friend feed.

Finally, by using the tabs at the top of the facebook application you can see the deposits made by your friends, and by yourself (you can hide these from your friends if you want to, by using the ‘hide’ links).

Time will tell if this method of depositing could help increase self-deposit rates, but please feel free to try out the application, discuss the potential, and highlight any problems. Please contact me or leave comments on this blog post if you have any suggestions, find any bugs, think this is a good or bad way of depositing etc. I’m currently at the SPARC repositories meeting in Baltimore, so if you want to chat about this or see a demo, come and find me. I’d be interested to hear what you think.

Have you ever wanted to try out SWORD, but don’t yet have a repository that supports it? As part of the JISC funded ‘SWORD 2′ project, we have now made available a test DSpace repository at the following URL:

• http://dspace.swordapp.org/

If you’ve not used SWORD before, and want to give it a go, here’s what you’ll need to do:

1. Sign up for an account on the test server by using the following link: http://dspace.swordapp.org/jspui/register (enter your email address, wait for a validation email to arrive, follow the link in the email, enter your name and a password).
2. Find a SWORD client to use. There are lists available at http://www.swordapp.org/sword/implementationsand http://www.swordapp.org/sword/demonstrators - I’d recommend trying out the web client: http://sword.aber.ac.uk/sword/client as this runs from within your browser.
3. You’ll need to know the URL of the service document for the repository. The service document lists the repository collections that you are allowed to deposit into. The URL for the service document for the DSpace demo repository is http://dspace.swordapp.org/sword/servicedocument and the web client should be pre-configured with this URL.
4. Enter your username and password, and press the ‘Get service document’ button. You should then be presented with a list of collections. Choose one to deposit into by pressing the relevant ‘Deposit’ button. If you’re interested in seeing behind the scenes of the responses that the DSpace server has returned, scroll to the bottom of the page to see the XML.
5. When you deposit an item into DSpace using SWORD, it needs to know about the metadata and the file. To combine these they must be packaged together. One of the drawbacks of all the clients to date is that you must have pre-created the package - they will not do it for you. An example package can be downloaded here: http://www.ukoln.ac.uk/repositories/sword/example.zip. Download this package, and save it to your computer.
6. Select this package using the button at the bottom of the deposit screen. You can ignore most of the settings on that page, in this case you don’t need to use any of them. Then you can perform the deposit by pressing the ‘Deposit’ button. You will then be returned a URL for your deposited item.
7. You have now performed your first SWORD deposit!

You’ll have seen from going through this process that a really good client is needed to make SWORD easy to use by all users. The packaging element also needs to be sorted out so that clients can collect the metadata and file(s) and create the package. Clients need to be user friendly, work in the way that users expect them to, and work in the environments that users want them to. The Microsoft Office SWORD deposit tool is a good first example of this.

Watch out for the launch of a new easier to use and more fully featured SWORD deposit client that also deals with the packaging issue in the next 24 hours whilst I’m at the SPARC digital repositories meeting.

Now that version 1.3 of SWORD (Simple Web-service Offering Repository Deposit) has been published, it is time to get cracking with implementing it. One of my roles in the project is to maintain the Java and the PHP SWORD libraries.

One of the nice new features in version 1.3 are error documents. These allow errors to be reported back to the user with more granularity and detail than earlier versions of the specification.

I was originally thinking that these would take me a while to implement, however it turns out to be very easy - 11 lines of code to be precise! (ignoring Java class and method signatures).

The reason for this is that error documents, like deposit entries are just extended atom entries. So seeing as we’ve already implemented AtomEntry and SWORDEntry (which extends AtomEntry), all I had to do was create a new class SWORDErrorDocument that extends SWORDEntry. This gives me (for free) an atom entry with the bells and whistles added by SWORD. All I then had to do was add a few lines of code to set the error reference and to change the top element to sword:error (from atom:entry). Easy-peasy!

Pablo Fernicola (Microsoft) has just written a blog entry about The Microsoft eJournal Service and how this “is a good example of a growing trend towards delivering functionality through the Software as a Service approach“.

Of most interest to me is their continued support for SWORD. As well as the eJournal Service supporting SWORD, they have built SWORD support into Microsoft Office 2007 and their Research-Output Repository Platform.

The blog entry says:

Repositories

At the end of the process, the Editor can configure the service to deposit the articles to different repositories. One of those repositories is ArXiv, which is very popular for Physics and Math content, and is accessed using the SWORD protocol. The service can also be used to deposit to other SWORD based archives. This functionality is also useful for depositing to institutional repositories, and as such, the service could be used to manage the review process for publications such as thesis.

In order to deposit to a repository, you will need a login name and password on the system. The repository may have requirements as to the file formats supported, and their packaging, which you will need to match before submitting.

For folks in BioMed, you can also select to deposit into PubMed Central, and, as noted before, you need to be approved for deposit ahead of time, and have access to the system.

On a related note: The ‘SWORD 2′ project is now starting to get off the ground, and having firmed up the specification for SWORD 1.3, the implementations will soon start appearing. Also part of the project is a new website, and an innovative SWORD deposit client - more on that one in the next week or so!

It has been very encouraging to see two announcements within the last 24 hours from Microsoft regarding SWORD:

The first came in the form of an email from Lee Dirks to the American Scientist Open Access Forum. In the email Lee says:

Microsoft Research and arXiv.org have been working closely on the adoption/utilization of the SWORD protocol and arXiv.org already has a preliminary service up and running.   I would encourage you to follow-up directly with Simeon and Paul for additional detail, but I think the bulk of the work is largely done.

In an important related point, I would like to add that we (Microsoft Research) is actively working on the ability to push from Word 2007 directly to repositories that can consume the SWORD protocol.

And in the second, a blog posting by Microsoft’s Pablo Fernicola gives details of the alpha preview of the Microsoft eJournal Service  (a hosted eJournal management system). In it he writes:

The service is open to all file formats, article submissions can be of any format, as configured as part of the site settings.  On the archival side, the service supports depositing into any Information Repository that uses the SWORD protocol (for example, the ArXiv repository and EPrints based IRs).

These are both encouraging developments for repository interoperability.

I’ve just returned from the latest CRIG (Common Repository Interfaces Group) meeting at Bath University. In typical CRIG fashion the event was held in a bar, where the food and drink flowed freely. The CRIG team ran an excellent event are are now quite used to running useful, informative and thought proving events.

This particular CRIG event was entitled ‘CRIG DRY Workshop’ - DRY = Don’t Repeat Yourself, and today that referred to metadata.

The day started with 5 five minute presentations, one of which was the first public outing for our new project ‘The Deposit Plait‘. This fitted in perfectly with the aims of not repeating ourselves when it comes to depositing items into a repository, and having to typically re-enter metadata.

There are three strands to a plait, and three strands that we hope to weave together in the deposit plait project:

1. Work out exactly what metadata ideally needs to be provided when depositing a scholarly work into a repository. This can be done by seeing who makes use of repository metadata, and what metadata they need in order to do this effectively.
2. Investigate what, if any, metadata can be extracted from XML documents in formats such as OOXML and ODF.
3. See what metadata can be extracted from online or personal bibliographic systems.

So were 1 and 2 to yield useful results, we could investigate the feasibility of writing a web service that take an uploaded document (or a reference to one), extracts some metadata (maybe title, author, abstract) and then uses these to pull in more metadata from other systems. Might be neat, might be a non-starter. That’s what the project will discover.

Anyhow, the event was useful in a number of ways, and there were a number of nice demonstrations. I particularly liked Richard and Rob’s demonstration of depositing OAI-ORE aggregations into DSpace using SWORD. On top of that there was then the resource map encoded in RDFa in the DSpace item page allowing an RDFa reader to use a standard DSpace metadata jumpoff page as an OAI-ORE resource map. The really nice thing about it was that from the DSpace side, it only required a new packager class, and a corresponding entry in the configuration file - I was thinking it might require more tinkering. I also appreciated the ORE talk from Rob. Whilst it only lasted 5 minutes, it was enough to explain the concepts and gave me the dummy’s guide that I’ve been looking out for for some time.

Thanks CRIG!

It was nice to see the announcement recently from the MAMS (Meta Access Management System) project at Macquarie University in Australia that they have implemented Shibboleth authentication for DSpace 1.5. It makes use of the stackable authentication system, and is therefore very nicely integrated with the DSpace architecture.

I’ve been playing with Shibboleth a bit recently, trying to get Blackboard on Windows to work with it. Apparently it works on Unix, but no one knows about Windows. To cut a long story short, I got it almost working. Shibooleth will get our local identity provider to perform the authentication, but unfortunately the IIS Shibboleth ISAPI filter sets the username in the HTTP_REMOTE_USER header, rather than the REMOTE_USER header. Blackboard isn’t configurable enough to look in either. So an enhancement request has been submitted!

Anyway, I was thinking it would be nice to convert our DSpace instance to use Shibboleth authentication rather than than LDAP. The great power of Shibboleth will be when all our systems use it, and we only have to log in to the IdP once. But I hit a snag in my thoughts…

I’ve just told a professor in our university that he could use our SWORD interface to remotely deposit some data that he is creating on a geographically remote server. This means he can periodically automatically archive the data in order to abide by the terms and conditions of the AHRC grant that is funding his work. How would SWORD work with Shibboleth? SWORD works with HTTP basic, and it would be hard to delegate this in the background to Shibboleth. So does that mean I can’t use Shibboleth?

But then I remembered the modular structure of DSpace. Each module (such as the user interface, the OAI-PMH interface, the SWORD interface) is deployed to the application server separately.  Each module can therefore have its own configuration. Normally they would share a single configuration, but I could use different configurations for each one. The normal user interface can use Shibboleth for authentication, and the SWORD interface can keep using LDAP,or what might be even better would be to use the local in-built password system in DSpace so that the professor doesn’t have to embed his university username and password in a script. 

So to conclude - we can use Shibboleth with DSpace whilst still having a working SWORD interface. Nice!