[om-list] use case #1: add new entity (and enter name)

[Luke Call]

******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 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);
*********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 
[include "add property" use case]

******optionally, user can point to another one & say "like that one"
*******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 workwith all the fancy relationships we 
need in the future?
*******(consider here the dif'c in meaning between "is identical 
to/synonum for" and "is a subset of" as Mark B points out).
*******System then creates a relationship between this and the 
"like-this" parent (better name? ask the team) which will be available 
in future queries, and which is not the only one of such 
relationships--it could be used for a default class-type association 
(the explicit list type--what was it named?).
********But we have to make sure if we use multiple inheritance this 
way, that there aren't conflicts. As Mark put it: in old mail archive 
#5: "> It may be that if we have the ability to create such flexible is-a
 > relationships throughout the data set, and can easily traverse them,
 > that it meets our needs, but we need to think about the implications for
 > querying, internal coherency (right term?), and support for all the
 > other features we envision.

Definitely - there must be checks to locate inconsistencies and allow
removal
or refinement.  Attributes and relationships can be considered to be a set
of
equations in multiple variables - if you can't find simultaneous solutions
for
all attributes of an entity then one of the following applies:

1. The entity is not real
2. One or more of the attributes are not real
3. One of the relationships / constraints is false and needs to be revised.

[I am assuming here we are primarily modeling reality]"

AND:  " Multiple inheritance is extremely important - the only
ambiguity
comes when you allow sub classes to override parent classes - in the real
world I cannot be strictly considered to be both an A and a B unless A and B
have no conflicts.  if I inherit only some of the attributes of each that is
a
similarity relationship rather than an "is A" relationship, object oriented
convention notwithstanding."
AND, from Tom & Luke, in old archive msg #8: "> Also, multiple "is-a" 
internodes are desired, and necessary, I believe.
  > The way to handle this (if I know which sense you mean, by "multiple 
is-a
  > relations"), is using meta-internodes.  You define the specific type
of is-a
  > relationship, and the, for logic requiring the ability to know of all
"is-a"
  > relationships, regardless of specificity, as in a query with little
  > constraint, it would use the meta-internodes, and perform a wider
search.  F
  > or narrower searches, such as for "makes and models" of cars, it
would not
  > need the dispersing-effect of meta-internodes.

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.

As Mark pointed out earlier, there could be inconsistencies in the
multiple parents. We would need a systematic way to deal with
those--perhaps checking for them at the time multiple parent types are
related to an object, then forcing the user to reconcile or specify
which side overrides the other, before saving the data."
********Later, if the class has a rule that a change to this entity 
breaks, it prompts the user(?) if that is really what they want, then is 
no longer part of the class--whether by deleting this explicit 
relationship, or by failing the query which defines the class.
********Consider this statement, for the naming? (from old mail archives 
#5): When you give it the name "truck" you imply one of two things:


   1. This is the only truck of any kind in the world
   2. This is a member of a larger class of trucks.

In order to make the linguistic tags useful, it is important that the
correct
or proper names be so marked, because while "truck" cannot be considered a
proper name for a single instance of a truck, it is most definitely the
proper
name for an entity that identifies the set of all trucks.
*******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.
********Any attribute that is a guess or a default needs to be clearly 
marked as such so that we do not introduce logical inconsistencies.  If 
I say A.x = 5 and B is an A, then I cannot say B.x = 6 because that 
implies that B is not A. What would be mathematically correct is to say 
that A.x has a certain probability distribution centered around the 
value 5 with standard deviation 2.  Or we could just say that A.x has 
nominal / normal / default value 5, but is not constrained to be such.
*******Perhaps the implication is that any entity whose properties 
aren't all set inherits the values for those  properties that are set in 
the "type-definer" parent, such as size, mass, etc. Could be a timesaver 
for simulations or depictions where you want to guess at things when you 
lack actual measurements? And can you have multiple "is-a" 
relationships? It would be handy for some things, but again, we may want 
to review the implications as we work through this. (from 
www.onemodel.org/maillist/oldlist-volume00-4). In next msg, Tom said 
"About multiple inheritance, fuzzy set theory makes this work better, 
and more correctly models natural language sets."
*******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.
******system records who entered info & when

*****enter name
******note: any object can have 0-n names.


[end]