Rewrite the POrchestrator to execute a N3 reasoner from Javascript

[phochste]

In the current POrchestrator prolog is used to manage the input and output for the EYE reasoner. Rewrite the code so that JavaScript (typescript) is used the start up a rule engine and gather all results.

[RubenVerborgh]

If running in a non-browser environment, https://github.com/RubenVerborgh/EyeServer might be helpful. It is a JavaScript wrapper for the EYE Prolog process.

In the browser, we could also host a Prolog engine via WebAssembly if we wanted to.

Maybe @josd has more ideas?

[mielvds]

And there is https://github.com/mielvds/EyeJs of course, which is split off from https://github.com/RubenVerborgh/EyeServer

[josd]

If running in a non-browser environment, https://github.com/RubenVerborgh/EyeServer might be helpful. It is a JavaScript wrapper for the EYE Prolog process.

In the browser, we could also host a Prolog engine via WebAssembly if we wanted to.

Maybe @josd has more ideas?

To run EYE in WebAssembly I was doing an attempt to port eye.pl to Scryer-prolog which is written in Rust. At this moment the port is not working and Scryer-prolog is also (much) slower than SWI-Prolog.

[phochste]

Thanks for the feedback. Both a browser and server versions of reasoner might need to be supported in the project. There are some classes of time based (and resource based) policy rules, that require an always online present reasoner. There are also many classes of policy rules can be run in a browser that doesn't need to be always online and present (and need to run only when a person is at her computer).

I miss some insights, for my simple usecases, where in my Notation3 rules I would require a full prolog environment. Would it be that hard to write in JavaScript rules like the one below, given that there is already an N3 Notation3 parser?

{
  ?id a ?class .
  ?class list:in (as:Accept as:Reject as:Announce as:Offer) .
}
{
  [ pol:policy [
      a fno:Execution ;
      fno:executes ex:sendEventLog ;
      ex:notification ?id
  ] ]
}.

From my experiments this seems doable. But as I said, I don't have insights which subclass of Notation3 can be scaled down easily and don't require a full EYE reasoner + prolog.

[RubenVerborgh]

I recall that @joachimvh started a JavaScript N3 reasoner at some point.

[joachimvh]

I recall that @joachimvh started a JavaScript N3 reasoner at some point.

https://github.com/joachimvh/jsreasoner

This was never completely finished and it's been a while so I don't remember which parts of it work exactly (and I probably regret a lot of code decisions there at this point). I think forward reasoning worked fine, but it doesn't even come close to EYE reasoner in both features and performance.

[mielvds]

There's also stuff like https://github.com/tau-prolog/tau-prolog if that would somehow run eye

[josd]

There's also stuff like https://github.com/tau-prolog/tau-prolog if that would somehow run eye

Indeed and I tried it for a while but found it not feasable. Another nice integration is http://ppr.cs.dal.ca:3002/n3/editor/ which we use intensively in the N3 community group. It looks straightforward https://github.com/william-vw/n3-editor-js/tree/master/lib

[phochste]

I've been experimenting in typescript with N3 and Comunica to write an engine using a very small subset of the Notation3 language I need for my project. The first implementation https://github.com/phochste/NO3 seems to be able to do inferences of simple rules.

Not using the richness of the Notation3 language allows for a lot of simplifications. Well ..that is ...from a programmers viewpoint to get something working. But, now I also understand much better why it is hard to create an implementation. The Javascript version works (a bit for easy cases), but is very (very very) slow compared to EYE and lacks many features. This is not something that can be solved with straightforward programming (like I did).

I learned more about Notation3 and can't wait for a real solution.