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 _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
