Egon Willighagen

In reply to interesting comments to [my previous
blog](http://chem-bla-ics.blogspot.com/2006/06/strigi-gets-kfile-plugin-support.html)
on [Strigi](http://www.vandenoever.info/software/strigi/) and xAttr
support in [KDE](http://www.kde.org/)4, I would like to suggest the
following mockups, which I would find very useful. The deal with the
ability to store keywords, for example, not but necessarily using xAttr.
I have no idea on how to implement these mockups, so any help or
pointers are appreciated.

The first plot is an example of how these keyword markup could be used
in KDE, other than searching itself. When showing the properties of a
directory in KDE, it would show an overview of hottest keywords for that
directory, such as used on social bookmark website like
[Technorati](http://technorati.com/) too:

![](/assets/images/kfileXAttrSupport.png)

This example shows that the keyword 'Strigi' was used much inside the
index_files directory (they are not just the keywords given for that
directory, but a summary of the directory content!). Now, these keywords
could be stored as xAttr, but in a database too. The first requires a
filesystem that supports xAttr, while the second requires a database
daemon to be running. However, for speed performance reasons this would
be required anyway. Strigi indexes xAttr now (post 0.3.0 release), and
basically allows both.

Independent of the chosen/prefered way to store keywords, these keywords
can be edited from the Properties dialog:

![](/assets/images/kfileXAttrSupport2.png)

Now comes the tricky part: though I would like to add this to KDE, I do
not have the C++/KDE experience to actually do this. I'm already happy
that I was able to extend the Strigi with support for KDE's kfile
architecture. Yes, the Strigi version in SVN will index all metadata
extractable with kfile plugins installed on the KDE installation.

#### References


In reply to interesting comments to my previous blog on Strigi and xAttr support in KDE4, I would like to suggest the following mockups, which I would find very useful. The deal with the ability to store keywords, for example, not but necessarily using xAttr. I have no idea on how to implement these mockups, so any help or pointers are appreciated.

KDE4 keyword support mockups

With some help, I got the
[kfile](http://developer.kde.org/documentation/tutorials/kfile-plugin/t1.html)
stream analyzer for
[Strigi](http://www.vandenoever.info/software/strigi/) working. This
means that Strigi will now index the meta data fields defined by the
[kfile-chemical](http://www.kde-apps.org/content/show.php?content=28995)
plugins.

The problem why it was not working earlier, was that it segfaulted on
every creation of KDE classes. That's something I really hate about
C/C++: the lack of stack traces, though [valgrind](http://valgrind.org/)
was helpful. It turned out that adding the below line fixed all. A
[KInstance](http://developer.kde.org/documentation/library/3.0-api/classref/kdecore/KInstance.html)
is needed when using KDE technology outside a KDE program:

:::: {.language-plaintext .highlighter-rouge}
::: {.highlight}
``` highlight
KInstance instance( "strigita_kfile" );
```
:::
::::

Combine this with the
[xattr](http://wiki.linuxquestions.org/wiki/Extended_attributes) support
added by Jos earlier today, I hope to see an interesting new Strigi
release soon! Now we only need to get [editing of
keywords](http://chem-bla-ics.blogspot.com/2006/06/kde-desktop-search-kat-strigi-and.html)
into KDE4.

#### References


With some help, I got the kfile stream analyzer for Strigi working. This means that Strigi will now index the meta data fields defined by the kfile-chemical plugins. The problem why it was not working earlier, was that it segfaulted on every creation of KDE classes. That’s something I really hate about C/C++: the lack of stack traces, though valgrind was helpful. It turned out that adding the below line fixed all.

Strigi gets kfile plugin support

Desktop searching has become a hot topic (some [earlier
](https://chem-bla-ics.linkedchemistry.info/2006/05/26/molecular-indexing-on-kde-and-osx.html)
[blogs
](https://chem-bla-ics.linkedchemistry.info/2005/11/07/ubuntu-dapper-will-include-chemistry.html)),
now that years of data accumulated on ones hard disk: PDFs,
OpenOffice.org documents, Latex manuscripts, old Java source code,
digitized music, and a lot of chemical files. Well, on my hard disk that
is. Unlike piles of paper, a computer could search this data, but due to
the size an index is required. What's KDE4 going to offer?

For the [KDE](http://www.kde.org/) desktop
[Kat](http://kat.mandriva.com/) has for more than a year offered this,
and latter
[Kerry](http://www.kde-apps.org/content/show.php?content=36832) came
along as frontend to \[Beagle(http://beaglewiki.org/Main_Page)\], though
this does not have the nice integration with KDE [kfile
plugins](http://developer.kde.org/documentation/tutorials/kfile-plugin/t1.html).
Since then, Kat developed has come to a stop (unfortunately), and
attempts to reach the main author
([Roberto](mailto:roberto.cappuccio@gmail.com)) have been unsuccesfull.
Last thing happening was a rewrite of the database backend.

Additionally, [Scott Wheeler proposed
Tenor](http://dot.kde.org/1109163846/) on
[FOSDEM](http://www.fosdem.org/) 2005: *"KDE 4: Beyond Hierarchical
Data, The Desktop as a Searchable Web of Context"*. A semantic desktop;
potentially cool, but I have heard [little from it
lately](http://www.kdedevelopers.org/blog/72?from=10), except for some
rumours that [Scott has some actual code at
home](http://mail.kde.org/pipermail/klink/2006-April/000133.html).

Now, [Strigi](http://www.vandenoever.info/software/strigi/)
([download](http://www.kde-look.org/content/show.php?content=40889)) has
come along, with a fast indexing engine, just the thing where the Kat
developed seemed to have stopped. The design is different from that of
Kat, but it does not seem unlikely that Kat code can be ported. No
support for PDF or OpenOffice.org documents yet, but that's really the
easy part, and kfile is on its way.

Getting back to Tenor, one might wonder how Strigi could implement Tenor
concepts. A simple approach is at least to allow users to tag files,
just like we have become used to with blogs (e.g.
[Technorati.com](http://www.technorati.com/)) and websites (e.g.
[Connotea](http://www.connotea.org/)). This could be easily implemented
using [extended
attributes](http://wiki.linuxquestions.org/wiki/Extended_attributes)
(xattr), [already used by
Beagle](http://chem-bla-ics.blogspot.com/2006/05/molecular-indexing-on-kde-and-osx.html):

:::: {.language-plaintext .highlighter-rouge}
::: {.highlight}
``` highlight
# file: home/egonw/1CRN.jpg
user.Tenor.Keywords="crambin"
user.Tenor.Comment="Used in my ontologies presentation."
```
:::
::::

Obviously, this example shows not just these tags, but a user comment
too. The idea, here, is that Strigi mines these attributes in addition
to the file itself, so that search on tags can be done too. BTW, my
argument to use this, instead of putting these things in the Strigi
database itself, is persistence: data and metadata are kept together.
KDE's file properties dialog would be extended with an extra tab that
allows editing these fields.

Strigi itself can be embedded in KDE applications to search specific
information (e.g. search molecular data within
[Kalzium](http://cniehaus.livejournal.com/23010.html) using the
[InChI](http://www.iupac.org/inchi/)), and even in the FileOpen dialog.
We need patches for KDE4 that allows this, soon.

#### References


Desktop searching has become a hot topic (some earlier
<i>
</i>
blogs
<i>
</i>
), now that years of data accumulated on ones hard disk: PDFs, OpenOffice.org documents, Latex manuscripts, old Java source code, digitized music, and a lot of chemical files. Well, on my hard disk that is. Unlike piles of paper, a computer could search this data, but due to the size an index is required. What’s KDE4 going to offer?

Rogue Scholar Beiträge

KDE4 keyword support mockups

Strigi gets kfile plugin support

KDE desktop search: Kat, Strigi and Tenor