I would like to incorporate Pyke into a web application and am particularly interested in question bases. I'd obviously need to implement my own ask module, but it appears that the ask modules are expected to be a synchronous interface.
A web app would require an asynchronous interface like:
1) Ask Pyke to prove a goal.
2) Pyke engine returns question to ask, leaving goal hanging.
3) Store the pyke engine in the web session and render question as an Http Response (web page)
4) Receive answer in Http Request
5) Pass answer back into Pyke (i.e. the Pyke engine associated with the web session).
6) Pyke proves goal, or returns another question (back to step 2)
I'm using Django, but any web app framework would require a similar approach.
Are there hooks in Pyke to facilitate this sort of approach? Has anybody else tried anything similar? Or would I need to start hacking deep into Pyke?
OK, I've thought a bit more about this, I think I need to write an ask module that:
1) stores the current question in the web session and can read an answer from the web session.
2) throws an exception if asked a question whose answer is not in the web session, and
3) provides additional interfaces to allow the web framework to validate answers and obtain review messages and error messages.
Involves lots of jumping up and down the callstack and lots of pickling things to and from the web session, but I think it should be a viable approach. Any comments?
Gee - quiet community around here.
I hit a minor stumbling block - in that if you implement the ask_module as a python module there is no way for it to know about the web session (unless you construct it dynamically each request).
However, looking at the Pyke code, I'm pretty sure everything will work the same if you implement the ask_*() functions as methods in a class instead of functions in a module, and set the engine ask_module to a class instance instead of a module. Then you can pass in any relevant information via the class instance.
Personally I think this is a better design anyway, as it lets you pass in session-specific options to the ask_module. (e.g. could pass in window display options to task_wx)
I'll let you know if the approach works (assuming there's anyone out there reading this).
Sorry for the delay…
Yes, you should be able to abort the proof when an unanswered question is encountered and store answers in the web session and then replay them in subsequent requests. This causes the initial inferencing to be repeated, but should lead to the same results.
On the ask_module being class based, I don't think that the code really cares whether it's a module or an object. It's all just how you want to implement it.
FWIW, I'm assisting in the use of Pyke for building a medical expert system (naimath.com) and what we're doing there with questions is to present the user with all of the questions that could come up, sorted by a relevance score. The user then chooses which one(s) to answer; and the cycle is repeated. In this case, rather than aborting the inferencing when each new question is encountered, the whole inferencing process is completed and a list of unanswered questions collected to be presented to the user. Then, when new answers are provided, the whole process is repeated again. This also lets the user change prior answers, as these are feed to the proof process each time. To my mind, this whole process only makes sense with the uncertain reasoning inherent in medical expert systems; because the user will want to see all diagnosis possibilities anyway (again, sorted by certainty factor), which will require answering all of the questions. (Actually not _all_ of the questions, as the user also chooses when to quit when the diagnosis CF is high enough).
Finally, in this case, we chose to implement the questions as simple fact lists and have implemented a tool to scrape the question and answer possibilities from the .krb files and feed them to the gettext translation facility for I18N.
If you come up with any question/answer enhancements, I would be happy to accept patches for inclusion into Pyke.
Your approach is interesting, but of limited use to me - I'm interested in presenting the user as few questions as possible. :)
The lack of a web-friendly approach to "ask" is IMO a big obstacle to using PyKE. I did some work with PyKE a year or so ago and this definitely was a major reason I didn't continue.
@Bruce: I think it would be great if you could package up your approach, even if you're not ready to include it in PyKE proper.
@Paul: I'm generally also interested in as few questions, but can also see needs for the approach Bruce's app is taking. I would be interested in seeing if we can't think up a way to make ask() work in a unified way for all of these.
I can see a need for the following:
1. Ability for ask() to queue a series of questions with some priority (either importance or logical order). This is not something limited to the web version.
2. Ability to render these questions (anywhere from 1 to N of them, depending on need)
3. Some thinking in general about how PyKE-for-web apps are architected (e.g., one PyKE instance or multiple, how sessions handled)
Probably the first step is to define some clear use cases.
(P.S. After I wrote the above, I just saw Paul's new posting: https://sourceforge.net/projects/pyke/forums/forum/744446/topic/3945480
which provides more thoughts on this matter. Perhaps we can set up a single wiki page to continue this brainstorming…don't know if SF offers that.)
I agree the ability to batch up questions would be very cool. I did think about that possibility, but for the specific applications I've looked at so far which questions to ask depends so heavily on the answers to previous questions that simply asking one question at a time is pretty close to optimal anyway.
I suspect it would take someone with a tighter intuitive grasp of logic and list based programming than myself to pull off. This is my first exposure to this way of thinking since University in the early 90s and it's been taking some getting used to!
There is a Pyke wiki at https://sourceforge.net/apps/trac/pyke/ so probably best to move any further brainstorming over there.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.