Re: ISSUE-130 draft response

Hi Antoine,

On Wed, Oct 01, 2008 at 05:36:28PM +0200, Antoine Isaac wrote:
> 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.

I don't think this is what Andy is proposing. I thought (based on [1])
that he was in support of skos:topConceptOf because it allows you to
express the link *from* the top concept *to* the scheme, which is
convenient when serialising the data as RDF/XML because you can avoid
a very large document describing the scheme. Andy please correct me if
I'm wrong.

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

Well, there is no formal integrity constraint, but there is a usage

"skos:hasTopConcept is, by convention, used to link a concept scheme
to the SKOS concept(s) which are topmost in the hierarchical relations
for that scheme" [2]

so I would hope everybody would use skos:hasTopConcept
according to this convention. Tool developers may depend on using
skos:hasTopConcept/skos:topConceptOf to provide a tree browsing
display, so may run into trouble where the convention is not followed.

Perhaps we should state an integrity condition here, just to be clear?

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

I think there are two points to consider here. 

First the query may be easy to build, but may not be fast to execute
for large concept schemes. It is one of those OPTIONAL .. FILTER
!bound.. queries, which can be slow for large datasets in my
experience. Hence the skos:hasTopConcept/skos:topConceptOf provides an
efficient alternative to searching the graph.

Second, a concept scheme might have "orphans" as you
suggest.. concepts which don't have any broader concepts, but where
the intention is not to consider it as one of the top level concepts
in a tree browser. This could be the case e.g. were a scheme is under
development, and many new concepts are being added and as yet not
given any parent. 

These two points for me have provided the rationale for
skos:hasTopConcept/skos:topConceptOf. On both of these I defer to
those with more implementation experience.




> Cheers,
> Antoine
>>> 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.

Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
United Kingdom
Tel: +44 (0)1865 281993

Received on Wednesday, 1 October 2008 16:07:08 UTC