Dear All, after studying the arguments provided by Reto and Tsuy, I must admit that for the sake of compliance to standards, we should change the SKOS namespace back to the one accepted by W3C.
However, I wonder if there is a mechanism to support existing users who want to upgrade their clerezza instance wihtout having to change their codes (means changing the import statements and all occurances of SKOS to SKOS08 in java program codes). Note that the change to SKOS class breaks existing codes (a software cannot fulfil its functionality). Since Clerezza is not intended to be used exclusively, but as a base for developing other functionality by our community members, we should take care that community members who are currently using Clerezza, will not be affected (if possible) if they would merely upgrade their Clerezza platform. I don't know whether using packageinfo (for versioning) can avoid or at least mitigate this problem. I am thinking of simply specifying the package version of rdf.ontologies to be imported by community members' projects. I'd suggest to investigate this and other possibilities before making changes to SKOS namespace. Thus -1 for the time being Kind regards Hasan On Thu, Sep 6, 2012 at 10:36 PM, Reto Bachmann-Gmür <[email protected]> wrote: > On Thu, Sep 6, 2012 at 1:02 PM, Tsuy Ito <[email protected]> wrote: > > > What happens if in future another version will be defined as namespace of > > SKOS? You will update it again and all users have to change their code, > > again? not very user-friendly. > > > Your argument about user friendlyness seems a bit starnge. How can it be > user friendly is in clerezza "SKOS" refers to a namespace that was only > temporarily proposed and never accepted and not to the namespace that is > and has been the standard across different all the different released > versions of the spec. > > The W3C has decided not to change the namespace, its only Clerezza that > adopted a proposed namespace change that was never accepted. So the SKOS > namespace is the old http://www.w3.org/2004/02/skos/core# one and users > rightfully expect the clerezza constants to refer to this. > > > > > > Especially because user who uses snapshot versions will not notice the > > change (build will not break) but this change will have a big impact on > the > > existing data. So they have to update their database or update their > source > > code. > > > Well, in a productive context a user should only change to a SNAPSHOT > version id this brings significant needed improvements. Here the only > improvemnet is exactly the resolution of CLEREZZA-717 is it asking to much > that somebody depending on the current bug either not to update or change > its code to use the SKOS08 class? > > Cheers, > Reto > > > > > > There is no technical reason for my -1 but I suggest do it the other way > > arround to be more user-friendly. > > > > > > -1 > > > > cheers > > tsuy > > > > > > On Sep 6, 2012, at 11:50 AM, Reto Bachmann-Gmür <[email protected]> wrote: > > > > > After checking the spec again I can confirm what Rupert wrote > > > > > > The august 28 2008 version used the > > > http://www.w3.org/2008/05/skos#namespace [1] but the final version of > > > the spec of August 28 2009 defines > > > http://www.w3.org/2004/02/skos/core# to be the namespace [2]. > > > > > > Therefore I vote > > > > > > +1 > > > > > > Cheers, > > > Reto > > > > > > 1. http://www.w3.org/TR/2008/WD-skos-reference-20080829/#L1302 > > > 2. http://www.w3.org/TR/skos-reference/#vocab > > > > > > > > > On Thu, Sep 6, 2012 at 11:43 AM, Reto Bachmann-Gmür <[email protected]> > > wrote: > > > > > >> As there doesn't seem to be a consensus on the discussed namespace > > change > > >> I ask for a vote on the resolution I propose for CLEREZZA-717. My > > proposed > > >> resolution can be seen here: > > >> > > >> > > https://svn.apache.org/repos/asf/incubator/clerezza/issues/CLEREZZA-717/ > > >> > > >> See > > >> > > > http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201209.mbox/%3ccalvhuevo5vu1+pqr_mjwsttwwcevrxeq-1y7apq0yuggb9x...@mail.gmail.com%3Eforthediscussion > thread. > > >> > > >> The vote will be open for at least 72h > > >> > > >> Please note that vetoes (-1) need a technical reason to be valid. > > >> > > >> > > >> > > > > --trialox ag------------------------------------- > > tsuyoshi ito > > hardturmstrasse 101 > > 8005 zuerich > > > > >
