W3C home > Mailing lists > Public > public-lod@w3.org > October 2009

Re: [Dbpedia-discussion] DBpedia SPARQL Endpoint and Transitive Queries

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Fri, 09 Oct 2009 10:28:42 +0200
Message-ID: <4ACEF43A.9040902@few.vu.nl>
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: J├╝rgen Jakobitsch <jakobitschj@punkt.at>, dbpedia-discussion@lists.sourceforge.net, "public-lod@w3.org" <public-lod@w3.org>
Hi Kingsley, Alexandre, others

The thread has become quite hard to follow (I cannot really see what refers to the existing situation and what is proposed as the solution to be implemented) , but I'll try to help where I can ;-)

>> consider the fact, that sparqling for skos:broaderTransitive does not 
>> include the direct skos:broader.
>> for example :
>> - conceptA skos:broader conceptB
>> - conceptB skos:broader conceptC
>> - conceptC skos:broader conceptD
>> sparql for skos:broader of conceptA => includes conceptB (and nothing 
>> else)
>> sparql for skos:broaderTranisitive of conceptA => includes conceptC, 
>> conceptD (but not conceptA)
>> sparql for skos:broader of conceptC => includes conceptD (and nothing 
>> else)
>> sparql for skos:broaderTransitive of conceptC => includes emptiness
>> if you would like the whole chain of broaders you would need to use 
>> skos:broader UNION skos:broaderTransitive

I really want to be clear about it: the sparql query for skos:broaderTransitive of concept A should return A, B and C, as skos:broaderTransitive is a super-property of skos:broader and is transitive.

So to get all ancestors of a concept, you only need broaderTransitive.

>>>> +1. Also, skos:subject is not in the recommendation...
>>> Fine, but what happens when the data in question already has such  
>>> triples? 

Well, I guess it should work, if you query using skos:subject. But you loose interoperability, as this property is not defined in the SKOS namespace.
I'd say it roughly amounts, in terms of interoperability, to coining and using a new dbpedia:subject property.
And of course it's not nice to coin constructs using someone else's namespace ;-)

>> BTW, do you have a link to Bernard's post ?

That would be handy!

>>> Ultimate solution: make an inference rule that asserts:  
>>> <skos:broaderTransitive> owl:subPropertyOf <skos:broader> (or make a  
>>> context rule from the entire skos ontology), and you will then have  
>>> the revised query return data for those databases that have used  
>>> skos:broader to build their concept scheme structure (assuming you  
>>> apply the inference rule pragma). Otherwise,  If your store has  
>>> skos:broaderTransitive data, then just change the query :-)

Yes, indeed the general idea for broader/broaderTransitive is that broader would be stated in the data (really corresponding to what is asserted in the original knowledge organisation system) while broaderTransitive is used in queries, to benefit from some form of semantic enrichement.


Received on Friday, 9 October 2009 08:29:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:00 UTC