I disagree.

The purpose of Scan is to provide a window into the dictionary of query
terms for a database.  It was NEVER intended to be used for thesaurus work,
though I admit that some tried to use it for such.

I think that you (Janifer) should have a separate authority database that
you can use to find terms to search in you bib database.  (So, I agree with
Joe about not having more bogus indexes. :-)

Ralph

> -----Original Message-----
> From: Joe Zeeman [mailto:[log in to unmask]]
> Sent: Wednesday, January 22, 2003 12:33 PM
> To: [log in to unmask]
> Subject: Re: Scan
>
>
> {deactivating cloaking device}
>
> I actually think that the distinction catalogers make between a
> bibliographic database and an authority database is spurious.
>  Authority
> information exists to validate the forms of name used in a
> catalog and to
> provide a reference structure.  Only a cataloger will have
> any interest in
> seeing authority "records" per se  and I'm not convinced we should be
> building artificial distinctions into the underlying data
> model to keep
> catalogers happy.  So I don't think we should be defining
> "*-authority" and
> "*-catalog" indexes.  Next thing you know we'll be defining
> "*-holdings"
> indexes too.  Neither should be be defining "*-authority" databases.
>
> I actually think that what gets returned by a scan should be
> something with
> a close family resemblance to an authority record.  If the term is an
> unused form, it should contain information that allows
> navigation to or
> direct searching of the used form; if there are related
> terms, these should
> be available; if term is a node in a hierarchical structure,
> it should be
> possible to navigate that structure.  AND it should provide
> an indication
> of how many documents (or, preferably works) a search on the
> term is likely
> to retrieve.
>
> j.
> RLG
>
> {reactivating cloaking device}
>
>
>
>
>
>                     Janifer Gatenby
>                     <[email protected]       To:     [log in to unmask]
>                     LCPICA.NL>                cc:
>                     Sent by: "Z39.50          Subject:     Re: Scan
>                     Next-Generation
>                     Initiative"
>                     <[log in to unmask]>
>
>
>                     01/22/2003 12:37 AM
>                     Please respond to
>                     "Z39.50
>                     Next-Generation
>                     Initiative"
>
>
>
>
>
>
> On second thoughts, I think it's better to use the index name to
> incorporate
> the target database.  So if you ask for index "author
> authority" it scans
> that index, the occurrence count means the number of
> authority occurrences
> and it leads to authority records.  "Author catalogue" scans give the
> bibliographic occurrence count and leads to bibliographic records.  By
> 'loading' the index name it actually removes the ambiguity from the
> occurrence count element.
>
> On step size, I've never used it but I think it is designed
> primarily for
> subject browse.  There are better ways to do an expanded and collapsed
> scan,
> e.g. by browsing headings that have no subdivisions then
> allowing them to
> be
> "opened" (Windows explorer metaphor).  Step size is a rather
> crude way to
> do
> a "quick flip".  If servers were to support some kind of expansion and
> collapse, I'm not certain that many would support any step
> size proposed by
> a client.  If we were to contemplate something equivalent to
> step size, I
> would propose a collapsed element and leave the server to
> interpret its
> meaning.
>
>
> Janifer
>
> -----Original Message-----
> From: Robert Sanderson [mailto:[log in to unmask]]
> Sent: Tuesday, 21 January 2003 20:07
> To: [log in to unmask]
> Subject: Re: Scan
>
>
> > I'm happy with these suggestions.  I'd like to dump stepSize and
> > targetDatabase.
>
> Jannifer wanted targetDatabase. No one wants stepSize, as far as I can
> tell.
>
> Following on from my 'discovery' that index/term needs to be a
> searchClause, everything fell to pieces fairly neatly:
>   http://srw.o-r-g.org:8080/l5r/?operation=scan&clause=ninja
>
> Accepts clause, numberOfEntries and responsePosition for SRU, and also
> xClause for SRW. Adds in echoedRequest ala
> searchRetrieveResponse for SRU.
> Also has a diagnostics list, but everything is Diagnostic 2 for the
> moment. [Temporary error :)]
>
> Why 'numberOfEntries' and 'responsePosition'?  These are the
> terms used in
> ZOOM's scan, so I just copy them from the request onto the
> ZOOM object.
> Also means for less confusion in having to do translations from one
> object's attribute name to another.
>
> Still working on the XSL for the display, but it does a simple linked
> table so far which is enough to demonstrate that it works.
> (Notably it doesn't use echoedRequest to generate the links, so the
> searches are always against the default index and it doesn't generate
> next/previous listing links)
>
> Things which would be useful which Theo (IIRC) brought up:
> Some sort of
> marker for where the term would be if it's not present, or
> that the term
> is the one used from the request.  Probably another field in <term> ?
>
> 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
>