Expressions versus the value they represent

In FOL the expression circle(point(0,0),1) is called a /term/. It is actually a ground term because there are no variables. It is NOT a circle! circle and point are /function symbols/ of arity 2. 0 and 1 are function symbols of arity 0. Terms can nest (e.g. 0, 1 and point(0,0) are all terms).

The term ellipse(point(0,0),1,1) is distinct from circle(point(0,0),1) even though we may regard them as both encoding a unit circle.

In FOL one distinguishes between a term and what it encodes under an / interpretation/. Under an interpretation function symbols become functions. For example, let circle(c,r) be a function that maps point c and number r to a circle centred at c with radius r. i.e.

  circle(c,r) = { (x,y) in RxR | (x-c.x)^2 + (y-c.y)^2) = r^2 }

Terms can be seen as a way to encode values that would otherwise be impossible to directly represent on a computer. E.g. a circle is uncountably infinite.

What interests me here is the question of whether or not it is appropriate for a formalism underlying database theory to distinguish between terms and the abstract values they encode under interpretation. At stake is the ability to express ideas such as the following clause in Prolog, which states for example that the term 3+4 should be simplified to the term 7:

simplify(X,Y) :- Y is simplified version of X simplify( plus(num(X), num(Y)), num(X+Y) ).

Obviously one cannot satisfactorily manipulate expressions if they are only seen for the abstract values that they encode.

I note that a D&D /selector/ for type CIRCLE is like a function that returns an abstract circle value (e.g. already interpreted and ready to be stuck into a relation). It seems implicit with the RM that there is no concept of interpretation (or putting it another way, interpretation has already taken place). A relation or tuple value encodes nothing other than itself. So to for the attribute values of any given tuple.

One of my main motivations here is to question the whole premise behind RVAs, which I have assumed are used to /encode/ attribute values within parent relations. I don't believe the RM should be allowed to play around with interpretation after the fact. Having multiple phases of interpretation seems extravagant, unnecessary and ill defined to me. I think FOL can encode all imaginable data types effectively using nothing more than nested terms with a single interpretation step.

The FOL distinguishes between function symbols and predicate symbols. Under interpretation a predicate symbol becomes a boolean valued function, which is the indicator function of some given relation. If this is how the RM is meant to fit into the picture then it seems inappropriate to use relations to somehow encode the values that are normally encoded by FOL terms. Received on Mon Apr 12 2010 - 07:13:34 CEST