RE: UMTHES and SKOS-XL

Hi Thomas, 
 
Thanks for the references, analysis and explanation.
You did not miss anything.
However, I want to iterate on some practical considerations
 
I see SKOS primarily as an exchange format not as a maintenance format.
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.
 
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). 
 
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
- Equivalence relationships (simple and compound)
Obviously, the industry may find the schema provided in the ISO standard
(UML/XML) sufficient.
 


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

 

  _____  

From: Thomas Bandholtz [mailto:thomas.bandholtz@innoq.com] 
Sent: Sunday, 25 October, 2009 15:23
To: Johan De Smedt; Johan De Smedt; SKOS
Cc: 'Antoine Isaac'
Subject: Re: UMTHES and SKOS-XL


Hi Johan & Antoine,

from the SKOS point of view, the structure of your ev:permutedLiteralForm is
very similar to that of umthes:lexicalVariant.
As both are defined as local datatype properties of skosxl:Label, the
property chain S57 will not work:

S57:      "The property chain (skosxl:hiddenLabel, skosxl:literalForm) is a
sub-property of skos:hiddenLabel."

You are right, OWL 2 introduces property chains for owl:ObjectProperty but
not for owl:DatatypeProperty. See 
http://www.w3.org/TR/2009/WD-owl2-new-features-20090611/#F8:_Property_Chain_
Inclusion

There has been some discussion about "formal expression of property chains"
in the skos list, but no final clarification. See
http://lists.w3.org/Archives/Public/public-esw-thes/2009May/0003.html

I think that Antoine's draft in
http://lists.w3.org/Archives/Public/public-swd-wg/2009Mar/0043.html and
is not valid OWL2 because he refers to datatype properties.

There are some valid examples in the OWL 2 primer, for instance:

 <rdf:Description rdf:about="hasUncle">
   <owl:propertyChainAxiom rdf:parseType="Collection">
     <owl:ObjectProperty rdf:about="hasFather"/>
     <owl:ObjectProperty rdf:about="hasBrother"/>
   </owl:propertyChainAxiom>
 </rdf:Description>

To me it is not really clear why this pattern is restricted to object
properties in OWL 2, but it is.

Anyway, given that S57 is valid, ev:permutedLiteralForm and
umthes:lexicalVariant would need to be remodelled as xl:literalForm of some
xl:Label, with some additional ev:hasPermutedLiteralForm subproperty of
xl:LabelRelation. Then you can point from the Concept to the permuted from
using xl:hiddenLabel. Something like:

# no hiddenLabel in this example
:123 rdf:type skos:Concept;
    skosxl:prefLabel :ABC.

:ABC rdf:Type skosxl:Label;
    skosxl:literalForm "Something";
    jv:permutedLiteralForm "permuted form of Something".

would need to be modified as in the next example:

# using hiddenLabel and a subproperty of skosxl:labelRelation 
:123 rdf:type skos:Concept;
    skosxl:prefLabel :ABC;
    skosxl:hiddenLabel :ABCperm.

:ABC rdf:Type skosxl:Label;
    skosxl:literalForm "Something".

:ABCperm rdf:Type skosxl:Label;
    skosxl:literalForm "permuted form of Something".

:ABC: jv:hasPermutedLiteralForm :ABCperm.

Looks a bit complicated, but this is how I read the SKOS specification, and
Antoine pointed to this in a previous mail.
I am still not decided whether to go this way for umthes:lexicalVariant. 

May be these properties just don't need to be hiddenLabels.
Definition of skos:hiddenLabel: 
"A lexical label for a resource that should be hidden when generating visual
displays of the resource, but should still be accessible to free text search
operations."

Doesn't seem to be very clear: free text search operations may access
literal values of any property, but a SPARQL query restricted to rdfs:label
(including subs) wouldn't.
As far as i see, this would be the only consequence.
Did I miss something?

Kind regards,
Thomas


Johan De Smedt schrieb: 

Hi Thomas,
 
The permuted label is managed by the EUROVOC editors.
ev:permuted LiteralForm is a data property on an xl:Label
For each xl:Label/xl:literForm, any number of label permutations may be
provided.
 
On export from the maintenance system, these permutations are made available
as skos:hiddenLabel by the export service,
So a skos:Concept that has an xl:Label either as an xl:prefLabel or an
xl:altLabel, and that xl:Label has permuted
literal form results in a skos:hiddenLabel for each of those permuted
literals.
(cfr the importRule annotation)
[
We could have defined property chains like
- skos:hiddenLabel (xl:prevLabel o ev:permutedLiteralForm)
- skos:hiddenLabel (xl:altLabel o ev:permutedLiteralForm)
But I think OWL2 only provides property chains on object properties (please
correct if I am wrong here !)
]

[
Would it make sense to make ev:permutedLiteralForm an annotation property ?
]
 
We chose this approach because:
- The skos:hiddenLabel semantics are less precise as what is intended by the
EUROVOC maintenance and aditorial team
  when handling "permutations".
- We still wanted users/application only using SKOS/XL and the EUROVOC
extension (so not interpreting the semantics 
  of permuted literal form) to be able to search using any of the permuted
literal values.
- In the back office permuted labels are not managed as "controlled
vocabulary" entities, but rather as properties of the original labels.
  We felt it was not up to the export service to "create" entities/resources
but to reuse the managed resources/literals
  when providing the closest possible SKOS equivalent.
 
Thanks for your remarks.
 
about PS:
- We still are working on the final form of the documentation.
  but making these considerations public is OK as that will only help to
establish best practices an to improve inter-operability.
 
kr, Johan De Smedt.
=================== 
 

  _____  

From: Thomas Bandholtz [mailto:thomas.bandholtz@innoq.com] 
Sent: Saturday, 24 October, 2009 23:45
To: Johan De Smedt
Cc: Antoine Isaac; Stella Dextre Clarke; 'Bernard Vatant'
Subject: Re: UMTHES and SKOS-XL


Hi Johan,

looking closer, i see one most interesting detail:

eurovoc.owl has one extended owl:DatatypePoperty(!) of xl:Label named
ev:permutedLiteralForm.
This is formally similar to umthes:lexicalVariant: both are not subclasses
of xl:Label connected by a subProperty of xl:labelRelation.
So there exists no property chain that would infer that both would appear as
skos:hiddenLabel instances towards a search agent.

Generally i have my doubt that such a property chain would work in practise
today, it has not even been formalized ...
Anyway, when i read your rdfs:comment about ev:permutedLiteralForm i am not
sure about your intention:

"This property provides a permuted search string for the label.
It is:
- Generated by the back-office system, based on the literal form of the SKOS
preferred or alternate label.
- Provided as a hidden SKOS label. {@en}"

When you declare ev:permutedLiteralForm as a owl:DatatypePoperty of
xl:Label, this will not infer to any appearance among the skos:hiddenLabel
instances. Is this only an oversight or some so far not yet unresolved
conflict of your model?

In other words: do you want the permutedLiteralForm  to appear as one of the
hiddenLabels?

As far as I see: you have the choice, it is not SKOS who makes the decision
;-)

Looking forward to further discussion.

Best,
Thomas




-- 

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