> related to. For example: the client doesn't have to know that there is a
> separate authority database and bibliographic database but the server

I disagree with this premise, upon which most of the discussion (by Joe,
Jannifer and Theo) is based.

We have the tools for doing searches. We have the tools for creating
browse lists from indexes. Much like Explain Classic wasn't implemented
because it was overly complex and didn't do anything that searching a
normal database couldn't, I fear that the thesaurus based Scan++ wouldn't
be implemented. And even if it is implemented at the server, then clients
would ignore the additional information, just wasting large amounts of
bandwidth as XML encoded PDUs aren't small.

All we need to do is tell the client that the term is part of a thesaurus,
which thesaurus, and a link to that thesaurus (be it an index in the same
database, or a separate database). Then we have Mike's ZThes in both
Z39.50 and SRW to enable all of the additional features being proposed.
Let the client do what it wants, rather than assuming that it wants all
the information available about it, but give it the information necessary
to enable it to find that information.

Otherwise, for name authority files, should we return entire EAC
instances? Entire marc authority records? Who draws the line at what is
useful to a client? How do you specify which Schema you want the record
returned in? How do you know which schemas are available? These are all
things solved already by the protocol that we would need to
needlessly duplicate for Scan++.

Rob

--
      ,'/:. Rob Sanderson ([log in to unmask])
    ,'-/::::. http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I