Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jakubklimek opened this issue Jan 22, 2014 · 24 comments
Open

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

jakubklimek opened this issue Jan 22, 2014 · 24 comments
Assignees

Comments

@jakubklimek
Copy link

@jakubklimek jakubklimek commented Jan 22, 2014

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
Copy link
Collaborator

@HughWilliams HughWilliams commented Jan 26, 2014

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

@ghost ghost assigned iv-an-ru Jan 31, 2014
@doriantaylor
Copy link

@doriantaylor doriantaylor commented Mar 13, 2014

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
Copy link

@doriantaylor doriantaylor commented Mar 13, 2014

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
Copy link

@doriantaylor doriantaylor commented Mar 13, 2014

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

@rnavarropiris
Copy link

@rnavarropiris rnavarropiris commented Dec 9, 2014

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
Copy link
Collaborator

@HughWilliams HughWilliams commented Dec 14, 2014

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

Done. -- 1 msec.
SQL> 
@rnavarropiris
Copy link

@rnavarropiris rnavarropiris commented Dec 15, 2014

@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
Copy link
Collaborator

@HughWilliams HughWilliams commented Dec 21, 2014

@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
Copy link
Collaborator

@smalinin smalinin commented Dec 22, 2014

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
Copy link

@rnavarropiris rnavarropiris commented Dec 29, 2014

@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
Copy link

@fgiasson fgiasson commented Jan 20, 2015

@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
Copy link

@rnavarropiris rnavarropiris commented Jan 20, 2015

@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
Copy link

@fgiasson fgiasson commented Jan 20, 2015

@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
Copy link
Collaborator

@HughWilliams HughWilliams commented Jan 21, 2015

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

@rnavarropiris
Copy link

@rnavarropiris rnavarropiris commented Jan 4, 2016

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

@HughWilliams
Copy link
Collaborator

@HughWilliams HughWilliams commented Jan 10, 2016

@rnavarropiris: It is still not resolved ...

@mwjames
Copy link

@mwjames mwjames commented Mar 12, 2016

Our integration tests [0] just encountered a similar issue:

PREFIX wiki: <http://example.org/id/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX swivt: <http://semantic-mediawiki.org/swivt/1.0#>
PREFIX property: <http://example.org/id/Property-3A>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX category: <http://example.org/id/Category-3A>
PREFIX wikiurl: <http://localhost/TravisWiki/index.php/>
INSERT DATA INTO GRAPH <http://example.org/phpunit-testrun> { 
wiki:Concept-3AConcept_for_any_value_selection
    rdf:type  owl:Class ;
    rdfs:label  "Concept for any value selection" ;
    swivt:page  <http://localhost/TravisWiki/index.php/Concept:Concept_for_any_value_selection> ;
    rdfs:isDefinedBy  <http://localhost/TravisWiki/index.php/Special:ExportRDF/Concept:Concept_for_any_value_selection> ;
    swivt:wikiNamespace  "108"^^xsd:integer ;
    owl:intersectionOf  (       [   rdf:type  owl:Restriction ;
            owl:onProperty  property:Population ;
            owl:someValuesFrom  rdfs:Literal ]      [   rdf:type  owl:Restriction ;
            owl:onProperty  property:Has_concept_description ;
            owl:someValuesFrom  rdfs:Literal ] ) ;
    swivt:wikiPageModificationDate  "2016-03-12T12:49:51Z"^^xsd:dateTime ;
    property:Modification_date-23aux  "2457460.0346181"^^xsd:double ;
    swivt:wikiPageSortKey  "Concept for any value selection" .
property:Modification_date
    rdf:type  owl:ObjectProperty ;
    rdfs:label  "Modification date" ;
    swivt:page  <http://localhost/TravisWiki/index.php/Property:Modification_date> ;
    rdfs:isDefinedBy  <http://localhost/TravisWiki/index.php/Special:ExportRDF/Property:Modification_date> ;
    swivt:wikiNamespace  "102"^^xsd:integer ;
    swivt:wikiPageSortKey  "Modification date" .
<http://semantic-mediawiki.org/swivt/1.0#page> rdf:type owl:ObjectProperty .
<http://semantic-mediawiki.org/swivt/1.0#wikiNamespace> rdf:type owl:DatatypeProperty .
<http://semantic-mediawiki.org/swivt/1.0#wikiPageModificationDate> rdf:type owl:DatatypeProperty .
<http://example.org/id/Property-3AModification_date-23aux> rdf:type owl:DatatypeProperty .
<http://semantic-mediawiki.org/swivt/1.0#wikiPageSortKey> rdf:type owl:DatatypeProperty .
 }

