Re: Problem with federated queries

Andy Seaborne Wed, 30 Aug 2023 13:36:29 -0700



On 30/08/2023 08:47, [email protected] wrote:

Thank you Simon and Andy. The LATERAL clause solved my problem. Hopefully, it 
is implemented in fuseki (although the UI displays a warning telling that it 
doesn't know this token). In case I need more control over federated query, I 
will look deeper into the service_enhancer extension.
Thomas, this suggests that Wikidata implements correctly the VALUES clause.

The query editor in the UI is a 3rd party compoent (from @zazuco/yasqe -it has security bug fixes from the original). It is has a SPARQL 1.1grammar engine which determines the synatx checking. It would benefitfrom a contribution to update the parser. LATERAL is not implemented byseveral engines.


    Andy


Orange Restricted

-----Message d'origine-----
De : Andy Seaborne <[email protected]>
Envoyé : mardi 29 août 2023 22:10
À : [email protected]
Objet : Re: Problem with federated queries

There is also the service enhancer

https://jena.apache.org/documentation/query/service_enhancer.html

which provides various ways to control federated query.

      Andy

On 29/08/2023 19:22, Simon Bin wrote:

You could use the "LATERAL" extension of Jena (not standard Sparql
1.1):

PREFIX wd: <http://www.wikidata.org/entity/> PREFIX owl:
<http://www.w3.org/2002/07/owl#> PREFIX ex: <http://example/> PREFIX
wdt:  <http://www.wikidata.org/prop/direct/>
PREFIX geof: <http://www.opengis.net/def/geosparql/function/>
SELECT *
WHERE {
    {
      ?ParisWDID owl:sameAs ex:Paris .
      ?BordeauxWDID owl:sameAs ex:Bordeaux .
    } LATERAL {
      SERVICE <https://query.wikidata.org/sparql> {
        SELECT * {
          ?ParisWDID wdt:P625 ?ParisLoc .
          ?BordeauxWDID wdt:P625 ?BordeauxLoc .
          BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist)
        } LIMIT 1
      }
    }
}

Cheers,

On Tue, 2023-08-29 at 16:28 +0000, [email protected] wrote:



Orange Restricted

-----Message d'origine-----
De : Thomas Francart <[email protected]> ...
No, that's not true. This is a possible implementation for federated
querying (*"Implementers of SPARQL 1.1 Federated Query may use the
VALUES clause...")*, but this is transparent for you, you don't have
to use the VALUES clause yourself.

Unfortunately, there is no example in that document on how to use
it,



That's because you don't have to use it

          FR> you're right, I missed the "Implementers of..."

Don't do federated querying :-)
Try to use an http to debug the exact query that is being sent by
Jena to Wikidata, this will help you understand the problem. Or maybe
Jena has a parameter itself to debug the queries it sends to external
services ?

          FR> If nobody in the list provides a solution, I'll will run
two instances of fuseki. One "local" and one "remote" and I'll check
on the standard output of the "remote" if the "local" has issued a
query with the clause "VALUES" 😊.

Orange Restricted

-----Message d'origine-----
De : RAMPARANY Fano INNOV/IT-S
Envoyé : mardi 29 août 2023 10:58
À : [email protected]
Objet : RE: Problem with federated queries

Thank you for pointing us the reason of the issue. However, it seems
that introducing the subquery first doesn't seem to work either.

I slightly modified the query you suggested to:

PREFIX wd: <http://www.wikidata.org/entity/> PREFIX owl: <
http://www.w3.org/2002/07/owl#> PREFIX ex: <http://example/> PREFIX
wdt:
<http://www.wikidata.org/prop/direct/>
PREFIX geof: <http://www.opengis.net/def/geosparql/function/>
SELECT *
WHERE {
    {
      SELECT ?ParisWDID ?BordeauxWDID
      WHERE {
        BIND (wd:Q90 AS ?ParisWDID)
        BIND (wd:Q1479 AS ?BordeauxWDID)
      }
    }
    SERVICE <https://query.wikidata.org/sparql> {
     ?ParisWDID wdt:P625 ?ParisLoc .
     ?BordeauxWDID wdt:P625 ?BordeauxLoc .
     BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist)
    }
}

