Comments on iso-thes-25964.owl

I find these presentations very useful in illustrating the ISO standard’s mapping to RDF:

 

·         <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/ISO25964-mapping-to-SKOS-XL.pptx> Exchanging ISO 25964-1 thesauri data using RDF, SKOS and SKOS-XL (Johan De Smedt,  <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/programme2012.html> NKOS 2012)

·         <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/TPDL2012_NKOS_Ambiguities.pptx> Ambiguities in representing thesauri using extended SKOS - examples from real life (Jutta Lindenthal,  <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/programme2012.html> NKOS 2012)

·          <http://www.iskouk.org/conf2013/abstracts.htm#Lindenthal> Building better controlled vocabularies- Guidance from ISO 25964 (Jutta Lindenthal and Detlev Balzer, ISKO UK 2013)

 

Johan, thanks for the ontology iso-thes-25964.owl that you posted on Sep 30! 

The work follows the mapping ideas from the NKOS 2012 workshop. In particular, your presentation explains your reasoning for the OWL schema, so is excellent extra documentation. 

I provide some comments below: I hope we can resolve them quickly, please let me know how I can help.

 

Disagreements with the Ontology

* This file should not define any DC/DCT classes/properties! It should just import them. Particular wrong declarations:

* dcterms:type is declared both owl:AnnotationProperty and owl:ObjectProperty
* dcterms:Agent is declared a owl:NamedIndividual and dcterms:AgentClass

* rdfs:label is used for ThesaurusArray and ConceptGroup, and one needs to attach provenance to rdfs:label using owl:Axiom annotations (similar to rdf:Statement reification only worse because IMHO fewer people know them). This means we need to use 3 different ways of representing "text with provenance": skosxl:Label for concept labels, typeless node+rdf:value for notes, and rdfs:label+owl:Axiom for array and group labels. Such spurious differences are very bad! Exporters will make mistakes, exporters need to make more complex scripts, and system vendors need to cater to yet another representation.

* Furthermore, in this representation arrays & groups can't have the pref/altLabel distinction. True, the ISO model talks only about a single label, but what if a particular thesaurus has the odd altLabel for an array?
* Despite what ISO thinks, arrays are NOT so different from concepts: they're both nodes in a hierarchy. Eg at the Getty, Guide Terms quite often evolve into concepts.
* Therefore, I suggest you use the same representation as for Concepts: skos:prefLabel or skosxl:prefLabel (and optionally altLabel)

* iso-thes:isMemberOfGroup has wrong label "superOrdinate"
* Don't declare iso:subGroup and iso:superGroup as transitive. This makes it hard for an application to find the immediate children and draw the group hierarchy.
Also, the definition "All members of the (object) subGroup are members of the (subject) group" means that a concept needs to have isMemberOfGroup not just to its immediate group(s) but also all their ancestor groups. 

* This increases isMemberOfGroup instances greatly and unnecessarily, makes it hard to find the immediate groups, and you'd need to declare a property chain between isMemberOfGroup and superGroup.
* skos:member is not transitive, why should these properties be transitive?

* The definition of iso:subordinateArray says "... or by concepts that need not be narrower terms (facet organization)... Though each array only contains sibling concepts, no hierarchical relation may be derived between a Concept and the the Concepts in any of its subordinte Arrays". This is counter-intuitive: how can siblings NOT have the same parent? How do you define "siblings" then, and the distinction between ThesaurusArray and ConceptGroup? Also, there are 2 typos ("the the" and "subordinte")
* In the above definition re array, you say "facet organization". But Jutta and Detlev give a lot of examples where a Facet is modeled as ConceptGroup. Is there a STRICT definition to let us pick reliably between ThesaurusArray and ConceptGroup?
* Better define the domain and range of iso:superOrdinate (don't just rely on owl:inverseOf)

Disagreements with ISO

Forgive me for disagreeing with a standard. Please note that I don't have access to the full standard, so I'd be much indebted if you explain whether I am wrong.

* The split term "adopted children" is depicted on Slide 16 of your presentation as altLabel (iso:splitAltLabel) of "child" and "adoption". But I think that's NOT a label of either concept "children" nor "adoption": it's the label of a compound pre-coordinated concept (narrower than both "children" and "adoption"). So I think the property iso:splitAltLabel should be removed, or renamed and NOT made a sub-property of altLabel.
* I think that the class iso-thes:PreferredLabel is an overkill, and  the name "PreferredLabel" can be misleading in some cases. It's conceivable that:

* One of the terms involved in a compound equivalence is not the prefLabel of its concept (eg Getty uses plurals so the prefLabel would be "children" but for linguistic reasons one may want to use the altLabel "child")
* The same xl:Label is prefLabel of one concept but altLabel of another.

* iso:plusUse conjoins the two "atomic" terms with symmetric (AND) semantics. But sometimes this is not enough: you may need to know which is the focus (main term) and which are modifiers. Soergel gives such examples in his review of AAT, eg in the compound concept "gilded engraved wooden chair": "chair" (object type) is the focus, and the rest (materials and techniques) are modifiers. Sometimes the semantics may depend on this, eg "logic of nature" vs "nature of logic"

Disagreement with SKOS

* Jutta and Detlev make a good case that only BTG and BTP should be transitive, but not BTI nor mixed chains of BTG and BTP. Since BTG, BTP, BTI are all modeled normally as skos:broader, this means that skos:broader should not always contribute to skos:broaderTransitive. 

But I don't have a proposal how this could be fixed. (Not that it can be fixed in the current SKOS version at this point...)

 

Cheers! Vladimir