W3C home > Mailing lists > Public > public-esw-thes@w3.org > January 2008

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

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 15 Jan 2008 11:32:01 +0100
Message-ID: <478C8BA1.3080201@few.vu.nl>
To: Johan De Smedt <johan.de-smedt@tenforce.com>
CC: 'SKOS' <public-esw-thes@w3.org>, 'SWD WG' <public-swd-wg@w3.org>

Hi Johan,

Thanks for the comments, and the advice (I do take the last part of your 
mail as advice on what our documents should contain)
Notice that for the moment there is no "standard extension" for SKOS. I 
think it's better if we have everything in one namespace. Whichj of 
course will not prevent people from creating their extensions, and some 
extensions to become kind of "references" for the community if they are 
widely re-used...

Best,

Antoine



> Dear,
>
> I am following the discussion because we want to use SKOS.
>
> The home page (http://www.w3.org/2004/02/skos/) tells me:
> SKOS is an area of work developing specifications and standards to support
> the use of knowledge organisation systems (KOS) such as thesauri,
> classification schemes, subject heading systems and taxonomies within the
> framework of the Semantic Web. 
>
> So I think the hard part is making a SKOS Core vocabulary (which may be an
> abstract) and then deriving
> The specialised owl/rdf models for each of the above KOS.
> If SKOS is only intended for thesauri, this would change the objective.
>
> By the end of the day, as a user I would like to find out:
> - when and how we should use SKOS core,
> - when and how we should a standard extension of SKOS
> - or how to make our own valid SKOS extension. 
>
> Kind Regards,
>    Johan De Smedt
> =================
> johan.de-smedt@tenforce.com
> =================
> -----Original Message-----
> From: public-esw-thes-request@w3.org [mailto:public-esw-thes-request@w3.org]
> On Behalf Of Antoine Isaac
> Sent: Monday, 14 January, 2008 18:26
> To: Simon Spero
> Cc: SKOS; SWD WG
> Subject: Re: AW: AW: [SKOS] Transitive broader and ISSUE-56 (was The return
> of ISSUE-44 )
>
>
> 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.com/login.aspx?
>>     > direct=true&db=aph&AN=6547855&site=ehost-live.
>>     >
>>     >
>>     > Making hierarchical relationships non hierarchical
>>
>>
>>     
>
>
>
>
>   
Received on Tuesday, 15 January 2008 11:36:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:59 GMT