Thinking out loud…

As the deadline for #jiscri draws close I have just returned to work after a month away from Bibliosight and I’m now desperately trying to catch up with the project and determine exactly what we can aim to achieve by the end of November…The candid truth is that we have only very recently got to the point where Mike can actually do some coding and begin to put together a prototype that fulfills the requirements of our (still formative) use-case[s].

Yesterday morning I had a stab at completing a more detailed template for a primary use-case (this comprises a narrative and the use case itself); then in the afternoon I sat down with Mike to catch up with his progress from a technical perspective and to brain-storm around precisely what functions we require from our prototype and how this may be achieved; there are also some outstanding issues of clarity pertaining to Thomson Reuter’s API documentation, specifically “WoS Search Retrieve Codes and Descriptions” in that we currently have unrestricted access to the API but it is my understanding that the free* service will actually be restricted.  We are not certain:

a)  Precisely which of the fields are associated with the restricted subset that we will be able to query and/or return under the current terrms of our WoS subscription*

b)  What some of the fields actually are as they lack a description in the documentation

*Free to us under existing subscription

Disclaimer:  I’m very much thinking out loud here and attempting to translate what I understand are ongoing conceptual issues for Mike as he works through the documentation.

Note:  I’ve continued to refer to ResearcherID – see http://bibliosightnews.wordpress.com/2009/10/02/visit-from-thomson-reuters/ – though it is not a service we plan on implementing as part of Bibliosight, and not necessarily even in the longer term, I’m pretty sure we are likely to require some sort of unique identifier for authors – a subject that is currently receiving a lot of attention from the repository community.

Anyway…looking back over the blog it seems that:

The requesting system can query the Web of Science using the following fields:

• Address (including Street, City, Province, Zip Code, or Country)
• Author
• Conference (including title, location, data, and sponsor)
• Group Author
• Organization or Sub-organization
• Source Publication (journal, book or conference)
• Title
• Topic
• Year Published

The service will support the AND, OR, NOT, and SAME Boolean operators.

The Web of Science Web Service returns five fields to the requesting system:

• Article Title
• Authors — All authors, book authors, and corporate authors
• Source — Includes the source title, subtitle, book series and subtitle, volume, issue, special issue, pages, article number, supplement number, and publication date
• Keywords — all author supplied keywords
• UT — A unique article identified provided by Thomson Reuters

The test queries that Mike has submitted to the API have returned XML that appears to be both more granular than indicated and that includes fields other than those that constitute these five (e.g. abstract) so the first thing to do, perhaps, is to contact Thomson Reuters and see if they can apply the restrictions that we will ultimately need to work with, if only to remove some of the noise and make it easier to see the wood for the trees.

The API documentation actually lists over 100 “fields”; only a handful of these are actually described in the documentation, however, and while many are reasonably transparent, others are a little less so and some look like they may duplicate information – or are they perhaps used as alternatives? (e.g. bib_id = Volume, issue, special, pages and year data / bib_issue = Volume and year data).  There is also some lack of consistency in this bibliographic info on a record by record basis; we need to ensure that we have consistent XML being returned for all records – hopefully we can then develop a template in intraLibrary itself that reflects that consistent XML as closely as possible such that we can devise an XSLT style-sheet to perform the approriate transformation.

Mike already has a desktop client that will take XML and perform an XSLT transformation so, once we have clarified the LOM format we require (an action for me from the last meeting), it *should* be relatively straightforward to plug into the WoS API to retrieve XML from the Web of Science which can then be transformed into appropriate LOM.

Then we need to ingest that LOM into intraLibrary, preferably using SWORD…which I shall think about another time!

Visit from Thomson Reuters

On Wednesday afternoon Mike and I were finally able to sit down with Jon and…Gareth? (sorry, I’m terrible with names) from Thomson Reuters to discuss Bibliosight and the work we are doing with the WoS API, it probably goes without saying just how useful this was, especially so soon after our Tuesday meeting.

