- From: Osma Suominen <osma.suominen@helsinki.fi>
- Date: Thu, 19 Dec 2013 14:47:52 +0200
- To: public-esw-thes@w3.org
Hi Johan!
I'm still a bit confused about the iso-thes namespace URI.
http://purl.org/schemas/iso25964/iso-thes gives a weird error from purl.org
http://purl.org/SCHEMAS/ISO25964/iso-thes gives a 404 error from
purl.org (even if I set the Accept header to e.g. application/rdf+xml)
So which one is the right namespace URI? Or none of the above?
Thanks,
Osma
On 08/11/13 09:54, Johan De Smedt wrote:
> Hi Antoine,
>
> Indeed the version Alexiev had was out of date.
>
> About the upper case:
>
> - I created a domain (/schemas/iso25964) at purl.org.
>
> - I made a 303 redirect for /schemas/iso25964/iso-thes
>
> However,
>
> - it does not work and I got no reply on my support request.
>
> - the /SCHEMAS/ISO25964/… does work and gets redirected to the origin
> server.
>
> Hence I adapted the .owl (and the html doc) to have the proper uppercase
> URI.
>
> The origin server will upload the corrections today (and some of the
> corrections mentioned below).
>
> Further outstanding issues:
>
> - the html redirect is not yet operational – I hope to remedy this asap
> – any advice is welcome.
>
> Kind Regards,
>
> *Johan De Smedt *
>
> /Chief Technology Officer/
>
> //
>
> mail: johan.de-smedt@tenforce.com <mailto:johan.de-smedt@tenforce.com>
>
> mobile: +32 477 475934
>
> mail-TenForce
>
> *From:*Isaac, A.H.J.C.A. [mailto:aisaac@few.vu.nl]
> *Sent:* Friday, 08 November, 2013 08:44
> *To:* Johan De Smedt; vladimir.alexiev@ontotext.com; public-esw-thes@w3.org
> *Cc:* 'Stella Dextre Clarke'; 'Marcia Zeng'
> *Subject:* RE: Comments on iso-thes-25964.owl
>
> Hi all,
>
> Just a quick note: I'm a bit confused by what Vladimir may have looked
> at: we had made a version that doesn't have many of the problems that he
> found. But perhaps this was still pending re-publication...
>
> By the way about the namespace: "SCHEMAS" in upper-case, really? That
> looks a bit strange!
>
> I may not have time to go further on the discussion on SKOS properties
> in Vladimir email before a couple of days, sorry.
>
> Best,
>
> Antoine
>
> ------------------------------------------------------------------------
>
> *From:*Johan De Smedt [johan.de-smedt@tenforce.com]
> *Sent:* 08 November 2013 08:33
> *To:* vladimir.alexiev@ontotext.com
> <mailto:vladimir.alexiev@ontotext.com>; public-esw-thes@w3.org
> <mailto:public-esw-thes@w3.org>
> *Cc:* 'Stella Dextre Clarke'; 'Marcia Zeng'
> *Subject:* RE: Comments on iso-thes-25964.owl
>
> 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: johan.de-smedt@tenforce.com <mailto: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 <mailto: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:
>
> ·Exchanging ISO 25964-1 thesauri data using RDF, SKOS and SKOS-XL
> <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/ISO25964-mapping-to-SKOS-XL.pptx> (Johan
> De Smedt, NKOS 2012
> <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/programme2012.html>)
>
> ·Ambiguities in representing thesauri using extended SKOS - examples
> from real life
> <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/TPDL2012_NKOS_Ambiguities.pptx> (Jutta
> Lindenthal, NKOS 2012
> <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/programme2012.html>)
>
> ·Building better controlled vocabularies- Guidance from ISO 25964
> <http://www.iskouk.org/conf2013/abstracts.htm#Lindenthal>(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:
>
> o dcterms:type is declared both owl:AnnotationProperty and
> owl:ObjectProperty
> o 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.
>
> o 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?
> o 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.
> o 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 /*
>
> * 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.
>
> o 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.
> o 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:
>
> The USE+/UF+ relationship is added as sub-properties of (skos-xl)
> xl:labelRelation.
>
> 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:
>
> 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/*
>
> o 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./*
>
> o 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
>
--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Teollisuuskatu 23)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suominen@helsinki.fi
http://www.nationallibrary.fi
Received on Thursday, 19 December 2013 12:48:29 UTC