Project meeting – minutes

Present: Peter Douglas, Wendy Luker, Arthur Sargeant,, Mike Taylor, Babita Bhogal, Nick Sheppard

1. Apologies

Phil Jones sent his apologies; Phil is leaving Leeds Met in October and it was agreed the project team should formally approach another academic member of staff as a replacement. In addition, it was thought that the project team would benefit from a research administration perspective; potential canditates were suggested and will be approached in due course. This will complete the membership of the project team as outlined in the original bid and plan.

Action: NS to formally approach named individuals

2. Progress since last meeting

• API

Having followed the documentation supplied by Thomson Reuters for the API, it is throwing an error that we have been unable to interpret due to lack of specific expertise in Java. MT suspected that there may, in fact, be a problem with the API itself and/or the documentation. Upon enquiry, Thomas Reuters have indicated that the documentation is, in fact, a little out of date and they are on the verge of releasing new versions of all of their Web Services documentation, hopefully by the end of August; in response to a follow up enquiry in advance of this meeting (28th August) Thomson Reuters were not yet able to offer any update on when the new documentation will be released.

Thomson Reuters are not able to offer formal technical support with respect to implementing the API; they did indicate that they would pass on the error message to their developers but suggested that we would also be advised to identify our own resources to resolve the problem. (NB. We have now identified a colleague with the appropriate Java skills who has agreed to look at the current API documentation and help us interpret the error.)

The project team needs to come to a fuller understanding of the differences between the various services offered by Thomson Reuters, who have recently defined Web Services Lite and Web Services Premium for us as follows:

“Web Services Lite: This service responds to queries to return a limited range of data elements from the Web of Science. The fields are Author, Source (volume, number, issue, date, page span), Article Title, Keywords, and UT (a unique record identifier). The primary use case for the Lite service is to populate institutional repositories and is scheduled to be made available within the next two-to-three weeks. This service is free.”

“Web Services Premium: This service is a much more robust version of WS Lite and is very similar to the API we sent you earlier. The primary differences are that the service needs to be entitled and has much, much better documentation. WS Premium is scheduled to be available within the next month to six weeks. I’m not sure what the price is (if any) for the service, but we hope to have that sorted out in the very near future.”

We hope that the updated documentation will help to clarify the situation for us; the fact that it is not yet available is obviously of some concern in the context of such a short project; it was agreed that, should the new WS documentation from Thomson Reuters not become available before the next scheduled meeting (Tuesday 29th September 2009) then major deliverables of the project may be seriously compromised. To reflect this, the associated risk has been officially elevated and will be fed back to JISC via the programme manager:

Risk	Probability	Impact	Action to Prevent/Manage Risk
API unsuitable for project deliverables	Low (elevated to Medium;1stSeptember 2009)	High	Feedback from Thomson Reuters indicates proposal technically feasible. Problems with API/documentation should be mitigated by forthcoming release of new documentation from Thomson Reuters; 1st September 2009)

Action:  NS to liaise with JISC via programme manager to emphasise elevated risk

Action:  NS to continue to liaise with Thomson Reuters regarding new API documentation

• SWOT analysis
SWOT analysis was emphasised as an ongoing process thoughout the lifetime of the project in line with JISC guidelines for Rapid Innovation projects and the project team were reminded that they can continue to contribute via the blog or via the PollDaddy questionnaire at http://surveys.polldaddy.com/s/5768FF905C3EB6E7/. The most recent SWOT post on the blog is dated August 13th 2009.

The most serious current threat is the ongoing problem implementing the API which represents an external technological threat that is difficult to mitigate against due to our lack of direct control.

Action: Continue to undertake and document SWOT analyses throughout the lifetime of the project

• Project reporting

WL emphasised again the lightweight approach to project reporting adopted by JISC for Rapid Innovation projects, using the blog as the primary mechanism.
Feedback from the JISC programme manager has been positive, acknowledging that the blog is updated regularly and is of a high quality; it was acknowledged that most members of the project team have contributed to the blog and they are asked to continue to do so.

Moreover, the benefits of open project reporting have been illustrated by appropriate liaison with other projects; even the difficulties we have experienced in implementing the API are useful to others who will be able to learn from the problems we have encountered.

Action: Project team to continue to contribute regular progress posts to the blog
3. Liaison with other projects

• Readiness for REF – http://www.kcl.ac.uk/iss/cerch/projects/portfolio/r4r.html

The project manager for R4R, Stephen Grace, very kindly answered recent correspondence acknowledging that Andy McGregor had spoken to him about Bibliosight and giving an overview of relevant aspects of their project; as far as I understand, the full remit of R4R is somewhat broader than Bibliosight. An element of the project, however, is work that will enable UK repositories to make effective and efficient use of the Web of Science API which is directly comparable to Bibliosight.

N.B. R4R explicitly identify that their work in this area will be of benefit to at least EPrints, DSpace and Fedora software which are the most well used repository platforms across the sector. Our own platform, of course, is intraLibrary and depending on how the API is implemented by the respective projects, there is likely to be considerable cross-over; like R4R, we also aim to deliver outputs that are of wider use across the sector.

Stephen emphasised that work on the API and associated workflows has not yet begun – R4R is a two year project running from April 2009 – March 2011- so there is unlikely to be a great deal of scope for direct liaison between the projects though there is still an opportunity for valuable communication throughout and beyond the end of our project.

• JournalTOCsAPI – http://www.journaltocs.hw.ac.uk/API/blog/

The JournalTOCsAPI project team has been working to recruit volunteers from across the sector to test their API and, in recent correspondence, recognised the potential synergies between our projects and acknowledged that, when their community is established, it will be useful to explore how Bibliosight can also engage with them. JournalTOCsAPI anticipate having a prototype of their API ready for testing some time in September; for Bibliosight, however, our technical problems mean that a prototype is unlikely to be ready for testing before mid to late October at the earliest.

Action: NS to continue liaising with R4R and JournalTOCsAPI as appropriate

4. Use case development

Given technical problems implementing the API, it seems sensible to focus on use case development; NS and BB/URO have begun to liaise in this regard.
In theory the lack of a working prototype is no barrier to developing detailed use cases; indeed it is desirable to define functional requirements entirely independently of software development.

Action: NS/BB to liaise to develop detailed use cases

5. A.O.B.

None

6. Date of next meeting

Tuesday 29th September 2009