From - Tue Feb 20 18:08:25 2001
X-UIDL: be1f53ac13ed7763
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 70407 invoked by uid 800); 20 Feb 2001 14:11:06 -0000
Date: 20 Feb 2001 14:11:06 -0000
Message-ID: <20010220141106.70406.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/14"%general-digest-list-request@onemodel.org>
Subject: archive retrieval: volume00/14
Precedence: bulk
Content-Disposition: inline; filename="volume00/14"
Content-Type: message/rfc822;
	directory="volume00"; name="14"
MIME-Version: 1.0

From: general-digest-list-request@onemodel.org
Subject: general-digest-list Digest V00 #14
X-Loop: general-digest-list@onemodel.org
X-Mailing-List: <general-digest-list@onemodel.org> archive/volume00/14
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 14

Today's Topics:
  Re: [Fwd: Modeling Relations -- Re:   [ Lee Howard <redder@deanox.com> ]
  "marketing"                           [ Lee Howard <redder@deanox.com> ]
  Re: [Fwd: Modeling Relations -- Re:   [ Mark Butler <butlerm@middle.net> ]
  Re: [Fwd: Modeling Relations -- Re:   [ "Tom and other Packers" <TomP@Burgo ]

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

Date: Sun, 27 Aug 2000 21:53:15 -0600
From: Lee Howard <redder@deanox.com>
To: general-list@onemodel.org
Subject: Re: [Fwd: Modeling Relations -- Re: use cases]
Message-Id: <3.0.6.32.20000827215315.00807670@server.deanox.com>
Content-Type: text/plain; charset="us-ascii"

Mark, could you expound a bit on the usage of nodes as internodes?

In a relational database, (as I understand it, obviously) traditionally
things are constructed such that two or more records are related by some
given path.  For example points A and B are separated by distance C on a line.

As I understand your proposal that internodes be a type or use of a node,
A, B, and C in the example above C would be treated as a piece of
information as much as A and B are, and in a real sense, our relation would
be that some field A is related to some field B by the manner of field C.
Am I correct?

Therefore, the internodal usage (the "separated by") of this node is a
specific quality of that node?  And not all nodes necessarily must also
function as internodes?

I'm sure that there is a way, but could you illustrate when you would use
what "normally" would be used as an internode also as a node?  For example
"separated by distance C" is related to "separated by distance E" by |C-E|
(an absolute) ?

Thanks.

Lee.

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

Date: Sun, 27 Aug 2000 22:10:23 -0600
From: Lee Howard <redder@deanox.com>
To: general-list@onemodel.org
Subject: "marketing"
Message-Id: <3.0.6.32.20000827221023.00809bd0@server.deanox.com>
Content-Type: text/plain; charset="us-ascii"

I have a little confusion as to the OM project.  (Well, I have more than *a
little* confusion with regards to it, but this is a part of it...)

Tom has spoken/written often about "marketing" the product when it's done.
Although "marketing" can mean a lot more things, my understanding has been
that specifically, this "marketing" is intended for selling it - for money
and profit.

My concern is that on the OM website, this project is said to be under the
GPL, and talk has gone on about CVS and other things (although CVS need not
be used specifically for "free" things).  These two ideas seemingly are in
conflict.

In one case, (selling software) the code itself (or even the software
itself) is never sold, and in order to protect copyrights, the customer
pays for a license to use it.

In the latter case, (GPL) the code itself (and likewise the software) is
also never sold because it is essentially "free" in the terms of the GPL
(the license to use it is free, and the code is free to alter).  The
customer in this case typically pays for the software's customization and
implementation.

Honestly, I think both of these cases are profitable [in most software
applications].  (Stuff like antivirus software can conceivably only
function profitably under the licensing method because it's really just a
compliation of information or "virus patterns" of which the free
distribution would undermine the profitability.)  I think both of them have
their purpose and place, and I tend to favor one over the other, but could
somebody please clarify the position of this project?

Thanks.

Lee.

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

Date: Mon, 28 Aug 2000 00:04:25 -0600
From: Mark Butler <butlerm@middle.net>
To: Lee Howard <redder@deanox.com>
CC: general-list@onemodel.org
Subject: Re: [Fwd: Modeling Relations -- Re: use cases]
Message-ID: <39AA00E9.286DACEF@middle.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lee Howard wrote:
> 
> Mark, could you expound a bit on the usage of nodes as internodes?

Well, first of all, I do not really understand the details of how nodes and
internodes and meta-internodes are intended to be used.  All I can say is that
in most symbolic systems, any abstraction of a first class symbol may be used
as another new first class symbol.  In the strict
"node-internode-meta-internode" system, neither internodes nor meta-internodes
are first class symbols.

Now a three level system could be ideal for representing distilled truth about
the state of reality, for reasons that Tom has spent a lot of time
considering, but I think that it is too narrow of an abstraction to  represent
the views of others in a form completely faithful to the original text.  My
recommendation is to start with more abstract data in non-Mathesis form and
then work on reducing it what I hereby dub Mathesis Normal Form (MNF), much
like a database analyst would normalize a database design.  The key is that a
data modeling tool does not prevent the designer from starting with a
denormalized model.
 
> In a relational database, (as I understand it, obviously) traditionally
> things are constructed such that two or more records are related by some
> given path.  For example points A and B are separated by distance C on a line.
> 
> As I understand your proposal that internodes be a type or use of a node,
> A, B, and C in the example above C would be treated as a piece of
> information as much as A and B are, and in a real sense, our relation would
> be that some field A is related to some field B by the manner of field C.
> Am I correct?

Roughly, yes - except you should substitute "record" for "field".
 
> Therefore, the internodal usage (the "separated by") of this node is a
> specific quality of that node?  And not all nodes necessarily must also
> function as internodes?

Yes.  In my view, an internode is a special kind of generalized node.  Most
generalized nodes are clearly not internodes. However, I believe a large
number of internodes should be considered to be nodes as well:

 "friendship", "similarity", "affinity", "bond"
 "inclination", "relationship", "association"
 "difference", "distance", "separation", "offset"
 "temperature", "altitude", "elevation"

I can speak of "friendship" as a "node", e.g. "friendship" in "I like
friendship"
I can also speak of friendship as an "internode", e.g. the friendship between
Jack and Jill.

As far as I can tell, the latter is an instance or sub-class of the former,
i.e. the "internode" is an instance or sub-class of the "node".

How about the sentence:  "He thinks his girlfriend really likes him"

We have two obvious nodes:  "He" and "his girlfriend"
We also have an obvious internode: really_likes(girlfriend,him)

But then we have a problem:  thinks(he,really_likes(girlfriend,him)) is
supposed to be another internode, but the second argument, the object of the
verb thinks, is already an internode, which is disallowed because all
internodes must relate two nodes.  Clearly thinks(...) cannot be a
meta-internode either because then "he" would have to be a internode instead
of a plain old node. 

Again, the solution is to promote the internode really_likes(...,...) to full
node-hood without giving up its internodal attributes.  

> I'm sure that there is a way, but could you illustrate when you would use
> what "normally" would be used as an internode also as a node?  For example
> "separated by distance C" is related to "separated by distance E" by |C-E|
> (an absolute) ?

See above for a good example.  Any discourse about an internode treats the
internode as a node. Key words to watch for are "about", "that", "according
to", "the statement", "true", and "false".  Without treating some internodes
as nodes, no meta-discourse (discourse about discourse) can be represented.  

- Mark


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

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

Date: Tue, 29 Aug 2000 06:48:04 -0600
From: "Tom and other Packers" <TomP@Burgoyne.Com>
To: general-list@onemodel.org
Cc: <general-list@onemodel.org>
Subject: Re: [Fwd: Modeling Relations -- Re: use cases]
Message-ID: <003001c011b7$7720cea0$2a01a8c0@oemcomputer>
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Mark

    First potential problem: I have not given any reason to believe that
internodes are verbs, and vice versa.

    To be practical, I guess we will have to devise a very abstract,
symbolic way of translating sentences like "He thinks his girl friend really
likes him".  But the ideal case would be to break such a sentence down into
very concrete relations, geometries if you will, and that would look nothing
like what Mark has done, e.g. "thinks( he, really_likes( girlfriend,
him ) )".

    I'll have to talk about this later.

tomp

----- Original Message -----
From: Mark Butler <butlerm@middle.net>
To: Lee Howard <redder@deanox.com>
Cc: <general-list@onemodel.org>
Sent: Monday, August 28, 2000 12:04 AM
Subject: Re: [Fwd: Modeling Relations -- Re: use cases]


Lee Howard wrote:
>
> Mark, could you expound a bit on the usage of nodes as internodes?

Well, first of all, I do not really understand the details of how nodes and
internodes and meta-internodes are intended to be used.  All I can say is
that
in most symbolic systems, any abstraction of a first class symbol may be
used
as another new first class symbol.  In the strict
"node-internode-meta-internode" system, neither internodes nor
meta-internodes
are first class symbols.

Now a three level system could be ideal for representing distilled truth
about
the state of reality, for reasons that Tom has spent a lot of time
considering, but I think that it is too narrow of an abstraction to
represent
the views of others in a form completely faithful to the original text.  My
recommendation is to start with more abstract data in non-Mathesis form and
then work on reducing it what I hereby dub Mathesis Normal Form (MNF), much
like a database analyst would normalize a database design.  The key is that
a
data modeling tool does not prevent the designer from starting with a
denormalized model.

> In a relational database, (as I understand it, obviously) traditionally
> things are constructed such that two or more records are related by some
> given path.  For example points A and B are separated by distance C on a
line.
>
> As I understand your proposal that internodes be a type or use of a node,
> A, B, and C in the example above C would be treated as a piece of
> information as much as A and B are, and in a real sense, our relation
would
> be that some field A is related to some field B by the manner of field C.
> Am I correct?

Roughly, yes - except you should substitute "record" for "field".

> Therefore, the internodal usage (the "separated by") of this node is a
> specific quality of that node?  And not all nodes necessarily must also
> function as internodes?

Yes.  In my view, an internode is a special kind of generalized node.  Most
generalized nodes are clearly not internodes. However, I believe a large
number of internodes should be considered to be nodes as well:

 "friendship", "similarity", "affinity", "bond"
 "inclination", "relationship", "association"
 "difference", "distance", "separation", "offset"
 "temperature", "altitude", "elevation"

I can speak of "friendship" as a "node", e.g. "friendship" in "I like
friendship"
I can also speak of friendship as an "internode", e.g. the friendship
between
Jack and Jill.

As far as I can tell, the latter is an instance or sub-class of the former,
i.e. the "internode" is an instance or sub-class of the "node".

How about the sentence:  "He thinks his girlfriend really likes him"

We have two obvious nodes:  "He" and "his girlfriend"
We also have an obvious internode: really_likes(girlfriend,him)

But then we have a problem:  thinks(he,really_likes(girlfriend,him)) is
supposed to be another internode, but the second argument, the object of the
verb thinks, is already an internode, which is disallowed because all
internodes must relate two nodes.  Clearly thinks(...) cannot be a
meta-internode either because then "he" would have to be a internode instead
of a plain old node.

Again, the solution is to promote the internode really_likes(...,...) to
full
node-hood without giving up its internodal attributes.

> I'm sure that there is a way, but could you illustrate when you would use
> what "normally" would be used as an internode also as a node?  For example
> "separated by distance C" is related to "separated by distance E" by |C-E|
> (an absolute) ?

See above for a good example.  Any discourse about an internode treats the
internode as a node. Key words to watch for are "about", "that", "according
to", "the statement", "true", and "false".  Without treating some internodes
as nodes, no meta-discourse (discourse about discourse) can be represented.

- Mark


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

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




