You sharin'? You askin'?

I spent a couple of days at the JISC offices in London last week in meetings talking about shared services. 

The first was organised by the Strategic e-Content Alliance (SEA) and focussed on the role of registries, but in particular registries of collections and services, in the UK information landscape.

The second was a slightly more general workshop looking at shared infrastructural services (SIS) in the context of the JISC Repositories and Preservation Programme.

I'm not going to blog in any detail about the specifics of these meetings because reports from both of them will be forthcoming.  But there were a couple of common themes across both days which struck me as potentially interesting.

1. Registries and the Web architecture (yes, that Web architecture!).  Registeries, it seems to me, have an uncomfortable fit with the architecture of the Web because they surface information about resources (i.e. they surface representations of resources) at places on the network that are unrelated to their URI.  Does that matter?  Yes, unfortunately it does.  In the first meeting we were talking about the need for registries of collections and services to surface their 'very useful' content thru Google ("we need to put our high quality content in places where end-users will find it" is how the registry owner might put it).  Quite right too.  Unfortunately, simply letting the Google robots in to index stuff is only part of the problem - one also needs other people to link to the registry content, in order to bump up its Google-juice.  But end-users don't want to link to the registry content - they want to link directly to the resources described by the registry.  The registry ends up getting in the way.  Ultimately, it sucks Google-juice away from the very resources that it is trying to promote - a problem made even worse in the scenario (a typical scenarios as it turns out) where multiple registries agree to share their records and all surface them at multiple points on the network :-(
2. Beta as a virtue.  In JISCworld, activities tend to get given labels such as 'project', 'service in development', 'service' and so on (I've probably got the labels wrong here, but you get the idea).  The problem is that these labels implicitly tend to flag non-service activities as somehow worse than service ones.  In Web 2.0, beta is a virtue - the perpetual beta and all that - whereas in JISCworld thereis a danger that it is seen as problematic.
3. The unhelpfulness of labels.  My JISC IE architecture diagram has stood the test of time, but not without some problems.  One problem is that the rigidity of the diagram doesn't reflect the messiness of the real-world.  The truth is that there are no service boxes like the ones on the diagram in RL.  It's a myth - a sometimes helpful myth, but still a myth.  This becomes most problematic when whole JISC programmes take on a label from the diagram - the Portal Programme for example.  In the meeting on the first day we tried to come up with a reasonable definition of the word 'registry' but failed to come up with any form of words that couldn't equally be applied to the word 'catalogue'.  Yet JISC funds cataloguing activity (e.g Intute) as though it was completely separate from and different to registry activity.
4. Technology vs. users as architectural drivers.  One of the other problems with the JISC IE diagram is that it was largely technology driven.  In particular, in the area of shared services there hasn't been much work done on deriving the services we think we need based on real end-user requirements gathering.  At the meeting on the second day we were tasked with brainstorming ideas for services and applications that would make use of the current set of shared infrastructural services.  My group had no trouble in coming up with lots of service ideas (I took it as a personal challenge to think of at least one idea involving Facebook, Twitter and Second Life) but getting them to involve the current set of shared services was pretty contrived.  Perhaps it is time to take a fresh look - analyse the services and applications we want, then see what shared services are required?