that's indeed the point: at least one dataset may (and is going to
receive) updates during runtime - so merging both datasets into one is
not the best solution. Currently I've solved this update problem by
adding a model listener that notifies my when an update occurres on the
original dataset. In this case - and only in this case - I have to
(re)merge both datasets again to keep my data consistent.
Querying is then performed only on this consistent, merged dataset.
As I already asked yesterday: did anyone of you already work with
MultiUnion - is it better than using model.union()?
Thorben
Am 23.10.2011 11:21, schrieb Bill Roberts:
indeed, the downside is possibly having to carry out updates in more than one
place - a classic consistency vs speed of access pay-off.
And where the best solution lies will depend on the nature of the data and what
Thorben wants to do with it.
On 23 Oct 2011, at 11:02, Paolo Castagna wrote:
Bill Roberts wrote:
On 22 Oct 2011, at 17:25, Thorben Wallmeyer wrote:
Am 21.10.2011 21:22, schrieb Andy Seaborne:
On 21/10/11 10:24, Thorben Wallmeyer wrote:
Hi all,
I've got a simple problem and looking forward to a "good" solution.
Hopefully someone can give me a useful hint... ;-)
I've got two TDB backed models both containing several named graphs: A
and B
You mean 2 TDB datasets?
I realise it's obvious and so you probably have good reasons you don't want to
do it, perhaps to do with avoiding duplication - but simply copying all the
data into a single TDB seems the easiest and quickest solution.
Hi Bill,
indeed, that seems the easiest solution, in particular if the two RDF datasets
you want to merge do not receive a lot of updates and you do not mind having
the merged result not updated in real-time with the sources.
If you allow stuff to be added/removed from the original RDF datasets and you
want to keep the merged dataset in sync things become more complicated. In
particular deleting stuff.
See also:
http://www.w3.org/2011/rdf-wg/track/issues/17
Paolo
Regards
Bill
