Re: [SKOS, SPARQL, ALL] Closure and SPARQL

Hi all,

I like Christoffel's summary below and agree with it.  Unfortunately,  
that still leaves us with Brian's question, summarized as, "Should  
SWBP take a position on SPARQL as it stands?"  I think it should.   
Further, I think the position should be something like this:

"The SWBP&D WG has identified areas of interest which would require  
the querying of transitive closure over RDF graphs and requests that  
the DAWG note this as a requirement of SPARQL.  The SWBP&D makes no  
judgement on whether this requirement should be optional or mandatory  
and leaves that to the DAWG.  However, the SWBP&D would be  
disappointed to see this requirement fulfilled solely via non- 
standard mechanisms."

I don't think that is too strong or overstating our concerns.  It  
leaves the DAWG to fulfill its charter by itself.  It also provides  
strong encouragement to plug a significant gap in a manner which will  
not leave practitioners hanging.

Thoughts?

Regards,
Dave


On 9 Dec2005, at 06:35, Christoffel Dhaen wrote:
> I'm not trying to suggest that SPARQL should be more expressive  
> than the languages it was designed for, I am merely trying to  
> suggest it should support or be able to express the possibility to  
> query for the transitive closure of the transitive properties  
> native to the rdf schema: rdfs:subClassOf and rdfs:subPropertyOf.
>
> RDF(s) has some semantics, like rdfs:subClassOf,rdfs:subPropertyOf,  
> rdfs:range and rdfs:domain.
> These can be used to infer information.
> As most KR-systems provide a way of retrieving "asserted" and  
> "inferred" information, it just seems a bit strange that SPARQL has  
> no notion of the inferred and can only query for the asserted  
> information, unless you have an "asserted" graph and an "inferred"  
> graph stored seper.
>
> I'm not saying all implementations of SPARQL should implement the  
> inferred option, but it would be very nice if some implementations  
> would, and have the option to express in the query if the result  
> should contain only the asserted, or also the inferred.
> Being able to do so would save a lot of applications a lot of  
> trouble of having to go though maintaining an asserted version and  
> an inferred version if they would like to use SPARQL to query it,  
> because it seems that that is the only option for such an  
> application if they want to use SPARQL and query for the asserted  
> and inferred. And this seems like a lot of overhead if this has to  
> be done over and over again for each application that wants to  
> query both. It seems a lot more natural to have a (or a few) SPARQL  
> implementations that have this option, but if this can not be  
> expressed in the query, then this would lead to "customized"  
> parameters for each of those implementations.
> It's like the /*+RULE*/ option in oracle queries: you can optimize  
> the queries all you want for oracle, but you'll have to start all  
> over again if you move to another database.
> Almost the same thing here: if I would like an implementation that  
> supports querying for the inferred without having to maintain a  
> second inferred graph, I would have to create a custom version with  
> custom keywords in the SPARQL statement.
> It would be much nicer if there was a standard way to express this  
> in the query and not a 1001 implementation dependant different  
> options to express the same. Since SPARQL is designed to query RDF,  
> and RDF has semantics, it seems like a logical step to include it.
>
> Christoffel
>
>
>
> This email and its attachment(s) is confidential and intended  
> solely for the use of the individual to whom it is addressed, and  
> not intended to be further distributed without explicit prior  
> approval of the sender. Any views or opinions presented are solely  
> those of the author and do not necessarily represent those of  
> Language & Computing, Inc. unless explicitly indicated. If you are  
> not the intended recipient, be advised that you have received this  
> email in error and that any use, dissemination, forwarding,  
> printing, or copying of this email is strictly prohibited.
>
>
>
>
>
>
>> -----Original Message-----
>> From: Enrico Franconi [mailto:franconi@inf.unibz.it]
>> Sent: donderdag 8 december 2005 23:58
>> To: Christoffel Dhaen
>> Cc: McBride, Brian; Christopher Welty; public-swbp-wg@w3.org;  
>> public-swbp-
>> wg-request@w3.org
>> Subject: Re: [SKOS, SPARQL, ALL] Closure and SPARQL
>>
>> On 8 Dec 2005, at 15:09, Christoffel Dhaen wrote:
>>> As far as I know, RDF does not allow you to state that a property
>>> is transitive, but the RDF schema itself has 2 transitive
>>> properties: rdfs:subClassOf and rdfs:subPropertyOf.
>>
>> True: these are fixed properties that are by definition transitive.
>> But what if you want to ask for a descendant (which is the transitive
>> closure of a "child" property) when in the RDF graph yoy have only
>> the "child" property (which is not transitive)? This is exacttly the
>> classical example calling for a transitive closure operator in the
>> query language.
>>
>>> I could be horribly wrong here, but one of the use-cases listed is:
>>> "2.17 Building Ontology Tools (Semantic Web)"
>>> It says: "Some parts of the ontology editor require the transitive
>>> closure of the query and other parts do not."
>>>
>>> Imho, a lot of applications will require the transitive closure of
>>> the query.
>>
>> Perfectly true. The main problem here is that the existence of a
>> transitive closure operatore raises the data complexity of the query
>> language beyond SQL (it becomes of the same complexity as datalog).
>>
>>> I don't think I said that RDF and OWL express transitive closure,
>>> but they do express transitivity.
>>
>> This does not help. You want the transitive closure of existing non
>> transitive properties (see the example of "child").
>>
>>> And indeed, the transitive closure of the transitive properties is
>>> what I would expect to find in a query language for RDF.
>>
>> Sure, but it ain't easy: you need a full fledged "graph" query
>> language (see, e.g., [1]), while I guess that SPARQLl suffers of a
>> mixed origin: a bit of SQL/relational data model and a bit of graph
>> data model.
>>
>> cheers
>> --e.
>>
>> [1] C Gutierrez, C Hurtado, AO Mendelzon. Foundations of Semantic Web
>> Databases. PODS'04
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.1.371 / Virus Database: 267.13.12/194 - Release Date:  
>> 7/12/2005
>>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.13.13/195 - Release Date:  
> 8/12/2005
>
>

Received on Monday, 12 December 2005 03:58:51 UTC