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

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)