Re: ISSUE-130 draft response

Hi Andy,

Sorry for not understanding! I think I was actually puzzled by your 
remark, because this isTopConcept is actually in the current vocabulary, 
and defined as an inverse of hasTopConcept. But it was introduced for 
technical reasons, so maybe it's still hidden under the carpet for the 
time being.

But maybe the most important reason for which I was confused is that 
isTopConcept would not be much more interesting for scalability. 
Consider you have a real SKOS repository, that is, aware of SKOS 
semantics. Then this repository would, because of the inverse axiom that 
you want (and that is there) infer the existence of all the 
hasTopConcept statements that you complain about, and serve them when 
asked about the concept scheme.

Antoine


>> From: Antoine Isaac [mailto:aisaac@few.vu.nl]
>> Sent: Wednesday, October 01, 2008 11:36 AM
>> To: Houghton,Andrew
>> Cc: public-swd-wg@w3.org
>> Subject: Re: ISSUE-130 draft response
>>
>> Hi Andy,
>>
>> Your idea of using a specific TopConcept class makes sense at first
>> sight, and I guess it was actually present in the SKOS vocabulary a
>> while ago. But there could be problems with that when concept schemes
>> re-use concepts from each other. In those cases a top concept for one
>> scheme may well not be a top concept for another scheme. Being a top
>> concept is really a contextual property, and not a part of the essence
>> of a concept, I think.
>>     
>
> Actually I wasn't suggesting a new class for TopConcept, but a mechanism for specifying that a skos:Concept is a top concept.  Something like:
>
> <skos:Concept rdf:about="concept URI">
>   <skos:isTopConcept rdf:resource="in-scheme URI" />
> </skos:Concept>
>
> skos:isTopConcept could be an inverse of skos:hasTopConcept in the skos:ConceptScheme.  This way you could specify a top concept where it makes the most sense.
>
>
> Andy.
>
>
>
>

Received on Wednesday, 1 October 2008 15:59:05 UTC