By Peter Sefton and Mahendra Mahey

Pitching for the DevCSI Developer Challenge at Open Repositories 11

On the first day of pre-conference meetings at Open Repositories 2011 we started promoting the DevCSI Developer Challenge. We visited all of the meetings we could and encouraged people, to:

• if at all possible, enter
• come along to the Developer Lounge during the conference and at the final ’Show and Tell Session’ on Thursday afternoon to see ‘the future of repostiories’
• encourage any of their colleagues who might have good ideas and some development skills to step up.

Each of the meetings had a different mood. The Fedora Commons committers were committed to solving fundamental architectural questions around authentication, authorisation, modularity and so on. The Hydra Partners were heads-down bringing together threads of work that have been going on all over the world on a major application. The Curate Camp, was set up as a kind of unconference where delegates had to choose/vote from a list of topics (e.g. community consensus on the tools, specifications, and microservices that are most needed; use cases for those tools, specs, and services; and interoperability among tools and repositories/digital asset management systems) in the area of curation, either presented prior to the meeting or during and discuss them for 30 minutes. If discussions were deemed valuable enough to continue, they did, if not, they moved on to the next one

And the DSpace group had started their session with some blue-sky dreaming. They compiled a list of points on “What’s the modern Repo?”. This is pretty close to our developer challenge theme of “The Future of Repositories”. Below, see a transcript of a whiteboard, taken from an EtherPad document from the DSpace meeting that we were not attending, via Tim Donohue. Might lack a little context, but worth glancing through for inspiration.

There are some key words and phrases here we might have heard 5 years ago at the first OR in Sydney, such as “submission should be much much easier” or “preservation”. But back then we would not have been hearing about Dropbox, the beautifully simple cloud-based file replication system or the SWORD deposit protocol because they were not invented yet and nobody knew we wanted them until developers made them.

One thing on the list is “new name”.  A potential entry in could be built around that. Think of a new name instead of repository and show something that demonstrates what it would look like.

Or could you re-imagine the repository as set of small pieces that all “do one thing, [&] do it well”? Get one piece working, and tell us about the rest.

“What’s the modern repo?” Brainstorm

Link (including photo: https://wiki.duraspace.org/display/DSPACE/Brainstorming+Activity)

- not just research: photos, music, data, etc

– More different kinds of content and metadata

- research management systems

– CRIS moves the repository to the back-end. As CRIS will be the front end

– In edinburgh, PURE is being used with the LNI to ingest

- simple (visual?) import — think dropbox?

- DepositMO

- SWORD / SWORD2

- Scott: submission should be much much easier.

- Bram: ScribD also had very easy upload, but poor in metadata. Nice  feature in embedding lists & collections in other applications

- automated metadata capture

- content easy to use / reuse

- CRUD

- branding / theming

- customisations (metadata and metadata structure)

- storage system integrations

- flexible content workflows

- versioning / relationships

- flexible authorisation

- give control to user communities (branding, etc)

- complex objects (representation of), human- and machine-readable

- scientific data sets

- reporting

- content reuse (“open” data)

- eg. embed in dept website

- search (easy)

- faceting / filtering

- statistics: regular reports to item authors (like Digital Commons), plus usage/admin reporting

- bot filtering

- getting stuff out

- disciplinary aggregation

- creating adhoc “sets” of content

- (this made me think of http://www.apsr.edu.au/orca/ - Kim)

- shareable metadata

- different metadata “views”

- shared version vs local use

- new name: just “repository” or “storage”?

- preservation

- identifiers / persistance (flexible, granular, parts of items, people, collections)

- the perils of handles…

- DOIs vs Handles

- Truly *external* IDs

- access / privacy

- “repository / DAM system that can display stuff vs. CMS that can do DAM”

- do one thing, do it well

- flexible metadata schema

- dissemination

- make data usable

http://piratepad.net/or11dspacemeeting

[Update: added license]

Copyright Peter Sefton and Mahendra Mahey, 2011-06-07. Licensed under Creative Commons Attribution-Share Alike 2.5 Australia. <http://creativecommons.org/licenses/by-sa/2.5/au/>