From - Tue Feb 20 18:08:22 2001
X-UIDL: 91f8418e664b2d55
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <general-digest-list-request@onemodel.org>
Delivered-To: lacall-onemodel:org-lacall@onemodel.org
X-Envelope-To: lacall@onemodel.org
Received: (qmail 70314 invoked by uid 800); 20 Feb 2001 14:11:04 -0000
Date: 20 Feb 2001 14:11:04 -0000
Message-ID: <20010220141104.70313.qmail@uruz.pair.com>
To: lacall@onemodel.org
References: <3A927AE2.4010408@onemodel.org>
In-Reply-To: <3A927AE2.4010408@onemodel.org>
X-Loop: general-digest-list@onemodel.org
From: general-digest-list-request@onemodel.org
Reply-To: Please.write.a.new.mail.instead.of.replying@FIRST.WORD.archive
Content-ID: <"volume00/12"%general-digest-list-request@onemodel.org>
Subject: archive retrieval: volume00/12
Precedence: bulk
Content-Disposition: inline; filename="volume00/12"
Content-Type: message/rfc822;
	directory="volume00"; name="12"
MIME-Version: 1.0

From: general-digest-list-request@onemodel.org
Subject: general-digest-list Digest V00 #12
X-Loop: general-digest-list@onemodel.org
X-Mailing-List: <general-digest-list@onemodel.org> archive/volume00/12
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/digest; boundary="----------------------------"
To: general-digest-list@onemodel.org
Reply-To: general-list@onemodel.org

------------------------------

Content-Type: text/plain

general-digest-list Digest				Volume 00 : Issue 12

Today's Topics:
  Re: Modeling Relations -- Re: use ca  [ "Tom and other Packers" <TomP@Burgo ]
  meeting                               [ "Tom and other Packers" <TomP@Burgo ]

------------------------------

Date: Sat, 19 Aug 2000 10:08:12 -0600
From: "Tom and other Packers" <TomP@Burgoyne.Com>
To: <general-list@onemodel.org>
Cc: "Jared (h) Norman" <dtfbti@yahoo.com>
Subject: Re: Modeling Relations -- Re: use cases
Message-ID: <001601c009f8$2c4913e0$2403a8c0@oemcomputer>
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Mark and Luke

    We need to consider fuzzy sets, too.  If you change or add an attribute
to a class, to a partial/fractional degree, that will also affect all
members of that class, but in an incomplete way: it will change or add the
probability-of-fractional-degree that such an attribute applies to any given
member of that class.  Or, if a member is a member to a fractional degree,
then any attribute added to its superclass, even one added completely to
that superclass, will only affect that member to the degree to which it is a
member of the superclass.  If both the attribute and the membership are
fractional, then some convention needs to be established for combining the
fractionality here, such as multiplication of the fractional value (a value
between 0 and 1).

    A fractional attribute to a class can be over-ridden by the member,
which would say that the degree to which that attribute affects it, the
individual member, is 100%.  Considering all members' degree-of-attribution,
and the degree of attribution of this attribute to the general class, we can
achieve a useful redundancy: you can compute the degree of attribution for
the entire class based on the degrees found in the individual members, and
see if these two number match.

    About internodes as nodes, I've known about this opinion of Mark's for a
while, that internodes should be considered as nodes, but I've not been able
to explain why I didn't like that idea until now.  My explanation follows
what I said in a previous letter about there being two interpretations of
the three mathetical constructs: the symbolic and the geometric.  If you
looked closely at those few first paragraphs of that letter, you noticed
that in the symbolic interpretation seems to allow for exactly what Mark is
suggesting.  But the geometric interpretation is something different.  In
Mathetical geometry, there is a distinction between internodes and
metainternodes.  Internodes have a slope, which is measured or compared
using metainternodes, but metainternodes do not "have" a slope in the same
sense.  They are slope.  They define slope.  Do you see what I mean?

    Mark, you're example in your next letter locks onto my symbolic example
