Re: Deprecated SKOS Vocabulary

Hi Guus and all,

I'll include the guidance regarding when to "rev" namespaces, and send 
you a snip of the text for review, likely over the weekend or early next 
week.

Thanks,

Elisa

Guus Schreiber wrote:

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

Received on Wednesday, 9 April 2008 22:42:43 UTC