core.logic: Dividing the knowledge base

[JvJ]

I'm creating something with core.logic that involves multiple "agents"(not the same as a clojure agent!) which each have distinct knowledge.  I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually.

The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient.  Is this a good approach, or is there something better I can do?

Thanks

[David Nolen]

Sounds like an interesting idea though I can't give much guidance about how to approach it. Curious to know how it goes though!

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[JvJ]

Thanks for the quick reply.  I guess I'll go through with my initial plan and see what happens.  Thanks.

[JvJ]

Actually, I have a quick question.  How could I modify the following code to add some metadata to he newly defined relation?

(defmacro defkrel

  "Macro for defining knowledge-based relations."

  [nme & rest]

  `(defrel ~nme

     ~'agent

     ~@rest))

[David Nolen]

Hrm, how are you going to consume that metadata?

[JvJ]

Actually, I figured it out.  I just didn't realize you had to do the #' thing to get the meta from a function.

But!  I'm basically going to write a variation of run* that binds an agent to the first argument of any "knowledge-based" relations.  So, if they have something like {:knowledge true} in their metadata, the first argument is replaced with the agent.

[Norman Richards]

On Wed, Feb 27, 2013 at 2:50 PM, JvJ <kfjwh...@gmail.com> wrote:

I'm creating something with core.logic that involves multiple "agents"(not the same as a clojure agent!) which each have distinct knowledge.  I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually.

The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient.  Is this a good approach, or is there something better I can do?

 

Threatgrid had the problem of wanting to have distinct datasets over the same relations.  Our solutions was to declare facts in to a persistent logic db and refer them explicitly when performing queries.  I've released part of that work here:

https://github.com/threatgrid/pldb 

There's a branch with indexing support on my fork, and I have a few other enhancements queued up.  We use this code on some very large datasets and it is working well for us. 

[David Nolen]

I'm also enthusiastic about eventually replacing the current core.logic defrel/fact stuff with this excellent work.

David

[JvJ]

Wow.  Thanks, this will probably help a lot!

[JvJ]

It states that retractions aren't yet implemented.  Is there any way to delete facts?

On Wednesday, 27 February 2013 16:45:07 UTC-5, Norman Richards wrote:

[Norman Richards]

On Wed, Feb 27, 2013 at 4:03 PM, JvJ <kfjwh...@gmail.com> wrote:

It states that retractions aren't yet implemented.  Is there any way to delete facts?

This is something I want to add, and if it's something you could use now, I'll bump up priority of getting that in.   What we do is just build a new logic db for each runs with different facts, which is why it hasn't been implemented yet.

[JvJ]

If it's not too much trouble, it's something I'd like to see, but I'm sure I can find a way around it somehow.

[JvJ]

One more thing I'd like to ask.  Is it possible to combine the databases in a way?

For instance, I'd like to have a universal database that every agent can access, as well as agent-specific databases.  I understand that databases can be modified in a purely functional way (which is great), but I'm wondering if there's a way for changes in the universal database to be reflected in the others.

[Norman Richards]

On Wed, Feb 27, 2013 at 4:32 PM, JvJ <kfjwh...@gmail.com> wrote:

One more thing I'd like to ask.  Is it possible to combine the databases in a way?

For instance, I'd like to have a universal database that every agent can access, as well as agent-specific databases.  I understand that databases can be modified in a purely functional way (which is great), but I'm wondering if there's a way for changes in the universal database to be reflected in the others.

 

I think it should be possible to support relations over multiple logic databases.  I'm going to add that to the feature list.  I will try to get a new release out this weekend.  

[Norman Richards]

On Wed, Feb 27, 2013 at 4:03 PM, JvJ <kfjwh...@gmail.com> wrote:

It states that retractions aren't yet implemented.  Is there any way to delete facts?

Retractions are now supported.  DB merging and cross-DB logic queries are still coming.  Feel free to comment on the github issues if you have specific use cases in mind you would like to see this support.  I have some specific ideas for things we want to do with this at Threatgrid, but that's only one use case.

[JvJ]

Thanks so much!  I'll check it out tomorrow!

[JvJ]

I'm not sure how else to go about contacting you about this, but I've found some problems in pldb.  The system just doesn't seem to work at all with the core.logic 0.8.0 builds.  I'm not too familiar with the guts of pldb or core.logic, but I'm wondering if maybe some implementation changes lead to this?

On Monday, 4 March 2013 10:51:48 UTC-5, Norman Richards wrote:

[David Nolen]

That's likely though pldb is so small I don't really think it would require much in the way of changes.

--

[Craig Brozefsky]

JvJ <kfjwh...@gmail.com> writes:

> I'm not sure how else to go about contacting you about this, but I've
> found some problems in pldb. The system just doesn't seem to work at
> all with the core.logic 0.8.0 builds. I'm not too familiar with the
> guts of pldb or core.logic, but I'm wondering if maybe some
> implementation changes lead to this?

You could use the Issues system in github for reporting this to pldb's
maintainers. Details of what "not works at all" looks like would help
them too.

--
Craig Brozefsky <cr...@red-bean.com>
Premature reification is the root of all evil

[Norman Richards]

On Mar 14, 2013, at 4:15 PM, JvJ <kfjwh...@gmail.com> wrote:

> I'm not sure how else to go about contacting you about this, but I've found some problems in pldb. The system just doesn't seem to work at all with the core.logic 0.8.0 builds. I'm not too familiar with the guts of pldb or core.logic, but I'm wondering if maybe some implementation changes lead to this?

PLDB was written against the current core.logic release. I have not yet started testing with the 0.8 pre releases, but judging from the recent core.logic announcement, now is probably a good time to start. :)

You can report issues on the github project page. Also, feel free to grab me on the clojure IRC channel at any time.

[David Nolen]

On Thu, Mar 14, 2013 at 7:18 PM, Norman Richards <o...@nostacktrace.com> wrote:

PLDB was written against the current core.logic release.  I have not yet started testing with the 0.8 pre releases, but judging from the recent core.logic announcement, now is probably a good time to start. :)

Please do. I'll probably just go ahead release 0.8.0 over the weekend. If you find issues please file tickets and we'll get things cleaned up for 0.8.1 shortly.

Thanks,

David