Question - Does Graal allow negating facts/rules?

[csavelief]

Hi,

I was wondering if Graal was allowing the negation of facts/rules:

@facts
u(1, 1, "garantie").
u(1, 2, "non").
u(1, 3, "souscrite").

u(2, 1, "garantie").
u(2, 2, "souscrite").

@rules
garantie_non_souscrite(X) :- u(X, A, "garantie"), u(X, B, "non"), u(X, C, "souscrite").
garantie_souscrite(X) :- u(X, A, "garantie"), u(X, B, "souscrite"), not garantie_non_souscrite(X).

@queries
?(X) :- garantie_souscrite(X). % Expected: X=2

[sipi]

Hi csavelief, not yet but an extension had been developed for stratified negation. it is accessible here: https://github.com/arthur-boixel/graal-stratified-negation

Does that meet your needs?

[csavelief]

It might. For now, I cannot make it run on my example above without throwing a fr.lirmm.graphik.graal.io.dlp.DlgpParseException: No statement found.

I tried to replace not garantie_non_souscrite(X) by not_garantie_non_souscrite(X) without success. I will try to debug it tomorrow (or maybe you know what is wrong?)

Thank you anyway!

[sipi]

I just tried, the set of rules and the set of facts must be in two separate files. java -jar graal-stratified-negation.jar -f rules.dlp -c facts.dlp Here the output of your example:

java.lang.StringIndexOutOfBoundsException: String index out of range: 0

===== ANALYSIS : STRATIFIABLE =====
Facts : parsing of 'facts.dlp'
java.lang.StringIndexOutOfBoundsException: String index out of range: 0
== Saturation ==
u\3("1","1","garantie").
u\3("1","3","souscrite").
u\3("1","2","non").
garantie_souscrite\1("1").
garantie_non_souscrite\1("1").

Ok, it doesn't work very well. I will have a look as soon as possible.

[sipi]

The tool seems to correctly compute the rule set stratification but does not apply the rules correctly… You can look at ASP tools (Answer Set Programming) for tools that manage negations, there is a list of tools on the Wikipedia page https://en.wikipedia.org/wiki/Answer_set_programming

[csavelief]

I tried Potassco and it is working fine on the previous example. Thank you!

Unfortunately, we will not be able to use it because our factbase is constantly changing and we cannot spend our time regenerating dlgp files. We currently use an Accumulo bridge to bind our factbase to Graal (and Jatalog) and we use this bridge to schedule queries every x minutes/hours/days.

[sipi]

We are interested by any use cases of Graal, can you tell us more about yours? Do you use forward or backward chaining? Do you use the rule set analyzer (Kiabora)? Do you use existential variables in your rules? For information, we are starting a project to handle key/value store in Graal… Maybe it will meet your needs. If you are interested to discuss your use case and your needs, we can do so by email (sipieter at lirmm dot fr and mugnier at lirmm dot fr) or even schedule a video conference.

[csavelief]

To be honest, we are not that much interested in using another triple store as our factbase. Accumulo allows us to manage sensitive facts in such a way that the same Ontology applied to the same factbase will yield different results according to the user's ACL. We already extend fr.lirmm.graphik.graal.core.store.AbstractTripleStore to feed data stored in Accumulo to Graal. The only reason we keep Jatalog is because of its ability to handle negations.

Our architecture looks like this :

Our collection process is way more complicated than the one above, but you get the idea. Our use case is to allow users to perform both simple queries (i.e. keyword search) and "bang queries" (ala DuckDuckGo) at the same time with the "bang queries" resorting to an Ontology.

For example, !demonstration (location:paris OR location:marseille) will returns all the documents which deal with demonstrations (strike, football event, etc.) and mention either paris or marseille.

[csavelief]

I watched this lecture and from what I understand there is no negation in Graal in order to lower queries complexity. Am-I correct?

Furthermore, I seem to understand that there is a kind of duality between the existential framework and graphs. Did you try to rewrite conjunctive queries as GraphBLAS (see this book for details) operations?

[sipi]

Hi, indeed "full" negation (ASP) increases the queries complexity however stratified one does not. If you want to manage "full" negation, you have to reason with multiple possible worlds but if you can stratify your rule set (compute a pre-order over rules in which you will never produce a "predicate" negated in a previous rule hypothesis) then you have no over-cost (except the computing of the pre-order but it can be pre-computed once).

About your second point, yes "fact base" can be seen as a graph (or an hyper-graph) but not, we does not try to implement conjunctive queries as GraphBLAS operations.