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

[Mikkel Kamstrup Erlandsen]

2009/4/24 Ivan Frade <ivan.frade at gmail.com>:
> Hi all,
> <SNIP>
> * 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)


Agreed on all points.

> 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.

We already have a product on the FDO bugzilla and really all the items
you mention ready for Xesam except and SVN server

> 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.

I almost assume that someone out there must have written some good
XSLTs RDFS->HTML...

> 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 was pretty much what I had hoped for with xesam.org. For
some reason or other it didn't happen.

> 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.

All in all I am all for your plan, I am however unsure whether it will
actually change anything from our current workflow. It would mean that
more people would start doing the boring and cumbersome tasks (that
also seem to give very little direct benefit). From my experience
people don't jump all over such tasks...

At the very least it requires the whole process to be incredibly smooth.

-- 
Cheers,
Mikkel