Hi Thomas, all,
I disagree with you on the fact that sub-classing skos:Concept would solve all
representation needs. There is data to be asserted at the concept scheme-level,
which would be inappropriately captured when being directly attached to a class
of concepts. E.g., the creator of a concept scheme or the rights attached to
it. These will stick very badly a class in an OWL ontology that represent the
concept scheme. At least (OWL) class and annotation properties are created
usually.
Also, concepts are not "instances of a concept schemes". It is really
stretching the way concepts and vocabularies are viewed in the domain, as already
mentioned by others. Plus, doing this would also break the fundamentally good pattern
followed by SKOS: SKOS data can entirely remain at the instance level (in OWL terms).
When one ports a thesaurus on the Semantic Web, one doesn't want to be forced to use
RDFS/OWL features in the data published.
Of course SKOS resources can be used to create OWL ontologies. But I think it's
better that this remains the business of an ontology creator (the guy creating
the property that admit values from a given concept scheme) and not the
business of a KOS publisher.
So yes I really dislike using some:codeA and some:codeB as Simon does in [1]. I
mean, having them is not bad, but having no concept scheme that bothers me.
I would really prefer the approach that consists of (OWL) defining
some:codeAConcept
as
some:codeAConcept owl:equivalentClass [
owl:intersectionOf ( skos:Concept
[ rdf:type owl:Restriction ;
owl:onProperty skos:inScheme ;
owl:someValuesFrom [ owl:oneOf (
some:codeAConceptScheme )] ]
)
] .
and then you use some:codeAConcept as the range of your my:property1 and keep
some:codeAScheme carrying its scheme-level data.
Or in fact, if you hate redundancy, you can create straight away your new
property as:
my:property1 rdfs:range [
owl:intersectionOf ( skos:Concept
[ rdf:type owl:Restriction ;
owl:onProperty skos:inScheme ;
owl:someValuesFrom [ owl:oneOf (
some:codeAConceptScheme )] ]
)
] .
I understand you may want a construct to directly relate a property to a
concept scheme to constrain its values. But then it is really about adding some
new (meta-modelling) feature which was not identified in the SKOS requirements.
And as said in my previous mail, for now I'd rather leave it to initiatives
(like DC) which address data modelling at a deeper level.
And in fact such feature would still be a shorthand for something that is
possible using OWL out-of-the-box.
Best,
Antoine
PS: by the way, I also disagree on merging (license or more generally any kind
of provenance) data on the (voiD) dataset and data on a ConceptScheme, as
hinted in [2]. In the past a project I've worked for has created a version of
the RAMEAU vocabulary, based on a snapshot from the official version [4]. I
think it was a good thing that people could make the difference between the
real vocabulary and the prototype dataset we had created. In other terms,
keeping distinct the thing that is represented from the dataset that represents
it -- another good pattern to follow, I think!
[1] http://lists.w3.org/Archives/Public/public-lod/2012Aug/0060.html
[2] http://lists.w3.org/Archives/Public/public-lod/2012Aug/0063.html
[3] http://stitch.cs.vu.nl/rameau
[4] http://rameau.bnf.fr
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-t...@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