[om-list] synergy (was Re: Recursive Belief Contexts / Comparative schema modelling)

[Luke Call]

Mark Butler wrote:
 > Schema is probably not a very good word for what someone believes
 > another person believes, so I have decided to use the word context
 > instead,
 > ....

I think i agree; I've been thinking that context would also determine 
which vocabulary something like OM would use to choose which word 
associated with an entity becomes its "name" that is most meaningful to 
a particular use, as well as which belief system (which set of ideas 
linked, which at a lower level means which entities are linked to which 
others, and what they represent, etc) takes effect for a given simulation.


And Mark later wrote:
 > ....
> one can represent a statements like this:
> 
>    He doubts that she really said that
>    She doubts that she really said that
> 
> I plan to store everything in noun counceptual form, where objects, attributes, and relations are all concepts, relations can relate any concept, and attributes can describe any concept.  So in this case:
> 
> (1) "He"  - A person
> (2) "She" - A person
> (3) "that" :  An unspecified statement
> (4) "She said that" - A temporal relation between (2) and (3)
> (5) "He doubts that she really said that"  - An evaluative relation between (1) and (4)
> (6) "She doubts that she said that" - An evalative relation between (2) and (4) 
 > ....

I think we had an exchange about how to represent belief in OM a year or 
more ago on this list (but I'm not going to look it up right at this 
moment...). I think our ideas converge, in looking at your 1-6.  It 
would be really great if we could start now sharing a schema and code 
base that goes with it. What would you think of looking over my .01 
version .zip file on the onemodel.org web site, particularly at the 
PostgreSQLDatabase.java file, and whatever interests you in branching 
out thru the code dependencies from there, and see if there is (OR COULD 
BE!) an overlap here that we can begin to take advantage of in some way. 
(I have tweaked it a bit since that release so I'd have to post my 
latest stuff if you find opp'ty for collaboration in what's there now.)


> I have one serious problem, however - if everything is stored in a relation, the lists of which relationships a concept participates in can get very long, especially for evaluating entities.  For processing purposes, I need very fast lookup of a very small fraction of those relationships , and that cannot be done with a linear scan of thousands of relationships. 

Would an rdbms index be inadequate? I imagine that someone, somewhere, 
may have already solved this problem. Either way, when the data grows 
too much, find better algorithms for processing data underneath, but the 
code which uses the database doesn't have to change because the 
abstractions between them hide that stuff. Maybe I haven't taken time to 
digest  what you're saying well enough.

Either way, some kind of synergy between your work and and mine now or 
in the future would be absolutely excellent, and it might be worth both 
of our being flexible enough to make it happen.

('Course, as a aside, I wrote the stuff in java and will soon be also 
using Scheme or Python as well, at least for test scripting, maybe other 
things, and I don't know if that will suit you. I believe at this point 
(at least for my goals, dunno 'bout yours) that my getting something to 
work before the next ice age is infinitely more valuable than 
performance or anything like it. And as Knuth or someone says "premature 
optimization is the root of all evil.")

Thoughts? This is some hasty writing this morning, on my part, but 
you'll see where I'm headed....

Many thanks, Mark & Tom.

Luke

(ps--I'm looking at Scheme again because now that SISC is implemented in 
Java, can call Java classes & libs, and they've started doing SRFI's and 
SLIB, the lack of real-world-useful libraries that scheme had in the 
early 90's may be largely gone; also I've got past the idea that Scheme 
+ OM = using FramerD, which slowed me down because I started thinking in 
FramerD's terms instead of my own, and wasting time reading FramerD 
internals code, and that line of thinking didn't get me where I needed 
to go at the time...)