Re: [SKOS] central issues

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?

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.

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.

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


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

> 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?

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 07:51:37 UTC