The IRI function in UpdateRequests ignores BASE IRIs about jena HOT 12 CLOSED

ARQConstants.sysCurrentPrologue would seem the better fix.

Noticed:
QueryExecDataset and QueryExecDatasetBuilder both set ARQConstants.sysCurrentQuery which isn't right.

from jena.

There is now a best-effort PR - however I am not sure about the SPARQL spec and whether this actually opens a bit of a pandora's box:

The sparql spec's grammar allows for multiple prologues on each Update - and I am not sure whether they actually need to stay separate or whether only the last one takes precedence.

[29] | Update | ::= | Prologue ( Update1 ( ';' Update )? )?

In any case, with Jena I get:

UpdateRequest req = UpdateFactory.create(String.join(";\n",
  "BASE <http://foo.foo/> INSERT { ?s ?s ?s } WHERE { BIND(IRI('s') AS ?s) }",
  "BASE <http://bar.bar/> INSERT { ?x ?x ?x } WHERE { BIND(IRI('x') AS ?x) }"));
System.out.println(req);

BASE    <http://bar.bar/>

INSERT {
  ?s ?s ?s .
}
WHERE
  { BIND(iri("s") AS ?s) } ;
INSERT {
  ?x ?x ?x .
}
WHERE
  { BIND(iri("x") AS ?x) }

Not sure if this is the correct semantics or whether jena's update model actually deviates from the spec here such that actually UpdateRequest would have to become a list of Updates without prologue, and every Update would have to extend Prologue.

from jena.

There isn't anything special about update: the prologue accumulates. For BASE that is "replace" although the new base URI is resolved against the previous one, starting from the file or URL the query is read from.

BASE <http://base/>
PREFIX ex: <z1/z2/>
BASE <y/>
PREFIX : <a>

SELECT (:123 AS ?X) (ex:456 AS ?Y)
WHERE {}

gives http://base/y/a123 ,http://base/z1/z2/456.

Repeated prologues in update are just updating the active prefixes and base as the parser goes along.

from jena.

Ok, so that means that the IRI function then only sees the final accumulated base IRI (and not that of the respective Update operation)

from jena.

This is a dynamic vs static scoping issue. Is the base dynamically or staticly scoped to the IRI function? For query, the difference is not observable.

Making it whole update is dynamic, picking base up at runtime; that becomes "last BASE" through out the update.

The static style alternative is the syntax element for the IRI function could record the base at point of creation i.e. the IRI function captures the parser base, and not have context at execution time.

I don't recall when I last saw a real-world update with split prologue.

Adding updates together ("fragments") does suggest the static approach.

from jena.

Making it whole update is dynamic, picking base up at runtime; that becomes "last BASE" through out the update.

This is at least the easiest thing to implement for the time being - although the statically scoped interpretation is clearly the intuitive one. But the latter would require quite some refactoring.

I don't recall when I last saw a real-world update with split prologue.

Yes, the cheap solution would be to drop split prologues from the spec 😁

from jena.

"static" is a parser change - I'll try it out.

(The fact Query and UpdateRequest extend Prologue was a mistake but we are where we are.)

from jena.

#1343 does static scoping.

It makes these

BIND(<x> as ?X1)
BIND(IRI("<x>") as ?X2)

in an update both produce the same IRI.

The first resolves the relative IRI by parsing, the second takes the base in scope of the parser captured bat parse time and applied it at runtime.

from jena.

PR #1343 provides static scoping and includes an extension which is "IRI" with a provided base IRI(base, rel).

There are now 2 IRI "E_" functions: the standard "E_IRI" takes on argument and records the pasrer base and "E_IRI2" which has two arguments - (base, rel) - and because base can be relative, it also records the parser base.

These become functions (iri) and (iri2) in the algebra.

from jena.

Seems very reasonable to me.

Though - while we are at it - I wouldn't be opposed to an IRI function that can yield relative IRIs "as given" - e.g. not resolving ../../common/schema.rdf against the parser base.
It's somehow odd that one can put a turtle file on the Web with relative IRIs pointing e.g. to resources such as downloads or ontology files - but there is no way to create such relative IRIs with SPARQL.
Using turtle with RIOT.symTurtleOmitBase is not really a solution because of iris with ".." are always resolved (iirc) so the ".." gets lost.

So maybe E_IRI2 could have an optional third boolean parameter whether to resolve against the parser base if the given base is relative which defaults to true.

from jena.

Let's do one thing at a time.

from jena.

Closed by PR #1343.

from jena.