At 1:30 PM +0900 4/1/07, Clifford Heath wrote:
> The only solution is a system that enables us to completely
> hide the physical layer from the user (from the queries),
> and that's what fact-based modeling can do. The details of
> how are contained in Terry Halpin's book "Information
> Modeling and Relational Databases", and are implemented in
> at least four significant database design tools, three of
> which he designed (the other is CaseTalk, www.casetalk.com).
> The most recent is an open source plugin for Visual Studio
> called NORMA, which is available as a CTP as the "orm"
> project at <http://sourceforge.net/projects/orm/>. Talk
> about an iceberg in hell! This thing is already *way* cool.
> I'm visiting the team (which Terry leads) for two days in
> May before the Rails conference.

I'm a big fan of ORM2 (The current name for the ORM effort).
I'm not a database wonk, but I play around a lot with graph-
based data structures, and ORM2 fits my needs very well.  I
would like to mention 2.5 other technologies that I'm hoping
to tie together with ORM2, Ruby, and Rails.

  *  Conceptual Graphs (Dr. John Sowa, et al)

     Although CGs use a different notation than ORM2, both
     systems describe hypergraphs (graphs in which edges
     may have more than two endpoints: "John took the train
     to Chicago").  While ORM2 maps nicely into relational
     DBs, CG maps nicely into predicate calculus.

  *  Ruby Graph Library   (RGL; Horst Duchene)
     GRAph Theory in Ruby (GRATR; Shawn Garbett)

     The basic idea in RGL and GRATR is a mapping between
     graph nodes and objects.  This lets you, for example,
     ask a node about its neighbors, forward messages to
     them, etc.

It seems to me (SciFi alert) that it should be possible to:

  *  extend RGL/GRATR to have both nodes and edges as objects,
     such that you can ask an edge about the objects it links

  *  back the resulting graph by an ORM2-style database (this
     would let me ask cross-graph questions such as "which As
     have a B relationship with Cs").

  *  send links (predicates) to a KR system (e.g., PowerLoom)

In fact, I've been musing about how close Active Record is to
being able to support a subset of this scheme.  Consequently,
I found your posting _quite_ interesting.


One problem I see with using AR join tables for relationships
is that there seems to be a presumption that there is only a
single reason why a set of tables would be joined.  So, "Rich
drives a Camry" and "Rich owns a Camry" live in cars_people.

My working plan is to use a "type" field (ala STI) in each
join table to disambiguate these cases.  Not pretty, however.
The discussion in

http://wiki.rubyonrails.org/rails/pages/ManytoManyPolymorphicAssociations

hints at some of the difficulties with this approach.

Another problem is that (apparently) AR doesn't support join
tables with more than two columns.  Given that I need hyper-
edges, this loses badly.  So, it looks like I need some model
(e.g., acts as) code...


> The remaining problem is that the existing tools are only
> design tools, that generate database schemata and static
> data layers.

There's also the slight problem that NORMA requires Visual
Studio, C#, M$Windows, etc.

> What's needed in addition is a flexible runtime
> and query processor, written in a dynamic language, and it's
> to create such an animal that I registered the ActiveFacts
> project on RubyForge. There's no content there yet (sorry
> Christian), but if anyone who's willing to do the background
> study, they're welcome to help out. I hang out on the new
> Yahoo group "information_modeling", and need folk to discuss
> ActiveFacts with while I develop it to the point where I have
> enough on which to base collaboration.

I'd be happy to be part of the discussion.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm / cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development