Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On Sep 26, 7:11 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> On 26/09/2010 2:16 AM, Erwin wrote:
>
>
>
>
>
> > On 25 sep, 22:41, Brian<br..._at_selzer-software.com>  wrote:
>
> >> The employee named paul c fills the position named toilet scrubber.
>
> >> Let's look at the information conveyed by this statement:
> >> 1. there is an employee named 'paul c.'
> >> 2. there is a position named 'toilet scrubber.'
> >> 3. the named employee fills the named position.
>
> >> Now, suppose that paul c's position changes from toilet scrubber to
> >> floor sweeper.
>
> >> Assuming that no other proposition references an employee named paul c
> >> or a position named toilet scrubber, doesn't the denial of
>
> >> (a) The employee named paul c fills the position named toilet
> >> scrubber.
>
> >> also deny that there is an employee named paul c and that there is a
> >> position named toilet scrubber?
>
> > LOFL.
>
> > Who again was it that should go back to school and take a course in
> > logic ?
>
> > EXISTS employee : employee(name) = 'paul c'&&  employee(position) =
> > 'toilet scrubber'  does indeed imply EXISTS employee : employee(name)
> > = 'paul c'&&  EXISTS employee : employee(position) = 'toilet
> > scrubber'.  But note that the former and the latter are not
> > equivalent, since the former conveys the extra information that the
> > two properties apply to the very same person.
>
> > NOT EXISTS employee : employee(name) = 'paul c'&&  employee(position)
> > = 'toilet scrubber' ===
> > FORALL employee : NOT(employee(name) = 'paul c'&&  employee(position)
> > = 'toilet scrubber') ===
> > FORALL employee : employee(name)<>  'paul c'  OR  employee(position)
> > <>  'toilet scrubber')
>
> > The denial of "(a) The employee named paul c fills the position named
> > toilet scrubber." implies merely that if an employee is named paul c,
> > then he is not a toilet scrubber, and also that if an employee is a
> > toilet scrubber, then he is not named paul c.
>
> > So the answer to your question "doesn't the denial of ... also
> > imply ..." is, "No, doesn't.".
>
> Also, the statement "there is a position named 'toilet scrubber'" (or
> suchlike but even if I remember it wrongly is reminiscent of how
> toilets relate to the current thread drift) is a tautology as far as the
> original db fragment is concerned, dressed up in invisible clothes,
> parading as an inference.  

No. It isn't. Again, you really need to take a beginner's course on logic. The sentence,

There is a position named 'toilet scrubber.'

is false just in case there isn't any position named 'toilet scrubber.' If it were a tautology, then it would be true under all interpretations, which it clearly is not.

<snip>

> Meanwhile, one big obstacle from the original scenario, "a labour
> activity date must not change", remains unexplained and unjustified and
> mystical to me.  Mystical because it's undersimplified, undersimplified
> because completely bald starting points can't be refined.  We still
> don't know whether it is some misapprehension of trivial FD's, some new
> notion of constraint applied to transactions instead of relations or
> just bald nonsensical technocratic-sounding mumbo-jumbo, or something
> else (if there can possibly be anything else).  I put this down to
> wanton, willful sloppy language use, even though there newsreaders that
> object to 'labour' but not to 'trival' might give some the illusion that
> what they wrote makes sense.

If you can't recognize the difference between a state constraint and a transition constraint, then there is absolutely no hope for you.

<snip> Received on Mon Sep 27 2010 - 05:38:27 CEST