EasyDeposit Work

EasyDeposit looks more and more promising as a straightforward way to manage the deposit interface for Fedora. I have written content models for the main categories of materials type (hardware, software, etc.). These content model objects also contain the

<rel:isCollection>true</rel:isCollection>

attribute elaborated on here, so they can function as “collections” in Fedora. Submitting test objects into these collections correctly gives them a RELS-EXT datastream stating they are a member of this collection, i.e.:

<rel:isMemberOf rdf:resource="gcm-cModel:hardware" />.

This is a good start I hope.

From this point two key issues stand out. The first is that EasyDeposit defaults to zipping submissions. This is appropriate when the submission is the actual data meant to be preserved, as is the case with a software submission, but is not appropriate when the submission is simply metadata. In this case a simple FOXML file is all that needs to be submitted. I am sure this can be changed somewhere.

The second is that a key feature of the repository is mapping relationships between pieces of hardware and software. Thus, a submitter needs to be able to specify such a relationship, ideally in the submission process. There needs to be a step where the user can pick from a list of relationships and previously submitted target resources. For example, some record isPartOf of x and y or hasPart a and b. Generating a list of possible relationships should be straightforward, but it is likely the user will simply have to specify manually what the target resource is.

Using SWORD for Deposit

I’ve been looking for suitable front-ends for Fedora. The default installation comes with both a Java administrator client and a newer (though less full-featured) web administration tool. Developers are currently trying to transition over to the web client, adding functionality with each point release. Neither of these clients are suitable as comprehensive front-ends for Fedora however.

I identified a deposit interface as the foremost component for the front-end, and quickly went looking to the SWORD APP for a solution. SWORD (Simple web-service offering repository deposit) is a profile of the Atom Publishing Protocol (APP), a successful syndication specification for items on the web. SWORD retools the protocol a tiny bit and emphasizes the request and deposit functions over functions like delete or update. APP is a HTTP-based protocol, so of course SWORD functions over the web. The idea is that a simple protocol like this will find widespread use and acceptance, bolstering the awareness and bulk of repositories by simplifying the deposit process, all while keeping it as a remote function. For instance, there’s SWORD Facebook app and a (sample) SWORD plug-in for Microsoft Office. Ideally from either of these platforms you can send your work right away to any number of receiving repositories.

I have setup SWORD with Fedora. It runs as a web application inside Tomcat. After a few kinks everything seems to be ironed out, and it’s a little more clear how SWORD could fit into the repository as a whole. SWORD is best at depositing content, naturally, and it’s best if that content is pre-processed. The out-of-the-box demonstration client isn’t going to provide a way add metadata to your deposit.

EasyDeposit, written by Stuart Lewis, looks very promising in this area. EasyDeposit is a PHP front-end to SWORD, and allows the user to go through several steps prior to delivering the deposit. It allows the administrator to adjust, add, delete, and create steps, tailoring the process to the organization. For our purposes, we would add steps to receive metadata information about hardware, bibliographic materials, software and so on. I’ve implemented EasyDeposit on our test instance and it does safely deposit content along with some default metadata fields. Concerning the steps already present, configuration is straightforward, requiring modification of .php files. It should be easy to add in collections, or content models that define metadata and behavior requirements, and present them in these steps. Unfortunately (for me), EasyDeposit is presently at 0.1 (although it just got support for the CrossRef API), and documentation is not all there. This doesn’t put EasyDeposit completely out of the running per se, as the interface looks great, and the idea of customizing a template is pretty attractive.

More broadly, SWORD will not serve as an entire front-end solution, and the question becomes whether one wants to join a SWORD interface like EasyDeposit with other Fedora-compliant components like searching and disseminating. Alternatives to this approach are projects like Muradora and Islandora that attempt to provide more full-featured front-end. I plan to explore these options and get a better idea of the possibilities for full implementation.