Make it easier for people to manage truth maintenance, including disabling it, dropping the computed entailments, recomputing the database-at-once closure efficiently, and re-enabling truth maintenance.
The following extensions to SPARQL UPDATE are proposed to manage the materialized entailments.
The following pattern illustrates a valid use of this feature when some assertions are retracted. This sequence of operations is ACID against a Journal. Clients will never observe an intermediate state where the full set of entailments are not available.
I am also wondering if there is any reason to "ENABLE ENTAILMENTS" or it that should be automatic when we call CREATE ENTAILMENTS.
Or ENABLE ENTAILMENTS could do the database-at-once closure and CREATE ENTAILMENTS could specify the set of rules to be maintained.
CREATE ENTAILMENTS "RDFS Plus"
CREATE ENTAILMENTS could default to the existing set of rules, but we also have an opportunity to change the rules that are being maintained at this point.
Mike and I also discussed some options to support this throught the NanoSparqlServer's REST API. The main concept was to add the following to the NanoSparqlServer API for methods that perform mutations.
And add a suppressTruthMaintenance method to the RemoteRepository, probably encapsulating it within the AddOp and RemoveOp classes by extracting a common base class and also refactoring the update() method to accept an UpdateOp that extends that common base class and inherits that boolean option. If you are using the REST API and the suppressTruthMaintenance URL query parameter to suppress incremental truth maintenance, the you can issue the "CREATE ENTAILMENTS" UPDATE REQUEST afterwards to update the entailments for the KB. If you have also retracted statements, then you would want to issue "DROP ENTAILMENTS; CREATE ENTAILMENTS;" to remove the old entailments before (re-)computing the entailments for the KB.
I am not yet convinced that it is a good idea to expose this feature through the REST API. Doing so makes it basically certain that the database will be exposed to mutation during a period when truth maintenance is disabled and that people will be able to read on states of the database that are not coherent in terms of the available entailments. It is much easier to encapsulate a series of changes in a single SPARQL UPDATE script. When that script runs, the entire process will be ACID. So long as the script restores entailments before it finishes, it will be impossible for clients to observe the intermediate database states.
Note: This issue was forked from BLZG-693 (SPARQL UPDATE "LOAD")
BLZG-918 (Turn on and off incremental truth maintenance and kick off database at once closure)