[Xesam] Nepomuk/Xesam future (was Re: condition of 1.0 ?)
phreedom.stdin at gmail.com
Sat May 2 16:35:07 PDT 2009
On 24 апреля 2009 19:00:25 Roberto Guido wrote:
> > at this time so xesam does not look a viable standard at the moment
> I can accept this, the most important point is to admit it.
> Next question is: would ever be Xesam a viable standard?
> Proposal from Ivan (please, correct me!!!) is to fork the Nepomuk ontology
> and maintain it in a community-driven structure, defining then the common
> API to access information. Is this possible? Is this a solution? Is this in
> the interest? Would "relevant trackers" agree to apply what specified here?
> What I'd like to see is to avoid a new failure as in Xesam 0.X: if a
> standardization is possible let's work to define that, otherwise close this
> project and move efforts in other directions.
A couple of points...
To fork or not to fork:
Xesam 2.0 isn't intended as a fork of Nepomuk. I'd rather consider it a
bleeding-edge Nepomuk with changes eventually backported into
Another reason to keep Xesam is standardization of Freedesktop-specific APIs
to access semantic desktop functionality. ATM Nepomuk provide nothing like
this and simply sharing ontologies isn't all that helpful to an application
that wants to work on all desktops.
Failure of Xesam 1.0: At some point it seemed like it was almost impossible to
get people to agree to anything. Now we have reached some consensus, and this
means that the ultimate goal of Xesam -- unified metadata functionality for
all desktops -- now has become realistic.
Semantic desktop tech is pretty fragile and complex. Fragmentation here with
desktops following different approaches could have killed or significantly
delayed the whole effort.
The biggest difference between 1.0 and 2.0 is that 1.0 was a lowest common
denominator of *current* abilities, limitations and quirks of a number
projects and as such was taking a reactive approach, that is just provide a
simple interface to use this. Needless to say this meant that any advanced
functionality the projects wanted to offer would end up having not being
standardized, any new functionality would be implemented ad-hoc and maybe at a
some point refactored to fit a workaround added to the spec etc etc.
2.0 is going to be proactive, that is it is well understood at the time of
standardization that there's no code that can do this right now and it might
take months to be written.
Nevertheless this means that when the functionality is implemented, it's
already standards-based, thought-out(instead of people hacking at random
things etc). Not that I consider coders stupid or anything, but understanding
the whole framework, how it's structured and how various different
parts(including ones a particular coder doesn't care about) play together, can
easily become a full-time job.
Any participating project implementing something significant that's not yet
supported by the spec could be considered a failure of the standard to guide
So Xesam is anything but a failure, even if ended up being successful in
another but related area.
As to the destiny of Xesam 1.0, implementing a wapper over a Xesam 2.0
implementation isn't going to be very hard indeed. Implementing a limited
1.0<->2.0 mapping is a bit more tricky but still possible. You can expect
clients to migrate to 2.0, some doing it fast because they need the abilities,
some doing it simply to follow the trend.
Current 1.0 implementations will either have to face the reality that a good
deal of apps DO need what 2.0 offers/will offer, or stick with a subset of
apps which would be just fine with simple tagging/commenting/document title
More information about the Xesam