W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2007

Re: Exactly what does broader/narrower mean?

From: Mark van Assem <mark@cs.vu.nl>
Date: Mon, 19 Feb 2007 17:02:26 +0100
Message-ID: <45D9CA12.6040109@cs.vu.nl>
To: Jakob Voss <jakob.voss@gbv.de>
CC: public-esw-thes@w3.org, Sören Auer <auer@informatik.uni-leipzig.de>, Richard Cyganiak <richard@cyganiak.de>


As I see it, SKOS is just meant as a way to _represent_ thesauri, 
classification schemes, glossaries, etcetera.

SKOS itself makes no judgement about what should or should not be a 
broader/narrower, it just represents the decisions made by the 
creators of a vocabulary. So if your vocabulary asserts

     "Rainy day" has subconcept "Sunny day"

it is completely valid to use skos:broader to represent this relation. 
  Whether or not this is a _useful_ statement is something that is 
decided by ontology/terminology/categorization theory, not by SKOS.

If it is ok in your application to see "german politicians" as 
subconcept of "germany" (and for IR applications this can be the case) 
then you should leave it as it is and represent it in SKOS. If it is 
not ok, you should either choose some other vocabulary, or do a 
systematic re-engineering of the vocabulary.


Jakob Voss wrote:
> Hi Richard, hi Sören,
> Looks like the group of people dealing with this aspects of knowledge
> organization is small so there are always the same people ;-)
> You wrote:
>> In Wikipedia, there are often category hierarchies like this:
>>     Germany
>>       |
>>       +-- German politicians
>> Can this be translated to SKOS? 
>> If Germany and German politicians are skos:Concepts, then is there a
>> skos:broader relationship between them?
> Yes - the hierarchical relations between Wikipedia categories are an
> application of SKOS.
>> I'm a bit concerned that one isn't really a sub-topic of the other.
>> To phrase the question differently: Is there a clear test to decide if A
>> skos:broader B? For RDFS class hierarchies it's simple: A
>> rdfs:subClassOf B iff all instances of A are also instances of B. What
>> would be the equivalent rule for SKOS?
> We don't have instances in SKOS but resources that are indexed with
> concepts. The rule in SKOS may be:
> A skos:narrower B if all resources that are indexed with A may also be
> indexed with B.
> The point is that "may also be indexed" is a much more vague constraint
> than beeing an instance also - and it depends on the context of your
> application. You may index all German politicians with "Germany" so
> users will find them when searching for "Germany". But if there are too
> many resources indexed with "Germany" than it's better to select a more
> detailed concept - it just depends on! Alistair presented the semantic
> model of cost expansion to deal with hierarchic relations in skos when
> doing retrieval, but this is only one possible application.
> Do you know Sorites paradox? Consider a heap of sand from which grains
> are individually removed. If you remove a single grain of sand of it, it
> still remains a heap - so you may conclude that a heap may be composed
> by just one grain of sand! This is also the nature of skos:broader: its
> a vague property. This may scare traditional AI fundamentalists, but it
> allows practical usage with real world resources and people with real
> world information needs.
> Greetings,
> Jakob
> For limited Cost Expansions see: Alistair Miles: Retrieval and the
> Semantic Web, page 32ff
> http://isegserv.itd.rl.ac.uk/retrieval/
> For more about Wikipedia category hierarchies see
> Voss: Collaborative thesaurus tagging the Wikipedia way.
> http://arxiv.org/abs/cs/0604036
> The chapter about hierarchical relations in a student paper I wrote in
> 2003 may also be of interest. Today I would not write it in the same way
> but the basics still apply:
> http://eprints.rclis.org/archive/00007589/, page 28.

  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Monday, 19 February 2007 16:03:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:38 UTC