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

Sorry, my owl:someValuesFrom should have been owl:allValuesFrom, I guess.

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 Tuesday, 28 August 2012 19:39:46 UTC