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