RE: Comments on iso-thes-25964.owl

Hi Vladimir,

 

Thanks for your remarks.

I numbered the issues and questions below.

Discussion on ISSUE 6 is not final yet.

For these replies, see in-line [JDS3:>].

 

In addition, I cut-out ([…cut…]) the things that are no issue any longer and numbered the remaining remarks.

 

For the basis for the iso-thes owl, see also [1] http://www.niso.org/schemas/iso25964/correspondencesSKOS/

 

Kind Regards,

 

Johan De Smedt 

From: Vladimir Alexiev [mailto:vladimir.alexiev@ontotext.com] 
Sent: Friday, 08 November, 2013 16:43
To: public-esw-thes@w3.org
Cc: 'Stella Dextre Clarke'; 'Marcia Zeng'
Subject: RE: Comments on iso-thes-25964.owl

 

Hi Johan, thanks for the comprehensive reply!

 

[JDS3:>] ISSUE 1 – Node Labels

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

[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 a common provenance statement mechanism we can consider a “NodeLabel” sub class of xl:Label.  What do you think?

 

If this will keep ISO happy J 

But what property will lead to NodeLabel? PLEASE use xl:prefLabel / xl:altLabel.

Here is an AAT example of a Guide Term having an altLabel (in Dutch):

http://www.getty.edu/vow/AATFullDisplay?find=300198841 <http://www.getty.edu/vow/AATFullDisplay?find=300198841&logic=AND&note=&subjectid=300078072> &logic=AND&note=&subjectid=300078072

If the ISO thinks nodes can’t have multiple labels, then it is wrong.

[JDS3:>]ISO 25964 allows for only one node label per language. In addition it gives some rules.

Typically the rules for Concept Labels and those for Node labels are different (uniqueness, form, …).

See section 14.3 “Relationships between terms and between concepts” and 14.6 “Node labels”.

About the AAT structure, I learned from Jutta and Marcia that some restructuring is on-going.

See http://www.getty.edu/research/tools/vocabularies/guidelines/aat_3_3_terms_names.html#3_3_2_5_17

These guidelines instruct to only use ‘preferred’ terms – see 5th bullet.

Do you consider the Dutch example you gave (using a plural and a singular form of the label) conforming to the AAT rules?

Therefor the proposal would be to only use xl:prefLabel for node labels.

Leonard also remarks to distinguish two AAT cases:

“The example cited from the AAT was <infrastructural elements>. This is not a node label, but a preferred term for a concept, which the AAT has decided to include for structural reasons but which they say should not be used for indexing documents. It is a preferred term for a concept, and the fact that it should not be used for indexing may be indicated by a value of the "status" attribute or a custom attribute of the term or of the concept that it labels.

It is unfortunate that the AAT uses the expression "guide terms" to cover such terms as well as node labels. An example of a node label in the AAT is <components by specific context>, showing how the concepts in the array which it introduces have been selected or arranged.

There is no problem in representing the AAT in conformity with the ISO model so long as this distinction is observed. It does mean intellectual intervention, as the typographical convention of angle brackets does not distinguish the two cases, though in most cases a node label can be recognized by the presence of the word "by" in the wording of the label.

”

 

[JDS3:>] ISSUE 2 : Provenance, authoring and tracking on Documentation

While we’re on the topic of “text with provenance”, may I ask which pattern is better for a Note:

- type-less node with rdf:value (as documented in SKOS “advanced documentation”), or

- xl:Label with xl:literalForm?

I’m a bit uneasy about type-less nodes.

[JDS3:>] Please see [1] http://www.niso.org/schemas/iso25964/correspondencesSKOS/ on this subject.

The advice is in-line with the SKOS ref and SKOS primer.  It also indicates the possibilities of using literals of type XMLLiteral in case rich structure are useful within notes (e.g. for embedding hyperlinks or structuring part of the documentation as a list).

 

[JDS3:>] […cut…]

 

[JDS3:>] ISSUE 3 – Incomplete definition of iso-thes:superOrdinate.

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

 

I’m afraid that is not true. AFAIK the only OWL rules for inverseOf are prp_inv1 and prp_inv2 that allow you to infer property instances. That does not let you make any conclusions about domain and range

[JDS3:>] Point taken – I will add domain and ranges here.

(Issue 3 closed)

 

[JDS3:>] ISSUE 4 – Compound Equivalence and alt labels.

* “child adoption” is 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")

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

 

You didn’t need to redo the animation from your presentation in this email. I understand what’s going on, but it still doesn’t answer my concern: “child adoption” is NOT a label for “child”! Any model that leads you to that conclusion is wrong.

 

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

 

It doesn’t matter whether the thesaurus includes such pre-coordinated concept. The concept “adoption AND children” does exist in an abstract sense (it’s the precoordination of the two indicated concepts). “Child adoption” is a label for it, not for any of the atoms.

[JDS3:>] The “Child adoption” was tagged in [1] as a “virtual” concept (you call it “abstract”) identified by the compound equivalence.

The relationship indicated by iso-thes:splitAltLabel depicts the relationship between the component “real” concepts and the term of a related “virtual” concept.

You are CORRECT that this is not a synonym of any of the “real” component concepts.

I will remove the rules for making skos:altLabel a superProperty of the chain iso-thes:splitAltLabel / xl:literalForm. 

 

[JDS3:>] […cut…]

 

[JDS3:>] ISSUE 5 – Expand modeling of compound equivalence

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

 

Why not add such extension (subproperty) to owl, as a best practice guideline?

[JDS3:>] This cannot be done in the context of ISO-25964 as it is nowhere discussed there.

Therefor I suggest a custom extension for now.

 

[JDS3:>] ISSUE 6 – Modeling of BTG/NTG, BTP/NTP, BTI/NTI 

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

 

I’m afraid this won’t work.

- broader is non-transitive (it’s a step relation), so it cant have transitive subprops.

- broaderTransitive is defined as a transitive superprop of broader. 

  Instead, it would need to be redefined as OR (superprop) of broaderGenericTransitive and broaderPartitiveTransitive 

[JDS3:>] Correct! – sorry for my sloppy and flawed answer on this.

Transitivity and “one step” relations (like “skos:broader”) do not work well together.

We can introduce broaderGeneric, broaderPartitive and broaderInstance as sub-properties of skos:broader (see also [1]) 

Further discussions are ongoing.  The proposal would be extended such that:

-  broaderGeneric is modeled as a sub-property of rdfs:subClassOf

- broaderInstance is modeled as a sub-property of rdf:type

ISO 25964 gives limits for the transitivity (and hierarchy) when using broaderPartitive/narrowerPartitive (whole – part) relationships.

These should only be in a hierarchical relationship when it complies with the ALL/SOME test.

“ALL ‘parts’ must be part of ‘the whole’” and there must exist SOME “whole” that have the “parts” as a part.

I propose to conclude on this is a separate mail thread.

 

 

Cheers! V