RE: SKOS comment: change of namespace (ISSUE-117)

Greetings:

Given that namespace seems to be used as a versioning mechanism .. I agree
with your proposal of retaining the 2004/02 namespace .

carl

<quote who="Alistair Miles">
>
> Hi all,
>
> The more I think about this issue, the more I think it makes sense to keep
> the old 2004/02/skos/core# namespace rather than move to a new one.
>
> The bottom line is that there is a lot of deployed SKOS data out there
> already, using the 2004/02 namespace. I hear about new deployments every
> week. As an aside, I'd love to put together a registry/discovery service
> for
> SKOS data, so we can get a handle on what is out there, because I get the
> feeling I don't know the half of it.
>
> Although it's not an enormous burden on the data providers to migrate to a
> new namespace, it will take time. I.e. there will be a significant
> transition period (probably years) before all currently available data are
> published using the new namespace.
>
> This means that, during this transition period, software providers will
> have
> to develop code to handle both the 2004/02 namespace and the new
> namespace.
> Again, although the burden isn't enormous, it's not insignificant.
>
> This also means that we'll have to wait some time after the SKOS Reference
> is published to have any substantial implementation, as we wait for data
> providers to migrate.
>
> If instead we stick with the 2004/02 namespace, then the SKOS Reference
> will, on publication, already have a very substantial implementation. This
> fits the reality which is that, right now, the standard is behind the
> data.
> This also means that deployment and implementation work can continue
> apace,
> without slowing either the data providers or the software providers down.
>
> The argument against sticking with the old namespace is that the semantics
> have changed significantly. I don't think that's necessarily true. The
> only
> change to the semantics of an existing element is the change of
> skos:broader
> to not being transitive. However, all data I know of currently published
> fits perfectly well with the usage pattern that "skos:broader is used to
> assert a direct hierarchical link between two concepts" -- and hence is
> perfectly consistent with the new data model. If anyone can provide a
> counter-example I'd be very grateful.
>
> Overall, I cannot think of any changes which make previously published
> data
> inconsistent with the current data model. Again, if anyone can provide
> counter-examples I'd be grateful.
>
> In sum, I feel that moving to a new namespace will impose a burden that is
> unnecessary, and that will significantly slow down all of the great work
> that's currently underway, without any great benefit. In other words,
> there's lots of down-side without much up-side.
>
> What are everyone's thoughts on this?
>
> The WG has formally resolved to move to a new namespace, so this is what
> will be implemented in the last call working draft of the SKOS Reference.
> However, the WG has agreed the namespace will be marked as a "feature at
> risk of change" in the last call working draft, and hence will be open to
> change at the next stage of the process.
>
> Cheers,
>
> Alistair.
>
> --
> Alistair Miles
> Senior Computing Officer
> Image Bioinformatics Research Group
> Department of Zoology
> The Tinbergen Building
> University of Oxford
> South Parks Road
> Oxford
> OX1 3PS
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: alistair.miles@zoo.ox.ac.uk
> Tel: +44 (0)1865 281993
>
>> -----Original Message-----
>> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-
>> request@w3.org] On Behalf Of Laurent LE MEUR
>> Sent: 17 June 2008 17:01
>> To: public-swd-wg@w3.org
>> Subject: SKOS comment: change of namespace
>>
>> Bernard Vatant just made me aware of the change of namespace of the
>> SKOS vocabulary (from  http://www.w3.org/2004/02/skos/core# to
>> http://www.w3.org/2008/05/skos#).
>>
>>
>>
>> I understand that there was a non-backward compatible evolution of the
>> draft during the 4 last years, but I still want to express my bad
>> feeling about this:
>>
>>
>>
>> Such modification is a pain for implementers: all XSLT stylesheets or
>> DBMS connectors have to be modified, endless discussions will arise
>> between SKOS providers and SKOS readers (" you have an old SKOS",
>> "which namespace do you have?").
>>
>>
>>
>> I agree that changing a namespace is good policy when a standard
>> evolves in a non-backward compatible way.
>>
>> BUT:
>>
>> a)      SKOS is still a draft, no a standardized vocabulary; SKOS has
>> no version that would allow people to say "I have implemented *this*
>> version"
>>
>> b)      such non-backward compatible evolution should only be
>> associated with a major versioning of a standard (e.g. from version 1.x
>> to 2.0)
>>
>> c)       the evolutions have touched side features, not core features,
>> so most draft implementations were still usable . until  the namespace
>> was changed.
>>
>>
>>
>> Best regards
>>
>> Laurent Le Meur
>>
>> AFP

-- 
Carl Mattocks
Chair OASIS Business Centric Methodology TC
co-Chair OASIS (ISO/TS 15000) ebXMLRegistry Semantic Content SC
ONTOLOG ONION CoP Leader
CEO CHECKMi
vmail(usa) 908 322 8715
www.CHECKMi.com
Semantically Savvy Agents

Received on Friday, 25 July 2008 12:47:37 UTC