Stuart Lewis’ Blog

Yesterday afternoon I was slightly bored, and was looking for small experiment to do in order to take my mind off of the reports I was in the middle of writing. The experiment ended up taking the form of messing around with the new CISCO 7941 IP phone that landed on my desk a few weeks ago.

I’d previously played a little with the web dialer feature that comes with the CISCO CallManager software which allows you to program the phone via a web interface. The web dialer allows you to either look up a user in the directory, or enter a number manually, and then your phone will automagically dial the number you requested. Cool stuff

Now I like messing with web forms, and decided to work out how it works, in order to rewrite in a more useful way that suits me. The following is the form that I cam up with, both form my own records, and in case it proves useful for anybody else:

<form action="https://*/webdialer/Webdialer" method="post" target="_new">
    <input type="hidden" name="cmd" value="doMakeCall" />
    <input type="hidden" name="sub" value="false" />
    <input type="hidden" name="red" value="null" />
    <input type="hidden" name="destination" value="**" />
    <input type="image" src="***.jpg" width="150" />
  </form>

*: The URL of your call manager installation

**: The number you wish to dial

***: In this case I used an image to submit the form - I have a page of photos of people I want to ring, and click on their name to ring them.

‘Preserving reactions to Lord Of The Rings’ is a funny blog posting title, but I’ll explain…

Back in 2003 to 2004, our department of Theatre, Film and Television Studies undertook the biggest audience response survey to a film ever. They collected just short of 25,000 responses to the films from speakers of 14 different languages. The project is now finished, published, and they’re hoping to move on to even bigger projects of the same type. So the work is ready to archive in our repository, and its my job to archive the data in such as way as to enable and ensure preservation.

Now, I’m no preservation expert, so the following details what I did to archive the data which was given to us in the form of a Microsoft Access database, and a word document explaining the structure of the database and the codings it used:

• The database: Well, nothing wrong as such with archiving an Access database - it can easily be used by people today. So that gets archived. But what about a long-term copy for archival and preservation purposes? Access has a nice handy ‘Export to xml’ feature. That looks good! It even gives the option to ensure the file is correctly encoded in UTF-8 to preserve the audience responses in different character sets. (As an aside, the xml file is about 40MB big, so I found in order to get an xml editor to open the file in order to validate it and check the encoding I had to upgrade the RAM on my VIsta workstation from 2Gb to 4GB!).
• The guidance notes: These came in Microsoft Word format, nice and easy, so that gets archived. A PDFa copy is then created using Microsoft Word’s ‘Export to PDF’ option, and that is archived too.
• The repository: All this is stored in a DSpace-powered repository, has daily file checksum checks being run to detect bit-rot, backed up nightly to disk and tape, with off-site copies of the tapes stored.

Now to a non-preservation expert, this all sounds too easy. Have I been naive and missed any thing out? (Wouldn’t surprise me! )

I’m traveling back from the RSP Summer School 2008 which has just finished. It was held up on the Wirral at Thornton Manor. The manor house, formally owned by Lord Leverhulme was a fantastic venue, and the food was top notch! Whilst there I gave an impromptu SWORD masterclass, and chaired the session on ‘Advocacy’.

The first of two presentations was given by Mary Robinson from SHERPA, who talked about her advocacy work for The Depot.

The second of the presentations was given by Niamh Brennan from Trinity College Dublin. This talk just blew everyone away - it was inspirational, practical, based on real experiences, and gave ideas that all the repository managers could take away with them and implement quite easily.

These are some of the insightful snippets I took away with me:

• TCD populate their repository from their CRIS. Personally I believe this is the way to go, and enjoyed the chance to talk to Niamh about the technical side of the CRIS. I’ve yet to find an open source CRIS, and was wondering if this is because so much local integration would has to take place to stitch a repository into local systems, that once you have done that, the core CRIS might as well be developed from scratch. Niamh says that this is not the case, and that a core CRIS is big enough to be worthwhile sharing (and hopes to share theirs! )
• Get in contact with, and stay in close contact with, your local research support office. They deal with the grant process, and are a good way of making contact with academics. A good time to explain the impact of the funder mandates to researchers is when they are signing the T&Cs for their latest grant.
• When it comes to publicity events, always celebrate success! Rather than having a formal launch of your repository, why not have a celebration of the items you already have in there, and the impact that has had.
• Make people feel good - they like that! Possible examples include ringing up academics who have been in the news congratulating them, and offering to archive their work. Or make some of your depositors “Featured Authors”. People like to be ‘featured”!
• Always try to get drinks at events, and once you have drinks, get some food. Once you have food, get some wine. Once you have wine, get some champagne. Once you have champagne, get a photographer. There’s nothing more that some people like that having a glass of champagne and having their photo taken at an event. This can be a powerful way of attracting senior managers.

