Trueg is the KDE-Nepomuk dude, and has been running a few cool blogs, for example about Nepomuk Virtual Folders - The Next Level, We Don't Search... and Fetch, Nepomuk, fetch!
Tagging is the future. Overcoming typos in tags, synonyms is a conflicting feature, but does not limit the wide applicability of being able to tie information together. Now, Nepomuk is a bit strict on the type of metadata allowed, which is why Strigi has a super ontology (as in super set), to which we can add chemistry bits.
I have yet to install KDE 4.1, assuming that a good deal of truegs work found its way into that. At least, the virtual folders bit, I hope. But just imagine tying together PDFs, PDB entries, etc, I have on my desktop, all belonging to a diabetes, by just typing this URL: nepomuksearch:/diabetes.
On a different note, this tagging if available in Kmail would provide a powerful approach to organize the processing of my inbox; I can tag emails with todo, toreply, toread, toarchive, ...
Oh, and let me squeeze in this statement too (sorry, jriddel) : Kubuntu 8.04 has required me to tweak to work around bugs than any other previous Kubuntu release. Things tend to be encountered by others earlier, so that Googling generally helps sufficiently. But missing dependencies is a bit ugly (sorry, forgot which program it was, so can't link to the bug report). And, still am a happy Kubuntu user!
Showing posts with label nepomuk. Show all posts
Showing posts with label nepomuk. Show all posts
Monday, May 12, 2008
Saturday, January 19, 2008
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:
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:
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.
- 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++)
- 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
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 /tmpAfter which I am stuck with this error message, I have no idea of how to solve in gutsy:
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 ..
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.
Saturday, April 14, 2007
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.
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.
Subscribe to:
Posts (Atom)