Delete data with blank nodes - Stardog cluster

HI,

I add a .ttl file which contains a rule:

PREFIX rule: tag:stardog:api:rule:
a rule:SPARQLRule ;
rule:content """ (contant removed) """ .

But then I experience difficulties to remove that rule from the store.

Obviously, to remove with the web console and the Data-Remove option will fail because of the blank node. However, I tried to load it in a specific Named Graph and then delete all triples from that graph, but the rule is still there. My SPARQL query to delete the NG:

DELETE where {GRAPH {?s ?p ?o}}

When I do the same but attributing a specific URL to that rule, than I can add/delete the data as expected (either with the data/remove GUI, or the SPARQL query).

As I am trying our new cluster, I wonder if I am just doing something wrong or if we could have some issues with the cluster/replication when blank nodes are involved ?

Thanks for any help
Fabian

Hi Fabian,

There are a couple different approaches you can take here. You could try running a query like:

DELETE WHERE {?r a rule:SPARQLRule ; rule:content """ (your rule here) """ }

That should remove the blank node. However if you have loaded the rule into a named graph you can use a DROP GRAPH <http://my.graph> query instead of a DELETE query, and that should also accomplish what you want.

1 Like

Now I realize what was happening with blank nodes and our cluster, and it makes me a little "scared" of blank nodes.

I would like to know if this is the correct behavior of a 3 nodes cluster with a HA load balancer, or if we did something wrong.

Each time I execute a query by pressing "Execute" on the web console, the response is obviously given by each cluster-node one after another.

I did load my rule, as described here above, the rule being:

a rule:SPARQLRule ;

I do have only one rule in the store. When I execute 3 consecutive time the query:to get the instances of rule:SPARQLRule, I will have each time a new resultset with one anser:
first run:

_:bnode_37f16220_602f_4ce7_9174_35d9d292ca7c_80

second run:

_:bnode_37f16220_602f_4ce7_9174_35d9d292ca7c_81

third run:

_:bnode_37f16220_602f_4ce7_9174_35d9d292ca7c_79

Which means that, on each server, the same rule:SPARQLRule did get a different bNode id. (if I keep on executing the query I will get one of those ID over and over again).

The DB is configured with Preserve BNode identifiers =ON, but this seems to have no effect here.

And this is where my strange behavior of my first post here happens: the rule is in a specific Named Graph, and I wanted to remove the rule by doing a

DELETE where {GRAPH <thegraph> {?s ?p ?o}}

And so, what was happening, is that the blank node of the rule was effecively delete from the cluster-node that was answering the query, but was not replicated on the other nodes, certainly because they are different resources/triples.

And then, when I execute 3 consecutive time the query:to get the instances of rule:SPARQLRule, I would expect to have no answer (empty resultset), but I will have two times the bnode corresponding to the answering cluster-node, and one time an empty result-set (when answered by the cluster-node on which the delete was performed).

Isn't this becoming a "nightmare" to handle triples with bNodes on a cluster ?
I am not used to work with bnodes, so maybe there is an easy workaround or guidelines that must be followed if we don't want the cluster to become a mess when updating datasets with bNodes?

Thank you
Fabian

Fabian,

Does the same behavior happen if you use a DROP GRAPH <thegraph> query instead of a DELETE query?

What about if you do a delete that is explicit about the rule:content like I mentioned in my previous post?

Stefen,

DROP GRAPH

works fine.

But about:

I do not manage to perform such a query, maybe due to the content of rule:content ?

A select query works fine, the rule is found:

select *
{
graph ?g{
?rule a rule:SPARQLRule ;
rule:content """prefix skos: <SKOS Simple Knowledge Organization System Namespace Document - HTML Variant, 18 August 2009 Recommendation Edition; prefix tstOnto: <http://testonto/&gt; IF {?s skos:prefLabel ?label .} THEN {?s tstOnto:aLabel ?label .}"""
}}

But a DELETE with the same content deletes nothing (the rule is still there, on the three nodes):

PREFIX rule: tag:stardog:api:rule:
DELETE WHERE {?r a rule:SPARQLRule ; rule:content """prefix skos: <SKOS Simple Knowledge Organization System Namespace Document - HTML Variant, 18 August 2009 Recommendation Edition; prefix tstOnto: <http://testonto/&gt; IF {?s skos:prefLabel ?label .} THEN {?s tstOnto:aLabel ?label .}"""}

But eventhough that query would work, is there not a special caution that should be taken with blank nodes, or do you mean that the situation I produced is a "bug" on our installation only ?

Thanks
Fabian

Fabian,

I’m not sure if it’s a typo, but your DELETE WHERE query does not contain the graph ?g that your select does, which would cause it to return no results. On further inspection, it doesn’t have the complete definition of prefix rule: but that’s probably a copy/paste error.

Regardless of this, the purpose of a bnode is specifically that you do not care what the identifier is. And while yes, I agree that a delete query like this should propagate over all the nodes in a cluster, a very simple way to avoid this (and obviously to ensure that the rule has the same identifier over all 3 nodes) would be simply to assign it an identifier instead of using a bnode:

:Rule1 a rule:SPARQLRule ;
    rule:content """ whatever """ .

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