Re: Objects and Relations

From: JOG <jog_at_cs.nott.ac.uk>
Date: 15 Feb 2007 07:06:21 -0800
Message-ID: <1171551981.857840.217210_at_p10g2000cwp.googlegroups.com>


On 15 Feb, 14:18, "Cimode" <cim..._at_hotmail.com> wrote:
> I realize now that BB has elevated to art, the ability to hide
> anything obvious that would undermine his authority in this NG. He
> automatically pinpoints anything that may potentially represent a
> serious contradiction, then he builds a straw man for that. (In this
> case me).
>
> Question is once again where is the *intellectual honesty* and
> *sincerity* in that?
>
> Below the proofs...
>
> > >>If I am not mistaken, it is *grammar*. What I meant is that LegoBlock
> > >>and Location concepts should be separated if LegoBlock is to be
> > >>considered a relation. A relation *must* have a stable primary key.
> > >>Location is not a stable primary key therefore it does not identify
> > >>LegoBlock. Please be sincere.
> > It is ironic. Above, Cimode insists on a far greater restriction than
> > required by the RM.
>
> According to BB's version of RM, stability for keys is not mandatory.
> Such leniance leads to acceptance of dynamic based keys such as
> location. If BB considered the logical consequence of that, he would
> have realized that the principle of stability in key selection has a
> direct impact on the respect or disrespect of the *mandatory* principe
> of *indiscernibility* which is not just about design.
>
> The principle states that --there's no way whatsoever of
> distinguishing between two objects, then there aren't two objects but
> only one.--(CJ DATE)
>
> Imagine 2 spheres of different sizes with the same center. If they
> are to be identified by their location XYZ then they would be
> indiscernible one from another.

This so wrong it hurts my head.

If two spheres are in different locations then they /are/ discernable as being unique. That's the whole point. Good grief.

This is an abdurdity breaking all
> what RM stands for !
>
> > Stability is an important design criterion for
> > choosing a primary key. Whether one chooses a stable key, though, is a
> > design tradeoff weighed against the other (sometimes conflicting) design
> > criteria like familiarity, simplicity, and irreducibility.
>
> Not just important. Stability is not just about *level of
> updatability in time*. Stability is about making sure, that during
> selection process that a primary key respects all mandatory principles
> IN TIME.
>
> The reason I consider stability as crucial is because I think it IS
> NOT OK to choose a key by while ignoring undiscernibility which is
> what you were heading to.
>
> > >>I am trying to help you get another pov about RM that is way too wide
> > >>to be locked up in BB's or my definitions.
> > And then he claims his position is expansive rather than restricting.
>
> That is called a trial of intension and a direct manipulation
> attempt. I spotted a reasoning that led to an absurdity and tried to
> warn you about. All was done with good intentions. Just make up your
> mind on what you observe.
>
> That is all I want to say.
Received on Thu Feb 15 2007 - 16:06:21 CET

Original text of this message