Back | Home | Next

Relations

ANNA  K5

@

Home
Glossary
Objectives
Formalism
Morphology
Physiology
Connectors
Serialization
Traits
Methods
Claims
Relations
Dictionary
Core UML
Ring1 Apps
Tiger Server
Features
History
ToDo
Authors
API
Images
ToDo
DNA Declarations
Physiology RO
Real Time RO
ANNA as an Eco System RO
HMM Generator
ERP

 

Node, Line, Selector, Type, Relation, Operator

Lines exist in the Morphic Operating System only as instances of OPERATORS.

Binary Relations generate Selectors

  1. A NODE:

N

  1. A unary connector:

S

  1. A binary connector

 

c

  1. A diagram combining three nodes N1, N2 and N3 with one binary connector L and one unary connector S:

 

N1

N2

N3

L

S

 

  1. A ternary connector:

S

1

2

3

 

Discussion.

  1. (Important) An instance of a type has an effect into the design space of the Morphism System, which is the NODE, and another effect into the user space, which is a Constant. Between the two there is a unidirectional relationship NODE to data through the NODE’s handle.
  2. (Important) The user data has no pointer back to the design space and reverse Correlation data to NODE is ensured by the System’s Morphic Memory Manager.
  3. A Type relates to other types through Relations and Operators.
  4. An instance of  Type is a NODE in the design space and a constant in the data space. The size of the constant is determined by the relations of the Type.
  5. A generalized connector is a NODE with any number of endpoint Femurs.
  6. A Relation has a connector.
  7. A relation with a connector that has no endpoint looks like a Type because it generates NODEs, but it is semantically different as it generates voids. All relations with no endpoints are equivalent to the Void type.
  8. A Selector is an instance of a Relation.
  9. (A[2],B[3]) R is a relation R linking two A instances to 3 B instances. A selector of R like $[1,2] precisely determines a pair of (A,B) instances, whereas $[1] is undetermined. To precisely determine a pair another selector will be needed, or an Instruction. If A and B are complex types then sub-selectors will be needed. Current approach is to contain the sub-selectors of A and B within the selector of R. Another approach would be to enhance the notion of a Selector with femur endpoints. In this case Selectors become Connectors and K5.V11 reverts to the evaluator version. In this model there is no difference between Relation and Operator, a highly desirable option.
  10. (???) A Selector may have to link to other selectors. Ex: a bi-dimensional matrix of points. A selector to a certain element may build based on two other selectors. point M[m][n]; M[2][3].x is an expression built with nested selectors. A ternary relation: R (A[2] B[3] C[5]); R[i,1,0] is a partial selector.
  11. A Selector has an effect in the design space and an effect in the data space.
  12. The effect of a selector in the design space is a NODE.
  13. The effect of a Selector in the data space is an (index,flags) pair. There NODE aspect of a selector points towards the index+flags pair of the data space through the NODE’s handle. There is no backward link. The backward correlation is ensured by the MMM.
  14. A Selector is owned by a Scope.
  15. The scope ownership of a selector should be free of semantics.
  16. A relation with a connector with one endpoint T is a self relation of type T.
  17. A relation establishes a Cardinality and attributes for each endpoint of the Connector.
  18. A binary relation is one whose connector is a line. Such a relation establishes a cardinality for both endpoints. Relation R links n elements of type T to m elements of type S. Such a relation needs two dialers to determine a selector.
  19. A relation with no endpoints needs no dialer to establish a selector.
  20. A relation with one endpoint needs one dialer to establish a selector.
  21. A relation with endpoints needs one dialer per endpoint to establish a selector.
  22. A selector is a node with a data tag of as many indexes as relation endpoints.
  23. An Operator instantiates Connectors in the design space and Instructions in the data space. A Connector links to the corresponding instruction through the Connector’s handle. Backward correlation is ensured through the MMM.
  24. An Operator has a Connector that defines the endpoints of the Operator.
  25. Operators of 0,1,2 and more endpoints are possible in the Morphism System.
  26. A Connector is a NODE followed by 0 or more STREE endpoints (Femurs).
  27. A Connector of 1 endpoint is a cross-reference. They are used in self relations.
  28. A Connector of 2 endpoints is a LINE.
  29. A Connector of 0 endpoints generates an instruction with no operands (Ex: LOADALL, STC, on Intel CPUs)
  30. For each endpoint of the Operator, an operand of (index+flags) is generated into the data space.
  31. Differences:
    1. Type vs Relation: Type generates NODE in the design space, and constants in the data space. Relation generates NODE in the data space and index+flags table in the data space.
    2. Type vs. Operator: Type generates NODE in the design space, and constants in the data space. Operator generates Connector in the data space and Instruction+operands in the data space. Operands are index+flags.
    3. Relation vs. Operator: both generate an index+flags table in the data space. Operator also generates an Instruction into the data space. A Relation generates a NODE in the design space and the Operator generates a Connector in the design space. A Connector is more than a NODE.
    4. Node+Constant, Node+Index table, Connector+Index table
  1. Degenerate cases: an Operator that doesn’t generate an Instruction has the same effect into the data space as a Relation. An operator that doesn’t have any endpoints behaves like a Relation with no endpoints, which in turn behaves like the Void type.
  2. A Selector may be nested in the scope of another selector.
  3. When A->B->C is a chain of 2 relations r1 and r2, and a an instance of A, a->r1->r2 is a nest of 2 selectors $1 and $2 with $1 selecting r1 within a, and $2 selecting r2 within r1. Therefore, $1$2 establishes a path from a to C over r1 and r2.
  4. The scope of selectors has a semantic role. Would be nicer otherwise, as selectors may be freely moved to another scope without loosing/changing their meaning.
  5. A relation R from T to T needs a unary connector of T.
  6. A relation R from S to S needs a binary connector from T to S.
  7. Unary connectors are Selectors.
  8. Binary connectors are Lines or Wires.
  9. Ternary connectors are TEEs.
  10. We introduce no new names for higher order connectors, so they'll be called "quaternary connectors", etc.
  11. A TYPE generates NODEs so that all objects of the Morphism System may belong to a hierarchy converging to the system's Nucleus.
  12. Any type that doesn't descend from NODE is abstract.
  13. Instances of abstract types are templates (in the sense of default value sets).
  14. If a Type has a Connector to one other Type, then its instances will also be Connectors.
  15. The Type that has connections to other types is a Relation.
  16. The Type aspect of the Relation is called a Field of that relation within the owner of the relation.
  17. The owner of the relation makes use of the relation by acting on its Field.
  18. A type that has more than one connection to other types would instantiate connectors of a higher order, namely: Lines, Tees, quaternary connectors, etc.
  19. The maximum order of the connectors that a Type generates is the maximum number of that type's connectors.
  20. Not all of the connectors of a type will be reflected in the generated connectors for that type. A type, for instance may have 3 connectors to 3 other types, yet generate a binary connector.
  21. A Connector is more than a Node with the addition of a vector of STREE structures called endpoints.
  22. A TYPE is more than a Connector with the addition of instance information.
  23. A Type that has a unary connector to another type is a binary relation.
  24. Binary relations generate Selectors or unary connections.
  25. A selector s is a unary connector between a type T and a relation R from type T to type A, in the scope of another type S. The selector is also an instance of the relation R.
  26. We have to also accept selectors to types, not just relations.
  27. S

    T

    A

    R

     

    c

     

    s

    The selector s is a unary connector owned by S with endpoint T. The selector is therefore an object that links S, T, and R together.
  28. The handle of a selector is the index into the target relation.
  29. Through selector s, S gains access to a certain aspect R of T.
  30. s is to S what c is to T.
  31. A relation is a logical and physical unit made of a Type together with all its owned selectors.
  32. R is a field of type T, and an image of A into T.
  33. R is owned by T.
  34. A selector c may be owned by a different scope than R.
  35. A selector c may be owned by another connector.
  36. The owner connector is a Cable.
  37. Cables may own any Node type, including other cables, and even Types.
  38. The link between c and R is one of solid structure containment.
  39. Selector s is not contained.
  40. c was generated by a relation outside the scope of this discussion, in the same manner as s.

 

  1. A selector equates to the following expressions:
    1. "Source selects a Destination for a Scope through Selector".
    2. "R selects A for scope X through c", and
    3. "T selects R for scope S through s."

 

