Pystardog insert named graph not updating

Hi I am a bit new and am getting confused.

I am using pystardog to hit a nonlocal db using virtual graphs. I am connecting to the nonlocal db and can query some results. I am having trouble updating the named graph I created to hold the relevant data. I am using the following options for uploading my ontology.

admin.new_database('db', {'': True, 'virtual.transparency': True, 'query.all.graphs': True})

Once creating my virtual graphs I perform the following operations:

conn.add(stardog.content.File('defaultstatement.ttl'), graph_uri='urn:12345') #this named graph contains an rdf statement.

The update from conn.update(sparql) contains string sparql, which looks something like this:

GRAPH <urn:12345> {
?s ?p ?o
?s a someObjectsAndStuff
however a select query on the named graph does not show the updated values. Any help would be much appreciated!


Hi Kevin,

What exactly were you expecting the results of the insert query to be? I don’t believe that it’s a valid query since there are no bindings for ?p and ?o but even if it was what I suspect you were trying to do you’d be querying the default graph, which is the union of all graphs including the one you’ve added data to, and inserting it back into the named graph which wouldn’t result in any changes.

1 Like

Hi Zachary,

The results I am expecting are the results from a SELECT query on the named graph that I updated with conn.update(sparql). I tried select queries like this :

SELECT ?s ?p ?o WHERE {GRAPH <urn:12345> {?s ?p ?o} }

but they only ever return the defaultstatement.ttl from the named graph.

Perhaps I am not using the correct methodology for creating a named graph from a nonlocal db.

My thinking:

  1. add ontology and create virtual graphs.
  2. Create a named graph with conn.add
  3. pull a constrained subset of the nonlocal db through virgual graphs and insert it into the named graph
  4. prove that this subset of data was put in the named graph by performing the SELECT query of the named graph above

Have you verified adding this file adds the expected data?

Following that, your update must bind all variables in the INSERT which is what Zachary is pointing out.

The default statement does show up as expected:

<urn:foo> a <urn:bar>

The INSERT I have looks closer to this in actuality (sorry for the poor example before):

GRAPH urn:12345 {
?s ?p ?o
?s a someObject

...some other constraints and filters...

?s ?p ?o

Does the triple at the end of the where clause sufficiently bind the variables?

Yes, that looks good. If you have query.all.graphs enabled, that should find the data in the urn:12345 graph (the one you added the file contents to). Does a SELECT work with the same WHERE?

I see two different formats for BIND in the docs and in the auto-mappings.

Which is correct or do they both work?
Docs ...
BIND (template("{acctNum}") AS ?subject)
Auto ...
BIND(template("{acctNum}") AS ?subject)


Your query isn’t going to produce any triples that aren’t already in your named graph unless you were expecting to be adding triples from your virtual graph. Is that what you were expecting?

I don’t think virtual graphs are added to the default graph even if you set the query all graphs option. There is a new feature, auto-virtualization? transparent virtualization? Something like that. I can’t remember the exact name right now. (I’m on my phone). That does do that but you’d have to enable that. I’m not sure if it works for update queries or just select queries. If not you’d have to explicitly add virtual graphs.

Zach, We were expecting triples to be added to the named graph from the virtual graph. Virtual Transparency was ON as was the query.all.graphs option.

Jess, You might want to fix the auto-generated mapping output for Studio. It is the one that generated the BIND(template("[{acctNum}") AS ?subject) clause. This is wrong, since I clearly don't want an = in my IRI. Interestingly enough, the auto-generated mapping in Studio generated BIND clauses to create IRIs without the = as well.


While it lacks a certain aesthetic appeal it comes from the R2RML direct mapping spec

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.