He was also happy for us to change / update the specification as well as not needing to use XCode which is also very good.

It was useful to find out how what we need to do in terms of JISC documentation and how to set up the blogging etc in a proper way. Very, very useful. Will have to get on with that and review the docs we’ve done already…

However, another file included in the archive, ESTI.wsdl, proved to be the key to the whole thing. For a quick bit of background information, the example from the old documentation instructed us to generate the java source files using a WSDL file retrieved from a remote server. Regenerating the java files using the newly supplied WSDL file was all it took to get the example working and spewing out copious amounts of (hopefully) useful XML.

I think we can breathe a sigh of relief now that we can move forward with the project again.

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:

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

Strengths

• The team has good experience in website development and alot of experience working with web programming, Content Management, FLASH, and have developed many commercial and academic websites.
• We have our own hosting facilities and can easily create sites for testing and trials by users
• Have already engaged some History postgraduates as volunteers to use a map-based CMS system applied to some History projects to evaluate both the CMS interface and the approach of the map background to display project items.
• Some other projects provide a good starting point for developments.

Weaknesses

• Not alot of Web2.0 experience, some with Google Maps
• There are significant differences between CMS systems and the type of systems we are trying to create with this project which will require a fair amount of development
• As the project will finish in November there won’t be time within that for testing by a full cohort of undergraduates (however this will continue after the end of the project).

Opportunities

• There are a large number of application opportunities for a web-enabled content managed display tool with a hierarchical structure as is envisaged.  It could be used to display project outputs in Universities, colleges and schools and across a number of disciplines
• Hosting a service could be a way to promote it and maintain sustainability
• There may be related applications which could be developed

Threats

• Getting the system finished on time with a very easy to use interface is a challenge
• Most potential users are not experienced IT users – we are looking for something very easy to use
• Publicising the finished system and making it widely available is a challenge

Unfortunately, this means we’ve not been able to spend as much time on ArtNotes as we’d have liked and so the learning of Objective-C has taken a bit of a step backwards. We’re hoping we’ll be able to wangle the scheduling of everything and try and get back on track, but we’re not so sure…. oh well…

Mike explained the developments of the Flash-based map system that would enable us to trial this type of visual display system with inexperienced users as the basis for a display mechanism to the XML version.

All were convinced of the need for a strong structure for the information, and the need to make it available in tiers to enable rapid browsing as well as drilling down into more detailed information and resources.

Mike proposed a 4 stage process to assist the users to construct and add content to a new project.  Mike also discussed a Virtual Learning Environment (VLE) model to deliver a number of projects with input from a supervisor to the groups involved.

Steve had identified 2 volunteers who were ready to help with the trialling of the Friargate and Frenchwood project displays.

It was agreed to commence a training session for these volunteers in the week commencing 27^th July.  Steve to contact them and arrange a meeting time.

Mike  will set up 3 blank sites with log on ids for the volunteers, and be ready to provide training in w/c 27^th July. This will provide a basis for evaluating the experiences of users and the user interface at an early stage.

Barbara. will evaluate the site interface when these have been set up and will conduct interviews with the volunteer users when they have had some experience using the system.

**Remember project team you can still contribute to the SWOT survey and you don’t have to fill out the whole form – any Strengths, Weaknesses, Opportunities or Threats you can think of are welcome throughout the project lifecycle.  N.B.  The survey has been modified to reflect PESTLE for external factors (I’ve missed out Environmental partly because I can’t think of any but mainly because I only having a basic, free PollDaddy account!)**

Internal factors:

People:

Strengths: Experienced and skilled programmer on team (Mike Taylor) / Experienced project team who have worked together previously / Good working relationship established with commercial partner / Strong buy in from senior staff within University.

Weaknesses:  One member of staff on the team is on a temporary contract; however, this does not expire until after the end of this project / lack of specific skill set required (Java) resulted in early difficulties in basic implementation of API.

Opportunities: Project team has access to necessary skill sets internally.

Threats: Other commitments within project team interfere with short project lifecycle.

Resources:

Strengths: Resources in place – no need to wait for any subscriptions, to go through any kind of purchasing process.

Threats: Actually not yet clear what the extent of the ‘free’ service will be from Thomson Reuters – there may, in fact, be additional subscription costs.

