Re: what are keys and surrogates?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 09 Jan 2008 11:06:19 -0400
Message-ID: <4784e2ed$0$19868$9a566e8b_at_news.aliant.net>
>>On Jan 8, 9:26 am, JOG <j..._at_cs.nott.ac.uk> wrote:
>>
>>In November I started a thread called "RM and abstract syntax trees"
>>in which I suggested that RM was poorly suited for the representation,
>>never mind manipulation of ASTs.
>>The problem is that the only
>>reasonable way to represent the structure is to introduce meaningless
>>node identifiers. An important principle in the RM is that a tuple
>>should always represent a proposition that makes sense to the problem
>>domain expert, so I agree with you that we cannot allow hidden
>>identifiers. Therefore the RM cannot help but expose the node
>>identifiers for all to see.
>>
>>Prolog is able to parse string expressions entered by users and build
>>and manipulate ASTs. Behind the scenes, nested functor expressions
>>are usually implemented using dynamically allocated nodes wired up
>>with pointers. However, as far as the programmer is concerned, only
>>unification is available to decompose the structure. It seems to me
>>that Prolog has a more general support for data modeling than
>>available in the RM, to the extent that nested functor expressions
>>avoid the need to introduce lots of meaningless identifiers.
Date: Wed, 09 Jan 2008 11:06:19 -0400
Message-ID: <4784e2ed$0$19868$9a566e8b_at_news.aliant.net>
Marshall wrote:
> On Jan 8, 6:17 pm, David BL <davi..._at_iinet.net.au> wrote: >
>>On Jan 8, 9:26 am, JOG <j..._at_cs.nott.ac.uk> wrote:
>>
>>In November I started a thread called "RM and abstract syntax trees"
>>in which I suggested that RM was poorly suited for the representation,
>>never mind manipulation of ASTs.
> > Hmmm, I think I remember that. ;-) > >
>>The problem is that the only
>>reasonable way to represent the structure is to introduce meaningless
>>node identifiers. An important principle in the RM is that a tuple
>>should always represent a proposition that makes sense to the problem
>>domain expert, so I agree with you that we cannot allow hidden
>>identifiers. Therefore the RM cannot help but expose the node
>>identifiers for all to see.
>>
>>Prolog is able to parse string expressions entered by users and build
>>and manipulate ASTs. Behind the scenes, nested functor expressions
>>are usually implemented using dynamically allocated nodes wired up
>>with pointers. However, as far as the programmer is concerned, only
>>unification is available to decompose the structure. It seems to me
>>that Prolog has a more general support for data modeling than
>>available in the RM, to the extent that nested functor expressions
>>avoid the need to introduce lots of meaningless identifiers.
> > This issue goes away if we relax 1NF and allow attributes that are > lists or relations. This gives us nested structures. (Nested relations > are not particularly controversial around here.)
The straw man starts at: "the only reasonable way". Received on Wed Jan 09 2008 - 16:06:19 CET