Fork me on GitHub
#asami
<
2021-03-04
>
rickmoynihan23:03:30

@quoll: Am I right that naga/pabu doesn’t implement negation or failure, or any way to do intersection? It’s purely monotonic right?

quoll23:03:05

Not at all

quoll23:03:37

There’s the not operator in queries

quoll23:03:34

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

rickmoynihan23:03:59

is there an example?

quoll23:03:19

Uh… probably. I’m rushing out at the moment, sorry

rickmoynihan23:03:40

its ok I’ll do some digging in the code; thanks for the pointer 🙇

quoll23:03:42

asami.core-query-test/test-not-query (line 70) uses it

quoll23:03:05

Also, I don’t know what you mean by “intersection”

quoll23:03:25

inner joins are an intersection. Do you maybe mean graph intersections? Or something else again?

rickmoynihan23:03:36

sorry I didn’t mean intersection at all; that’s clearly used a everywhere — I meant disjointness constraints

quoll23:03:52

OK, yes. It’s the not operator. I don’t actually follow Datomic semantics 😳 Instead, I follow SPARQL semantics

quoll23:03:15

Also, look at test/naga/test_rules.cljc line 238 (test-rewrite). That’s doing query rewriting for rules

👀 1
rickmoynihan23:03:35

@quoll: Sorry that appears to be in asami queries… I’m meaning in naga rules

quoll23:03:03

Well, Naga rules ARE Asami queries

quoll23:03:25

They’re based on them anyway

quoll23:03:59

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

quoll23:03:22

Rules do this internally

rickmoynihan23:03:52

ok — not sure if this is quite what I’m after

rickmoynihan23:03:10

Essentially if I detect a contradiction in the graph; I’d like to fail the reasoning

rickmoynihan23:03:16

e.g. return a failing goal

rickmoynihan23:03:38

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

quoll23:03:14

Are you thinking like eq-diff1 rule?

👍 1
quoll23:03:13

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

quoll23:03:25

OK. You’re looking for output when something does not exist

quoll23:03:47

That’s hard to do in terms of query bindings

quoll23:03:53

It’s approximated by having statements that match the negation term, and use a NOT operation to remove them

quoll23:03:31

But you need data that exists to subtract your terms from

quoll23:03:30

Naga has a space in it for doing non-assertion things. I just haven’t had a need to do it yet 🙂

quoll23:03:49

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).

quoll23:03:41

see in Naga: src/naga/engine.cljc line 125

rickmoynihan23:03:46

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.

quoll23:03:01

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