December 2000 ZIG Meeting
Focus Sessions

Updated: December 29, 2000


XML Query Language

Chair: Mark Needleman

Guest Speaker: Paul Cotton, Chair of the W3C XML QL WG

Abstract: The W3C currently has an activity to define an XML Query language. A W3C Working Draft (August 15, 2000) specifies goals, requirements, and usage scenarios for the XML Query data model, algebra, and query language. There has been ongoing debate within the ZIG over the relationship between XML/QL and Z39.50. In the context of Z39.50, XML/QL is analogous to a query type (e.g. type-1) and theoretically it might be possible to adopt XML/QL as Z39.50 a query type, though this would mean close liaison between the ZIG and the W3C XML/QL WG to ensure compatibility with Z39.50. There are arguments for and against adopting XML/QL as a Z39.50 query type. The argument in favoring is that the w3c working group is not defining a protocol, just a query language, and so ultimately will need to wrap it in a protocol; Adopting XML/QL as a query type would forestall the process of defining another information retrieval protocol that would likely re-invent much of the Z39.50 functionality. The argument against adopting XML/QL as a query type (some say) is that there is little or no benefit to the Z39.50 community (there is little overlap of information retrieval and XML-style querying) and the expenditure of ZIG resources is not justified, and further, the W3C may be resistant to technical accommodation (to make the XML/QL compatible with Z39.50) that the ZIG would propose.

Presentations:


Z39.50 as an XML Protocol

Chair: Poul Henrik Jørgensen.

Abstract: Z39.50 abstract syntax and encoding have been under scrutiny for several years, increasingly so since the rise of XML. Both the abstract syntax notation (ASN.1) and the encoding (ASN.1/BER) have been discussed in terms of XML. In fact there is an alternative to ASN.1/BER-- XER: "XML Encoding Rules (for ASN.1)". Of course XER still presumes ASN.1 as the abstract syntax (it merely provides a way to encode the ASN.1 described structures in XML). But for several years now, dating back even to pre-XML times, the use of ASN.1 itself (as an abstract syntax notation) for use with Z39.50, has been called into question: the 1992 version of ASN.1 is the only viable version (Z39.50 cannot consider migrating to a later version - 1994 or 1998) and the 1992 version is growing old, becoming outdated, and may soon no longer be supported. In recent months there seems to be growing enthusiasm for re-defining the Z39.50 abstract syntax via XML. This doesn t mean starting again with an entirely new protocol development effort, but rather to retain the rich Z39.50 semantics, functionality, and modelling, expressing these via XML rather than ASN.1. This raises many question, not the least of which are: is this a good idea? Is it achievable? Another important question is: to what extend would this new version maintain compatibility with earlier versions? (By compatibility , we mean functional and semantic compatibility. Bit-compatibility would be lost.) Should it be compatible with version 3? If so, can compatibility with version 2 be dropped? How would this XML application be layered within the web protocols? Should it define bindings to SOAP? XP? HTTP? TCP?

Presentations:


Explain

Chair: Bob Waldstein

Abstract: This session will contemplate the possibility of re-defining Explain. We should ask: What problem is Explain intended to solve? What problem does it solve? What problem should it solve? What information should servers provide, and how? What is the impact on existing implementations of re-defining Explain?

Presentations:


Virtual Library Services

Chair: Pat Stevens

Abstract: Today, many libraries are working cooperatively to bring their collected resources to the Web. These virtual libraries are more than just catalogs; a user may obtain all of the services available in the library on the Web � including personal reference service.

Union catalogs with dedicated loan systems may form the basis of a virtual library, but in many cases, a single library may belong to multiple virtual libraries. This makes it desirable that standards allow libraries to use the systems they have in place. The session will present practical experience from the field in building and maintaining virtual library systems.

Presentations:


Profiles
Chair: Bill Moen

Abstract: Z39.50 Profiles are specifications for using Z39.50 in particular applications. This session gives an brief overview on profiles, what they do, and why they are important. There will be reports on the Bath International Profile for Library Applications, library application profile development and use in Europe, the Government Information Locator/Global Information Locator Profile, and the new NISO standards effort to develop a US National Z39.50 Profile for library applications.

Presentations:

 


Z39.50 URL

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?

Presentations:

Questions:

  1. Is current usage so minimal that we can simply "start over"? Is anyone actually using ZURLs, or is this all an academic exercise?
  2. If we generalize it, is this a job for the ZIG? Or IETF, W3C, etc?
  3. How transient is a URL?
  4. Should we have result set offsets in a URL?
  5. How do we address a specific result record for a system without the docID concept?
  6. 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?
  7. 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 appropriate. 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 produced may not be appropriate for all classes of users.
  8. It is possible to provide a stateful implementation of Z39.50 URLs without the need for alternative Z39.50 protocol identifiers?

Expectations

  1. Explore how z-urls are currently used.
  2. 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?
  3. Based on 1 and 2, determine if a new definition is needed.
  4. 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.

Notes about implementation and usage of Z39.50 URL from Dave Vieglas.

 


Digital Libraries

Chair: Denise Troll

Presentations:


Library of Congress