- From: Osma Suominen <osma.suominen@helsinki.fi>
- Date: Wed, 23 Apr 2014 11:05:23 +0300
- To: Jutta Lindenthal <jutta.lindenthal@gmail.com>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>
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