RE: SKOS comment: change of namespace (ISSUE-117)

I have been watching this conversation with detached interest.  From one perspective, it doesn’t bother me that the namespace has changed, being a publisher of SKOS vocabularies.  The reason why is because SKOS is still a draft and I expect that things are going to change until it gets to a candidate recommendation.  My prior publications of controlled vocabularies under SKOS are still using the old URI and have the same semantics as before.  However, if the SKOS namespace were to change during a candidate recommendation, I would be concerned.

 

>From another perspective, it seems to me that this breaking change was not all that necessary.  The semantics of skos:broader and skos:narrower were transitive and it seems to me that instead of changing them to be non-transitive the committee could have created skos:broaderNonTransitive and skos:narrowerNonTransitive instead of creating skos:broaderTransitive and skos:narrowerTransitive and reusing skos:broader and skos:narrower for non-transitivity.  Most of the major controlled vocabularies are transitive so forcing them to use skos:broaderTransitive seems a little ridiculous.

 

It also seems to me that there is a problem with this flip/flop of skos:broader and skos:narrower being transitive.  SKOS now specifies skos:broader and skos:narrower to be non-transitive, but skos:broaderTransitive and skos:narrowerTransitive are a sub-property of skos:broader and skos:narrower respectively.  This implies to me, not being an RDF/OWL expert, that skos:broaderTransitive and skos:narrowerTransitive inherit non-transtivity from skos:broader and skos:narrower respectively, and that just seems funky since you are saying that the relationship is transitive.

 

As an observation, it seems to me that the current process may not be as transparent as it was under Alistair Miles prior direction.  I’m sure there are some meeting minutes that detailed the namespace change and the committee’s discussion of the implications in changing the namespace, but given the reaction to the namespace change on this list it appears a lot of people were caught off guard by the committee’s decision without being able to comment on the change before the change was actually voted and acted upon by the committee.  Perhaps better communication would have helped smooth this issue over with the community.

 

Andy.

 

From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org] On Behalf Of Simon Spero
Sent: Monday, July 28, 2008 3:27 PM
To: Alistair Miles
Cc: Laurent LE MEUR; public-swd-wg@w3.org; public-esw-thes@w3.org
Subject: Re: SKOS comment: change of namespace (ISSUE-117)

 

On Fri, Jul 25, 2008 at 8:00 AM, Alistair Miles <alistair.miles@zoo.ox.ac.uk> wrote:

	
	The argument against sticking with the old namespace is that the semantics have changed significantly. I don't think that's necessarily true. The only
	change to the semantics of an existing element is the change of skos:broaderto not being transitive. However, all data I know of currently published
	fits perfectly well with the usage pattern that "skos:broader is used to assert a direct hierarchical link between two concepts" -- and hence is perfectly consistent with the new data model. If anyone can provide a counter-example I'd be very grateful.


http://lcsh.info/

The Hierarchical Relationship: Broader Topics and Narrower Topics
[...]
A heading is normally linked to one immediately next to it in the subject heading hierarchy. Since the referenced headings are linked in turn to ther headings, reference for distant relationships are no longer made. References leading to two or more levels in a hierarchy reflect an obsolete practice. 

Library of Congress Subject Headings (22nd edition) vol. 1, p. x 


This policy corresponded to the introduction of explicit BT and NT relationship designators, and is incrementally implemented. This instruction is only plausible because the BT relationship is transitive ("No matter what the level at which one enters the hierarchy, one can follow either the  BT or NTs to find the broadest or most specific headings" (ibid) 

In current LCSH, we have separate, explicit assertions that:

1: Technological innovations BT Inventions        (TI  BT I)
2: Inventions BT Creative ability in technology    (I BT CAIT)
3: Technological  innovations BT Creative ability in technology   (TI BT CAIT)

Under the tranditional meaning  of BT, assertion 3 is uncessary, due to the semantics of hierarchical relationships.  Under LC rules, which are semantic preserving, it is safe to remove this link.

Removing it, we have 

TI BT I ,  I BT CAIT   |= TI BT I, I BT CAIT,  TI BT CAIT

Under the original, correct, skos  semantics, broader operates the same   BT. 

TI broader I,  I broader CAIT |= TI broader I, I broader CAIT, TI broader CAIT 

Under the new semantics
TI "broader" I, I "broader" CAIT |/= TI broader CAIT

The semantics of the new "broader" are *clearly* not the same as BT, or the correct broader.  

IF you want to keep the same namspace, rename the new "broaderTransitive" relationship to "broader", and rename the new "broader" relationship to "directllyAssertedBroader". 

The BT relationship is intrinsically hiearachical and thus transitive.