- From: Christophe Dupriez <dupriez@destin.be>
- Date: Thu, 23 Aug 2012 12:19:42 +0200
- To: public-esw-thes@w3.org
- Message-ID: <503603BE.7030107@destin.be>
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