1 / 10

Summary of Z39.50 initiatives relevant to GIR

Background. IS and QP interfaces in GIR share a common API for searching and retrievalOur work to specify this part of GIR will overlap with work done in the IR standards community over more than 20 years, centered around Z39.50 and related open standards such as SRWIn principle, it would be good

hayley
Download Presentation

Summary of Z39.50 initiatives relevant to GIR

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. Summary of Z39.50 initiatives relevant to GIR Nassib Nassar (Etymon)

    2. Background IS and QP interfaces in GIR share a common API for searching and retrieval Our work to specify this part of GIR will overlap with work done in the IR standards community over more than 20 years, centered around Z39.50 and related open standards such as SRW In principle, it would be good to leverage that work rather than “reinventing the wheel”

    3. How to leverage it? Current direction of GIR-WG is to investigate the feasibility of taking the good and leaving the bad from relevant standards There are trade-offs to importing or modifying vs. “pointing to” relevant standards Ultimately it will depend on the details of how well suited they are to GIR

    4. Z39.50 ANSI/NISO Z39.50 is also known as the international standard, ISO 23950 It is an IR service definition and protocol specification designed to provide interoperable searching and retrieval Widely implemented in library systems Based on ASN.1 and (usually) BER, running over TCP/IP; rather complex and heavy Contains many useful concepts and semantics Library of Congress is the maintenance agency: http://www.loc.gov/z3950/agency/

    5. ZING ZING is “Z39.50 International: Next Generation,” a collection of initiatives to make the “intellectual/semantic content” of Z39.50 usable in a broader set of applications ZING initiatives include SRW/SRU, CQL, ZeeRex, and ZOOM These initiatives represent most of the current specification activity related to Z39.50

    6. SRW/SRU SRW is the “Search/Retrieve Web Service” specification, a somewhat simplified reworking of Z39.50 semantics based on web services SRW defines a web service; SRU is an HTTP GET form of the service

    7. CQL Common Query Language (CQL) is designed for SRW/U as a substitute for the query mechanism of Z39.50 It is text based (i.e. human readable) XCQL is a direct rendering of CQL semantics in XML and can also be used in SRW/U

    8. ZeeRex ZeeRex is an effort to rework the “explain” function of Z39.50 as an XML schema ZeeRex is SRW/U’s equivalent of Z39.50 explain The purpose of explain/ZeeRex is to provide information about the supported features and current state of a Z39.50/SRW server In Z39.50, explain was implemented as a searchable database; in SRW, it is a static XML document conforming to ZeeRex

    9. ZOOM ZOOM is the “Z39.50 Object-Orientation Model,” an abstract OO API extracted from a subset of the Z39.50 semantics Does not specify any protocol behind the API Fairly intuitive, generic OO model, but does not necessarily match current GIR model

    10. Discussion topics (1) Z39.50 is probably too complex for our use; SRW/U may be too simple Unlike ZOOM, Z39.50 and SRW/U include underlying protocol specifications; however, all three contain API-like semantics that we can use. Which one is most relevant to GIR? SRW/U is based on static web services; would it translate well to the instantiatable grid service model?

    11. Discussion topics (2) ZOOM’s default connection model appears to be based on the instantiation of a Connection object, which does not map to the IS/QP life cycle; is there a way around this mismatch? ZOOM models queries, result sets, and result set records as object classes; does the model allow us to choose which of these to model as grid services? The last point seems to be related to Matthew Dovey’s suggestion of implementing result sets as grid services

More Related