X

T

R

c

S

A

s


 

  1. The following figure illustrates the 4 different types of relationships around a unary selector $, which characterize and define it:
    1. Selector $ belongs to the scope hierarchy X.
    2. Selector $ has an endpoint to destination type D
    3. Selector $ is contained by type S.
    4. Selector $ is an instance of type T.

X

T

D

S

$

  1. A selector is "a place in the Morphic System".

Serialization

The notion of interdependent versus independent systems is discussed at Formalism.

Two systems L and R are interdependent and disjunctive, which implies the existence of another system E called the Environment of L and R. For the following discussion we consider L, R and E. L has subsystems A and F. Subsystem A is made of B, C, D, and E. Subsystem F is made of G. D has a link to G and E to B.

E

R

L

F

G

b

a

A

B

D

C

E

i

E's link to B is inbound to reference system A, whereas D's link to G is outbound to A.

Both links are inbound to reference system L, and totally foreign to R. Line b exists as discussed in section SSS to support D's link to G. Line i exists to support E's link to B.

 

We now pose the following problem: store system A into system R. Since this operation is not the same as moving A into R, we have to resolve the following problems:

  1. Cloning A to A', and each subsystem of A to subsystems of A'.
  2. Clone all internal links of A such as i to i'.
  3. Clone any outbound references of A such as a and b to a' and b'.

