Re: Positioning Z39.50

> Dumb question time
>
> Is there anywhere we can get to descriptions of what people are
> actually using explain for currently and what the proposed
> usage would be.

I actually think this is one of the more intelligent questions to ask.
We use explain to allow our clients to dynamically discover the structure
of a database. We do not normally use Z39.50 for bibliographic information.
We mainly do XML/SGML document databases. We use Z39.50 because it gives
good separation of the physical data representation (XML/SGML/whatever)
from the logical query view (attribute lists etc). I think this is a
BIG BIG BIG selling point for Z39.50 over other standard search
approaches. SQL for example ties the data representation and query
language very closely together. This is bad for document databases
where people want to search on things like "TITLE" and "AUTHOR"
(ie simple fields) but want the data structure to represent the
rich structure of a document.  Most of our client applications want
a very simple view of the world: fields to search, fields to scan,
function modifiers for fields in searches, element sets to request,
descriptions of available databases. (We use a little more, but this
is the main information).

(1) For fields to search the clients want a field name and a description.
    (We use our CCLInfo structure to map this on to an attribute list.)

(2) For fields to scan the clients want a field name and a description.
    (Again we use our CCLInfo structure to map this on to an attribute list.)
    Normally the search and scan field names are the same, but one may be
    a subset of the other.

(3) For function modifiers (eg: stem, fuzzy match) we have a function name,
    description, and attribute list to merge with the field attribute list.

(4) For element sets we want a set name and a description. (Mind you,
    90% of clients just use F and B).

(5) For database information we want a database name, description, and
    the number of records in it.

Note that from the above you can develop quite a sophisticated web
based interface. To choose database(s) to search you provide a pick
list with db name and number of records (with a 'info' button for
a longer description). To build a search you can have a drop down list
of field names, a drop down list of modifiers to apply, and a text area
for terms. To scan, again a drop down list of field names (but no
modifiers). Summary lists can use "B" and full record views can use "F"
(available element sets could be chosen from using a drop down list).
This is quite a useful and functional client which is easy for people
to understand.

Note: We also support more advanced applications that use a much larger
subset of Explain, but the above is enough for 95% of our client
applications. Database information and element sets are available
fairly easily via explain at the moment. The search and scan field
names (which bind to various combinations of attribute lists) are not
possible using the current Explain (hence we invented our own CCLInfo
category).

Alan

[Complex side note on Explain:
We do also support record syntaxes etc. One inconvenient thing about
Explain at the moment is that different record syntaxes can support
different element set names. This sort of makes sense as additional
element sets may be defined for particular record syntaxes. However,
since the server does not have to return the record syntax you request
(or if you use the server default the server can return anything),
then the element set may not work as you expect. This is not trivial
to fix as we can return records with different record syntaxes in
the one database (and so in the one present request). Mandating that
all record syntaxes must support the same list of element set names
would simplify this, but might be too restrictive for people to accept.]

Received on Tuesday, 21 November 2000 18:15:33 UTC