[ZOOM] hello and first impressions of the C++ bindings

Sebastian Hammer quinn at indexdata.dk
Mon Nov 5 14:20:19 CET 2001

At 12:59 PM 11/5/2001 +0000, Robert Sanderson wrote:

>Error handling will become much messier as, say, my EAD database refuses
>to return MARC but scifi returns it fine.
>I've not looked at the spec for this (never needed to) but I assume that
>only one resultset is created for the combined search? Or does it create
>one resultset for each database? There seems to be nasty issues with both
>ways.  (eg distinguishing origin of records, vs somehow returning multiple
>result sets)

Yes, only a single result set is created.

>* mailarchive  (simple XML rendition of an email list archive)
>* LCSH         (the lcsh in marc authority)
>* scifi        (marc bibliographic data)
>* eadhub       (EAD XML)
>* unesco       (Unesco thesaurus in proprietary xml)
>* transcript   (TEI transcription in middle french (my PhD))
>* IR-Explain-1

This is wrong. From the *point*of*view* of Z39.50, each of your databases 
contain a collection of abstract records. They have no specific record 
structure (or even a schema) associated with them. When the client asks for 
the retrieval of records, it asks the server to apply a certain schema, and 
a certain transfer syntax. Now, the server can either meet that request for 
a given database, or it can't (in which case it generally returns a 
diagnostic, or improvises).

So... it's not really relevant what documents you store in your physical 
server. If it's clever enough it'll be able to return ANY of the record 
types you mention as USMARC, or DC-XML, or whatever the client asks for. 
Our own server will attempt to do simple schema mappings if it has tables 
for it... doubtless, some people have gone to even greater extremes to do 
schema/syntax mappings on demand.

It *can* be a can of worms, depending on the makeup of the databases, but 
that's not our problem. We don't apply the possibilitty in a general sense 
-- we just allow those applications that need it, to deal with it. The 
issues are already (supposedly) addressed by the current diagnostics 
mechanism what we're just passing through anyway.

Fact of the matter is, the database field in the searchrequest is a list, 
and there is a spot in the record structure to identify what database a 
record comes from. It would be very weird for us to exclude this from ZOOM.

Oh... and as for multiple *targets* my impression is that this is supposed 
to be part of ZOOM -- it just hasn't been defined yet. Right Mike?


More information about the ZOOM mailing list