simple search api (was Re: mimetype standardisation by testsets)
jean-francois.dockes at wanadoo.fr
Mon Nov 27 14:53:10 EET 2006
Mikkel Kamstrup Erlandsen writes:
> - About the query language, and just for the record, the syntax described
> > on WasabiDraft is more the one from Beagle than the one from Lucene
> > (which defaults to ORing, not ANDing the terms I think). This is
> > probably and appropriately more intuitive for end-users.
> Which is? AND or OR? This is kind of a religious thing I guess. At wotk we
> had a huge flame fest about this :-) We ended up ANDing... This was the
> ruling from our usability consultants, I work at a library, and the same
> usability rules might not apply to desktop search...
What I meant was that Lucene defaults to OR, Beagle to AND and that the
latter seems more intuitive to me but I don't really care either way. This
is just for clarification. There are mentions of the Wasabi language being
a Lucene subset on the draft page, this is wrong. No big deal, just to
> > [about switch requirement list]
> Yeah, I admit that the current requirements was a bit arbitrary, I just
> needed to put something there...
> The idea with author and title and such was to take dublin core into
> consideration (which should probably not be mandatory for indexers).
> The group switch is another deal. As I've pointed out before I think this is
> a really really useful switch to application developers, and as it has been
> pointed out elsewhere in this thread it is not always and easy task to group
I have no problem with the list, just with the "mandatory" mentions. I
think that a back-end engine may still be useful if it doesn't provide an
"author" field, it may have other qualities :) The "group" idea is a very
good one I think, but we can imagine a user with a preferred engine
specialized for office files, who always searches office files and couldn't
care less about "group". Should we forbid this back-end of claiming or
aiming for wasabi compatibility because it doesn't do groups ? Maybe there
should be a "recommended" mention between mandatory and optional.
> > [sample parser]
> There are several ways to do this. One idea could be to provide stand alone
> libs for QT and GObject... Ie. no "bindings" just pure implementations.
I agree. I think we should also have a toy/"throw away" implementation
quite fast, this will help with detecting problems in practice.
> > [Beagle use of xml as serialization format]
> Cool. Good that you took the time to look at this. Now we can dismiss that
> option with confidence. Thanks.
Also goes to prove that you can turn a Beagle query into XML and back if we
had a doubt :)
More information about the xdg