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

Hi Simon,

In fact for LCSH conversion we have not implemented transitivity for 
broader. Only the asserted statements (originally in a 550 Marc field, 
for instance) are found there.
If you have such example, it is that it was already present in LCSH, 
even though, as you point out, this is a bit useless.

Now, coming to your argument, I am still unconvinced. Indeed I can read 
your quotes in a different manner

> A heading is normally linked to one immediately next to it in the 
> subject heading hierarchy.
Therefore it is not productive to link to an ancestor with the same link 
as the one that is in the parent.
If we had broader to be transitive, then a same link (corresponding to 
550/BT) would link to the parent and all other ancestors.

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

This precisely hints that the link to ancestors should be derived from 
an extra action: "following" the BT links, and not reading BTs that 
would be considered transitive.
(which by the way contradicts your "BT relationship is intrinsically 
hiearachical and thus transitive": if it was the case, you would not 
have to "follow" BTs to have the ancestors, but just to read/access them)
That is precisely what broaderTransitive aims at capturing: it is a 
property whose semantics allow to implement this "follow-the-BTs" 
strategy to find ancestors.

To come back to your proposition:
>
> IF you want to keep the same namspace, rename the new 
> "broaderTransitive" relationship to "broader", and rename the new 
> "broader" relationship to "directllyAssertedBroader".
That's because you really want "broader" to have its (assumed intuitive) 
meaning of "is more general than, whatever the number of steps followed".
I actually agree that this could make some sense. But of course I prefer 
to keep broader mirroring BT as much as possible. I know that you'll 
argue again against that, but to me if we have in original KOS data
> cats BT mammals
> mammals BT animals
and not
> cats BT animals
and if we have guidelines that say "if this latter kind of BT occur, 
then it's a bug", then I don't see why broader should do what BT does 
not. That's the role of another property.

Note, further, that most existing SKOS conversions out there seem to 
follow nicely (for us of course) the 
"broader-as-directllyAssertedBroader" stance. So changing is not needed, 
and would even not be ideal.

(actually to be honnest about intuitive names, if we cannot change 
something as obfusctating as using "broader" for "hasBroaderConcept", I 
cannot see how we would change the hierarchical property labels to 
reflect our choices better. Following what Dan just wrote, maybe for 
broaderTransitive it could be possible to re-label it as "ancestor", or 
something like that. But doing it for braoder seems nearly impossible)

Best,

Antoine

> On Fri, Jul 25, 2008 at 8:00 AM, Alistair Miles 
> <alistair.miles@zoo.ox.ac.uk <mailto: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. 
>
>
>

Received on Tuesday, 29 July 2008 08:03:24 UTC