Re: ZNG dicussion

I am afraid I wont be able to make it to any ZIG meetings in the forseable
future - so took this as an excuse to put forward my personal opinion
since this got raised again :-). I have just finished a first version
of a generic SOAP tool kit into our product which has a Z39.50 library,
so I am also in a position to build a SOAP->Z39.50 gateway fairly easily.
I should also point out that I use Z39.50 in a document management
environment, not libraries with MARC records etc. So I have a different
view on the world possibly than the main ZIG community (which could
be good or bad).

The following is all my own personal opinions. I have probably missed
things too. I am presonally very interested in a SOAP gateway to Z39.50.
The exposed API would not be Z39.50. It would just be easy to translate
between Z39.50 and SOAP.

Z39.50 Strengths
----------------
To me, strengths of Z39.50 are

* The separation of access points from physical data representation.
  One query can be easily submitted to multiple databases with completely
  different types of data in them.

* When fetching records, you can ask for full or brief, which again is
  abstraction layer away from the physical representation.

* GRS-1 is good because it has a fairly rich and complex data model
  (tree of named values). Values can have metadata attached (applied
  variants) holding things such as MIME types for the data.

* Scanning is good to explore the contents of a database. It gives a
  feel for what is there.

Z39.50 Weaknesses
-----------------
To me, weaknesses of Z39.50 are

* The protocol is too large and hard to implement at the low level.
  When an existing tool kit does not do the job, you are stuck.

* There are too many concepts. This makes joining the crowd hard, or
  makes interoperability hard.

* Its still not that easy to use from major programming languages.

* Numeric values for attributes is ugly - there is no standardized human
  readable query language.

* While USE attributes are good, all the other attributes I think should
  be part of the query language, not defined in Bib-1.

SOAP -> Z39.50
--------------
In order to get the benefits and not the weaknesses, I would like to see
a SQL-like textual query language. CCL-based seems logical (but I would
tighten a few things up). I would introduce a standard set of attribute
names for USE attributes (Author, Title, ... not 1/1003). In practical
terms, I would like to see for Bath and other such protocols a set
of standard names for use in CCL when issuing the standard queries that
must be supported. (In other words, the names are bound on to attribute
lists.)

I would like to see index scanning based on the same names as searching.
To me you scan a list of terms you can use in queries. That is why
you scan.

I would like to see Explain cut back a lot to a base set of simple
well defined concepts using XML. Then application specific extensions
could be dropped in using other namespaces to allow extensions for
particular products. DatabaseInfo is good, determining what can be
scanned and searched on is good. Element set names is good.

I would like to see a GRS-1 like record structure as the only record
structure. XML as a record syntax is not satisfactory to me. I want
to ship GIF, etc binary data. I don't want to have to munge it into
XML first. I don't want multiple record syntaxes. (Our Z39.50 client
API munges all record syntaxes into GRS-1 to give programmers a single
world view).

Creating result sets, deleting result sets: all good stuff.

Sorting, ranking: useful, but might be too much to bite off initially.

Conclusions
-----------
The above may not be the goal of ZNG. I am not trying to hijack ZNG.
But I hope it gives some idea of goals that I am interested in: keeping
the good abstraction concepts of Z39.50, but making it feel more like
SQL (that is text query language rather than binary tree, human
readable named columns rather than numbers for everything, etc - I am
certainly not proposing support for joins or the SELECT line etc).
Trying to make new people interested in numbers to identify things
is a hard sell.

Alan

Received on Wednesday, 26 September 2001 04:53:41 UTC