Re: Onto a potential relational manipulation language

On 12 déc, 17:55, vadim..._at_gmail.com wrote:
> On Dec 12, 2:16 am, Cimode <cim..._at_hotmail.com> wrote:
>
> > I am curious.  What do yo mean by assertion?  Are you refering to ra
> > predicate boolean logic?  When you say that the purpose is verify that
> > an assertion is a valid theorem in RL, what do you call a *valid
> > theorem*.  Thank you ellaborating on this last particular point.
>
> Well, it is sloppy language on my part, nothing more. "Assertion" is
> widely used in computer language, while first order logic term is
> "sentence". This is why sprinkling examples here and there helps
> communication a lot. When I write
>
> a ^ b = b ^ a.
>
> people don't ask if it is an assertion or sentence.
I understand now what you are refering to. This terminology clarification reveals that we are not refering to the same thing. Having a mathematical bias, I prefer using the term *equation*. In the context of the computing model and subsequent programming language I am working onto, the *equation* is solely embodied as the ability by the system to represent a relational operation and represent its output as another relation in a way that avoids previous mistakes made (biggest one being TTM). The example you have provided is not the layer of a computing model but on RM research. Therefore I can not comment any further as we are not refering to similar work.

> > As I mentionned in the response to paul c, the
> > computing model and subsequent implementation main purpose is relation
> > level manipulation and operation not tuple level.
>
> Well, RL manipulates with relations as they are unstructured entities.
Could you clarify what your mean by *unstructured entities*. Do you mean sets?

> There is no reference to attributes and tuples -- relation structure
> is captured in axioms. However, we don't know complete axiom system
> for RL. QBQL serves as a tool to semantically validate RL sentences
> and thus have to leverage relation structure (as a set of tuples).
I am beginning to understand your logic. Thank you for clarifying. The RL logic I am exploring does not validate what you call *assertions* with a tuple based granularity but rather makes use of domains intervals to represent a relation and therefore operate it as a part of an equation.

> > Relation operation and traditional boolean logic are not mutually
> > exclusive concepts
>
> There is established Logic <-> Algebra correspondence. For
> propositional calculus we have boolean algebra. What algebra do we
> have for predicate calculus? None. I'd suggest that RL is predicate
> calculus without quantifiers and relation attributes.
I am curious as to why you would assume that only predicate calculus would be sufficient to clarify operations in RL, in a way they can reasonnably be implemented? Why would you assume that creating an algebra for predicate calculus is a sufficient condition to clarify RL operations. I have been exploring this possibility for years and found it rather limitative to define RL effectively. I have used and am still using other mathematic tools than algebra such as combinatory analysis and probabilism to allow further verification and rediscovery of previous work. Among other things, this alternative allowed me to formalize the consumption of ressources on a direct image system as relation cardinalities become infinite. That formalization also allowed to design a storage mechanism that allows to decorrelate consumption of IO resources and relation cadinality at run time.

> > > (((Peter ^ Parent) v Relationship) ^ (Max ^ Child)) v R00 = R01.
>
> > I do not quite see the relation between the example posted and the
> > example you provided.  Please explain why you see a relationship?
I understand. Thank you for providing this clarification. You are right you really did *hack* this thread. But thanks for doing so, as it did allow to point out some interesting aspects that were (and still are) a great challenge to me in the computing model I am trying to set up.
[Snipped] Received on Sat Dec 13 2008 - 13:29:44 CET