Re: [SKOS] central issues

Jon Phipps wrote:
> 
> 
> 
> 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.

Jon,

My point was not in favor or against the constraints, just that in absence of a strong arguments either way we should refrain from putting constraints. Below you can give some pretty strong arguments in favor, which is very helpful.

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

-- 
Vrije Universiteit Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
T: +31 20 598 7739/7718; F: +31 84 712 1446 
Home page: http://www.cs.vu.nl/~guus/

Received on Tuesday, 3 July 2007 22:38:47 UTC