On 25/04/2019 14:13, Marc Agate wrote:
Hi Andy,
We (https://www.tbrc.org/#!footer/about/newhome
<https://www.tbrc.org/#!footer/about/newhome>) currently have all our data
(this is quite huge) in a single fuseki based TDB instance. While we have
successfully implemented the « read » part of our system, we are now planning to edit
any resource or graph of this dataset as necessary.
So our main concern is not (for now) to maintain in sync various version of the
same dataset across a network of fuseki servers. It is really to apply rdf
changes to our dataset, from a web app using a sophisticated client UI and
software.
The rdf update is actually one part of what we call an "edit transaction",
since other actions need to be taken along with rdf patching, namely Logging and also
updating a git repo containing turtle serializations of all the resources of our dataset
(from which we can rebuild our TDB dataset when necessary, thanks to a custom java
software).
Therefore, we thought about using RdfPatch and RdfChanges to apply rdf changes,
while eventually leveraging any available logging features (and more features,
if suited).
We will have to process batches as well and we are about to investigate what
could be the best way to proceed in that situation and what would the patch
look like in such a case (one transaction, many transactions, transaction
rollback strategies, etc…)
For now, the basic question is: what is the best way to proceed when using an
existing remote server ? (FYI: I tried to get a graph from a DatasetAccessor,
then to get a RDFChangesApply object and a RDFPatchReaderText to apply the
changes, but I was unable so far to make it work - I suppose I might have to
put back the edited graph in the dataset, using the datasetAccessor...).
Is the code for that open somewhere?
1/
DatasetAccessorFactory.createHTTP? A graph from that is a copy. If that
is then the default graph of a dataset, it'll not have the graph name in
the RDFPatch (
If you can pull the graph (by name), edit it locally, you can PUT it
back to replace the data. Practical for small graphs.
Or an RDFChanges that adds back the graph name.
add(dftGraph or null, s,p,o) -> add(graphname, s,p,o)
2/
General comment - RDFConnection is a better API. It pulls all the ways
of accessing toegther into one place. RDFConnectionFuseki enables blank
node handling such as fetching one graph with blank node labels not
transformed by syntax issues of _:label.
Andy
I am gonna check the docs and code in more details. Any input and advice from
you will be greatly appreciated!
Marc
Le 25 avr. 2019 à 06:19, Andy Seaborne <[email protected]> a écrit :
On 24/04/2019 14:20, [email protected] wrote:
Hi,
We are planning to use RDF Patch and RDF Delta
(https://github.com/afs/rdf-delta) to edit our TDB dataset served through a
fuseki endpoint.
Interesting!
We took a look at various docs pertaining to Delta and Patch and browse the
github repo, but we are still wondering about what could be the best approach
for implementing a solution to our issue.
Can you say more about the solution?
Is there Delta java docs available somewhere (that would be a first step to be
able to navigate easily through the various library packages).
There is javadoc with each artifact when you get the artifacts (maven, gradle
etc)
e.g.
http://central.maven.org/maven2/org/seaborne/rdf-delta/rdf-delta-client/0.7.0/rdf-delta-client-0.7.0-javadoc.jar
Thanks
Marc.
