W3C home > Mailing lists > Public > public-esw-thes@w3.org > November 2009

AW: AW: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?

From: Neubert Joachim <J.Neubert@zbw.eu>
Date: Thu, 5 Nov 2009 18:52:45 +0100
Message-ID: <3A59BB6451C972429019B12996F92DAD02B18A62@frodo.zbw-nett.zbw-kiel.de>
To: "Simon Reinhardt" <simon.reinhardt@koeln.de>
Cc: "Richard Cyganiak" <richard@cyganiak.de>, <dbpedia-discussion@lists.sourceforge.net>, "SKOS" <public-esw-thes@w3.org>, "Pat Hayes" <phayes@ihmc.us>
Hi Simon,
Sorry for causing some misunderstanding: My point was not that you SHOULD use skos:Concept. What I rather wanted to say is that it does no harm and that it's already in use for named entites. 
This point arises from the suggestion to use skos:exactMatch/closeMatch. These properties are sub-sub-properties of skos:semanticRelation, which entails that subject and object of these properties are instances of skos:Concept (since skos:Concept are domain and range for skos:semanticRelation).
The great advantage of skos:exactMatch/closeMatch (over owl:sameAs) is that their semantic doesn't smush the resources with all their properties (like the administrative properties you mentioned).
The reason why I prefer skos:exactMatch/closeMatch to the suggested UMBEL properties is that, as an W3C Recommendation with a lot of implementations already, SKOS  is more widespread (and maybe more stable). So I expect better  immediate understandig and more tool support for the skos properties. However, this may be the biased view of a long-term thesaurus/KOS afficinado ...
Cheers, Joachim


Von: Simon Reinhardt [mailto:simon.reinhardt@koeln.de]
Gesendet: Do 05.11.2009 17:35
An: Neubert Joachim
Cc: Richard Cyganiak; dbpedia-discussion@lists.sourceforge.net; SKOS; Pat Hayes
Betreff: Re: AW: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?


Neubert Joachim wrote:
> In my eyes, it's completely ok to use skos:exactMatch or skos:closeMatch
> in a situation like this (I did it myself for the STW Thesaurus for
> Economics mapping to dbpedia).
> Thesauri and classifications are not restricted to abstract concepts.
> Some thesauri deal explicitly with individual things, e.g. the widely
> used Getty "Thesaurus of Geographic Names" or "Union List of Artist
> Names". Other thesauri (like STW) have sections (or facets, as Leonard
> put it) on geografic names along with others containing "pure" concepts.
> SKOS, as I understand it, is intended to cover all this and to be used
> beyond strict class hierarchies or class/individual dichotomies.

While I agree that using real-world entities for classification is ok I don't think this means you have to declare them to be (skos:)concepts. The "has subject" relationship in FRBR [1] for example can link a work to a concept but also to places, people, events, other works, etc. So in this case you can use real-world entities to classify the work (to state what its subjects are) but that doesn't mean you declare all those entities to be conceptual.

So in my eyes there's still value in keeping (skos:)concepts and other things apart. Concepts to me are closer to classes than to individuals. And as Dan pointed out concepts have administrative data attached - they get created and changed etc. so they're basically units of organisation.

I'd therefore prefer using the UMBEL terms or something else for aligning real-world entities and concepts.

> By the way, some of the SKOS properties (especially the
> prefLabel/altLabel/hiddenLabel semantics) can be useful in a broad range
> of applications. Eg. dbpedia itself could be used as a great source for
> synonym candidates by mapping the resources to skos:Concept and the
> labels for dbpedia:redirect resources to skos:altLabel.

Yup, it has a lot of useful annotation terms. They are all declared to be annotation properties and deliberately don't have skos:Concept in their domain. So you can use them on anything which is great!


[1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 - scroll down to "5.2.3 Subject Relationships"
Received on Thursday, 5 November 2009 17:53:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:59 UTC