incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Jena and PostGIS (à la LARQ)
Date Tue, 13 Sep 2011 17:01:49 GMT
Andy Seaborne wrote:
> On 13/09/11 17:45, Paolo Castagna wrote:
>> Andy Seaborne wrote:
>>> On 13/09/11 16:14, Alexander Dutton wrote:
>>>> Does Fuseki/TDB currently fire off some kind of signal when updates
>>>> happen?
>>> Handling of events isn't consistent yet.
>>> Each GraphStore sees startRequest()/finishRequest() around a SPARQL
>>> Update. That should be roughly what you are looking for, I guess.
>>> There isn't an event down to the level of each quad added or removed.
>> This might be easier for developers (since they don't need to parse
>> the SPARQL Update request).
>> But, maybe there is a good reason why there isn't an event down to the
>> level of each quad added|removed. Let me guess: performances? :-)
> Not some much this time - here, it's consistency of the data.
> What does it mean to signal a quad added or removed without context? 
> e.g. for geo, it may take several triples to change the dataset from one 
> application-consistent view to another.
> Context matters here and just seeing a triple/quad change is a bit 
> useless.  What if you want to see a set of changes ... like one complete 
> update.

In the case of LARQ, a single triple/quad would be sufficient, since that
represent the complete update in order to update the underlying Lucene

However, this is a special and very simple case, in comparison to what you
might want to do in general.

Even the simplest geospatial index, for example, you want to have at least
two triples/quads: latitude and longitude.

Is there something in between SPARQL Update and triples/quads which would
simplify things for developers or receiving SPARQL Update notifications is
simple enough and the best thing to do?

>>> Now is a good time to work out the details of what's wanted. The
>>> original jena events mechanism works well but places the events on an
>>> object, so only objects supporting the event interface participate.
>>> Makes global or general events unnatural as well.
>> Yep.
>>  From a LARQ or similar point of view (i.e. third party custom indexes)
>> it would be extremely easy to be able to be notified for each quad
>> added or removed.
>> This way and external index can be kept up-to-date as data changes.
>> Often, there are little changes and it's a waste of time/resources
>> (and it require manual intervention or automated scripts) to re-index
>> everything just because a small percentage of data has changed.
> An example of wanting set of changes.

Yep, that would work as well.

>>> The package org.openjena.atlas.event (in ARQ) is my attempt to retain
>>> the light weigh event mechanism but decouple it from an event
>>> interface. You can send events relating to objects without the objects
>>> participation.
>> I'll have a look (and see if I can use that in LARQ).
> I suspect we need a system-wide design - e.g. events on transactions. 
> And transactions give a consistency point as well.

events on transactions == fire the event (with the set of changes) after
the transaction has been committed successfully?


>     Andy
>> Thanks,
>> Paolo
>>> Andy

View raw message