Innovation & Ideas:

Strengths: The ideas behind the project are timely, fit in with University objectives, and will be of value to the wider community / Bibliosight is one of 3 projects working in this area and this is an opportunity to share ideas and maybe even code so that we can get further along then we would on our own.

Weakness: Whilst the original project idea is a strength, other project teams are working in this area, and there is a risk that our work may be superceded either by the commercial developer (Thomson Reuters) or other projects in the sector.

Opportunities: Bibliosight represents a fertile area in current developments in research metrics and innovation & ideas should continue to evolve throughout the project.

Marketing:

Strengths: The project blog is set up, and is linked to by an existing and well visited blog, so the project should attract attention.  Ditto for Twitter. / There is a real advocacy benefit to be reaped if this service fits closely with the users’ workflows.

Weaknesses: Difficult to market a potential service before a working prototype is available.

Opportunities: Possibility of engaging with user community recruited by JournalTocsApi project.

Threats: Lack of local and wider community engagement.

Operations:

Strengths: Project managed / outputs will be implemented by established repository team responsible for overall development of repository infrastructure.

Weaknesses: The 6 month funding structure is a threat in terms of sustainability. What happens if we don’t have a finished service at the end of 6 months, and even if we do, how is ongoing development funded?

Opportunities: As the repository infrastructure itself is still in development there is the opportunity to integrate project outputs more easily into the evolving infrastructure.

Threats:  (As yet unseen) difficulties in appropriate integration with developing repository infrastructure.

External factors:

Political:

Strengths: Potential to fit in with broader political zeitgeist in HE – contribute to developing processes for REF.

Threats: Conflict with commercial interests of Thomson Reuters.

Economic:

Strengths: Low cost project with the potential to deliver a flexible product with wide opportunity for reuse accross the sector.

Threats: Not yet clear what the extent of the ‘free’ service will be from Thomson Reuters – there may be additional, unforseen costs.

Social:

Strengths: Well established (within) #jiscri community utilising Twitter/blogs.

Opportunities: Possibility of engaging with user community recruited by JournalTocsApi project.

Threats: Lack of engagement of wider HE communities.

Technological:

Strengths: Third party API should result in robust application.

Weaknesses: Early question marks around API / documentation – current documentation out of date; revised documentation expected by the end of August 2009.

Threats: Revised documentation won’t be available in line with project lifecycle.

Legal:

Threats: Thomson Reuters commercial model not fully defined – potential implications for reuse

(The points are numbered for ease of referencing, not for ordering.)

Strengths

1. We think we’re starting with a good idea, at least in principle; an innovative solution to a recognized need.
2. Using sux0r as a starting point has given us access to existing OS code and put us in contact with a knowledgeable developer.
3. We have a settled team who have worked well together on a number of previous projects over the last 4-10 years.
4. We have good existing links with experts in JISC, CETIS, the IE, UKOLN, JISC services and projects (and we’re not afraid to use them).
5. We have previous experience in related projects dealling with Journal ToC and other RSS feeds (e.g. PerX, TicTocs, GoldDust . . .).
6. We work in close proximity to our intended test user group (which should help with encouraging engagement for the trials).

Weaknesses

1. We have lots of new stuff to learn: this is the most deliberately RESTful development we have undertaken; we’re using a project management technique that is new to us; this is first time we’ve worked on a branch of an existing OSS project; we need more robust user trials than we’ve previously managed.
2. We have all that to learn in a short project time frame (six months, all the team are working part time on this project).
3. Bayesian filtering is not a complete solution. Other techniques (e.g. popularity from usage data analysis; manual over-rides to specify that that everything from some authors is important, no matter what the topic) would help identify important items but are out of scope.
4. Bayesian filtering might not work for our users with the type of data and sources we have (see threats), though as a good academic I think this is not so much a weakness as a potential research finding.

Opportunities

1. Working with sux0r provides an opportunity to work with an existing user base and experienced developer.
2. Other projects in the information environment provide additional/alternative usage scenarios (but see threat 2).
3. It may be possible to embed the output of this project into other services, e.g. TicTocs, TechXtra, JISC IE or commercial services.
4. There is good support for RESTful development approaches.
5. There is a good developer community in the JISCRI projects.

