Re: First meeting of our group

Hi Sandro,

Excellent background!  A question though . . .

On 12/11/18 1:08 PM, Sandro Hawke wrote:
> It has long seemed 
> like rules were a promising approach: rather than than having to code 
> around all the possible forms the input data could take, we simply write 
> the appropriate rules and let the system match them to the input data 
> whenever/however possible.  I've built a variety of systems like this, 
> and in my experience, the promise has not worked out terribly well.  
> Rules are very, very hard to debug. 

On one hand, the complexity and difficulty of working with rule systems 
has been observed by many people, for a long time.  As Jesus Barras 
commented (slides 34 & 35): "
"No one likes rules engines --> horrible to debug / performance"
https://www.slideshare.net/neo4j/graphconnect-europe-2017-debunking-some-rdf-vs-property-graph-alternative-facts-neo4j

On the other hand, we all need to munge RDF data.  At the most 
fundamental level, an inference rule is merely a procedure
that takes some RDF assertions and produces new RDF assertions (the 
entailments) -- in essence a function from RDF to RDF.  Many of us have 
been using a variety of RDF-to-RDF transformation techniques that fall 
well outside of traditional rules languages and rules engines, including 
SPARQL, ShEx and general-purpose programming languages, such as Python, 
Java and JavaScript.  I -- and I assume others -- have used these 
alternative techniques for three reasons: (a) lack of a convenient, 
standard rules engine; (b) greater expressiveness (loops, for example) 
and control; and (c) programmer/maintenance economy of using the same 
language for multiple tasks.

Because of the potentially fatal performance and complexity impact of 
rules, I think it is important to be able to carefully control exactly 
which, where and how inference rules are applied.  This I think is a 
flaw of OWL reasoners.

Also, I think it may be wise to separate forward-chaining rules from 
backward-chaining rules, except in those (rare?) cases where a single 
rule definition can easily be run either way.  The reason for this is 
that I -- as a developer -- generally know exactly when/why I want to 
apply my rules, and if I am using an "alternative" rules language such 
as SPARQL or JavaScript then the implementation would be completely 
different for forward versus backward rules.

Returning now to my question: What is your take on whether/how we could 
achieve both the simplicity of a convenient rules language and the 
control and power of a general-purpose programming language?

Actually, I guess this question is both for you and anyone else who 
wants to address it.  :)

Thanks,
David Booth

Received on Wednesday, 12 December 2018 00:32:27 UTC