Re: Concept Schemes hierarchies

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>
>
> 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 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>>
>
> 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>
> 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>
>

Received on Sunday, 30 December 2012 20:42:30 UTC