Hey, @lf94. Sorry for the delay in replying.
I’m not an expert in the underlying technologies, but here’s how I understand the differences between s(CASP) and pure Prolog…
First, pure Prolog is not able to answer all of the questions that s(CASP) can. Some queries that will not terminate in Prolog do terminate in s(CASP). So there is an advantage in terms of the types of encodings that will actually return an answer.
Second, Prolog gives you bindings, but s(CASP) returns minimal answer sets. The answer sets include the bindings, but also whatever other conclusions needed to be reached in order to obtain those bindings. This is similar, but not identical to a trace. Pure Prolog will give you a binding, and you can, if you want, find the trace that you used to get it. But s(CASP) returns all of the valid answer sets, which means that if there is more than one way to use the code to get to the same conclusion, you get all of them.
That’s a very important feature in legal knowledge representation, because in order to know whether or not our encoding of a law is correct, we need to know not only whether it returns the right answers, but whether it returns those answers for the right reasons, and only the right reasons.
Third, the answer set also includes a tree-structured justification for the conclusion, which is a zero-overhead addition because of the way that s(CASP) resolves the goals.
Fourth, s(CASP) is capable of explaining default negated conclusions, which requires a lot of additional work to do in pure Prolog. That makes explanations much more usable to the developer of the encoding and the end user. It also lets you default negate your tests to get an explanation for why they aren’t working.
Fifth, and perhaps most importantly, s(CASP) has built in support for hypothetical reasoning, allowing you to create alternate universes and search for solutions in all of them. That, plus the minimal answer sets, means that you can use it to do all sorts of powerful things like process planning to achieve goals, powering expert systems by telling the front end what additional hypothetical facts would be relevant to the goal, finding loopholes in legislation without needing to provide facts, and much much more.
Sixth, and I’m a little fuzzy on the details here, s(CASP) is an answer set programming language implemented inside Prolog. There are others that do the same thing, but those others can’t deal with contradictions. If there is a contradiction anywhere in the code, no answer sets are returned. That’s considered a good thing for people who are trying to model a system in order to determine if it is consistent. But in legislative drafting, we may be in a situation where what we want is information about what is causing the inconsistency. You can’t get that from most other answer set programming approaches, they just fail to return anything at all. In rules as code we may also be in a situation where the law we encoded is inconsistent with regard to some things, but those inconsistencies don’t apply to everything. In that case, s(CASP), because it is goal oriented, can use an internally inconsistent ruleset to provide answers and reasons for things where the inconsistency isn’t relevant. That means we can use it to more faithfully encode bad laws, and the encodings will still be useful.
Seventh, s(CASP) has built-in support for constraints over reals (I think it’s “reals”?), which allows for constraint logic programming over infinite domains. That lets you do things like event calculus without needing to specify steps, start, and end “times”.
Eighth, s(CASP) unlike many answer set programming techniques, s(CASP) calculates answer sets without a grounding step. For complicated rulesets, that can result in a significant increase in speed over other answer set programming approaches.
If you just want bindings, and you want them fast, pure Prolog is the better option.
Honestly, of these, the only one I was aware of before I started using s(CASP) in late 2020 was justifications. The rest has been a pleasant surprise. I had been working in Flora-2, mostly, for several years. I will not go back. With s(CASP) I get way more help from the reasoner when doing the encoding, and the resulting encoding is capable of doing way more things. Even if all I needed was bindings, and fast, I would write the code in s(CASP) first, to make sure it was right, and then I would re-implement the code in Prolog.
Almost anything that you can do in Prolog you can also do in s(CASP), with exception of things like IO. So if you have need for things like probabilistic graphs, it’s probably capable of them. The answer set approach may be inefficient, though, I don’t know. That said, I don’t find a lot of use-cases for probabilistic logic in Rules as Code. There are other places in legal tech where it’s helpful, like in calculating the loss of income from a tort injury, microsimulation, or case-based reasoning, but those are sort of far-off future problems for me, right now.
Thanks for the great question, let me know if that helps.
