How does the Facebook SWORD client actually work?

I’ve been asked a few questions recently about how SWORD clients work, and in particular how the SWORD Facebook client works. The Facebook client is one of the most complete demonstration clients that there is, and as such ‘hides’ a lot of the work that goes on behind the scenes. This post will explain how a SWORD deposit from within Facebook actually works:

• First off, the user has to select the repository they wish to deposit into. This can either be done by selecting from a dropdown list of known demo SWORD repositories, or by manually entering the URL of a service document:

• Most repositories will require their users to authenticate using a username and password. These are typically passed to the SWORD server using HTTP BASIC authentication. Optionally, an ‘on-behalf-of’ user can be specified (see the SWORD specification for what this means):

• When this initial form is submitted, the client will visit the SWORD server, and request the service document by performing a HTTP GET of the service document URL. In the case of the SWORD Facebook application, it is written using the SWORD PHP library. The PHP library uses cURL to retreive the service document. Using a 3rd party library such as the PHP library makes it *really* easy to do this. Here is the required PHP:

require("swordappclient.php");
$sac = new SWORDAPPClient();
$sdr = $sac->servicedocument($url, $user, $password, $onbehalfof);

• Hopefully (assuming a valid service document URL, username and password) the client will receive a service document back from the SWORD server. The service document will specify which collections a user may submit to and provide some details about each collection (e.g. name, URL to deposit to, policy, prefered packaging types etc). Different repository platforms interpret the meaning of ‘collection’ differently. In DSpace, these map to DSpace collections, wheras in EPrints, they relate to workspaces within the user’s account.

• Once you have selected a collection into which you wish to deposit an item, you are presented with a form requesting metadata. Your promted for the type of item, its peer-review status, title, abstract, and first author. You can optionally add second and their author names, and an existing URL for the item.

• So what happens with this metadata you enter? In a nutshell, it all gets crosswalked and wrapped up in a METS document, encoded in SWAP. To see what I mean, look at the following example:

<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<mets ID="sort-mets_mets" OBJID="sword-mets" LABEL="DSpace SWORD Item" PROFILE="DSpace METS SIP Profile 1.0" xmlns="http://www.loc.gov/METS/" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd">
<metsHdr CREATEDATE="2008-09-04T00:00:00"><br /><agent ROLE="CUSTODIAN" TYPE="ORGANIZATION">
<name>Stuart Lewis</name>
</agent>
</metsHdr>
<dmdSec ID="sword-mets-dmd-1" GROUPID="sword-mets-dmd-1_group-1">
<mdWrap LABEL="SWAP Metadata" MDTYPE="OTHER" OTHERMDTYPE="EPDCX" MIMETYPE="text/xml">
<xmlData>
<epdcx:descriptionSet xmlns:epdcx="http://purl.org/eprint/epdcx/2006-11-16/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://purl.org/eprint/epdcx/2006-11-16/ http://purl.org/eprint/epdcx/xsd/2006-11-16/epdcx.xsd">
<epdcx:description epdcx:resourceId="sword-mets-epdcx-1">
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/elements/1.1/type" epdcx:valueURI="http://purl.org/eprint/entityType/ScholarlyWork" />
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/elements/1.1/title">
<epdcx:valueString>Item Title</epdcx:valueString>
</epdcx:statement>
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/terms/abstract">
<epdcx:valueString>Item Abstract</epdcx:valueString>
</epdcx:statement>
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/elements/1.1/creator">
<epdcx:valueString>Lewis, Stuart</epdcx:valueString>
</epdcx:statement>
<epdcx:statement epdcx:propertyURI="http://purl.org/eprint/terms/isExpressedAs" epdcx:valueRef="sword-mets-expr-1" />
</epdcx:description>
<epdcx:description epdcx:resourceId="sword-mets-expr-1">
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/elements/1.1/type" epdcx:valueURI="http://purl.org/eprint/entityType/Expression" />
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/elements/1.1/language" epdcx:vesURI="http://purl.org/dc/terms/RFC3066">
<epdcx:valueString>en</epdcx:valueString>
</epdcx:statement>
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/elements/1.1/type" epdcx:vesURI="http://purl.org/eprint/terms/Type" epdcx:valueURI="http://purl.org/eprint/entityType/Expression" />
<epdcx:statement epdcx:propertyURI="http://purl.org/dc/terms/available">
<epdcx:valueString epdcx:sesURI="http://purl.org/dc/terms/W3CDTF">2009-04-28</epdcx:valueString>
</epdcx:statement>
<epdcx:statement epdcx:propertyURI="http://purl.org/eprint/terms/Status" epdcx:vesURI="http://purl.org/eprint/terms/Status"  epdcx:valueURI="http://purl.org/eprint/status/PeerReviewed" />
<epdcx:statement epdcx:propertyURI="http://purl.org/eprint/terms/copyrightHolder">
<epdcx:valueString>Stuart Lewis</epdcx:valueString>
</epdcx:statement>
</epdcx:description>
</epdcx:descriptionSet>
</xmlData>
</mets>

