RE: [Zope] ANN: ZCatalog 1.0.0 alpha
At 15:52 28/06/99 , Michel Pelletier wrote:
* Right now, search results on multiple indexes are intersected; if you have a search term on the title and the body of a news item, only objects that have hits on both indexes are shown. This makes it practically impossible to present one search field that will present the user with objects that have the search term in one of the indexes. I would like to be able to concatenate the results from different indexes. intSet supports this operation (union).
Oh man, I knew someone would open up the Query Language can of worms.
*smirk*
Yep, your right, the catalog (like ZTables) takes only the intersection of a search. Modifying the _indexedSearch() algorithm wouldn't be too hard, it's just *how* to modify it is the tricky part. The ideal solution would be to create some sort of query language that web form could dynamicly build queries to, that way, you can design your querty rather smartly. A nifty wizard could even be built to build complex web forms that you can then tweak for usability. Brainstorm on this, and let me know what you come up with.
Hmm.. many searching interfaces that let you search on multiple fields (like Eudora 4.2) give you only the option to show objects that match any or all criteria. It would certainly solve my problem if we had this choice =). Maybe ZCatalog should accept a special argument that specifies with a normal boolean search string how to join the results of the different indexes, something like: title and (summary or body) which stands for the intersection of the search results on title and the union of the search results of summary and body. The parsing logic is already there. This would allow for quite complex web interfaces, allowing for some nice datamining on ZCatalog instances. And it will allow me to do something like: <dtml-call "REQUEST.set('title', search-string)"> <dtml-call "REQUEST.set('summary', search-string)"> <dtml-call "REQUEST.set('body', search-string)"> <dtml-call "REQUEST.set('results-join', 'title or summary or body')"> <dtml-in NewsCatalog size=20 start=query_start> .. displaying results .. </dtml-in> where results-join tells Catalog to use the union of title, summary and body. Next question: The tutorial talks about ZCatalog aware objects. How can I make a ZClass ZCatalog aware? * Indexing an instance when adding is easy, as is updating the Catalog when editing but how does the deletion part work? Only when using a python base class? * Is there a standard way of selecting the Catalog instance my newly created ZClass instance will use? Or should I just use: <dtml-if "superValues('ZCatalog')"> <dtml-if "_.len(superValues('ZCatalog')) > 1"> <td><select name="catalog"> <dtml-in "superValues('ZCatalog')"> <option value=&dtml-id;><dtml-var title_and_id> </dtml-in> </select></td> <dtml-else> <dtml-in "superValues('ZCatalog')"> <td><dtml-var title_and_id> <input type=hidden name=catalog value=&dtml-id;></td> </dtml-in> </dtml-if> </dtml-if> in the addForm? -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------
Martijn Pieters wrote:
Michel Pelletier wrote:
Brainstorm on this, and let me know what you come up with.
Hmm.. many searching interfaces that let you search on multiple fields (like Eudora 4.2) give you only the option to show objects that match any or all criteria. It would certainly solve my problem if we had this choice =).
Maybe ZCatalog should accept a special argument that specifies with a normal boolean search string how to join the results of the different indexes, something like:
title and (summary or body)
1. Just to add turbulence to the brainstorm, and supposing 1.1 we invoke a "look for the technical jackpot solution" heuristic, which means, have a look at the less obvious in the hope of a magical solution. 1.2 we take "boolean search strings" as the standard solution to the problem of extending to more, your simple first proposal of an any/all choice. 2. What are the non-standard solutions, then ? Are there any ? INEQUATIONS Well, of course, boolean searches can be expanded to inequations, like the above one can be turned to : 4*title + summary + body > 5 While at first sight such a notation may seem, when compared to boolean search strings, not to bring anything in terms of useability, it is yet notable that : 1) In any case, boolean searches can be translated to them, automatically if need be. 2) When given as "4*title+summary+body", it extends the expressivity of the corresponding boolean search, since it simultanously stipulates a preference ranking on matches. 3) It is not impossible that artists of the trade (of searching databases) can show a better performance using a similar formalism rather than boolean search strings. 4) Maybe there's an interesting way to add fuzzy logic to acquisition wrappers ;-) Well... other directions ? PICTIONARY-STYLE QUERY BY QUALIFIED EXAMPLE Thinking over the matter of refining searches, one wonders if Zope's OO should not transfer to a search language providing elegant semantics to the fact of refining searches while reviewing the first (and unsatisfying) first items returned. Typically, a keyword-centered query returns too many items, and the "power" user may want to instruct the system to remove all of the members of a readily recognizable family of false matches. An interface designed to help such a move is nice... imho... and of course simple intersective search already fits that bill in some manner. But symmetrically, I guess an imprecise query should allow being augmented in extension. In other words, the general idea would be to seek an interface that turns previous searches (and top items) to objects easily clickable or nameable by the user, to combine them in further search expressions, as relative examples of what's wanted and what's not wanted, step by step, somewhat like (one of) the natural strategi(es) of the game of pictionary. DISCLAIMER The above takes as only justification, the call for a brainstorm by an aliased zopener ;-) Regards, Boris Borcic
On Mon, 28 Jun 1999, Boris Borcic wrote:
Martijn Pieters wrote:
Michel Pelletier wrote:
Brainstorm on this, and let me know what you come up with.
Hmm.. many searching interfaces that let you search on multiple fields (like Eudora 4.2) give you only the option to show objects that match any or all criteria. It would certainly solve my problem if we had this choice =).
Maybe ZCatalog should accept a special argument that specifies with a normal boolean search string how to join the results of the different indexes, something like:
title and (summary or body)
....
2. What are the non-standard solutions, then ?
How about using the LDAP qurey syntax: object_property = value object_property < value More advanced operations coule be done like (& (property = value) (other_property < value)) Chris from DC posted some LDAP specs to the list that summed up the syntax pretty well. One thing that could be done is to say that if no property name is specified then it means to search any property. --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
participants (3)
-
Boris Borcic -
Martijn Pieters -
Scott Robertson