Re: Concept Schemes hierarchies

Hi Thomas,

Do you mean somenthing like this?

<C1> skos:inScheme <S1>
<C1> skos:topConceptOf <S1>
<S1> skos:hasTopConcept <C1>
<COL1> skos:inScheme <S1>
<C1> skos:member <COL1>

Where <COL1> is a MIcrothesauri. Then, to obtain the Top Concepts for
<COL1>:

select ?topconcepts where {
   ?concept skos:topConceptOf <S1>;
         skos:member <COL1> .
}

Is this correct?

In such case: how can be used this mechanism for structures like the Unesco
Thesaurus?

1 Education
   1.05 Educational sciences and environment
   1.10 Educational policy
   1.15 Educational planning
   ...
2 Science
   2.05 Scientific approach
   2.10 Science and research management
   ...
3 Culture

etc

Best regards,
Juan

2012/12/31 Thomas Bandholtz <thomas.bandholtz@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>
>
>> 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>
>>>
>>>
>>
>>
>
>
>  --
> 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
>
>
>
> --
> Thomas Bandholtz
> Principal Consultant
>
> innoQ Deutschland GmbH
> Krischerstr. 100,
> D-40789 Monheim am Rhein, Germanyhttp://www.innoq.comthomas.bandholtz@innoq.com+49 178 4049387
> http://innoq.com/de/themen/linked-data (German)https://github.com/innoq/iqvoc/wiki/Linked-Data (English)
>
>


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