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

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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This e-mail, and any file transmitted with it, is confidential and
> intended solely for the use of the individual or entity to whom it is
> addressed. If you have received this email in error, please contact the
> sender and delete the email from your system. If you are not the named
> addressee you should not disseminate, distribute or copy this email.
> 
> For more information on Agence France-Presse, please visit our web site
> at http://www.afp.com
> 
> 
>

Received on Friday, 25 July 2008 12:01:35 UTC