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

Re: [SKOS] thesaurus USE patterns

From: Jakob Voss <jakob.voss@gbv.de>
Date: Wed, 14 Feb 2007 13:35:03 +0100
Message-ID: <45D301F7.4020402@gbv.de>
To: public-esw-thes@w3.org

Antoine Isaac wrote:

>> USE X + Y and USE X OR Y is semantically related to:
>>
>> SKOS-R-ConceptualMappingLinks
>> (http://www.w3.org/2006/07/SWD/wiki/CandidateReqList)
>>
> Not really: SKOS-R-ConceptualMappingLinks is about links between
> concepts from different concept schemes. Here we have:
> - elements from a same CS
> - elements that are not at the same modeling level: X, Y are more like
> concepts (in SKOS, prefLabel univovally associated to their
> skos:Concept) and Z is an alternative term, never used as a subject or
> in a subject, so not a candidate for a concept.

Why should skos:broader/narrower be limited to concepts from the same
concept scheme? If we want such a restriction then it needs to be
mentioned in

http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RdfsSemanticExtension

but I don't see the advantage of it. The second point is right - "Z" is
not a concept but a term and currently skos does not allow it to be a
subject - but the whole USE-relationship is about terms anyway.

>> SKOS-R-IndexingAndNonIndexingConcepts.
>> (http://www.w3.org/2006/07/SWD/wiki/CandidateReqList)
>>
> Neither. But here you were tricked by my poor wording. 'non-indexing
> concepts' refers to conceptual entities, that is things that could be
> converted into kind skos:Concepts (they are essentially of conceptual
> nature, they have labels/captions as well as BT/NT/RT links), but which
> cannot be used alone as subjects for a document (which would somehow
> undermine the range assertion for skos:subject).
>
> Typical examples appear in coordinated languages (e.g. UDC, LCSH), which
> propose a range of auxiliaries/qualifiers used to narrow down the
> meaning a another concept which will be the main subject of a document.

But deprecated or unusual concepts could be another application. Up to
now there is no official way how to encode deprecated concepts so why
not using the 'non-indexing concepts'?

>> SKOS-R-ConceptComposition
>> (http://www.w3.org/2006/07/SWD/wiki/CandidateReqList)
>>
> I agree with this link you make between this USE+ and
> SKOS-I-Coordination, since  the + and OR features of this issue
> explicitly call for some sort of coordination.

You have to define the semantics of "+" in "USE X + Y" - as far as I
understand it's the semantic of coordination (although you may differ
between precoordination and postcoordination - "+" is probably
postcoordination).

> And as said in my other mail [1], I also agree with the link you make
> between  SKOS-I-coordination-8 and SKOS-R-ConceptComposition, even if
> the consequence was not the one you foresaw perhaps ;-)

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"


>> Implementation:
>>
>> Say you have the statement "Z" USE "X + Y", then:
>>
>> 1. "Z" is a NonIndexingConcept
>> 2. "X + Y" is a coordination/composition of Concepts
>> 3. the "USE"-statement is a Mapping
>>
> Well, what I said about non-indexing concepts and mapping would invalid
> this view.
>
> Indeed I think we should go for a simpler solution, using altLabel:
> 1. "X + Y" is a coordination
> 2. "X + Y" skos:altLabel Z

You are right - that's the way.


>> The "Z USE X OR Y" stament does not need special treatement neither:
>>
>> a) Either you define two concepts "X" and "Y" with alterative Label "Z"
>> b) Or you define "X", "Y" as Concepts, "Z" as a NonIndexingConcept and a
>> Mappings between "Z" and "X" and "Z" and "Y"
>>
> I think I definitevely favor the first solution (actually your two
> solutions actually differ in the status you give to Z, and not really
> the way you (don't) deal with coordination issues). This way of doing
> would mirrors my natural interpretation of altLabel (and USE/USED FOR).
> But I think we would need expert's advice on that.

It also depends on whether we want explicit "USE" or implicit. Up to now
the "Z USE X OR Y" should be implicit with altLabel "Z" (or another
label-property, I'm not lucky with the current prefLabel/altLabel
solution) and the "Z USE X+Y" is explicit with coordination of "X+Y" and
altLabel "Z".

>> Voilą!
>>
> Thanks for the help, by the way!

This is teamwork in progress :-)

Greetings,
Jakob
Received on Wednesday, 14 February 2007 12:34:56 GMT

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