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

Hi everyone,

Jumping in a bit late. Many things have been said indeed in a couple of days. And this is a very interesting discussion indeed!
Whatever one thinks about whether the elements are needed or not, the extension is a great example of how to do this sort of things. Well done.
(and I can't resist a play on words like uneskos ;-) )

Among the general points raised, the elements seem indeed not really specific to the Unesco thesaurus, but well there is no new version of SKOS planned...
ISO-THES could be an option... And maybe actually there can be an update of that domain to fit a couple of the Uneskos properties. Juan, would this be interesting for you, in the future?

About some more specific elements in the discussion:

- RDFa has @rev, which removes the need for reverse properties, to a great extent. I agree a lot with Osma here...

- There is no relation between Collections and ConceptScheme in SKOS because it was unclear whether Collections should always be member of a ConceptScheme, in the first place.
It might have been that some Collections are introduced as a grouping mechnism, which is not really essential to what make the ConceptScheme.
That said, once some types of Collections (like micro-thesauri) are provided with clearer semantics that relate them to "concept scheme design" motivations, then it makes sense to have such link for them.

- hasMainConcept seems quite a good idea. The notion of "prefered entry point" can be really useful, following the hasTopConcept example. My problem is that the current Uneskos doc is a bit weaker than Juan Antonio's points in the thread! I think it could be also very useful to show a collection with plenty "basic" concept, to show the interest (and the method) for identifying main entry points in these collections.

- there's been some discussion at one point about keeping both skos:narrower and skos:broader in the SKOS voc.
One of the serious arguments in the end was that the thesaurus standards had both NT and BT, and that some thesaurus publishers may just prefer to publish the data as it was in the legacy models. This is a time where pragmatism (facilitating SKOS adoption) has been privileged over elegance of model.
There might have been other reasons, but this was certainly one.

Cheers,

Antoine

[1] btw Juan, there's a typo "unekos:" in the doc.

On 9/18/15 11:18 PM, Juan Antonio Pastor Sánchez wrote:
> 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 <mailto: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 <tel:%2B358%2050%203199529>
>     osma.suominen@helsinki.fi <mailto: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 <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
> http://webs.um.es/pastor
> pastor@um.es <mailto:pastor@um.es>

Received on Sunday, 20 September 2015 17:21:31 UTC