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!

There is some more good news for repositories that surfaced this weekend (via Peter Suber’s blog and Klaus Graf) about how Google Scholar now highlights results that have open access versions of papers by the addition of a green flag / arrow / triangle.

Google continues its behaviour of showing the publishers version of the paper as the first result, but where it does do this, it also lists the open version next to the title:

This should make Google Scholar much more useful, as one of the common arguments held against it in the OA world is that it puts the publishers version first, even if it isn’t open but there is an open version available. Thanks Google!

As a closing remark, I’ll comment on Peter Suber’s closing remark in his blog post:

Note the first item on the return list for this search:

• “klaus graf”

The green triangle points to a version of an article with a Google address.  Is Google also entering the OA archiving business?

For all we know Google may be entering the OA archiving business, but in this case it is just a PDF hosted on a http://pages.google.com/ ’Google Page Creator’ site (now ‘Google Sites’) which is a simple hosting facility provided by Google to anyone.

This afternoon we (the JISC-funded Repositories Support Project) formally launched ‘The DSpace Course‘ - a creative commons licensed course for new DSpace repository administrators and developers.

There are currently 20 modules, and a Live CD that can be used for the training. The course is designed to be taught by a trainer, and used in a mix-and-match way so that courses can be designed around the attendees and their desired outcomes. Each module has a set of slides and a student workbook.

We’d be glad to receive any feedback on the course in order to improve it!

The press release says:

Today the JISC-funded Repositories Support Project (http://rsp.ac.uk/) have formally launched a modular training course for DSpace - “The DSpace Course“. The course materials have been published with a Creative Commons licence in order to facilitate their re-use.

The course is suitable for DSpace administrators and developers, with the choice of modules being dependent on the people taking the course. The course tutor can mix-and-match the modules to create a custom course. Each module comes with a set of PowerPoint slides, and an associated student workbook. The course has been successfully taught in the UK and Italy.

There are 20 modules in the course, with more modules due to be added soon. The modules include:

 - An Introduction to DSpace

 - How to Get Help

 - Repository Structure

 - Identifiers

 - DSpace Configuration

 - User management and authentication options

 - Metadata Input Customisation

 - Look and Feel Customisation

 - Language Customisation

 - Item Submission Workflows

 - Import and Export

 - Configuring LDAP

 - Upgrading from 1.4. to 1.5

In addition to the course materials the RSP has released a DSpace ‘Live CD’.

The CD allows any PC to be used as training machine with a copy of DSpace pre-installed, along with all of the files required to perform a new installation. 

The CD is inserted into a computer upon boot, and will load a live version of the DSpace software without installation to the hard drive. Upon completion of the training course, remove the CD and the normal operating system will be loaded upon restart of the PC. 

The course materials can be downloaded from:

 - http://hdl.handle.net/2160/615

The Live CD can be downloaded from:

 - http://hdl.handle.net/2160/563

The course has been written by Stuart Lewis (DSpace committer, developer and trainer), Chris Yates (DSpace developer, support provider and trainer) and has benefited from input by Claudia Jürgen (DSpace committer, developer and trainer).

For help and support, please direct all enquiries related to the course to support@rsp.ac.uk.

In addition, the support team may be able to put you in touch with suitable trainers who could teach the course in your area.

A few weeks ago I made a test LDAP service available (read the blog post) in order to allow people without an LDAP service to test their LDAP-related DSpace patches, or to help people configuring their DSpace LDAP settings by showing them an example with the correct configuration settings.

I’ve been working recently to upgrade the LDAP support in DSpace to allow it to support sub-tree searching. At present it can only authenticate users within a single OU, but many institutions separate their users across a large tree of OUs.

So, I have now released a patch that does this, which will either be included in the upcoming DSpace 1.5.1, or will have to wait for 1.5.2 or 1.6 etc.

In order for me to test this I have had to include more users in my test LDAP service which you are welcome to use too! The patch allows you to specify the DN and password of a user who has full read and search rights overs the LDAP tree in order to identify the DN of the user who is trying to log-in. If you have anonymous access enabled on your server you could comment out the user’s details. The patch then uses that DN and the password provided by the user to re-bind to the LDAP server to make sure their credentials are correct. If you want to make use of this service, here are the settings you’ll need:

• ldap.provider_url = ldap://ldap.testathon.net:389/
• ldap.id_field = cn
• ldap.object_context = OU=users,DC=testathon,DC=net
• ldap.search_context = OU=users,DC=testathon,DC=net
• ldap.email_field = mail
• ldap.surname_field = sn
• ldap.givenname_field = givenName
• ldap.phone_field = telephoneNumber
• ldap.search_scope = 2
• ldap.search.user = CN=stuart,OU=users,DC=testathon,DC=net
• ldap.search.password = stuart

There are now nine users, structured as shown below:

As before, all passwords are the same as usernames. 

I hope this is a useful service. Comments welcome!

Some good news for open access repository advocates: It seems that the normal Google search engine has now started bringing the richness of Google Scholar results into the main Google search results. This extra information includes:

• The (first) author’s name
• Links to papers that have cited it
• Links to related articles
• Links to other versions

For me this is great news. When we go out selling repositories to academics, one of our arguments is “your paper will appear in Google Scholar, and other specialist search engines such as Intute Repository Search and OAIster“. However, if we are honest, how many people use these, and I’m including Google Scholar in this, as their first point of call? Not many I suspect.

So getting this extra information into Google is a big selling point as we now get the richness of Google Scholar into our default search service.

This example shows a paper written a couple of years ago by Jon Bell and myself about using OAI-PMH and METS to move items between repositories, and you can see the extra metadata from Google Scholar being shown.

The Repository Mashup Map (http://maps.repository66.org/) has just undergone a bit of a software upgrade. Here are some details:

• A JavaScript spring-clean: The JavaScript which powers the maps (not including the Google Maps code!) has evolved over time from a simple map showing repositories in the UK, to repositories worldwide, with data from multiple data sources, and with multiple filters. The code has now been tidied up and rationalised, which will hopefully make it faster and more efficient, and is about 10% smaller than it was before. For example, rather than holding multiple arrays of the same data but keyed differently for different filters, it is now all stored in one multi-dimensional array. No rocket science here, just a tidy-up.
• Extra filter: You can now filter on the country where the repository is located, as well as the software platform it runs on, and the date it was created.
• Auto-zooming: When you select a filter (e.g. “Show me all DSpace repositories in the UK”) the map will automatically zoom to show just the area covered by the repositories (in this case, just the UK).
• Auto-filtering: When you select a filter (e.g. “Show me repositories in Austria”) the maps update on their own, without you having to press the filter button.

To make my life easier, I also now have a development copy of the maps where I can test upgrades. The URL for this is http://beta.repository66.org/

As always, comments or suggestions on how the maps could be improved are very welcome!