At the Understanding Organisational Cultures workshop, I got talking to Andrew McGregor (JISC Program manager), and it came out that he has funded someone to look at biulding an iGoogle deposit tool.
I too have been thinking about this idea, and I have the deposit side mapped out, but the “social” side of it is still flakey… what ideas I do have are dependent on technologies/services that don’t exist yet.
Facebook OpenSocial deposit application
The basic premiss for this idea is that there is a recognised problem with getting deposits.
Yes, there is a problem with getting metadata; Yes there is a problem with sharing, duplication, and so forth…. but there is also a fundamental problem in getting authors to deposit.
Roughly speaking, less that 20% of research output makes its way into an IR; and less that 20% of that is author-deposited. This means that just 4% of the total research output is author-deposited. A problem indeed!
There are a number of ways that this can be approached, but one very strong contender is to “bring the deposit process into the users workflow”. There are many ways to do this. This idea is to use the realm of social networks to make the task of depositing easier
I have opted for OpenSocial over FaceBook, as OpenSocial applications plug into over 75 different web environments (including iGoogle & Bebo), whereas Facebook apps work in…. just Facebook!
(Having said that, the changes needed to get something to written for the OpenSocial API to work with the FaceBook API is, apparently, minimal)
The basic build-process for any application within the OpenSocial framework is twofold:
- There is a small app that displays a summary of “social information” gathered locally (eg from Bebo users in a friends-list)
- There is a main application that runs on the providers servers, and renders onto the OpenSocial canvas space.
The scope of this suggestion is not to determine how an application can be used socially, but simply to provide an application that will enable people to deposit from a familiar place (ie bebo, iGoogle, or Orkut).
To mis-quote Rufus Pollack “The coolest thing to do with your code will be thought of by someone else”.
Create the OpenSocial Deposit Tool, knowing that someone else will come up with other ways to use it.
I know that (data-)librarians have a bee about metadata, but when it comes down to it, user-supplied metadata is actually not a huge issue:
- Can we trust the academic to get the metadata right (especially when it is recognised that professional cataloguers are not 100%)
- Pretty much every IR out there is mediated – deposits are reviewed, amended, catalogued, and then finally approved.
A rough drawing of the OpenSocial deposit app
This is the basic version, one up from a proof-of-concept. It is simply a sideways step from the EM-LOADER project.
In this version, the target repository is hard-wired to the Depot, and the users name and password for SWORD depositing are held in the users preferences.
This will prove that it can be done, but does not help real Institutional Repositories.
Here we make the tool actually useful:
- Users can specify a preferred repository (good for when they are away from their institution)
- We use Repository junction to provide a list of local repositories (good as it makes the app almost self-configuring)
- We allow multiple deposits (notice checkboxes, not radio buttons)
Really really cool version
The really really cool version will do things like query PubMed (& co) for metadata; use tools such as content parsing to extract metadata; use Intute to see if the record already exists in Repository Land; use the Author Authority service for author names; and possibly handle updating records, not just depositing records.
The Social side
I’ve not really thought this one through much – one could pull in an RSS feed from your preferred repository, or maybe merge the feeds from the repositories found by Repository Junction.
Can you somehow link OpenSocial accounts with repository user IDs? (I don’t think so: too many people devolving authentication to their Institutional Authentication system)