contexts in LOOM

View: New views
2 Messages — Rating Filter:   Alert me  

contexts in LOOM

by Robert Goldman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I was wondering if anyone could enlighten me about how to use concepts
in LOOM.

Here is what I would like to do (I think):

I would like to create a KB that contains a stable TBox.  I can do this
with DEFKB, I believe.

I have some concepts I *may* want to add to the TBox, *if* they satisfy
some tests, which have to do with whether or not appropriate subsuming
classes exist.  I was considering this doing the following procedure:

1.  Create a new context
2.  Add my new concept temporarily to this new context
3.  Conduct some queries to see whether the new concept should
permanently be added.
4.  Destroy the context
5.  If the queries were successful, add the new concept to the KB.

I have looked over the documentation on concepts in the LOOM 3.0 release
notes, and I believe that I can create the temporary context using

(define-context <gensym> <type-of-context> <parent-contexts>
:creation-policy :classified-instance)

It's the arguments I am having difficulty with.  In particular:

1.  What's the difference between the different context types?  I get
the sense that :theory is heavyweight and not for my purpose here, but
don't have the foggiest idea whether :workspace, :island, or :world is
most appropriate, although :workspace seems suggestive.

2.  What should I choose as the parent-context?  Should I be making a
context as well as a KB when I call defkb?  Should I somehow be
establishing a default context for my KB?  If I don't establish a
default context, what should the parent-contexts be?  NIL?

There is some code in use-loom that seems suggestive in this regard, but
I don't fully comprehend it, and I can't really invoke use-loom in my
application -- the wide-ranging package surgery it does is really not
appropriate for me.

3.  Does the :creation-policy matter to me at all?  I ask because I am
only going to be working with concepts in the TBox in this temporary
context.  Does :classified-instance affect concepts, or only instances?
 If instances only, then I assume :creation-policy is a don't-care for me...

Thank you very much for any advice!

P.S. feel free to ignore me for not using PowerLoom, if you so wish, but
the decision to use Loom rather than PowerLoom was *not* made based on
ignorance of the latter's existence.  I need to rapidly prototype an
inference capability to be tightly integrated into a Common Lisp
application, and PowerLoom's use of Stella makes this prohibitively
difficult.
_______________________________________________
Loom Knowledge Representation Language Forum
loom-forum@...
Change subscription: http://mailman.isi.edu/mailman/listinfo/loom-forum

Parent Message unknown Re: contexts in LOOM

by Robert Goldman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thank you very much for your so-helpful answers.  For specific points
below, I have added some remarks.

Thomas Russ wrote:

>
> On Apr 1, 2008, at 4:14 PM, Robert P. Goldman wrote:
>> I was wondering if anyone could enlighten me about how to use concepts
>> in LOOM.
>>
>> Here is what I would like to do (I think):
>>
>> I would like to create a KB that contains a stable TBox.  I can do this
>> with DEFKB, I believe.
>
> Yes.  Although in the later versions we switched to prefering DEFCONTEXT
> instead.  When we revamped the context system for version 3.0, we kept
> the older DEFKB for backwards compatibility.  We don't really use it
> anymore.

Does that mean that I should just drop the defkb altogether and simply
create an initial context that contains the stable TBox?

If I do this, when I call DEFINE-CONTEXT the first time, what should be
the parentcontexts?  Would it be safest to do

(define-context 'my-context :theory (list (current-context)))
?

Your instructions about creating child contexts were quite clear; it's
only the basis case about which I still have questions.
>
> I should note that some of the documentation is rather dated, so you
> should make sure you read the release notes for both versions 3 and 4,
> since that describes the newer features.  [Edit:  I see below that
> you've done that.  Good.]

I am, in a desultory way, editing the HTML files when I find something
out-of-date.  If you are at all interested in the results, I would be
happy to tar them up and send them to you.

[..snip...]

>>
>> P.S. feel free to ignore me for not using PowerLoom, if you so wish, but
>> the decision to use Loom rather than PowerLoom was *not* made based on
>> ignorance of the latter's existence.
>
> I would never do that.  They are, in fact, different tools and have
> different strengths and weaknesses.  If you are looking for a
> classification-based KR language, I don't think you can beat Loom.
> Although I am a bit biased, I much prefer Loom to OWL.  The only
> significant drawback to Loom for most users is the need to use Common
> Lisp, which is not a barrier for you.

Rather the contrary, thanks!

>
>>  I need to rapidly prototype an
>> inference capability to be tightly integrated into a Common Lisp
>> application, and PowerLoom's use of Stella makes this prohibitively
>> difficult.
>
> If you have some time, I would like to hear what about the Stella
> connection makes this so difficult.  Normally for most of our code
> prototyping, I just type PowerLoom expressions at the lisp command
> line.  There are a few gotchas relating mostly to keyword and symbol
> arguments that I'm aware of, but I would be curious to know what makes
> it hard to integrate.

In a past project I had tried to use PowerLoom, but the embedding was
quite difficult, because there was a difficult boundary when invoking
PowerLoom functions and, even more when unpacking their results.  I had
particular problems when I was getting sets of things back from
PowerLoom, and had to traverse them to pull information out and import
it into Common Lisp.  In particular, I found it difficult to use the
structure accessors, and the iterators.  I'm a little bit hazy on the
details, but I recall it being difficulty to, for example, have a stella
iterator that would extract information for the benefit of CL code.

Possibly this was partly due to what makes PowerLoom work for you!  As
you say, it's very easy to interact with PowerLoom through the Loop
REPL.  Unfortunately for the person wishing to use PowerLoom *with* CL,
this is done by tailoring the behavior of the REPL.  So, for example, my
use of describe and the inspector to root around inside the stella
objects to figure out how to pull out information was complicated.

If I recall correctly, there was also some difficulty in using the
emacs-lisp interface in a mixed Stella + Common Lisp environment.  It's
been some time now, but it's possible that the standard meta-. type
facilities behaved oddly....
>
> This isn't meant to be pushing you to use PowerLoom, necessarily.  There
> are things where Loom is a better tool to use.

I think that is my case, at any rate, since I really want something like
a DL solution here.  I am using LOOM to give some DL-like services to a
conventional planner, so I don't need as total a solution as PowerLoom.

Thanks again,
Robert


--
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

211 N. First St., Suite 300
Minneapolis, MN 55401

Voice: (612) 384-3454
Email:    rpgoldman@...
_______________________________________________
Loom Knowledge Representation Language Forum
loom-forum@...
Change subscription: http://mailman.isi.edu/mailman/listinfo/loom-forum