If the changes are in the right shape, and in RDF, the change can be
applied with (outline):
DELETE WHERE {
<some_resource> ?p ?o
... any metadata about <some_resource> ...
} ;
INSERT DATA {
... new data ...
}
but the danger of working with this is that not all changes fit this
pattern and the copy will drift apart. The compromise might be do
incremental for a few times and rebuild every 1 or 3 months.
Andy
On 25/11/17 09:14, Lorenz Buehmann wrote:
Ah, interesting. That's what I meant with incremental changeset provided
by the source maintainer. I knew that there was something like this for
DBpedia, simply providing changesets of triples. Weird that there is no
RDF format available for Wikidata. Maybe Laura could open a feature request.
By the way, thanks for RDF Patch pointer.
Cheers,
Lorenz
On 24.11.2017 18:43, ajs6f wrote:
Wikimedia does offer a sort of general procedure for this: you can check to see
the updates since the last dump and do per-resource changes.
https://www.wikidata.org/wiki/Wikidata:Data_access#Incremental_updates
But perhaps more efficiently for yourself, you could use their incremental
dumps:
https://dumps.wikimedia.org/other/incr/wikidatawiki/
which are for some reason only provided in XML.
ajs6f
On Nov 24, 2017, at 12:24 PM, Laura Morales <[email protected]> wrote:
Laura, can you tell us a little more about why you are trying to avoid
transmitting the whole graph? Is it because of an unreliable network between
your client and Fuseki or because of something else?
Wikidata is about 4 billion triples, and it takes a lot of time to create the
TDB store from the nt file. They release a new dump about once a week, and I
would like to update my local copy when they release a new dump. Reloading the
entire graph from scratch every time seems very inefficient (as well as an
intensive process) considering that only a tiny % of the wikidata graph changes
in a week.
