Re: Modeling question...

On Oct 28, 5:49 am, David BL <davi..._at_iinet.net.au> wrote:
> [snip]
> > > 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).

Hi David. This is still putting the cart before the horse as far as I'm concerned. Once you say there are "types", and they are "recursive", you have already created a model in your head. Trying to then squash that model into the RM is bound to cause problems. A book does not contain recursive types as. Saying that they do to someone in the street and they'll think you're loopy-loo right?

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

What was wrong with the method I suggested of just copying how you describe things in real life? And then just representing that in predicate logic? I don't need recursive types to model statements of fact (although I would agree recursive queries/constraints are extremely valuable).

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

You'd like Haskell - have you tried it?

>
> 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
> > proposition...it can be encoded as a tuple in RM.
>
> I agree that statements about things are well suited to the RM.

Statements about things is what all databases are concerned with, not just the RM. Anything else is out of its remit. Its function is to model facts, not values such as equations. I certainly wouldn't use it to model something like a car engine schematic either (but facts about that engine... yes!).

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

Why would you want to record facts about wff's instead of, well, just using them for things? I can't imagine the application at the moment <scratching_head/>.

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

Not a formula - it is not a datum (as meant in the term database), just a value. However, a grammer such as a BNF, yeah I can. Very much so in fact, because it consists of rules which are statements of fact. I think we should give it a spin ;)

>
> 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 Wed Oct 29 2008 - 00:26:42 CET