[Kat-development] Re: Anything about Tenor?

[Roberto Cappuccio]

Alle 18:37, martedì 9 agosto 2005, Frank Osterfeld ha scritto:
> On Tuesday 09 August 2005 01:49, Scott Wheeler wrote:
> > From what I've seen of Kat, it's more or less a traditional search tool. 
Yeah, more or less. Obviously we started from the ground.
Four months ago, KDE did not have an architecture for fulltext extraction, so 
we created it. It didn't have an interface to inotify, so we developed it.
This said, even without messing with contextual linkage, there is a lot of 
things that can be done using the actual Kat framework. 
I'm talking about computational linguistics, data mining and semantic web.
I wouldn't call that a "traditional search tool".

> > I really hope that I'll have more time to work on Tenor in the next few
> > months
We all hope so :-D

> > and if that happens there could probably be a merge where we could 
> > use some of the things that Kat is doing in terms of full text extraction
> > and Kat could be an interface for the Tenor library layer.
I was thinking, instead, to ask you to start building Tenor on top of Kat 
technology. There is no reason to reinvent the wheel. 
All in all, at the actual stage of development, Tenor is an empty box while 
Kat is almost production ready.
Kat is an architecture for desktop search, with its solid and expandable 
database layer and API. Tenor could simply add contextual linkage to Kat's 
architecture. 
Anyway contextual linkage will represent IMHO a minimal part of the whole 
architecture, maybe the most innovative and fascinating part, but still a 
minimal part.
In other words, I think that Tenor should be based on Kat and not vice-versa.

> > (That said, I don't really like the interface of Kat, but that's another 
matter.)
The actual Catalog Browser is NOT the interface of Kat. 
I know, we have not been particularly successful in explaining that to the 
users... 
Kat's interface will be integrated in Konqueror, in a way which is similar to 
the actual "Search Files" feature.
The Kat Catalog Browser will only be used for disconnected media, like CDs, 
DVDs, USB dongles and the like, where the user will have the possibility to 
browse the actual directory structure of a disk even if it is not inserted in 
the drive.
(That said, I would really like to see Tenor's interface, sooner or later, but 
that's another matter.) :-D

> Right, the current interface isn't that good, I never saw a search tool
> where the actual search functionality is so well hidden as in kat ;-)
As I said, it was not meant to be the primary search tool in Kat's 
architecture.

> But that will be improved soon, from the feature plan for 0.7.0: "Make a
> brand new simple and usable search client" (they plan integration into
> konqueror). 
Exactly.

> I think the client hasn't changed much since I tried kat the 
> first time in its early days... 
It is pretty the same since then. As I said before, it was not our main focus 
to further develop it.

> They put more effort into the backend, like 
> the fulltext extractors, language detection, the indexer, and a kded daemon
> that does the indexing in the background (monitoring changes using inotify,
> which will be part of Linux kernel 2.6.13). There is also libkat in the
> works so other apps can make use of kat.
Yes, the backend got almost all of our attention. We wanted a modular 
architecture which could be easily expanded, so we created the fulltext 
kioslave and a series of fulltext plugins. 
We are about to publish another 20 of them in the next release so that, from 
this point of view, Kat will not have to fear competition.
Using the same scientific principles that allow us to identify the language of 
a document, we want to implement a highly innovative kind of search based on 
linguistic fingerprints. 
It will allow searches like: "find a document similar to this". No matter if 
the words used in the documents differ, the linguistic fingerprint of 
document belonging to the same domain, are similar. We want to exploit this 
property of language.
I would like you to notice that this feature is missing from ALL the 
competitors.

> > With that in mind, if Kat matures a bit it may make a nice mid-term
> > solution so that we have something doing search-type stuff, but of course
> > it doesn't cover some of the more interesting ideas from Tenor like
> > contextual linkage and content management.
Yesterday we moved to KDE SVN Playground and this gave me the possibility to 
take a look to Tenor's directory.
From the empty stubs I have found therein, the things you want to develop, 
apart from contextual linkage and content management (whatever you mean with 
it) are already available in Kat.
I don't think it would be a good thing to duplicate that features in Tenor or, 
as you proposed, merge them in Tenor, since Kat is almost finished.
We would therefore welcome you if you decide to help us to further develop our 
infrastructure and then use it for building Tenor on top of it.
So, I don't consider Kat a mid-term solution, but a fully fledged search 
architecture that could be expanded and adopted by KDE as a standard.

> I wonder if the KAT API could become a generic API for (context-less)
> search.
> Tenor could then implement the API as well, allowing easy migration 
> of KAT-enabled apps to KAT/Tenor.
Implement is not the right word. Tenor, like any other application needing 
desktop search, could simply "use" the Kat API and eventually extend it with 
contextual linkage and other sophisticated search technologies.

> I really hope we can bring KAT and Tenor together and cooperate, instead of
> having two competing solutions, maximizing confusion for developers and
> users.
My proposal is clear: I invite Scott Wheeler, Aaron Seigo and every other KDE 
developer to join the Kat team and help building the Kat desktop search 
infrastructure, to adopt it as the standard search architecture for KDE and 
then to build the contextual linkage search on top of it.

> Regards,
>
> Frank

Bye

Roberto