W3C home > Mailing lists > Public > public-esw-thes@w3.org > August 2012

Re: referencing a concept scheme as the code list of some referrer's property

From: Christophe Dupriez <dupriez@destin.be>
Date: Thu, 23 Aug 2012 12:19:42 +0200
Message-ID: <503603BE.7030107@destin.be>
To: public-esw-thes@w3.org
Another extreme: keep only SKOS properties  from Geonames features:
RDF/XML:
http://www.destin-informatique.com/scheme/skos.jsp?about=featureCodes
I would appreciate comments/suggestions about this "simplification".

By the way, as ASKOSI is also storing usage statistics, I would be very 
grateful for suggestions about places where I could get (API or 
scraping) usage frequencies for these concepts.

I also think at using VOID to republish the gathered usage statistics 
(this concept is used x time by this application for this "role"): any 
existing example of similar VOID use? (for any vocabulary, not 
specifically Geonames!)

Have a nice day!

Christophe

Le 23/08/2012 11:57, Bernard Vatant a écrit :
> Hi Thomas
>
> I've been munching over this issue for maybe as many years as you have :)
> ... but somehow arrived to different conclusions.
>
> Regarding the Geonames example you quote, the Geonames "feature 
> classes" and "feature codes" have been modeled as they are, as 
> skos:ConceptScheme and skos:Concept respectively from the very 
> beginning, and I'm not more keen today than back in 2006 (when 
> geonames ontology was first released) to use subclasses of 
> skos:Concept instead.
> Apologies for the confusing vocabulary but "feature class" and 
> "feature code" were named that way in Geonames data base, and when 
> building the geonames ontology I did want to respect the "local" 
> vocabulary, coming from the original NGA classification. See 
> http://www.geonames.org/export/codes.html for the current Geonames 
> codes and http://geonames.nga.mil/ggmagaz/feadesgsearchhtml.asp for 
> the original ones.
>
> If you take the list of codes in the "class" "S" it's actually a 
> finite, arbitrary and likely to evolve, list of codes with an informal 
> description. If I model this stuff as a subclass of skos:Concept, and 
> hence as either rdfs:Class or owl:Class I could not give any logical 
> definition of this class, because there is none. Using a 
> skos:ConceptScheme here, defined only by enumeration, and not a 
> subclass of skos:Concept, is very handy.
>
> In conclusion it seems to me that skos:ConceptScheme has indeed a 
> specific niche in KOS.
> OTOH I never use skos:Collection, every time I have tried, people I 
> was working with had all a different notion of what it should be used 
> for, so I'm totally confused now about it :)
>
> Bernard
>
>
> 2012/8/23 Thomas Bandholtz <thomas.bandholtz@innoq.com 
> <mailto:thomas.bandholtz@innoq.com>>
>
>     Hi Antoine and CCs and everybody,
>
>     nice answer, and I'm glad you have detected my question in this
>     haystack.
>     I think I have to tell more about the context of this question.
>
>     We have a new R&D project about Linking Open Environment Data [1].
>     Here we try to bring together Data Cubes (prefix qb:) [2], SKOS, DCAT,
>     VoID, etc.
>
>     In Data Cubes, dimension properties are defined having rdfs:range
>     skos:Concept + qb:codeList rdfs:range skos:ConceptScheme.
>     Fine so far.
>
>     We have also developed iQvoc [3] in the previous years following the
>     pattern described by SKOS in [4]: "The notion of an individual SKOS
>     concept scheme corresponds roughly to the notion of an individual
>     thesaurus". The technical consequence has been (so far) serving a
>     single
>     concept scheme per iQvoc instance, and we may link multiple concept
>     schemes by SKOS mapping properties between such instances.
>     Fine as well so far.
>
>     Now we have some quite large concept schemes, and a single dimension
>     property cannot refer to entire the concept scheme (= thesaurus)
>     as its
>     value set, but only to a subset. So we have established the pattern of
>     expressing such subsets by one skos:Collection per referring property.
>     Fine again, but different from the qb: pattern (which is also used by
>     geonames, but with a different property: gn:featureClass).
>
>     If we have many dimension properties, each of them referring to a
>     small
>     subset of concepts as the value set, and we want to follow  Data Cubes
>     (or GeoNames), and use iQvoc, we would have to deploy many iQvoc
>     instances each of them containing just a single value set. This would
>     break the overall thesaurus into pieces.
>
>     Of course we can write some lines of OWL code so that a reasoner can
>     infer a dedicated concept scheme for all skos:member instances of each
>     skos:Collection, but ...
>
>     All this raised the question if it wouldn' have been better either
>     to ...
>
>     (a) define one single pattern as part of the SKOS standard how to
>     specify any subset of skos:Concept individuals as the value set of a
>     property,
>
>     (b) strictly use subclasses of skos:Concept to describe any kind of
>     subsets of skos:Concept individuals, so nobody would need any kind of
>     attachment to the rdfs:range to refer to this subset.
>
>     (b) is my preferred solution of (a).
>
>     After thinking this over more and more, I find that the given
>     definition
>     of skos:ConceptScheme has introduced a fatal and completely needless
>     structural redundancy. This could have been avoided by deciding
>     for (b).
>
>     To be more general:
>
>     skos:ConceptScheme priotises domain conventions over common and shared
>     (better: to be shared) RDFS/OWL patterns.
>
>     I found something similar in the Data Structure Definition of Data
>     Cubes. Dave (cc) will understand, as we had some discussion about this
>     topic ;-)
>
>     I strictly believe it is a better strategy to convince each domain
>     inheritance of a single global standard with only few
>     indispensable options.
>
>     Following each of the aquainted  domain pattern leeds to structural
>     weakness  of this one global standard, as everything can be expressed
>     using multiple patterns even though one pattern can fit all. In
>     the open
>     world, each reasoner needs to understand all those domain patterns.
>     This is a quite obscure requirement.
>
>     Dave et al. is conciliatory with SDMX and weakens RDFS/OWL by this.
>     SKOS is conciliatory with the ISO thesaurus people and weakens
>     RDFS/OWL
>     by this.
>     The same happens more and more in any domain, and may be it is too
>     late
>     to stop this, or even roll this back.
>
>     I am quite sad about this.
>     Unfortunately, W3C has no clear governance in this question (@Sandro).
>     Sometimes I feel a working draft becomes a recommendation only by
>     public
>     rating in some domain which has no understanding of the power of pure
>     RDFS/OWL .
>
>     Sorry if I have taken so much of your time, if you have read until
>     here.
>
>     Finally I quote some lines from Neill Young: "Ambulance Blues"
>     which may
>     talk about myself:
>
>     "And I still can hear him say:
>     You're all just pissin' in the wind
>     You don't know it but you are".
>
>     Think I even know it.
>
>     Best regards,
>     Thomas
>
>
>
>     [1] http://innoq.github.com/led/
>     [2] http://www.w3.org/TR/vocab-data-cube/
>     [3] https://github.com/innoq/iqvoc/
>     [4] http://www.w3.org/TR/2009/REC-skos-reference-20090818/#L1101
>
>     Am 22.08.2012 21:15, schrieb Antoine Isaac:
>     > Dear Thomas,
>     >
>     > I'm ccing public-esw-thes@w3.org
>     <mailto:public-esw-thes@w3.org>. Perhaps this was the one you were
>     > looking for!
>     >
>     > (1) & (2)
>     > You probably mean, if a ConceptScheme could be defined as a
>     class, of
>     > which the concepts of a given concept scheme are instances?
>     > That would be the way to proceed, if you want to use the concept
>     > scheme directly as the range of a property.
>     > This is has never been suggested for inclusion in SKOS. In fact
>     it is
>     > not forbidden, either. You can assert rdf:type statements between
>     > concepts and a concept scheme, if you want.
>     > You can also define an adhoc sub-class of skos:Concept (say,
>     > ex:ConceptOfSchemeX), which includes all concepts that related to a
>     > specific concept scheme (ex:SchemeX) by skos:inScheme
>     statements. This
>     > is quite easy using OWL. And then you can use this new class as the
>     > rdf:range.
>     >
>     > The possibility of these two options makes it less obvious, why
>     there
>     > should be a specific feature in SKOS to represent what you want.
>     > But more fundamentally, it was perhaps never discussed, because it's
>     > neither a 100% SKOS problem, nor a simple one.
>     > It's a bit like the link between a document and a subject concept:
>     > there could have been a skos:subject property, but it was argued
>     that
>     > Dublin Core's dc:subject was good enough.
>     > But it's maybe even worse than that :-) There are indeed discussions
>     > in the Dublin Core Architecture community about represent the link
>     > between a property and a concept scheme directly, similar to
>     what you
>     > want. This is what is called vocabulary/value "encoding schemes"
>     there
>     > [1].
>     > But the existence of this feature at a quite deep, data-model level,
>     > rather confirms for me that it is something that clearly couldn't be
>     > tackled at the time SKOS was made a standard. One can view this
>     > problem as one of modeling RDFS/OWL properties, rather than
>     > representing concepts, no?
>     >
>     >
>     > (3)
>     > I'm not sure I get the question. If they exist, such mapping
>     > properties could be very difficult to semantically define. Would a
>     > concept scheme be broader, equivalent, narrower than another one?
>     > Rather, I'd say that the property you're after indicates that some
>     > concepts from these two concept schemes are connected. For this I
>     > think one could use general linkage properties between datasets,
>     such
>     > as voiD's linksets [2].
>     >
>     > I hope that helps,
>     >
>     > Antoine
>     >
>     > [1] http://dublincore.org/documents/profile-guidelines/ , search
>     > "Statement template: subject"
>     > [2] http://vocab.deri.ie/void
>     >
>     > -------
>     >
>     > This is about SKOS usage in LOD.
>     >
>     > Yesterday I sent a post to public-swd-wg@w3.org
>     <mailto:public-swd-wg@w3.org>, but obviously it has
>     > not been distributed, although it can be found in the archive.
>     > http://lists.w3.org/Archives/Public/public-swd-wg/2012Aug/0000.html
>     > public-swd-wg@w3.org <mailto:public-swd-wg@w3.org> isn't very
>     active any more, so public-lod@w3.org <mailto:public-lod@w3.org>
>     > might be a better place.
>     >
>     > Best regards,
>     > Thomas
>     >
>     >
>     > -------- Original-Nachricht --------
>     > Betreff:     referencing a concept scheme as the code list of some
>     > referrer's property
>     > Datum:     Sun, 19 Aug 2012 10:50:05 +0200
>     > Von:     Thomas Bandholtz <thomas.bandholtz@innoq.com
>     <mailto:thomas.bandholtz@innoq.com>>
>     > An: public-swd-wg@w3.org <mailto:public-swd-wg@w3.org>
>     >
>     >
>     > Hi SKOS,
>     >
>     > I came across several examples where concept schemes are
>     referenced as
>     > the code list of some property.
>     > Usually this is done by two statements:
>     >
>     > ex:property rdfs:range skos:Concept ;
>     >         ex:codeList < [some concept scheme] > .
>     >
>     > E.g. Data Cubes and geonames use this pattern, but one uses
>     qb:codeList
>     > to point to the scheme, the other gn:featureClass.
>     >
>     > Regarding this, I have two questions:
>     >
>     > (1) does someone remember a discussion why concept schemes
>     should not be
>     > expressed as subclasses of skos:Concept?
>     > If subclassing  would have been used, any concept scheme could be
>     > referenced in a single rdfs:type statement of the concept and a
>     single
>     > rdfs:range statement of the referrer.
>     >
>     > (2) if there are sufficient reasons to insist in the current
>     patterns,
>     > shouldn't SKOS be extended by a standard property to be used by
>     > referrers when they point to a concept scheme along with  a
>     rdfs:range
>     > statement?
>     >
>     > And I add
>     > (3) why do we not have mapping properties to link concept
>     schemes from
>     > different providers?
>     > This cannot be inferred from a given concept mapping, as mapping
>     of some
>     > concepts does not imply mappings of their entire schemes.
>     >
>     > Best regards,
>     > Thomas
>     >
>
>
>     --
>     Thomas Bandholtz
>     Principal Consultant
>
>     innoQ Deutschland GmbH
>     Krischerstr. 100,
>     D-40789 Monheim am Rhein, Germany
>     http://www.innoq.com
>     thomas.bandholtz@innoq.com <mailto:thomas.bandholtz@innoq.com>
>     +49 178 4049387 <tel:%2B49%20178%204049387>
>
>     http://innoq.com/de/themen/linked-data (German)
>     https://github.com/innoq/iqvoc/wiki/Linked-Data (English)
>
>
>
>
>
> -- 
> *Bernard Vatant
> *
> Vocabularies & Data Engineering
> Tel : + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> Blog : the wheel and the hub <http://blog.hubjects.com/>
>
> --------------------------------------------------------
> *Mondeca*****
> 3 cité Nollez 75018 Paris, France
> www.mondeca.com <http://www.mondeca.com/>
> Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
>
Received on Thursday, 23 August 2012 10:20:19 UTC

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