Hi all
I'm with Antoine and Dave on this - as previously written (I think).
owl:hasValue is indeed a nice and too much overlooked OWL construct allowing to
define a class based on any property-value pair, e.g.,
"A "Blue Thing" is a Thing of which property "color" has value "Blue"
ex:BlueThing a owl:Class
owl:equivalentClass
[a owl:Restriction;
owl:onProperty ex:color ;
owl:hasValue ex:Blue]
Which is the way natural language and underlying unformal typing works,
actually. We organize the world naturally using property values, then abstract
some property-value pairs into formal classes. t
x rdf:type ex:BlueThing
is no more no less than a more abstract property-value pair expresssion of
x ex:color ex:Blue
Note that by this definition a Blue Thing can have other values of "color", which means
it's not necessarily "completely blue".
So you can always construct a subclass of skos:Concept by a similar restriction
on skos:inScheme, as Dave below.
The interesting aspect of this construction is that it does not prevent an
instance of such a class to belong to another skos:ConceptScheme ...
Bernard
2012/8/29 Dave Reynolds <dave.e.reyno...@gmail.com
<mailto:dave.e.reyno...@gmail.com>>
On 28/08/12 20:39, Antoine Isaac wrote:
Sorry, my owl:someValuesFrom should have been owl:allValuesFrom, I
guess.
Actually I think owl:someValuesFrom is right though the easiest construct
is owl:hasValue :
some:codeAConcept owl:equivalentClass [
owl:intersectionOf ( skos:Concept
[ rdf:type owl:Restriction ;
owl:onProperty skos:inScheme ;
owl:hasValue some:codeAConceptScheme ]
)
] .
I agree with the rest of your comments.
Dave
Antoine
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
<http://lists.w3.org/Archives/Public/public-lod/2012Aug/0060.html>
[2] http://lists.w3.org/Archives/__Public/public-lod/2012Aug/__0063.html
<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/
<http://www.w3.org/TR/vocab-data-cube/>
[3] https://github.com/innoq/__iqvoc/
<https://github.com/innoq/iqvoc/>
[4] http://www.w3.org/TR/2009/REC-__skos-reference-20090818/#L1101
<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
<mailto: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/
<http://dublincore.org/documents/profile-guidelines/> , search
"Statement template: subject"
[2] http://vocab.deri.ie/void
--
*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>
