As you will have hopefully read in the publicity that has gone out – DSpace 1.6 is finally released! It has been 9 or 10 months in the making, has involved and benefited from a lot of input from dozens of developers, users, and testers, and contains some fantastic new features. It has been a privilege to co-ordinate the release, and I hope it proves a useful upgrade to current users, and a useful product to new users.
But progress waits for no one – the community is already thinking about what comes next! We’ve seen changes in the way development has taken place for 1.6 (see: ‘On DSpace Development‘) and we want to continue to innovate both in terms of the way development is steered, and how it takes place. We’ve got some ‘special meetings’ planned to look at this: how to manage releases and how to manage the release cycle. Exciting times. If you’ve got any interest in DSpace, keep an eye out for these meetings and join in. Associated with this is the call for more committers. If you’re interested in developing DSpace, read the call.
[A small errata from the DSpace newsletter: It states that the ability for item exports to take place via the user interfaces has been added in 1.6. This facility has been there since 1.5.1 and was written by Scott Philips. What has been added in 1.6 is the ability (making use of some of Scott’s code) for the command line version of the batch importer and exporter to handle zip files of multiple items. This means you can export multiple items to just one zip file, transfer the single file to a new server, and re-import it.]
A few weeks ago I wrote about the EasyDeposit system we’ve created at The University of Auckland Library. In a nutshell, it allows you to easily create custom web-based SWORD deposit interfaces to enable the deposit of items into your repository. We’ve used it locally to create custom deposit interfaces for PhD theses, Masters theses, and Computer Science technical reports.
One of the key features of EasyDeposit is how custom interfaces can be built by selecting from a set of ‘steps’. Each step performs a task such as allowing the user to upload files, enter metadata, login, verify the details of the deposit etc. Steps can be easily added by creating two new files – one which contains the business logic (coded in PHP) and one which contains the view (HTML). We maintain some custom steps locally to manage the licensing of theses (to select embargo terms and Creative Commons options).
I recently became aware of the CrossRef API. This web service allows you to look up the metadata of an item that has a DOI. Requests are made using a URL in the form of:
The whole ethos behind EasyDeposit is to enable repository administrators to create custom SWORD deposit interfaces that make it easy for their users to deposit content into their repositories. Therefore it seemed a good idea to write a new EasyDeposit step that allows users to enter a DOI instead of manually entering metadata. A typical deposit interface could now be as simple as:
- Do you have a DOI for your item? If so:
- Enter a DOI
- Confirm the metadata is correct
- Upload a file
- Verify the deposit detail
I have now uploaded the ‘CrossRefDOILookup’ and ‘CrossRefDOIMetadata’ steps to the EasyDeposit site. You can use these steps (they must be used together) in your EasyDeposit interface. Here are some screenshots:
In order to use the API you must register with CrossRef. You can do this at: http://www.crossref.org/requestaccount/. Your API key will the email address that you used to sign up, and must be entered in the easydeposit.php configuration file:
// CrossRef API DOI lookup configuration
// Register for a key at http://www.crossref.org/requestaccount/
// Your API KEY is the email address that you used to register
$config[‘easydeposit_crossrefdoilookup_apikey’] = ‘API_KEY’;
As always, I’d be pleased to receive feedback about this feature.