RE: UMTHES and SKOS-XL

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  <mailto:> abuse"@en .
:childAbuse ev:permutedLiteralForm "abuse,  <mailto:> child"@en .
For this, the EUROVOC publishing service generating SKOS will generate in
addition
:C skos:prefLabel "child abuse"@en <mailto:>  .
:C skos:hiddenLabel "abuse, child"@en <mailto:>  . 
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