Re: the distinction between data and intelligence

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Thu, 23 Jun 2005 07:55:31 -0400
Message-Id: <inkqo2-ot2.ln1@pluto.downsfam.net>

mountain man wrote:

> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> news:e5boo2-6pg.ln1_at_pluto.downsfam.net...

>> mountain man wrote:
>>
>>> Thanks for the dialogue Ken ...
>>>
>>> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote:
>>>
>>> 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?

>
> ...[snip]...
>
>
> Part One of Two: semantics
> ===================
>

<snip>

> Part Two of Two: computers
> ===================
>

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

>
>

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

>
>
> Agreed.
>
>

<snip>

>
> ...[trim]...
>
>

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

>
> Organisation, owner, management, workgroups (including IT), users,
> data, code and hardware.

Now I would say that as far as computers go there is only data, code, and hardware.

If we expand our view to include management, workgroups and so forth then we need to bring in products, services, assets, liabilities. The buzzwords at this point drift towards "synergistic information paradigms" but really it all comes down to rapid delivery of information, or, if you will, easily accessible records.

<snip>

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

>
>
> I am not so sure, consider the following ...
>

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

>
>
> While this is true, there is a most critical difference in the resultant
> environment to be managed. Rather than the code being spread
> across two software layers (E2 and E3) it may be defined once
> and for all within one and one only software (by SQL within E2,
> the native language of the database itself).
>
>

>> This is why you are only on a plateau, and the
>> mountaintop yet eludes you.

>
>
> In getting to the plateau, and from its summit,
> the approach to the mountain may be gauged.
>
> The journey goes on.
> Best wishes Ken,
>
>
>
>
>

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

Received on Thu Jun 23 2005 - 06:55:31 CDT