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:]
>>Verzonden: donderdag 21 oktober 2010 14:43
>>Aan: Edo Plantinga; LeVan,Ralph
>>CC: Ray Denenberg, Library of Congress;
>>
>>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
>>
>>
