RE: Comments on iso-thes-25964.owl / completion.

I noted one answer was incomplete - appologies  – added editing as [JDS2:>]

=====================================

Hi Alexiev,

 

Thanks for your comments.

The final version is ready to be released soon – the base URI will be http://purl.org/SCHEMAS/ISO25964/iso-thes#.

(Likely to be available in this final form as of tomorrow.)

It is based on the analysis provided in http://www.niso.org/schemas/iso25964/correspondencesSKOS/ [1]

Please see my answers below.

 

Kind Regards,

 

Johan De Smedt 

Chief Technology Officer

 

mail:  <mailto:johan.de-smedt@tenforce.com> johan.de-smedt@tenforce.com

mobile: +32 477 475934

mail-TenForce

 

From: Vladimir Alexiev [mailto:vladimir.alexiev@ontotext.com] 
Sent: Thursday, 07 November, 2013 19:50
To: public-esw-thes@w3.org
Cc: 'Stella Dextre Clarke'; 'Marcia Zeng'
Subject: 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

[JDS:>] All DC/DCT definitions have been removed from the final version.

* 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)

[JDS:>] The schema reflects the ISO WG consensus, clearly distinguishing between both.  I agree with the argumentation on the added complexity for making provenance statements in different ways for rdfs:label and for the skosxl:Label. 

In order not to conflict with ISO 25964 and to find [JDS2:>] a common provenance statement mechanism we can consider a “NodeLabel” sub class of xl:Label.  What do you think?

* iso-thes:isMemberOfGroup has wrong label "superOrdinate"

[JDS:>] isMemberOfGroup was not part of [1] (see above) and has been removed.

* 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?

[JDS:>] isMemberOfGroup has been removed

Concerning the subGroup/superGroup I want to propose to amend in-line with the skos model on broader/broaderTransitive:

- follow-up on your suggestion to have subGroup/superGroup not transitive

- add a subGroupTransitive/superGroupTransitive which are transitive closures of the ConceptGroup

* 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")[JDS:>]  Typos are corrected.

[JDS:>] The phrase refers to the ISO 25964 - 1 where the subordinate array may be used the organize facets as an array under a concept.  The concepts in the array are siblings though do not necessarily have the superOrdinateConcept as a parent.  Examples are given in ISO 25964 part 1.  The concept and the model comply to ISO 25964.  In essence, in case the concepts in an array are actually narrower terms of a/the superOrdinateConcept of that array, the an explicit broader/narrower relationship must be stated. This broader/narrower relationship may not be inferred from the superOrdinateConcept/subordinateArray relationship.

* 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?

[JDS:>] The array is the means for organization in the sense that the elements of the array are the top level facets.  Obviously, these top level facets may have narrower terms of their own (expressed by the broader/narrower relationship).  See section 11 of ISO 25964 (Facet Analysis) and figure 4.  Concept groups are not particular for the organization but may serve various other purposes. 

* Better define the domain and range of iso:superOrdinate (don't just rely on owl:inverseOf)

[JDS:>] This is implicit by inference on the owl model.  I do not think there is a need to do it.

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.

[JDS:>] Let’s take the drawing (with color legend and build-up) and the ISO UML diagram to focus the discussion:

- From the UML diagram the compound term “adopted children” is a SplitNonPreferredTerm having a USE+/UF+ relationship with the preferred terms “children” and “adoption”.

For the purpose of this example, there is no “narrower” concept “adopted children”.

Model_2011-06-02

The compound relationship between the labels is depicted as:

cid:image008.jpg@01CEDC5D.39625D20

The USE+/UF+ relationship is added as sub-properties of (skos-xl) xl:labelRelation.

cid:image009.jpg@01CEDC5D.39625D20

The preferred labels are preferred labels of particular concepts.  These are added.

Further, the iso-thes:splitAltLabel is added (as sub of xl:alt:Label).  This construct provides the alternative label relationship for SKOS-XL systems that are not aware of iso-thes skos semantics.  It thus recognizes the compound non preferred term (“adopted children” as an alternative (SKOS-XL) label for preferred terms “adoption” and “adopted”).

The last drawing concludes the availability of the relationship between preferred labels, their associated concepts and the alternate labels at SKOS level:

cid:image014.jpg@01CEDC5D.39625D20

Does this clarify the example and the used relations?

Note I do understand that if a thesaurus would include “adopted children” as a concept, this indeed would make a different instantiation.

However, to illustrate the model for compound relationship, the example must be read as there is no “adopted children” concept (or preferred term).

* 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:

[JDS:>] iso-thes:PreferredLabel is removed from the final version

* 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")

[JDS:>] The compound equivalence relationship itself is as per ISO USE+/UF+ between a non preferred compound term (the “SplitNonPreferredTerm”) and the preferred terms.

The linguistic constituents of the compound term indeed may be different.  See also “adopted” vs “adoption” in this example.

* 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"

[JDS:>] The difference between main term and modifiers indeed is not modeled, neither in the ISO 25964 nor in the owl scheme made for it.

If it is needed, this would require an extension.

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...)

[JDS:>] my-understanding: skos:broaderTransitive is the transitive closure of skos:broader. I understand from the discussion of Jutta and Detlev that:

- BTG and BTP should be declared as transitive sub-properties of skos:broader

- BTI should be declared as sub-property of skos:broader, but NOT as transitive.

(Compare to the superGroup discussion above.)

 

Cheers! Vladimir