- From: Juan Antonio Pastor Sánchez <pastor@um.es>
- Date: Mon, 31 Dec 2012 09:53:19 +0100
- To: Antoine Isaac <aisaac@few.vu.nl>, Johan De Smedt <johan.de-smedt@tenforce.com>
- Cc: public-esw-thes@w3.org
- Message-ID: <CAFkhdr8L7RFZp_=HfEmKNaezBottqzuNhok5+t=NkRP+we=2bQ@mail.gmail.com>
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> > 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<johan.de-smedt@tenforce.com> >> > >> >> mobile: +32 477 475934 >> >> mail-TenForce >> >> *From:*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 >> *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<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<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<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>> >> >> 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/<http://www.niso.org/schemas/iso25964/correspondencesSKOS/> >> [2] http://www.loc.gov/standards/**mads/rdf/v1.html#** >> isMemberOfMADSCollection<http://www.loc.gov/standards/mads/rdf/v1.html#isMemberOfMADSCollection> >> [3] http://www.w3.org/TR/2009/WD-**owl2-primer-20090421/#** >> Property_Chains<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<http://lists.w3.org/Archives/Public/public-esw-thes/2010Jun/0010.html> >> [2] http://www.w3.org/TR/skos-**reference/#L1101<http://www.w3.org/TR/skos-reference/#L1101> >> [3] http://www.w3.org/TR/skos-**reference/#L2805<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> >> http://webs.um.es/pastor >> 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> >> http://webs.um.es/pastor >> 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 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
Received on Monday, 31 December 2012 08:53:47 UTC