RE: Concept Schemes hierarchies

Hi Thomas,

 

Using skos:Collection is indeed the advised use in
http://www.niso.org/schemas/iso25964/correspondencesSKOS/

 

Kind Regards,

 

Johan De Smedt 

Chief Technology Officer

 

mail:  <mailto:johan.de-smedt@tenforce.com> johan.de-smedt@tenforce.com

mobile: +32 477 475934

mail-TenForce

 

From: Thomas Bandholtz [mailto:thomas.bandholtz@innoq.com] 
Sent: Monday, 31 December, 2012 10:00
To: public-esw-thes@w3.org
Subject: Re: Concept Schemes hierarchies

 

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 <tel:%2B32%20477%20475934> 

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