It has been announced that JISC have commissioned the creation of a new repository aggregator site:

JISC Repository Aggregator Website 

JISC funds a wide variety of development projects on behalf of its funding bodies. These projects include consultancies and supporting studies where the main deliverable is a report and projects where the deliverables include products and services as well as these reports. 

The project involves developing a small user community to guide the development of the site, to produce the site and to develop a series of bespoke widgets to draw information from readily available sources of information. 

The overall aim of this demonstrator site will be to enable a user to search for, organise and hand submit information about a range of relevant information about repositories. The repository aggregator will provide a single destination where people interested in repositories can get information about digital repositories. 

Aims and Objectives 

The objectives of the aggregator website are to: 

Produce a demonstrator website that can be shown to some members of the repository community to gauge whether they would find such a service useful. Then, make the service available as a public beta offering while plans are made to develop the site further. 

Create a customizable and personalisable solution that can adapt to the wide range of information that a user might like to aggregate. 

Specifically ensure the service can aggregate with RSS feeds from relevant blogs, the Intute Repository Search service, information from the RSP site including support contacts. Statistics from OpenDOAR and ROAR, Sherpa RoMEO and JULIET, brief explanations of key topics, persistent aggregated search of sources like google scholar and technorati, subject based collection details from IESR, descriptions of useful repository software, e.g. IRstats, feedforward, sword client, manakin and RSS feeds from relevant repositories. 

Create focus groups in a structured way to help manage the feeback from the user community at all stages of development. 

Specific development requirements include the consideration of the Netvides Universal Widget API, Netvibes Universe, an authentication system, cross browser compatibility. 

(No, not ‘widgets as found in cans of beer‘, but widgets as in ‘web widgets‘!)

