Re: Modeling question...

From: paul c <>
Date: Tue, 25 Nov 2008 17:41:53 GMT
Message-ID: <BNWWk.224$si6.191_at_edtnps83>

David BL wrote:
> 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:
> 1. Using recursive RVAs; or
> ...

Without getting into whether "recursive RVAs" are actually possible, whenever I've written programs I've always been struck by the old wisdom that certain structures make the mental explanation of the job easier. But regarding theory, one question I have about such a structure is whether it can logically stand for a reasonable predicate. A simpler structure I've brought up before is this:

R{a int, b typeof(R)}

(Here, "typeof" is a language gizmo that stands for a type that is the same type as R's type.)

If R's extension can be loosely pictured like so, where the string "a b" stands for a conventional heading, R has one tuple and the "first" b has one tuple and the second "b" has no tuples:

a b

   a b
1 2 {},

I might refer to the value 2 which is of type int (as opposed to the value (2 {}) which is a value of a relation) with another gizmo such as "b.a". A predicate for this might be "a plus 1 equals b.a".

To my way of thinking, no matter what predicate or relation we decide stands between a and a.b, there must be another predicate that involves a and b, say for example's sake, "b is the set of tuples that have 'a' values that are numerically larger than the value of a".

One problem I have with talking about RVA's for this example is that I can't get very far with a notation that might need to look something like a.(b.a(b.a(b.a(b.a)))) when writing a query to find out if the number 5 has such a tuple, in other words "is the integer 5 greater than the integer 1?".

The thought that keeps recurring (ha, ha) to me is that if any of the above is reasonable I would need a different notion of projection than the conventional one, one that allows me to to see a relation that involves the "second" predicate. Graphically, let me write it like so:

a b.a
1 2
1 3
1 4
1 5
2 3
2 4

P would be easy to query (ie., not cumbersome) using conventional RM theory. It makes me wonder if there is a way to see conventional non-recursive relations as being a special case of recursive ones.

Eg., as far as syntax goes, I can't think why I shouldn't be able to express P as "R{a,b.a}". This is different from "R{a,b}" which expresses identity in the conventional way, ie., "R is equal to R{a,b}" whereas in P, "a" ranges over all "b.a's" but not all "b.a's" range over all "a's". In terms of practical results, I suppose the "b.a" notation is not much different from introducing a "tclose" operator. For some reason I can't explain very well, I find it more appealing to express structure than to express procedure.

Sometimes I also wonder whether conventional projection is too simplistic even for non-recursive relations. There is always an unwritten second operand, the complement of the attributes that name the chosen projection. When people like Fabian P talk about "R-tables", it seems to me that sometimes they don't want that second operand to always be the same complement.

(Maybe part of the reason is that the RM puts so much emphasis on the logical structure of data (which seems under-explored and widely ignored to me, at least in the mainstream press, eg., hardly anybody writes about the logical use of material implication for certain kinds of constraints.)

Just trying to keep things going here ... Received on Tue Nov 25 2008 - 18:41:53 CET

Original text of this message