KDE 4.0.0: no Yukuake for Kubuntu?

Last week I installed the Kubuntu gutsy packages for KDE 4.0.0, and was delighted about the result (see the visual guide). Surely, I have some things I got so much used too, which do not seem 4.0.0 material:

• taskbar at the top of the desktop
• option to resize the taskbar
• searching files with I tagged/rated with Dolphin/Nepomuk
• Strigi still does not have PDF support (and I'm not that fluent in C++)

And, there are many things which showed up in blogs over the past year, which do not have made it into 4.0.0:

• strigi search in Alt-F2 or in the KDE menu (mentioned here)
• cool plasma widgets (e.g. this calendar, or the RSS feed widget in one of the screenshots here); the set in the Kubuntu debs seems limited

On the other hand, maybe I just forgot to install some packages, though I installed the extragear-plasma.

Yakuake
Though I very much like the new Konsole, I got so used to Yakuake, this will keep me running a KDE3 for just now. KDE4 capable packages are reported (version 2.9b1) but I failed to compiled these on Kubuntu Gutsy:

cd /tmp
cp ~/Desktop/yakuake-2.9-beta1.tar.bz2 .
tar xvjf yakuake-2.9-beta1.tar.bz2
cd yakuake-2.9-beta1/
cd build/
sudo aptitude install build-essential cmake kdebase-workspace-dev
cmake -DCMAKE_INSTALL_PREFIX=/usr/lib/kde4 ..

After which I am stuck with this error message, I have no idea of how to solve in gutsy:

CMake Error: Qt compiled without support for -fvisibility=hidden. This will break
plugins and linking of some applications. Please fix your Qt installation.
-- Configuring done

Anyway, congratulation to the KDE developers, and looking forward to the upcoming dotdot releases and KDE4.1 this summer! If not just for the planned better Strigi/Nepomuk/KDE integration.

P.S.: I just discovered the plasmoid section on kde-look.org, which I'm going to browse right now.

Friend-of-a-Friend (FOAF) support in Strigi

Last week I have been hacking on a Strigi plugin for FOAF files. Now, one will not expect FOAF files on ones desktop soon... unless, you start indexing your Konqueror history. I have not seen that feature yet, but not overly difficult to implement for a skilled Konqueror developer (just use the dbus interface for Strigi).

However, HTML files may have this line in the <head> element:

<link href='http://blueobelisk.sourceforge.net/people/egonw/foaf.xrdf'
rel='meta' title='FOAF' type='application/rdf+xml'/>

This could be the trigger for a Strigi plugin, to download this file and provide that as substream for the HTML file. I am aware for security issues at immediately pop up, but that is something we can surely deal with.

Using this approach the whole semantic desktop takes shape. Say, I am searching what I have on my desktop on some topic, then, additionally, Strigi will make me aware that I recently read the blog from someone who showed interest in that topic too. Moreover, it will even allow Strigi to tell me which projects on SourceForge are related to this topic.

Far fetched? No, it's really just around the corner. If interested, you may find the source code in KDE SVN under trunk/playground/utils/strigi-foaf. The Konqueror history hack is not implemented yet, as I need to know first what efforts are ongoing in that respect.

MDL SD files as folders: opening a single molfile

Alexandrs Google Summer of Code project is over, and he is wrapping up his code and blogging about his resource. He just blogged about one of his achieved goals: opening SD file as folders using Strigi's jstream technology. It provides tight support of chemistry on the KDE desktop: browse a SD file as a folder, open a single MDL molfile entry from the SD file with the FileOpen dialog, all in addition to finding a specific molecule by InChI in the SD file. Check the screenshots that Alexandr put online.

Strigi now understands Xesam queries

Flavio wrote about Strigi getting Xesam query support, which is cool and allows me to look up email from me to a friend using this query:

<request>
  <query>
  <and>
    <equals>
      <field name="email.to"/>
      <string>Christoph</string>
    </equals>
    <equals>
      <field name="email.from"/>
      <string>Egon</string>
    </equals>
  </and>
  </query>
</request>

So that, after having saved the above as query.xml, I can then issue a strigicmd call:

strigicmd xesamquery -t clucene -d index/ -q query.xml

Now, with proper nesting and all functional (see the full query language specification), I can do all sorts of nice queries:

<request>
  <query>
    <equals>
      <field name="xml.usesNamespace"/>
      <string caseSensitive="true">http://www.xml-cml.org/schema</string>
    </equals>
  </query>
</request>

Possibly embedded in XHTML (or vice versa):

<request>
  <query>
    <and>
      <equals>
        <field name="xml.usesNamespace"/>
        <string caseSensitive="true">http://www.xml-cml.org/schema</string>
      </equals>
      <equals>
        <field name="xml.usesNamespace"/>
        <string caseSensitive="true">http://www.w3.org/1999/xhtml</string>
      </equals>
    </and>
  </query>
</request>

And, after having installed strigi-chemical currently developed by Alexandr, the GSoC student on chemistry support for Strigi, chemical queries. For example, to get all molecules with a certain mass range, I can find all files that use a CML namespace:

<request>
  <query>
    <and>
      <greaterThan>
        <field name="chemistry.molecular_weight"/>
        <float>50</float>
      </greaterThan>
      <lessThan>
        <field name="chemistry.molecular_weight"/>
        <float>59</float>
      </lessThan>
    </and>
  </query>
</request>

Or, give me all chemical files which contains a molecule with 'butane' in the name:

<request>
  <query>
    <and>
      <contains>
        <field name="content.mime_type"/>
        <string>chemistry</string>
      </contains>
      <contains>
        <field name="chemistry.name"/>
        <string>butane</string>
      </contains>
    </and>
  </query>
</request>

GSoC Meeting with Alexandr

Yesterday I met with Alexandr to discuss things around his GSoC project, like time schedule etc. During the mentors meeting to work out the final rankings, one fellow mentor argued that this project is too specialized for KDE. We, therefore, discussed how we can maximize the effect on the rest of the KDE project, and ideas that came up include a dedicated query tool for complex data (such as chemical data). Anyway, this will be discussed in our blogs soon.



Meanwhile, I have registered to the new Planet SoC which was announced on the Summer of Code Blog.

GSoC: towards a chemical semantic desktop

Now that I am officially a Google Summer of Code mentor for KDE's participation, it was more than time to get my KDE4 install up to date. Meanwhile, Jos' Strigi toolkit is well integrated already, and Jerome has updated the chemical kfile plugins to the new Strigi based architecture.

I was talking to Phreedom on IRC about ontologies used by Strigi, and added one for chemistry. It currently has the fields chemistry.inchi, chemistry.molecular_formula, chemistry.molecular_weight, chemistry.pdbid, and chemistry.xray_resolution, but more are expected to be added. I already updated kfile_chemical to make use of these fields, and updated it for a few fields from the more generic ontologies in Strigi.

Extracted metadata
Strigi currently focusses on metadata only, as do the kfile_chemical plugins: they extract metadata from the file, and do not generally create metadata based on the file (actually, Strigi calculates sha1 hashes). These are typically fields like molecular formula, title, X-Ray resolution (in case of PDB files), identifiers (e.g. InChI, PDB id), etc. However, there can be a lot more interesting information in those files, which require some more tought. For example, PDB files cite one or more publications, which might be present at ones hard disk too. The idea is here, that Strigi actually links the PDF with the publication and the PDB file. This is where Nepomuk comes in, and where Strigi is currently disabled. Similarly, any general organic chemistry publication will mention many molecules, each of which might have other publications discussing them, or even have 3D coordinates or other properties defined.

Created metadata
Another interesting thing one can do for chemical documents, is calculate metadata: for example, calculate InChI's for mol/xyz/hin/... files, using OpenBabel. Or Rule-of-Five properties, e.g. using the CDK. This is where the GSoC project comes in which I am mentoring, and on which Alexandr (a former CUBIC student) is going to work.

Oh, and like most desktop search tools, it can simply work on your HTML cache too, so that all these cool things will work on the webpages you search too. That should trigger some more ideas :) It does for me at least.

Chemical KDE GSoC Project Ideas

Very likely KDE will participate again in the Google Summer of Code. At this moment two project ideas are written up related to chemistry:

• A 3D Molecular Editor
• Strigi: chemistry and biology support

The second is my personal favorite, and I have worked on this topic in the past myself. See also Carsten's post on this.

The only thing I really miss in the full list of ideas, is the idea of completing a Greasemonkey plugin for Konqueror. I could not mentor a project like this, and, therefore, cannot put it up on the idea list :(