- From: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
- Date: Thu, 2 Oct 2008 11:01:12 +0100
- To: "Houghton,Andrew" <houghtoa@oclc.org>
- Cc: "SWD Working SWD" <public-swd-wg@w3.org>, "Tim Berners-Lee" <timbl@w3.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 UTC