Tag Archives: repositories

Facebook advertising Open Access “Are you a researcher?”

Leave a reply

2012 has been a busy year in the world of Open Access.  From a UK funding point of view, the big news has included the Finch Report and the RCUK’s reaction this in its new Policy on Access to Research Outputs.  To cut a very long story short, the RCUK is now providing £17+ million to UK institutions (pro-rata to the size of grants) to help fund Gold Open Access: that is, payments of Article Processing Charges (APCs) in order to make journal papers free at the point of use, from the publishers’ website, with a Creative Commons By Attribution (CC-BY) licence, at the time of first publication.  There are many on-going debates about how to proportion this money, exactly what is covers, and how best to administrate and report the spending.

An unsurprising reaction to this has been from the open access hybrid publishers.  Pure Open Access Publishers (BioMed Central, PLoS etc) already run their business model this way.  Traditional publishers have had to introduce hybrid approaches to allow Gold APCs to paid to make papers available which would have normally been funded by subscriptions.  The latest changes for hybrid publishers have been to take into account the requirement for the CC-BY licence.  An example is the Nature Publishing Group who have introduced differential pricing based on the Creative Commons licence selected, for example to make up for the shortfall of income from reprints.  Another example is Wiley and their new Open Access schemes.

However the point of this blog post was my surprise at logging into Facebook this morning…

springerfacebook

In case you missed it, here is one advert in particular that I’ve not seen before…

areyouaresearcher

Clicking on this takes you to Springer’s web page on Open Access:

springer

Springer is advertising on Facebook to let authors know about their journals and open access publishing options, and most importantly, that there is money from RCUK to back it up (for RCUK-funded outputs).

I don’t want to pass judgement on this, I don’t really have an opinion on it, however it is an interesting development!  Those of us who work closely with these Open Access initiatives and the RCUK block grants need to be aware of the messages that are being put out there.  This is a new message in a new medium!

A prize will be offered for the first (genuine!!!) enquiry received about Open Access and the RCUK funding from an author who ‘saw it on Facebook’!  It will be interesting to see how well this message propagates and is understood.

Oh, the admin and the coder should be friends!

1 Reply

This is a tongue-in-cheek blog post a few days before the Open Repositories 2012 conference that is being held here in Edinburgh. I’ll give a bit of background first, a disclaimer, a video, then the main content of this post.

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]

Is the Repository Developer a dying breed?

4 Replies

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.]

Building a ‘blogliography’

Leave a reply

I shall shortly be moving on to pastures new from my current role at The University of Auckland Library. Before I depart, I wanted to document a few of the projects that I have worked on during my (almost) three years in Auckland, the first of which is contained in this post: a project to build a new online bibliography for the New Zealand Asia Institute.

As a library, we host a lot of online collections, many of which are simple bibliographies of materials relating to a particular subject.  In this case we worked with the library’s Business and Economics subject team to build an online bibliography of materials concerning the business interactions between New Zealand and Asia.

Here is a list of some of the high-level requirements we were given:

  • Small scale (a couple of thousand records)
  • Import data from an EndNote library (initial import followed by periodic updates)
  • Multilingual content (English, Chinese, Japanese, Korean)
  • Additional static content
  • Provision of RSS feeds

Traditionally our library has used a product from http://www.inmagic.com/ to deliver this sort of site. However this time we tried something a little different… we built it using blogging software.  To be more precise, we built it using the WordPress blogging platform (the same software as powers this blog).

Here are some of the reasons that we chose WordPress:

  • WordPress sites can contain a mixtures of blog entries (in this case bibliography entries) and static content.  NZAIS has a static home page and other static content, along with lots of entries.  Each entry in the bibliography is a blog post.
  • Being a blogging platform, certain features such as word clouds and RSS feeds are part of the standard configuration.
  • Like all well-mannered systems, it defaults to UTF-8, meaning the multilingual content poses no problem.
  • WordPress supports themes.  It is very easy to choose a suitable theme, and then customise it for your specific needs (colour scheme, logo, etc).
  • The system can be extended using plugins.

