[SKOS] The return of ISSUE-44 (was Re: TR : SKOS Reference Editor's Draft 23 December 2007)

Hello Simon, Dan (ccing this thread to the SWD list since it is again 
about important stuff)

I copy the complete message, but, my only important comment is at the end
[apart from saying again that with the current setting for skos:broader, 
we can have a transitive specialization of it, which would allow what 
Simon proposes while not hurting other applications]
>
> De: public-esw-thes-request@w3.org de la part de Dan Brickley
> Date: mer. 09/01/2008 12:52
> À: Simon Spero
> Cc: Miles, AJ (Alistair); SKOS
> Objet : Re: SKOS Reference Editor's Draft 23 December 2007
>
>
> ref: http://www.w3.org/2006/07/SWD/SKOS/reference/20071223#L2413
>
> Simon Spero wrote:
> > [Greetings from Sunny Chigwell]
>
> And from sun-kissed Bristol...
>
> > I'm still really, really uncomfortable with the breakage of 
> > skos:broader, primarily in regards to the loss of transitivity.
>
> Me too. I feel a bit guilty, I saw these threads go past but didn't
> really get that transitivity was being dropped. I think this is a
> probably a mistake. The transitivity of skos:broader comes from the "er"
> part in the naming, ... something is more something than something else.
> More broad, in this case. Younger, richer, broader, ... etc.
>
> > BT relationships in all compliant thesauri must be transitive.
> >
> >   Each of the relationships should lead to hierarchies that are amenable
> > to a logical test through reference to the basic types of concept
> > represented by the terms. (NISO 2005, §8.3)
> > 
> > As an  example of a valid hierarchical relationship and test  (NISO
> > 2005, Figure 6 ) uses:
> >
> > /cacti/   ? /succulent plants /
> > SOME /succulent plants/ are /cacti/
> > ALL /cacti/ are /succulent plants/
> > /
> > /The example given for an  invalid hierarchical relationship is (NISO
> > 2005, Figure 7 )
> >
> > /cacti/ ? /desert plants /
> > SOME /desert plants/ are /cacti/
> > SOME /cacti/ are /desert plants
>
> SKOS is by design more scruffy than RDFS/OWL class hierachies, so saying
>
> _:cacti:concept skos:broader _:desert_plant  isn't quite like saying
> "there's a class Cacti that is subClassOf DesertPlant, and anything in
> te former is in the latter". With SKOS, it's more like, here's a couple
> of concepts, and then we attach semantics like "anything that is a
> document that is about the former is also in a sense about the latter".
> With the wiggle-room expressed in supporting vocabulary, eg.
> skos:subject. So we could agree that c1 has skos:broader c2, yet have
> plenty of room to debate about what else that implies, if anything.
>
>
> > A  relationship that does not obey these properties is not hierarchical
> > and should not be labeled as such.
>
> Yep, it's perfectly OK to be able to write false claims in SKOS. There's
> nothing wrong with being wrong.
>
>                  The relationship is associative, and
> > can be modeled in SKOS using the appropriate construct
> > (skos:related).    The error is in the data, not the standard.
>
> +1
>

-1
As far as I'm concerned, we are not trying to propose with SKOS a 
standard that would oblige KOS owners to re-engineer their conceptual 
structures to fit our whishes. The objective is to easily represent and 
to publish KOSs. So if there is enough cases of "non-transitive" 
hierarchies (and I do believe it is the case) then it is a wrong design 
decision to make skos:broader transitive.

I would actually like to get some feedback on the following point of 
view, to see whether I'm completely wrong or not. To me, ISO and others 
are standards that are also intended as guidelines for designing good 
thesauri, hence their spending much pages on explaining how to properly 
choose a term and so on. SKOS is different because:
- it is not a guideline that says in details what makes a good KOS or 
not for KOSs. We have some recommendations, but the number of 
constraints is very small.
- SKOS could be used to represent KOSs that are not thesauri

Cheers,

Antoine

Received on Wednesday, 9 January 2008 21:17:01 UTC