Re: implementations of networked RDF store replication, please?

>>>>> Steve Harris <steve.harris@garlik.com> writes:
>>>>> On 2011-03-01, at 09:42, Ivan Shmakov wrote:

[…]

 >>> If it's for the purposes of replication then you can configure
 >>> 4store to do this, and probably most other clustered RDF stores.

 >>> Just create a cluster of two nodes, and enable replication. Your
 >>> write will end up on both nodes. Then you will be using whatever
 >>> internal protocol the cluster uses though, rather than HTTP. It
 >>> should be more efficient, but it's not portable between RDF stores.

 >> ACK.  Thanks.

 >> Furthermore, I see that both of the solutions impose the “single
 >> administrative domain” limit — they don't seem to provide a way for
 >> “stranger nodes” to walk in from time to time, subscribing and
 >> unsubscribing to the change notifications as they wish.

 > 4store allows that, at least in theory. Its discovery is based on
 > mDNS - I don't know how often/how the HTTP server responds to new
 > replicas appearing though. Depending on the volume of data the
 > catchup time can be considerable, and self-consistent, but globally
 > inconsistent replicas aren't that useful for many purposes, so we
 > wouldn't recommend running it that way.

 ACK.

 Actually, somehow in my searches for an RDF store, I've missed
 4store entirely (BTW, registering it on http://freshmeat.net/
 may help make it known), but now I see that I should give it a
 try.  Thanks.

 > Modifying the storage code to allow global inconsistency would be
 > trivial, if you have a use case where that's advisable. I guess we'd
 > accept a patch that made it a compile time option.

-- 
FSF associate member #7257