Re: [SKOS] central issues

Guus Schreiber wrote:
>
>> Hi Alistair
>>
>> 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]

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.

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

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 Monday, 2 July 2007 19:17:04 UTC