W3C home > Mailing lists > Public > public-esw-thes@w3.org > December 2012

Re: Concept Schemes hierarchies

From: Thomas Bandholtz <thomas.bandholtz@innoq.com>
Date: Mon, 31 Dec 2012 09:59:37 +0100
Message-ID: <50E153F9.3050701@innoq.com>
To: <public-esw-thes@w3.org>
Hi all,

did anybody consider using skos:Collection in order to represent
microthesauri instead?

Best regards,
Thomas

Am 31.12.2012 09:53, schrieb Juan Antonio Pastor Sánchez:
> Hi Antoine, Johan,
>
> Thank you very much for your help and solve my doubts.
>
> Finally, we have decided to use skos:inScheme or a subproperty like
> ex:subSchemeOf as solution for skos:ConceptSchemes hierarchies in
> order to represent microthesaurus for this project. This will be a
> TEMPORARY solution for the first SKOS version of the thesaurus.
>
> When a namespace for iso-thes is avalaible we'll begin to use
> ConceptGroup/subGroup/superGroup. We have analyzed this change will be
> very easy to do for a version of the thesaurus adapted to iso-thes.
>
> Happy new year to everyone !!!
> Juan
>
>
>
> 2012/12/30 Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>>
>
>     Hi Juan, Johan,
>
>     Juan is right on the lack of domain for inScheme, I've reacted too
>     fast.
>     Using inScheme between things that are of a same nature (two
>     concept schemes) seems weird, but from a formal perspective it
>     should be alright then.
>     That being said, I'm still more comfortable with relying on a
>     property that one can connect to some established practice
>     (micro-thesauri or others). Because the matter is indeed quite
>     complex, and keeping some explicit track of the practice that is
>     "represented" could be handy.
>
>     It's perhaps similar to what happens to mapping properties.
>     Formally, it's fair to use skos:broader between concepts from
>     different schemes, which are aligned posterior to their design.
>     But using skos:broadMatch allows data consumers to make the
>     distinction between these cases and the "more traditional" cases
>     of skos:broader, if they want to.
>
>     Antoine
>
>
>         Hi Juan,
>
>         Some remarks (repeating part of my previous answer) in-line.
>
>         Kind Regards,
>
>         *Johan De Smedt *
>
>         /Chief Technology Officer/
>
>         //
>
>         mail: johan.de-smedt@tenforce.com
>         <mailto:johan.de-smedt@tenforce.com>
>         <mailto:johan.de-smedt@tenforce.com
>         <mailto:johan.de-smedt@tenforce.com>>
>
>         mobile: +32 477 475934 <tel:%2B32%20477%20475934>
>
>         mail-TenForce
>
>         *From:*pastorcito@gmail.com <mailto:pastorcito@gmail.com>
>         [mailto:pastorcito@gmail.com <mailto:pastorcito@gmail.com>]
>         *On Behalf Of *Juan Antonio Pastor Sánchez
>         *Sent:* Sunday, 30 December, 2012 19:51
>         *To:* Antoine Isaac; Johan De Smedt
>         *Cc:* public-esw-thes@w3.org <mailto:public-esw-thes@w3.org>
>         *Subject:* Re: Concept Schemes hierarchies
>
>         Hi Antoine, Johan:
>
>         Certainly, I had my ideas clear: the domain of skos:inScheme
>         is skos:Concept and the range is skos: ConceeptScheme.
>         However, when I re-read the SKOS reference, I surprised when I
>         found the following [1]:
>
>         "4.6.5. Domain of skos:inScheme
>
>         Note that no domain is stated for the property skos:inScheme,
>         i.e., the domain is effectively the class of all resources
>         (rdfs:Resource). The decision not to state any domain has been
>         made to provide some flexibility, enabling extensions to SKOS
>         to define new classes of resource but still use skos:inScheme
>         to link them to a skos:ConceptScheme. [...]"
>
>         and really in
>         http://www.w3.org/2009/08/skos-reference/skos.rdf there is not
>         domain form skos:ConceptScheme.
>
>         At this point I thought a statement like <S11> skos: inScheme
>         <S1>:
>
>         * Is consistent with normative SKOS
>         * This uses respects the disjoiness between skos:Collection,
>         skos:Concept and skos:ConceptScheme.
>
>         Therefore, some question:
>
>         A) Considering [1] where is the problem to subdordinate a
>         skos:ConceptScheme to another using skos:inScheme?
>
>         */[JDS:>] You are correct that there is no domain constraint
>         on skos:inScheme. /*
>
>
>
>         B) In [2] iso-thes:ConceptGroup are defined as a sub-class of
>         skos:Collection and requires a sub-property of skos:inScheme:
>         Considering [1]: it is necessary that property? It would be
>         enough with skos:inScheme since its domain is not stated?
>
>         */[JDS:>] The ConceptGroup class is much wider use thatn only
>         “microThesaurus”./*
>
>         */Any type of group can be used depending the modelling needs.
>         Domain, micro-thesaurus, Theme, subjectCategory …/*
>
>         */Hence the dedicated modeling of superGroup/subGroup/*
>
>         */Note also in ISO 25964 this hierarchy is different from the
>         there defined contains/isPartOf relationship (where the ISO
>         25964 isPartOf maps to the skos:inScheme as per [2])/*
>
>
>
>         C) The definition of iso-thes:ConceptGroup (as sub-class of
>         skos:Collection) is not consistent with the use of
>         skos:hasTopConcept and skos:topConceptOf? It's necessary
>         another properties a bit complex [2]: "Shall be derived in
>         SKOS from skos:broaderTransitive where the object of
>         skos:broaderTransitive is a concept having the property
>         skos:topConceptOf (i.e., a ThesaurusConcept having topConcept
>         = true)."
>
>         */[JDS:>] This is not related to the discussion at hand. /*
>
>         */A) There is NO inconsistency in the definition of
>         iso-thes:ConceptGroup as there is not statement (inferred or
>         direct) linking it to skos:hasTopConcept and skos:topConceptOf./*
>
>         */B) The cited explanation of [2] details how the UML model in
>         ISO25964 is mapped to skos./*
>
>         */It notes the difference in in usage becasuse/*
>
>         */- in ISO 25964 hasTopConcept relates any concept to its
>         hierarchical root/*
>
>         */- in SKOS, skos:hasTopConcept relates a skos:ConceptScheme
>         to the top level concepts/*
>
>
>
>         Although I prefer modeling using "native" SKOS elements, I
>         recognize that a property like ex: subScheme could be valid.
>         In the case of the project in which I'm working I need find a
>         solution as soon as possible, and the development of iso-thes
>         just begun.
>
>         */[JDS:>] As Detailed in my previous mail, the semantics of
>         sub-scheme or micro-scheme are not fully standardized as far
>         as I know./*
>
>         */- The subScheme extension suggested by Antoine captures the
>         semantics you seem to need (handle a part of a thesaurus as a
>         thesaurus on its own account)/*
>
>         */- The relation among the sets of concepts and their
>         relationships is well captured by the proposed mapping in [2].
>         It does not capture sub-scheme semantics (in the sense that it
>         is necessary to publish a part of a thesaurus as a thesaurus
>         on its own account). However, it does capture any possible
>         concept grouping that may be needed. Such groupings can be
>         further typed as necessary. With the mapping the grouping is
>         defined as a part of the thesaurus./*
>
>         Sorry for all my questions, and thank you very much for your
>         time to answer !!!*//*
>
>         */[JDS:>] I hope the answers are useful for your objective,
>         though it is not fully clear to mean what you want to achieve./*
>
>
>
>         Best regards,
>         Juan
>
>         [1] http://www.w3.org/TR/skos-reference/#L2805
>         [2]
>         http://www.niso.org/apps/group_public/download.php/9507/Correspondence_ISO25964-SKOSXL-MADS-2012-09-16.pdf
>
>         2012/12/30 Antoine Isaac <aisaac@few.vu.nl
>         <mailto:aisaac@few.vu.nl> <mailto:aisaac@few.vu.nl
>         <mailto:aisaac@few.vu.nl>>>
>
>         Hi Juan,
>
>         There has been suggestions like these in the past, already.
>         The problem with your pattern (using skos:inScheme between
>         ConceptSchemes) is that skos:inScheme has skos:Concept as
>         domain and skos:ConceptScheme as range. This would cause
>         "sub-schemes" like S11 to be infered to be instances of
>         skos:Concept, which is probably not something you want.
>
>         The cleanest option may be to create a new property, like
>         ex:subSchemeOf. Properties like ISO's
>         iso-thes:microThesaurusOf [1] or
>         madsrdf:isMemberOfMADSCollection [2] may fit, this remains to
>         be investigated (I'm afraid especially that these are mostly
>         used with sub-class of skos:Collection, not skos:ConceptScheme).
>
>         Note that coining a new property could still allow the kind of
>         inference you describe below (<C1> skos: inScheme <S1>). The
>         trick is to use an OWL property chain axiom [3] stating that
>         the chain (skos:inScheme, ex:subSchemeOf) is a sub-property of
>         skos:inScheme.
>
>         Antoine
>
>         [1] http://www.niso.org/schemas/iso25964/correspondencesSKOS/
>         [2]
>         http://www.loc.gov/standards/mads/rdf/v1.html#isMemberOfMADSCollection
>         [3]
>         http://www.w3.org/TR/2009/WD-owl2-primer-20090421/#Property_Chains
>
>         Hello everyone,
>
>         Recurrently some messages in this list concerning the
>         implementation with SKOS of thesauri formed by several
>         microthesauri Thesauri [1]
>
>         Some KOS as EUROVOC define specific properties to represent
>         this. The use of properties such as dc:isPartOf or developing
>         artifacts is another approaches.
>
>         Considering only skos:inScheme: is it possible to use this
>         property to define hierarchies of concept schemes?
>
>         Example: two concept schemes and <S1> and <S11>, <S1>
>         represents the whole thesaurus and <S11> a microthesaurus. It
>         could be defined:
>
>         <S11> skos:inScheme <S1>
>
>         Certainly this is consistent with the definition of
>         skos:inScheme in [2] and [3].
>
>         In this case, could be usefull define skos:inSheme as
>         transitive (skos:inScheme rdf:type owl:Transitive Property).
>         Thus, having a <C1> concept and the declaration:
>
>         <C1> skos: inScheme <S11>
>
>         could be inferred that:
>
>         <C1> skos: inScheme <S1>
>
>         Best regards,
>         Juan
>
>
>         [1]
>         http://lists.w3.org/Archives/Public/public-esw-thes/2010Jun/0010.html
>         [2] http://www.w3.org/TR/skos-reference/#L1101
>         [3] http://www.w3.org/TR/skos-reference/#L2805
>
>
>         --
>         Juan Antonio Pastor Sánchez, Ph.D.
>         Dep. of Information and Documentation
>         Faculty of Communication and Documentation
>         University of Murcia
>         phone: +34 868 88 7252 <tel:%2B34%20868%2088%207252>
>         <tel:%2B34%20868%2088%207252>
>         http://webs.um.es/pastor
>         pastor@um.es <mailto:pastor@um.es> <mailto:pastor@um.es
>         <mailto:pastor@um.es>> <mailto:pastor@um.es
>         <mailto:pastor@um.es> <mailto:pastor@um.es <mailto:pastor@um.es>>>
>
>
>
>
>         --
>         Juan Antonio Pastor Sánchez, Ph.D.
>         Dep. of Information and Documentation
>         Faculty of Communication and Documentation
>         University of Murcia
>         phone: +34 868 88 7252 <tel:%2B34%20868%2088%207252>
>         <tel:%2B34%20868%2088%207252>
>         http://webs.um.es/pastor
>         pastor@um.es <mailto:pastor@um.es> <mailto:pastor@um.es
>         <mailto:pastor@um.es>>
>
>
>
>
>
>
> -- 
> Dr. Juan Antonio Pastor Sánchez
> Dep. de Información y Documentación
> Facultad de Comunicación y Documentación
> Universidad de Murcia
> Tel: +34 868 88 7252
> http://webs.um.es/pastor
> pastor@um.es <mailto:pastor@um.es>
>
> Juan Antonio Pastor Sánchez, Ph.D. 
> Dep. of Information and Documentation
> Faculty of Communication and Documentation
> University of Murcia
> phone: +34 868 88 7252
> http://webs.um.es/pastor
> pastor@um.es <mailto:pastor@um.es>


-- 
Thomas Bandholtz
Principal Consultant

innoQ Deutschland GmbH
Krischerstr. 100, 
D-40789 Monheim am Rhein, Germany
http://www.innoq.com
thomas.bandholtz@innoq.com
+49 178 4049387

http://innoq.com/de/themen/linked-data (German)
https://github.com/innoq/iqvoc/wiki/Linked-Data (English)
Received on Monday, 31 December 2012 09:00:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 31 December 2012 09:00:08 GMT