[om-list] use case #1: add new entity

[Mark Butler]

Luke Call wrote:
> 
> ******user chooses add new object option from interface
> ******interface prompts user for name; user enters
> *******system makes this into a very simple object w/ only one
> attribute: a name & saves to database

A nice interface for this has one or more worksheets and a toolbar.  You
select the create entity tool and then click on the worksheet to place it. 
You have an entity selection / filtering interface to place any entity on any
number of worksheets. The worksheets can then be used to communicate ideas to
others. Bachman Analyst (aka Cayenne Groundworks, aka Sterling ?) works this
way.  

> ********a ModelObject (they can suggest better naming!) or "mo", is the
> base class
> ********it has set(String, value) and (type??) get(String) methods,
> which define its setters and getters (like docm);

--RANT_MODE=1--
In my opinion, the excessive use of setter and getter member functions is
methodological overkill that afflicts large parts of the OO world.  If I
wanted to make all my C++ code run twice as slow, I would enforce their use
everywhere.  The database world runs quite well with no such functions at
all.  

If I were on the C++/Java design committee, I would propose standardizing the
Delphi/C++ Builder property extension that allows readable "X.attribute =
value" syntax to call such functions behind the scenes.
--RANT_MODE=0--

> *********system maps that to the meta-model, saves it to the database
> *******system displays object name back to user, w/ menu
> 
> ******user can add properties & relationships in series, edit, etc

The best way to add a relationship is to use a relationship tool and click on
two entities.  However, relationships should be createable between entities
both on and off the current worksheet to avoid clutter.


> [include "add property" use case]
> 
> ******optionally, user can point to another one & say "like that one"

You need different options for "create instance of" and "create similar
entity".  An instance of a class semantically inherits all of its parent's
relationships, where a similar entity must have all of the relationships
explicitly duplicated.

> *******If I just go through the emails on this from mark & the past incl
> emstar ones) then can I tell if this approach--saving the reference to
> the object to which user pointed when said "like that one", will it
> allow for the kind of simple system we're starting out with, where the
> user can build relationship types and assign them later, but good enough
> to use for now, and will still work with all the fancy relationships we
> need in the future?

We need inheritance relationships to be easily identifiable, I suggest a
dotted line with an arrow head overlapping the mid point of the line pointing
in the direction of the parent class.  It would be good to have a tag to
visually mark whether any given entity is inherently singular or plural, i.e.
whether the entity is a class of one or more objects or a singular object.

Please note that a "list" or a "collection" is a noun distinguishable from its
contents, where a "set" or a "class" generally is not.

> Multiple inheritance as you've described above makes sense to me. But as
> to the meta-internodes and queries, detailed examples in layman's terms
> would help--describing specific entities, relationships,and
> how a search would traverse them. Maybe a handful of dissimilar examples
> would be best. This would communicate it not only to
> me, but would make use case fodder for us to build on.

Fido is a dog.
A dog is a mammal.
A mammal is an animal.
A animal is a living being.
Living beings exist.

Fido is a pet.
A pet is a dependent.
A dependent is a living being.

Fido is a hero.
A hero is a living being.

Fido is a fictional being.
Fictional beings do not exist.



> *******then system displays properties from that "like-this" parent as
> available, with prev values as defaults. Do operations use those prev
> (default) values from the "like this"-parent, when not overridden,
> instead of copying them? Yes, for now.

If a similar (sibling) entity, the program *must* copy them because there is
no alternative, if an instance entity, the program *should not* copy them
until information is entered that further constrains an inherited
relationship.

> In next msg, Tom said
> "About multiple inheritance, fuzzy set theory makes this work better,
> and more correctly models natural language sets."

Granted.  However, where used, fuzziness introduces serious computational
efficiency issues.  We need to distinguish between degree of set membership
and  degree of belief.

> *******user edits those as desired
> *******system saves the fact that user pointed to another object for
> this--in case it is useful for a query later on.

The only way to do that is to create an explicit similarity relationship,
which tends to be inefficient.  Normal query processing is always done top
down from parent classes to instances, because that is the way we think. If
one explicitly makes a similar entity, it ends up belonging to the same parent
classes, so we can find it with the first strategy before resorting to the
second.

If I were executing a find similarity query, that would be my first strategy,
followed by a strategy of finding similarly valued relationships to non-parent
entities.  

None of this advanced processing is going to work very well without loading
significant parts of the model into RAM, B.T.W.  Relational databases just
aren't suited for graph traversal.

- Mark