Re: ISSUE-130 draft response

Hi Alistair,

Of course you're right.
I don't have your orginal mail right now, but I think my objection was 
based on the interpretation of your wording according to which the 
integrity constraint would be introduced as a necessary and sufficient 
condition, something like
"all the concept that are top concepts have no parents, and all concepts 
that have no parents are top concepts" (which I think could be tempting 
a statement :-).
But of course if it just a necessary condition ("all the concept that 
are top concepts have no parents") then my remark is not valid.

Cheers

Antoine

> Hi Antoine,
>
> On Wed, Oct 01, 2008 at 06:19:01PM +0200, Antoine Isaac wrote:
>   
>> 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. 
>>     
>
> No, I don't think so. You could, I think, state a condition such that
> a graph e.g.
>
> <S> skos:hasTopConcept <X>.
> <X> skos:broader <Y>.
> <Y> skos:inScheme <S>.
>
> is *not* consistent, however a graph e.g. 
>
> <orphan> skos:inScheme <S>.
>
> is still perfectly consistent, and does *not* entail
>
> <S> skos:hasTopConcept <orphan>.
>
> The trouble is how to clearly state such a condition.
>
> Maybe something like...
>
> If a scheme S has top concept X, then there is no concept Y such that Y is in scheme S and Y is broader than X.
>
> Cheers,
>
> Alistair.
>
>   
>> 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 Thursday, 2 October 2008 19:50:44 UTC