This process is called serialization

d

e

f

E

R

A'

B'

D'

C'

E'

L

F

G

b

a

A

B

D

C

E

i

Read more on serialization.

 


Relation definitions

Scope children of S may be:

1.      Unrelated sub-scopes with no size impact onto S.

2.      Relations of S in one of the general forms S.r:A*B inducing size as described.

3.      FROM relation endpoints of relations that may induce size

4.      TO relation endpoints of relations that may (but never does) induce size.

The following table describes all fundamental binary relations of the general form S.r:A*B where r is a relation in scope S from A to B.

 

Size evaluation is l2r

Nr

Relation

Description

B

r

A

S

1

S.S:S*S 

Null scope relation

 

 

 

-

2

S.S:S*A

Scope auto-definition

 

 

-

+A

3

S.S:A*B 

Scope definition

-

 

+B

-

4

S.S:A*S 

Scope Will

 

 

+S

-

5

S.r:A*B

Containment

-

-

+B

+r

6

S.r:A*S 

Contract

 

-

+r

+r

7

S.r:A*r 

FROM auto-relation

 

-

+r

+r

8

S.r:A*A

Fractal

 

-

+{A}

+r

9

S.r:S*A 

Has

 

-

-

+r+A

10

S.r:r*A

TO auto-relation

 

+A

-

+r+A

11

S.r:r*r 

Auto Fractal

 

+{r}

 

+r

12

S.r:S*S 

Scope Promise

 

-

 

+r

 