As we have come to appreciate, Thomson are still very much in an ongoing process of developing their suite of tools and commercial services around the extraction of data from WoS using their API and, overall, I was given the impression that the company are currently practising something of a balancing act to weigh their commercial interests against providing appropriate value added services to their subscribers under existing licensing agreement – which is, of course, entirely reasonable.  Jon suggested that the Bibliosight project is something of a pioneer in using this technology and a useful case-study for the company, which certainly puts some of our early difficulties into context – though he did indicate that numerous other folk are also actively investigating the API; in particular he mentioned Queens College Belfast, an institution in Birmingham and R4R at Kings College London in collaboration with EPrints’ Les Carr at Soton.  R4R is the only project that I was hitherto aware of and have had any contact with; it would be really useful if we were able to communicate with others also using the API.

Thomson Reuter’s flagship commercial product is called InCites and “supplies all the data and tools you need to easily produce targeted, customized reports… all in one place. You can conduct in-depth analyses of your institution’s role in research, as well as produce focused snapshots that showcase particular aspects of research performance.” We discussed how, though such a service will be invaluable for the research oriented Russell Group institutions, it is likely to be overkill for a million plus institution like Leeds Met; nevertheless we do require a certain level of functionality to help us analyse our research performance which, alongside our traditional strengths in teaching and learning, is increasingly important, especially in view of the REF.  Hopefully this is where the developing ‘suite of tools’ comes in and our guests were keen to get a handle on precisely what we are hoping to achieve with Bibliosight (aren’t we all!).  I outlined our preliminary use-cases for them as a foundation for our discussion and was also keen to ask some of the specific questions that had arisen during the previous day’s meeting.  First of all I asked about the wording of the documentation that appears to suggest that it is only possible to return 100 records with a single query using the API – they weren’t aware of such an issue and agreed that the way it was expressed in the documentation was a little ambiguous; Jon will follow this up for us though Mike may also be able to elucidate the situation when he has investigated further.  They were able to say that another user had discovered that the API could be called twice every second, however, so didn’t anticipate any problems with extracting all the data we need.

The major issue that came up at the meeting on Tuesday was how best to return all of the articles for a given institution with the most appropriate field to query apparently being the address field.  It is not clear, however, how consistent the institutional address actually is and Jon confirmed that it is derived from information harvested from individual journals/papers which preliminary manual searching of WoS has already demonstrated to be idiosyncratic  – at least in the case of Leeds Metropolitan University and almost certainly other institutions aswell (leeds metropolitan university; leeds met [uni]; lmu etc).  Jon suggested that the safest and most effective method of returning all records would actually be by using ResearcherID though this would require all institutional authors to be registered and an additional paid subscription to ResearcherID download (as opposed to upload which is free) – in lieu of this, however, he did confirm that the address field was the only way and that it may be necessary to build a catch-all query to ensure that we don’t miss anything – precisely how we achieve this is still a little bit of a moot point, though he did indicate that some work has been done on disambiguating institutional address formats within WoS and will follow up on this for us in due course.

Through our discussion, Article Match Retrieval is finally beginning to make more sense to me now, and Jon confirmed that this is the method that would be used in conjunction with the API to provide numbers of citations to an individual article – AMR can be queried by numerous fields including DOI and UT Identifier (A unique identifier for a journal article assigned by Thomson Reuters.); in terms of the current project, I think it makes sense to focus initially on extracting bibliographic data first before worrying about citation metrics; via the API, we can also extract the UT identifier and then use this to query AMR.

We also touched on Terms & Conditions and Thomson, again reasonably, expect WoS as data source to be clearly acknowledged on each individual record – Mike wasn’t initially certain how this could easily be achieved from a technical perspective, at least in the case of bibliographic citation information (which may have been added manually); we have a few ideas on how this could actually be achieved but is really just something to be aware of at this stage.

All in all I now feel that the overall shape project is beginning to be resolved and, in addition to the technical work required to extract, store, parse, convert (XML) records and then pass them somewhere else (intraLibrary/EndNote), a large part of Bibliosight will necessarily focus on developing use-cases for our institutiona research administration which is likely to continue well beyond the designated 6 month life-cycle of the #jiscri project!

Project meeting – minutes

(Date of meeting 29th September 2009)

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

1.  Apologies

No apologies

2.  Team membership

Thank you to Sue Rooke who has agreed to join the Bibliosight project team; Sue is a research administrator in the Faculty of Health and has already been involved in repository development, contributing to developing workflows and providing feedback on the Open Search interface.  We hope that Sue will contribute, in particular, to use case development.