returns with

Virtuoso 37000 Error SP031: SPARQL compiler: Blank node '_:topcons_19_11' is not allowed in a constant clause

SPARQL query:
define sql:big-data-const 0 

Yet, the query works successful on Fuseki 1.1.1 [1], Sesame 2.8.7, and Blazegraph 1.5.2 [3].

[0] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki/jobs/115515265
[1] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki/jobs/115515263
[2] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki/jobs/115515269
[3] https://travis-ci.org/SemanticMediaWiki/SemanticMediaWiki/jobs/115515272

@HughWilliams
Copy link
Collaborator

@HughWilliams HughWilliams commented Mar 16, 2016

@mwjames: This test case has been added to the internal ticket for development to look into ...

@kidehen
Copy link

@kidehen kidehen commented Mar 16, 2016

On 3/15/16 9:32 PM, HughWilliams wrote:

@mwjames https://github.com/mwjames: This test case has been added
to the internal ticket for development to look into ...


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#126 (comment)

This issue is scheduled to be fixed such that SPARQL 1.1 INSERT variations
work consistently.

Regards,

Kingsley Idehen

@rnavarropiris
Copy link

@rnavarropiris rnavarropiris commented Jul 6, 2016

@kidehen Scheduled for a specific date/version? (7.2.5? 7.3.x?)

@hdoeleman
Copy link

@hdoeleman hdoeleman commented Feb 1, 2017

This is not fixed in version 07.20.3217.

When is this planned to be fixed?

@retog
Copy link

@retog retog commented Jan 21, 2018

I've notived that this operation has no effect

INSERT DATA { GRAPH <http://retog.linked.guru/> { <http://retog.linked.guru/question> <http://schema.org/question> _:B212cb46450a7f989762fb2a108d811f7 .
_:B3933053180ace24fceac3423cf15ddce <http://schema.org/name> "Steve" .
} }

while this one actually adds triples:

INSERT { 
  GRAPH <http://reto.linked.guru/> { 
    <http://retog.linked.guru/question> <http://schema.org/question> _:B212cb46450a7f989762fb2a108811f7 .
    _:B3933053180ace24fceac342cf15ddce <http://schema.org/name> "Steve" .
  }
}
WHERE {
  SELECT * {
    OPTIONAL { ?s ?p ?o . }
  } LIMIT 1
}

Is this also this issue?

@HughWilliams
Copy link
Collaborator

@HughWilliams HughWilliams commented Jan 21, 2018

Note this issue is resolved in the new SPARQL engine available in Virtuoso 8 which is currently ONLY available in commercial form:

SQL> SPARQL INSERT DATA { GRAPH <urn:sparql:tests:insert:data>  {_:node18errd605x19406 <http://www.w3.org/2006/vcard/ns#postalCode> """67401""" .} };

Done. -- 4 msec.
SQL> SPARQL SELECT * FROM <urn:sparql:tests:insert:data> WHERE {?s ?p ?o};
s                                                                                 p                                                                                 o
LONG VARCHAR                                                                      LONG VARCHAR                                                                      LONG VARCHAR
_______________________________________________________________________________

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

1 Rows. -- 2 msec.
SQL> SPARQL INSERT DATA { GRAPH <http://retog.linked.guru/> { <http://retog.linked.guru/question> <http://schema.org/question> _:B212cb46450a7f989762fb2a108d811f7 . _:B3933053180ace24fceac3423cf15ddce <http://schema.org/name> "Steve" . } };

Done. -- 2 msec.
SQL> SPARQL SELECT * FROM <http://retog.linked.guru/> WHERE {?s ?p ?o};                                                                             s                                                                                 p                                                                                 o
LONG VARCHAR                                                                      LONG VARCHAR                                                                      LONG VARCHAR
_______________________________________________________________________________

nodeID://b10015                                                                   http://schema.org/name                                                            Steve
http://retog.linked.guru/question                                                 http://schema.org/question                                                        nodeID://b10014

2 Rows. -- 0 msec.
SQL> 
SQL> status('');
REPORT
VARCHAR
_______________________________________________________________________________

OpenLink Virtuoso VDB Server
Version 08.00.3224-pthreads for Mac OS X as of Dec  4 2017 
@abourdon
Copy link

@abourdon abourdon commented Apr 23, 2018

@kidehen, when do you plan to add this fix into the opensource version?

rogargon added a commit to rhizomik/rhizomerAPI that referenced this issue Oct 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.