MongoDB rule engine?

2,548 views
Skip to first unread message

Garry

unread,
Jan 6, 2012, 1:36:36 PM1/6/12
to mongodb-user
Hi,

I'm interested in using MongoDB as the "working memory" of a rule
engine, say Drools or Prolog.
Has anyone attempted such an integration of MongoDB with a rule
engine? Any thoughts about the
general approach?

Thanks, Garry

Chris Westin

unread,
Jan 6, 2012, 2:14:03 PM1/6/12
to mongodb-user
Caveat: it's been about 30 years since I wrote any prolog, so my
knowledge of what you can do with prolog engines today may be out of
date.

My recollection is that you do two things in prolog: you specify a
bunch of facts, which amount to a number of tuples. Then you can ask
the engine if propositions are satisfied by those facts. In very
simple terms, it does a sort of search across the facts -- if the
facts are kept internally as a tree, it might amount to doing some
kind of recursive backtracking algorithm to find facts that support
the proposition.

Can you be more specific about what you mean by "working memory?" Do
you mean to store the facts? Are there prolog engines that support
external persistent fact storage these days? When I saw these, you
put all your facts in a file that had to be loaded before you could
make propositions.

Or, by "working memory," do you mean the memory used during the
execution of the "search" for facts that support the proposition?

I don't know of anything offhand, so I did a Google search, and found
this thread on this group: http://groups.google.com/group/mongodb-user/browse_thread/thread/7f045cfff353f39e
. I'd suggest contacting the OP there about their driver and how it
is used.

Chris

Garry

unread,
Jan 6, 2012, 2:30:25 PM1/6/12
to mongodb-user
Hi Chris,

Thanks for your response. We're writing "event" documents into
MongoDB and these are
essentially the facts on which we want rules to execute. So I do mean
"fact memory" and
not "rule memory." For Drools, I did find a discussion about
accessing facts in an
RDBMS via Hibernate so that product has, apparently, externalized fact
access. At this
early stage, I'm interested in canvassing what you and others have
done or think about
the idea.

Garry


On Jan 6, 2:14 pm, Chris Westin <cwes...@yahoo.com> wrote:
> Caveat:  it's been about 30 years since I wrote any prolog, so my
> knowledge of what you can do with prolog engines today may be out of
> date.
>
> My recollection is that you do two things in prolog:  you specify a
> bunch of facts, which amount to a number of tuples.  Then you can ask
> the engine if  propositions are satisfied by those facts.  In very
> simple terms, it does a sort of search across the facts -- if the
> facts are kept internally as a tree, it might amount to doing some
> kind of recursive backtracking algorithm to find facts that support
> the proposition.
>
> Can you be more specific about what you mean by "working memory?"  Do
> you mean to store the facts?  Are there prolog engines that support
> external persistent fact storage these days?  When I saw these, you
> put all your facts in a file that had to be loaded before you could
> make propositions.
>
> Or, by "working memory," do you mean the memory used during the
> execution of the "search" for facts that support the proposition?
>
> I don't know of anything offhand, so I did a Google search, and found
> this thread on this group:  http://groups.google.com/group/mongodb-user/browse_thread/thread/7f04...

Chris Westin

unread,
Jan 6, 2012, 4:37:12 PM1/6/12
to mongodb-user
While I haven't done anything with this, I can certainly imagine that
having persistent fact memory would be useful for managing large
numbers of facts without having to reload the environment every time
you want to do a query. (Back then, when all we had was VT220's
(that's a character mode serial terminal), and large numbers of facts
weren't at the top of the list of concerns.) I would recommend
contacting the poster in the thread I linked to above and asking them
about the MongoDB prolog driver they discussed.

Chris

Timothy Hawkins

unread,
Jan 6, 2012, 8:16:03 PM1/6/12
to mongod...@googlegroups.com, mongodb-user
This may be relevant, we have been looking at using mongo to store the downloadable freebase
Database. In the end I just used mongo to cache the queries to the online interface. But we looked hard at mongo as an rdf store, for storing facts and relationships. And are still doing
Some experimentation in that area.

http://www.dotnetrdf.org/blogitem.asp?blogID=35

Sent from my iPad

Timothy Hawkins

unread,
Jan 6, 2012, 8:28:10 PM1/6/12
to mongod...@googlegroups.com, mongod...@googlegroups.com
Should add, the link below, is not to our work, it's just to an example of work that other groups
have done in the area of mongo based rdf stores

Sent from my iPad

Garry

unread,
Jan 9, 2012, 4:16:40 PM1/9/12
to mongodb-user
Thanks, Tim, for the URL - very interesting and timely as we are
considering, in fact, using an RDF representation for our facts.



On Jan 6, 8:28 pm, Timothy Hawkins <tim.hawk...@mac.com> wrote:
> Should add, the link below, is not to our work, it's just to an example of  work that other groups
> have done in the area of mongo based rdf stores
>
> Sent from my iPad
>
> On 7 Jan 2012, at 09:16, Timothy Hawkins <tim.hawk...@mac.com> wrote:
>
> > This may be relevant, we have been looking at using mongo to store the downloadable freebase
> > Database. In the end I just used mongo to cache the queries to the online interface. But we looked hard at mongo as an rdf store, for storing facts and relationships. And are still doing
> > Some experimentation in that area.
>
> >http://www.dotnetrdf.org/blogitem.asp?blogID=35
>
> > Sent from my iPad
>

Muruganantham Mani

unread,
Aug 14, 2013, 10:51:17 AM8/14/13
to mongod...@googlegroups.com
Gary,
You can check out this mongodb rules engine.  It also supports any RDBMS mapping.


Regards.
Reply all
Reply to author
Forward
0 new messages