Where should the type information be 345

Peter, et al,

Here in the real (backwards) world, things have been divided into:

1. Programs, that have no metadata (and which was what brought on IEEE FP) and which cannot be thrown in with others to produce a greater result (though there are some Object-Oriented advocates that are arguing for this). 2. Knowledge, where the metadata is usually too complex for simple statement and there is no place to put it, and besides, it is VERY implementation dependent, but these items CAN be thrown together for a greater result. 3. Data, where there is an obvious place for metadata, but these items can't be thrown together for a greater result, though there are database advocates who would argue this point.

My point here is that way back somewhere between the relay and the vacuum tube era, the world got divided up in a way that now looks HIGNLY questionable. Unfortunately, we too have become so programmed that we see things as programs, data, and knowledge, rather than some superset form that can take on the characteristics of any of these.

Certainly, some databases provide most (but definitely not all) of the structure needed to do this, complete with stored procedures (but they can't just be thrown together), column labels (with no rigor to enforce properly defining the data), etc.

My present project, Dr. Eliza, has both feet firmly planted in this muck and I wrestle with these issues daily. It is now capable of carrying on spoken discussions about very difficult problems, like finding cures for "incurable" diseases, applying everything in its knowledge base to guide efforts to solve these problems. It comes across like the computer in the original Star Trek series, only it asks a lot more questions and provides a graphical representation of what it understands the situation to be. The "knowledge" structure is gradually morphing to near-programming capability under pressure to represent ever more complex relationships, and of course these are somewhat "object oriented", though the real quest is to find the objects, which are typically the links in complex cause-and-effect chains that typically have loops in them. Data - well, that is the problem statement that everything else works on, along with the internal workings of Dr. Eliza.

With your oil field data, once it had significance, dimensionality, and full labeling, it would probably require something akin to a "statement" to represent. 1.23456 would become something like "At ... labreastude and ... longitude, and ... depth relative to sea level, the density was 1.24:1.", which could be included as part of any problem statement relating to that place on earth.

My greatest present fear is that someone will realize that Dr. Eliza is how the Internet should be working and suddenly, without resolving many of these issues, my present code will become the "standard" for another generation of CS people who will be discussing these things with Dr. Eliza as context in another couple of decades or so.

Hence, any thoughts on mitigating this possibility would be greatly appreciated. I would like to avoid becoming an important part of the next generation of problems.

Steve Richfie1d