The last point is one that was particularly pleasurable to work with: the majority of the requirements that could not be fulfilled directly with WordPress could be delivered using a third-party free plugin.  In order to turn a traditional blog into a useful online bibliography, we used the following plugins (in alphabetical order):

  • Breadcrumb NavXT:  Used to provide breadcrumb functionality to assit the user know where they are in the site
  • Bulk Delete:  Useful when developing to remove old content, or when performing a complete re-load of data
  • Custom Field Template:  WordPress supports ‘metadata’ through the use of ‘custom fields’ which can be set for each post.  This plug allows that metadata to be set via a template for each post
  • Google AJAX Translation:  Allows individual entries (blog posts) to be translated on-the-fly without the page being reloaded.  Useful for translating between English / Chinese / Japanese / Korean content
  • Google Translator:  Adds a translate widget to see the whole site translated into a different language
  • Search Everything:  Modified the search system to search all fields, including the custom fields
  • CSV importer:  Data from EndNote was exported to a text file, and a short Java script used to convert it into a CSV (Comma Separated Values) file which was then imported using this plugin.  We modified this plugin to support multiple values in some fields (for example to allow multiple authors to be inserted for a single item)
  • Custom Field Taxonomies:  Builds controlled vocabulary functionality into custom fields / metadata

The site can be viewed at http://nzais.auckland.ac.nz/

The following screenshot shows the use of metadata fields (custom fields) for an entry in the bibliography:

[This development took place in late 2009 / early 2010.  It was a successful project and proved that WordPress is a flexible platform for delivery a site such as this.  However the technology used to power this site is about to change, not because of any problem with the site, but due to a rationalisation of platforms in the library.  With an ever increasing number of similar collections needing to be developed each year, we decided to develop a single solution for those collections that don't fit into our traditional repository offerings (DSpace research outputs repository or ExLibris DigiTool).  To this end we developed what we've called the Super Index.  More about that in another post...!]

The collection is dead! Long live the collection!

6 Replies

“The collection is dead! Long live the collection!”  That summarises my current thoughts and feelings about the collection hierarchy structure in DSpace.

When first installed, DSpace shows its need for a community and collection hierarchy, because without at least one community, containing at least one collection, it is impossible to even submit an item.  Therefore, from day one, DSpace repository managers get used to creating collections, giving them names, and creating a hierarchy.  Having created a first community with its first collection, it seems silly to have just a single community and collection.  So the repository managers creates a larger hierarchy – often mimicking the organisational structure of their institution.  Often this hierarchy extends down to departments, research groups, even individuals.

And the repository manager feels good.  There is structure which will give people a sense of belonging, and more importantly, ownership of ‘their collection’.  This will help them gather content for their repository by helping the individual or research group feel that it is their space.

Very often of course it means that a repository has a lot of structure with empty collections.  Also it leads to other problems – what about theses?  We want them to appear in their department’s collection, but also to appear in our central library thesis collection for harvesting by a service such as EThOS.  Or what a about an article that has been co-authored by people across different departments?  Or departments that move around in the organisation.  This collection structure is starting to feel a bit inflexible and restrictive!  What started of as a useful tool that made us feel ‘organised’, now feels the opposite.

Luckily, help is now at hand!  Since version 1.7 DSpace has included the ‘discovery’ module.  This is nothing ground-breaking as such, just a faceted search feature using solr contributed to DSpace by atmire.  The real beauty and power of faceted search comes with their ability to make ‘virtual collections’.  You want a collection of theses published by the faculty of science: sure – just link to the type:thesis + faculty:science facet search result page.  You want a collection for Prof. S Smith?  No problem, link to the author:s. smith faceted search result page.  Want a collection of the ‘recent’ publications of a department?  Just link to the department:foobar + year:2011.

Facets give us the ability to create ‘views’ over the data, based on properties (metadata) of items.  Maybe this is why Google and other search engines are more popular than http://www.dmoz.org/?  We like to have our own collections defined instantly by a search, not be forced to traverse a hierarchy dictated by others.  Of course this does rely on quality (consistent / present / correct) metadata to ensure that items all appear in their virtual collections.  To conclude – sometimes it feels like “The collection is dead!”.  We have better ways to create structure over the repository rather than through it.

