This repository has been archived by the owner on Jan 28, 2025. It is now read-only.
Federated query with PREFIX statements fails on some conditions #140
Comments
|
Hi,
You may try the patch below.
In class fr.inria.corese.core.query.CompileService
replace function :
Constant create(ASTQuery ast, IDatatype dt) {
if (dt.isURI()) {
if (dt.getLabel().contains(" ")) {
return Constant.create(dt.getLabel().replace(" ", "%20"));
} else {
return ast.createQNameURI(dt.getLabel());
}
}
else {
return Constant.create(dt);
}
}
by function :
Constant create(ASTQuery ast, IDatatype dt) {
if (dt.isURI()) {
if (dt.getLabel().contains(" ")) {
return Constant.create(dt.getLabel().replace(" ", "%20"));
} else {
return Constant.create(dt.getLabel());
}
}
else {
return Constant.create(dt);
}
}
Best regards,
Olivier
… De: "Dmitrii" ***@***.***>
À: "Wimmics" ***@***.***>
Cc: "Subscribed" ***@***.***>
Envoyé: Vendredi 29 Septembre 2023 14:33:19
Objet: [Wimmics/corese] Federated query with PREFIX statements fails on some
conditions (Issue #140)
Issue Description:
Federated query with PREFIX statements fails on some conditions (in my case,
when one of the federated endpoints replies with more than 6 triples):
2023-09-29 10:49:17 INFO query.ProviderService.getTimeout:919 [] - Timeout:
10000
2023-09-29 10:49:17 INFO load.Service.basicPost:253 [] - Post
http://10.112.17.134:8078/query
2023-09-29 10:49:17 INFO load.Service.basicPost:286 [] - Response status: 400
2023-09-29 10:49:17 ERROR load.Service.basicPost:318 [] -
http://10.112.17.134:8078/query
2023-09-29 10:49:17 ERROR load.Service.basicPost:319 [] -
jakarta.ws.rs.client.ResponseProcessingException error at 13:52: expected UNDEF
2023-09-29 10:49:17 ERROR query.ProviderService.exception:507 [] -
jakarta.ws.rs.client.ResponseProcessingException
http://10.112.17.134:8078/query
2023-09-29 10:49:17 ERROR query.ProviderService.error:596 [] - service error:
http://10.112.17.134:8078/query
2023-09-29 10:49:17 ERROR query.ProviderService.error:600 [] - error at 13:52:
expected UNDEF
2023-09-29 10:49:17 ERROR query.ProviderService.error:602 [] -
prefix network: <http://example.com/network.owl#>
prefix ex: <http://example2.com/ns#>
prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select *
where {
?device network:hasVrf ?vrf .
?device rdf:type network:Device .
?vrf network:hasInterfaceVrf ?intf .
}
limit 1000
2023-09-29 10:49:17 INFO query.ProviderService.submitError:612 [] - Blacklist:
http://10.112.17.134:8078/query 1
The query works as expected without PREFIX and full URIs.
Bug Details:
We intercepted query from the corese to one of the federated endpoints and
noticed inconsistency: mixed prefix and URI statements, leading to HTTP 400
error from the federated endpoint.
query=prefix+network:+<http://example.com/network.owl#>
prefix+ex:+<http://example2.com/ns#>
prefix+rdf:+<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select+*+
where+{
++values+(?intf+){
++++(<http://example.com/network.owl#SS1-DRDC-111-000_Port-channel151.10>+)
++++(<http://example.com/network.owl#SS1-DRDC-111-000_Port-channel152.20>+)
++++(network:SS1-DRDC-111-000_Vlan3920+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether31.10>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether32.20>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether100.2301>+)
++++(network:SD-0MSK-MAR4-001_GigabitEthernet0/0/0/1+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_TenGigE0/0/0/13.3054>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_TenGigE0/0/0/13.3332>+)
++++(<http://example.com/network.owl#SD-0MSK-MAR4-001_Bundle-Ether100.433>+)
++}
++?device+network:hasVrf+?vrf+.
++?device+rdf:type+network:Device+.
++?vrf+network:hasInterfaceVrf+?intf+.
}
limit+1000+
The error does not occur on federating small graphs (up to 6 triples in our
case). The error occurs when one of the federated endpoints replies with more
than 6 triples.
Steps to Reproduce:
1. Set up corese federation as described in [
#138 | #138 ]
2. Roll out two SPARQL endpoints for federation: [
https://github.com/vemonet/rdflib-endpoint | SPARQL endpoint for RDFLib ] and [
https://github.com/oxigraph/oxigraph | Oxigraph ]
3. Query ../federate endpoint provided by the corese
Expected Behavior:
Federated query returns results.
Actual Behavior:
[ https://github.com/vemonet/rdflib-endpoint | SPARQL endpoint for RDFLib ]
returns HTTP 400 error on query from the corese (probably because of mixed
prefix and URI statements).
Note to Developers:
None
Screenshots/Attachments:
None
—
Reply to this email directly, [ #140 |
view it on GitHub ] , or [
https://github.com/notifications/unsubscribe-auth/ABKXNJGOGKE3HD3A6J2GKT3X425Y7ANCNFSM6AAAAAA5MM3O74
| unsubscribe ] .
You are receiving this because you are subscribed to this thread. Message ID:
***@***.***>
|
|
Thank you for the report. I've made the necessary changes in the code. The fix will be included in the next release. If you'd like to access the modifications immediately, you can compile them from the source in the development branch. |
|
Thank you @ocorby , @remiceres for providing the patch and including it into upcoming version. I will wait for the new version to test it. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Issue Description:
Federated query with PREFIX statements fails on some conditions (in my case, when one of the federated endpoints replies with more than 6 triples):
The query works as expected without PREFIX and full URIs.
Bug Details:
We intercepted query from the corese to one of the federated endpoints and noticed inconsistency: mixed prefix and URI statements, leading to HTTP 400 error from the federated endpoint.
The error does not occur on federating small graphs (up to 6 triples in our case). The error occurs when one of the federated endpoints replies with more than 6 triples.
Steps to Reproduce:
Expected Behavior:
Federated query returns results.
Actual Behavior:
SPARQL endpoint for RDFLib returns HTTP 400 error on query from the corese (probably because of mixed prefix and URI statements).
Note to Developers:
None
Screenshots/Attachments:
None
The text was updated successfully, but these errors were encountered: