1 / 34

UKOLN is supported by:

An overview of the OpenURL UKOLN/JIBS OpenURL Meeting London, September 2003 Andy Powell, UKOLN, University of Bath a.powell@ukoln.ac.uk. UKOLN is supported by:. www.bath.ac.uk. www.ukoln.ac.uk. A centre of expertise in digital information management. Contents.

kwashington
Download Presentation

UKOLN is supported by:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. An overview of the OpenURL UKOLN/JIBS OpenURL Meeting London, September 2003 Andy Powell, UKOLN, University of Bath a.powell@ukoln.ac.uk UKOLN is supported by: www.bath.ac.uk www.ukoln.ac.uk A centre of expertise in digital information management

  2. Contents • overview of OpenURL background and functionality • examples • current and future status • issues

  3. Acknowledgements • Thanks to Herbert Van der Sompel for the contents of some of the following slides…

  4. Background and functionality

  5. Origins of the OpenURL • the context • distributed information environment (JISC IE) • multiple A&I and other discovery services • rapidly growing e-journal collection • need to interlink available resources • the problem • links controlled by external info services • links not sensitive to user’s context (appropriate copy problem) • links dependent on vendor agreements • links don’t cover complete collection

  6. The problem • the context • distributed information environment • multiple A&I and other discovery services • rapidly growing e-journal collection • need to interlink available resources • the REAL problem • libraries have no say in linking • libraries losing core part of ‘organising information’ task • expensive collection not used optimally • users not well served

  7. OpenURL OpenURL resolver (link server) The solution… • do NOT hardwire a link to a single service on the referenced item (e.g. a link from an A&I service to the corresponding full-text) • BUT rather • provide a link that transports metadata about the referenced item • to another service that is better placed to provide service links

  8. link source link destination Non-OpenURL linking document delivery service A&I service . link to referenced work reference resolution of metadata into a link (typically a URL)

  9. link link link link link destination link destination link destination link destination OpenURL link source OpenURL resolver OpenURL linking document delivery service A&I service user-specific transportation of metadata & identifiers . reference context-sensitive provision of OpenURL resolution of metadata & identifiers into services

  10. Brief history of the OpenURL • ~1998 – nature of solution determined • ~1999 – first real experiments (Ghent, LANL, Wiley, SilverPlatter, Ex Libris, arXiv, …) • ~2000 – OpenURL 0.1 released, adoption by community, SFX beta released • ~2001 – integration of OpenURL and DOI/CrossRef frameworks, first non-SFX resolvers appear • proposal to standardise OpenURL framework thru NISO…

  11. Examples

  12. Example 1 • journal article • from Web of Science to ingenta Journals

  13. button indicating OpenURL ‘link’ is available

  14. OpenURL resolver offering context-sensitive links, including link to ingenta

  15. also links to other services such as Google search for related information

  16. Example 2 • book • from University of Bath OPAC to Amazon

  17. button indicating OpenURL ‘link’ is available

  18. OpenURL resolver offering context-sensitive links, including link to Amazon

  19. also links to other services such as Google search for related information

  20. ingenta Summary… ISI Web of Science Google OpenURL resolver University of Bath OPAC Amazon OpenURL Resolver OpenURL Source OpenURL Target

  21. Summary (2) • OpenURL source • a service that embeds OpenURLs into its user-interface in order to enable linking to most appropriate copy • OpenURL resolver • a service that links to appropriate copy(ies) and other value added services based on metadata in OpenURL • OpenURL target • a service that can be linked to from an OpenURL resolver using metadata in OpenURL

  22. Current and future status

  23. OpenURL status in UK • OpenURLs currently in use in some form at • Bradford, EDINA, Edinburgh, UEA, Derby, Bath, Bangor, MIMAS, Royal Holloway, Westminster, Swansea, … • OpenURL technology available from several vendors • Ex Libris (SFX), Openly Informatics (1Cate), Endeavor (LinkFinderPlus), FD (OL2) • open source solutions • ZBLSA

  24. Standardisation • all current OpenURL deployment is based on OpenURL version 0.1 • NISO currently standardising version 1.0 • expect to see gradual transition over next 12-24 months or so towards greater use of version 1.0 • …

  25. NISO OpenURL version 1.0 • retains notion of transporting metadata to obtain context-sensitive services • more flexible framework (metadata, syntax and transport) • version 0.1 limited to bibliograph resources • version 1.0 extensible to other communities (e.g. eLearning)

  26. Issues

  27. Issues for ‘resolvers’ • selecting OpenURL resolver software • hosted vs. in-house? • same vendor as library system or not? • maintaining OpenURL resolver configuration tables (knowledge base) • this is where bulk of your effort is required • ideally need to include details of all physical and electronic holdings • may buy-in some of the information from 3rd-party supplier (e.g. serialsolutions.com) based on knowledge of subscriptions

  28. Issues for ‘sources’ • remember… you’ll probably want to make your OPAC an ‘OpenURL source’ • in general, need to maintain knowledge of end-user’s prefered OpenURL resolver… • … but in the case of an institutional OPAC, can probably hardwire the same resolver for everyone?

  29. Issues for ‘targets’ • remember… you’ll probably want to make your OPAC an OpenURL target • need to identify mechanism for deep-linking into ‘target’ service from OpenURL resolver • e.g. does ‘target’ support URLs based on ISBNs or ISSNs? • need to disclose this mechanism to resolvers (but no standard way to do this yet)

  30. Questions?

More Related