search

noxdafox / clipspy

Python CFFI bindings for the 'C' Language Integrated Production System CLIPS
BSD 3-Clause "New" or "Revised" License
177 stars 32 forks source link

A kind request of information #49

Closed lulu-elohim closed 2 years ago

lulu-elohim commented 2 years ago

Hi Noxdafox, first of all I'd like to thank you for your amazing work in the Python wrapping of Clips functionalities. Your library is well documentated, well written and the manual is perfect. Congrats.

That said, I've to be frank: I'm an "absolute beginner" with Expert Systems (ES) or Rules Base Systems (RBS). My goal is to produce a thesis on this matter and so I started to study some implementations in Python, that's the language I've to use.

After some searches on web I put the attention on these libraries: 1) CLIPSPY (noxdafox) 2) DURABLE RULES (jruizgit) 3) BUSINESS RULES (venmo) forgetting all the others minor implementations as Rule-engine, PyKnow/Experta, Python Knowledge Engine (PyKE) and so on.

Of course, the paired CLIPS + CLIPSPY stays on other planet (NASA docet...), so I kindly ask you some information and your useful tips.

It's clear that CLIPSPY is a wrapper of the underlying C functions of CLIPS; so when we design an ES or a RBS we've to think in CLIPTONIC way, not in PYTHONIC.

Keeping in mind both are OOP, do you have some advices for using directly the Object Model written in Python to create the CLIPS CLASSES and relative inheritance hierarchy? Maybe there are something I neglected, or something you have in your to top hat. Something like this pseudocode:

CLIPSclass: str = env.CreateFromPythonObject(object)

And this also for the creation of rules, starting, somehow, from the functions of the Python object with some adorners, why not.

If there is nothing ready-to-use, I'll be happy to write some code and send to your repository, if you agree.

Thanks in advance for your kind reply, and all the best for this new year. Ciao LH

noxdafox commented 2 years ago

Hello,

sorry for the late reply.

I am not aware of any existing mapping layer between CLIPS deftemplate/defclass and Python class. Usually, data is de-serialized from other sources (files, queues/streams, HTTP handlers, ...). With this in mind, I usually prefer to map Python dict directly to CLIPS deftemplate as most of the time I deal with JSON as origin of the data.

Regarding the contribution to CLIPSPy of such logic I would rather keep this library lean. Reason for that, is we can rely on the very solid documentation CLIPS provide as Basic Programming Guide and especially Advanced Programming Guide. Anything we build on top of CLIPS C APIs we are bound to maintain.

IMHO, any wrapper on top of CLIPSPy should go as a separate project which relies on this library for the sole interfacing between the upper layer and the CLIPS engine itself. A clearer separation of concerns makes things easier to maintain.

I am myself prototyping something on that line here, The progress is being very slow nevertheless as it's a toy project and my spare time is very limited nowadays.

noxdafox commented 2 years ago

Closing this issue. Please re-open if questions are still unanswered.