Re: ISSUE-130 draft response

Hi Alistair,
>
>
> 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.
>   

As said in the other mails I have indeed misinterpreted Andy's proposal. 
But as I also said, in theory introducing isTopConceptOf (as an inverse 
of hasTopConcept) might not be really beneficial, unless you de-activate 
the SKOS inferences.
>   
>> 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
> convention
>
> "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?
>   

The problem is that if you state an integrity condition that fully 
mirrors the convention definition for top concept ("*the* SKOS 
concept(s) which are topmost") then all the orphans that are discussed 
below would be involved in hasTopConcept statements. Or am I wrong?

By the way I think I agree with your point on the SPARQL implementation 
of such a constraint. The irony is that if the concept schemes are 
generally richly structured, then the explicit statement is more 
economic. But if we have thousands of skos:hasTopConcept and very few 
skos:broader, then I would expect the difference to be less significant ;-)

Antoine


>   
>> 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,
>
> Alistair.
>
> [1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jul/0084.html
> [2] http://www.w3.org/TR/2008/WD-skos-reference-20080829/
>
>   
>> Cheers,
>>
>> Antoine
>>
>>
>>     
>>>> From: public-swd-wg-request@w3.org [mailto:public-swd-wg-
>>>> request@w3.org] On Behalf Of Alistair Miles
>>>> Sent: Wednesday, October 01, 2008 10:31 AM
>>>> To: public-swd-wg@w3.org
>>>> 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 16:19:38 UTC