Open lkitching opened 1 year ago
Is the JENA issue a bug then? If so should we file it up stream, regardless of whether it will fix the issue for us?
It looks like a Jena bug, although it looks like the implementation does follow the logic in the URI spec so maybe there's something we can do to make the first condition return true
.
The query rewriter used within draftsets parses incoming query strings with Jena Arq, and then replaces any live graph URIs with their corresponding draft graphs. The Jena query parser resolves all URIs against a base URI during the parsing step. If one is not explicitly specified, the URI for the process current working directory is used.
The URI of the working directory looks something like
file:///opt/drafter
. This contains afile
scheme, an empty authority and a path of/opt/drafter
.The URI specification describes how URIs should be resolved against a base URI. Note that in section 5.2.2 if the 'relative' URI defines a scheme, the resulting URI should use the scheme, authority, path and query from the relative URI. Jena does not respect this behaviour and instead uses the scheme and (empty) authority from the base URI.
This means that a query such as
is parsed as
before being rewritten.
Ideally we would specify a base URI such as
https://drafter.publishmydata.com
to such queries instead of relying on the default Jena behaviour. We should also process live queries the same way instead of submitting them directly to stardog.