[om-list] Fast subset enumeration in object-relation models

[Luke Call]

Mark,

Most of my comments to this are the same as in my previous email. You
can ignore my hasty wordiness here but I don't want to stifle, just in
case something good works out between our efforts. :)

I'd just repeat that I'd hope in OM that one could build object models
on the fly, as a side-effect of "idea processing" (akin to
"word-processing"), via the OM user-interface. Thus not just recording
knowledge in an shared exponentially useful collaborative way, but in a
crude way building software applications where the object model is not
defined once and for all at the design phase, but grows and evolves with
usage. So if you have genealogy-related entities and I have other
entities for whatever I'm doing, but they have a common "ancestor"
Entity (using terms loosely; they'd perhaps both point to a common
"like-this one" "person" entity or other) with mutually usefully
modelled behaviors or properties, we collaborate in our models at that
point, and so could others.

A substrate of common tools, structures, and algorithms is used to
facilitate the higher-level stuff your recent posts have described.
While it may use Scheme (a lisp, cleaner than common lisp it seems) for
some logic processing, algorithms, etc., it would use an off-the-shelf
dbms under the hood for performance issues--I personally have no desire
to rewrite the great work of others but to build on it.

And with good abstractions in between, the two worlds (dbms &
lisp/AI-land) shouldn't collide but rather they would have to serve each
other.

Mark Butler wrote:
> Fast subset enumeration in object-relation models
> 
> ....
> Although there are other aspects of knowledge modelling that may have an 
> impact on choice of data structures, fully polymorphic object relation 
> models - those that use a class hierarchly with only one or two roots 
> (Object and/or Relation, respectively) have a serious performance 
> issue.   Traditionally if you want fast access to an attribute, you 
> store it inline.  If you move attributes out into separate objects, you 
> typically have to traverse a list for every access.  This is a bit of a 
> problem, one of the reasons why LISP hasn't taken over the world yet, 
> for example.
> ....
> A typical example is dealing with an 'object' that represents a 
> universal, or a class.  A class typically has only one or two base 
> classes, a half dozen attributes, but perhaps millions of instances.  
> Any system that needs fast access to base classes and class attributes 
> is going to fail miserably if the instance relations have to be scanned  
> to find the more fundamental  relationships.  I believe what I have 
> proposed will solve the problem nicely and have started an 
> implementation in C++ that I am going to use in my family history 
> system.  The trick of course is to encapsulate it all nicely, so that 
> the ugly details are not apparent in higher level code.

If you make the switch to java, you get faster development,
cross-platform (you code on NT, I code on linux, Tom runs & could code
if desired on whatever his department uses) and decent performance for
many things (not startup though I'm afraid), and it can be optimized
selectively as needed, which is less than you'd think. Java's
performance really isn't bad, depending on how one codes
(creating/destroying scads of objects is something to be careful about
optimizing, but there are ways. Programmer productivity seems more
important, at least for my goals.) Then we can work together. Or maybe
that will still come later on (bummer if so, but is OK for now).   :)

(Writing copy constructors adds nothing useful to my life! I think state
of the art has advanced a long way since C++ was designed. Mono is very
interesting but doesn't feel "there yet"--I don't trust MS; Miguel is
brilliant and all ...    :)

....but we also have what appears to be a really nice Scheme
implementation in SISC, that is written in Java, so they interoperate.
I'm rereading "scheme and the art of programming", again appreciating
the power of proper tail recursion, currying, procedural abstraction,
and need to get some of the other stuff like handling of continuations
as first-class data types. (You probably remember the link you forwarded
about some programmers bought out by Yahoo who were more productive than
the competition because they used lisp w/ its macros etc.) I just read
the language spec & several other things to get ready to try it
seriously first for unit test scripting then maybe for more advanced
stuff. The SISC users mailing list on sourceforge is friendly, helpful,
and very low-volume (those are some very smart folks like you).

Luke