Draft OR10 Challenge idea

Please note that what follows is a draft. A few weeks ago I posted some thoughts about a Developer Challenge for OR10, with a plea for ideas for specific challenges. I'm pleased to say that this post got a really good response, with plenty of useful ideas and comments. Thank you to all who responded. I think it fair to say that all of the comments influenced our thinking, but the interest in linking content ( most fully expressed by Andy Powell) stood out from several comments, so we have concentrated on trying to create a challenge around the this. While linked data was mentioned often (naturally enough), we wanted to stick to our principle of involving non-developers (or users) as much as possible: this can be difficult when dealing with the more esoteric aspects of linked data. So, after some discussion within the DevCSI team, we have worked up the following challenge:

Create a functioning repository user-interface, presenting a single metadata record which includes as many automatically created, useful links to related external content as possible.

Definitions:

• "functioning" in this sense means that mockups/screenshots are not sufficient - however a working prototype is OK
• "related" in this sense means that the external content is related to this particular metadata record in some way.
• "as many useful links" means that marks will be awarded for useful links, so an interface with fifty meaningless links does not beat one with three genuinely useful links!
• links must be related to content, not just a system. So, for example, a link to the page at http://www.wikipedia.org is not legitimate, but a link to a specific page in Wikipedia could be. Only one link of each 'type' counts: i.e. having four links to URLs which reference ‘topics’ in a given system is fine but will count as one link for the challenge.

Rules: Entries must come from a team of at least one developer and one person representing users. The entries must be presented, in person, at OR10. If a team is responsible for the entry then not all of the team members need be present at OR10, but at least one team-member must be. Judging: The entries will be presented/demonstrated at OR10 in a show and tell session in a room dedicated for this. The show and tell will be open to OR10 delegates to come along and see the presentations as they are being made. These presentations/demonstrations will be video-recorded. There will be an opportunity for those delegates present (the 'audience') to ask questions and/or comment on the presentations. There will be a panel of judges who will observe and make notes. The judges will take note of the responses from the audience. Following the show and tell, the judges will privately discuss the entries and draw up a shortlist. The videos of the shortlisted entries will be presented at the conference dinner for the assembled delegates to vote a winner and a runner-up. The judges will particularly take into account the following:

• functionality - the links must work and must have been created automatically as part of the repository system
• usefulness - the usefulness of the links to an end-user of the developed interface must be demonstrated
• number of links - the number and variety of links will be considered
• audience reaction - favourable and unfavourable reactions for the audience will be taken into account

General points: The Challenge will be issued well in advance of the conference, giving people plenty of time to develop an entry. We will make facilities available at OR10 - such as a Developers' Lounge area, for further work to be done at the conference itself. We are very interested in any comments people may have about this - we intend to publish the final version of this, and open up the Developer Challenge, at the end of this week.