Clojurians Log v2

@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

https://en.wikipedia.org/wiki/Negation_as_failure

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