The team is still lacking a representative from the academic community and we are currently waiting for a reply to recent correspondence. WL is attending the research sub-committee on Monday 5th October and may raise the issue there if necessary.

Action:  WL/NS to pursue academic contact(s) for a representative to sit on the project team

3.  Progress since last meeting

• API

We have now received the updated documentation from Thomson Reuters and Mike has submitted a query to the API  and received an appropriate response in XML. Thomson Reuters’ FAQ gives a full summary of the data fields that can be queried by the service and the data elements that can be returned which appears to be in line with this XML response.

We are therefore able to formally reduce the associated risk back to low:

Risk	Probability	Impact	Action to Prevent/Manage Risk
API unsuitable for project deliverables	Low (elevated to Medium;1stSeptember 2009 – reduced back to Low; 29th September 2009)	High	Feedback from Thomson Reuters indicates proposal technically feasible. Problems with API/documentation have been mitigated by release of new documentation from Thomson Reuters; 29th September 2009)

N.B.  The wording of the documentation appears to suggest that it is only possible to return 100 records with a single query using the API – NS to clarify with Thomson Reuters.  If this is the case, the practical implications  are limited in the case of Leeds Metropolitan University which publishes a relatively small amount of research but would be considerable for an institution with a greater research output.

Action:  NS to clarify 100 record limit with TR

Action:  MT to continue appropriate* implementation of API

* Hopefully what is “appropriate” will evolve over the coming weeks!

• Use cases

Technical difficulties have contributed to a lack of conceptual clarity amongst the project team and there was considerable discussion around precisely what data Bibliosight will now seek to retrieve from WoS using the API and what we will aim to achieve with that data.

The original use case narratives outlined in the bid were several and focussed on an alert service for researchers and/or repository administrators to encourage the deposit of an appropriate full text in the repository and perhaps neglected the obvious administrative use case whereby metadata from WoS is pulled directly into intraLibrary.

N.B.  An important use case was also the extraction of citation metrics that would potentially inform the REF – we are not yet clear how this would be achieved but we understand it will rely on the Article Match Retrieval service.

Of course we also want to produce outputs that are of use to the wider community rather than just to users of our specific repository software and this reflects the considerations of the Readiness for REF project which also hopes to enable UK repositories to make effective and efficient use of the WoS API (as part of a much broader project) and is focussing on EPrints, DSpace and Fedora as the most well established OA research repository platforms.  R4R raises several pertinant questions, many of which also arose independently and in a similar form during our own discussion:

• What are the different workflows relevant to (i) backfilling a repository with a one-off download and (ii) ongoing use of WoSAPI to populate a repository?
• What uses might records downloaded from WoSAPI be put to?
• How might the workflows be designed to enable other datastreams also to help populate the repository (eg from UK PubMedCentral, arXiv, or sources that better serve the arts, humanities and social sciences)?
• What workflows might be able to handle facts such as that the WoS record will become available some time after the paper is published, whereas deposit into the repository may happen earlier than that?
• What methods might be helpful in addressing the inevitable questions of duplicate records, or ambiguous relations with existing records?
• Are there implications for a repository’s mission and reputation if the balance of content it holds is rapidly changed by a large number of WoS-derived records?

Use cases may also be informed by the JournalTOCsAPI project (see item 5 below) who also explored similar issues in a recent post.

One  practical consideration from a technical perspective and that will have a bearing on developing use cases is the best method of extracting comprehensive records from institution “X” – the most appropriate field to query seems to be the address field but it is not clear how consistent the institutional address in this field will be – for example, early experimentation has found that “leeds metropolitan university” only returns 201 records; using a wildcard in the form “leeds met*”, however, returns 1503 records (test conducted 29th September 2009).  This was an issue flagged to follow up with Thomson Reuters reps on Wednesday 30th September (see item 4; post to follow).

In terms of the practicalities of actually getting records from WoS into intraLibrary once they have been harvested, Peter did indicate that it should be possible to upload suitable XML records into intraLibrary though this will need to be in LOM format, meaning that we may need to perform an XSLT transformation to convert data retrieved from WoS into a suitable format.  Also, Peter is uncertain whether XML that can be imported in this way will also include the LOM extensions we are using to accommodate bibliographic information and will need to speak to his technical colleagues at Intrallect to clarify.

