Re: Storing data and code in a Db with LISP-like interface

From: JOG <jog_at_cs.nott.ac.uk>
Date: 1 May 2006 20:05:48 -0700
Message-ID: <1146539148.405239.200950_at_i40g2000cwc.googlegroups.com>


Alvin Ryder wrote:
> JOG wrote:
> > Alvin Ryder wrote:
> > [snip]
> > > But once we try to capture the "meaning" of data to provide more
> > > intelligence in the db, we enter a wide open never ending pursuit. Now
> > > we are not using sets in a blind way.
> > [/snip]
> >
> > Hi Alvin, apologies for the ruthless snip, but I have seen this sort of
> > sentiment so many times that it becomes frustrating. Data has no
> > meaning to a pc. It is just data. Computers simply cannot 'do' meaning
> > - understanding of semantics requires embodiment in the appropriate
> > domain. This situatedness is such a complex problem that AI is decades,
> > if not hundreds of years, from solving it. As such, anything with
> > cliche's such as 'bridging the semantic gap' or 'providing meaning' in
> > the title is currently fool's gold.
> >
> > Data models describe things for us. The best ones do so with solid
> > theoretical basis such as RDM, but that is all they do.
>
>
> Hi JOG,
>
> You must've snipped my reference to one of many of Codd's papers on the
> subject. You liked his 1970 work, I thought you might've enjoyed some
> of his other contributions as well ;-)

I've stated in other threads I am far from a fan of RM/T's closer integration with entity modelling. That doesn't negate the inventiveness and remarkable insight of Codd's work.

> Granted the simplicity of the earlier version of the model has great
> appeal, but surely you can admit there are limitations, If you haven't
> discovered any, nevermind, enjoy you day.

Limitations in the theory, or limitations in the tools I have to apply that theory? The latter by a country mile.

>
> Cheers.
Received on Tue May 02 2006 - 05:05:48 CEST

Original text of this message