But wait!  I cry “Long live the collection!”.

Whilst in our main ‘institutional repository’ at The University of Auckland Library (http://researchspace.auckland.ac.nz/) we have been rationalising the number of collections we have and removing most of organisational structure, we have been making use of DSpace collections in another very useful way…

We’re halfway through a project known internally as the SuperIndex.  Not (just!) because it is ‘super’, but because we are creating a super-index of many of our disparate bibliographic and digital special collections.  We have many databases of collections all over the place, and the SuperIndex project aims to bring them all together into a single system.  This will make management of the collections more consistent, while reducing the number of systems to maintain.  DSpace is our chosen central management system.

This is where the collection structure is becoming very useful. Each collection of items really is a collection.  An item in a database about fisheries in New Zealand will not (or is unlikely to!) appear in any of our other special collections.  This collection structure makes it easier to manage each collection separately.  We can run curation tasks on a collection, or control who has rights to edit a collection.  The management of this repository is much wider than the institutional repository that is just administered by one team.  We will have staff in many areas editing the items.  It also allows us to create individual websites for each collection, each with their own URL structure and branding – the end user does not know that the item they are viewing is actually managed in a DSpace somewhere, and that the DSpace contains thousands of other items in different collections.

So the ‘collection’ is starting to become less useful in the standard institutional repository of research outputs (which is, in a way, a single collection) but is having a new life for us in managing what could be seen as more traditional ‘collections’ in a single DSpace repository.

I’d be interested to hear what you think are the strengths and weaknesses, or reasons for and against forced collection hierarchies in DSpace.

“The collection is dead! Long live the collection!”

Android SWORD deposit mobile app

2 Replies

As part of the Open Repositories 2011 Developers Challenge, our team submitted a few different prototypes that formed our vision of ‘The Future of Repositories’.  Our whole entry centered around the theme of ‘Raas’, or ‘Repository as a Service’.  The notion of RaaS included the ability for the Repository become a commodity which could be switched in and out of our infrastructure.  In order for this to happen we required interoperability at multiple levels – we demonstrated two: ingest (using SWORD) and discovery (using Solr).

One of the prototypes was a new deposit application using SWORD.  It was written for the Android mobile operating system, and was designed to deposit photographs into repositories.  The use case for this is for social scientists who want to capture photographs straight into trusted storage – a repository.  One of the benefits of taking photographs with mobile phones is that they are usually now geo-tagged using the in-built GPS functionality to stamp the photo with the location where it was taken.  Of course the modern smartphone is a great data collection device, and could be used to capture many different kids of data, ready for deposit.  The notion of ‘citizen science‘ could come in to play here with a large set of distributed data collection devices in the pockets of millions of cell phone users.

Android has a nice ‘Share’ system, where applications are able to share files with one another.  If you take a photo or look at one in the photo gallery application, you should be able to find the ‘Share’ option.  From here you can share the photo with applications that know how to consume photos, such as posting to Facebook, sending as email attachements, or adding to tweets on Twitter.  Using our new application called ‘SWORD Share’, you can now deposit the photos into a repository!

If you have an Android phone, launch the marketplace application, and search for ‘sword share’.  Alternatively visit https://market.android.com/details?id=org.skylightui.swordshare&feature=search_result or scan the QR code.

When you launch the application you’ll be prompted to enter your SWORD server details: Author name, username, password, and the deposit URL.  If you don’t have easy access to a repository, you could try depositing to the DSpace Demo Server.  Use the following details: Name: Your name, Username: dspacedemo+admin@gmail.com, Password: dspace, Deposit URL: http://demo.dspace.org/sword/deposit/10673/39403

You will then be able to ‘share’ a photo you have taken, and a username and password, and deposit it to the repository.  Once the deposit has finished, you’ll be given the URL of the deposited item.  Just one thing to note if you use the demo.dspace.org system: It looks like the handle server isn’t currently running on that server, therefore if you receive a URL back such as http://hdl.handle.net/10673/{12345}, to see your item, instead visit http://demo.dspace.org/jspui/handle/10673/{12345}.

I’d be interested to hear about your ideas for the application, and if it worked OK for you!

Of course the code is open source, and housed in github.