Z39.50 URLs

1
Z39.50 URLs
December 2000 ZIG
2
Chair Kevin Gamiel
Abstract How are Z39.50 URLs (Z39.50s and
Z39.50r) being used? What purposes should a
Z39.50 url serve? Are these existing definitions
serving these purposes? Should they be revised?
Should a new Z39.50 url be defined? And if so,
should it replace or compliment the existing
definitions?
3
Plan

• Introductory overview, background, etc.
• "Current Z39.50 URL". Describe the current
  Z39.50 URL, it's structure, what can be done with
  it.
• "Current uses". The ways that ZURLs are
  currently used in applications.
• "Future". Desired use of a Z39.50 URL.
  Generalizing the URL structure beyond a Z39.50
  scope.

4
Expectations

• Explore how z-urls are currently used.
• Explore the potential utility of a newly-defined
  Z39.50 url -- what would people like to use a
  Z39.50 url for, if they could?
• Based on above, determine if a new definition is
  needed.

5
Expectations (continued)

• If so, set in motion a process to determine the
  requirements, develop a definition, and to reach
  agreement. Stress "set in motion the process"
  we're not planning to determine requirement,
  develop a definition and reach agreement in this
  session, just to set the process in motion.

6
Z39.50 URLs
History and Overview December 2000 ZIG
7
September 1994 ZIG Meeting at CNIDRMinutes
from Denise Troll

• session and fetch URL
• Z39.50//hostport/database/docID/...
• When users click on this URL, it will open a
  Z39.50 client ("helperapplication"), point to the
  existing service, construct a RPN query, and
  return a result set with one or more items. The
  Z39.50 client will theneither convert the items
  to HTML for display in Mosaic or open the Z39.50
  client to the user. The Z39.50 client is
  responsible for determining whether or not to
  open to the user. Brad McLean

8

• Potential problems cited for this proposal were
• DocIDs change over time. The ID should be a
  logical ID. Ryan Troll
• What about the result set name?
• Is this a transient or persistent result set Ray
  Denenberg?
• Three unresolved issues remain Brad McLean
• Element set names
• Should we restrict this to retrieving a single
  document or enable retrieving multiple documents
  (with the client deciding what to do if there are
  multiple items)?
• Access control (user ID and password).

9

• Do we want 2 URLS, one to fetch and close, the
  other to be interactive, or 1 URL (that launches
  a helper to determine whether to fetch and close
  or run interactive)?
• Mark Hinnebusch framed the question, but many ZIG
  members participated in the lengthy debate, in
  the midst of which Ray Denenberg pointed out that
  the URL must include the record syntax. The
  debate was tedious, but well done, with ZIG
  members switching camps throughout.

10

• Leaders (rhetors) eventually arose for the two
  camps and final arguments were given. Ralph
  LeVan argued for 2 URLs. Denis Lynch argued for
  1 URL. Mark Hinnebusch somehow divined concensus
  and the shot was called there will be 2 URLs
• Search URL
• Z39.50s//hostport/databasedatabase...
  /termESNelementsetRSrecordsyntaxrec
  ordsyntax
• Retrieve URL
• Z39.50r//hostport/databasedatabase...
  /termESNelementsetRSrecordsyntaxreco
  rdsyntax

11

• Database name is required. Any missing
  components default to the client's choice. If
  more than one record syntax is provided, the
  first one in the sequence is preferred. If the
  client cannot handle the preferred syntax, it my
  choose among the others.
• John Kunze was commissioned to take our URL
  proposal to the IETF URL group.

12
1996 -- RFC 2056Uniform Resource Locators
for Z39.50

• The Z39.50 Session URL
• The Z39.50 Retrieval URL

13
z39.50url zscheme "//" host "" port
"/" database ""
database "?" docid
"esn" elementset
"rs" recordsyntax " recordsyntax zsche
me "z39.50r" "z39.50s Future
extensions to these URLs will be of the form
keywordvalue.
14
Z39.50 Session URL

• informally described as providing the
  mechanism to switch the user to a z39.50 client
  application.
• Host is required.
• Port is optional, and defaults to 210.
• All other parameters are optional.
• Z39.50 client starts a session to the specified
  host/port (need not explicitly start a session,
  may instead utilize an already open session to
  the same host/port).

15

• A database must be included if docid is
  included.
• If docid is included, the client will perform
  the specified search
• If docid is not included, and other parameters
  (besides host/port) are specified, the client
  may use those parameters as "hints".
• Various clients may choose to treat them as
  requirements, or as preferences, or ignore them.

16

• In any case (whether a search is Performed or
  not), the client leaves the Z39.50 session open
  for the user, to do retrievals, new searches,
  etc. (This is the main distinction from the
  Retrieval URL which leaves it up to the client
  whether or not to keep the Z39.50 session open.)

17
The Z39.50 Retrieval URL

• Intended to allow a Z39.50 session to be used as
  a transparent transfer mechanism to retrieve a
  specific information object.
• A Z39.50 client uses information in the URL to
  formulate a Search Request. The server's Search
  Response indicates how many records match the
  Request.

18

• If number of matching records not equal one
• the retrieval is considered unsuccessful, and
  the client application's behavior is not defined.
  
• If number of matching records equals one
• the server may have included the desired record
  in the Search Response. If not, the client
  requests transmission of the record with a
  Present Request.
• After the client has received the specified
  record it may close the Z39.50 session
  immediately, or keep it open for subsequent
  retrievals.

19

• Host required.
• Port optional, default 210.
• Database required.
• The meaning of a retrieval URL with no docid is
  undefined.
• docid placed into a type-1 query, as the single
  term, in the general format (tag 45)
• Bib-1 attribute set
• Use attribute docid
• structure attribute of URx
• The docid string is server-defined and completely
  opaque to the client.

20
Questions

• Are there other current uses we didn't list?
• Is current usage so minimal that we can simply
  "start over"? Is anyone actually using ZURLs, or
  is this all an academic exercise?
• If we generalize it, is this a job for the ZIG?
  Or IETF, W3C, etc?
• How transient is a URL?
• Should we have result set offsets in a URL?
• How do we address a specific result record for a
  system without the docID concept?

21
Questions

• Can we stringify the Z39.50 query structure in a
  manner suitable for including in a URL, making it
  simpler for the lay-person to construct one?
• What about the content of the response to a
  Z39.50 URL? Although it may not be entirely in
  the context of a Z39.50 URL definition
  (implementation rather than definition) Some
  discussion about this may be appro-priate. For
  example consider an implementation that
  transforms everything to XML for transmission to
  the client process, convenient for
  post-processing of results, but the structure of
  the XML document pro-duced may not be appropriate
  for all user classes.

22
Questions

• Is it possible to provide a stateful
  implementation of Z39.50 URLs without the need
  for alternative Z39.50 protocol identifiers?