There is always work to do. This is true for every project. It is even more true for open-source projects. It is the truth in itself when it comes to the semantic desktop and Nepomuk. Getting people to help was never a strong point of mine. I think that is partly due to the fuzzy task descriptions. Well, today I try once again but with a slightly different scope. It is not about KDE or Nepomuk coding, this is about the work that needs to be done for the maintenance of the Nepomuk ontologies.
The ontologies have a moved history. They started out as part of the Nepomuk research project. When that was over they lived on in the kdebase package. Then the OSCAF foundation was created with the goal to maintain the ontologies. That did not really work out. Thus, we created the oscaf project on Sourceforge trying to do ontology development the open-source way. This sort of worked but communication with other projects was troublesome (The Tracker project still maintains their own fork of the ontologies). With the oscaf project the shared-desktop-ontologies project was born. Thus, we had a package named shared-desktop-ontologies in the oscaf project. Then we created the shared-desktop-ontologies project on freedesktop.org hoping that this in combination with a move to git would bring the Tracker guys back to the main development – at least in the same repository. Of course that did not happen either. So now we have the oscaf project on sourceforce, the shared-desktop-ontologies project on freedesktop.org and to top it all off we have semanticdesktop.org/ontologies which is used to host the ontologies semantic-web-style.
So much for the mess. If you are still reading that means that I did not scare you away and you might be a candidate to help us out of that mess.
This is what needs to be done – at least that is my current idea, if you bring better ideas – great:
- Create a simple website for the shared-desktop-ontologies project on freedesktop.org including links to semanticdesktop.org and the sdo package releases.
- Migrate the package releases of sdo from SourceForge to freedesktop.org. I suppose they can be put in some ftp folder and be linked in some download section on the new website.
- Set in place scripts that automatically update the ontology pages on semanticdesktop.org like the NIE page. This involves:
- Convert the existing HTML headers that we have for ontologies like NAO or NIE into docbook (html2docbook might help with the first conversion step)
- Write a script that parses the ontologies and creates docbook code with links to super and sub-properties/classes including links between the ontologies. The result should be something like the existing (but outdated) HTML pages.
- Write a script that converts the docbook to HTML and puts it onto semanticdesktop.org.
- If possible somehow integrate the l10n script that Sebastien Renard wrote to allow translation of labels and comments (Sebastien or me can provide the script).
There you have it. Not a single line of C++ required and not really any ontology or RDF knowledge necessary. It would be grand to find someone willing to invest some time and effort into this allowing us to finally have up-to-date ontologies on semanticdesktop.org and a clean shared-desktop-ontologies portal.
Thanks for reading.
Trueg's Blog 
1. Create a simple website for the shared-desktop-ontologies project on freedesktop.org including links to semanticdesktop.org and the sdo package releases.
With that you mean “create a project wiki page(s) on freedesktop org”? Like this: http://www.freedesktop.org/wiki/Software/LibreOffice ?
Convert the existing HTML headers that we have for ontologies like NAO or NIE into docbook (html2docbook might help with the first conversion step)
By “existing HTML headers” you mean all the explanatory data before “Ontology Classes Description”(which should be autogenerated). If you mean all that stuff with onologies overview, basic usage, example, and so on – i really suggest to use wiki for such documentation. Freedesktop wiki might be a good candidate for that. Wiki will help to keep all that data up-to date without much hassle. I think there is a way to publish all the autogenerated stuff on wiki too.
Docbook is way more expressive and allows conversion in all sorts of formats. What I want is something like an API documentation for the ontologies – IMHO docbook fills the hole that doxygen does for code here.
Docbook is really complicated beast. What features exactly you see in maintaining Docbook documentation, that aren’t achievable with just having wiki for docs? Wiki on its own will lower the contribution bar for documentation, and hopefully more people will contribute to it.
I see this as two different things:
1. The “API” which is the ontology documentation. You don’t want anyone contributing to your API documentation. This should be a process that is as controlled as the ontology development itself.
2. Additional documentation like howtos, examples, faqs, and so on. This can perfectly be done in a wiki.
This is the way we do it in KDE and I suppose it is the way most projects do it.
1. The “API” which is the ontology documentation. You don’t want anyone contributing to your API documentation.
If we try to make parallel with api.kde.org – the latter is completely autogenerated, and quite terse. If someone wants to change it – he should edit docstrings in source files. This is not very
convenient way to deal with large, paragraphed documentation (that’s one of the reason why it is terse). Handling complete docs is what techbase.kde.org is for (ideally).
Back to our case – i think wiki is good way to handle everything, that cannot be autogenerated. Using docbook will result in leaving only few people, who will be able to change documentation. Spreading some docs between wiki and other sources is not a good idea either.
On “conversion in all sorts of formats.” – this is nice thing to have, if there is a need to deliver documentation as some offline/downloadable and viewable content (smh. like documentation distribution). But is there really such need?
Docbook is really complicated beast.
docbook is far from complicated. It might be complex, not not complicated.
So what happened with OSCAF?
Docbook isn’t a complicated beast at all, it is really just that easy. For more than 10 years in dealing with KDE, Debian, and now the Ubuntu/Kubuntu communities, we had people without any xml experience jump right in and figure it out. No matter their background it was easy to do. Seb, I would be interested in helping out. You can hit me up on IRC or fire me an email ‘rjohnson AT kde DOT org’.
Sorry to say, but for me nepomuk ist complete pointless. I’ve killed it 2h ago and
well, my computer runs fine. Is there a way to get rid of nepomuk (KDE 4.5, archlinux)?
Daemons, that are also running and wasting cpu:
– Akonadi
– ConsoleKit
– PolicyKit
Killed all of them, now i only have about 120 tasks running (before >300!).
Pingback: Randa and Ontologies and whatnot… « Trueg's Blog