Re: DASL / GILS alignment

For me, there is also another perspective to Z39.50 that seems to have gone
unchecked in the discussion so far. The messages to date seem to have talked
around the "origin" (client) aspects of a z39.50 query, rather than the
"target" (server). When I think of Z3950, I think of an interface that allows
me to expose the contents of a database, without the need for searchers to
understand the semantics (Is that idiosyncrasies ?) of my local repository.
Why is this important? The application domain of Z3950 was traditionally
library automation and what we have here is many vendors who all store data
about books & other mixed resources, but the many database schemes contain
attributes like book-title, title, catalogue-item-description, titre. All of
which are used to represent the core concept "title". The "problem" has
nothing to do with the library domain.

Now... Sure, z39.50 has a mechanism where by one can "Discover" these
attributes. However, one of the the most important concepts in z39.50 is that
everyone who has implemented the protocol has made a huge effort to map their
internal schemas onto a commonly accepted set of access points, on a per
domain basis. In fact, I might even go so far as to say that deciding on, and
getting right, this mapping is far more complex than implementing the
protocol. I am a HUGE proponent of NLP and AI in query processing, and I
really think the z39.50 community needs a bit of a rocket in this area. All
the vendors have such complete IR systems that most have no idea about the
current state of play WRT such technologies. The truth is, however, until we
have a module that can take a phrase like "Find the locations of good thai
restaurants in Los Angeles" and actually convert this into (for example)
schema specific SQL, we need this explicit level of abstraction between
searcher and resource.

Here at Fretwell-Downing we have some "concurrent" z39.50 search tools whereby
a user can throw a query at several targets and see which respond, I guess
like visiting n repositories and saying do you have the report with id 663454.
The great thing about z39.50 is I can say "Do you support Report-Number as an
attribute" and only send the query to those targets, which will then interpret
the request on to local attributes like repno, reportid, report-number, etc.
My (limited) understanding is that under DSAL you would have to re-formulate
the query for each repository you wish to search, taking the attribute which
represents the concept "report-number" from the DISCOVERY service. How one
then makes the connection between this concept and the text string that the
DISCOVERY service reports as attribute "RepNo" is (to me) unknown (OK,  I will
read the doc again :-)).

All that said, when I first got hold of  the DASL specification my first
thought was great... We can gateway DASL onto our z39.50 search service and
provide an easy to use service. Everything considered, this reminds me of the
ZORBA debate, maybe also the whois++ debate... At the end of the day z39.50 is
about information retrieval. It matters not a jot if it's BER encoded ASN,
CORBA IDL, or maybe even XML encoded ASN, what the "protocol" represents the
current-best-practice in distributed information retrieval. We will always be
up against it when trying to trade-off "Simple" UI's against complex
requirements. For me, the solution to this problem lies with AI & NLP, but
until that technology is polished it's a dangerous step to discard z39.50 all
together. It's ability to absorb a wide variety of IR problems makes it
invaluable as a tool for exposing a resource. By all means lets use DASL to
access a z39.50 service, but to cut it out altogether? After all, you can
always "hide" the features of a complex protocol, but when you need a richer
feature set, you can't use a facility if it is not present in a "simple"
protocol.

WRT the "Experiment", I think fretwell-Downing would be very interested in
being involved with any DASL/Z39.50 work. I feel sure we would be happy to be
involved in any way possible.

Don't think I am saying anything controversial here, Just wanted to add
another voice to the Z39.50 supporters camp.

Ian.