Native SPARQL engine and property paths

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Native SPARQL engine and property paths

franzlst
Hi,

I'm currently trying to switch from the RDFLib queries to using the native SPARQL engine and am really happy about the performance gain.

However, I have a problem with using a relatively simple property path that should be supported, according to the Owlready2 documentation.

I want to run the following query:
SELECT  ?s ?c   WHERE {  ?s <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>/<http://www.w3.org/2000/01/rdf-schema#subClassOf>* <http://purl.org/ieee1872-owl/sumo-cora#Entity> .  OPTIONAL { ?s <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?c }  }

This gets translated to the following SQL query:

WITH RECURSIVE prelim1_objs(s) AS (VALUES (355) 
UNION
SELECT q.s FROM objs q, prelim1_objs rec WHERE q.p=9 AND q.o=rec.s)

SELECT q1.s, q2.o FROM objs q1 LEFT JOIN objs q2 ON (q2.s=q1.s AND q2.p=6) WHERE q1.p=6 AND q1.o IN (SELECT s FROM prelim1_objs)

When I run this query, I get a
rdflib.query.ResultException: Unknown result type: WITH

Is there anything I can do about it?

Could it be related to an relatively old version of SQLite, which e.g. does not support "IIF"?
Reply | Threaded
Open this post in threaded view
|

Re: Native SPARQL engine and property paths

Jiba
Administrator
Hi,

I'm very surprised by the error message you get (rdflib.query.ResultException: Unknown result type: WITH) because the new SPARQL engine does not use rdflib at all and thus should not produce rdflib error... Are you sure of this error message ?

I tried your query on a basic dataset, and it worked as expected.

I think you can remove the OPTIONAL keyword, as the first part already ensure that there is a "type" relation -- thus the OPTIONAL actually occurs always.

Jiba

Reply | Threaded
Open this post in threaded view
|

Re: Native SPARQL engine and property paths

franzlst
Oh gosh, stupid me. You are absolutely right, the error was caused by something else.

I'm currently creating an Owlready2 plugin for SuRF. The queries are thus generated by SuRF. In this case they could definitely be optimized.