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 > On Sep 29, 2016, at 12:42 PM, Jason Koh <[email protected]> wrote: > > Thanks for the idea. I think it is great! Though this id due to my lack of > knowledge, one thing I am curious of is that DatasetGraph wrapper seems to > be for the entire graph. Does it mean that it runs SPIN inference to the > entire graph whenever I write something? I may want to apply SPIN partially > sometimes like applying SPIN on the new triples (not sure if it sounds > reasonable.) > > I will start looking at it! > > > With regards, > Jason Koh > cseweb.ucsd.edu/~jbkoh > > On Thu, Sep 29, 2016 at 8:37 AM, A. Soroka <[email protected]> wrote: > >> This seems a lot stronger in the end-- you get the Fuseki integration >> desired, but this would also be useful outside that context. And the code >> is going to be rather a lot easier to write. Much of Fuseki's code concerns >> managing HTTP action, which isn't really of the essence to your goal. >> >> --- >> A. Soroka >> The University of Virginia Library >> >>> On Sep 29, 2016, at 11:34 AM, Andy Seaborne <[email protected]> wrote: >>> >>> >>> >>> On 28/09/16 23:59, Jason Koh wrote: >>> ... >>>> Questions: >>>> 1. What is the functions related to SPARQL query processing? I am >> looking >>>> at SPARQL_Query.java, ActionSPARQL.java, etc., but this kinda >>>> reverse-engineering does not work well until now. I will look into the >>>> JavaDoc more, but I would appreciate if I can get an enlightment here. >>> >>> There is another way to hook in that may be useful. >>> >>> Instead of the HTTP request lifecycle, hook into the transaction >> lifecycle on the dataset. >>> >>> >>> A DatasetGraph wrapper means you can add the functionality to any >> existing dataset. >>> >>> This is in jena-arq. >>> >>> All Fuseki requests on the data are performed inside a transaction so if >> you catch a write transaction, and when it commits, trigger SPIN processing. >>> >>> Fuseki uses Jena's assembler mechanism to describe datasets so they can >> be setup and configured with needing application Java code >>> >>> Andy >> >>
