Re: AW: AW: [SKOS] Transitive broader and ISSUE-56 (was The return of ISSUE-44 )

Hi Simon,

> Did we come to a resolution on this issue?

Yes, the issue [1] has been closed by adopting [2].

>  If it has been decided to break with the standards, then the Primer 
> and Reference need to be rewritten to make this explicit everywhere 
> that broader and narrower are discussed.

The latest Primer draft [3] (don't go and comment everything there! 
We'll release it in some weeks only ;-) reads:
[[
Mirroring the fundamental categories of relations which are used in 
vocabularies such a thesauri [ISO2788], SKOS proposes three standard 
sub-properties for it:
    * skos:broader and skos:narrower enable the representation of 
hierarchical links, such as the relationship between one genre and its 
more specific species, or the one between one whole and its parts;
    * skos:related enables the representation of associative 
(non-hierarchical) links, such as the relationship between one type of 
event and a category of entities which typically participate in it. 
Another use for skos:related is between two categories where neither is 
more general or more specific.
]]
Do you think this really breaks with the standards?

>
> Just because an inference is possible doesn't mean that a query 
> expansion has to follow it;  the difference between BT/NT and RT is 
> that the inference is permissible.

I agree. The problem is that if specify that skos:broader is transitive 
we do not specify that the inference is permissible, we specify that it 
is mandatory, which forces any query reformulation strategy should 
follow it.
Imagine a server which serves the statements "A skos:broader B" and 
"B:skos:broader C".
Then if SKOS says that skos:broader is transitive, then the server 
should also serve "A skos:broader C". Otherwise it won't be compliant 
with SKOS specification.
So if a reformulation service goes to this vocabulary servic to get the 
narrower concepts of C, it will get both B and C, whatever it wants to 
use transitivity or not.

With the current resolution of [2], we offer services to access both a 
non-transitive (skos:broader) and a transitive version 
(skos:transitiveBroader) of a same hierarchy.

>
> On the other hand, making BT non-hierarchical  makes it much harder to 
> apply the principle of specificity.  If a result set  contains 40 
> documents about different kinds of rodents, most  of which have 
> different headings,  non-hierarchical  broader prohibits merging any 
> headings that aren't direct siblings.

I would like to answer this, but honnestly I really don't understand 
what your "non-hierarchical" means, as I'm convinced skos:broader 
denotes a hierarchical link (even if it is not transitive)

Best,

Antoine

[1] http://www.w3.org/2006/07/SWD/track/issues/44
[2] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0090.html
[3] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer
>
> Simon
> On Jan 14, 2008, at 12:25 PM, Antoine Isaac wrote:
>
>> Hi Simon,
>>
>>>
>>> >The Core guide reads
>>>
>>> > To assert that one concept is broader in meaning (i.e. more general)
>>> > than another, where the scope (meaning) of one falls completely 
>>> within
>>> > the scope of the other, use the |skos:broader
>>> > < http://www.w3.org/2004/02/skos/core/spec/#broader>| property
>>>
>>> >The current Primer reads the same, as well as the Reference.
>>> I> think this is rather compatible with ISO 2788 for instance.
>>>
>>> It's 100% compatible with the standards- it's just  incompatible 
>>> with intransitive broader.   :)
>>>
>>> Any intransitive broader must feature at least some cases of   
>>> partial overlap.
>>
>> I think I can understand your point. To me, however, what is 
>> important is user satisfaction. And if I can find somewhere a SKOS 
>> users that are not happy with transitivity of broader, this ruins the 
>> idea of having it generally transitive.
>> Examples most often encountered are:
>> - KOS designers that do not "support" the kind of inference that 
>> transitivity would imply for their KOS, for whatever reasons (even if 
>> in the loop that forces them to acknowledge that their hierarchy is 
>> dirtier than what they would hope for)
>> - KOS consumers (e.g. designers of user interface) that do not like 
>> the idea of having inferences that ruin the structure as it was 
>> defined. In information retrieval it is acknowledged that the value 
>> of items retrieved "decreases" when you expand queries using the 
>> hierarchy: it can be quite ok if you expand using the specializations 
>> that are one step down the initial query, much less ok if you return 
>> a document described with a concept ten steps below the initial query.
>>
>> Best,
>>
>> Antoine
>>
>>>
>>>
>>> Simon
>>>
>>>
>>> On Jan 14, 2008 11:42 AM, Antoine Isaac <aisaac@few.vu.nl 
>>> <mailto:aisaac@few.vu.nl>> wrote:
>>>
>>>    Hi Simon,
>>>
>>>    The Core guide reads
>>>
>>>    > To assert that one concept is broader in meaning ( i.e. more
>>>    general)
>>>    > than another, where the scope (meaning) of one falls completely
>>>    within
>>>    > the scope of the other, use the |skos:broader
>>>    > < http://www.w3.org/2004/02/skos/core/spec/#broader>| property
>>>
>>>    The current Primer reads the same, as well as the Reference.
>>>    I think this is rather compatible with ISO 2788 for instance.
>>>
>>>    Best,
>>>
>>>    Antoine
>>>
>>>    > On Jan 14, 2008, at 7:29 AM, Antoine Isaac wrote:
>>>    >
>>>    >> I'm not sure this would be 100% safe, as multiple ways of
>>>    >> specializing skos:broader can be thought of, cf ISSUE-56 [1]
>>>    >> And these mixes, leading to possibly confusing hierarchies for
>>>    >> newcomers: consider the combination of "transitive"and 
>>> "partitive"
>>>    >> specializations. We can specialize skos.broader into
>>>    >> skos:broaderTransitive, skos:broaderPartitive,
>>>    >> skos:broaderTransitivePartitive. If we consider other axes of
>>>    >> specialization (e.g. for "generic" and "instance" flavors of
>>>    >> hierarchy) this would blur the picture even more...
>>>    >>
>>>    >> On the other hand, given the number of reactions we had on this
>>>    >> transitive aspect of broader, we might just decide to introduce
>>>    only
>>>    >> transitiveBroader, as an acknowledgement of the interest it 
>>> gained.
>>>    >
>>>    > Can somebody explain to me what 'broader' and 'narrower',
>>>    unqualified,
>>>    > mean now?
>>>    >
>>>    > Given that the whole semantics of SKOS are now completely
>>>    undefined,
>>>    > and that the core guide is going to have to be completely 
>>> rewritten,
>>>    > what do these terms mean.
>>>    >
>>>    > We know that they can't be *any* kind of orderings.
>>>    >
>>>    > We know that they can't be  associative relationships, because
>>>    > otherwise they'd just be called relationships.  We know that the
>>>    > language used in the SKOS Core Guide has previously been  taken 
>>> from
>>>    > and aligned with Z39.19 et al, but that this is no longer
>>>    acceptable.
>>>    >
>>>    > Just calling an associative relationship hierarchical does not
>>>    make it
>>>    > so.  The LC made tried that  twenty years ago.  Mary Dykstra(1988)
>>>    > explained the problems  with this approach (if you haven't read
>>>    this
>>>    > article, it's very helpful background for this discussion).
>>>    >
>>>    > I I have no problem with SKOS being used to represent false 
>>> claims;
>>>    > I'm working with the LCSH, which, being of Congress, is riddled
>>>    with
>>>    > the things. Redefining an existing concept so as to make the false
>>>    > claims become true brings in to question the whole exercise.  
>>> 'Sorry
>>>    > if I'm sounding like a broken record on this, but the broadening
>>>    that
>>>    > I'm most afraid of is  the whole thing going pear-shaped.
>>>    >
>>>    > If having a transitive broader is too problematic, can we at least
>>>    > remove   unqualified broader and narrower completely?
>>>    >
>>>    > Simon
>>>    >
>>>    > [Dykstra(1988)] Mary Dykstra. LC Subject Headings Disguised as a
>>>    > Thesaurus. /Library Journal/, 113(4):p42 –, March 1988. ISSN
>>>    03630277.
>>>    > URL http://search.ebscohost
>
>

Received on Friday, 25 January 2008 13:11:40 UTC