It is an interesting development and with my repository stats hat on (http://maps.repository66.org/) I’m particulaly looking forward to seeing what this aggregation can offer, and the value it will provide.

I’ve just returned from the latest CRIG (Common Repository Interfaces Group) meeting at Bath University. In typical CRIG fashion the event was held in a bar, where the food and drink flowed freely. The CRIG team ran an excellent event are are now quite used to running useful, informative and thought proving events.

This particular CRIG event was entitled ‘CRIG DRY Workshop’ - DRY = Don’t Repeat Yourself, and today that referred to metadata.

The day started with 5 five minute presentations, one of which was the first public outing for our new project ‘The Deposit Plait‘. This fitted in perfectly with the aims of not repeating ourselves when it comes to depositing items into a repository, and having to typically re-enter metadata.

There are three strands to a plait, and three strands that we hope to weave together in the deposit plait project:

1. Work out exactly what metadata ideally needs to be provided when depositing a scholarly work into a repository. This can be done by seeing who makes use of repository metadata, and what metadata they need in order to do this effectively.
2. Investigate what, if any, metadata can be extracted from XML documents in formats such as OOXML and ODF.
3. See what metadata can be extracted from online or personal bibliographic systems.

So were 1 and 2 to yield useful results, we could investigate the feasibility of writing a web service that take an uploaded document (or a reference to one), extracts some metadata (maybe title, author, abstract) and then uses these to pull in more metadata from other systems. Might be neat, might be a non-starter. That’s what the project will discover.

Anyhow, the event was useful in a number of ways, and there were a number of nice demonstrations. I particularly liked Richard and Rob’s demonstration of depositing OAI-ORE aggregations into DSpace using SWORD. On top of that there was then the resource map encoded in RDFa in the DSpace item page allowing an RDFa reader to use a standard DSpace metadata jumpoff page as an OAI-ORE resource map. The really nice thing about it was that from the DSpace side, it only required a new packager class, and a corresponding entry in the configuration file - I was thinking it might require more tinkering. I also appreciated the ORE talk from Rob. Whilst it only lasted 5 minutes, it was enough to explain the concepts and gave me the dummy’s guide that I’ve been looking out for for some time.

Thanks CRIG!

One of the many great features of Google Analytics is that it can shown the search terms that visitors to your site have used in search engines. This is a great tool for finding out what brings users to your repository.

Seven months ago Google launched a new feature in Google Analytics that also allows you to track the search terms used by visitors within your repository. Its very easy to set up, all you need to do is enable the feature and set the query parameter used by your repository. Follow these rules from the help pages:

1. Log in to your Google Analytics account.
2. Click ‘Edit’ under Website Profiles for the profile you would like to enable Site Search for.
3. Click ‘Edit’ from the ‘Main Website Profile Information’ section of the Profile Settings page.
4. Select the ‘Do Track Site Search’ radio button in the Site Search section of the Edit Profile Information page.
5. Enter your ‘Query Parameter’ in the field provided. Please enter only the word or words that designate an internal query parameter such as “term,search,query”. Sometimes the word is just a letter, such as “s” or “q”. You may provide up to five parameters, separated by a comma.
6. Select whether or not you want Google Analytics to strip out the query parameter from your URL. Please note that this will only strip out the parameters you provided, and not any other parameters in the same URL. This has the same functionality as excluding URL Query Parameters in your Main Profile - if you strip the query parameters from your Site Search Profile, you don’t have to exclude them again from your Main Profile.

For DSpace you need to set the query parameter to query and with EPrints set it to simple.

To view the results, follow the links shown in the image (Content -> SIte Search) and explore the results. 

Here is some interesting statistics from our repository as an example of the extra stats it can provide:

• 89% of visits did not make use of a a site search, whilst the remaining 11% did.
• 39% of search users left the system having performed the search without going any further (e.g. looking at one of the items found by the search)
• 22% of searchers resulted in search refinements being undertaken by the searcher
• 50% of searches were performed from the repository homepage, the remaining from item, collection and community pages.
• Following a search, the average visitor stayed on the site for a further 1 minute and 30 seconds.
• 8% of searches were performed without the visitor having entered a search term.

Yesterday I spent the day with a colleague delivering a training day aimed at new or potential DSpace administrators as part of my role working with the Repositories Support Project (known as the RSP).

We had a fun, interesting and busy day talking about DSpace, but a few hiccups along the way.

With each event we run, we learn new things about planning and delivering events. Whilst we’ve never had a bad event, there have been issues from time to time. With this event, the main issue was the hardware provided to us in the training suite at New Horizons in Birmingham. The staff were great, and the facilities good, the food was excellent, but the PCs were, ummm, a little on the old side! We were teaching DSpace, which is a pice of server software, so requires quite a bit of ‘infrastructure’ in terms of software requisities. Each trainee had their own PC with a copy of DSpace installed so that they had their own copy to mess about with, configure, and populate. To make this a little easier, we used the Ubuntu Linux distribution.

So when we combined Ubuntu (not a lightweight distro) with Postgres, Java, Tomcat, and Cocoon, lets just say that the poor 7 year old Pentium 866’s with 256 MB of RAM couldn’t quite cope. In fact, they couldn’t cope at all! Our other problem was that we’d configured the machines to launch Firefox as soon as they booted, so that the users were presented with DSpace straight away. Firefox had two tabs opened automatically upon startup, one for the JSP interface, and one for Manakin the XML interface. This meant that Tomcat then had to startup these web applications, at which point the whole machine came unusable and started swapping like crazy.

Our solution was to run round each machine and delete the more resource intensive Manakin user interface, and teach the course using the JSP interface instead. Even then, the machines were slow, so we had a lot of the trainees using one of our test servers back in the office instead.

So what is the lesson to be learnt from this?

Make sure you agree (in writing) the spec of the machines that you’ll be provided with at a training suite.

It sounds obvious, and we were probably just naive to assume that a PC training company would have machines that weren’t quite so old. But we live and learn, and have now negotiated a better room for our next course. Now to get the agreement in writing….