RE: First meeting of our group

Proofs  will also certainly help for debugging but they rather help in cases where unexpected derivations happen. 

                +1! 

When I expect a result which I then do not get, there is also no proof to check what happened (no proof for something which is not true).

                Why not? .. (aside from technical considerations)

 

W

 

From: Doerthe Arndt <doerthe.arndt@ugent.be> 
Sent: December-12-18 11:09 AM
To: public-n3-dev@w3.org
Subject: Re: First meeting of our group

 

Dear Sandro, all,






My own interest is in making it practical (even fun and easy) to base real applications on open-world data (that is, RDF or other KR data), so that we end up with a full data-sharing ecosystem. 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.  Hopefully things will improve some day.

I am used to Prolog and wonder whether the simple debugging predicates and modes of for example SWI-Prolog could help here.  

The problem with debugging in Prolog (and I guess in any other rule language as well) is that it depends on the reasoning algorithm. In Prolog this is resolution with the left-most selection rule. Since we know that, we can also easily (ok, debatable, but I think it is easy) see where reasoning got stuck in case of problems. But I do not think that we should completely fix the reasoning mechanism we expect for N3 (for example we could be flexible with a selection rule and hope for different approaches) and concentrate on the logic instead.

Proofs  will also certainly help for debugging but they rather help in cases where unexpected derivations happen. When I expect a result which I then do not get, there is also no proof to check what happened (no proof for something which is not true).

 
N3, as implemented in cwm, was an attempt to attack the problem by one person (with some advice from a few others -- I don't mean to minimized DanC's role, but I think he'd agree the vision was Tim's) who had no experience with existing rule-based system or familiarity with the literature, so the design ended up rather idiosyncratic. At the other end of the spectrum, RIF was an attempt to attack this problem by a committee which included experts in many different kinds of rule-based systems, so it ended up rather complicated and full of options.  I joined Tim's group a few weeks after cwm started, in late 2000 and was staff contact for RIF from chartering <https://www.w3.org/2005/rules/wg/charter>  through Recommendation <https://www.w3.org/TR/rif-overview/> . I might be the only person involved in both projects.

I'd love to see something simple and elegant enough it actually catches on. I highly doubt that will be classic N3, in all its self-referential glory (the "implies" operator is just an RDF predicate!), or RIF, in all its complexity.

I agree with both points and hope to find a practical solution here. I also think that we should consider the work already done in the past on N3 and RIF, so I am glad that you share your experience.

If this group just wants to nail down N3, more or less as implemented in cwm (and perhaps EYE), then more power to it, I wish it well.  I'll try to follow the progress from time to time.

On the other hand, I rather hope it ends up evolving into a language which really fits the needs of application developers. That would be awesome.

I also think that this should be the goal of the group should be to find a practical rule language which fits the needs of developers. Nevertheless, I also think that we should not be too ambitious either to be sure to not deviate from our goal of specifying a standard. So, maybe we start with N3 as it is and "fix" what according to the experience of the people in this group needs to be present in a rule language?

I hope that you can help us here with all the lessons learned from the two other groups.

 





 

* Together with the formalisation we should also discuss whether we provide a reference implementation together


In general, in standards work, reference implementations are not a great idea. It's much better, if possible, to have multiple independent implementations and a shared test suite.  Every substantive decision by the group -- that is, a decision that might affect whether some implementation conforms to the spec -- as well as every normative statement in the spec should be recorded as multiple tests added to the test suite, showing the correct way for reasoners to behave.  For a rule language, positive-entailment and negative-entailment tests are most of what you probably want.  Of course there are also positive-syntax and negative-syntax tests.  See, for example, https://www.w3.org/TR/rif-test/



Thank you for your advice. So, let's simply drop the point of  a joint reference implementation then and write some test cases instead.

Regards,
Doerthe

-- 
Dörthe Arndt
Researcher Semantic Web
imec - Ghent University - IDLab | Faculty of Engineering and Architecture | Department of Electronics and Information Systems
Technologiepark-Zwijnaarde 19, 9052 Ghent, Belgium
t: +32 9 331 49 59 | e: doerthe.arndt@ugent.be <mailto:doerthe.arndt@ugent.be>