[Xesam] Nepomuk/Xesam future (was Re: condition of 1.0 ?)

Ivan Frade ivan.frade at gmail.com
Fri Apr 24 01:54:24 PDT 2009


Hi all,

On Thu, Apr 23, 2009 at 5:16 PM, Mikkel Kamstrup Erlandsen <
mikkel.kamstrup at gmail.com> wrote:

> 2009/4/22 Roberto Guido <bob4mail at gmail.com>:
>
> The thing that initially kept me from pushing the button was the
> unclear state of the ontology, and it seems that a lot of the
> high-profile FOSS projects are moving towards the Nepomuk ontologies.
> I still think that there are a lot of people out there using (or
> waiting for) the xesam ontologies however.
>

 Well, xesam and nepomuk has both their pros/cons, and we should decide what
to do with both projects in the future. I am working on tracker, and we are
using nepomuk. Here are my thoughts about the current situation:

* It is much easier to discuss a "stable" ontology. To start discussions
very early stops the progress.
  (In this sense nepomuk is more comfortable to use)

* The ontologies need updates. The real world is not the academic world, and
some tunings are unavoidable. The developers writing code discover the
problems and there must be an open process to discuss/improve/publish the
results (not depending on project funding or one-person free time)
  (In this sense a xesam-alike project, community driven, can work much
better than nepomuk)

* It is not only a question of preparing an ontology. To publish it, update
documentation, explain it... is an _essential_ part of the process.
  (we have some new ontologies extending nepomuk in tracker, but no process
to publish and document them)

So, here is my idea of a nice future, as a revamped XESAM or as whole new
project. That is just a detail.

1) Take the nepomuk ontologies as base, and put them in a public repository.
Freedesktop/sourceforge/whatever
2) A bugzilla/mailing list/wiki/irc system to handle the improvements
     Great if the proposals can be patches to commit once approved.
3) A clear svn policy (what format to upload the ontology, what documents in
what format and location)
4) A whole set of scripts to generate the ontologies in different formats +
HTML documentation
5) A script "publish everything" that updates the web site.

The process:
1) Application developer is working on his application and discover that
certain property makes sense in the ontology
2) Open a bug requesting that details
3) Discussion in the bugzilla/mailing list about this
4) Resolution of the bug. If it is "commit", apply the changes (including
updated doc and changelog)
5) Publish ASAP. <- How to handle versions?

Well, this is not rocket science: it is just apply the usual open source
development to the ontologies. The obvious con here is that ontologies must
be stable to be usable... but if you freeze the ontologies too early, they
are useless. The XESAM users is still a quite small group, and everybody is
following the mailing lists. Lets take advantage of it to improve the
ontology!  At some point, we can also use the odd/even version numbers to
unstable/stable versions of the ontologies.

This is my solution proposal, to start up the discussion. What do you think?
Better solutions are always welcome.

Regards

Ivan Frade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20090424/77dae9d9/attachment.htm 


More information about the Xesam mailing list