of metainternodes (the familial-relation example), which makes sense: you
are looking at things symbolically.  You're a computer programmer, so this
makes perfect sense.  And I must say, you've done an efficient job at coding
my example in a very useful-appearing code.  And yes, I thought that it
looked like Prolog.  But what about my geometric examples?  Can we do the
same with internodes and metainternodes in the geometric interpretation?
Prolog would never work.  I sat down with Prolog for a couple of hours once,
and quickly (and I believe accurately) decided that it was way too
restrictive for use in anything remotely similar to Informatica -- or, in
this case, OM.  I didn't try modelling relations metarelationally, so maybe
it wasn't as restrictive as I thought.  But, I tend to believe that it is,
even if it does what you've suggested.

    I want the model to be seamless, and the conversion from one relational
level to the other (from internodes to metainternodes) seems like an ugly
seam to me.  There may be instances when we want to compare nodes and
metainternodes more directly, without having to go through any shifts in
levels of relationality.  And like I said, I see no reason to go beyond
metainternodes, *and* three construct -- just three ... that's not all that
many, you know?  It's simple, and it's powerful.

    Do you have any more to add to your reasons for wanting only two
constructs?

ciao,
tomp

----- Original Message -----
From: Mark Butler <butlerm@middle.net>
To: <general-list@onemodel.org>
Sent: Friday, August 18, 2000 12:01 AM
Subject: Re: Modeling Relations -- Re: use cases


Luke Call wrote:
>
> So, when a user creates some form of is-a relationship between
entities,
> perhaps  the system can assume it is an
> instance of an existing type unless they change the attributes. So, as
> mentioned before, each class is defined by a "type-definer" instance
(an
> archetype), which has additional type-specific data defined, such
> as constraints, default values, and the type name. These could be
> moved, if someone prefers, to a different entity, which then becomes
the
> archetype in its place. But
> then when you add or remove attributes from a member of that class,
does
> that automatically define a new class, modify the existing class (we
> could prompt the user for which), or is a new type created only when
you
> sub-type it by creating another is-a that points to it as the parent?

First, the archetype *is* the class.  If you create a different archetype
you
have just created a new class.

Second, any entity may be thought of as a class of a sort, if only of
membership one.  If I add an attribute to "Mark Butler", I have not changed
any properties of living organism, human, or male - I have changed the
record
of what is known about me alone.   On the other hand, if I add an attribute
to
"human", that automatically affects the interpretation of every instance or
sub class of "human", including "Mark Butler".  If it didn't, it would not
be
a correct attribute.

Sub-classes do not need to explicitly repeat any attributes of the parent
classes - after all we may not know anything about a sub class or instance
beyond some sort of name.  "a human" is a valid instance of "human" with
cardinality one and no other known information.  There is no need to waste
space listing attributes we do not know the value of.


> Could we handle worldviews and inconsistencies in data by allowing
> inconsistent data, but being able to show where the inconsistencies
are,
> and allowing a user to choose the data set they prefer (or choose it
for
> a given query), given the conflict?

Well, I think we should allow users to specify trust levels for different
world views / schemas, and then have the query engine take those levels into
account.  A good query engine would also automatically deprecate the trust
level of each piece of any unresolved inconsistency.

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

Personally, I do not see any reason to draw a iron-clad distinction between
a
node and an internode.  If you treat an internode as a type of node, then a
meta-internode is simply another node that happens to be an internode to an
internode.  And of course, you can then easily add meta-meta-internodes, and
meta^3-internodes, ...

- Mark

--
Mark Butler        ( butlerm@middle.net )
Software Engineer
Epic Systems
(801)-451-4583

------------------------------

Date: Wed, 23 Aug 2000 08:14:50 -0600
From: "Tom and other Packers" <TomP@Burgoyne.Com>
To: "OM List" <general-list@onemodel.org>
Subject: meeting
Message-ID: <003201c00d14$5dd326c0$2f01a8c0@oemcomputer>
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

meeting

Hello Om People

    I guess we all got busy again.  I haven't heard from most of you
recently.

    Some of us want to get together, in person, to discuss the OM thing, and
I think now is the time to start looking for days and times.  Let's get as
many people together as possible, but don't feel badly if you can't make it.
We'll do this again, probably many times in the more distant future.

    I propose September 2, the first Saturday after school starts.  That
will be a good time for me, because I am thinking of combining my work on OM
with my work in an "individual projects and research" CS class I will be
taking next semester.  "Feed two birds with one crumb" as my boss, Dan Cook,
says.

tomp

--------------------------------
End of general-digest-list Digest V00 Issue #12
***********************************************