Note:  There was also discussion around appropriate integration with SFX, our OpenURL resolver, as a possible means of identifying a published URL for WoS records – this is an area that has scope implications both for Bibliosight and the remit of the Leeds Metropolitan University repository itself; beyond an Open Access repository of research (i.e. to also comprise citation only records).  This is an area that may need to be explored in more detail later in the project.

Action:  PD to clarify re upload of XML to intraLibrary including LOM extensions

Action:  NS/BB/SR to meet with another member of the URO to clarify potential use cases (meeting on Thursday 1st October)

Action:  All team members to contribute to ongoing discussion on the blog.

• Project reporting – blog; tags specified by JISC

It was agreed that the specific subject for blog posts this month will be ‘Technical standards’ – Peter agreed to contribute a post before the next meeting.

Action: PD to contribute a blog post on ‘technical standards’.

Action: All team members to contribute to ongoing discussion on the blog.

4.  Visit by Thomson Reuters reps on Wednesday 30th September

Mike and I met with Jon and Gareth from TR on Wednesday 30th (yesterday) who were able to clarify several issues for us – separate post to follow

5. Review of JournalTOCsAPI – http://www.journaltocs.hw.ac.uk/index.php?action=api

During the meeting, I gave a quick overview of the recently released JournalTOCsAPI at http://www.journaltocs.hw.ac.uk/index.php?action=api with a view to de-mysifying the concept of an API for the less technical amongst us and also potentially giving the more technical a developmental steer.  Currently, queries need to be submitted to the API by URL and are returned as an RSS feed which includes as much metadata as in the original TOC feed – depending on the quality of the original record – comparable to Bibliosight in many respects, this project perhaps has greater flexibility regarding the metadata it is able to query and return – it is, after all, building an API from the ground up that will query an openly accessible data source – however, it is likely that the quality of the data may not be as consistent as WoS; there may be fields missing, for example.

It has also been informative to engage with another, similar project as a ‘user’ and we discussed how Bibliosight might also engage with JournalTOCsAPI community of users and agreed that it is a valuable opportunity to solicit the opinion of repository managers from other institutions using different software platforms.

Action:  NS to continue engaging with JournalTOCsAPI as a ‘user’

Action:  NS to send an email that can be forwarded to JournalTOCsAPI community of users as suggested in recent correspondence from Lisa Rogers

6.  Article Match Retrieval & Researcher ID

These were only touched upon briefly in the meeting and flagged to follow up with Thomson Reuters reps on Wednesday 30th September (see item 4; post to follow).

7.  A.O.B.

None

8.  Date of next meeting

20th October 2009 – 11:30 am

More on ResearcherID

A quick search of my blog feeds turned up surprisingly little on ResearcherID – just 8 posts from my fairly populous repository oriented RSS aggregation, all from 2008, they include this post from June 2008 on the Wrap Repository blog which emphasises that “it would be easier for the author if there were a universal unique identifier that could help us all to share information about the author in a more automated way” and a post on the principles of citation-based evaluation from Overdue Ideas in which @ostephens summarises a session by James Pringle from Thomson Reuters and voices concern about how the work being done by Thomson Reuters “joins up with activity in the sector, and by other organisations. How does ‘ResearcherID.com’ link to OCLC Identities work? It would be great to see some joined up thinking across the library/information sector on this, as otherwise we will end up with multiple methods of identification.”

So it seems that ResearcherID received a flurry of attention when is was released back in 2008 but is still just one potential solution to an ongoing issue – as I noted in a recent post, Open Research Online is using a unique University ID in their EPrints repository (though I need to do more reading, other solutions mooted in the blogosphere seem to be OpenID and OCLC identities.)  I also searched http://www.researcherid.com/ for “Leeds Metropolitan University” and found just 4 of our researchers in the database…

Nevertheless, in terms of the of the Bibliosight project, and the wider context of the Leeds Met repository, ResearcherID could well be an appropriate solution, and is certainly worth exploring further with the project team and with the URO…just a very quick note on practicalities; batch upload to ResearcherID would require us to prepare a detailed XML document which, to my mark-up phobic eye, looks decidedly none trivial – it would need to comprise records for all leeds Met researchers of course.  This is an example (view in IE or FF; Chrome will interpret the XML rather than show mark-up)

Project meeting number 3: Draft agenda

