- From: Juan Antonio Pastor Sánchez <pastor@um.es>
- Date: Thu, 17 Sep 2015 16:48:03 +0200
- To: Osma Suominen <osma.suominen@helsinki.fi>
- Cc: public-esw-thes@w3.org
- Message-ID: <CAFkhdr9=MY6LGA=CCPQ8L+Mj_EzYG-Ld1u=RpnWrm5M8W8Zf-w@mail.gmail.com>
Dears Osma and Armando,
Thank you very much for your observations. I find very usefull and
sugestive all your comments. Really, I undertand your point of view. Even I
agree with you in many cases.
However, I think that I must explain better the reasons that lead us to
create the UNESKOS vocabulary. The UNESCO Thesaurus (and the Nomenclature)
are avalaible in differents formats by content negotiation. One of this
formats is XHTML-RDFa. In the first versión, we create the links from a
Concept to its Collection (Micro-Thesaurus) throught a SPARQL query and did
the same to connect a Concept Scheme with the Collections, and from the
Collection to the Top Concepts. The problem is that:
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
*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).
*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.
*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.
*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.
*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.*
Best,
Juan
P.S.: I find this discussion very stimulant....
2015-09-16 20:13 GMT+02:00 Osma Suominen <osma.suominen@helsinki.fi>:
> Dear Juan,
>
> I am very sorry for my unclear brief comments. I didn't mean that you
> wanted to introduce changes to SKOS, and certainly didn't intend to
> restrict you from creating and publishing UNESKOS. Rather, my thoughts are
> along these lines:
>
> 1. Having an inverse property for {skos:inScheme,skos:member} has nothing
> to do with the *content* of the UNESCO Thesaurus. In my impression, the
> content in the UNESCO Thesaurus very closely follows standards and best
> practices. The only slightly special aspect in UNESCO Thesaurus that I'm
> aware of is the use of microthesauri, but that is not relevant for this
> discussion, at least not for the above mentioned SKOS properties.
>
> 2. Thus, if there is a good reason for introducing such properties, that
> reason should equally apply to all SKOS datasets, or at least many of them.
>
> 3. Therefore, if such properties are introduced, a good place to define
> them would be SKOS itself, or a general purpose SKOS extension similar to
> iso-thes or perhaps the GVP extensions to SKOS. Not a thesaurus-specific
> vocabulary such as UNESKOS.
>
> Armando already explained that there may be good reasons why such
> properties were not defined by SKOS itself. In some cases it simply makes
> sense to keep the model simpler by not introducing many properties. There
> are also practical concerns like Armando mentioned - for example, DESCRIBE
> queries returning way too much data, or having to generate RDFa markup for
> tens of thousands of concepts on the HTML page of the concept scheme. These
> may or may not apply in your specific case. Perhaps the benefit of forward
> direction properties outweighs the potential pitfalls.
>
> You mentioned that getting from the ConceptScheme to, e.g., microthesauri
> represented by ConceptGroup, is impossible, because of the inverse property
> between these. But this assumes that you can only follow properties from
> subject to object. Why this restriction? Obviously CBD is defined in such a
> way, but Linked Data representations can equally well serve Symmetric
> Concise Bounded Descriptions (and often do), or use another subset
> definition that includes statements also in the inverse direction.
>
> As I said you are of course free to define and use your own properties as
> you like and, as you noted, your usage is fully compliant with SKOS and
> users may simply ignore your extensions and still get all the information
> from the SKOS properties. By the way, it is excellent that you have made
> such good documentation for UNESKOS, so that it is possible to have this
> discussion!
>
>
> Also, congratulations on the new release of the UNESCO Thesaurus! I've
> played with the earlier version, and also put it up on the Skosmos demo
> site here: http://skosmos.dev.finto.fi/unesco/en/
> (I expect to update the demo installation to the upcoming Skosmos 1.2
> release in the near future, then the microthesauri/groups could also be
> displayed and browsed!)
>
> The UNESCO Thesaurus has been exemplary in itse use of SKOS and RDF. In my
> previous research I've looked at the data quality of many SKOS datasets,
> and the UNESCO Thesaurus was one of the very best!
>
>
> Best regards
> Osma
>
>
>
> 16.09.2015, 15:28, Juan Antonio Pastor Sánchez kirjoitti:
>
>> Dears Armando and Osma
>>
>> Thank you very much for your observations.
>>
>> Osma, sorry, but we don't want to change anything about SKOS. We don't
>> require any SKOS changes. I don't know the reason why you say that. Can
>> you explain me? The UNESKOS vocabulary refers to an vocabulary for and
>> specific case that can be used for others thant find useful our work.
>> *Your affirmation that we want to change SKOS is absolutely false.* Our
>> work complements SKOS, but doesn't replace it. SKOS should continue as
>> is to remain SIMPLE as you think.
>>
>> I think that define a specific vocabulary that *complements* SKOS and
>> ISO-THES is not forbidden (as far as I remember) and this restriction is
>> a kind of dogmatism that goes against the very essence of the Semantic
>> Web. And I don't like it.
>>
>> UNESKOS is designed to complement SKOS and ISO-THES. It isn't an
>> alternative. If fact, if you get the SKOS dataset for the UNESCO
>> Thesaurus and ignore all the statements that have any UNESKOS property
>> the SKOS representations is acording to SKOS and ISO-THES. Certainly,
>> the dataset have been tested with Skosify.
>>
>> The question is: Really, it's necessary a vocabulary that define
>> inverses for several SKOS properties?
>>
>> In my opinion, we must not forget that Linked Data remains the Web and I
>> think that the Information Architecture principles for SKOS dataset are
>> applicable (and useful). Please, as we note in the reference document:
>> don't think that a SPARQL Endpoint it's always avalaible.
>>
>> Think in the home page of a web site that no have links to continue the
>> navigation to the inside contents. The lack the properties from the
>> Concept Schemes to the Concept Groups (that are intended for represent
>> micro-thesaurus) is the same.
>>
>> Please take a wider view and *don't think only in terms of SPARQL*,
>> think in terms of information architecture of the dataset so that it can
>> be reused in other ways to increase interoperability.
>>
>> So, please, think about a scenario in which you don't have an SPARQL
>> Endpoint to query the dataset. An example for this: the HTML version of
>> a vocabulary with RDFa markup that include the RDF statements of the
>> SKOS dataset into the HTML markup. The Concise Bound Description doesn't
>> useful in this case because implies needless and artificial HTML code.
>>
>> One case: From a iso-thes:ConceptGroup (or micro-thesaurus): How can we
>> reach to the top concepts without using SPARQL and applying the
>> SKOS/ISO-THES properties only?
>>
>> In one word: impossible. So this is the meaning of
>> uneskos:hasMainConcept and uneskos:mainConceptOf: Access points to
>> continue (or start) to navigate the hierarchical structure of the
>> thesaurus.
>>
>> Even more: How can we reach from skos:ConceptScheme to
>> iso-thes:ConcepGroup. Impossible, because iso-thes:microThesaurusOf goes
>> on inverse way. So this is the meaning of uneskos:hasMicroThesaurus.
>>
>> The uneskos:memberOf solves the discovery of the Collection/ConceptGroup
>> to which a concept belong without use SPARQL.
>>
>> Repect uneskos:contains. Well, with a depply reading of the reference
>> document you can find:
>>
>> NOTE: It is not necessary the inclusion of uneskos:contains property
>> between the Concept Schemes and the Concepts in the SKOS dataset. In the
>> context of a well designed KOS, it is possible to find a path to any
>> Concept of the KOS starting from the Concept Scheme and the Top
>> Concepts. However, SKOS does not provide any element to discover (i.e.)
>> the Collections of a KOS from the Concept Scheme. The property
>> uneskos:contains covers this need.
>>
>> This is because the first SKOS version of the UNESCO Thesaurus includes
>> statement like this:
>>
>> <Collection> skos:inScheme <Concept_Scheme>
>>
>> And the uneskos:contains property is intended for:
>>
>> <Concept_Scheme> skos:contains <Collection>
>>
>> Best regards,
>> Juan
>>
>>
>> 2015-09-16 13:36 GMT+02:00 Osma Suominen <osma.suominen@helsinki.fi
>> <mailto:osma.suominen@helsinki.fi>>:
>>
>> Hi Juan!
>>
>> My first reaction was the same as Armando's 2nd point, i.e. some of
>> your extensions (namely unesco:contains and unesco:memberOf) are
>> extensions of core SKOS with no inherent relationship to the UNESCO
>> Thesaurus.
>>
>> There are certainly arguments about whether properties should be
>> defined in both directions or not. In this case SKOS has decided to
>> make only one way relationships (at least in these two cases,
>> skos:inScheme and skos:member) and you now want to change that by
>> introducing the inverse properties as well. You can certainly do
>> that for your own thesaurus but I think that sticking to the SKOS
>> properties would be simpler for everyone. In SPARQL and most RDF
>> toolkits it is not very difficult to follow property paths in either
>> direction.
>>
>> -Osma
>>
>>
>>
>> On 16/09/15 11:57, Armando Stellato wrote:
>>
>> Dear Juan,
>>
>> just a couple of notes.
>>
>> 1.Why the word “main” adopted in some property names? I don’t
>> find any
>> rationale for the use of “main” as the concepts do not seem to
>> be “main”
>> at all for the related schemes/collections.
>>
>> 2.Some properties, more than being targeted at a special domain
>> (e.g.
>> UNESCO), seems plain extensions of the core SKOS, aiming at
>> filling some
>> gaps left by it. However in some cases I feel like these gaps
>> were left
>> by purpose. E.g. the uneskos:contains provides an inverse
>> property for
>> skos:inScheme. Think about a 30.000 concepts thesaurus (for
>> which there
>> exists at least a scheme containing all concepts). If you were
>> using the
>> UNESKOS vocabulary, you surely would try a SPARQL DESCRIBE on
>> this main
>> scheme? ;-)
>>
>> a.Use of SPARQL (or -1 expressions in DL) does not strictly
>> require for
>> the presence of named inverse properties for everything. So, why
>> do they
>> exist? Because when you get the description (for example by a
>> DESCRIBE,
>> but not limited to that) of a resource, they can provide nice
>> “resumes”
>> for it. The kind of path you want to realize (see the description
>> of
>> hasMainConcept) can be performed without the strict need of the
>> property. It is up to SKOS browsing tools to allow for that
>> visualization/traversal options.
>>
>> Just my two cents on that,
>>
>> Best regards,
>>
>> Armando
>>
>> *Da:*Juan Antonio Pastor Sánchez [mailto:pastor@um.es
>> <mailto:pastor@um.es>]
>> *Inviato:* mercoledì 16 settembre 2015 02:21
>> *A:* public-esw-thes@w3.org <mailto:public-esw-thes@w3.org>
>> *Oggetto:* UNESKOS Vocabulary and 2nd SKOS version of UNESCO
>> Thesaurus
>>
>> Dear all,
>>
>> I want to communicate the publication Vocabulary UNESKOS that
>> complements certain aspects of SKOS [1] and ISO-THES [2]. This
>> vocabulary is designed in the context of the proposed UNESKOS,
>> more
>> specifically for the SKOS representation of the UNESCO Thesaurus.
>>
>> The document describing the vocabulary is available at:
>>
>> * http://skos.um.es/TR/uneskos
>>
>> The RDF vocabulary is available for download and use from the
>> UNESKOS
>> namespace:
>>
>> * http://purl.org/umu/uneskos# <http://purl.org/umu/uneskos>
>>
>> Likewise, the 2nd SKOS version of the UNESCO Thesaurus is
>> available at:
>>
>> * http://skos.um.es/unescothes
>>
>> Includes following features:
>>
>> * Persistent and Dereferenceable URIs.
>> * Turtle and RDF/XML Datasets avalaible for download.
>> * RDFa markup.
>> * SPARQL Endpoint.
>> * Content negotiation avalaible in N3, JSON-LD, etc...
>>
>> This second version makes use of SKOS, ISO-THES and UNESKOS.
>> Along the
>> coming weeks new features navigation within the HTML version
>> will be added.
>>
>> Please, for any suggestion or correction you can contact me.
>>
>> Best regards,
>>
>> Juan
>>
>> --
>>
>> 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>>
>>
>>
>>
>> --
>> 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
>
>
--
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
Received on Thursday, 17 September 2015 14:48:39 UTC