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!

A few days ago it was announced that my preferred hosting provider Slicehost had been purchased by the big hosting company Rackspace. In addition to buying Slicehost, they have also included Jungle Disk in their spending spree. Hopefully this will all be good news for the respective companies, but it has reminded me of a blog entry that I have been meaning to write for a while: “Why I love my Slice”

A bit of background about Slicehost: First-off, Slicehost is a virtual server provider. You pay your money, and in return you get your own virtual server, that is a machine that you can log into, set the root password, and set up as you so desire. So for anyone looking for a simple web host, it might not be the solution you are looking for, but more about that later. Slicehost sell ’slices’ of a real server, so your virtual server is dedicated a proportion of the resources (disk space / memory / bandwidth) of that server. You can choose what resources you need and buy an appropriately sized Slice. Slices are actually sized upon the RAM you want, starting with 256MB, and going up 512, 1024, 2048, 4096 etc.

I own a slice, and have done for nearly a year. But why do I love my slice? Here’s my top 5 reasons:

1. It’s my server, and I can configure it how I like! Just that really, it is my server, and I can configure it how I like! My main use for the server is to provide web hosting and database services for several different domains such as this blog. As well as simple out-the-box type hosting, I can configure Apache and PHP as I desire, to include any libraries and modules that I want. I am a software developer and appreciate that freedom. Not only can I configure the machine how I want, I also get a choice of Linux distributions installed (or reinstalled) for free.
2. I am not just limited to web hosting services. My main use of my slice is for web hosting, but by having a slice I can run other services. The main example of this is the test LDAP service that I run to allow people to test their DSpace repository LDAP settings, although it could be used for other things too. If I so wished I could run any other service I wanted such as mail (although I use Google Apps for this) or DNS (I use GoDaddy for that).
3. I can define my own backup strategy. Any hosting provider of repute will run a decent backup system. However for the most part this is simply to protect themselves in case of severe hardware failure. They take backups for themselves, not for me. So if need to restore a file from yesterday, I can’t do it. Remember, they take backups for themselves, not for me. They may perform a restore, but it’ll be expensive. By running my own server, I can run my own backups. The way I do this is to rsync the important bits of my server to my Mac laptop whenever I’ve made any changes to code or configuration via a script. Rsync only takes the differences, so this is quick and efficient. I then let Apple’s TimeMachine do its job, and backs it up to my local backup system which provides me with backups going back as far as I have disk space for. If I need to perform a restore, I restore the files locally, then rsync them back to the slice. Slicehost do offer a backup solution, but this costs money, and I like my own solution
4. I can experiment and learn. I’m a developer, not a hard core systems administrator - I’m lucky and work with some excellent sys admins who look after most of our systems. But aspects of my job require me to work with Gentoo Linux servers, and I can learn by messing with my slice rather than a production server. I can also do things on my own slice that I wouldn’t be able to do on a work machine…
5. I can run services on my slice which I couldn’t run at work or home. Being able to run whatever services I want is great. One service I also run purely for myself, and is firewalled accordingly, is a Samba web proxy service running on a server in the U.S. This allows me to pretend that I am in the U.S. so that when I encounter web sites that like to change the price to british pounds because I am in the UK, and charge the dollar rate in pounds, I can still pay the cheaper dollar rate. Noting illegal, just being prudent and saving me money!

Oh, if you happen to purchase a slice, use this link

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.

Today we (the JISC-funded Repositories Support Project) launched a new directory of repository related blogs at http://rsp.ac.uk/blogs/

The launch statement says:

The JISC funded Repositories Support Project has today launched a new service - The RSP Blog Directory (http://rsp.ac.uk/blogs/). It provides a list of recommended and informative blogs regarding the repository scene from around the globe. Listed blogs include personal creations from those with firsthand experience of repository management and/or technical development of repository software; blogs for specific repositories, projects and software developers; as well as blogs for groups and societies with an interest in the open access movement and digital curation.

Each entry in the directory has a brief description of what the blog contains, with links to view either the entire blog or just the RSS feed.

Blogs have been arranged into categories by type, and you are able to download an OPML file to view the RSS feeds within your blog reader of choice for a selected category, or for all the blogs listed in the directory.

We hope the directory is pretty comprehensive but if you think there are any blogs missing from this list, please e-mail your suggestion to the RSP team at support@rsp.ac.uk

If you know of any blogs we have missed, please do get in touch!

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!