To this end, both Figshare and Zenodo have recently developed and released integrations into GitHub.  These both allow the depositor to easily take a copy of their code from GitHub, and deposit it into the respective repository.  One of the key benefits of doing this is that the repository platforms are then able to assign a persistent DataCite DOI (Digital Object Identifier) to the software, which makes it easier to cite and track through scholarly literature.

As one of the developers of the open SWORD deposit protocol that facilitates the deposit of resources into repositories, I thought it would be good to try and re-create this functionality using SWORD.  Below is the ‘recipe’ of how this works…

Step one (optional): Setup your browser with a bookmark
To make it easier to deposit code from GitHub, you can install a ‘bookmarklet‘ that automatically detects that GitHub repository, and lets the deposit system know where this is.  This means that from any GitHub repository, you can click on the bookmark to deposit the code.  To install it, visit http://easydeposit.swordapp.org/example/github/easydeposit/ and drag the bookmarklet at the bottom of the page to your browser’s bookmark bar:

Step two: Choose the GitHub repository to deposit

GitHub makes use of accounts and repositories.  Each user of the service has an account, and each account can create multiple code repositories.  URLs for GitHub are in the form of https://github.com/{account}/{repository}, for example the PHP programming language is stored in GitHub: https://github.com/php/php-src (php is the account name, and php-src is the code repository for the PHP language).

Choose the GitHub repository that you wish to deposit in the repository by opening the repository in your browser.  In the example below, this is the DSpace repository platform’s code repository:

Step three: Click the bookmark!
If you click the ‘GitHub Deposit’ bookmark that you created earlier, this will redirect you to a SWORD deposit system.  The bookmarklet contains javascript that passes the URL of the GitHub repository to the deposit client, and populates the form automatically.  Alternatively you can just visit http://easydeposit.swordapp.org/example/github/easydeposit/ and enter the URL of the repository yourself:

Step four: Download the code

Clicking ‘Next >’ will initiate the download of the latest version of the code (‘master’ in git terminology).  Depending on the size of the repository, this may take a few seconds.  The code isn’t doing anything clever, and unlike the Zenodo and Figshare integrations, it doesn’t make use of the GitHub API.  Instead, it downloads the master.zip file by constructing a URL such as https://codeload.github.com/DSpace/DSpace/zip/master.   It then uses basic metadata such as the title of the repository (title), the account holder (author), the URL of the repository (link) and the latest check-in comment and revision hash (abstract).  These are then presented back to you to confirm:

