- From: Osma Suominen <osma.suominen@helsinki.fi>
- Date: Mon, 21 Sep 2015 10:17:01 +0300
- To: public-esw-thes@w3.org
Dear Juan,
This isn't exactly CBD, but below is the SPARQL query that the most
recent version of Skosmos (1.2 released last week) performs to get all
the relevant information about a concept.
In this example the query is targeted at the UNESCO Thesaurus concept
"Graph theory" (http://skos.um.es/unescothes/C01721).
Skosmos uses this query to collect all information about a concept for
the purpose of creating a web page describing the concept. See here for
the result: http://skosmos.dev.finto.fi/unesco/en/page/C01721
Also the same query is used for creating the RDF/XML and Turtle
representations. You can find them linked from the above page.
The reason there are so many UNIONs is to avoid internal duplication of
results (unrestricted cross product joins) and so keep the query
efficient. Typical query execution time using Jena Fuseki is about 10-15 ms.
-Osma
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
CONSTRUCT {
?s ?p ?uri .
?sp ?uri ?op .
?uri ?p ?o .
?p rdfs:label ?proplabel .
?p rdfs:subPropertyOf ?pp .
?pp rdfs:label ?plabel .
?o rdf:type ?ot .
?o skos:prefLabel ?opl .
?o rdfs:label ?ol .
?o rdf:value ?ov .
?directgroup skos:member ?uri .
?parent skos:member ?group .
?group skos:prefLabel ?grouplabel .
?group rdf:type ?grouptype .
} WHERE {
GRAPH <http://skos.um.es/unescothes/> {
{ ?s ?p ?uri . }
UNION
{ ?sp ?uri ?op . }
UNION
{
?directgroup skos:member ?uri .
?group skos:member+ ?uri .
?group skos:prefLabel ?grouplabel .
?group rdf:type ?grouptype .
OPTIONAL { ?parent skos:member ?group }
}
UNION
{
?uri ?p ?o .
OPTIONAL {
{ ?p rdfs:label ?proplabel . }
UNION
{ ?p rdfs:subPropertyOf ?pp . }
UNION
{ ?o rdf:type ?ot . }
UNION
{ ?o skos:prefLabel ?opl . }
UNION
{ ?o rdfs:label ?ol . }
UNION
{ ?o rdf:value ?ov . }
}
}
}
VALUES (?uri) { (<http://skos.um.es/unescothes/C01721>) }
}
On 19/09/15 00:18, 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>
--
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
Received on Monday, 21 September 2015 07:17:33 UTC