Threats

1. Lack of user engagement. We don’t know that users will be as enthusiastic about this approach as we are, they might just resent disruptive technologies.
2. Expectation mismatch (see opportunity 2 & weakness 3), possibly leading to scope creep.
3. There might be some unexpected conflict with the sux0r project (over approach or priorities).
4. There might be a lack of table of content information from the right journals in RSS form, or what there is might be polluted (garbage in garbage out).
5. Competing demands on time from other projects/tasks that the team are working on (see weakness 2).

I guess some mitigation of the negative factors is called for, that will come later, but a quick reflection is that engagement with the project externals is going to be important.

The programme guidance documentation suggests that the SWOT analysis is best to be undertaken in small steps, throughout the duration of the project; and the other guidance I read suggested that it should draw on as many view points as possible. So, hopefully this isn’t the last on SWOT, and please comment on anything that has been overlooked.

So we have migrated the sample metadata to Deegree CSW, which supports various spatial filters including geometry intersection.

The catalogue service runs from an installation of Apache Tomcat, which we run on a separate machine so that we do not overload the development machine. The CSW obtains its metadata from an installation of the PostgreSQL database and its spatial extension PostGIS. The CSW and the PostgreSQL/PostGIS database reside on the same machine to reduce the transmission time for geospatial objects retrieved from the database.

When populating the CSW with metadata we had to harvest metadata from existing Z39.50 servers. To do this, we used the Iharvest application that is distributed with ISite Z39.50 software. We then created a program that reads the harvested metadata, transforms the XML into Insert requests and sends the requests to the CSW. For transforming and inserting the metadata, we used Netbeans IDE because it has better XML and web service development support.

REQ-001: The mediator shall query participating services through a CSW interface

REQ-002: The mediator shall allow for multiple catalogue services to be queried

REQ-003: The user interface shall offer check boxes for selecting one or more servers, with a clear warning of performance issues if more than one servers is searched at a time.

REQ-004: The mobile client shall communicate with the mediator through an XML-based interface, that is not SOAP

REQ-005: The mobile client shall allow for keyword searches to be configured before or during fieldwork

REQ-006: The mobile client shall allow for the user’s current location to be transmitted as a spatial search during fieldwork

REQ-007: The mobile client shall offer a visualisation of the user’s current location

REQ-008: The mediator should apply some access control between the mobile phone and third-party services

REQ-009: The system shall offer concurrent searching on multiple catalogue services

REQ-010: The interface shall make it easy for the user to switch between a map view, ranked list view and metadata view.

REQ-011: The map view shall use bounding boxes to show the extents of datasets and any datasets intersecting with the bounding boxes would be highlighted in the ranked list view.

Strengths

• Expertise in OGC standards, including Catalogue services.

• Several years Java programming experience.

• Participation in the Global Earth Observation System of Systems (GEOSS) which extensively uses Catalogue services.

• Several years in developing XML and web-based applications for Geographic Information Systems.

• Participation in AGILE/EuroSDR/OGC Persistent Testbed offers potential volunteer developers.

• Situated with other Android and Location Based Services projects i.e. D-Scent & Horizon.

Weaknesses

• Project duration includes the month of August which is typically ‘holiday season’.

• Promotion amongst developer and user communities may be hampered by duration of the project.

