Re: referencing a subset of concepts as the code list of some referrer's property

Hi Thomas,

As explained in [1] I don't like the idea replacing skos:ConceptScheme by a sub-class of skos:Concept as introduced in [2]. But it's still ok to have a sub-class of skos:Concept coined next to a concept scheme, and defined using it. That being said, it can be preferable to skip the introduction of an explicit class, as I did in [1] with the definition of my:property1 using an rdfs:range/owl:allValuesFrom/owl:oneOf pattern.
In fact my solution in [1] is an objection to your "cannot be used in rdfs:range". skos:ConceptScheme (and of course skos:Collection) can be used in rdfs:range the way you want it, it's just that it's more complex than what you would dream of.

Note that from the technical perspective of a OWL reasoner, it makes no real difference. These constructions (i.e., a range constructed from a concept scheme or a range using an explicit sub-class of skos:Concept) are logically equivalent. It really just depends on where you prefer to put the cursor in terms of ontology conception, i.e., minimizing the number of classes vs. making more classes explicit.

Now, you may ask about recommended practice. 2 can be deployed with concept schemes or collection alike, as my proposed more complex definition can use concept scheme or collection indifferently. Both could use in fact other constructions... So it boil down to chosing between collections and concept schemes for grouping concepts.
Well, I'm pretty sure to disappoint you then. Whatever grouping is relevant as "value range" of your property may fit!
Some approaches, like DCAM "vocabulary encoding schemes" will work much better with concept schemes [2]. And I think most of the cases I can think of would fit in here.
But if your property case dictate to use some sub-grouping of an existing scheme, I don't see any objection. For example one could want to create my:designType property for a class my:Chair, and you restrict the values to belong to AAT's <chairs by design> [3], which can be represented as a skos:Collection.
It could be another type of grouping, either a refinement of concept scheme or collection such as MADS/RDF's MADSCollection [4], or a new kind of grouping. The rdfs:range/owl:allValuesFrom/owl:oneOf pattern can accommodate anything.

Best,

Antoine

[1] http://lists.w3.org/Archives/Public/public-esw-thes/2012Aug/0013.html
[2] http://dublincore.org/documents/profile-guidelines/ , search "Statement template: subject"
[3] http://www.getty.edu/vow/AATHierarchy?find=armchairs&logic=AND&note=&page=1&subjectid=300038257
[4] http://www.loc.gov/standards/mads/rdf/#t24


> Hi Antoine,
>
> so far we have identified three patterns of referencing a subset of a given concept scheme (e.g. AgroVoc):
>
>  1. by skos:ConceptScheme - this would result in nested and/or overlapping concept schemes just to describe a local value set. Cannot be used in rdfs:range.
>  2. by subclasses of skos:Concept - pro: the referrer can simply use rdfs:range; con: a simple value set does not deserve a class in my eyes.
>  3. by skos:Collection - semantically the best fit. I just pick some individual concepts from one or more concept scheme(s) which may be distributed. This does not make a concept scheme or rdfs:Class. It is just my local collection. Cannot be used in rdfs:range.
>
>
> I know all the three patterns are in use and somehow "valid".
> Any reasoner coming along has to understand three patterns of desribing the same kind of reference.
> Quite cumbersome.
> This is why I would like to have a single recommended pattern.
>
> Best regards,
>
> Thomas
>
> 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
>>
>> -------
>>
>> This is about SKOS usage in LOD.
>>
>> Yesterday I sent a post to public-swd-wg@w3.org, but obviously it has not been distributed, although it can be found in the archive.
>> http://lists.w3.org/Archives/Public/public-swd-wg/2012Aug/0000.html
>> public-swd-wg@w3.org isn't very active any more, so public-lod@w3.org might be a better place.
>>
>> Best regards,
>> Thomas
>>
>>
>> -------- Original-Nachricht --------
>> Betreff: referencing a concept scheme as the code list of some referrer's property
>> Datum: Sun, 19 Aug 2012 10:50:05 +0200
>> Von: Thomas Bandholtz <thomas.bandholtz@innoq.com>
>> An: public-swd-wg@w3.org
>>
>>
>> Hi SKOS,
>>
>> I came across several examples where concept schemes are referenced as
>> the code list of some property.
>> Usually this is done by two statements:
>>
>> ex:property rdfs:range skos:Concept ;
>> ex:codeList < [some concept scheme] > .
>>
>> E.g. Data Cubes and geonames use this pattern, but one uses qb:codeList
>> to point to the scheme, the other gn:featureClass.
>>
>> Regarding this, I have two questions:
>>
>> (1) does someone remember a discussion why concept schemes should not be
>> expressed as subclasses of skos:Concept?
>> If subclassing would have been used, any concept scheme could be
>> referenced in a single rdfs:type statement of the concept and a single
>> rdfs:range statement of the referrer.
>>
>> (2) if there are sufficient reasons to insist in the current patterns,
>> shouldn't SKOS be extended by a standard property to be used by
>> referrers when they point to a concept scheme along with a rdfs:range
>> statement?
>>
>> And I add
>> (3) why do we not have mapping properties to link concept schemes from
>> different providers?
>> This cannot be inferred from a given concept mapping, as mapping of some
>> concepts does not imply mappings of their entire schemes.
>>
>> Best regards,
>> Thomas
>>
>
>
> --
> Thomas Bandholtz
> Principal Consultant
>
> innoQ Deutschland GmbH
> Krischerstr. 100,
> D-40789 Monheim am Rhein, Germany
> http://www.innoq.com
> thomas.bandholtz@innoq.com
> +49 178 4049387
>
> http://innoq.com/de/themen/linked-data  (German)
> https://github.com/innoq/iqvoc/wiki/Linked-Data  (English)
>

Received on Tuesday, 28 August 2012 19:26:16 UTC