Re: Modeling question...

On Oct 29, 8:26 am, JOG <j..._at_cs.nott.ac.uk> wrote:
> 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?

I understand what you're saying. However I personally find recursive data types very intuitive and useful so if I consider /myself/ as a user of a DBMS, a restriction to the RM feels like one hand is tied behind my back.

I'm interested in the storage and management of compound documents, scene graphs and so on. I cannot imagine doing without recursive data 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.
>
> 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).

I agree you don't need recursive types to model statements of fact. However I don't consider data to necessarily be regarded as a bunch of propositions. We have had this argument before!

Remember when I said that I regard a recorded poem as just a value, not a proposition? A CD containing a single text file that is a poem could I guess be construed as a single proposition as a claim of its own existence! But I regard such a claim as metaphysical and therefore meaningless. Alternatively the proposition could represent the real claim that that /particular/ CD records a poem. It would seem silly to try to make that proposition explicit by recording additional encoded values on the CD. For a start that would make it more difficult to copy the data to another media. So if the proposition is implicit - and you don't see it directly in the recorded data then I suppose you could say that the "actual recorded data" is an encoded string value whereas the "data" is a proposition. Do you think this distinction is useful? I don't!

What's wrong with defining "data" to mean "encoded value(s)" rather than "encoded fact(s)"? Note that the former encompasses the latter because a relation is a value.

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

Yes, but "tried it" is a fair description.

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

I don't agree that the term "database" should imply it is only concerned with storing facts. A new term is required: "factbase" :)

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

I agree that you don't generally need to records facts about wffs. Our point of disagreement seems to stem from the meaning and scope of the word "data".

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

Ok, I think we mostly agree with each other. Received on Wed Oct 29 2008 - 02:51:40 CET