So my Abox and rulesets changes from time to time, and hence I would like to remove old triples and add new triples when needed. The Abox and rulesets are in different .ttl files, but I sent the data to the database during creation with bulk loading.
There are several valid ways to accomplish this. If you have small amounts of data to delete or insert, you can write a SPARQL DELETE/INSERT query. If you just have the files, you can manually stardog data remove myDb oldFile.ttl and stardog data add myDb newFile.ttl on the CLI. If you have versioning enabled on your database you can perform the delete and insert through one stardog vcs call like so.
Versioning is not enabled by default, so chances are high you don't have it. You can read the versioning example in our stardog-examples repository for an in-depth tutorial on how our versioning works and what it does.
The problem is that Bnodes are anonymous resources which are assigned IDs at parsing time. The assigned IDs are not consistent across invocations. Let me illustrate this with an example.
Inability to remove Bnodes
Create a simple file with a Bnode, load it into Stardog and verify the data is present:
$ cat x.ttl
<urn:a> <urn:b> [ <urn:c> <urn:d> ] .
$ stardog data add test x.ttl
Adding data from file: x.ttl
Added 2 triples in 00:00:00.050
$ stardog query execute test 'select * where { ?s ?p ?o }'
+------------------------------------------------+-------+------------------------------------------------+
| s | p | o |
+------------------------------------------------+-------+------------------------------------------------+
| urn:a | urn:b | _:bnode_5e84acc9_885d_4f49_8ca1_32aad1fbef5e_1 |
| _:bnode_5e84acc9_885d_4f49_8ca1_32aad1fbef5e_1 | urn:c | urn:d |
+------------------------------------------------+-------+------------------------------------------------+
Query returned 2 results in 00:00:00.053
Note the generated ID in the Bnode namespace: _:bnode_5e84acc9_885d_4f49_8ca1_32aad1fbef5e_1.
If we try to delete the data by passing the same file to Stardog, a new Bnode ID will be generated and the deletion will not match any triples:
$ stardog data remove test x.ttl
Removing data from file: x.ttl
Removed 0 triples in 00:00:00.039
Removing triples deterministically
Now consider this example which does the same thing use an IRI:
$ cat x2.ttl
<urn:a> <urn:b> <urn:realIRI>
<urn:realIRI> <urn:c> <urn:d> .
$ stardog data add test x2.ttl
Adding data from file: x2.ttl
Added 2 triples in 00:00:00.070
$ stardog query execute test 'select * where { ?s ?p ?o }'
+-------------+-------+-------------+
| s | p | o |
+-------------+-------+-------------+
| urn:a | urn:b | urn:realIRI |
| urn:realIRI | urn:c | urn:d |
+-------------+-------+-------------+
Query returned 2 results in 00:00:00.036
$ stardog data remove test x2.ttl
Removing data from file: x2.ttl
Removed 2 triples in 00:00:00.035
In this example, we loaded the same structure but instead of using a Bnode, we used an IRI. The deletion worked because the urn:realIRI matched the object/subject of the associated triples.
The [] is the blank node and everything inside of it is triples with the blank node as the subject. Please let me know if some aspect of my example was not clear.