• If you examine the XML, you’ll see the metadata in the METS document. For example the title is described on line 14, the abstract on line 17, the author on line 20, and the deposit date on line 31. The mapping of metadata elements from the form fields to the METS/SWAP is fixed in the software.
• The next stage of the submission is to upload a file to add to the metadata to make the package to deposit. The details of the file you choose are added in to the METS document. This is done using the fileSec and structMap portions of the METS standard:

<fileSec>
<fileGrp ID="sword-mets-fgrp-1" USE="CONTENT">
<file GROUPID="sword-mets-fgid-0" ID="sword-mets-file-0" MIMETYPE="application/pdf">
<FLocat LOCTYPE="URL" xlink:href="SWORD Ariadne Jan 2008.pdf" />
</file>
</fileGrp>
</fileSec>
<structMap ID="sword-mets-struct-1" LABEL="structure" TYPE="LOGICAL">
<div ID="sword-mets-div-1" DMDID="sword-mets-dmd-1" TYPE="SWORD Object">
<div ID="sword-mets-div-2" TYPE="File">
<fptr FILEID="sword-mets-file-0" />
</div>
</div>
</structMap>

• The mets file (mets.xml) and the uploaded file are the put into a zip file, and deposited to the repository. Again, these two steps are very easy using the PHP library:

require('packager_mets_swap.php');
// Create a new package with the root and directory of the input files, and the root and directory of the created package
$package = new PackagerMetsSwap($rootin, $dirin, $rootout, $fileout);

// Add metadata to the package
$package->setType($test_type);
$package->setTitle($title);
$package->setAbstract($abstract);
foreach ($creators as $creator) {
$package->addCreator($creator);
}

// Add a file to the package
$package->addFile($filename, $mimetype);

// Now deposit the package
require("swordappclient.php");
$sac = new SWORDAPPClient();
$dr = $sac->deposit($depositurl, $username, $password, $onbehalfof, $filename, $packageformat, $pacakgecontenttype);

• Once the pacakge is sent to the repository, it is up to the repository to decide how to handle the package. In the case of DSpace, two things happen. The first is that a raw copy of the original package is archived in a new item allowing us to see precisely what was deposited. This is hidden from users though. Secondly, the package is opended up and processed. The file is added to the item, and the metadata is crosswalked using XSL to Dublin Core as used by DSpace. An example of part of the XSL used is shown below (mapping dcterms creator to dc.contributor.author):

<!-- creator element: dc.contributor.author -->
<xsl:if test="./@epdcx:propertyURI='http://purl.org/dc/elements/1.1/creator'">
<dim:field mdschema="dc" element="contributor" qualifier="author">
<xsl:value-of select="epdcx:valueString"/>
</dim:field>
</xsl:if>

I hope this post clears up a bit of what goes on ‘behind the scenes’ of a SWORD client. I hope it also shows how easy it can be to create a SWORD client using the PHP library which provides not only code to request service documents and deposit items, but also to create pacakges in a format that is accepted by DSpace and EPrints. Any questions?

• About

  
  This is the blog of Stuart Lewis, a DSpace committer, repository developer, repository66 mashup creator, and SWORD project member. Currently working as the IT Innovations Analyst and Developer at the University of Auckland Library, formerly working at Aberystwyth University.

• 
  This work by Stuart Lewis is licensed under a Creative Commons Attribution-ShareAlike 3.0 New Zealand.

• ---

  Disclaimer
  Opinions expressed here are my own, and not those of employers or funders, past or present.

  ---

• Tags

  analytics blackboard blogs citations depositplait dspace easydeposit eprints fedora google google scholar gsoc interoperability jisc jisc-crig ldap life mashups open access open data preservation repositories repository66 repository mashup map roadproject rsp rspsummerschool2008 search servers sharepoint shibboleth sword training twitter voip web windows youtube

•  

  June 2009

  M	T	W	T	F	S	S
  « May				Jul »
  1	2	3	4	5	6	7
  8	9	10	11	12	13	14
  15	16	17	18	19	20	21
  22	23	24	25	26	27	28
  29	30

• Archives

  • March 2010
  • February 2010
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008

• Recent Comments

  • Stuart on Tweeting temporal tidal data
  • Stuart Lewis' Blog » DSpace 1.6 released! on On DSpace development
  • Scott on Tweeting temporal tidal data
  • Ajankohtaista julkaisuarkistoista – Digitaalinen kirjasto on On DSpace development
  • DuraSpace Blog » Blog Archive » Ready to Go: DSpace 1.6 is Now Available on DSpace 1.6 – What will be in it for me?
  • Stuart Lewis' Blog » EasyDeposit – DOI integration with CrossRef API on EasyDeposit – SWORD deposit tool creator
  • Stuart on EasyDeposit – SWORD deposit tool creator
  • Stuart on DSpace 1.6 – What will be in it for me?