On 29/09/16 17:47, A. Soroka wrote:
DatasetGraph covers the same ground as an RDF Dataset. So you have a
default graph and many named graphs, each with its own triples. When
an update is made, it is via methods that work with a single quad at
a time. _BUT_ those methods can be (always are with Fuseki) used
within the boundaries of a transaction, which is declared by other
methods on DatasetGraph. So at a given moment during an update in
Fuseki, you will have a bunch of triples sorted into different
graphs, and you will be calling different add and remove methods.
When the update is done, a commit method will be called on the
DatasetGraph.
So you could hook into the begin method (called to begin a
transaction) and the add and delete methods (to keep track of what is
being changed during the transaction/update) and then the commit
method (so that you can trigger your rules then, using whatever
context is appropriate).
--- A. Soroka The University of Virginia Library
Yes - the unit of transactions is the dataset (= a default graph and
zero or more named graphs)
Transactions are significant here for two reasons:
* API: Meaningful boundaries for changes from the application-domain -
SPIN works against a whole graph so which the graph is changing, seeing
incomplete updates is not useful. If adding a person is 3 triples,
foaf:Person, first name, last name values, then seeing the graph while 1
of those 3 has been added but not the other two yet, then a rule for
"Persons" isn't useful. A transaction marks with begin-commit a set of
changes.
* Unit of persistent change. A graph (model) is a view of a dataset and
datasets are the units of transactions for robustness, persistence etc
(all the ACID properties).
That does not preclude processing changes as they stream in. Any
inference changes get applied to the permanent storage at the
transaction commit.
Andy
