Home > ACErep, Prototype, SWORD > Working search prototype and a SWORD fight

Working search prototype and a SWORD fight

November 23, 2010 Leave a comment Go to comments

Since the last meeting, Mike has done a great job in putting together a working (search) prototype that uses the Xpert API to search http://www.nottingham.ac.uk/xpert/ for just those resources tagged “alpsportal” i.e. ALPS resources that I have added to our repository and that have been harvested by Xpert.  Currently Xpert is only harvesting Leeds Met but it should now be fairly straightforward to also harvest YSJ and Leeds such that any resources appropriately tagged will be returned from the portal.  It’s on a restricted test server at the moment so this what it looks like (with a few explanatory slides):

And the SWORD fight? There are 3 repositories (possibly 4 if we count JORUM) that we need to be able to deposit into – this is a problem as currently only one of them – intraLibrary at Leeds Met – has fully functioning SWORD.  This did lead us to consider a hybrid deposit process allowing for manual package forwarding but given limited technical resources (this approach would have its own, not inconsiderable, overheads) and the clear advantages of utilising SWORD, it probably makes sense to focus on a prototype that can utilise the protocol and that can, hopefully, plug into the other repositories in the future.

One of the issues we face is that intraLibrary is based on IEEE LOM and only accepts IMS Content Packages by SWORD whereas the majority of (open source) repositories are based on Dublin Core metadata and only accept METS by SWORD; I have been working with Jorum to test their SWORD deposit – as a customised DSpace repository it accepts METS (not IMS) so we have had to map IMSCP for one of our resources -> METS in order for it to be accepted.  Currently I have only been able to achieve this with a very simple package comprising just title, description and author (I’ve also tried to add keyword and rights but these don’t seem to be picked up by Jorum – I’m not sure if this is a problem with Jorum or with my XML – probably the latter!)

It is still a moot point whether we will need METS or IMSCP for YSJ/Leeds until various questions around their specific repository implementations have been answered but we probably need to progress on the basis that we should support both. We will need to get Mike involved on the technical side and I’m hoping that he can start developing a web-based SWORD deposit client that, eventually, will be able to post to any SWORD service URL whether at Leeds Met, Leeds, YSJ or Jorum; as the only viable target repository at this stage is Leeds Met we will want to package as IMSCP in the first instance, ultimately with a view to also packaging as METS depending on the requirements of the destination repository.

MT – I may be asking for the moon on a stick here but I know you’ll put me straight and tell me what we can actually achieve and in what time-scale…just to summarise, below, what (I think) I understand about SWORD so far and what I anticipate might be required of this type of implementation:

SWORD works by means of a service URL that a package is posted to via the ATOM publishing protocol – this service URL allows a “service document” to be retrieved from the target repository which itemises available collections for SWORD deposit. The desktop client I have been using with our repository and with Jorum is available from Sourceforge – http://sourceforge.net/projects/sword-app/.  It enables me to post a .zip containing a resource + its metadata in an imsmanifest.xml to intraLibrary (or resource + mets.xml to Jorum)

Screenshots below:

Authenticate to repository / retrieve service doc (note SWORD service URL)

Authenticate to repository / retrieve service document (note SWORD service URL)

Service doc successfully retrieved – choose collection to deposit into:

Service doc successfully retrieved - choose collection to deposit into:

Confirm collection details for post operation:

Confirm colection details for post operation

Browse to zip on hard drive (already containing imsmanifest.xml) and click button to post to repository:

Browse to zip on hard drive (already containing imsmanifest.xml) and click button to post to repository

Resource and full metadata record successfully posted to repository:

Resource and full metadata record successfully posted to repository:

I imagine we would need a web-form that allows similar metadata to be captured and transformed into an imsmanifest.xml, then allows file upload and zips resource and manifest into an IMSCP that is then posted to a specified collection in the service doc at http://repository-intralibrary.leedsmet.ac.uk/IntraLibrary-Deposit/service.

Erm, sounds a bit tricky to me, Mike?

It might also be worth looking again at Stuart Lewis’ EasyDeposit (blogged about at http://repositorynews.wordpress.com/2010/06/04/easydeposit-the-sword-client-creation-toolkit/) which packages as METS for DSpace/EPrints etc.

  1. Pat
    November 23, 2010 at 3:14 pm

    Keyword spamming seems a bit thin? Custom URL search better?

    • Nick
      November 23, 2010 at 3:15 pm

      Pat, this is Mike, Mike, Pat…

  1. March 23, 2011 at 11:37 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: