- From: Johan De Smedt <johan.de-smedt@tenforce.com>
- Date: Thu, 19 Dec 2013 14:03:08 +0100
- To: "'Osma Suominen'" <osma.suominen@helsinki.fi>, <public-esw-thes@w3.org>
- Message-ID: <040e01cefcba$aa9485e0$ffbd91a0$@tenforce.com>
Hi Osma,
The correct iso-thes URI is http://purl.org/iso25964/skos-thes
Kind Regards,
Johan De Smedt
Chief Technology Officer
mail: johan.de-smedt@tenforce.com
mobile: +32 477 475934
> -----Original Message-----
> From: Osma Suominen [mailto:osma.suominen@helsinki.fi]
> Sent: Thursday, 19 December, 2013 13:48
> To: public-esw-thes@w3.org
> Subject: iso-thes namespace Re: Comments on iso-thes-25964.owl
>
> Hi Johan!
>
> I'm still a bit confused about the iso-thes namespace URI.
>
> <http://purl.org/schemas/iso25964/iso-thes> http://purl.org/schemas/iso25964/iso-thes gives a weird error from purl.org
>
> <http://purl.org/SCHEMAS/ISO25964/iso-thes> 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: <mailto:johan.de-smedt@tenforce.com> johan.de-smedt@tenforce.com < <mailto: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> mailto:aisaac@few.vu.nl]
> > *Sent:* Friday, 08 November, 2013 08:44
> > *To:* Johan De Smedt; <mailto:vladimir.alexiev@ontotext.com> vladimir.alexiev@ontotext.com; <mailto:public-esw-thes@w3.org> 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:* <mailto:vladimir.alexiev@ontotext.com> vladimir.alexiev@ontotext.com
> > < <mailto:vladimir.alexiev@ontotext.com> mailto:vladimir.alexiev@ontotext.com>; <mailto:public-esw-thes@w3.org> public-esw-thes@w3.org
> > < <mailto: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#> 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/> 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 < <mailto: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> mailto:vladimir.alexiev@ontotext.com]
> > *Sent:* Thursday, 07 November, 2013 19:50
> > *To:* <mailto:public-esw-thes@w3.org> public-esw-thes@w3.org < <mailto: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> https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/ISO25964-
<https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/ISO25964-mapping-to-SKOS-XL.pptx> > mapping-to-SKOS-XL.pptx> (Johan
> > De Smedt, NKOS 2012
> >
> < <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/programme2012.html> 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> https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/TPDL2012
<https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/presentations/TPDL2012_NKOS_Ambiguities.pptx> > _NKOS_Ambiguities.pptx> (Jutta
> > Lindenthal, NKOS 2012
> >
> < <https://www.comp.glam.ac.uk/pages/research/hypermedia/nkos/nkos2012/programme2012.html> 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> 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
> <mailto:osma.suominen@helsinki.fi> osma.suominen@helsinki.fi
> <http://www.nationallibrary.fi> http://www.nationallibrary.fi
Received on Thursday, 19 December 2013 13:03:44 UTC