(Unfortunately, SlideShare doesn't seem to respect the animation I had put in so some of the diagrams in the above will be a little dense. But bear with me .. and remember, "when you hear this sound," [CLICK] "please turn the page.")

The KBART working group's goal is to improve the supply of data to link resolvers and knowledge bases, in order to improve the efficiency and effectiveness of OpenURL linking. [CLICK] I figured, therefore, that it would be useful to start with a recap explaining what the OpenURL is, why it came into existence, and how it works. I followed that with an overview of the various groups within the information community who have an interest in making sure that it works effectively, and an exploration of what each group contributes to the process. Then I explained what a knowledge base is and why it is a key part of the OpenURL process, before suggesting some ways in which that process can break down. This brought us nicely to introducing the KBART working group, how it came into being, and what it sets out to do.

About half of the delegates at each of my sessions were serials librarians, with the remainder split about equally between publishers and technology/service vendors. So my explanations are biased towards serials librarians, particularly in that they reference "journals" and "articles" when these are just two of the many types of object which OpenURLs can describe. (They are also the area in which OpenURL usage is most prevalent, and therefore the area in which most problems have been encountered to date).

Origins of the OpenURL
[CLICK]
OpenURL is a NISO standard. It was developed to solve the "appropriate copy" or "Harvard" problem, where (once online publishing took off) different versions of a single article began to exist online, and a user was unlikely to have a licence to all of them. Conventional reference linking in those days (>5 years ago) involved hard-coding links between one supplier and another, so users were often linked to the “wrong” version of an article, one which they were not licensed to access. In the worst case scenario, this would result in a user undertaking a document delivery or pay-per-view transaction to obtain an article that might actually have been licensed elsewhere by the library.

The OpenURL was designed to perform “context-sensitive” linking, whereby links are flexible and able to take into account the user’s institutional affiliations and the licences of that institution. It became a standard and has since been widely adopted. Here’s a graphic explanation of all that [CLICK - this next slide was beautifully animated to walk through each of the steps, which made it a little easier to follow. View the animated version here]. Explanation of graphic (if viewing the animated version, click at the end of each bullet to bring in the next step):

• a user comes across an article citation
• it could be linked to the full text on a publisher's website
• or in a database
• or in a gateway
• the full text might be in a print collection
• or in a repository.
• But, any one of these links might take the user to an "inappropriate" copy i.e. one which he is not entitled to access.
• However if the institution has a link resolver, it can register
• the base URL of that link resolver with the provider of the article.
• The provider also knows the metadata of the citation
• and can put this together with the base URL of the link resolver to form an OpenURL query.
• This query is directed to the link resolver, which contains a knowledge base of
• library and
• publisher holdings data. They are assessed to find a match (where the library indicates that it subscribes through a particular provider, and the provider indicates how to link to its content).
• The link resolver can then put together a predictable link to the cited article
• to which the library has indicated that it has a licence.
• That's the way to do it!

Which bits do publishers do?
[CLICK]
I avoided going into the specifics of OpenURL compliance, and just indicated the requirements for publishers at the simplest level. In the context of KBART, it is useful to consider that a publisher is OpenURL compliant if it is able to create OpenURLs within its citations, and that a publisher is “knowledge base compliant” if it has provided holdings data and a predictable linking syntax to knowledge base providers.

• OpenURL compliance makes you a source
• knowledge base compliance makes you a target
• they can be separate
• together, they make you fully compatible with link resolvers.

Which bits do libraries do?
[CLICK]
Again, at its simplest, libraries need to have a link resolver, and need to register it with content providers (publishers). They, or their link resolver supplier, also need to customise the resolver's knowledge base with their own holdings data.

What does the link resolver do?
[CLICK]
The link resolver takes an OpenURL and extracts the article metadata. It compares this to the information provided by the library, in its knowledge base, to find out where the article is available, and which version is preferred by the library. Then it uses the information provided by the publisher to create a predictable link to its preferred version. Note that a predictable link is not an OpenURL. It needs to follow a formula, but not necessarily the same formula as the OpenURL.

Hang on. What is a knowledge base?
[CLICK]
It's a database that contains information about web resources (what content is where, and how to link to it) and about the resources licensed or owned by the library. [CLICK] It is important because it knows where all the content is, which versions the library is able to access - and so is the only place that can get a user to an "appropriate copy" for them.

To summarise, then: [CLICK]

• user finds citation
  
• OpenURL is sent to his link resolver
  
• link resolver redirects him to cited article

But, this only works if the data supplied to the knowledge base is accurate, and is provided in a timely manner. If it isn't, [CLICK], the chain breaks: wrong data or [CLICK] outdated data will lead the user to a data end (very frustrating) and prevent traffic from reaching the publisher's site.

So what is KBART?
[CLICK]
The Knowledge Bases And Related Tools working group is a collaboration between UKSG and NISO, intended to improve navigation of the e-resource supply chain by ensuring timely transfer of accurate data to knowledge bases, e-resource management systems, etc.. [CLICK] It was established following a 2007 UKSG research report, Link Resolvers and the Serials Supply Chain; its key findings indicated that a lack of awareness of the OpenURL's capabilities is impacting the quality and timeliness of data provided to knowledge bases, which is undermining the potential of this sophisticated technology.

[CLICK] The working group is chaired by me and by Peter McCracken of SerialsSolutions, and consists of representatives from all the major stakeholder groups in the information supply chain - link resolver and ERM suppliers, publishers, agents, aggregators, libraries and consortia. The group's mission [CLICK] is to create guidelines for best practice, to educate the necessary parties as to the importance of adhering to these guidelines (and of the OpenURL in itself), and to provide an information hub for resources relating to knowledge bases and OpenURL linking. We plan to achieve this [CLICK] first by agreeing on the core terminology, then by identifying and selecting the problems to be addressed and finally by recommending solutions that can be adopted.

To wake everybody up, at this point I took the session all interactive, and encouraged the audience to contribute their own suggestions for terminology [CLICK] and problems [CLICK] that the KBART group could useful define and address, respectively. We received a wealth of suggestions, particularly of problems that delegates are encountering day-to-day, and these have all been noted for consideration by KBART. (Several, we have to acknowledge upfront, will be outwith the group's mandate/scope, but we will pass them on to other appropriate groups where possible). Problems highlighted included:

• title changes, abbreviations and relationship modelling
• insufficient granularity in knowledge base licence data
• disconnects between package definitions as communicated to the customer and to the knowledge base
• lack of supply chain mapping / responsibility allocation
• "blocking" of Open Access journals since these are not indicated as "licensed".

[CLICK] We're aiming to deliver some initial outputs from the project by the next UKSG conference (April 2009), at which point we will consider whether it is necessary to create a standard (thereby effectively mandating, rather than encouraging, compliance) and we'll assess what areas to address with future phases of the project.

For more info about KBART, please check out our website: http://www.uksg.org/kbart, where you can (amongst other things) sign up for the KBART interest group mailing list to be alerted ongoing with details of the group's progress.

The PT posse will be at the UKSG annual conference next week. We've got a stand (56 - branded as Publishing Technology so look for the squares not the eye!) - halfway between the exhibition hall entrance and the lunch, so we'll be looking out for you as you queue for rations. It would be worth swinging by if you're there, if only to check out the groovy new design in the works for IngentaConnect (no blogger previews, I'm afraid - not yet, anyway).

I will once again be blogging the conference so if you can't be there, be sure to keep an eye on LiveSerials to find out what's happening ... who's happening ... where it's happening ... whether it's happening? (of course it will be!)