Re: R: UNESKOS Vocabulary and 2nd SKOS version of UNESCO Thesaurus

Dear Osma,

Thank you very much for your suggestions. We will carefully consider them.
Certainly, the "rev" property simplifies the CBD for RDFa Markup. The RDFa
Distiller & Parser works fine with this approach.

By the way (and in order to get more information) two questions:

Could you (or anyone of the mail list) give us more information about any
SKOS dataset that applies CBD?
Any example about any one-SPARQL-query for obtaining such description?

This can be very helpful for us.

Thanks in advance,
Juan





2015-09-18 9:18 GMT+02:00 Osma Suominen <osma.suominen@helsinki.fi>:

> Dear Juan,
>
> Thank you for the excellent clarifications!
>
> Some further comments below.
>
>
> 17.09.2015, 17:48, Juan Antonio Pastor Sánchez wrote:
>
> We didn't the RDFa markup for these links because don't exist SKOS
>> properties that allow do it. In the context of an RDFa distiller the
>> data of these links are lost. The use of CBD in HTML markup is not the
>> solution because implies hide to user html code: it's an artificial
>> solution for a modelling issue.
>>
>> This is the main reason for introduce these properties for this project.
>> You suggest that the best place to define this properties is SKOS
>> itself. But we must consider (is my opinion) two points:
>>
>> 1) SKOS must be simple, and probably define this properties in the
>> "core" of SKOS must turn SKOS a bit complex.
>>
>> 2) The specification and namespace is for a better documentation of the
>> ad-hoc UNESKOS properties. Certainly can be used in others projects, but
>> that decision must be taken by others.
>>
>> I believe that there is a very interesting discusion about SKOS. In the
>> past some properties have been discussed and rejected by the SKOS
>> community. So, I want to explain the meaning of the UNESKOS properties:
>>
>>
>> *A) UNESKOS:CONTAINS.*
>>
>> As I understand, this is the most controversial property. There is a
>> "fear in the air" to connect a Concept Scheme with every of the 30.000
>> Concepts of a KOS. We advice about don't use uneskos:contains for this
>> in the specification. I will give you a metaphor: A webmaster can define
>> in the home of a web site a link for every (maybe thousands) pages of
>> the site. What prevent this? The common sense.
>>
>>   So, a "SKOSer" can define 30.000 statements from a Concept Scheme to a
>> Concept with uneskos:contains? Yes, but it's a nonsense.
>>
>>
>> *B) UNESKOS:MEMBEROF*
>>
>> Well, it's curious that in SKOS there is a property that connect a
>> Concept with a Concept Scheme (skos:inScheme) but not the same for
>> Collections. Why not? Because there is property for the inverse way
>> (skos:member). There is a "fear in the air" to define links from Concept
>> Schemes to Concepts, but not from the Collections to Concepts. Really,
>> Is it more reasonable 300 skos:member from Collections to Concepts
>> instead one "skos:memberOf" from every Concept to its Collections
>> (Hey!!! Just like skos:inScheme).
>>
>> But in the past the SKOS community reject this property. I understand
>> the problems in order to entail this property with ordered collections.
>> So, this is the reason for uneskos:memberOf
>>
>
>
> As I read it, your justification for uneskos:memberOf and uneskos:contains
> really boils down to this: you want to use a specific kind of RDFa markup
> to express the relationship between two entities (Concept -> ConceptGroup
> and ConceptScheme -> Concept, respectively).
>
> For unescos:memberOf, you currently have this kind of HTML+RDFa markup on
> the concept page (slightly reformatted for clarity):
>
> <ul rel="uneskos:memberOf">
>   <li resource="http://skos.um.es/unescothes/COL425">
>     <strong>MT</strong>
>     <a href="http://skos.um.es/unescothes/COL425/html">4.25 Social policy
> and welfare</a>
>   </li>
> </ul>
>
> But as I see it, you could just as well have used the "rev" attribute
> defined in RDFa for specifying the reverse relationship, like this:
>
> <ul rev="skos:member">
>   <li resource="http://skos.um.es/unescothes/COL425">
>     <strong>MT</strong>
>     <a href="http://skos.um.es/unescothes/COL425/html">4.25 Social policy
> and welfare</a>
>   </li>
> </ul>
>
> Then there would be no need for uneskos:memberOf. Right?
> And likewise for unescos:contains, as you could be using
> rev="skos:inScheme" instead of rel="unescos:contains". If your RDFa tool
> doesn't allow this, it's not a fault of the data model but a missing
> feature in the tool.
>
> *C) UNESKOS:HASMAINCONCEPT & UNESKOS:MAINCONCEPTOF*
>>
>> In SKOS, Collections are concibed as "bag" of concepts. I can understand
>> this. But probably (probably) the introduction of iso-thes:ConceptGroup
>> change this Why? Because the use of iso-thes:ConceptGroup for
>> representing micro-thesaurus implies (probably) the access to an
>> hierarchical structure starting for Higher concepts. In the past, the
>> class skos:TopConcept was rejected. I don't remember if someone proposed
>> that the range of skos:hasTopConcept and the domain of skos:topConceptOf
>> were the union of skos:Collection and skos:ConceptScheme, but,
>> sincerely, I don't know if this is a solution. Really, I can't affirm if
>> this is a problem. But for us is a modelling issue: "I reach the
>> micro-thesaurus.... And now.... I can see 200 concepts!!!". The first
>> SKOS versión of UNESCO Thesaurus define this access points as the
>> intersections of Concepts of the Collection with the Concepts with a
>> skos:topConceptOf (with SPARQL sure).
>>
>
> These seem like useful additions in your case, where you have multiple
> independent microthesauri and only some of the concepts in those
> microthesauri are top level concepts / entry points. In effect, your
> microthesauri work a lot like independent concept schemes (and perhaps an
> alternate modelling would be to define them as concept schemes instead?)
> and these properties are analoguous to skos:hasTopConcept /
> skos:topConceptOf.
>
> *D) UNESKOS:HASMICROTHESAURUS*
>>
>> I don't read any inconvenient in your messages for this property.
>> Perhaps someone in the next hours send a message disapproving this
>> property, arguing that /"is not explicitly defined in the UML data model
>> of the ISO Standard and exists an inverse property"/. But (again... is
>> my opinion only) It seems logic reach to Micro-thesauri from the Concept
>> Scheme.
>>
>
> Specifications like SKOS and ISO 25964 are not divine :) But often the
> choices in them have reasons behind them. Sometimes better, sometimes worse.
>
> In this case I think one could use just plain skos:inScheme (or more
> likely its inverse), since it is permitted to use skos:inScheme for a
> Collection or ConceptGroup. The domain of skos:inScheme is left open so it
> can be used with any type.
>
> *FINAL REFLECTION I)* Maybe the "mantra" in this discussion is "If there
>> is a property, then we don't need to define its inverse". Can you
>> imagine that skos:narrower were not defined because with skos:broader is
>> enough.
>>
>
> SKOS indeed is not completely consistent here. Both skos:broader and
> skos:narrower are defined (and their mapping and transitional variants),
> and likewise both skos:hasTopConcept / topConceptOf. For broader/narrower,
> I think the choice to include both was affected by the long tradition of
> using both BT and NT relationships in traditional thesauri. For
> hasTopConcept / topConcept of I'm not sure why both properties were
> included. The otherwise excellent paper "Key choices in the design of
> Simple Knowledge Organization System (SKOS)" by Tom Baker et al. doesn't
> really shed much light on this aspect.
>
> *FINAL REFLECTION II)* I have found in the last years, many SKOS
>> datasets with ad-hoc properties that complement SKOS. Even I found SKOS
>> datasets that define Micro-thesaurus as Concepts, because need certain
>> conection features unavalaible for Collections or Concept Scheme.
>> Sometimes, SKOS is so simple that its application for many KOS is a bit
>> complex.
>>
>
> Your observation is absolutely correct! There have been lots of ad-hoc
> extensions and also somewhat questionable modelling of microthesauri and
> similar organizing structures that are not really regular concepts. I'm
> happy that iso-thes has provided more options for representing
> not-so-simple structures, but it doesn't solve all issues either.
>
> *FINAL REFLECTION III)* I think that the definition of ad-hoc documented
>> and persistent properties are an optimal scenario for this situation...
>> at least while SKOS not be revised to incorporate some properties for
>> use cases (more general that I can think). But sincerely,*I think that
>> SKOS must not be revised: keep in mind that ISO-THES gives to SKOS new
>> possibilities that have yet to be exploited.*
>>
>
> Yes, starting with ad-hoc but well documented (as you have done!)
> extensions is a good starting point for further discussion and in some
> cases eventual standardization of extensions. I've done similar things in
> the past too (see http://schema.onki.fi/skosext/ - remember this was
> before ISO 25964).
>
> Revising SKOS doesn't seem likely at this point. Maybe some time in the
> future there is enough critical mass or energy to revise, but what we have
> right now in SKOS and iso-thes is good enough for most purposes.
>
> -Osma
>
> --
> Osma Suominen
> D.Sc. (Tech), Information Systems Specialist
> National Library of Finland
> P.O. Box 26 (Kaikukatu 4)
> 00014 HELSINGIN YLIOPISTO
> Tel. +358 50 3199529
> osma.suominen@helsinki.fi
> http://www.nationallibrary.fi
>
>


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