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

Re: Concept Schemes hierarchies

From: Juan Antonio Pastor Sánchez <pastor@um.es>
Date: Mon, 31 Dec 2012 09:53:19 +0100
Message-ID: <CAFkhdr8L7RFZp_=HfEmKNaezBottqzuNhok5+t=NkRP+we=2bQ@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>, Johan De Smedt <johan.de-smedt@tenforce.com>
Cc: public-esw-thes@w3.org
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 GMT

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