Because the variables ?ParisWDID and ?BordeauxWDID should hold the
Wikidata identifiers. But the target query should be:

PREFIX wd: <http://www.wikidata.org/entity/> PREFIX owl: <
http://www.w3.org/2002/07/owl#> PREFIX ex: <http://example/> PREFIX
wdt:
<http://www.wikidata.org/prop/direct/>
PREFIX geof: <http://www.opengis.net/def/geosparql/function/>
SELECT *
WHERE {
    {
      SELECT ?ParisWDID ?BordeauxWDID
      WHERE {
        ?ParisWDID owl:sameAs ex:Paris .
        ?BordeauxWDID owl:sameAs ex:Bordeaux .
      }
    }
    SERVICE <https://query.wikidata.org/sparql> {
     ?ParisWDID wdt:P625 ?ParisLoc .
     ?BordeauxWDID wdt:P625 ?BordeauxLoc .
     BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist)
    }
}

As these identifiers are defined in the RDF graph and are not
supposed to be known when building the query.

Unfortunately, although they use subqueries, none of the two queries
work.
The error persists ☹

Fano


Orange Restricted

-----Message d'origine-----
De : Thomas Francart <[email protected]> Envoyé : lundi 28
août
2023 18:26 À : [email protected] Objet : Re: Problem with
federated queries

One typical problem is that the federated query might be executed
*before* the rest of the query.
So when you write

    SERVICE https://query.wikidata.org/sparql {
     ?ParisWDID wdt:P625 ?ParisLoc .
     ?BordeauxWDID wdt:P625 ?BordeauxLoc .
     BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist)
    }

Then that part is sent to Wikidata *without any bindings of the
variables*, which is basically asking wikidata to return the
distance between *all* pairs of entities in the database, resulting
in a timeout.
And this is why your second query works.

If you want to guarantee ordering of execution, use a subquery,
which is logically executed first :

PREFIX wd: http://www.wikidata.org/entity/ PREFIX owl:
http://www.w3.org/2002/07/owl# PREFIX ex: http://example/ PREFIX
wdt:
http://www.wikidata.org/prop/direct/
PREFIX geof: http://www.opengis.net/def/geosparql/function/
SELECT *
WHERE {

{
    SELECT ?ParisWDID ?BordeauxWDID
    WHERE {
      BIND(ex:Paris AS ?ParisWDID )
      BIND(ex:Bordeaux AS ?BordeauxWDID )
    }
}

    ?ParisWDID owl:sameAs ex:Paris .
    ?BordeauxWDID owl:sameAs ex:Bordeaux .
    SERVICE https://query.wikidata.org/sparql {
     ?ParisWDID wdt:P625 ?ParisLoc .
     ?BordeauxWDID wdt:P625 ?BordeauxLoc .
     BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist)
    }
}

(note : that typical query pattern is supported in Sparnatural
SPARQL query builder, see
http://docs.sparnatural.eu/Federated-querying.html#additionnal-exper
im
ental-config--executedafter
)

Le lun. 28 août 2023 à 18:08, <[email protected]> a écrit :


Hello,

I've got a problem running this query on fuseki 4.9.0 (basically,
I'd like to delegate to Wikidata, the computation of the distance
between two
cities) :

PREFIX wd: http://www.wikidata.org/entity/ PREFIX owl:
http://www.w3.org/2002/07/owl# PREFIX ex: http://example/ PREFIX
wdt:
http://www.wikidata.org/prop/direct/
PREFIX geof: http://www.opengis.net/def/geosparql/function/
SELECT *
WHERE {
    ?ParisWDID owl:sameAs ex:Paris .
    ?BordeauxWDID owl:sameAs ex:Bordeaux .
    SERVICE https://query.wikidata.org/sparql {
     ?ParisWDID wdt:P625 ?ParisLoc .
     ?BordeauxWDID wdt:P625 ?BordeauxLoc .
     BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist)
    }
}
____________
Here is the content of my rdf graph:

@prefix wd: http://www.wikidata.org/entity/ .
@prefix owl: http://www.w3.org/2002/07/owl# .
@prefix wdt: http://www.wikidata.org/prop/direct/ .
@prefix ex: http://example/ .

wd:Q90 owl:sameAs ex:Paris .

wd:Q1479 owl:sameAs ex:Bordeaux .

