Re: [SKOS] central issues

Hi Antoine,

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] 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.

More inline below...

--Jon

Antoine Isaac wrote:
> Hi Jon
>>
>>>>
>>>>
>>>> This is a good framework for questions I was about to post, which 
>>>> fit at least in part in  [ISSUE-44]
>>>> What are the relation of broader/narrower semantics with 
>>>> conceptScheme semantics, if any?
>>>>     * Should broader/narrower link concepts of the same concept 
>>>> scheme, or are they allowed across concept schemes?
>>>>     * If a concept belongs to several concept schemes, would it be 
>>>> possible / does it make sense to distinguish broader-narrower 
>>>> hierarchies in different schemes?
>>>> Related question, I would like to see specified the semantics of 
>>>> ConceptScheme, and the difference between ConceptScheme and 
>>>> subclass of Concept. Maybe another issue number for this?
>>>
>>> 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.
>
> 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 
> metadataregistry.org).
>
> 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".
>>
>> There's also the more minor question of constraints on the transitive 
>> nature of BT-NT-RT. It's much simpler to achieve transitive closure 
>> when transitive properties are constrained to a single scheme.
>
> I'm not sure: in this respect the matter is more on the knowledge 
> source which contains the scheme. If you have a same scheme splitted 
> in different knowledge repositories, then it will be as difficult as 
> for a case with several interlinked schemes on several repositories.
>
> To finish, with, a complex piece of evidence against your evidence to 
> the contrary ;-). This is adapted from a set of library vocabularies 
> I'm working with
> ex:travelGuide-Italy skos:inScheme ex:subjectScheme
> ex:Italy skos:inScheme ex:placeScheme
> ex:travelGuide-Italy skos:broader ex:Italy
>
> In my cas there is actually an overall ConceptScheme that would allow 
> I think to have your solution implemented. But what if we propose a 
> rule that says that skos:broader cannot be asserted from concepts from 
> different CS? Or should you rule be "there should not be skos:broader 
> statements between concepts from different CS unless they come from a 
> same CS?"
>
> In which case you would need the authority for one CS to control the 
> way their concepts could be 'imported' in other vocabularies, by 
> creation of extra (local) inScheme statements...
>
See my opening statement at the top of the message.
>>
>>
>> We have also considered the possibility that a concept might be 
>> managed/owned by an Agent but be included in schemes that an Agent 
>> doesn't own, via inScheme, and came to the conclusion that the 
>> addition of an inScheme property to a concept might not need to be 
>> endorsed by the concept owner the way that other concept 
>> relationships would require, since it's usually much less 
>> semantically meaningful. [2]
>
> Are tou sure? Your constraint on the use of BT etc. makes it very 
> important, on the contrary.
>
Ah, well. Although it pretty consistently puts me at a disadvantage in 
these discussions, I'm never sure. We just concluded that it was less 
bad to allow un-endorsed inScheme assertions in order to allow easy 
import of one scheme into another. I think we would have been happier in 
general if a CS had a hasConcept property that could be used to collect 
Concepts. But in any event, we haven't implemented this yet in the 
Registry so we don't have any practical experience yet. This makes me 
even less sure than usual.
>> 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!
>
> Cheers,
>
> Antoine
>>
>> Despite the fact that the Registry currently allows creating such 
>> inter-scheme relationships, we would much prefer to see the SKOS 
>> relational properties constrained to asserting relationships between 
>> concepts in the same scheme, and the use of something like the 
>> current mapping terminology [3] for asserting relationships between 
>> concepts that are in differing schemes.
>>
>> --Jon Phipps
>>
>> [1] 
>> http://www.w3.org/2006/07/SWD/wiki/RucMetadataRegistryExtended#head-13cdc8e59c2c42837fee59ef584461868f01aaee 
>>
>> [2] http://www.w3.org/2006/07/SWD/wiki/RucMetadataRegistryExtended
>> [3] http://www.w3.org/2004/02/skos/mapping/spec/
>>
>>>>
>>>> Bernard
>>>>> Hi all,
>>>>>
>>>>> I'd like to suggest we focus some attention on several issues to 
>>>>> do with the central stuff in SKOS, like the skos:Concept class, 
>>>>> the SKOS labelling properties and the SKOS semantic relation 
>>>>> properties.
>>>>> This would help us to fill out some of the earlier parts of the 
>>>>> SKOS Semantics wiki draft [1]. The wiki draft has only one section 
>>>>> so far, on grouping constructs, and so looks a bit empty :) This 
>>>>> would also help the discussion of other issues, such as the 
>>>>> relationships between labels.
>>>>>
>>>>> There are three central issues in the tracker we could look at:
>>>>>
>>>>>  * [ISSUE-31] "BasicLexicalLabelSemantics" - defining the 
>>>>> semantics of the three basic labelling properties, skos:prefLabel, 
>>>>> skos:altLabel and skos:hiddenLabel
>>>>>  * [ISSUE-44] "BroaderNarrowerSemantics" - defining the semantics 
>>>>> of skos:broader and skos:narrower
>>>>>  * [ISSUE-54] "ConceptSemantics" - defining the semantics of 
>>>>> skos:Concept
>>>>> Issue 31 is already open. Issues 44 and 54 need to be opened (I 
>>>>> just raised 54).
>>>>>
>>>>> Of course we should also continue the very valuable discussion of 
>>>>> other issues and work to our requirements document!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Alistair.
>>>>>
>>>>> [1] <http://www.w3.org/2006/07/SWD/wiki/SKOS/Semantics>
>>>>> [ISSUE-31] <http://www.w3.org/2006/07/SWD/track/issues/31>
>>>>> [ISSUE-44] <http://www.w3.org/2006/07/SWD/track/issues/44>
>>>>> [ISSUE-54] <http://www.w3.org/2006/07/SWD/track/issues/54>
>>>>>
>>>>> -- 
>>>>> Alistair Miles
>>>>> Research Associate
>>>>> Science and Technology Facilities Council
>>>>> Rutherford Appleton Laboratory
>>>>> Harwell Science and Innovation Campus
>>>>> Didcot
>>>>> Oxfordshire OX11 0QX
>>>>> United Kingdom
>>>>> Web: http://purl.org/net/aliman
>>>>> Email: a.j.miles@rl.ac.uk
>>>>> Tel: +44 (0)1235 445440
>>>>>
>>>>>   
>>>
>>>
>>
>>
>
>
>

Received on Tuesday, 3 July 2007 14:11:23 UTC