Rule limitation explanations


(zachary.whitley) #1

I've been meaning to ask this question for a while but haven't. Probably because I still have a hard time even expressing what exactly the problem is so I hope you'll forgive me if this is a bit incoherent. The fundamental problem is I don't quite understand the rule limitation listed in the documentation under section Rule Limitations and Gotchas. I'm not completely lost and I guess that's the problem. I get it but I only ever feel like I get it 70% and find myself going back and re-reading that section.

I hope that other people might share my confusion and benefit from additional clarifications. One reason that I'd really like to understand this section is there is an unfortunate contrast to the simplicity of rules, if this then that, and the complexity of this exception. I'd like to understand it well enough that I could explain it to someone else. I don't want to introduce someone to rules only to have them inevitably write one that isn't valid and then not be able to explain why. I feel like if I introduce them to the simplicity of the rules but warn them of the complexity it would go a long way to managing their expectations when using them.

I think what I'm finding confusing about the documentation is there seem to be a couple of notions of "cycle" but it's not clear which one is being referred to in the documentation. I keep finding myself reading, "....cycles are not allowed...." and thinking, "Which cycles? In the body? head? Cycles within a single rule or is that a universal restriction across all rules?".


(stephen) #2

The cycle rule essentially boils down to your rules needing to be rewritable as SPARQL property paths when used in queries. It is a universal restriction across all rules, as clarified by the 2 rules in the These rules are not acceptable since there is a cycle section of the docs.

Rule 3 is a list of clauses that can't be rewritten. Probably EXISTS and NOT EXISTS are the ones that people most try to use in rules that trips them up (myself included. I often forget). It also mentions that rdf:type can only have a constant object, which is good practice in general with reasoning, as variable types tend to gum everything up.