• According to an AdMob report for April 2009, the iPhone and Symbian continue to dominate the market; however, Android is seen as gaining popularity and has caught up to platforms such as PalmOS (http://metrics.admob.com/wp-content/uploads/2009/04/admob-mobile-metrics-april-09.pdf)

Opportunities

• Use of Android offers the possibility of accessing in-built GPS.

• Vodafone is currently offering unlimited internet packages with HTC Magic phones(running Android).

• Rapidly growing developer community behind Android.

• Showcasing at the 2009 Location Based Services and TeleCartography conference in Nottingham.

Threats

• HTC Magic has entered the market around the same time as Apple iPhone 3GS so they are likely to share the market.

• Potential limitations in the ability of the selected catalogue services or mobile devices to realise the proposed use case.

Up until last week, we had an Android app with three (non-functioning) GUI components, namely a ListView for listing search results, a TextView for showing the metadata, a MapView for showing the user’s location relative to bounding boxes of retrieved metadata records.

Added a configuration view for the user to enter the search keyword and the query frequency. Added a manual query button for debugging purposes.

Progress on CSW:

So far this is what the prototype can do…

Upon clicking on the manual query button the search keyword is added to a Catalogue service request which is then sent to the Catalogue service. The response is parsed using DOM then the ListView is populated with the titles of the retrieved metadata records. When the user clicks on a title in the ListView the rest of the metadata for that dataset is printed on the TextView.

The XML parsing and communication with the catalogue service is done in a separate thread using Android’s AsyncTask class. This is the recommended way for retrieving data over HTTP in Android because “Android is not thread-safe”. The AsyncTask method seems to work fine.

Every certain number of meters the Location sensor (GPS) is queried and the user’s current location is sent to a catalogue service, together with the search keyword.

Added a feature to make sure the ListView is only updated if there are changes in the list of returned search results.

Project SWOTing: Undertake a basic SWOT analysis of your project (which is a good thing to repeatedly do with yourself when you have a couple free moments waiting for a bus or train, especially helpful at the end of code sprints). The key is to truly knowing thyself or at least your project.

I’ve found a useful introduction to SWOT at http://www.cipd.co.uk/ which emphasises that “while at first glance the SWOT looks like a simple model and easy to apply, experience shows that to do a SWOT analysis that is both effective and meaningful, requires time and a significant resource. It requires a team effort and cannot be done effectively by only one person.”

While JISC do suggest a basic analysis and this is, after all, rapid innovation, nevertheless it would perhaps be rather too easy to pay lip service to a funder exortation such as this and rattle off a few platitudes before moving on so I thought I’d try to use the blog to generate some input from the project team – not least because I tend not to use public transport and drive everywhere…

The CIPD site points at a template for SWOT at http://www.rapidbi.com/created/swot-pestle-template.html which looks quite thorough and lists internal and external strengths and weaknesses under several headings: people; resources; innovation & ideas; marketing; operations; finance.

I’ve set up a survey to try and get some input from my colleagues:

http://surveys.polldaddy.com/s/5768FF905C3EB6E7/

(Slightly cut down due to a free account only allowing 10 questions – I’ve missed out finance.)

This is primarily for input from the #bibliosight project team but we would also welcome input from anybody interested in SWOT/#bibliosight/#jiscri

N.B. Below is the (very brief) risk register from the original bid:

Risk register from original bid

1.  Apologies

Phil Jones sent his apologies.

Peter Douglas sent his apologies – Charles Duncan attending from Intrallect in his stead.

2.  Project overview

WL chaired the meeting and began by presented an overview of the proposed project; to exploit the Web of Science web-services API in order to promote full text deposit of author versions of published peer reviewed research papers in the Leeds Met repository; to develop an alerting service to alert the repository team/URO when a research paper associated with Leed Met is picked up by WoS; automated communication to a researcher which would alert them to the presence of their citation on Web of Science, and request an author version for the repository; potentially also to import metadata from WoS to automatically populate the repository.

3. Project management and meetings

The project is funded under the JISC Rapid Innovation programme (tag: JISCRI; programme code repository and wiki at http://code.google.com/p/jiscri/) and is due to complete at the end of November 2009.  A rapid development cycle is therefore essential and will be based on the SCRUM methodology recommended by JISC.

• Team and roles

The team of 6 people comprises:

a) Members responsible for project deliverables

Wendy Luker – Project Manager (or SCRUM master); Arthur Sargeant – Project consultant; Mike Taylor – Web-developer responsible for technical development; Nick Sheppard – Repository Development Officer responsible for project research; Peter Douglas – representative of Intrallect

b) Representative stakeholders who will inform development and potentially benefit from project deliverables.

Babita Bhogal – represents the University Research Office; a potential customer/user of project deliverables; Phil Jones – represents the Carnegie Research Institute; a potential customer/user of project deliverables.

There will be 5 “sprint” cycles; at the end of each cycle there will be a full team meeting to review progress and technical development.  In addition NS/MT will liaise more closely throughout the sprint cycle including face to face on a weekly basis – these meetings may also include WL, AS as necessary.

