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

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>

> 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. 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
Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>