Clojurians Log v2
asami
@quoll: Am I right that naga/pabu doesn’t implement negation or failure, or any way to do intersection? It’s purely monotonic right?
no
Not at all
There’s the not operator in queries
which can also be used in rules for Naga. Indeed, if you create a new object in the head of a rule, then Naga updates the query to use a not expression to remove existing entities that already match the pattern
is there an example?
Uh… probably. I’m rushing out at the moment, sorry
its ok I’ll do some digging in the code; thanks for the pointer 🙇
asami.core-query-test/test-not-query (line 70) uses it
Also, I don’t know what you mean by “intersection”
inner joins are an intersection. Do you maybe mean graph intersections? Or something else again?
sorry I didn’t mean intersection at all; that’s clearly used a everywhere — I meant disjointness constraints
OK, yes. It’s the not operator.
I don’t actually follow Datomic semantics 😳
Instead, I follow SPARQL semantics
me too
🙂
Also, look at test/naga/test_rules.cljc line 238 (test-rewrite). That’s doing query rewriting for rules
@quoll: Sorry that appears to be in asami queries… I’m meaning in naga rules
Well, Naga rules ARE Asami queries
They’re based on them anyway
That test takes a set of patterns for generating data, and a :where clause, and it rewrites the :where clause to exclude data that already matches the output pattern
Rules do this internally
ok — not sure if this is quite what I’m after
Essentially if I detect a contradiction in the graph; I’d like to fail the reasoning
e.g. rules like eq-diff1: https://www.w3.org/TR/2012/REC-owl2-profiles-20121211/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules
e.g. return a failing goal
I suppose I could always just return a special error report node, that if present meant inconsistency… I guess I could capture information the failure that way too
Are you thinking like eq-diff1 rule?
That kind of thing is not negation! There are 2 approaches. One is to assert data that indicates a failure. The other is to have rules perform a failing action rather than asserting data. Either way, it’s a positive test. It’s just what you choose to do with what you find
Naga has a space in it for doing non-assertion things. I just haven’t had a need to do it yet 🙂
My original thought was to connect to a messaging API and send things there. A client process could then report on what comes through.
The other thing is to define a head that indicates an error. I thought maybe an empty head. Or possibly a predicate form, like (error "eq-diff2") :- owl:sameAs(X, Y), owl:differentFrom(X, Y).
see in Naga: src/naga/engine.cljc line 125
OK. You’re looking for output when something does not exist
That’s hard to do in terms of query bindings
It’s approximated by having statements that match the negation term, and use a NOT operation to remove them
But you need data that exists to subtract your terms from
ok cool that’s essentially what I was thinking I’d do too. I think that’ll work for a lot of what I want.
It’s interesting to think of an assertion when something doesn’t exist. It doesn’t make sense for a query, but it does for a rule. I think I can manage that