There are several types of relations in the morphic system as follows:

  1. S.S:S->S is the null auto-relation. Since this relation is of its own scope, it defines the beginning of an independent morphic entity, a cell, or a clone. All morphic systems start off as null auto-relations. This relation also has the properties of the (6) registration relation.

  2. S.S:S*A Scope TO auto-definition induces A into S.

  3. S.S:A*B Is a scope definition.

  4. S.S:A*S Scope FROM auto-registration induces S into A.

  5. S.r:A*B R is a relation in scope S from type A to type B. This kind of a relation is the most general case that describes an induction of B space into the substance of A under the control of S. Scope S owns and dials the relation.

  6. S.r:A*S R is a relation in scope S from type A to type S. S owns and dials the relation, allocates space for it. S induces space into A. R is a "registration" relation. As more such relations S.Rn:N*S are born in the system, S grows to hold the registration of each relation Rn. With each new relation added, all previous N-1 types that depend on S also grow. These registered types know one another.

  7. S.r:A*r R is a FROM auto relation in scope S from type A. This kind of a relation describes an induction of R space into the substance of type A and of A into S. This relation is an inclusion of A into S. R is self described. S owns, dials and allocates the relation.

  8. S.r:A*A Self-relation much like STREE{ STREE*STREE.Next } R Induces a fractal upon A, and as such it must be depth limited. Scope S owns,allocates, and dials the relation.

  9. S.r:S*A R is a relation in scope S from type S to type A. This kind is the most common to users. Type S owns and dials the relation, and allocates space for its inprint. These are relations of "free-will".

  10. S.r:r*A R is a TO auto relation in scope S to type A. This kind of a relation describes an induction of A space into the substance of the relation itself. This relation is an inclusion of A into r and of r into S under the control of S. R is self described. S owns and dials the relation, and alocates space for it.

  11. S.r:r*r R is a fractal auto relation in scope S. This kind of a relation describes an induction of R(6) space into the substance of type R and of R into S. This relation is an inclusion of R into S. R is recursively self described. S owns, dials and allocates the relation. R is recursive and should therefore have previous or following members, as well as a determined fractal depth count. If R doesn't have previous or following members, then it is void. This is the true nature of the Void type in the Morphic system.

  12. S.r:S*S Scope self-registration adds r to scope S for dialing.
     

Types of relations of scope S that affect its size, based on the previous definition.

Nr

Ord

EP

Relation

Description

Size(EP)

 

1

r

S.S:S*S 

Null scope relation

-

 

2

r

S.S:S*A

Scope auto-definition (1)

+A

 

3

r

S.S:A*B 

Scope definition

-

 

4

r

S.S:A*S 

Scope Will

-

1

5

r

S.r:A*B

Containment

+r

2

6

r

S.r:A*S 

Contract with A

+r

3

7

r

S.r:A*r 

FROM auto-relation

+r

4

8

r

S.r:A*A

Fractal

+r

5

9

r

S.r:S*A 

Has (1)

+r

6

10

r

S.r:r*A

TO auto-relation (1)

+r

7

11

r

S.r:r*r 

Auto-Fractal (1)

+r

8

12

r

S.r:S*S 

Scope Promise (1)

+r

 

1

from

S.S:S*S 

Null scope relation

-

9

2

from

S.S:S*A

Scope auto-definition (2)

+A

10

3

from

B.B:S*A 

Scope definition

+A

11

4

from

A.A:S*A 

Will of A upon S

+A

12

5

from

B.r:S*A

Containment

+A

13

6

from

A.r:S*A 

Contract with S

+r

14

7

from

A.r:S*r 

FROM auto-relation

+r

15

8

from

A.r:S*S

Fractal induced by A

+{S}

16

9

from

S.r:S*A 

Has (2)

+A

17

10

from

B.S:S*A

TO auto-relation (2)

+A

 

11

from

A.S:S*S 

Auto Fractal (2)

+{S}

 

12

from

S.r:S*S 

Scope promise (2)

-

 

 

Hit Counter Created on 05/27/2009 06:33:55 AM, modified on 05/27/2009 06:33:55 AM

Home
Various representations of relations

Home | Feedback | Contents | Search

Send mail to webmaster@ProximaCentauri.ro with questions or comments about this web site.
All principles and artwork exposed on this site or by our software products is our intellectual property. 
Copyright © 2006 Proxima Centauri Romania SRL. Last modified: 05/27/09