[om-list] Re: Data models

[Mark Butler]

I agree completely that we should avoid fixed data models in the 
traditional sense.  However we do need a common ground level data model 
(or meta-model)  or we have little hope for exchanging models between 
systems.  We have discussed meta models in the past, but I for one am 
much more prepared to have a coherent discussion these days, based on 
what I have learned over the past few years.

My current family history data model is very generic - it has Concepts, 
Attributes, Relations, and Evaluations, where the latter three are 
sub-classes of the first.  I still create sub classes to bind code to 
various types of objects, but the data itself is stored at a very high 
level rather than in hard coded sub class specific fields.  This turned 
out to be very important for several critical algorithms I am developing 
- the one for intelligent model merging being the foremost.

At some point I would like to write an interpreted language that works 
against the object model at a much higher level than can be achieved in 
either Java or C++.  Declarative and procedural aspects could easily be 
implemented as part of the same language.

- Mark


Luke Call wrote:

> 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.
>