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

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
>> [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-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
>>>>
>>
>>
>>
>

Received on Wednesday, 29 August 2012 06:59:54 UTC