RE: Label management information in SKOS-XL (continuing from UMTHES and SKOS-XL)

Hi Christophe, I provided some in-line considerations
 
nice evening


kr, Johan De Smedt.
=================== 

 

  _____  

From: Christophe Dupriez [mailto:christophe.dupriez@destin.be] 
Sent: Wednesday, 04 November, 2009 22:06
To: Johan De Smedt
Cc: 'Thomas Bandholtz'; 'SKOS'; 'Antoine Isaac'; Dominique Vanpée
Subject: Label management information in SKOS-XL (continuing from UMTHES and
SKOS-XL)


Hi!

It was asked to me today how I will keep track of a label source (and other
management information) in SKOS... 
>>>JDS-3: dc:source applied would seem a nice candidate
Hopefully SKOS-XL reifies labels.

Looking at ISO 25964, I have:
Attributes of ThesaurusTerm:
LexicalValue String      1 The wording of the term
identifier   String      1 A unique identifier for the term
created      date     0..1 The date when the term was created
modified     date     0..1 The date when the term was last modified
source       String   0..1 The person(s) or document(s) from which the term
was taken
Status       String   0..1 Indication of whether the term is candidate,
approved, etc.
lang         language 0..1 A code showing the language of the term. This
should be
                           included if the thesaurus supports more than one
language

The subject may be touchy but one could like to see a standardized way to
have SKOS / ISO 25964 interchangeability
(something like an SKOS/ISO application profile) .

This would allow:
1) An ISO 25964 thesaurus editor could unload/reload using SKOS files
without information losses. 
>>>JDS-3: I think it is feasible to write a SKOS extension that captures the
formal model of the ISO standard.
>>>JDS-3: on an earlier version of SKOS-XL, I made an exercise some time ago
to cover the BS8723 (which was input for the ISO standard)
>>>JDS-3: note this exercise was never discussed on any forum yet 
2) Exchanges between different ISO 25964 thesauri could be done using the
SKOS format.
3) SKOS aware applications could support ISO 25964 "extensions" without
parameterization to indicate which RDF attributes contains the supplementary
ISO data.
4) SKOS would benefit from the insights of ISO 25964 design team. 
>>>JDS-3: I support these considerations.  It would provide a formal
guideline for SKOS - ISO thesaurus transformation.

There is a rather striking difference between SKOS flexibility and
extendability (opening ways to unstandardized horizons) and ISO willingness
to build upon the past within a stricter frame.

What I am suggesting is to check (and to normalize somewhat) how the
complete data model of ISO can be mapped in SKOS(-XL).

By the way, labels reification opens the way to write labels which are
written from multiple coordinated concepts.
A reified label of a coordination concept could include an rdf:Seq.
This rdf:Seq would contain strings and/or refers to (reified) labels from
the different coordinated concepts and/or refers to coordination operators
(conjunctions).
This could generate a dynamic literalForm based on the labels of the
differeent coordinated concepts.

Have a nice evening,

Christophe


Johan De Smedt a écrit : 

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