Re: UMTHES and SKOS-XL -- representing variants of terms as labels

Hi Thomas, Johann,

Thanks for the interesting Eurovoc examples!

In fact the practice that Johann uses for Eurovoc is closer to what the SKOS documentation suggested. All variants of a "term" end up being represented as some form of labels, and "lexical" links such as acronyms occur between instances of xl:Label.
It may well be the case that some of the fine-grained information that Thomas is referring to (ie, whether a "permuted form" is obtained from a given term or another) may be lost. But well, that's not what SKOS-XL is about, and if Johann's scenario is also not about exchanging that kind of information, why bother?

Note that this does not prohibits devising fine-grained extension to capture that kind of thing, and, importantly, all variants of a term may not end up being represented as labels (this, to answer Thomas' question on UMTHES case). As long as this is a conscious decision from the KOS' publisher (and especially if it is documented somewhere!), we should perfeclty be able to live with that. If you don't want something like "wastewaters" to be used as a label (even a hidden one) for the concept with "waste water" as prefLabel, then I don't see why you should be forced to do so.
You both say 
> I see SKOS primarily as an exchange format not as a maintenance format.
and 
> As far as I see: you have the choice, it is not SKOS who makes the decision ;-)

These are both perfectly valid statements in that case. We can only provide constructs, and present some practices we think are good, but in the end the appreciation of what should be represented as a label in such an exhange format (whether standard SKOS or SKOS-XL) is left to KOS publishers, who are assumed to know better the nature *and potential use* of what they publish. 

Cheers,

Antoine



