[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws-comment]DisplayTerm // Forms versus Scan and Facet // was: ....
In Ralph's example: On Wed, 20 Oct 2010 11:54:44 -0400, LeVan,Ralph wrote > <terms> > <term> > <actualTerm>n201012345</actualTerm> > <displayTerm>Ralph LeVan</actualTerm> > </terms> > </facet> > > In this example, there is no index that supports looking up names. > There is only an LCCN index. LCCN is worthless for display to the user. > > Ralph > I agree that the cryptic n201012345 is "worthless" for anyone not intentionally searching a LCCN index (knowing the numbers) but might also suggest that a display of "Ralph LeVan" OK.. Pretend that there are more than one "Ralph LeVan" then a search won't return just the LCCN = n201012345 Ralph but the others.. On the other hand a scan would also return a collection of what on the display level is a list of multiple "Ralph LeVan"s but with different LCCNs. Pretend that our target has ONLY a single index: an LCCN index. Somehow we are associating Ralph LeVan with n201012345 and thus it does not matter if there is some table/relation/index in the system that associates n201012345 with Ralph LeVan or there would not have been the possibility to return Ralph LeVan in the <DisplayTerm> associated with the value n201012345 as its stored in the index. For the implementor in this case its pretty easy: If the term does not meet the syntax of an LCCN then its a name. The scan of the index as names would produce a list of names.. as LCCNs its a list of ... LCCNs.. Again.. anything goes.. And if having a list of user names is not what the server wants to deliver (or accept) then it does not need to supply them or handle them.. Some my say: "Performance".. Its faster to search for "n201012345" in my LCCN index than to find "Ralph Levan". Maybe.. but surely the resources demanded--- CPU, I/O, bandwidth etc.--- I would suggest are higher in the DisplayTerm model than in what I've proposed, Throw in the architecture of our computers which tend to have for our application I/O bottlenecks and the DisplayTerm looks even more costly... -- Edward C. Zimmermann, NONMONOTONIC LAB Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts Office Leo (R&D): Leopoldstrasse 53-55, D-80802 Munich, Federal Republic of Germany Telephone: Voice:= +49 (89) 385-47074 Corp.Fax:= +49 (89) 692-8150 Umsatz-St-ID: DE130492967
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]