As our project draws to a close, it is instructive to look back at the composite view that we have built up of the state of play with Relationship Management in our stakeholder group at Loughborough. This is illustrated quite nicely in the diagram below, which shows the various external facing University units operating very effectively in parallel, but maintaining their own contact and project databases and thus losing the economies of scale and synergies that would apply from a more strategic approach.

We are proposing a way forward that would see a unified approach to gathering and maintaining information about partners, together with details of contacts with them, joint projects and so on. What has been very interesting is that our stakeholders quite rightly saw the introduction of an IT system in support of Relationship Management as a secondary activity, contingent on us developing a fuller understanding of our own processes. The consensus view at a recent stakeholder workshop was that we should begin by profiling the extent of our involvement with a small number of key partners, across the spectrum of organizations that the University is involved with. It was felt that these should include the likes of a commercial partner, another Higher Education Institution, a charity or Non-Governmental Organization, and central Government.

The approach to process mapping developed for the JISC project should prove highly valuable as we move forward to take a broader and deeper look at institutional practices. Even from the relatively small number of processes we studied, it was clear that things were often more complex than they needed to be, and that there were any number of opportunities for “quick wins” to improve the efficiency of existing processes and procedures. The diagram below demonstrates this general principle by showing some of the steps involved in the production and distribution of the University’s undergraduate prospectus.

In reality the process is far more complicated, and student recruitment more generally takes in the likes of student “ambassadors” visiting schools and prospective student visits to the University. In our primary context of Business and Community Engagement there are direct parallels with the less immediately tangible benefits that accrue from “networking” events and groups such as the Innovation Networks set up under the auspices of emda, the East Midlands Development Agency.

The graph below, by Christian Bizer, illustrates some of the links and relationships between well known sets of data – note that this was put together before the release of data.gov.uk.  You can read more about this work at the WWW2009 Linked Data on the Web workshop site.

In the context of our work on Relationship Management for JISC, it’s particularly interesting that there is a mixture of data collected by very different bodies and for different purposes shown here, and also to consider how it can be made possible to link from one set of data to another.  When a piece of data is tagged with a particular identifier we also need for that identifier to come from a common shared vocabulary or at least to have an agreed set of mappings from the vocabulary used in one database to that used in another.  Examples that have some relevance in our context are HESA JACS codes and Companies House Company Numbers.  When used in combination with structured data in a format such as XML, many doors are opened.  For example JACS course codes and XCRI course advertising in combination potentially allow a prospective student to “shop around” to see which institutions offer a particular course.  Further linked data sets could make this an extremely powerful tool by linking directly into the institutions’ course materials on their Virtual Learning Environments, iTunesU, YouTube, etc.

At Loughborough we have been looking into the feasibility of taking the Linked Data approach for tracking some of our research and business partnerships, and found quite a few pitfalls.  Higher Education institutions tend not to go bust and only infrequently merge or change their name.  In the commercial world this is a matter of routine, and further complicated by the likes of holding companies and wholly owned subsidiaries.  Even settling on a name can be a fraught process.  Is Loughborough’s Systems Engineering partner BAe Systems also referred to as BAe and British Aerospace?  You bet!  Additionally, in some key areas we will need to collect further information to link existing datasets.  For example, our publications database is not presently aware of co-authors’ institutional affiliations.  Similarly, whilst research proposals have to be processed on a standard University form before they can be submitted to the funding councils, information about project partners is not presently collected in a structured way on these forms.  At present we adopt a human assisted approach to populating our Institutional Repository, and in our interviews for the PIPaL project a commonly expressed view was that something similar would be desirable to ensure consistency when exploring the possibilities opened up by a Linked Data approach.

A particular eye opener from the first round interviews has been the mountains of paper – there really is a lot of material in circulation that isn’t directly usable by any computer system, even if the vast majority of it started out life that way.  A good example of this is the University’s press coverage, sent to us on paper by a commercial clippings service.  When we started mapping existing processes it was also quite striking to see areas where there is no feedback loop to speak of.  For example, when sending the University Prospectus out to schools and colleges we gather very little information on how it has been received and the effect it has on decision making and the application process.  The old adage about a picture telling a thousand words is very true – once this particular process was turned into a diagram it was obvious that there was a problem.  In this case the people involved already knew that we could do more, but I expect that we will find others that are more obscure as the project progresses.

The event was aimed primarily at developers working on projects in the Rapid Innovation programme, giving people an opportunity to share information, compare notes, and promote their work.  A very valuable part of this was a media coaching exercise, that gave delegates the opportunity to hone their presentation skills, with advice from media professionals and JISC programme directors.

Many of those present were working with leading edge “Web 2.0″ technologies, such as Google Wave and Yahoo! Pipes.  This is very interesting from the point of view of a project like PIPaL where we are concerned with information that the institution considers sensitive – e.g. details of potential partnerships.  We can begin by considering the circumstances under which personal information was provided to the University and any restrictions that might apply to sharing this between the University’s departments and functions.  Following on from this, there are further Data Protection implications regarding the use of third party Internet services for modelling, visualisation etc.

Whilst it’s no substitute for being at the conference in person, you can follow the discussions via #jiscri Twitter posts, the IE demonstrator blog and Photos from Flickr.  Personal highlights included Scott Wilson’s presentation on the Apache Wookie Widget server, showing W3C standard widgets embedded within the Moodle VLE, and Peter Pratt describing the Walking Through Time Google Maps historical map mashup.  It was also very interesting to hear from Symplectic’s Richard Jones on their work on Institutional Repository deposit architectures, and to catch up with my old eLib colleague Jasper Tredgold on the Mobile Campus Assistant project.

Several bar and BoF discussions were had around the typical research focus of the Institutional Repository versus the VLE’s role as “Learning Object Repository”, and the feeling of personal ownership of the material uploaded to the VLE – inhibiting information sharing and re-use.  There is a clear parallel here with partner relationship information gathered by individuals or departments/sections.

Google Docs permits multiple collaborators to edit a document and see the results of each others’ changes in real time – without having to email it back and forth, save to a shared hard drive, hand around USB pen drives etc.  This is not to imply that Google are the only choice – for instance, Microsoft have a similar system called Office Live.  A particular advantage of these services is the ease with which collaborators who are not part of one’s home institution can be involved.  We will probably end up sharing our space with our associates from JISC CETIS, members of the other BCE project teams and other external advisors.

Wordle word cloud map of journals that Loughborough academics publish in

This is the result of running two 5 line Perl scripts against our corporate publications database – snarfing out all publications in something with ‘Journal’ in the title and then massaging a little.  Wordle (see http://wordle.net/) make the cloud map using the frequency data for the journals published in.  More publications in journal X == Bigger font for it in the word cloud.  If you want to use Wordle in a similar way, note that you need to change all space characters ” ” to tildes “~”.

Guess what discipline is really big at Loughborough  Some of the other headliners were equally obvious, but the next level down starts to get quite interesting.  In terms of PIPaL, the question is whether we could do something similar using what knowledge we are able to glean of people’s external partner relationships – picture company names in the cloud rather than journal names.  Next step academics’ home pages, methinks.

http://code.google.com/apis/searchappliance/documentation/60/oneboxguide.html

The GSA has been unboxed, racked up, and given a minimal config – but we have some more work to do to figure out things like which authentication mechanism to use, and also (ironically) to ensure that we don’t reveal to the world those indexed resources that would not normally be viewable outside of our IP range.