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

Yes, Osma, indeed, skosxl:altLabel properties are sufficient to express the
relationship between the ambiguous term and the differentiated concepts,
since inferencing is not necessary. I thought of a custom structure in the
case we want to retain automated duplicate checks, and the  machine has to
distinguish between "normal" skosxl:altLabel and these sort of term
entries. The machine could then generate a sort of "disambiguation prompt".

Jutta




2014-04-23 10:05 GMT+02:00 Osma Suominen <osma.suominen@helsinki.fi>:

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



-- 
Jutta Lindenthal
Mecklenburger Landstraße 5
23570 Lübeck
Tel.: 04502-8809421