Re: the distinction between data and intelligence

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote:

Thanks for the dialogue Ken ...

> 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.

Let's examine the database systems environment of a progressive organisation that has harnessed technology to some lengths. We would see that there is going to be three layers of software:

E1: some operating system
E2: some (R)DBMS (and data).
E3: some application (code)

The activity of the combination of these software layers (in conjunction with the data itself) effectively acts as a developed intelligence with respect to the organisation.

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

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

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.

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.

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.

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).

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.

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".

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.

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 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).

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.

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.

Best wishes for now,

-- 
Pete Brown
Falls Creek
OZ
www.mountainman.com.au