Date of meeting:  Tuesday 29th September 2009

1.  Apologies

2.  Team membership

3.  Progress since last meeting

• API
• Use cases
• Project reporting – blog; tags specified by JISC

4.  Visit by Thomson Reuters reps on Wednesday 30th September

5.  Review of JournalTOCsAPI – http://www.journaltocs.hw.ac.uk/index.php?action=api

• Potential synergies with Bibliosight

6.  Article match Retrieval & ResearcherID

7.  A.O.B.

8.  Date of next meeting

Just round the next corner…

Thomas Reuters new research analytics website - http://researchanalytics.thomsonreuters.com/ –  has finally provided a thread through the labyrinthine Research Analytics infrastructure that I’m able to follow – forgive the hyperbolic metaphor –  it’s probably isn’t that difficult to navigate and I’m hardly an ancient Greek hero – just easily lost! Nevertheless, it links intuitively amongst the various information and I’m reviewing, in particular, the information on Web Services, Article Match Retrieval and ResearcherID in advance of next week’s meeting.

I’ve certainly asked most of the Web Services FAQ myself over the past few weeks.  The most relevant from our perspective are:

What data fields can be queried through the service?

The requesting system can query the Web of Science using the following fields:

• Address (including Street, City, Province, Zip Code, or Country)
• Author
• Conference (including title, location, data, and sponsor)
• Group Author
• Organization or Sub-organization
• Source Publication (journal, book or conference)
• Title
• Topic
• Year Published

The service will support the AND, OR, NOT, and SAME Boolean operators.

What data elements are returned by the service?

The Web of Science Web Service returns five fields to the requesting system:

• Article Title

• Authors — All authors, book authors, and corporate authors
• Source — Includes the source title, subtitle, book series and subtitle, volume, issue, special issue, pages, article number, supplement number, and publication date
• Keywords — all author supplied keywords
• UT — A unique article identified provided by Thomson Reuters

One of the issues we are likely to run into retrieving data from WoS is differentiating between similar names and disambiguating the same name that has been entered in different formats and this is where ResearcherID can come in.

N.B.  This is actually an issue with implications beyond Bibliosight and purely internally; I’ve been aware of the need for a unique identifier for researchers in intraLibrary for a while, prompted by a blog post from Open Research Online describing how they have developed a feed of a faculty group members’ publications from ORO (EPrints) to the faculty’s website which “made use of the fact that everyone’s publications in ORO are linked to their unique university ID.”  This prompted me to wonder aloud on Twitter if such use of unique identifiers was standard practice for Eprints – @smithcolin and @ostevens tell me that it isn’t.

ResearcherID is a global service to assign a unique identifier and eliminate author misidentification – with the obvious benefit over an institutional ID that it is universal rather than just local.

As far as I understand, the ResearcherID Web Service from Thomas Reuters comprises two element -

• ResearcherID upload “that enables administrators to mass create ResearcherID profiles and upload publication data for some or all of the accounts you create for faculty, researchers, etc. at your institution.”
• Researcher ID download is “a web-based service that enables you to query ResearcherID for researchers at your institution and return publication data for them, including times cited counts where applicable, as well as return institution affiliation for researchers at the requesting institution.”

Upload is freely available to everyone but download is a subscription based service.

I have now registered with the ResearcherID batch upload service and will report on it more fully at the meeting next week.

So what about Article Match Retrieval?  To be honest, this is where my thread runs out, and I’m still not entirely sure how this fits in.  It’s free I think (to WoS subscribers) and the blurb says:

“Article Match Retrieval allows for a real-time lookup of bibliographic metadata such as DOI, author, source title, etc., against the Web of Science database (using the institution’s subscription entitlements). If a match is found, the service will return Times Cited information as well as links to view the full record, related records page, or citing articles page in Web of Science. An institution can use these links as a way to link into Web of Science from their library web page or institutional repository. Subscribers to Journal Citation Reports can use this service to retrieve links to the JCR record for a given journal.”

There is then a form to fill out “to find out how to create direct links to Web of Science articles or Journal Citation Reports” – I’m pretty sure I’ve already filled it out back when we were submitting the bid but this is something to check out with Jon when he comes on Wednesday…

So though things are not crystal clear quite yet, Tuesday and Wednesday next week should put us firmly on the right track.