Re: the distinction between data and intelligence

"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

The term "computerised artificial intelligence" is interchangeable with my use of the term "intelligence". Is Big Blue, as an opponent, an intelligent chess player? Semblance of intelligence equates somewhere with the ability to perform processes that "seem to be intelligence" with respect to that environment.

Generalising with respect to the 40-80% relational database management systems environment (as used today globally) *and* their incumbent database application software, one might observe that there exists a range of situations in which it makes reasonable sense to consider the term "computerised artificial intelligence" is applicable to such systems.

Now maybe this is semantics, so I'll not further here use this term "intelligence" as a short form of "computerised artificial intelligence".

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.

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

No, here I am meaning by E2 the generic available RDBMS (or SQL-DBMS) software "layer", and in some cases, the proprietory DBMS software of earlier decades. (eg: SQL Server, Oracle, DB2, etc)

People putting code into this layer is a separate issue, and dealt with as the application layer E3, as we agree below.

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

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

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

Ok.

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

Data is usually added, updated, deleted and/or selected by means of code. Code is usually generated for the explicit purpose of adding, updating, deleting and/or selecting data.

They are ying and yang. ;-)
How can they not have so much in common?

> Why not just describe productive assets as productive assets?

 good advice!

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

In a nutshell.

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

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,

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au