RE: [search-ws-comment]DisplayTerm // Forms versus Scan and Facet // was: ....

["Edo Plantinga" <Edo.Plantinga@ictu.nl>]

To quote Edward:
">>Some my say: "Performance".. Its faster to search for  
>>"n201012345" in my LCCN index than to find "Ralph Levan". "
My take on this (in addition to what Edward says):
1. Performance is not an issue here, as <query> can still include
"n201012345" if the server so chooses to handle it for performance
reasons. 
2. And on top of that: let's not require the client to solve the
server's performance problems. As an analogy: I'm sure that for my email
server it would be easier if I logged in with a number and not my email
adres, but why should I care? Somebody else's problem....

Ok, let's try to wrap this up. I believe we all had plenty of
opportunities to voice our opinions. Since Edward and me seem to agree
about this and both of us already have a working implementation, I think
a fair way to do conclude this discussion is to require Ralph to show a
pseudo code example to prove his point. Please not that I'm proposing
this with the best intentions; I feel this discussion is starting to
take too long.

Regards,

Edo

 

>>-----Oorspronkelijk bericht-----
>>Van: Edward C. Zimmermann [mailto:edz@nonmonotonic.net] 
>>Verzonden: donderdag 21 oktober 2010 14:43
>>Aan: Edo Plantinga; LeVan,Ralph
>>CC: Ray Denenberg, Library of Congress; 
>>search-ws-comment@lists.oasis-open.org
>>Onderwerp: 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
>>
>>