Re: the distinction between data and intelligence

mountain man wrote:

> Thanks for the dialogue Ken ...
>
> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote:
>

>> Normally when pressed for details on "intelligence", you seem, and I use
>> this word inviting correction, to equate intelligence with processes.  I
>> would suggest this is way too broad.  You are trying to pin down the
>> assets
>> that are not physical, no?  Boxes are physical.  Data, being static once
>> recorded, is actually more like boxes than it is like code, because once
>> you have it you have it.  But what is code?  Is this what you call
>> intelligence?  I'd like to follow that reasoning through and see if it
>> can be nailed down to measurable terms.

My dispute is with the term "intelligence". I just can't get past that. Isn't it closer to the fundamentals to say they have established procedures around technology assets, those assets being hardware, software, and data?

>
> Selection of some E1 is not regarded as "high-level" intelligence
> but rather as a service for E2 and E3.

Architecturally, yes. It is infrastructure.

>
> Selection of some E2 is not regarded as "high-level" intelligence
> but rather as a service for E3 and for housing the data itself.

This is not universally true. Plenty of people put code into the db just as you do and I do, but we'll go with the definition for the sake of flow.

>
> OTOH, whatever is being defined in the E3 application layer
> is implicity related to the functionality of the organisation. Typically
> E3 is a suite or a series of suites of component program objects
> that have been developed by programmers, using CODE of
> some form.

Ok....

>
> The code of a simple report can be viewed as being an atomic
> element of some degree (not necessarily defined) of intelligence.
> The code of the report is a method for extracting data in a
> particular format and presentation for some workgroup or
> user in the organsation.

Again I have to strike out "intelligence" and state that it is a productive asset. Until of course the day needs change and it is ignored, later to be discarded. It is not intelligence. It is not an autonomous reasoning being.

>
> Once improved, by revising the code, a report can be may
> *more* "intelligent" by enhancing its functionality, etc. By
> definition all development work should expect to increase
> the overall "computerised intelligence" of an organisation.

The report can be made more useful, but since it is not intelligent in the first place it cannot become moreso.

There is perhaps an argument that a critical mass of useful items like reports and programs result in intelligence as an emergent property. The problem of course is that this is sci-fi, Skynet and Arnold the Terminator. Intelligence does not appear to emerge from any level of computer complexity yet achieved by human beings.

>
> Intelligence also exists in the data, or rather in the efficiency
> of the relationships between the data elements. The relational
> model is viewed as a prescription for maximising intelligence,
> and for example, improving the overall relational schema, may
> be seen as making the whole database systems environment
> more intelligent (with respect to the organisation).

The relational model is a way of maximizing the accuracy of record-keeping. Calling it intelligent is like calling a library intelligent.

The RM made it easier to store records, and therefore easier to use them.

We must continue to reserve the word "intelligence" for the human agents that make use of these records.

>
> In the past I have attempted to define "organisational intelligence"
> as some form of stock-take (union) of all data and code that
> is in service to that organisation.
>
> But I do agree that the term "intelligence" has today much
> associated baggage, and even though I have tried to be
> very specific in the (informal) definitions and examples
> (such as above and before), room for gross misunderstandings
> seems inevitable.

I would say with all respect that you are contributing to the baggage by trying to force the use of a word that does not apply.

Here is a challenge, Pete. Force yourself not to use the word "intelligent" and then describe the collection of data, code and hardware. What terms come to mind? Before creating an abstract holistic description of them, define them individually and precisely, then see what description emerges.

My contention is that you have some good insights here but they are hobbled by your own use of the word. You have fallen into the trap you describe. The ideas you are pursuing will likely expand very usefully if you abandon that word.

>
> So what is another term, to be applied to the superset of
> all data (held in E2) and all code (E3), besides "intelligence"
> [ie: computerised OI]? One suggestion was simply
> "data plus code".

Well here is a thought. It may be that lumping E2 and E3 together is not appropriate. Just because they both exist inside a computer does not mean they are all that related. Data is records, code is agents. They don't have quite so much in common as people think.

Why not just describe productive assets as productive assets?

>
> Whatever this term, it is this superset that is the final production
> and theoretical environment to be managed and defined. The
> data is important and central, but it is not all there is to
> database systems.

Here is where I come in with my claim that the *specification* of the database is the One True Superobject you are seeking. Managing all of these assets is all about:

-> Getting the spec right
-> Getting the implementation right
-> Successfully repeating when spec changes

>
> Date says in the intro to his new book (and elsewhere many
> times) that the RM is "a large part of the foundation of database
> systems". This of course begs the question: what is the other
> part to the foundation?

I like Date, but he is not a prophet for me, so I'm afraid I can't answer that one.

>
> I answer this question as follows: All database system invariably
> have associated with this data a specific suite of database
> application software (CODE).
>
> Traditionally this code was external to the database, but times
> and technology are rapidly changing. Today, much of this code
> (ie: E3 - application software code) may exists internal to the
> (R)DBMS - stored procedures coded from SQL.
>
> To take matters to their extremes, I am able to demonstrate
> http://www.mountainman.com.au/software/southwind/
> a database system in which 100% of the application code
> is internal to the (R)DBMS - along with the data - in the
> form of SQL (stored procs).

For the above three paragraphs, I would contend you have mistaken a *plateau* for the *mountaintop*. As an implementation issue, being able to put code into the DB solves a crucial issue, it allows you to enforce biz rules on the server itself, allowing for no back-door to commit bad data.

But this is only an implementation ability, it is not the final theory of coding. When you move the code into the server you carry with you all of the problems of coding, all of the version control issues, all of the need to match code to structure. This is why you are only on a plateau, and the mountaintop yet eludes you.

>
> There seems to be an opportunity to generalise the theory of
> database systems to take into account not just the data, but
> the data and *its* code.
>
> Ultimately, it is this union that needs to be addressed, by
> practice and by theory, IMO.

My own answer remains the same, to expand the database designer's ability to specify what goes into the database. My own whitepaper on that subject is here:

http://www.secdat.com/dev/atomic.html

Once you have obtained a complete specification of what records must be kept, you can then decide where to put the code (and here the two of us both put it into the server).

>
> I term this union "computerised intelligence" only for want
> of a better (single) term that bundles data and code together.
>
> Hope this reply has revealed the reasoning behind the need
> to find a term for the data PLUS the code.
>

It has.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)