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

Re: Comments on SKOS namespace change question

From: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
Date: Thu, 2 Oct 2008 11:01:12 +0100
Message-Id: <BA6A17E0-80E6-4946-81A7-4AE1F7375896@manchester.ac.uk>
Cc: "SWD Working SWD" <public-swd-wg@w3.org>, "Tim Berners-Lee" <timbl@w3.org>
To: "Houghton,Andrew" <houghtoa@oclc.org>


On 1 Oct 2008, at 13:57, Houghton,Andrew wrote:

>
>> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-
>> request@w3.org] On Behalf Of Sean Bechhofer
>> Sent: Wednesday, October 01, 2008 6:48 AM
>> To: Tim Berners-Lee
>> Cc: SWD Working SWD
>> Subject: Re: Comments on SKOS namespace change question
>>
>> The issue here is that one of the changes is to the semantics of
>> broader (and narrower). If we change the names of these properties,
>> then I think a lot of the benefit of keeping the same namespace is
>> lost. To return to my earlier characterisation of the issue [1], the
>> two choices are:
>>
>> [[
>> *A*/ Keep the existing SKOS namespace
>>
>> Pros:
>> + Existing legacy data can continue to use vocabulary
>>
>> Cons:
>> - Semantics of the SKOS vocabulary change (e.g. broader),
>> causing problems with legacy applications.
>
> I just don't understand your Cons statement.  If you had kept the  
> original semantics of skos:broader the same and introduced a new  
> skos:broaderNonTransitive, exactly how would this cause problem  
> with legacy data and applications?

My intended interpretation of A is that although we keep the SKOS  
namespace the same, we do not keep the original semantics of broader.  
This then means that applications that make use of the original  
semantics (e.g. the fact that skos:broader is transitive) may no  
longer be respecting the normative semantics.

> Personally, I see another option:
>
> 1) keep the same namespace
> 2) make skos:broader and skos:narrower no longer infer any  
> semantics about transitivity
> 3) make skos:broaderTransitive for transitive and a sub-property of  
> skos:broader
> 4) make skos:broaderNonTransitive for non-transitive and a sub- 
> property of skos:broader
> 5) make skos:narrowerTransitive for transitive and a sub-property  
> of skos:narrower
> 6) make skos:narrowerNonTransitive for non-transitive and a sub- 
> property of skos:narrower

This issue was discussed at length by the WG. We believe that the  
pattern that we have chosen (no assertions about transitivity of  
broader/narrower along with a transitive superproperty) provides the  
flexibility of supporting direct assertions of broader/narrower along  
with query across the transitive closure using the superproperty.

> Legacy data and applications could easily live with the fact that  
> skos:broader and skos:narrower no longer infer transitivity, but  
> just mean one concept is broader or narrower than another.

The fact that applications might /not/ easily live with this change  
in semantics is exactly my Cons statement above. If it is the case  
that this is not a problem, then that's fine -- I would be interested  
to hear more from implementers about this though.

	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 Thursday, 2 October 2008 10:01:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 2 October 2008 10:01:12 GMT