creating a content system

[Roberto Cappuccio]

Alle 13:16, mercoledì 10 agosto 2005, Scott Wheeler ha scritto:
> On Wednesday 10 August 2005 13:03, Roberto Cappuccio wrote:
> > Alle 12:41, mercoledì 10 agosto 2005, Stanislav Karchebny ha scritto:
> > > Just a little note about "i will never use such a feature". You will
> > > not have to _use_ it, since it will be naturally integrated in the user
> > > interface. You will just feel a little bit naked after installing an
> > > ancient copy of KDE 3.4.1 and screaming "where the hell is that skype
> > > conversation related to this file in my doc/ folder, why is it not
> > > shown here in 'Whats Related' area?"....
> >
> > I think that 95% of times that relationship would be also reflected by
> > the content of the document I'm searching for.
> > But I admit, I could also being underestimating the power of contextual
> > search. Maybe using it I would appreciate it better.
>
> I think you're overestimating traditional search, actually.  :-)
Yes :-D
I think it could be "professional deformation"... Anyway I'm extremely curious 
to see Tenor at work. I would be really glad to see an effective enhancement 
in my search abilities using it.

> Take images for example -- aside from the metadata, which is almost always
> pretty useless, it's almost impossible to do interesting search on images
> without context.  That's an easy case to point to, but one that we see
> pretty easily with i.e. Google image search.
I agree completely. Without contextual information, no useful search would be 
possible on images.

> The other thing that I think you're overestimating is the reach of
> "documents".  You mentioned your mails being indexed, but that's mostly
> luck -- you happen to have them locally in a format that an indexer can
> handle, but actually if Till gets his way (most active KMail developer at
> the moment) mail will be stored in a very different way in KDE 4.  i.e.
> mails won't be files anymore.
Ok, but in this case we will have a mail plugin which will extract the mails 
from whatever storage media.
There is also a lot of other cases in which the "document" may not reside on a 
filesystem. I'm thinking of AmaroK playlists and the like, residing in a 
database. We could provide plugins also for this kind of "document".

> I could go through other examples, but those are two of the easier ones --
> that's what got me to the point of thinking that file indexing is just the
> start, but that effective desktop search needs to account for context and
> more generalized resources than files.
Agreed.

> (But again, that seems to be mostly beyond the scope of Kat and I don't
> think there's a huge overlap there.)
Yes, Kat and Tenor get different information about the same objects. They also 
handle that information differently. They could, and IMHO actually should, 
save that information in the same repository so that the complete information 
about each of the objects can be retrieved from the same source and 
eventually be built aggregating different kinds of information.

>
> -Scott

I'm preparing a schema of the actual architecture of Kat. I'll put it in the 
WIKI as soon as I finish it.

Roberto