> Hi Thomas,
>  
> Please find in-line and prefixed with ">>JDS-2:" clarifications on your 
> added questions.
> In the examples, "ev:" stands for the EUROVOC schema prefix.
>  
> 
> kr, Johan De Smedt.
> ===================
> 
>  
> 
> ------------------------------------------------------------------------
> *From:* Thomas Bandholtz [mailto:thomas.bandholtz@innoq.com]
> *Sent:* Sunday, 25 October, 2009 20:13
> *To:* Johan De Smedt
> *Cc:* 'SKOS'; 'Antoine Isaac'
> *Subject:* Re: UMTHES and SKOS-XL
> 
> Hi Johan,
> 
> some considerations inline:
> 
> [skip]
>> I see SKOS primarily as an exchange format not as a maintenance format.
> 
> This is a very important issue. I used to see SKOS purely as an exchange 
> format either, but since LOD I understand skosified reference 
> vocabularies as an important building block at runtime. This does not 
> constrain maintenance to anything else than the vocabulary has to be 
> serializable in SKOS so that it will meet the expectations of a SKOS 
> aware application.
> 
>> Users of the EUROVOC thesaurus maintenance system manage permuted 
>> literals as properties of preferred or alternate xl:Labels.
>> Hence:
>> - the genuine managed labels are ok to have a URI that can later be 
>> used in an LOD or SPARQL service interface
>> - permuted literal forms do not have this quality
>> However, when making a SKOS compliant publication, the hidden label 
>> has relevance (as search value)
>> Hence EUROVOC publishes for a skos:Concept :C
>> - :C xl:prefLabel :ptC; xl:altLabel :nptC; skos:hiddenLabel "permuted 
>> literal form of C" .
>> - :ptC xl:literalForm "PT of C" .
>> - :nptC xl:literalForm "nPT of C" .
>> I think this is compliant with SKOS(XL) - comment is welcome.
> 
> I don't see any reason why this should not be compliant with SKOS. But 
> it may not express your semantics:  
>> >JDS-2: indeed, not all semantics are expressed that is what I try to 
> explain below..
>  You provide prefLabel and altLabel with XL, but hiddenLabel in plain 
> SKOS, so how will you express that some permuted literal form refers to 
> one of the labels? A Concept by itself has no literal form, so i do not 
> understand how it may have a permuted literal form. Is there exactly one 
> permuted literal form per Concept or per Label?
> Could you give an example?
>  >>JDS-2: example:
> C stands for the concept with preferred term "child abuse"
> :C xl:prefLabel :childAbuse
> :childAbuse xl:literalForm "child abuse"@en <mailto:"child abuse"@en> .
> :childAbuse ev:permutedLiteralForm "abuse, child"@en <mailto:"abuse, 
> child"@en> .
> For this, the EUROVOC publishing service generating SKOS will generate 
> in addition
> :C skos:prefLabel "child abuse"@en <mailto:"child abuse"@en> .
> :C skos:hiddenLabel "abuse, child"@en <mailto:"abuse, child"@en> . 
> This is based on the following two (informally noted) rules that go with 
> the EUROVOC schema
> - A chain xl:prefLabel([Concept][Term]) o 
> ev:permutedLiteralForm([Term][literal]) → 
> skos:hiddenLabel([Concept][literal]) .
> - A chain xl:altLabel([Concept][Term]) o 
> ev:permutedLiteralForm([Term][literal]) → 
> skos:hiddenLabel([Concept][literal]) . 
>>  
>> The details of why
>> - :nptC is an an alt label
>> - "permuted literal form of C" is a permuted label
>> can be found in the equivalence relationships (simple or compound) or 
>> in the permuted literal forms of either :ptC or :nptC.
>> This is expressed in the EUROVOC specific SKOS extension (and thus 
>> requires knowledge of the owl schema beyond
>> the formal OWL expressions - i.e. the documentation that goes with the 
>> schema).
> 
> I understand that "ptC" stands for "preferred term of a Concept" and 
> "nptC" for "non-preferred term of a Concept", right?  >>JDS-2: yes. 
> The basic ISO equivalence relationship is "preferredTerm USED FOR 
> non-preferredTerm" with inverse "non-preferredTerm USE preferredTerm".
> There is no such construct in SKOS. A SKOSXL Label cannot be preferred 
> or not by itself, it only depends on how it is linked to a Concept 
> (pref/altLabel).
> (see an example below ...)
> Guess that is the reason why you have a EUROVOC specific SKOS extension 
> (which we don't know so far).
> I wonder how you express "permuted literal forms of either :ptC or 
> :nptC", when the permuted literal form is a rdf:Literal? 
>> >JDS-2: an xl:Label may have an arbitrary number of 
> ev:permutedLiteralForm.  This is a data property (like xl:literalForm).
>> >JDS-2: in contrast though, ev:permutedLiteralForm has no cardinality 
> constraints.
>> >JDS-2: further, for any xlLabel :L, its property xl:literalForm and 
> all its ev:permutedLiteralForm must have the same language. 
> This might be a special case, but xs:labelRelation is intended to point 
> to a xl:Label instance, not to a Literal.
> 
> 
>> The selection of something being a PT or an nPT or a permuted label is 
>> up to the thesaurus maintenance/management.
>> It is not always obvious if either an acronym ("OWL") or the full name 
>> ("Web Ontology Language") will be used as PT
>> in a real world thesaurus.  (Like considerations apply for other label 
>> relations)
>> However, once a name is selected as the PT, the related labels are 
>> likely (mandatory?) candidates for nPT or hidden labels.
>>  
>> As there currently is no SKOS extension capturing such label 
>> relations, we now discuss on which approach to take.
>> I would advocate that for some of the work done on the ISO 
>> standardization, it may be worthwhile to do some RDF
>> standardization effort in the future.
>> Possible candidates are:
>> - Concept groups
> 
> What is the difference from a skos:Collection? 
>> >JDS-2: group means any subset of concepts while collections where 
> aimed to represent "node labels" and "facets".
>> >JDS-2: I think Stella and Antoine are better placed to respond to this 
> accurately. 
> 
>> - Equivalence relationships (simple and compound)
> 
> SKOS only has altLabel prefLabel relations from a Concept to a Label.
>  From this arises the question whether the same Label my be pref of one 
> Concept and alt of another?
> Would this be compliant? Yes (may be not intentionally).
> 
> S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise 
> disjoint properties."
> S14: "A resource has no more than one value of skos:prefLabel per 
> language tag."
> 
> These only keep you from saying something like:
> 
> <Love> skos:prefLabel "love"@en ; skos:prefLabel "adoration"@en .
> 
> or
> 
> <Love> skos:prefLabel "love"@en ; skos:altLabel "love"@en .
> 
> But the following is compliant:
> 
> <A> skos:prefLabel "love"@en ; skos:altLabel "adoration"@en .
> <b> skos:prefLabel "adoration"@en ; skos:altLabel "love"@en .
> 
> Or even more evident in XL:
> 
> <A> skosxl:prefLabel :love; skosxl:altLabel :adoration .
> <B> skosxl:prefLabel :adoration ; skosxl:altLabel :love .
> :love skosxl:literalForm "love"@en .
> :adoration skosxl:literalForm "adoration"@en.
> 
> SKOS pref/alt of a label is only known in the context of a given 
> Concept, while
> ISO pref/nonPref is bound to a given label (~term).
> Right? 
>> >JDS-2: I agree and this makes ISO Thesaurus semantics more strict than 
> SKOS (as you demonstrate in the example below). 
> 
> If you want to have ISO equivalence in SKOS you may express something like:
> 
> prefTerm subClassOf xl:Label .
> nonPrefTerm subclassOf xl:Label .
> prefTerm disjointWith nonPrefTerm .
> 
> xl:prefLabel range prefTerm .
> xl:altLabel range nonPrefTerm . 
>> >JDS-2: I do not follow with these last 2 rules as they would redefine 
> SKOS-XL.
>  
>> >JDS-2: Instead we define ev:EquivalenceRelation relating a prefTerm 
> and a nonPrefTerm using properties ev:use and ev:uf respectively.
>> >JDS-2: ev:use and ev:uf do have range prefTerm and nonPrefTerm 
> respectively.
>> >JDS-2: then we say that :C xl:altLabel :nptC is entailed by:
>> >JDS-2: :C xl:prefLabel :ptC.
>> >JDS-2: :eqr rdf:type ev:equivalenceRelation ; ev:use :ptC ; ev:uf :nptC. 
> 
> usedFor subPropertyOf xl:labelRelation;
>     domain prefTerm;
>     range nonPrefTerm;
>     inverseOf use .
> 
> and then:
> 
> love  a prefTerm;
> adoration a nonPrefTerm;
> love usedFor adoration.
> 
>> Obviously, the industry may find the schema provided in the ISO 
>> standard (UML/XML) sufficient.
> 
> ? I do not really understand this. 
>> >JDS-2: I mean the ISO standard went a long way:
>> >JDS-2: The BS preparing it defined an XML schema for Thesauri. 
>> >JDS-2: This covered more than SKOS (this statement is scoped to 
> thesaurus).
>> >JDS-2: In addition a model was defined using the Unified Modeling 
> Language (UML).
>> >JDS-2: Likewise this model has more specific thesaurus artifacts. 
> 
> -- 
> Thomas Bandholtz, thomas.bandholtz@innoq.com, http://www.innoq.com 
> innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
> Phone: +49 228 9288490 Mobile: +49 178 4049387 Fax: +49 228 9288491

Received on Monday, 9 November 2009 14:03:40 UTC