- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Wed, 26 Sep 2001 18:53:07 +1000
- To: Pieter Van Lierop <pvanlierop@geac.fr>
- Cc: "'www-zig@w3.org'" <www-zig@w3.org>
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