Step five: Perform the deposit
Upon clicking the deposit button, the code will then translate the metadata into a METS file, and zip that up alongside the downloaded code bundle.  All this is then deposited into the demo DSpace server (http://demo.dspace.org/).  Assuming the deposit works, you’ll be presented with the URL of the deposited code.  In this case, it is a ‘handle’, but to all intents and purposes that is a DOI, and DSpace can be configured to issue DOIs.

Step six: View the code

To see the deposited code in the repository, just click on the handle link!  For example, http://hdl.handle.net/10673/51. This will take you to the repository, where the metadata can be seen, and the code downloaded!

This isn’t a highly polished integration, and was thrown together in a couple of hours, by adding it as an optional ‘step’ in the configurable web-based deposit client ‘EasyDeposit‘.  But it is a good demonstration that creating small tools that archive code into SWORD-compliant repositories (DSpace, EPrints, Fedora, etc) can be achieved quite quickly!site

In order to really test the library, it is good to think of a real end-to-end use case and implement it.  The use case I chose to do this was to mirror one repository to another, and to then keep it up to date.  This first involves a baseline sync to gather all the content, followed by an incremental sync of changes made each day.

ResourceSync provides the mechanism by which to gather the resources from the remote repository.  However another function is then required to take those resources and put them into the destination repository.  The obvious choice for this is SWORD v2.

ResourceSync is designed to list all files (or changed files) on a server.  These are then transferred using good old HTTP, but to get them into another repository requires a deposit protocol – in this case, SWORD.  In other words, ResourceSync is used to harvest the resources onto my computer, and SWORD is then used to deposit them into a destination repository.

The challenge here is linking resources together.  An ‘item’ in a repository is typically made up of a metadata resource, along with one or more associated file resources.  Because these are separate resources, they are listed independently in the ResourceSync resource lists.  However they contain attributes that link them together: ‘describes’ and ‘describedBy’.  The metadata ‘describes’ the file, and the file is ‘describedBy’ the metadata.  A good example of this is given in the CottageLabs description of how the OAI-PMH use case can be implemented using ResourceSync:

[xml]
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:rs="http://www.openarchives.org/rs/terms/">

<rs:ln rel="resourcesync" href="http://example.com/capabilitylist.xml"/>
<rs:md capability="resourcelist" modified="2013-01-03T09:00:00Z"/>

<url>
<loc>http://example.com/metadata-resource</loc>
<lastmod>2013-01-02T17:00:00Z</lastmod>
<rs:ln rel="describes" href="http://example.com/bitstream1"/>
<rs:ln rel="describedBy" href="http://purl.org/dc/terms/"/>
<rs:ln rel="collection" href="http://example.com/collection1"/>
<rs:md hash="md5:1584abdf8ebdc9802ac0c6a7402c03b6"
length="8876"
type="application/xml"/>
</url>

<url>
<loc>http://example.com/bitstream1</loc>
<lastmod>2013-01-02T17:00:00Z</lastmod>
<rs:ln rel="describedBy" href="http://example.com/metadata-resource"/>
<rs:ln rel="describedBy" href="http://example.com/other-metadata"/>
<rs:ln rel="collection" href="http://example.com/collection1"/>
<rs:md hash="md5:1e0d5cb8ef6ba40c99b14c0237be735e"
length="14599"
type="application/pdf"/>
</url>
</urlset>
[/xml]

So here’s the recipe (and here’s the code) for syncing a resource list such as this, and then depositing it into a remote repository using SWORD.  Both use PHP libraries, which makes the code quite short.

• ResourceSync PHP API library
• SWORD v2 PHP API library

The recipe

[php]
include_once(‘../../ResyncResourcelist.php’);
$resourcelist = new ResyncResourcelist(‘http://93.93.131.168:8080/rs/resourcelist.xml’);
$resourcelist->registerCallback(function($file, $resyncurl) {
// Work out if this is a metadata object or a file
global $metadataitems, $objectitems;
$type = ‘metadata’;
$namespaces = $resyncurl->getXML()->getNameSpaces(true);
if (!isset($namespaces[‘sm’])) $sac_ns[‘sm’] = ‘http://www.sitemaps.org/schemas/sitemap/0.9’;
$lns = $resyncurl->getXML()->children($namespaces[‘rs’])->ln;
$key = ”;
$owner = ”;
foreach($lns as $ln) {
if (($ln->attributes()->rel == ‘describedby’) && ($ln->attributes()->href != ‘http://purl.org/dc/terms/’)) {
$type = ‘object’;
$key = $resyncurl->getLoc();
$owner = $ln->attributes()->href;
}
}

echo ‘ – New file saved: ‘ .$file . "\n";
echo ‘  – Type: ‘ . $type . "\n";

if ($type == ‘metadata’) {
$metadataitems[] = $resyncurl;
} else {
$objectitems[(string)$key] = $resyncurl;
$resyncurl->setOwner($owner);
}
});
[/php]

This piece of code is performing a baseline sync, and is using the callback registration option mentioned in the last blog.  The callback is just doing one thing: sorting the metadata objects into one list, and the file objects into another.  These will then be processed later.

Next, each metadata item is processed in order to deposit that metadata object into the destination repository using SWORD v2:

[php]
foreach ($metadataitems as $item) {
echo " – Item " . ++$counter . ‘ of ‘ . count($metadataitems) . "\n";
echo "  – Metadata file: " . $item->getFileOnDisk() . "\n";
$namespaces = $xml->getNameSpaces(true);
if (!isset($namespaces[‘dc’])) $sac_ns[‘dc’] = ‘http://purl.org/dc/terms/’;
if (!isset($namespaces[‘dcterms’])) $sac_ns[‘dc’] = ‘http://purl.org/dc/elements/1.1/’;
$dc = $xml->children($namespaces[‘dc’]);
$dcterms = $xml->children($namespaces[‘dcterms’]);
$title = $dc->title[0];
$contributor = $dc->contributor[0];
$id = $dc->identifier[0];
$date = $dcterms->issued[0];
echo ‘   – Location: ‘ . $item->getLoc() . "\n";
echo ‘   – Author: ‘ . $contributor . "\n";
echo ‘   – Title: ‘ . $title . "\n";
echo ‘   – Identifier: ‘ . $id . "\n";
echo ‘   – Date: ‘ . $date . "\n";

// Create the atom entry
$test_dirin = ‘atom_multipart’;
$atom = new PackagerAtomTwoStep($resync_test_savedir, $sword_deposit_temp, ”, ”);
$atom->setTitle($title);
$atom->addMetadata(‘creator’, $contributor);
$atom->setIdentifier($id);
$atom->setUpdated($date);
$atom->create();

// Deposit the metadata record
$atomfilename = $resync_test_savedir . ‘/’ . $sword_deposit_temp . ‘/atom’;
echo ‘  – About to deposit metadata: ‘ . $atomfilename . "\n";
$deposit = $sword->depositAtomEntry($sac_deposit_location,
$sac_deposit_username,
$sac_deposit_password,
”,
$atomfilename,
true);
[/php]

This option being used here is to first create an atom entry that contains the metadata, and depositing that.  The SWORD v2 ‘in-progress’ flag is being set to TRUE, which indicates that further activity will take place to the record.

The code then needs to look through the list of file resources, and find any that are ‘describedBy’ the metadata record in question.  Any that are, are deposited to the same record using SWORD v2:

[php]
// Find related files for this metadata record
foreach($objectitems as $object) {
if ((string)$object->getOwner() == (string)$item->getLoc()) {
$finfo = finfo_open(FILEINFO_MIME_TYPE);
$mime = finfo_file($finfo, $object->getFileOnDisk());
echo ‘    – Related object: ‘ . $object->getLoc() . "\n";
echo ‘     – File: ‘ . $object->getFileOnDisk() . ‘ (‘ . $mime . ")\n";

// Deposit file
$deposit = $sword->addExtraFileToMediaResource($edit_media,
$sac_deposit_username,
$sac_deposit_password,
”,
$object->getFileOnDisk(),
$mime);
}
}
[/php]

Using the SWORD v2 API library is very easy: once you have the file and its MIME type, it is a single line of code to add that file to the record in the destination repository.

Once all the related files have been added, the final step is to set the ‘in-progress’ flag to FALSE to indicate that the object is complete, and that it can be formally archived into the repository.  This is a simple as:

[php]
// Complete the deposit
$deposit = $sword->completeIncompleteDeposit($edit_iri,
$sac_deposit_username,
$sac_deposit_password,
”);
[/php]

The end to end process has now taken place – the items have been harvested using ResourceSync, and then deposited back using SWORD v2.

Limitations

The default DSpace implementation of the SWORD v2 protocol allows items to deposited, updated, and deleted.  It does this by keeping items in the workflow, and when the ‘In-progress’ flag is set to false, the deposit is completed by moving it out of the workflow and into the main archive.  Once the item is moved into the main archive, it can no longer be edited using SWORD.

This is a sensible approach for most situations.  Once an item has been formally ingested, it is under the control of the archive manager, and the original depositor should probably not have the rights to make further changes.

However in the case of performing a synchronisation with ResrcoueSync, the master copy of the data is in a remote repository, and that should therefore be allowed to overwrite data that is formally archived in the repository.  This is an implementation option though, and if an alternative WorkflowManager was written, this could be changed.

[Update: 20th June 2013.  I have now edited the default WorkflowManager, to make one that permits updates to items that are in workflow or in the archive.  This overcomes this limitation.  I hope to add this as a configurable option to a future release of DSpace.]

Conclusion

ResourceSync and SWORD are two complementary interoperability protocols. ResourceSync can be used to harvest all content from one site, and SWORD used to deposit that content into another.

ResourceSync can differentiate between new, updated, and deleted content.  SWORD v2 also allows these interactions, so can be used to reflect those changes as they happen.как разместить объявление в контакте

• Background to the initiative: http://www.niso.org/workrooms/resourcesync/
• H. Van de Sompel, R. Sanderson, M. Klein, M. L. Nelson, B. Haslhofer, S. Warner, C. Lagoze. A Perspective on Resource Synchronization. D-Lib Magazine, Vol. 18, No. 9/10, 2012. http://dx.doi.org/10.1045/september2012-vandesompel
• M. Klein, R. Sanderson, H. Van de Sompel, S. Warner, B. Haslhofer, C. Lagoze, M. L. Nelson. A Technical Framework for Resource Synchronization. D-Lib Magazine, Vol. 19, No. 1/2, 2013. http://dx.doi.org/10.1045/january2013-klein.
• S. Lewis, R. Jones, S. Warner. Motivations for the Development of a Web Resource Synchronisation Framework. Ariadne, Issue 70, November 2012.

The specification itself can be read at http://www.openarchives.org/rs, and a quick read will highlight very quickly that the specification is based on sitemaps (http://www.sitemaps.org/) which is no surprise, given that they were developed for the easy and efficient listing of web resources for search engine crawlers to harvest – which in itself is a specialised form of resource synchronisation.

As with anything new, the proof is always in the pudding, which in this context means that reference implementations are required in order to both test that a standard can be implemented and fulfill the original use cases it was designed to do, but also to smooth off any rough edges that only appear once you use it in anger.

My role therefore has been to develop a PHP ResourceSync client library.  The role of a client library is to allow other software systems to easily interact with a technology – in this case, web servers that support ResourceSync.  The client library therefore provides the facility to connect to a web server and synchronise the contents, and then to stay up to date by loading lists of resources that have been created, updated, or deleted.

The PHP library can be downloaded from: https://github.com/stuartlewis/resync-php

The rest of this blog post will step through the different parts of ResourceSync, and shows how they can be access by the PHP client library:

The first step is to discover whether a site supports ResourceSync.  The mechanism to do this is by using the well-known URI specification (see: RFC5785).  Put simply, if a server supports ResourceSync, it places a file at http://www.example.com/.well-known/resourcesync which then points to where the capability list exists.

The first function of the PHP ResourceSync library is therefore to support this discovery:

[php]
include(‘ResyncDiscover.php’);
$resyncdiscover = new ResyncDiscover(‘http://example.com/’);
$capabilitylists = $resyncdiscover->getCapabilities();
echo ‘ – There were ‘ . count($capabilitylists) .
‘ capability lists found:’ . "\n";
foreach ($capabilitylists as $capabilties) {
echo ‘ – ‘ . $capabilties . "\n";
}
[/php]

Zero, one, or more capability list URIs are returned.  If none are returned, then the site doesn’t support ResourceSync.  If one is returned, the next step is to examine the capability list to see which parts of the ResourceSync protocol are supported:

[php]
include(‘ResyncCapabilities.php’);
$resynccapabilities = new ResyncCapabilities(‘http://example.com/capabilitylist.xml’);
$capabilities = $resynccapabilities->getCapabilities();
echo ‘Capabilities’ . "\n";
foreach($capabilities as $capability => $type) {
echo ‘ – ‘ . $capability . ‘ (capability type: ‘ . $type . ‘)’ . "\n";
}
[/php]

The output of this is that the specific ResourceSync capabilities supported by that server will be returned.  Typically a resourcelist and a changelist will be shown.

The next step is often to perform a baseline sync (complete download of all resources).  Again, the PHP library supports this:

[php]
include ‘ResyncResourcelist.php’;
$resourcelist = new ResyncResourcelist(‘http://example.com/resourcelist.xml’);
$resourcelist->enableDebug(); // Show progress
$resourcelist->baseline(‘/resync’);
[/php]

It is possible to ask the library how many files it has downloaded, and how large they were:

[php]
echo $resourcelist->getDownloadedFileCount() . ‘ files downloaded, and ‘ .
$resourcelist->getSkippedFileCount() . ‘ files skipped’ . "\n";
echo $resourcelist->getDownloadSize() . ‘Kb downloaded in ‘ .
$resourcelist->getDownloadDuration() . ‘ seconds (‘ .
($resourcelist->getDownloadSize() /
$resourcelist->getDownloadDuration()) . ‘ Kb/s)’ . "\n";
[/php]

It is possible to also restrict the files to be downloaded to those from a certain date.  This can be useful if you only want to synchronise recently created files:

[php]
$from = new DateTime("2013-05-18 00:00:00.000000");
$resourcelist->baseline(‘/resync’, $from);
[/php]

Once a baseline sync has taken place, all of the files exposed via the ResourceSync interface will now exist on the local computer.  The next step is to routinely keep this set of resources up to date.  To do this, depending on the frequency at which the server produces change lists, these should be processed to download new or updated files, and to delete old files:

[php]
include ‘ResyncChangelist.php’;
$changelist = new ResyncChangelist(‘http://example.com/changelist.xml’);
$changelist->enableDebug(); // Show progress
$changelist->process(‘/resync’);
[/php]

Again, there are options to see what files have been processed:

[php]
echo ‘ – ‘ . $changelist->getCreatedCount() . ‘ files created’ . "\n";
echo ‘ – ‘ . $changelist->getUpdatedCount() . ‘ files updated’ . "\n";
echo ‘ – ‘ . $changelist-getDeletedCount() . ‘ files deleted’ . "\n";
echo $changelist->getDownloadedFileCount() . ‘ files downloaded, and ‘ .
$changelist->getSkippedFileCount() . ‘ files skipped’ . "\n";
echo $changelist->getDownloadSize() . ‘Kb downloaded in ‘ .
$changelist->getDownloadDuration() . ‘ seconds (‘ .
($changelist->getDownloadSize() /
$changelist->getDownloadDuration()) . ‘ Kb/s)’ . "\n";
[/php]

Also again, it is possible to only see changes since a particular date.  This can be used to keep note of when the sync was last attempted, meaning only changes made since then are processed:

[php]
$from = new DateTime("2013-05-18 00:00:00.000000");
$changelist->process(‘/resync’, $from);
[/php]

The PHP library allows in a few steps, each consisting of a few lines, for the contents of a ResourceSync enabled server to be kept in sync with a local copy.

A further two blog posts will be published in this series.  The next will show how to interact with the library so that more complex actions can be performed when resources are created, updated, or deleted.  The final blog post will show this in action, with an application of the PHP ResourceSync library making use of the resources it processes.как разместить контекстную рекламу

First the background: I have a slight love/hate relationship with the repository community and the Open Repositories conference related to how it makes a strong distinction between ‘Repository Managers’ and ‘Developers’.  Its nice that we do this as it allows for innovate conference strands such as the ‘developers challenge‘ where developers can come and show-off their wares. However I also hate this segregation and the labeling of delegates into these categories.  Personally I see myself as straddling the two, and I feel that we should be looking for our shared interests (developing open repository services) rather than highlighting differences between our roles.

However, I won’t rant or get on my soap-box, but instead I’ll butcher a song from the Rodgers and Hammerstein musical ‘Oklahoma!‘. One of the most famous songs is about how the farmers and the cowboys don’t get along and look for all the differences between themselves, rather than trying to work together to make the most of being settlers in a new territory. (See any similarities?!)

The disclaimer – the song makes the assumption that farmers and cowmen are all male, and that the females stay at home cooking, with the daughters waiting to get married.  In my re-working of the lyrics I’ve been equally sexist and made the repository managers female and the developers male.  This is not representative of my views or of reality, but it fits for the song!  So please don’t hold this against me!  This is just a light-hearted piece!

The song also fits with the OR2012 conference as it talks about the admins and coders (‘repository managers’ and ‘developers’ are too long for the song!) dancing together.  The conference dinner will be ending with a ceilidh, where hopefully there will be much dancing and fun!  If you’ve never seen Oklahoma you can watch a performance of this song below:

So sing along (preferably in your head if you work in a shared office!)

The admin and the coder should be friends.
Oh the admin and the coder should be friends.
One of them likes to bulk upload, the other likes to cut some code,
But that’s no reason why they can’t be friends!

Repository folks should stick together,
Repository folks should all be pals.
Admins dance with the coders’ daughters,
Coders dance with the admins’ gals.
(repeat)

I’d like to say a word for the admin,
She come out west when repos were in beta,
She came out west and built a lot of services,
And uploads PDFs with metadata!

The admin is a good and thrifty citizen,
no matter what the coder says or thinks.
You sometimes see ’em drinkin’ in the tea room.
And always wants download stats when she rings.

But the admin and the coder should be friends.
Oh, the admin and the coder should be friends.
The coder writes a script with ease, the admin holds the OA keys,
But that’s no reason why they can’t be friends.

Repository folks should stick together,
Repository folks should all be pals.
Admins dance with the coders’ daughters,
Coders dance with the admins’ gals.

I’d like to say a word for the coder,
the road he treads is difficult and stoney.
He codes for days on end with just a keyboard for a friend.
I sure do find he’s often tired and moany!

The coder should be sociable with the admin.
If he drops in looking like he needs bath water,
Don’t treat him like a louse make him welcome in your house.
But be sure that you lock up your wife and daughters!

I’d like to teach you all a little saying.
And learn the words by heart the way you should.
I don’t say I’m no better than anybody else,
But I’ll be damned if I ain’t just as good!

Repository folks should stick together,
Repository folks should all be pals.
Admins dance with the coders’ daughters,
Coders dance with the admins’ gals.

Suggestions for better lyrics are most welcome!

[If you want to see the original lyrics, you can view them at: http://www.stlyrics.com/lyrics/oklahoma/thefarmerandthecowman.htm]]]> http://feedproxy.google.com/~r/typepad/mleggott/loomware/~3/QenxhR2ARU8/ipad-app-for-islandora-repo-now-available.html <div><p>Our new iPad application, Telling Island Stories, is now available in the App Store (and yes it does support the retina display). TIS is a front-end to a number of <a rel="nofollow" target="_blank" href="http://islandora.ca/">Islandora</a>-based digital collections, with a focus on story and geo-level presentation of digital assets. As a lightweight iPad app it will give you a good example of what can be done with a powerful Islandora-<a rel="nofollow" target="_blank" href="http://fedora-commons.org/">Fedora</a> driven backend. Some highlights of this version:</p> <blockquote> <p>- provision of "collection" views via Media (images, audio, books, maps), Stories (associated subsets of assets) and Communities (assets sharing a geographic range);<br>- a map-based view of all assets, including media-specific pins, pin aggregation for larger numbers of items in close proximity (including the ability to turn this feature on and off), search/display via the map;<br>- flexible display including ability to toggle metadata display on and off by item, filter items by type;<br>- delivery of high quality retina-display quality books in a page </p> </blockquote> <p>Items available at launch include photographs from the University of PEI and community groups, herbarium specimins, digital books from the <a rel="nofollow" target="_blank" href="http://www.lmmontgomery.ca/">Lucy Maud Montgomery Institute</a>, oral histories from the <a rel="nofollow" target="_blank" href="http://www.islandvoices.ca/">Dutch Thompson collection</a> and <a rel="nofollow" target="_blank" href="http://www.islandimagined.ca/">maps from UPEI and partner organizations</a>. As content is added to the Islandora system it automatically shows up in the app - no need to download a new app just for new content. A future version will allow the user to submit content to a central repository.</p> <p>We are especially proud of the collaborative approach to making content from all parts of Prince Edward Island available to the world. If you are visiting PEI this summer you definitely want to download the free TIS app to your iPad!</p> <p>TIS is a joint development venture between <a rel="nofollow" target="_blank" href="http://upei.ca/">UPEI</a> and <a rel="nofollow" target="_blank" href="http://discoverygarden.ca/">DiscoveryGarden</a>, an Islandora services company, along with generous funding from <a rel="nofollow" target="_blank" href="http://www.innovationpei.com/">Innovation PEI</a>. If you are interested in adapting the TIS app to your own Fedora/Islandora framework <a rel="nofollow" target="_blank" href="mailto:mleggott@mac.com">drop me a note</a>.</p> <blockquote> <p> </p> </blockquote></div><div class="feedflare"> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=QenxhR2ARU8:0uWltsh9w2k:yIl2AUoC8zA"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?d=yIl2AUoC8zA" border="0"></a> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=QenxhR2ARU8:0uWltsh9w2k:F7zBnMyn0Lo"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?i=QenxhR2ARU8:0uWltsh9w2k:F7zBnMyn0Lo" border="0"></a> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=QenxhR2ARU8:0uWltsh9w2k:V_sGLiPBpWU"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?i=QenxhR2ARU8:0uWltsh9w2k:V_sGLiPBpWU" border="0"></a> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=QenxhR2ARU8:0uWltsh9w2k:EpLpB3ZkKWg"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?d=EpLpB3ZkKWg" border="0"></a> </div> mleggott tag:typepad.com,2003:post-6a00d83452e76c69e20168ebfdfa49970c Fri, 01 Jun 2012 13:11:18 +0000 http://feedproxy.google.com/~r/typepad/mleggott/loomware/~3/C4lfLSIF4_8/upei-senate-approves-open-access-policy.html <div><p>After a lengthy but very fruitful process UPEI's Senate approved <a rel="nofollow" target="_blank" href="https://cab.upei.ca/sites/default/files/attachments/OpenAccessandDisseminationofResearchOutput.pdf">a new open access policy</a>. Some highlights of the policy:</p> <ul> <li>immediate deposit of scholarly articles (including faculty, grad student and undergraduate works) in the UPEI repository is encouraged (a mandate was not considered a viable option - next time...);</li> <li>encouragement for scholars to retain copyright, including a reference to the <a rel="nofollow" class="zem_slink" target="_blank" href="http://en.wikipedia.org/wiki/SPARC" title="SPARC">SPARC</a> addendum;</li> <li>deposit of research data into a UPEI <a rel="nofollow" target="_blank" href="http://library.upei.ca/vre">Virtual Research Environment</a> is also encouraged, along with links to the final scholarly work.</li> </ul> <p><a rel="nofollow" target="_blank" href="http://islandscholar.ca/">IslandScholar.ca</a> is the UPEI open access repository, and it is currently undergoing a major re-architecture with a new launch this summer. The UPEI effort is also a key part of the new <a rel="nofollow" target="_blank" href="http://islandora.ca/">Islandora</a> Institutional Repository Solution Pack, which will be released this summer as well.</p></div><div class="feedflare"> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=C4lfLSIF4_8:ELE4kW3L6jE:yIl2AUoC8zA"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?d=yIl2AUoC8zA" border="0"></a> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=C4lfLSIF4_8:ELE4kW3L6jE:F7zBnMyn0Lo"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?i=C4lfLSIF4_8:ELE4kW3L6jE:F7zBnMyn0Lo" border="0"></a> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=C4lfLSIF4_8:ELE4kW3L6jE:V_sGLiPBpWU"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?i=C4lfLSIF4_8:ELE4kW3L6jE:V_sGLiPBpWU" border="0"></a> <a rel="nofollow" target="_blank" href="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?a=C4lfLSIF4_8:ELE4kW3L6jE:EpLpB3ZkKWg"><img src="http://feeds.feedburner.com/~ff/typepad/mleggott/loomware?d=EpLpB3ZkKWg" border="0"></a> </div> mleggott tag:typepad.com,2003:post-6a00d83452e76c69e2016766e80188970b Tue, 29 May 2012 12:16:15 +0000 http://blog.stuartlewis.com/2012/04/18/is-the-repository-developer-a-dying-breed/ Is the Repository Developer a dying breed, and should we care? Cast your mind back, perhaps seven or eight years.  It was the heyday of repository development.  Projects such as DSpace and EPrints were taking off, and institutions around the world were watching the area closely and with excitement to see where this glorious new [&#8230;] http://blog.stuartlewis.com/?p=769 Wed, 18 Apr 2012 11:59:22 +0000 Is the Repository Developer a dying breed, and should we care?

Cast your mind back, perhaps seven or eight years.  It was the heyday of repository development.  Projects such as DSpace and EPrints were taking off, and institutions around the world were watching the area closely and with excitement to see where this glorious new world would take us.

But back in those days repositories were similar to the early motor car – you needed a lot of money, several years, and your own mechanic/driver (developer) to make it work.  Luckily, back then these resources were often available, money was perhaps a little easier to come by, and there were many funding opportunities from the likes of JISC to help out too.

As the repository developer worked with the repository software for a few years, they became intimately related with the software – they knew how it worked, how it was structured, what it could and couldn’t do, how to structure data within the repository, and often became key players in the development of the open source platforms by taking on roles such as DSpace Committership.  Life was good, and I was lucky to be part of this, riding on the waves of e-theses, JISC projects (Repository Bridge, ROAD, RSP, Deposit Plait, SWORD) and the start of local institutional open access advocacy movements.

However… life moves on.  The early repository developers have taken different career paths, and now find themselves in different situations.

• Some have left the domain when the project funded projects slowed down, repositories could be implemented without a dedicated developer, and new areas of interest arose.
• Some have progressed in their careers, and chosen to take a non-technical route up the tree.
• Some have taken a commercial route, choosing to take their skills into the commercial sector and providing development services back to repository-using institutions.
• Others have specialised as repository developers, but often find their emphasis has to be on compliance or marketing issues such as statistics, research assessment, or branding, rather than continuing to develop and apply core repository functionality.

It is rare to find a role these days where a developer can specialise in repositories, spending the majority of their time in that area.

I believe there is still a need for repository developers, as they bring many benefits such as:

• An understanding of the technology that helps them to know when repository technology can and should be applied, and when it should not.  Often repositories do not appear to be suitable choices for some of our system requirements as we’re used to confining them to electronic theses and journal papers, but they have great potential in new areas.
• They know the underlying technology and data structures used by repositories, and how these can be mapped onto new domains.  This can save institutions time and money, as they can re-use their existing repository infrastructure and expertise, rather than in investing in others.
• Equally and opposite, they know the weaknesses of repositories, and where current or future functionality will not be suitable.
• They provide technical credibility.  Often repositories are run by libraries, but in environments where there are IT departments who may hold varying views on the technical development competence of the library.
• They make the running of the current repository/ies more smooth, and can help manipulate the data they contain (import / export / update / delete) in ways that are not supported by the native interfaces.
• Repositories are starting to become integration targets of enterprise systems such as CRIS systems.  Having a repository develop around can make these integrations easier.

I think we’re seeing a downward spiral in the availability of repository developers.  From time to time you see job adverts seeking experienced repository developers, and unfortunately they seem to be becoming a rare breed – a breed which I think we should protect, recognise, foster, and grow.  I’m lucky to have worked in several large institutions lately where there have been small, effective, embedded, and valued repository development teams.  However these types of teams are starting to become fewer and harder to find.

Opportunities for repository developers to network, learn, and share, are decreasing.  There are exciting events such as Open Repositories with their Developers Challenge, and the Repository Fringe, but these are only annual events, and do not provide the opportunity for repository developers to show their skills and the potential of repository technologies to anyone outside of the repository community.

How will this affect the repository community?  I think that there will be increasing problems in the repository world if repository developers become a very rare breed:

• The large open source platforms that we have come to rely upon (installations of platforms such as DSpace, EPrints, and Fedora number in the thousands) will find it harder to continue to develop and keep pace with current requirements.  The large amount of development effort that has gone into these systems over the past decade could be wasted, and we’ll fail to see some of the benefits that only come to fruition after this length of maturity.
• There will be fewer exemplars of good practice of repository use to inspire and drive forward the innovative use of repositories.
• Those who administer repositories will lose their local allies who are able to provide the tools and integrations to make repositories a local success.
• The potential for repositories to be involved in new hot topics such as Research Data Management, the resurgence of interest in open access publishing, or the need for better digital preservation may be missed.
• It will be even harder to recruit experienced and passionate repository developers, and without well-established teams of these, new developers thrust into the arena will find it harder to grow their skills and knowledge.

What should we, and can we do about it?  It think that we need to value the role of the repository developer, and continue to recognise that despite there being less requirement for a repository developer in order to run a repository, the absence of development skills may inhibit a good repository service from becoming a great repository service.  As we value multi-talented systems librarians, we should value the repository developer as a multi-skilled employee that allows us to correctly apply and integrate repository technologies.

Looking around at commercial companies that offer repository development services (for example Cottage Labs and atmire) we see the sort of innovative thinking that has so much potential in this area, and when I talk to staff involved with these companies there seems no shortage of people wanting their skills.  And this is good, and shows that there is a demand.  But equally I feel we need to keep growing these skills within institutions, and not let the local Repository Developer become a dying breed.

Repositories are in their teenage years, we nurtured them through birth, messy childhoods, promising early years, and now we’re starting to get a glimpse of how they can become powerful embedded tools.  But without the continued availability of skilled parents to shepherd their development, they may never reach their full adulthood potential.

[This blog post was written on the way to a DevCSI event for managers of developers, where we shall be looking at how we can show the positive impact of having local development teams within universities, and from my perspective and passion, their particular value to libraries.]site

JISC elevator is a new way to find and fund innovative ways to use technology to improve universities and colleges. Anyone employed in UK higher or further education can submit an idea. If your idea proves popular then JISC will consider it for funding. The elevator is for small, practical projects with up to £10,000 available for successful ideas. So if you have a brainwave, why not pitch it on the elevator?

A small team of us from the University of Edinburgh Digital Library submitted a proposal: The Open Access Index #oaindex.  The video submission is shown below…

I’ve previously blogged about the experience of creating this submission.  This post however contains a few observations about the Elevator concept, and the proposals that have been submitted.

First off – I’m a big fan of this system for a number of reasons:

• It gave us an avenue to submit this type of proposal for a small amount of funding (only a few thousand pounds)
• It provided us with a public platform and forum to socialise and discuss the idea
• It adds a more open peer review stage to the process
• It could encourage proposals from first-time bidders (although the public nature of it might put some people off?)

It will be interesting to see if or how the concept evolves overtime.  Last week I got to chat about this with Andy Mcgregor the JISC Programme Manager in charge of this, and Owen Stephens.  A few ideas that arose include:

• Restrict the number of votes that any one person can place – make voters think harder about which ideas are most worthy of funding as there is only a limited number of projects that can be funded
• Perhaps allocate each voter a set of votes or mock money or shares – they decide how they invest them across the proposals (all to one great idea, or spread across a few)
• Be more transparent about the funding each project has requested and who has voted

I’ve been following the different ideas as they’ve been submitted, and a few trends have surprised me.

The first relates to the funding band that the proposal falls into.  There are three funding bands: up to £2,500, up to £5,000, and up to £10,000.  There is a total of £30,000 being made available to fund some of the submissions.  I can’t tell what band the proposals that have already received enough votes for fall into, but for those that are still collecting votes, the breakdown is as follows:

I was surprised at the number that requested the full £10,000.  Of course, it could be that those in the ‘unknown’ category (those which  have already received the number of votes they require) are all in the lower bands, therefore require fewer votes, and are there now fully voted for.  When pitching an idea, I always consider the amount of money available, and therefore the likelihood of receiving a given share of that money.  In this case, due to the very limited funding, we chose to submit a proposal in the lowest band to (hopefully) increase our chances.

The second aspect of the submissions that struck me was the domain to which the submission relates. I’ve split these up into three very broad (and arguably very bad) categories: Learning (students / learning enhancement), IT (systems, development) and Library (materials, metrics).

The ‘education’ category received by far the most submissions, with IT and Library lagging far behind.  Indeed our #oaindex proposal seems to be the only one in the library domain.  Why is this?  Perhaps the amounts available are much lower in the IT and Library domains than we are used to bidding for?  Perhaps there are less opportunities for funding in the education domain?  Are those in the education domain better at seizing these new and innovative funding opportunities than those in the library or IT domain?  Discuss…!

When we created our video, we ensured that we mentioned who we were and which institution we worked for.  However it didn’t cross our minds to include any sort of branding in our submission.  I only thought of this when watching some of the others.

We were not alone, only a few included some.  Did we miss an opportunity here, or is the brand somewhat irrelevant to the format of submitting elevator pitches: should voters be influenced by the idea more than by the host institution?

Our submission took the format of ideas being drawn on a whiteboard, with a voice-over in the background.  I’ll openly admit that this was because none of us really wanted to stand in front of a camera for 3 minutes.  Given how much we laughed during the simple voice recording, I think doing this in front of the camera would have taken even longer.  Sorry – we didn’t keep the out-takes!!!

Voting for the proposals ends in a few days, and I’m looking forward to seeing which get funded, which don’t get enough votes, and whether or not the concept continues.  But the scheme certainly gets my vote for the periodic allocation of small amounts of funding for great ideas!

[ The data that I’ve collected on the proposals can be seen at: https://docs.google.com/spreadsheet/ccc?key=0AgXAkDGxqBWYdHR1c0l6Uzk5aDFfQzlaM0ZtV04wcVE I’d be happy to receive updates or corrections.]racer games

First, I should provide a brief explanation of the two routes:

• The ‘traditional’ route: Traditionally JISC requires bid proposals to be submitted as text documents, usually in the range of 6 to 12 pages.  These include cover sheets, budgets, benefits and risks, a bit about the people involved, and of course an explanation of the problem that will be investigated.  On top of that, there are letters of support and FOI checklists.  As part of the recent JISC Digital Infrastructure call, we submitted a couple of bids.  What we bid for is somewhat irrelevant, but I will disclose that the two bids we submitted were requesting funding of approx £30,000 each.  These proposals will now be marked by internal and external markers, followed by a panel decision.
• The Elevator route: JISC are currently running an experimental funding stream, known as the JISC Elevator.  The idea is that proposals should be lightweight, consisting of a brief video presentation, along with a few words.  No budgets, no letters of support, no FOI statements – just an elevator pitch about the idea.  This is the first difference.  The second difference is that ‘the crowd’, which in this case consists of anyone with a .ac.uk email address, are allowed to vote on which projects should be considered for funding.  Any that get enough votes will go forward for consideration by a panel.  The number of votes required are proportional to the amount requested, with three bands being up to £2,500, up to £5,000, and up to £10,000.  We pitched at the bottom end of this scale, meaning that we required 50 votes (which we received in less than 24 hours).

I’ll openly admit that the traditional route is often stressful.  It takes around about 1 week of effort (full time), usually spread over 3 or 4 weeks.  The final days tend to get quite frantic as everything is pulled together, we go through internal reviews and consents, seek letters of support, and pull the bid together for final submission.

In comparison, our pitch for the elevator took about half a day – an hour to refine the idea and seek approval, an hour to write a script, an hour to record the voices, an hour to make the video, and a few minutes to upload it.

The feeling at the end of the elevator process was markedly different to the end of the traditional process – and this felt good.  However, when you look at the sums (adjusted slightly to make the numbers easier)…

Elevator: 1/2 day = £3,000 potential funding
Traditional: 5 days = £30,000 potential funding

So the actual potential return per hour invested in bid writing is the same!

However if I extrapolate this to other bids I have written in the past, some of which have been for higher amounts, the trend does not seem to continue in a linear fashion.

My personal experience (your mileage may vary – it would be good to compare notes!), is that bids in the range of thirty to perhaps two hundred thousand, take a similar amount of time:  a week or so for a primary proposal author, and various time commitments from other parties.  But bids above this amount then start taking longer again, as project complexities, often around collaboration and external involvement kick in.

What can I conclude from this?  I’m not sure really!  Feel free to draw your own conclusions and to make comparisons with your own experience.

What I can say, is that we enjoyed the process of making, submitting, and then publicising our elevator pitch.  We felt that we had more freedom to be inventive with our interpretation of the submission requirements, and felt quite refreshed at the end of the process, rather than frazzled!

Now we await the outcomes of both…сколько стоит раскрутка сайта