Re: Order & meaning in a proposition
Date: Tue, 06 Apr 2004 15:35:04 GMT
I was going to type a response, but I think Tony said everything I had to say... in my experience, the more detailed I got with my business analysts, the less our documents looked like English. We developed notations, diagrams, etc. and one of them even wrote me formulas in FORTRAN! Language (and I assume you mean English - I would assume most Western languages have the same issues, though I can't speak for Eastern ones) is the starting point for all requirements, but only the starting point.
"Tony" <andrewst_at_onetel.net.uk> wrote in message
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> > I broke down and bought the latest Date "An Introduction to Database
> > Systems" text. It looks very comprehensive on the one hand and I look
> > forward to reading it cover to cover, even though I have read some of it
> > prior versions.
> > Without having read the entire book, there still seems to be an aspect
> > missing that is integral to understanding data -- language. When taking
> > proposition and normalizing it for the purpose of modeling it, there are
> > times when information is inadvertently lost or left behind because it
> > not critical. Sample proposition:
> > Pat is the host who seated the President and the Secretary of the
> > If we have a relational model for this proposition, we will end up
> > this proposition up and will undoubtedly lose the order of those who
> > seated. If Pat seated others too, we will also lose the fact that these
> > seemed to have been seated together or in close proximity of time or
> > There is nothing explicit about the ordering, nor is it considered
> > important, perhaps, for our software application. However, there is an
> > ordering here that is not arbitrary -- the President was listed first as
> > indication of the relative importance of the two who were seated. Even
> > Pat seated the Secretary of State later, it is likely relevant that such
> > information is in a separate proposition from the one above.
> > Once we split apart a proposition in such a way that we cannot get the
> > original proposition back, even if we THINK we are getting the important
> > aspects of it back, we have lost some of the meaning we intended to
> > This is an off-the-top-of-my-head example of where one might lose
> > information when normalizing data and likely not a very good example
> > compared to what might be lost in a typical business application.
> > the point is that the process of normalizing data makes it sometimes
> > impossible to retrieve the original propositions, thereby losing some
> > information.
> > A data modeling process that respects the integrity of the stored
> > propositions so that they can be retrieved again has something going for
> > that the relational model lacks, it seems. Any thoughts?
> Your example demonstrates exactly why language is a POOR way to
> express a proposition, and hence should not be the basis of a data
> model. You state that sentence and then claim that it also denotes
> a) The President was seated first, then the Secretary
> b) The President and the Secretary were seated together (maybe)
> c) The President and the Secretary were seated at the same time
> Well, if it was meant denote any or all of those things it is not at
> all clear about it. In fact, these seem to be assumptions rather than
> true inferences. For all I know it might form part of a longer
> "Pat is the host who seated the President and the Secretary of the
> Interior. Pat seated the Secretary when he/she arrived at 8pm, and
> the President half an hour later. The President sat at the top table
> and the Secretary sat at the bottom table."
> Now if the facts are as you believe, then the propositions should be
> stated as such, e.g.:
> Pat is the host
> Pat seated the President at time T1 in location L1
> Pat seated the Secretary of the Interior at time T2 in location L2
> That no longer reads like everyday language, because it is now being
> precise about what it means, which everyday language does not as a
Received on Tue Apr 06 2004 - 17:35:04 CEST