Re: [SKOS] on ISSUE-36, ISSUE-39, ISSUE-47 mapping and concept scheme provenance and (was Re: [SKOS] central issues)

Hi Jon,

Before answering in detail, a point concerning the discussion we had 
during the teleconf. It seems to me that your objection in this 
discussion is mainly about using skos:broader between concepts from 
different CS, not about having concepts in multiple concept scheme.

> I think it's important to consider the value of the SKOS mapping 
> vocabulary [3] in all of this. Mapping doesn't infer or require the 
> assertion of explicit semantic properties and doesn't require 
> endorsement by a Concept or CS owner. [1]

I'm puzzled by this: mapping to me does result in semantic links between 
concepts. Hence my proposal to use existing semantic links for it. 
Furthermore, provenance is important for mappings: usually I will like 
to know the source of the mapping before taking it for granted. (and 
indeed I think you're amongst the ones responsible for the raising of 
ISSUE-47 on mapping provenance ;-) (

> So it allows the assertion of relationships while maintaining the 
> intellectual integrity of the related Concepts.
> It seems to me that it might be a useful resolution to some of this to 
> dust off the SKOS mapping vocabulary and think about how that might be 
> extended to allow inter-Scheme Concept semantic relations to be 
> defined without requiring the assertion of those relationships as 
> Concept properties.

By concept properties do you mean SKOS core semantic relationship?

>>>> Yes, good to sort this out. As a general rule I would like to adopt 
>>>> that we follow the principle of least ontological commitment, 
>>>> unless we have clear eveidence to the contrary. So, in this case, 
>>>> if we have no hard pro's and con's for allowing skos:Concepts to be 
>>>> part of ultiple schemes, we should refrain from specifying the 
>>>> constraint. For the broader-narrower term there is actually a 
>>>> strong reason in favor of not limiting it to concepts within one 
>>>> scheme - see the the mappping stuff Antoine mentions.
>>>> Guus
>>> Guus,
>>> I'm not sure I agree, and would like to present some clear evidence 
>>> to the contrary.
>>> The Metadata Registry use case includes a notion of concept/scheme 
>>> management that requires ownership by an agent of a concept scheme, 
>>> its related concepts, and their properties. We've struggled a bit 
>>> with the idea that a concept may have properties that are _inferred_ 
>>> by the assertion of a bidirectional relationship, rather than 
>>> explicitly asserted by the concept owner. [1]
>>> We have come to feel quite strongly that thesaural relationships, 
>>> such as BT, NT, and RT, between concepts represent assertions of 
>>> semantically meaningful concept properties. If the assertion is made 
>>> in the context of a concept over which the owner has no control, 
>>> then that assertion requires the explicit endorsement by the owner 
>>> of the target concept in order to maintain the integrity of the 
>>> concept. [1]
>> Consider a scenario when you want to locally extend a general 
>> vocabulary (e.g. containing A) by your own concepts (e.g. B). If I 
>> understand you well, you cannot do so using B skos:broader A, unless 
>> you ask to the concept scheme authority to acknowledge and control 
>> the way your link could change the meaning of A?
> Yes. Extending a scheme by inference would require explicit 
> endorsement of the inference by the scheme/concept owner. In which 
> case all SKOS properties would need some sort of  'status' attribute 
> which would allow such endorsement to be stated. (This is what we do 
> in the Registry [1])
>> Well I think I understand your motivation, but I think it could be 
>> harmful: it prevents easy extension. Also, playing the devil's 
>> advocate I can foresee big problems if you want to generalize your 
>> point to other skos properties. I especially think of skos:subject. 
>> The documents indexed by a concept are a important part of its 
>> meaning, therefore the use of skos:subject for some concept should be 
>> controlled by the concept's owner.
> However desirable, I'm not convinced that "easy extension" should be a 
> goal. Provenance is one of the fundamental attributes of any RDF 
> statement or property that is unfortunately currently difficult to 
> express. This is a case where the negative effects of uncontrolled 
> extension of a concept could only be mitigated for a concept owner by 
> a requirement that the provenance of the extension be explicitly stated.

Do you mean that proper solution for ISSUE-36 on ConceptScheme 
containment ( would help you remove your objection? I have the feeling somehow that we are argueing over the use of BT as mapping links between different vocabularies because we don't have a solution for ISSUE-36 (and, I agree, this one might be hard to find). which bothers me a bit because these problems seems to me slightly orthogonal...

>> Generally I think it is counter-productive to aim at maintining 
>> 'global' integrity for vocabularies published on the web. All that 
>> you can do, perhaps, it is ensure 'local' integrity by e.g. saying 
>> that all the skos:broader assertions between concepts from my CS are 
>> valid, plus the ones that concern concepts from my CS and concepts 
>> from other schemes for which I trust the creators (let's say the CSs 
>> at
>> For such a scenario the inScheme information (or any solution to 
>> ISSUE-XXX) should be ok.
> It depends on how much you value the concept of 'ownership' of a 
> Concept or CS. For managers of formal vocabularies and the library 
> community that typical uses them -- and I believe that this includes 
> much of the SKOS target audience -- maintaining the global 
> intellectual integrity of their work is critical to their ability to 
> use SKOS. The library community in particular is comfortable (perhaps 
> too comfortable) with strong information silos in which ownership is 
> clear and control is paramount. I think it's counterproductive for 
> SKOS to aim at disintegrating "'global' integrity for vocabularies 
> published on the web".

I see strong point in your objection. However I'm not sure maintaining 
global integrity on the web is a goal that is really compatible with the 
very nature of the web. Actually even outside the web such problems 
occur. Does the LoC control the way the LCSH is used in other libraries? 
Yet this could break the literary warrant for these subjects. For the 
LCSH, all what we can eventually say is : "LoC only acknowledge the LoC 
indexing to be used as literary warrant for the LCSH subjects" (and even 
then I suspect there could be problems ;-)

> [snip]
>>> On the other hand, this might also present a case where, as Bernard 
>>> wonders, it then makes sense to allow the assertion of BT-RT-NT 
>>> relationships between concepts that are already related by their 
>>> inclusion in the same scheme via inScheme. If this is the case, then 
>>> I could then see requiring the endorsement of an inScheme property 
>>> assertion which would then allow un-endorsed concept relationships, 
>>> since by definition the concepts would then be in the same scheme.
>> I don't follow you. Would you say that concepts can only appear in 
>> one scheme?
> No, I'm saying that once we allow un-endorsed inScheme assertions then 
> by definition a CS would contain Concepts that would not necessarily 
> be owned by the owner of the CS. But she would then be allowed to make 
> un-endorsed-by-the-original-owner changes to all Concept properties 
> because the Concept was now considered 'part' of her scheme. This is 
> also a good argument then for requiring endorsement of inScheme as 
> well. I become less sure by the minute!

To me extensions of one concept scheme are not part of this concept 
scheme anymore. If I extend LCSH I don't want LoC experts to have a look 
at what I do ;-)



PS: By the way I think the solution presented in [2] is really 
sophisticated (duplicating concepts from extended scheme, using the copy 
as the start of the extension and creating exactMatch links between the 
original and the copy). Why not just putting skosm:broadMatch between 
the 'new concept' and the 'extended one', without duplicating the 
extended one?
>>> [1] 
>>> [2]
>>> [3]

Received on Tuesday, 3 July 2007 17:53:54 UTC