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

You're right, Dave--thanks for the correction!
And thanks to Bernard for the additional case. Though there might be a problem with owl:hasValue and "it does not prevent an instance of such a class to belong to another skos:ConceptScheme". My previous owl:someValuesFrom was perhaps a bit more fit for this statement :-)

Antoine


> 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.reynolds@gmail.com <mailto:dave.e.reynolds@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-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/ <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>
>

Received on Wednesday, 29 August 2012 08:53:20 UTC