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

Re: Deprecated SKOS Vocabulary

From: Guus Schreiber <schreiber@cs.vu.nl>
Date: Wed, 09 Apr 2008 17:39:20 +0200
Message-ID: <47FCE328.4060108@cs.vu.nl>
To: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
CC: SWD Working Group <public-swd-wg@w3.org>



Sean Bechhofer wrote:
> 
> 
> 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:

Thanks, Sean, very useful.

> 
> *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.

The fact that A makes old vocabularies invalid (no corresponding SKOS definition at the namespace URI) means that this solution unacceptable for me. 

> 
> *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.
> 

Changing in semantics are maybe not unacceptable, but certainly unwanted. I don't mind the bloat so much. 

> 
> *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.

The update is only needed in case collections want to move to the Rec version of SKOS, which will probably be a conscious decision anyway. The old namespace stays intact, so nothing goes wrong. I have a strong preference for this solution.

Proposed general guideline (for the VM document?):
- minor updates should keep the same namespace document. For example  I would expect OWL 1.1 to use the OWL 1.0 namespace as it is chartered to define extensions. 
- major updates/revisions should have a new namespace (with the old one intact of course). 

Guus




> 
> 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
> 
> 
> 
> 

-- 
VU University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
T: +31 20 598 7739/7718; F: +31 84 712 1446 
Home page: http://www.cs.vu.nl/~guus/
Received on Wednesday, 9 April 2008 16:15:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 April 2008 16:15:54 GMT