I haven’t actually gotten around to fiddling with Java, but ran Strigi against it to extract RDF, while having the Strigi-Chemistry plugins installed. This is part of the RDF that came out:

<example-doc.docx>
  <http://freedesktop.org/standards/xesam/1.0/core#title>
    "acetic acid",
    "(8R,9S,10R,13S,14S,17S)- 17-hydroxy-10,13-dimethyl- 1,2,6,7,8,9,11,12,14,15,16,17-dodecahydrocyclopenta[a] phenanthren-3-one",
    "testosterone";
  <http://freedesktop.org/standards/xesam/1.0/core#version>
    "2",
    "2";
  <http://rdf.openmolecules.net/0.9#atomCount>
    "8",
    "49";
  <http://rdf.openmolecules.net/0.9#bondCount>
    "7",
    "52";
  <http://rdf.openmolecules.net/0.9#molecularFormula>
    "C2H4O2",
    "C19H28O2";

I believe there is quite some room for improvement, but it’s a start :) Thanx to Joe for posting the public domain test file, so that other projects can start play with the exiting new technology. I should note, however, that I am not running a Microsoft OS nor MS-Word, and the saved documents source are the only way I have access to the CML right now.

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 too:

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:

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.

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. A KInstance is needed when using KDE technology outside a KDE program:

KInstance instance( "strigita_kfile" );

Combine this with the xattr 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 into KDE4.

For the KDE desktop Kat has for more than a year offered this, and latter Kerry came along as frontend to [Beagle(http://beaglewiki.org/Main_Page)], though this does not have the nice integration with KDE kfile plugins. Since then, Kat developed has come to a stop (unfortunately), and attempts to reach the main author (Roberto) have been unsuccesfull. Last thing happening was a rewrite of the database backend.

Additionally, Scott Wheeler proposed Tenor on FOSDEM 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, except for some rumours that Scott has some actual code at home.

Now, Strigi (download) 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) and websites (e.g. Connotea). This could be easily implemented using extended attributes (xattr), already used by Beagle :

# 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 using the InChI), and even in the FileOpen dialog. We need patches for KDE4 that allows this, soon.