I updated our external supervisor Dr. Ben Goertzel about our current progress on 25th of October.
I communicated with my group mates and completed the initial version of the SRS on 26th October. As requested from the course coordinator I uploaded that version to the Moodle on 29th October. After the project meeting with course coordinator, we thought of altering our SRS a bit, and agreed to again look into parts did in the SRS by each one of us and come up with an improved version by 1st of November. As discussed I made few small changes to the parts I had done in the SRS, and send them to Chamilka, for formatting tasks on 31st of October.
Meantime I had few chats going on with the OpenCog developers community, mainly with Dr. Joel Pitt, Jerad, and Linas, at the #opencog IRC channel, for better understanding of our requirements. Since our project idea came from Dr. Ben Goertzel, I thought to have a chat with him to get clarify few problems. I had a google chat with him on 1st of November and the points discussed were following.
Why the existing RelEx2Frame code is kind of hacky?
What if the introduction of a standard rule engine degrades the performance?
Is there a corpus that can be used for testing purposes?
For final presentation purposes is it possible to use the virtual dogs developed by OpenCog?
That discussion was really worth, and I shared the chat log in our mailing list.
I did a bit research on the generated drools rules after converting hand written rules using the Rule Converter developed by Danaja and Nisansa. To get clarified few things which I came across from those converted rules, I contacted the Drools community through their mailing list on 31st of October. There I had a discussion with a Drools developer called Wolfgang Laun and figured out few important facts that we should condider.
In Drools rule eval() function is the least efficient way of formulating a condition; none of the optimizations will work this way.
eval() cannot be used on the RHS, after 'then'. It is a wrapper for general
boolean expressions, to be used as a constraint in a Pattern.
I shared these with my group mates and did necessary modifications.
In this period I had taken up another task which is to integrate RelEx with Drools, using minimum number of dependencies needed to get Drools to work. I integrated a test class given by Drools into the successfully configured RelEx Eclipse Project Folder, and built it and find out the missing libraries (JAR files) and added them to the Java Build Path of the RelEx project. Following were the minimum JAR files needed from the Drools 'bin' folder for a successful build.
I communicated with my group mates and completed the initial version of the SRS on 26th October. As requested from the course coordinator I uploaded that version to the Moodle on 29th October. After the project meeting with course coordinator, we thought of altering our SRS a bit, and agreed to again look into parts did in the SRS by each one of us and come up with an improved version by 1st of November. As discussed I made few small changes to the parts I had done in the SRS, and send them to Chamilka, for formatting tasks on 31st of October.
Meantime I had few chats going on with the OpenCog developers community, mainly with Dr. Joel Pitt, Jerad, and Linas, at the #opencog IRC channel, for better understanding of our requirements. Since our project idea came from Dr. Ben Goertzel, I thought to have a chat with him to get clarify few problems. I had a google chat with him on 1st of November and the points discussed were following.
Why the existing RelEx2Frame code is kind of hacky?
What if the introduction of a standard rule engine degrades the performance?
Is there a corpus that can be used for testing purposes?
For final presentation purposes is it possible to use the virtual dogs developed by OpenCog?
That discussion was really worth, and I shared the chat log in our mailing list.
I did a bit research on the generated drools rules after converting hand written rules using the Rule Converter developed by Danaja and Nisansa. To get clarified few things which I came across from those converted rules, I contacted the Drools community through their mailing list on 31st of October. There I had a discussion with a Drools developer called Wolfgang Laun and figured out few important facts that we should condider.
In Drools rule eval() function is the least efficient way of formulating a condition; none of the optimizations will work this way.
eval() cannot be used on the RHS, after 'then'. It is a wrapper for general
boolean expressions, to be used as a constraint in a Pattern.
I shared these with my group mates and did necessary modifications.
In this period I had taken up another task which is to integrate RelEx with Drools, using minimum number of dependencies needed to get Drools to work. I integrated a test class given by Drools into the successfully configured RelEx Eclipse Project Folder, and built it and find out the missing libraries (JAR files) and added them to the Java Build Path of the RelEx project. Following were the minimum JAR files needed from the Drools 'bin' folder for a successful build.
- drools-core-5.1.1.jar
- drools-compiler-5.1.1.jar
- drools-api-5.1.1.jar
- lib/antlr-runtime-3.1.3.jar
- lib/ecj-3.5.1.jar
- lib/mvel2-2.0.16.jar
- lib/xstream-1.3.1.jar
