[om-list] synergy

[Mark Butler]

Luke:

My current genealogy project that has to integrate with a large C++ code 
base, so I really couldn't do it in Java even if I wanted to.  However, 
it would be nice to be moving in the direction of a common data model, 
so if you would create a standalone commented description of your 
database tables, I would be glad to compare to what I am doing and offer 
suggestions for convergence.

Regrettably, most relational databases do not perform particularly well 
for graph intensive applications like family history, at least in 
client/server mode due to the high latency required for each edge 
traversal.   My current project uses an external file format, but 
someday a real transactional database will be required.  I suppose a 
relational database might work if a middle tier that aggregated several 
graph edges for a single client request was implemented.

This is an area where web services excel - Over wide area networks with 
high latency, the extra XML processing time is negligible compared to 
the enormous latency savings gained by effectively bundling a large 
number of lower level requests in one higher level one. 

We will probably need a distributed network protocol at some point (to 
implement the "One" in "One Model"), but I suggest that we start with a 
comparative data modelling discussion. 

 - Mark


Luke Call wrote:

>
> 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...)
>
>
> _______________________________________________
> om-list mailing list
> om-list at onemodel.org
> http://www.pairlist.net/mailman/listinfo/om-list
>