____________
Here is the trace on the standard output:

17:44:59 INFO  Fuseki          :: [8] POST
http://localhost:3030/sparql/sparql
17:44:59 INFO  Fuseki          :: [8] Query = PREFIX wd:
http://www.wikidata.org/entity/ PREFIX owl:
http://www.w3.org/2002/07/owl# PREFIX ex: http://example/ PREFIX
wdt:
http://www.wikidata.org/prop/direct/  PREFIX geof:
http://www.opengis.net/def/geosparql/function/  SELECT * WHERE {
   ?ParisWDID owl:sameAs ex:Paris .   ?BordeauxWDID owl:sameAs
ex:Bordeaux

   SERVICE https://query.wikidata.org/sparql {    ?ParisWDID
wdt:P625
?ParisLoc .    ?BordeauxWDID wdt:P625 ?BordeauxLoc .
BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist)   } }
17:46:08 WARN  Fuseki          :: [8] RC = 500 :
com.google.gson.stream.MalformedJsonException: Unterminated string
at line
19922828 column 49 path $.results.bindings[855041].ParisLoc.value
org.apache.jena.sparql.resultset.ResultSetException:
com.google.gson.stream.MalformedJsonException: Unterminated string
at line
19922828 column 49 path $.results.bindings[855041].ParisLoc.value
        at
org.apache.jena.riot.rowset.rw.rs_json.RowSetJSONStreaming.moveTo
Nex
t(
RowSetJSONStreaming.java:214)
~[fuseki-server.jar:4.9.0]
        at
org.apache.jena.riot.rowset.rw.rs_json.RowSetJSONStreaming.moveTo
Nex
t(
RowSetJSONStreaming.java:66)
~[fuseki-server.jar:4.9.0]
...
        at
org.apache.jena.riot.rowset.rw.rs_json.IteratorRsJSON.computeNext
Act
ua
l(IteratorRsJSON.java:136)
~[fuseki-server.jar:4.9.0]
        at
org.apache.jena.riot.rowset.rw.rs_json.IteratorRsJSON.moveToNext(
Ite
ra
torRsJSON.java:72)
~[fuseki-server.jar:4.9.0]
        at
org.apache.jena.atlas.iterator.IteratorSlotted.hasNext(IteratorSl
ott
ed
.java:63)
~[fuseki-server.jar:4.9.0]
        at
org.apache.jena.riot.rowset.rw.rs_json.RowSetJSONStreaming.comput
eNe
xt
Actual(RowSetJSONStreaming.java:225)
~[fuseki-server.jar:4.9.0]
        at
org.apache.jena.riot.rowset.rw.rs_json.RowSetJSONStreaming.moveTo
Nex
t(
RowSetJSONStreaming.java:210)
~[fuseki-server.jar:4.9.0]
        ... 112 more
17:46:08 INFO  Fuseki          :: [8] 500 Server Error (68,499 s)

____________
I verified that when replacing the variables ?ParisWDID and
?BordeauxWDID with their values, the query is processed correctly.
Thus

this query works:


PREFIX wd: http://www.wikidata.org/entity/ PREFIX owl:
http://www.w3.org/2002/07/owl# PREFIX ex: http://example/ PREFIX
wdt:
http://www.wikidata.org/prop/direct/
PREFIX geof: http://www.opengis.net/def/geosparql/function/
SELECT *
WHERE {
SERVICE https://query.wikidata.org/sparql {
     wd:Q90 wdt:P625 ?ParisLoc .
     wd:Q1479 wdt:P625 ?BordeauxLoc .
     BIND(geof:distance(?ParisLoc,?BordeauxLoc) AS ?dist) } }

____________
Thank you for any hint on what I did wrong

Kind regards,

Fano




Orange Restricted

_________________________________________________________________
___
__ ______________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler a l'expediteur et le
detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie.
Merci.

This message and its attachments may contain confidential or
privileged information that may be protected by law; they should
not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that
have been modified, changed or falsified.
Thank you.



--

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

___________________________________________________________________
___
______________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler a l'expediteur et le
detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration, Orange decline toute responsabilite
si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or
privileged information that may be protected by law; they should not
be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that
have been modified, changed or falsified.
Thank you.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: Problem with federated queries

Reply via email to