I assumed you didn't want a coding solution. It can be done - there is code in RDF Delta 1

jena-arq's DatasetGraphMonitor is right idea but does not go far enough. Theer is only any point notifying at the commit point else any inspecting the data won't see the changes if that happens too quickly.

You could just wrap with DatasetGraphWrapper and intercept the commit.

rdf-patch has DatasetGraphChanges is more sophisticated. It signal all operations, alloing the differences to be built up and then handled when commit happens.

It is currently used to send a patch to a URL.

But this fails have "Fuseki push" - some assembly required.


On 10/08/18 16:52, Claude Warren wrote:
I was actualy thinking of putting a message on a queue so that anyone
listening could pick it up.  Most of our infrastructure is based on push
rather than pull.  Particularly when our data sources are in a more secure
zone.  We only want to connect from the most secure zone to the lesser
secured zone not visa-versa  if possible.  A push would make much of this

worst case I can create a poller that does the push but I suppose I was
looking for a more elegant solution.


On Fri, Aug 10, 2018 at 1:28 PM, Andy Seaborne <a...@apache.org> wrote:

General comment about Fuseki (or any server really):

Having server track the clients so it can initiate sending is a real pain
to do: clients go away, client crash without signing off, clients get
moved, clients go slow, etc etc.

Having the client poll the server may seem like excessive work but the
reality is that many systems are built that way underneath for all those
client reasons.

The trick is to make the "ping" cheap.

For RDF, keep triple with the tiemstamp of last change and get it each

Or to put it another way, do Last-Modified or ETags for the data.


On 09/08/18 17:29, Nouwt, B. (Barry) wrote:

Hi Claude, another hack that might work (but is probably a bit devious),
is using a GenericRuleReasoner rule instead of a ASK query, like:

[myAskRule: (?some pre:pattern bla:Eek) (?some eek:prop
"1234"^^xsd:integer) (...) -> print("The condition is TRUE!!!")
customBuiltinThatNotifies(?some, "s...@eek.org") ]

Note that you would need to create a custom 'notification' Builtin that
contains the actual notification logic.

Regards, Barry

-----Original Message-----
From: ajs6f <aj...@apache.org>
Sent: donderdag 9 augustus 2018 16:59
To: users@jena.apache.org
Subject: Re: Push notification?

Hey, Claude--

Is it a particular ASK query or just any time any ASK query returns
successfully? I don't know enough about ARQ to really answer your question,
but a hack might be to see if there is an exact pattern of calls to find()
that occur for that ASK and only that ASK on the underlying DatasetGraph
and use DatasetGraphWrapper to intercept and fire your notifications. I'm
guessing there's a much cleaner better way to do that at ARQ, which will
actually know about ASK queries, and I'm looking forward to someone who
knows more than I telling us what that is. :grin:


On Aug 9, 2018, at 10:39 AM, Claude Warren <cla...@xenei.com> wrote:

Does anyone have a way to have Jena/Fuseki perform push notifications?
I am looking for a mechanism whereby I can create an ASK query and be
notified when it succeeds.

Any ideas would be appreciated.

I like: Like Like - The likeliest place on the web
LinkedIn: http://www.linkedin.com/in/claudewarren

This message may contain information that is not intended for you. If you
are not the addressee or if this message was sent to you by mistake, you
are requested to inform the sender and delete the message. TNO accepts no
liability for the content of this e-mail, for the manner in which you use
it and for damage of any kind resulting from the risks inherent to the
electronic transmission of messages.

Reply via email to