The triplestore is part of the application state. Mutations to that state include adding new terms: we currently load a submitted term into the triplestore, run validation, and if validation fails we drop that named graph and load the old set of terms back in. Validation currently takes a few seconds, and during that time any user accessing the triplestore will see the term(s) under test. We could also have multiple concurrent submissions, which would break the system. Those are just two examples.
One option is to build a lock for the triplestore and only allow one query at a time.
Another option is to be smarter how data is separated in the triplestore. Right now we're running queries against the default graph, which is the union of all the loaded named graphs. Instead we could query over the union of a careful selection of named graphs. This effects the way we write all our SPARQL queries, including the validation queries.
The triplestore is part of the application state. Mutations to that state include adding new terms: we currently load a submitted term into the triplestore, run validation, and if validation fails we drop that named graph and load the old set of terms back in. Validation currently takes a few seconds, and during that time any user accessing the triplestore will see the term(s) under test. We could also have multiple concurrent submissions, which would break the system. Those are just two examples.
One option is to build a lock for the triplestore and only allow one query at a time.
Another option is to be smarter how data is separated in the triplestore. Right now we're running queries against the default graph, which is the union of all the loaded named graphs. Instead we could query over the union of a careful selection of named graphs. This effects the way we write all our SPARQL queries, including the validation queries.