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.


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.

> 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] 
> [2]
> [3]
>>> 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] <>
>>>> [ISSUE-31] <>
>>>> [ISSUE-44] <>
>>>> [ISSUE-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:
>>>> Email:
>>>> 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:

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