Some reasons for doing a scan are that you do not know exactly how to write a term, you want to pick the right term from a list of similar terms or for a specific term a list of related terms. So that may be rather different. What is "behind a term" may also differ per implementation. Therefor I want to propose to add to the list below a termId and a termType. 
"termType" should be from a fixed list (bibliographic, name authority, subject heading, see also, fuzzy match etc.). 
"termId" is internal to the server, which knows what term it is related to. For example: the client doesn't have to know that there is a separate authority database and bibliographic database but the server knows because of the termId. termId can only be used for the specific server that provided it.

So "Rob's list" becomes:

termValue
termFrequency
displayTerm
totalTerms                  
termType (default is bibliographic)
termId (when absent the termValue only indicates the existence of a term, which is usefull in itself)

Next the client should be able to use the results for further navigation, which can be:
1) do a search with "termValue"
2) give me the record with relations for further navigation (an authority record or thesaurus information etc)

Navigation on basis of termId may require an extra operation, but I would prefer, that when a termId is specified the server does not need a query.

Does this idea make any sense?

Theo



>>> [log in to unmask] 23-01-03 21:43 >>>
No, I think you need to define "alternate term" more precisely.  It is
shockingly badly specified in Z39.50, which has the following description:
"A suggested alternative term".  What the heck does that mean? To me
"alternate" and "alternative" implies it has equal weight: use either A or
B to get the same stuff.  So I can't say "You won't find anything if you
search for A, but look for B and you'll hit the motherlode".  (and no, a
silent redirect at search time is not sufficient in all cases - you want to
be able to look at the term list around the preferred term).   What is
needed is something with a bit more semantic information:  "A isn't used in
this database; B is the synonym we use" or "A will retrieve items; if you
search on B you may find related items".  What I have in mind is primarily
the distinction between the see-from reference and the see-also reference.
See-also has subcategories (narrower, broader, used synonym, etc.), but I
could live without those if I really had to.

To handle thesaural expansion I think what is primarily needed is a flag in
the term record returned by scan to indicate that the term has collapsed
children.  We would then need another service to request term expansion.
(nice mental image, all these children collapsing.  Very Victorian).

j.





                    Robert
                    Sanderson             To:     [log in to unmask] 
                    <[email protected]       cc:
                    OOL.AC.UK>            Subject:     Re: Scan
                    Sent by:
                    "Z39.50
                    Next-Generation
                    Initiative"
                    <[log in to unmask]>


                    01/23/2003
                    10:55 AM
                    Please respond
                    to "Z39.50
                    Next-Generation
                    Initiative"






> So is this "window into the dictionary of query terms" allowed to contain
> references?  If not, then it's no use to me.  That's not to imply that a
> server is REQUIRED to provide references, just that if the references are
> there, the service should enable them to be carried.

Can you explain further what you mean by 'reference'?  Do you mean
alternateTerms ?

> it needs to subsume the behaviour of scan too.  I don't see these
services
> as being as fundamentally different as Ralph seems to.

It's not that they're fundamentally different -- more that the basic scan
can be extended when the terms are from a controlled vocabulary to do
other things as well.  That the Jannfier/Joe scan is a superset of the
Rob/Ralph scan.

What I'd like to avoid is to put too much into scan that can be duplicated
with a second search or scan, if the server can tell the client about the
second location.  This could be in Explain or in the scanResponse, but I
would rather it be done manually, not automatically.

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