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

RE : [SKOS] thesaurus USE patterns

From: Antoine Isaac <Antoine.Isaac@KB.nl>
Date: Wed, 14 Feb 2007 14:41:56 +0100
Message-ID: <68C22185DB90CA41A5ACBD8E834C5ECD039A1F31@goofy.wpakb.kb.nl>
To: "Jakob Voss" <jakob.voss@gbv.de>, <public-esw-thes@w3.org>
Hi,

> De: public-esw-thes-request@w3.org de la part de Jakob Voss
> Date: mer. 14/02/2007 13:35
> : public-esw-thes@w3.org
> Objet : Re: [SKOS] thesaurus USE patterns
>
>
> 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.
> TR : [SKOS] thesaurus USE patterns -------- Message d'origine--------

Well, I also see some practicalities in allowing what you say in the end. But for now, from a requirement perspective it's a different issue to know whether we are representing a single CS or links between different ones.

> >> 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'?

Could be interesting, yes, though one could still argue that they are still subjects in some non-updated database...
However that's a different issue, that I will try to keep in mind for later

>
> >> 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).

I had that concern in mind when I wanted to draw a line between the old coordination and the 'composition' requirement. But in the end for the moment I prefer to keep the problem simpler...

>
> > 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"

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...


>
>
> >> 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".

Yep.

Cheers,

Antoine

[1] http://www.w3.org/2006/07/SWD/wiki/EucUDC
Received on Wednesday, 14 February 2007 13:42:57 GMT

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