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.

Also, about your scalability issue. In my project we work with big 
vocabularies that are not all very structured, with some thousands of 
top concepts (19K is our record!). It's of course not ideal, but well, 
it is manageable from a data representation and storage perspective.
Further, even though we've not done it ourselves, I would actually 
consider *not representing these links* in the SKOS representation of 
such KOSs. After all, this whole notion of "entry point in a hierarchy" 
does not makes much sense if you have thousands of such entry points. 
I'd like to hear your opinion on this!

To continue, the convention is that hasTopConcept will link to concepts that are the 
roots of some hierarchies, but it might not be the case in specific KOSs. As 
Alistair pointed out, hasTopConcept may point to concepts that have 
parents. I would add that hastopConcept statements could ignore some of the 'orphan' concepts (I use 'orphan' 
intentionally here: these concepts' not having parent could just result 
from weak structuring, and not from KOS designer's intentions)
To sum up, the graph of hasTopConcept could be different from the SPARQL 
query that would request for "these concepts that have no parent in the 
considered scheme". Note by the way that this query is actually pretty 
easy to build. That would make the explicit declaration of hasTopConcept 
statements quite redundant...



>> From: [mailto:public-swd-wg-
>>] On Behalf Of Alistair Miles
>> Sent: Wednesday, October 01, 2008 10:31 AM
>> To:
>> Subject: ISSUE-130 draft response
>> Hi all,
>> Here's a draft response to Kjetil on [ISSUE-130], let me know what you
>> think. Note *this is just a draft, not the actual response* -- I'll
>> wait for feedback from the WG before replying formally to
>> Kjetil.
>> [...]
>> so it was great to see that skos:topConceptOf is in! Please keep it
>> there, it
>> is simply much easier for us to use it in development with the present
>> architecture.
> The problem with skos:hasTopConcept or skos:topConceptOf is that it does not scale.  If your vocabulary has tens of top concepts it works well, but if your vocabulary has hundreds or thousands, then listing all of them in skos:ConceptScheme is cumbersome.  It would be better for vocabularies with a large number of top concepts to indicate in skos:Concept that they are a top concept.  Thus when you retrieve a skos:Concept you also have an indication that itís a top concept rather than having to also retrieve the skos:ConceptScheme to see whether the skos:Concept is a top concept.
> Andy.

Received on Wednesday, 1 October 2008 15:37:22 UTC