RE: Comments on iso-thes-25964.owl

Thanks Vladimir,

 

I think we can almost finalize.

 

On the Node label – issue 1:

- ISO 25964 has 0 or 1 label per language.

  xl:prefLabel is sufficient.

  An application specific extension that has a purpose for alternative labels could then use xl:altLabel (–s).

  However that is outside of ISO 25964 then.

Is this ok?

 

For ISSUE 6: I will await further input from Antoine and Jutta.

If we comply with other ongoing discussion I will proceed:

- as you suggest (just the 1-step skos:broadr sub properties)

- document the broaderPartitive ISO limitation - This would mean that a BTP/NTP not complying to that condition should NOT be mapped to broaderPartitive.

- BTI will use the terminology you suggest (and as in http://www.w3.org/2006/07/SWD/track/issues/56)

 

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: Monday, 11 November, 2013 18:07
To: 'Johan De Smedt'; public-esw-thes@w3.org
Cc: 'Stella Dextre Clarke'; 'Marcia Zeng'; 'Jutta Lindenthal'; 'Antoine Isaac'; 'Leonard Will'; 'Joan Cobb'
Subject: RE: Comments on iso-thes-25964.owl

 

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

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?

 

I don’t know, that’s for Getty to answer. Joan: maybe Getty can give up altLabels of Guide Terms?

Marcia also quoted directly from the standard, which is adamant that Groups/Arrays are not supposed to have pref/altLabel but only a single label per language

 

In SKOS/SKOSXL you have the following implications:

  skosxl:prefLabel o skosxl:literalForm implies skos:prefLabel

  skosxl:altLabel o skosxl:literalForm implies skos:altLabel

  skos:prefLabel implies rdfs:label

  skos:altLabel implies rdfs:label

There's no property leading to skosxl:Label without the pref/alt distinction.

 

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

 

I like this suggestion, but people may ask “if there’s pref then where is alt”. 

Another option:

- add property iso:label with range skosxl:Label (I don’t think a subclass is needed)

   (could be a super-property of skosxl:prefLabel and skosxl:altLabel, but I don’t see a need for this yet)

- add implication (owl:propertyChain): iso:label o skosxl:literalForm implies rdfs:label

- to provide Array/Group label one could use either iso:label (structured label) or rdfs:label (plain literal). 

 

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.

 

In the Getty database there’s a field record_type that clearly distinguishes: facets, hierarchies, guide terms, concepts.

We’ll represent the first 3 as ConceptArrays with a custom flag gvp:subjectType reflecting record_type.

 

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

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

- xl:Label with xl:literalForm?

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

 

Ok, we’ll use type-less node with rdf:value (I guess this pattern was documented before the advent of skosxl:Label) 

 

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

 

Glad we agree!

 

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

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

 

Isn’t it better to call it broaderInstantive? (I think early SKOS drafts also used that name).

 

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

 

Please don’t do this. It means you’ll equate skos:Concept with owl:Class, raise the level of required OWL inference, and engage Punning (because the same concept could be both a class and an individual).

 

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.

 

I agee with these principles (as illustrated by Jutta), but this is not fixable unless we give up skos:broaderTransitive.

For our current purposes, this would be going too far (all TMS I know use skos:broader and all query expansions use skos:broaderTransitive),

so for now let’s just define broaderGeneric, broaderPartitive and broaderInstantive as subprops of skos:broader, and leave it at that