December ZIG: proposed focus sessions

This is the second of two messages conveying preliminary information about the
December ZIG meeting. This message describes proposed "focus sessions".

Please post thoughts on any of these proposed sessions, described below. List
discussion prior to the meeting will make these sessions more valuable. Please
also feel free to suggest additional topics.

And (most importantly) please consider volunteering  to help develop one or more
of these sessions.


1.  The Z39.50 url
--------------------
What purposes should a Z39.50 url serve? Are the existing  definitions (z39.50r
and z39.50s) 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?

The tentative "leads" for this session are: Kevin Gamiel, Dave Vieglas, and
Eliot Christian.


2. Explain
-----------
What problem is Explain *intended to* solve? What problem *does* it solve? What
problem *should*  it solve? What information should servers provide, and how?
Should the existing Explain definition be replaced by something more useful?

Someone please volunteer to chair this session.


3. Distributed Searching
------------------------
Focusing on integrating results. With demos.

Tentative "leads": Sebastian. Hammer and Ralph LeVan.


4. XML Query Language
--------------------------
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.

Chair for this session: Mark Needleman. We will also invite the W3C XML/QL WG
Chair, to participate in the discussion.


5.   Z39.50 as an XML application.
------------------------------------
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 an alternative encoding, XER, based on XML, now is an alternative to
ASN.1/BER. 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? HTTP?
Directly over TCP?

Tentative Chair for this session: Poul Henrik Jorgensen.


6.  New service-definition specification-technique for Z39.50.
-------------------------------------------------------------
This is not a new topic; it comes up repeatedly and  it arose again at the last
meeting: Can we re-write the Z39.50 service definition (independent of the
protocol) so that it is more-easily understood and implemented. For example, one
approach would be to define a layer above the service definition, consisting of
“verb”s (as in the Dienst protocol), that then map onto Z39.50 services.  For
example, consider these two functions: “List formats supported for a Database”
and “List formats supported for a record”. Though similar, the first maps to
Explain and the second involves a number of retrieval functions (including
variants, eSpec).  This complexity could be hidden at the “verb” layer.
Subsequently, profiles could be expressed largely in terms of verbs, and not
need to refer extensively to the Z39.50  services.

Chair: Ray Denenberg


7. Virtual Libraries.
-------------------
 Union catalogues, holdings, circulation, ILL.

Tentative leads:  Pat Stevens, Barbara Shuh, Ralph LeVan.


8. Digital Libraries.
-------------------
Discussion of Z39.50's role in digital library applications, for example, Open
Archives.

Tentative Leads: to be announced.




--
Ray Denenberg
Library of Congress
rden@loc.gov
202-707-5795

Received on Tuesday, 26 September 2000 10:35:01 UTC