Re: RE : Suggestion for SKOS FAQ

The requirement for Transitivity is implicit in  the requirement that
hierarchical relationships be all-some - that is, if A BT B, all documents
about A must also be about B.   This is the subset relationship between the
extensions of A and B (which are sets of documents).  This obviously
requires transitivity.
To clarify my example:  if A broader B and B broader C,  the altered SKOS
semantics permit  NOT(A broader C), but even when this is the case, would
still  prohibit A related C.

The prohibition of A related C is sensible under the standard semantics, but
does not seem justifiable under the altered SKOS semantics.


Simon

On Mon, Mar 10, 2008 at 7:20 AM, Antoine Isaac <Antoine.Isaac@kb.nl> wrote:

>
> Hi Simon,
>
> Two objections to your mail:
>
> 1. I still don't get it why ISO2788 says BT *should* be transitive. Of
> course there can be interpretations that leads to this, but it's still not
> 100% clear to me. Can you quote a sentence that makes you say so?
>
> 2. In the exemple you give, SKOS does not prohibit A broader C. We say
> that broader is *not transitive*, that different from saying that it is
> *intransitive* (or "antitrantisitive") ! "transitivity does not hold" does
> *not* mean that (NOT A broader C) is valid in all cases.
>
> Maybe actually point 2 is an answer to point 1, if you got our proposal
> for skos:broader semantics wrong.
> To sum up:
> - from A skos:broader B, B skos:broader C you cannot automatically infer A
> skos:broader C: there are concept schemes for which this would be assuming
> too much coherence for the hierarchical links.
> - there can be concept schemes for which the co-existence A skos:broader
> B, B skos:broader C and A skos:broader C is OK. Maybe all thesauri that are
> compliant with ISO2788, if ISO2788 say BT is always transitive. But the A
> skos:broader C was in that case produced by some knowledge that is not in
> the SKOS semantics.
>
> Does it make the situation clearer? You can also go to [1], when Alistair
> noticed this subtle differences (that had been also interfering with the SWD
> working group discussions)
>
> Best,
>
> Antoine
>
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2007Dec/0052.html
>
> -------- Message d'origine--------
> De: public-esw-thes-request@w3.org de la part de Simon Spero
> Date: ven. 07/03/2008 23:58
> À: al@jku.at
> Cc: iperez@babel.ls.fi.upm.es; SKOS
> Objet : Re: Suggestion for SKOS FAQ
>
>
> On Fri, Mar 7, 2008 at 4:54 PM, Andreas Langegger <al@jku.at> wrote:
>
> >
> >  thanks for the pointer to issue-44. I didn't read deep into the thread.
> > But as Antoine pointed out, there is the transitive version also
> (obviously
> > the result of the issue-44 discussion). So both kinds of semantics can
> be
> > expressed in the model and are not defined by the application.
> >
>
> The problem with the introduction of an intransitive "broader"
> relationship
> is that such a relationship is fundamentally incompatible with the Broader
> Term relationship as defined in ISO-2788 et. al.
>
> The defining characteristic of hierarchical relationships  is that they
> are
> totally inclusive.  This property absolutely requires transitivity.  If
> this
> condition does not apply, the relationship is associative, not
> hierarchical.
>   Renaming the broader and narrower term relationships doesn't change
> this;
> all it has done is cause confusion.
>
> As an example of the confusion so caused, note that associative
> relationships remain disjoint from broaderTransitive (S24)?    If
> "broader"
> can be intransitive, this constraint is inexplicable.
>
> Let A,B,C be Concepts,
>        A broader B,
>        B broader C,
>
> and suppose that transitivity does not hold (  NOT A broader C)
>
> By S18,  we have
>       A broaderTransitive B,
>       B broaderTransitive C,
> By S21,
>       A broaderTransitive C
>
> and hence, by S24,
>       NOT A related B,
>       NOT B related C,
>       NOT A related C
>
> We have NOT A broader C and NOT A related C, so there can't be any
> relationship between A and C  at all!
>
> Simon
>
>