Re: Fwd: [NISO iso25964] FW: Representing USE-OR in SKOS/XL/ISO25964

Thanks Jutta for your thoughts. I hope you don't mind me Cc'ing 
public-esw-thes so your message gets recorded there as well.

Indeed using the SimpleNonPreferredTerm would be similar to my original 
example 1 (using only SKOS Core altLabels) but using SKOS XL and 
iso-thes, and also similar to what Johan suggested to use, but custom 
structures (classes and/or properties) could be use to guide the user to 
the correct ones - although, I think the (inverse) skosxl:altLabel 
properties could already be sufficient to express the relationship 
between the ambiguous term and the differentiated concepts.

-Osma


On 23/04/14 10:42, Jutta Lindenthal wrote:

> Hi Osma and Johan,
>
>
> I think compound equivalence (1) and disambiguation of homographs (2)
> cover two different situations:
>
> (1) A complex concept, represented through a SplitNonPreferredTerm (e.g.
> "football pitch"), is split into two concepts for indexing (e.g.
> "football"; "sports field"), and post-coodinated retrieval (e.g.,
> "football" AND "sports field").  Thus, CompoundEquivalence enables "the
> representation of complex concepts by a combination of terms"
> (ISO-25964-1).
>
> (2) A homograph (e.g., "pitch") has to be disambiguated for the sake of
> retrieval precision, and usually is not a compound (since compounds tend
> to be differentiated and thus are less likely to be ambiguous). Instead,
> one could think of the homographic term as a lead-in entry analogue to
> dictionaries. In this sense the homograph provides an entry for indexing
> and retrieval to choose between disjoint concepts. This is what you have
> in mind, I think (e.g.
>
> (ex) pitch
> 1 "sports field", skos:altLabel "pitch (sports)"
>
> 2 "pitch (sound)"
>
> 3 "pitch (steepness)
> ...
>
> (1) provides a lead-in term in order to be combined by an AND-operator,
> wheras (2) would function as a lead-in-term which offers mutually
> exclusive terms (exclusive OR) for indexing and retrieval. Therefore,
> and as Johan already elaborated, the CompoundEquivalence does not appear
> to be suited for (2).
>
> Perhaps one could treat (ex) as
> http://purl.org/iso25964/skos-thes#SimpleNonPreferredTerm, allowing for
> identifiers etc., and define a custom class that guides the user to two
> or more distinct concepts.
>
> Actually, I am not happy with the ISO modelling of CompoundEquivalence
> via terms instead of concepts.
>
> Best regards,
>
> Jutta


-- 
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Teollisuuskatu 23)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi

Received on Wednesday, 23 April 2014 08:05:52 UTC