A question and a note on running LOOM with SBCL

[Robert Goldman]

The question:  Is there any way to associate meta-information with
concepts?  That is, information that is relevant to the concept qua
concept, rather than to the members of the concept?  I suspect that this
is probably addressed somewhere, but it's beyond what is in the scope of
a tutorial, and I just need a gentle nudge to send me in the right
direction in the HTML documentation, the older manual, or the release notes.

Related to this, is it appropriate to make relations and concepts be the
values of roles?  Or would it be more appropriate to use the names, and
leave the mapping to LOOM entities outside LOOM?  I had assumed the
latter, but as I look inside the implementation of LOOM, it seems like
LOOM entities are used in relations.

The comment -- I was caught without my ACL license one day, and spent a
few hours  getting LOOM partly working on SBCL.  It was a little messy,
because SBCL puts all the CLOS functions in COMMON-LISP and all the MOP
functions in SB-MOP, and these all seem to be in CLOS:: in LOOM.  I
*think* I have that resolved.  LOOM seems to expect that any CL
implementation that has CLOS will have :clos on the *features*, but SBCL
is so firmly ANSI that it doesn't even consider the possibility of NOT
having CLOS.  I just stuffed :clos on the *features* for SBCL; I hope
that's appropriate.  Another issue is that SBCL is ferociously strict
about the ANSI standard, whereas ACL, at least, is very lax on allowing
CLtL1 constructs (exports at top level, etc.).  SBCL's MOP is a little
different, too.  I note, for example, that access to fields of
STANDARD-METHOD must be done functionally, and cannot be done by
SLOT-VALUE (the slots are given names that foil access).

If anyone's interested, I could probably extract a comprehensive patch
from our SVN repository.  I still have one error in loading the coda.
--
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

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

Voice: [phone]
Email:    rpgoldman@...
_______________________________________________
Loom Knowledge Representation Language Forum
loom-forum@...
Change subscription: http://mailman.isi.edu/mailman/listinfo/loom-forum

[Thomas Russ]

On Apr 8, 2008, at 7:32 PM, Robert P. Goldman wrote:
> The question:  Is there any way to associate meta-information with
> concepts?   That is, information that is relevant to the concept qua
>>
> concept, rather than to the members of the concept?

It's easy.  There are two ways to do this, but they all boil down to  
the same answer.

In Loom, everything is an instance.  Concepts and relations are  
instances themselves (this is essentially more like OWL-Full, rather  
than OWL-DL).  So you can make assertions about the concept or  
relation just by using its name.  (Note that if you create concepts  
and relations that have the same name, one of them will get an  
instance name that is different, and you will have to use that)

So, the simplest answer is to just use TELL to assert things:

   (defconcept person-concept)
   ...
   (tell (author person-concept "Fred Smith"))

This asserts an author relation value about the person-concept.

The other method, if you want to keep all of this information together  
is to use the :ANNOTATIONS keyword. Essentially you add metaconcepts  
to annotations as the concept name, and binary relations as a list of  
(relation-name relation-value).  So, in the example above:

   (defconcept person-concept
      :annotations ((author "Fred Smith")) )


>   I suspect that this
> is probably addressed somewhere, but it's beyond what is in the  
> scope of
> a tutorial, and I just need a gentle nudge to send me in the right
> direction in the HTML documentation, the older manual, or the  
> release notes.

There is an example of that on the DEFCONCEPT documentation page.

> Related to this, is it appropriate to make relations and concepts be  
> the
> values of roles?  Or would it be more appropriate to use the names,  
> and
> leave the mapping to LOOM entities outside LOOM?  I had assumed the
> latter, but as I look inside the implementation of LOOM, it seems like
> LOOM entities are used in relations.

Sure.  That is perfectly fine.  Loom is quite happy to have such meta-
relations defined.  You should just use the Loom objects because that  
will make your usage of Loom a lot simpler.

> The comment -- I was caught without my ACL license one day, and  
> spent a
> few hours  getting LOOM partly working on SBCL.  It was a little  
> messy,
> because SBCL puts all the CLOS functions in COMMON-LISP and all the  
> MOP
> functions in SB-MOP, and these all seem to be in CLOS:: in LOOM.  I
> *think* I have that resolved.  LOOM seems to expect that any CL
> implementation that has CLOS will have :clos on the *features*, but  
> SBCL
> is so firmly ANSI that it doesn't even consider the possibility of NOT
> having CLOS.  I just stuffed :clos on the *features* for SBCL; I hope
> that's appropriate.

Hmm.  In answering your previous message, I found myself trying to  
compile Loom 4.0 on my Intel Mac using SBCL and started running into  
some problems relating to packages as well.  One thing I ended up  
doing was to add CLOS as a nickname of the SB-MOP package, but I still  
need to figure out what the magic incantation is to suppress the  
package-lock warning.  Oh, wait, it looks like WITHOUT-PACKAGE-LOCKS.

I should add that to the Loom packages file.

>  Another issue is that SBCL is ferociously strict
> about the ANSI standard, whereas ACL, at least, is very lax on  
> allowing
> CLtL1 constructs (exports at top level, etc.).

Actually, a lot of Loom development was done on MCL, which was also a  
strict compiler.  Moving Loom 2.0 to it back in the early 1990s  
cleaned up a lot of the laxity in the code.

EXPORTS at top level are not really disallowed by the ANSI standard.  
That should generate just a style warning.

I think I have some ways to perhaps disable such style warnings in  
some other Lisp code.  Maybe that could be added to Loom to make it  
seem less scary.  I should at least add it to the code that calls the  
compiler during runtime, since that will also help things seem less  
scary.

>  SBCL's MOP is a little
> different, too.  I note, for example, that access to fields of
> STANDARD-METHOD must be done functionally, and cannot be done by
> SLOT-VALUE (the slots are given names that foil access).

This area is historically the trickiest part of porting Loom to new  
lisp implementations.  There is a small bit of MOP-hackery associated  
with creating CLOS classes, and a bit more relating to the run-time  
creation of methods for role access. Those tended to be a bit  
problematic, because Loom was implemented just around the time that  
this was becoming a de-facto standard, so there is a lot of  
conditional code around that aspect.  I'll have to take a look at it  
some time.

>
>
> If anyone's interested, I could probably extract a comprehensive patch
> from our SVN repository.  I still have one error in loading the coda.

I would be interested in getting that information.  With some spare  
time, I would then update the distribution on our web site.


_______________________________________________
Loom Knowledge Representation Language Forum
loom-forum@...
Change subscription: http://mailman.isi.edu/mailman/listinfo/loom-forum