Skip to content

Loading…

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

Open
jakubklimek opened this Issue · 16 comments

7 participants

@jakubklimek
INSERT DATA {_:node18errd605x19406 <http://www.w3.org/2006/vcard/ns#postalCode> """67401""" .}

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

INSERT {_:node18errd605x19406 <http://www.w3.org/2006/vcard/ns#postalCode> """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

@HughWilliams
Collaborator

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

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

There is a similar issue with DELETE, for which I found http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTricksGuideDeleteTriplesWithBlanknodes 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?)

@doriantaylor

Never mind, found this: http://docs.openlinksw.com/virtuoso/rdfdatarepresentation.html

Plus this solution:

SELECT
(<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
WHERE {
    GRAPH <http://example.com/d> {
        ?s ?p ?o FILTER isBLANK(?s)
    }
}

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

@doriantaylor

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

@rnavarropiris

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 <http://www.w3.org/2006/vcard/ns#postalCode> """67401""" .}

try this

INSERT {GRAPH <urn:test> {_:node18errd605x19406 <http://www.w3.org/2006/vcard/ns#postalCode> "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.

@HughWilliams
Collaborator

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

SPARQL INSERT DATA {:node18errd605x19406 http://www.w3.org/2006/vcard/ns#postalCode """67401""" .}
SQL> SPARQL INSERT {
:node18errd605x19406 http://www.w3.org/2006/vcard/ns#postalCode """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 http://www.w3.org/2006/vcard/ns#postalCode """67401""" .} WHERE { SELECT * {OPTIONAL {?s ?p ?o} } LIMIT 1 }
SQL>

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

SQL> SPARQL INSERT { GRAPH {_:node18errd605x19406 http://www.w3.org/2006/vcard/ns#postalCode """67401""" . } } WHERE { SELECT * {OPTIONAL {?s ?p ?o} } LIMIT 1 };

Done. -- 1 msec.
SQL>

@rnavarropiris

@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).

@HughWilliams
Collaborator

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

SQL> SPARQL INSERT {GRAPH urn:test {_:node18errd605x19406 http://www.w3.org/2006/vcard/ns#postalCode "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
VARCHAR VARCHAR VARCHAR


nodeID://b10013 http://www.w3.org/2006/vcard/ns#postalCode 67401

1 Rows. -- 27 msec.
SQL>

@smalinin
Collaborator

The next versions of INSERT are worked for me:

SPARQL INSERT INTO <urn:test> {_:node18errd605x19406 <http://www.w3.org/2006/vcard/ns#postalCode> "67401" .}; 
SPARQL INSERT {GRAPH <urn:test> {_:node18errd605x19406 <http://www.w3.org/2006/vcard/ns#postalCode> "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>  <http://www.w3.org/2006/vcard/ns#postalCode> "67401" .};

OR

sparql DELETE FROM <urn:test> { `iri("nodeID://b12345")` <http://www.w3.org/2006/vcard/ns#postalCode> "67401" .};
@rnavarropiris

@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)

@fgiasson

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

However,

@rnavarropiris are you saying that:

SPARQL INSERT {GRAPH <urn:test> {_:node18errd605x19406 <http://www.w3.org/2006/vcard/ns#postalCode> "67401" .}};

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

@rnavarropiris

@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)

@fgiasson

@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)

@HughWilliams
Collaborator

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

@rnavarropiris

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

@HughWilliams
Collaborator

@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.