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

[Evgeny Egorochkin]

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 
stable/enterprise-friendly Nepomuk.

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

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

-- Evgeny