1 / 34

European Endeavor Users Group Meeting Helsinki, Sept 1-6 2003 Esa-Pekka Keskitalo, System Analyst

OpenURL 1.0. European Endeavor Users Group Meeting Helsinki, Sept 1-6 2003 Esa-Pekka Keskitalo, System Analyst Helsinki University Library. Outline. Background The Draft OpenURL in Libraries. Background. Appropriate Copy Problem Broken Link Problem

jparkhurst
Télécharger la présentation

European Endeavor Users Group Meeting Helsinki, Sept 1-6 2003 Esa-Pekka Keskitalo, System Analyst

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. OpenURL 1.0 European Endeavor Users Group MeetingHelsinki, Sept 1-6 2003 Esa-Pekka Keskitalo, System Analyst Helsinki University Library

  2. Outline • Background • The Draft • OpenURL in Libraries

  3. Background • Appropriate Copy Problem • Broken Link Problem • Appropriate Copy – Linkking should be user sensitive • Broken Links should be fixed centrally (need to be fixed somewhere)

  4. OpenURL is ”a methodology for describing • resources that that are referenced in a networked environment • contextof the reference” • Neutrally in respect to applications and user communities

  5. From 0.1 to 1.0 • Much extended • ”Registry” • From ”scholarly” to a more general approach

  6. Standard in two parts • ContextObject • A description of a resource that is referenced (target) • A description of the context of the reference (source) • A definition of a set of Namespaces • Registry • Detailed lists of options – will expand

  7. A Context Object is a Set of Entities • Context Object is an information construct with six Entities. • Referent is the core entity sine qua non • Referent = what is being referenced= what we e.g. want to read in fulltext

  8. Referring Entity Resolver ContextObject Entities Service type Requester Referrer Referent

  9. ContextObject Entities • Referent: a referenced resource, e.g. an article, a person etc. • Referring entity: where the reference is, e.g. an article • Requester: who is using the system • Service Type: what is wanted, e.g. ”fulltext” • Resolver: the target resolving service • Referrer: The system that generates the ContextObject.

  10. ContextObjectEntitiesDescriptors Detailed information about an Entity. • Identifiers • Metadata-by-Value • Metadata-by-Reference • Private Data

  11. ContextObjectEntitiesDescriptors1) Identifiers Defines • Namespace that is being used • Identifier, unique in that Namespace Namespace: DOIIdentifier: 10.1126/science.275.5304.1320 Namespace: MailtoIdentifier: some.one@helsinki.fi Namespace: ISSNIdentifier: 1234-5678

  12. ContextObjectEntitiesDescriptors2) By-Value Metadata Defines • the metadata format used • metadata expressed in that format Metadata: MARC21 = MARCXML Schemarft_val_fmt = ori:fmt:xml:xsd:MARC21 <?xml version=”1.0” encoding=”UTF-8”?>---<varfield id="245" i1="1" i2="0"><subfield label="a">Policing the new world disorder /</subfield> <subfield label="c">by Robert Oakley and Michael Dziedzic.</subfield> </varfield>

  13. ContextObjectEntitiesDescriptors3) By-Reference-Metadata Defines • the Metadata Format used • the network location of the metadata Metadata: MARC21 = MARCXML Schema rft_ref_fmt = http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd rft_ref = http://www.loc.gov/standards/marcxml/Sandburg/sandburg.xml

  14. ContextObjectEntitiesDescriptors4) Private Data • Not defined in the Standard • Specific to the Referrer (the generator of the ContextObject) • Must be understood by the Resolver

  15. ContextObjectEntitiesConstraints • Exactly 1 Referent in one ContextObject • No more than 1 Referring Entity, Requester, Referrer • Zero or more Service Types and Resolvers. • All Descriptors may describe all Entities • Multiple Descriptors possible

  16. REGISTRY • description of network-referenced resources • description of the context of the references • support of transportation of the descriptions over the network

  17. RegistryComponents • Namespaces • 3 Naming Environments • Character Encodings • Physical Representations • Constraint Languages • Context Object Formats • Metadata Formats • Transports • Community Profiles

  18. Registry Components1) Naming Environments • URI – Uniform Resource Identifier • ORI – Open Resource Identifier • XRI – Private Resource Identifier

  19. Registry  Components Naming Environmentsa) Uniform Resource Identifier • Internet Assigned Naming Authority (IANA) • http, ftp, mailto • ldap • urn, urn:ISBN, urn:ISSN, urn:NBN

  20. Registry  Components Naming Environmentsb) Open Resource Identifier • bibcode, doi, isbn, issn, oai, sici • Id for Referrers: • domain name + string • Id for Service Types: • abstract, citation, fulltext, holdings, ILL

  21. Registry  Components Naming Environmentsc) Private Resource Identifier • Not defined any further

  22. Registry  Components 2) Encodings • Character Encodings • UTF-8, ISO-8859-1, Big5 • IANA List

  23. Registry  Components 3) Physical Representations • Physical Representations • XML and KEV (Key/Encoded Value) • KEV specified in the Standard

  24. Registry  Components 4) Constraint Languages • Constraint Languages • Z39.88-2003 MTX • W3C XML Schema

  25. Registry  Components 5) Context Object Formats • Format • a concrete method to express a class of information constructs • Physical representation + constraint language+ constraints • A definite choice set within the Format triple • KEV + MTX + Matrix of Section 8.1. of Part 2 • XML + XSD + XML Schema of Section 8.2 of Part 2

  26. Registry  Components 6) Metadata Formats • MARC 21 • OAI_dc • XML and KEV metadata formats for books, dissertations, journals, patents specially defined

  27. Registry  Components 7) Transports • Method of tarnsporting over the network • OpenURL 0.1 for backwards compatibility • 6 combinations: OpenURL http or https • inline • by reference GET / POST • by value GET / POST

  28. Registry  Components 8) Community Profiles • A set of choices from Registry entries for an application domain • 1 Context Object Format • Metadata Formats • URI and ORI Namespaces • Transports • Identifiers • Expressed in XML

  29. Draft Standard 1.0 • Released in March • Time for testing and comments ends in November, 2003 • Big changes to version 0.1

  30. OpenURL resolving server • Resolving server needs constat attention • Centralised update services emerging, but - • Central knowledge needs adjusting • Local knowledge needed in addition • Growing demand for reliable identifiers • A standard for knowledge database format would be useful

  31. Library Systems • Need to be ”OpenURL Enabled” • 0.1 ”pretty easy”; how about 1.0?

  32. OpenURL and cataloguing • What should be catalogued into the records? • Every static URL in records will be a problem • Static URLs still useful as long as they work • Cataloguing rules revision?

  33. OpenURL and the others • DOI and URN are for persistent linking, OpenURL for context-sensitive linking Work well togethet • OpenURL is not a new Z39.50. With OpenURL, you have to know what you are looking for. • OpenURLs are not for human eyes

  34. OpenURL in the Future • OpenURL is gaining momentum • Standardisation • Sharing of knowledge • Identification • Software development

More Related