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

Qualifiers and non-indexing-concepts

From: Jakob Voss <jakob.voss@gbv.de>
Date: Wed, 14 Feb 2007 16:13:00 +0100
Message-ID: <45D326FC.3080703@gbv.de>
To: public-esw-thes@w3.org

Antoine Isaac wrote:

>> Well, I was not thinking about qualifiers but it may be another
>> case where USE occurs in practise. Let's have for instance:
>> 
>> #c1  skos:prefLabel  "C (letter)
>> #c1  skos:altLabel   "C"
>>
>> #c2  skos:prefLabel  "C (programming language)" 
>> #c2  skos:altLabel   "C"
>>
>> #c3  skos:prefLabel  "Vitamine C" 
>> #c3  skos:altLabel   "C"
>> 
>> Then your interface could create
>> 
>> "C": USE "C (letter)" OR "C (programming language)" OR "Vitamine C"
> 
> I would also consider this as a valid use of altLabel leading to a
> same term. Notice however that this was not the kind of 'qualifier' I
> was refering too (though I agree I would also use qualifier for this,
> can somebody help us?). I wanted to refer to the conceptual bits that
> you append to a concept to build a complex one, like the -23 'special
> auxiliary' in UDC [1]. Something like conceptual qualifier vs lexical
> qualifier...

Yes, we don't have a strict definition of "qualifier" yet. Note that
there are always several ways and it heavily depends on the application
how to encode complex concepts:

1. You can model it without any qualifiers and implicit USE:

#c1 skos:prefLabel "Nuclear meltdown".
#c1 skos:altLabel  "Meltdown".
#c2 skos:prefLabel "Artic Meltdown".
#c2 skos:altLabel  "Meltdown".

2. You can model it with lexical qualifiers:

#c1 skos:prefLabel "Meltdown (nuclear reactor)".
#c1 skos:altLabel  "Meltdown".
#c2 skos:prefLabel "Meltdown (ice)".
#c2 skos:altLabel  "Meltdown".

3. You can model it with hierarchic skos relations:

#c1 skos:broader #meltdown.
#c2 skos:broader #meltdown.
#meltdown skos:prefLabel "Meltdown".

4. You can use coordinations (not specified yet):

#c1 skos:coordination { #meltdown #nuclear-reactor }.
#c1 skos:coordination { #meltdown #ice }.

*Semantically* the "conceptual bits that you append to a concept to
build a complex one" should not be different to "simple" coordination of
concepts that you can also use independently (like the #nuclear-reactor
and #ice in case 4). The "-23 'special auxiliary' in UDC" is also an
skos:Concept. But it should not be directly used for indexing. How about
several types of 'non-indexing concepts'?:

skos:NonIndexingConcept rdfs:subClassOf skos:Concept.
skos:Qualifier rdfs:subClassOf skos:NonIndexingConcept.
skos:DeprecatedConcept rdfs:subClassOf skos:NonIndexingConcept.

Here skos:NonIndexingConcept is a Concept that should not be used for
new indexing - indexing applications should give warning or not allow
users to create new statements if:

?d skos:subject ?s. and ?s rdf:type skos:NonIndexingConcept.

but retrieval applications should be able to deal with them. In Detail

skos:DeprecatedConcept

should be disallowed and

skos:Qualifier should be allowed in coordination only (This restrictions
can easily be specified formally).

Special vocabularies may create subclasses of skos:Qualifier with
additional restrictions, for instance allowing special types of
qualifiers only in combination with special other types of concepts.

Greetings,
Jakob
Received on Wednesday, 14 February 2007 15:13:06 GMT

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