- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 29 Jul 2008 10:02:52 +0200
- To: public-swd-wg@w3.org
- CC: public-esw-thes@w3.org
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:23 UTC