N.B.  The JISC programme manager has indicated that Bibliosight could benefit from work being done at Kings College with the R4R (Readiness for REF) project and should also liaise with another JISCRI project based at Heriot Watt University that is building an API for ticTocs.

Action:  NS – investigate / establish contact with these projects and provide a detailed overview before the next meeting.

• Project reporting; blog

To reflect the scale of projects under the programme, JISC are advocating a light-weight reporting framework utilising the blog as the primary mechanism.  It is anticipated that all team members will contribute to the blog and that the subject for posts will be specified at each meeting in line with 6 subject areas specified by JISC.  These are:  Project SWOT analyses; User participation; Day to day work; Technical standards; Value add; Small wins and fails; Progress report.

Aggregation tag for the project is #bibliosight (blog posts and Twitter updates).  Other relevant tags are #JISCRI, #SWOT, #rapidInnovation, #progressPosts, #UseCase

Action:  NS/WL -  blog initial SWOT analysis in advance of next meeting.

Action:  NS – ensure all team members have administrative access to the blog.

• Technical

The first workpackage is a “full technical review of Web of Science Web Services API / technical developments required to appropriately integrate API into repository” with the time scale June-July 2009.

NS/MT recently attended a webinar run by Thomson Reuters where they presented an Introduction to Thomson Reuters Research Evaluation Tools which reviewed the API; MT has also reviewed API documentation and has gained the appropriate administrative permissions to run a Java programming environment on his local machine and is now in a position to explore the API in more detail. MT may require technical input from Java programmers at Intrallect and CD confirmed that this would be acceptible under the terms of the bid.

A code repository has also been set up in line with JISC guidelines at http://code.google.com/p/bibliosight/.  This is where any code produced by the project will be stored subject to appropriate Open Source licensing (see below) and the location for all documentation and bug tracking.  The version control system implemented is subversion; as  the only developer currently associated with the project, MT is the only user who requires full  access.

There was also some preliminary discussion around how the API will most appropriately be integrated into the Leeds Met repository; whether WoS data will be pulled directly into intraLibrary or into an external environment for example and what the implications of this might be eg. prototype proof of concept build of intraLibrary.  However, it was decided that initial focus should be on manually mapping the process and on the API itself before these issues can usefully be explored further.

CD raised a technical question regarding the API; whether the interface only supports  SOAP or if it can also supports REST which would potentially provide a lower technical threshold.

Action:  NS – full review of Thomson Reuters services; article match and retrieve; Web-services lite; Researcher ID upload; Researcher ID download; Web-services premium.  Disambiguation of free vs. paid services.  SOAP vs. REST

Action:  MT – explore / implement API and document process.  Establish precisely what information can be extracted from WoS using the API.

Action:  NS/MT/AS – manually review WoS to elucidate desired process i.e. What information do we want and what information can we get a) manually b) programmatically (free vs. paid)

• User testing and engagement

This will be facilitated through appropriate liaison with BB (URO) and PJ (CRI) and will initially focus on communication – NS is attending the CRI Readers’ and Professors’ meeting on Thursday 16th July – and generating use-cases and scenarios, possibly in collaboration with Intrallect who have experience and expertise in this area.

Action:  NS to attend CRI Readers’ and professors’ meeting on Thursday 16th July for initial communication and feedback.

Action:  NS/BB/PD to liaise to generate preliminary use-cases/scenarios.

4.  Licensing

Software/code/project deliverables are to be made available under appropriate licence agreements in line with JISC guidelines.  The licence provisionally applied at http://code.google.com/p/bibliosight/ is GNU GENERAL PUBLIC LICENSE Version 3 – http://www.gnu.org/copyleft/gpl.html.  This may or may not be suitable for our software requirements; other project deliverables may require different licensing models; requires further research.

Action:  NS to research; liaise with OSS watch to clarify licensing issues

5.  AOB

Administrative housekeeping (unminuted)

6.  Date(s) of next meeting(s)

Given the short project lifecycle, it was decided that provisional/approximate dates should be outlined for all remaining meetings:

• w/c 31st August 2009 (bank holiday Monday)
• Late September
• Mid-late October
• Early November
• Last week in November

Action:  NS to call next meeting w/c 31st August 2009