W3C home > Mailing lists > Public > public-swd-wg@w3.org > April 2008

Re: Deprecated SKOS Vocabulary

From: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
Date: Wed, 9 Apr 2008 13:12:04 +0100
Message-Id: <173CFAE1-4582-474F-AE27-37BAC02DD896@manchester.ac.uk>
Cc: SWD Working Group <public-swd-wg@w3.org>
To: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>


On 7 Apr 2008, at 13:05, Sean Bechhofer wrote:
>
>
> I've had a long standing action next to my name to propose a way to
> handle deprecated properties. This is related to the task of producing
> an RDF schema -- in particular whether we include the deprecated
> properties as instances of, for example, owl:DeprecatedProperty.
>
> The deprecated vocabulary should be documented somewhere (in
> Reference), but I do not see a great advantage in including the
> vocabulary in the RDF schema. Rather, I would see that it could lead
> to additional "clutter" in the schema. As this is the first "official"
> description of the vocabulary, I would like to start with as clean a
> slate as possible.
>
> So, my proposal is that we include a section in the Reference that
> details the deprecated vocabulary from the original schema, but that
> we do *not* include the deprecated properties in the RDF schema.
>
> This does have the effect that there will be vocabulary elements in
> the SKOS namespace in use in some legacy vocabularies that are not
> explicitly defined in the RDF schema. There is a question as to
> whether we consider this to be a problem.
>
> A related question here concerns the namespace of the SKOS vocabulary.
> I think there is an implicit assumption that we will continue to use
> the http://www.w3.org/2004/02/skos/core namespace for the vocabulary.
> I see no strong argument for changing this (and arguments for not
> changing it -- for example to ensure that existing SKOS content and
> applications continue to work), but thought that it would be useful
> to at least have this explicitly stated.

It seems from the discussions on yesterday's telecon that these issues
are closely related. Hopefully the following summarises possible
courses of action:

*A*/ Keep the existing SKOS namespace and do not include definitions
of the old vocabulary. Reference should include an appendix describing
the deprecated vocabulary.

Pros:
+ Existing legacy data can continue to use vocabulary

Cons:
- Deprecated vocabulary lacks machine readable descriptions.
- Semantics of the SKOS vocabulary may change (e.g. broader),
causing problems with legacy applications.

*B*/ Keep the existing SKOS namespace, and include the old vocabulary
in the schema, marked as deprecated.

Pros:
+ All vocabulary in use has machine readable descriptions.
+ Existing legacy data can continue to use vocabulary

Cons:
- Potential "bloat" in the schema.
- Not quite a "truth and beauty" solution, with the first "official"
version of the schema containing deprecated vocabulary
- Semantics of the SKOS vocabulary change (e.g. broader),
causing problems with legacy applications/collections.


*C*/ Introduce a new SKOS namespace, without the old
vocabulary. Existing schema remains.

Pros:
+ We can provide new semantics without implicitly affecting
existing collections or implementations
+ Clear versioning
+ Old vocabulary still has machine readable descriptions

Cons:
- Legacy collections may need to update.

Following the discussion, my preference (in decreasing order) is C,  
A, B, but then I'm a truth and beauty kind of guy :)-)

	Sean

--
Sean Bechhofer
School of Computer Science
University of Manchester
sean.bechhofer@manchester.ac.uk
http://www.cs.manchester.ac.uk/people/bechhofer
Received on Wednesday, 9 April 2008 12:13:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 April 2008 12:13:20 GMT