Re: Order & meaning in a proposition

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:I1Scc.51787$_37.3056_at_newssvr16.news.prodigy.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c4vdsj$n7k$1_at_news.netins.net...
> > Bingo - I'm referring to stuff that no one would consider "important
> enough"
> > from a data processing standpoint, but still provides information that
> need
> > not be lost (in all cases). Why lose ordering if you don't have to?
>
> Why leave its importance implicit (e.g. to be used or ignored, but in
either
> case ASSUMED by application developers) if you don't have to?

The information of which I speak (and my example is not great) is that which we would recognize as insignificant and when we ask the user, to be certain we are making correct assumptions, they will acknowledge the data as unimportant. In fact, it is not important, it is just a little more information that could perhaps seep into our brains and help us solve a business problem better, unwittingly. I recognize that by turning sentences into data to which we will apply predicate logic, we are losing some of this "fruffy" information. But, if we don't lose anything from a logic perspective in keeping such things as the ordering of multiple nouns in a sentence, then let's not.

For example, if there are strict rules at the pizz place (yes, that is another thread) that we put mozzarella on before we put parmesan on the pizza and when the order pops up it says

Pizza Mozzarella

           Parmesan

Then that helps us in some little bit, even though it is redundant information. It wouldn't be worth collecting this information specifically in some sort of ordering data element, but if we pop this puppy into the database and it keeps the order that we stated it in, so much the better, right?

> > > Is an XML document a data model? I've only seen XML used for
> > > presentation of data, not for data storage, so forgive my ignorance.
> >
> > Nope, an XML document is not a data model, but modeling data for
eventual
> > deployment via an XML document (for example, for data exchange purposes)
> > likely means use of a different data model in the first place.
>
> I disagree completely. A relational structure allows the simple generation
> of any number of hierarchies, without favoring one. Unless you enjoy
> coupling the internals of your app to every communication it has to make
> with the outside world, that's a Good Thing (tm 2004, Martha Stewart
Inc.).

This reminds me of some new customers to a UniData (an IBM PICK database) application who told me that they would like to use ODBC to retrieve their data for an XML document. I pointed out to them that the UniData data had information such as a student and their "set of majors" (whether stored that way or virtual data) so you could ask it to

LIST STUDENTS MAJORS and you would get one record for each student, with their list of majors.

If you then use ODBC to access it, you are doing a virtual normalization of the data, then you are taking that data and mapping it to XML, where, in this case, they needed one document per student (I'm truncating the example for simplicity purposes).

Similarly, we can take what is in our brain as a statement about David majoring in Math and Philosophy and turn that into two propositions about David prior to designing the schema for a PICK database where we would then pour those two statements back together. But why go through that silly exercise? Skip the 1NF in the process and you can go "from your brain to your data structure" even without a lot of theory classes in between. And then the translation to XML is quite obvious too. Get SQL, ODBC, and the relational 1NF, uh, hogwash out of the middle -- it only makes for extra steps. --dawn Received on Wed Apr 07 2004 - 17:44:00 CEST