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

Thomas - 

I've come to the same conclusion. 

my:property1 rdfs:range some:codeA .
my:property2 rdfs:range some:codeB .
some:codeA rdfs:subClassOf skos:Concept . 
some:codeB rdfs:subClassOf skos:Concept . 
some:item1 a some:codeA . # also a skos:Concept because of subclass relationship
some:item2 a some:codeA . 
some:item3 a some:codeA . 
some:item4 a some:codeB , some:codeA . 
some:item5 a some:codeB . 

All of the items can be in the same ConceptScheme and in the same repo, but the ConceptScheme is not used explicitly in the ontology using the concepts. 

Simon Cox

-----Original Message-----
From: Thomas Bandholtz [mailto:thomas.bandholtz@innoq.com] 
Sent: Thursday, 23 August 2012 8:07 AM
To: public-esw-thes@w3.org; <public-lod@w3.org>
Cc: dave.e.reynolds@gmail.com; sandro@w3.org; Till Schulte-Coerne
Subject: Re: referencing a concept scheme as the code list of some referrer's property

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)

Received on Thursday, 23 August 2012 02:15:21 UTC