Skip to content


Blank nodes not allowed with SPARQL 1.1. INSERT DATA? #126

jakubklimek opened this Issue · 16 comments

7 participants

INSERT DATA {_:node18errd605x19406 <> """67401""" .}

results in
SP031: SPARQL compiler: Blank node '_:node18errd605x19406' is not allowed in a constant clause

INSERT {_:node18errd605x19406 <> """67401""" .}
is OK.

However, in the SPARQL 1.1 INSERT DATA specification I don't see any reason why this should be disallowed. The same states this answer


This problem has been recreated and reported to development to look into ...

@iv-an-ru iv-an-ru was assigned

There is a similar issue with DELETE, for which I found but I'm trying to write an adapter that will need to be able to address specific identifiers, blank or otherwise, without any prior knowledge of their contents other than what has been previously returned from the server.

Blank nodes come out of Virtuoso with identifiers of the style nodeID://123456, but I'd like to know if a) that is a deterministic relationship to the internal representation and b) how stable it is.

(PS that nodeID::// formulation breaks parsers expecting the Turtle syntax for bnodes, even _:123456 would be valid. Is there any way to change it?)


Never mind, found this:

Plus this solution:

(<LONG::bif:iri_id_num>(?s)) AS ?s_num
(<LONG::bif:iri_id_num>(<LONG::bif:min_64bit_bnode_iri_id>())) AS ?min
?s ?p ?o
    GRAPH <> {
        ?s ?p ?o FILTER isBLANK(?s)

Presumably I'll be able to massage something out of that.


Oops, never mind. Finding that nodeID://b123456 can be addressed as a skolem IRI.


I could also reproduce the problem.

@HughWilliams : Any words on when will this issue be fixed? Is it at least planed?

@jakubklimek : I found a workaround (version: same as here).
Instead of this:

INSERT DATA {_:node18errd605x19406 <> """67401""" .}

try this

INSERT {GRAPH <urn:test> {_:node18errd605x19406 <> "67401" .}} WHERE { SELECT * {OPTIONAL {?s ?p ?o} } LIMIT 1 }

really ugly, but useful if you absolutely need to import blank nodes using the SPARQL interface.


What version have you tested against as your workaround query failed for me against the latest git develop/7 branch ?

SPARQL INSERT DATA {:node18errd605x19406 """67401""" .}
:node18errd605x19406 """67401""" .} WHERE { SELECT * {OPTIONAL {?s ?p ?o} } LIMIT 1 };

*** Error 37000: VD [Virtuoso Server]SQ074: Line 1: SP031: SPARQL compiler: No default graph specified in the preamble, but it is needed for triple constructor in INSERT {...} without GRAPH {...}
at line 3 of Top-Level:
SPARQL INSERT {_:node18errd605x19406 """67401""" .} WHERE { SELECT * {OPTIONAL {?s ?p ?o} } LIMIT 1 }

Thus I needed to specify and actual default graph name as indicated, for it to work:

SQL> SPARQL INSERT { GRAPH {_:node18errd605x19406 """67401""" . } } WHERE { SELECT * {OPTIONAL {?s ?p ?o} } LIMIT 1 };

Done. -- 1 msec.


@HughWilliams my bad, I copied a wrong version of the query. I updated my previous comment with a corrected one.
The version I used is the same as here).


@rnavarropiris , the updated variant of the query runs for me now:

SQL> SPARQL INSERT {GRAPH urn:test {_:node18errd605x19406 "67401" .}} WHERE { SELECT * {OPTIONAL {?s ?p ?o} } LIMIT 1 };

Done. -- 222 msec.
SQL> SPARQL select * from urn:test where {?s ?p ?o };
s p o

nodeID://b10013 67401

1 Rows. -- 27 msec.


The next versions of INSERT are worked for me:

SPARQL INSERT INTO <urn:test> {_:node18errd605x19406 <> "67401" .}; 
SPARQL INSERT {GRAPH <urn:test> {_:node18errd605x19406 <> "67401" .}};

It isn't used "INSERT DATA..." query, but it works.
About deleting of Blank Nodes like: nodeID://b12345
The next queries are worked properly:

sparql DELETE FROM <urn:test> { <nodeID://b12345>  <> "67401" .};


sparql DELETE FROM <urn:test> { `iri("nodeID://b12345")` <> "67401" .};

@smalinin: in your examples, neither the used syntax nor the direct usage of a node id are compliant with SPARQL 1.1 (which is a requirement of my current use case), that is why I use the mentioned "ugly" query workaround (it works with Virtuoso & Jena in-memory model, should work with other SPARQL 1.1 compliant stores as well)


@HughWilliams I think that INSERT DATA should handle these kind of bnodes (do you know if this will happen?)


@rnavarropiris are you saying that:

SPARQL INSERT {GRAPH <urn:test> {_:node18errd605x19406 <> "67401" .}};

is not SPARQL 1.1 compliant? If so, in what it is not?


@fgiasson: yes, the query is not compliant with the 2 INSERT query types: INSERT/DELETE (missing where clause) or INSERT DATA (missing DATA keyword). Virtuoso, however, accepts the "wrong" query (be it for backwards compatibility or for any other reason)


@rnavarropiris yeah that is right, didn't noticed the missing where clause. I think this is for backwards compatibility when the SPARUL specification was around (before SPARQL Update 1.1)


@fgiasson: I am checking the status of this with development ...


@HughWilliams: what's the status of this issue?


@rnavarropiris: It is still not resolved ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.