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

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>

> 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. 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, 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 isn't very active any more, so 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>
> > An:     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
> +49 178 4049387
>
> 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
Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>