Re: Modeling question...

From: David BL <>
Date: Mon, 27 Oct 2008 22:49:33 -0700 (PDT)
Message-ID: <>

On Oct 27, 10:16 am, JOG <> wrote:
> On Oct 24, 10:13 am, David BL <> wrote:
> > On Oct 24, 4:16 pm, "Walter Mitty" <> wrote:
> > > "David BL" <> wrote in message
> > >
> > > >Ok, I’ll bite…
> > > >No doubt any data can be made to “fit” into the relational model.
> > > >The more important question is whether it happens /naturally/. The
> > > I don't understand the word "naturally" in this context. Isn't all modeling
> > > artificial, rather than natural?
> > I'm suggesting that in certain situations the RM is cumbersome, making
> > it inappropriate or inapplicable. This is specifically with regard
> > to /recursive data types/.
> > For example, recursive data types are appropriate for representing
> > wffs in most formal languages. They are also relevant in compound
> > documents. Eg
> > struct Chapter
> > {
> > String title;
> > Vector<Paragraph> paragraphs;
> > Vector<Chapter> subchapters;
> > };
> > There are two ways that the RM can be used to represent recursive data
> > types:
> I think this is the wrong way of looking at it. The OO (for want of a
> better word) and RM approaches are two different ways of modelling
> statements of fact from the world. And yet you seem to be stating the
> problem as how to try and model a struct/object in RM? (That would be
> like complaining that after you've put all your milk into a fridge,
> you're having trouble pouring the fridge onto your cereal!)

I'm making the following claims:

  1. There are applications that require the management of data in the form of heavily nested values (ie of recursive value types).
  2. There doesn't exist a satisfactory decomposition of values of a recursive value type into the RM other than by the use of recursive RVAs.

This has nothing specifically to do with structs, objects and OO. In fact if anything OO languages tend to be rather poor at supporting user defined value types.

Lisp and Prolog both provide excellent means to represent and process recursive value types, and arguably much better than in C/C++.

I would suggest that the constraints imposed by RM/RA are best understood by an experienced Prolog programmer. One of those constraints (assuming no recursive RVAs) is tantamount to outlawing nested terms.

> > 1. Using recursive RVAs; or
> > 2. By introducing abstract identifiers for all the nodes, and
> > appropriate integrity constraints
> > I find the first quite reasonable, but I'm suspicious of actually
> > calling such an approach "relational".
> What do you do in real life to identify a chapter? You refer to it by
> name or number - and the same for subchapters too right? And if two
> subchapters have the same local identifier (e.g. 'introduction') well
> you use a composite identifer such as "the 'introduction' of the third
> chapter". And if you can refer to a chapter when communicating with
> someone else, then you have necessarily stated something about it in
> the form of a proposition - and if it can be stated as a
> can be encoded as a tuple in RM.

I agree that statements about things are well suited to the RM.

> And as far as constraints are concerned, what more do you need apart
> from a subchapter can only have one containing chapter? I don't see
> the issue with this example. Regards, J.

The example of the chapter was to show that recursive data types are quite common (and not just limited to wffs in formal languages). This suggests there are many applications for which these questions are relevant. However the example is too simple to reveal the problems.

If you have a fairly complex grammar (or definition of a wff in some formal language), such as defined by the OpenDocument specification, would you be happy to represent those wffs in the RM?

The OpenDocument V1.1 spec is 738 pages. It is basically a heavily commented XML schema. Although I find XML hideous, I can understand how the entries represent the elements of a recursively defined wff in some formal language. I would cringe at the idea of trying to map it all to the RM. The integrity constraints would be horribly complex. Received on Tue Oct 28 2008 - 06:49:33 CET

Original text of this message