Re: Expressions versus the value they represent

From: Keith H Duggar <duggar_at_alum.mit.edu>
Date: Mon, 12 Apr 2010 08:35:33 -0700 (PDT)
Message-ID: <e8bbb80a-355b-4ace-a18b-45be210984dd_at_c1g2000vbc.googlegroups.com>


On Apr 12, 7:09 am, David BL <davi..._at_iinet.net.au> wrote:
> On Apr 12, 2:37 pm, Keith H Duggar <dug..._at_alum.mit.edu> wrote:
> > Hopefully we can agree that since there is no interpretation defined
> > in the RM nor FOL that there are not "multiple phases" nor "playing
> > around" nor any other of the problems above.
>
> Yes I agree with that, but I actually want to consider the problems
> that arise under interpretations.

Ok, cool. Thanks for this and the other clarifications. Now I'm a bit clearer on understanding what you are exploring. However, are we agreed that in the context of RM this is what we would call the "physical" layer?

For example, suppose that we define a particular interpretation that maps the ellipse and circle terms to particular structures say sets over which we define various other axioms (perhaps even including axioms referring to natural (as in physical world) observations. Then I would argue that even though these sets are not bits and bytes they are, none-the-less, "physical" in so far as the RM is concerned. Would you agree?

> > > 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).
>
> > That is a contradiction. You claim the term circle(...) is "NOT a
> > circle!" then immediately claim that a "circle [is a] /function
> > symbol". Note that in both claims you used the 6 letters "circle".
>
> It's not a contradiction if you allow for the word "circle" to be
> overloaded (which I thought was obvious). I should have used
> different names for the symbols to avoid confusion. E.g. I could have
> said:
>
> In FOL the expression c(p(0,0),1) is called a /term/.
> It is actually a ground term because there are no
> variables. It is NOT a circle! c and p are
> /function symbols/ of arity 2. 0 and 1 are function
> symbols of arity 0. Terms can nest (e.g. 0, 1 and p(0,0)
> are all terms).

Agreed. However, that is an important clarification because now I may clearly ask that you define "circle". Mostly likely in a FOL-only discussion it would remain undefined as just a symbol. But, as is now clear, you are aiming instead at some, as yet undefined, interpretation. That's what was not clear to me in the original post.

> > > 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.
>
> > What is the point here? If we are talking about a multi-sorted FOL
> > then those two terms have distinct types. If either is equal to some
> > other expression say "UnitCircle()" or whatever, then that must be
> > derivable from the stated axioms and type definitions.
>
> Actually I was considering single sorted FOL with equality. Sorry for
> not being clear.
>
> My point was that under interpretation, distinct terms can represent
> the same value. This leads to an equivalence relation on terms. I was
> actually thinking about an analogy to the D&D type system (where
> circle is a subtype of ellipse).

Ok.

> > Anyhow, interpretation is
> > orthogonal and therefore irrelevant to both FOL and RM.
>
> I agree. However I consider the topic of my post to concern the
> problem of how to encode values on a computer, in which case a formal
> semantics is required.

Got it.

> Perhaps it would be worth discussing whether that is a fundamental
> requirement in database theory? I consider "data" to mean "encoded
> value".

Hmm ... interesting question. I'm guessing, and this truly is a guess, that in the larger context of "database theory" the answer is yes. In the smaller context of "relational model" the answer is no. I hope one of the "regulars" will correct and expound on this.

> > > 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.
>
> > Well fortunately the RM does not "see" them as abstract values.
> > It "sees" them in exactly the same when they are "seen" in FOL,
> > as terms, as expressions, they may or may not have a type. So,
> > we are in luck: the RM does not in any way limit the expression
> > of such clauses.
>
> I'm not sure what you mean. What are you suggesting is the equivalent
> of nested terms/expressions in the RM? I assume you mean relation or
> tuple valued attributes.

relational algebraic expressions or "views" of which relations with RVAs are a subset.

> If so I would say we are in luck in one
> sense but badly out of luck in another.
>
> As I think you suggest, we are in luck because it is possible to
> manipulate the nested "expressions" transparently without any
> limitations.
>
> I think the problem is how to define a formal semantics, such that
> under interpretation a relation or tuple is able to encode something
> else (e.g. an image, string, triangulated surface etc). More
> importantly, how is the equality operator which can be regarded as
> predefined on relations and tuples somehow overridden to comply with
> the interpretation? Also note that the RM operators are defined in
> terms of equality of attribute values. So which version of equality
> is used on RVAs?
>
> An interpretation on nested terms is very simple and elegant.
> Equality can be treated as a predicate symbol. How is an
> interpretation defined on nested relations?

Ok, let me make sure I understand this correctly by making up a concrete example. Suppose for example I have a relation with a DirectedGraph attribute where DirectedGraph is a relation valued attribute with header {NodeA : Node, NodeB : Node} under an interpretation "there is an edge from NodeA to NodeB".

Now given those choices the question arises how to define "equality" because The RM already defines a strict equality for relations which would/could be applied to these RVAs but under our interpretation we may require that "equality" instead be defined as graph isomorphism.

So it seems we have a problem of how to "override" the equality operator (say "=") such that it is consistent with our desired semantic interpretation.

Is this what you mean?

KHD Received on Mon Apr 12 2010 - 17:35:33 CEST

Original text of this message