An s3db operator,

*f*, is a discrete variable with a set of

*n* ordered states. The elements of the set can exist in two different forms, a upper case or dominant form,

*Φ*, and a lower case or recessive form,

*ϕ*. For example, the capital form of the i

^{th} state of the operator

*f*, would be represented as

*Φ*
_{
i
}, where

*i ε[1,..., n]*. Accordingly, the description of such relationship between a user and some

*s3db:entity* is defined using the state of the operator, as represented in Equation

1:

The three functions described below, merge, migrate and percolate, are used in the resolution of state propagation between data elements. That description is best followed by testing different scenarios using the accompanying tool at http://s3db-operator.googlecode.com.

#### Merging

As illustrated in Equation

1, for each user,

*U*, and for each instance,

*E*, of any of the seven types of

*s3db:entity*, the nature of the relationship can be described by an arbitrary number of states of the operator

*f* , by simply declaring the

*{U f E}* triple. However, regardless of such statements having been made between a User and an Entity, the

*f* state assigned as predicate in those statements is not necessarily the effective state of that relationship. Other states may also be indirectly asserted to the relationship by directly assigning them for relationships with entities upstream of the target entity. The resolution of what state is effective for the relationship between a given

*U* and

*E* is resolved by merging all the assigned states, directly or indirectly, as defined in Equation

2. In this equation,

*A* is the vector of indexes of assigned dominant (upper case) states,Φ; and

*a* is the index vector of assigned recessive (lower case) states,

*ϕ*. As for the other definitions, the behaviour and implementation of merge can be verified using the accompanying tool at

http://s3db-operator.googlecode.com.

The numeric indexes of the vectors *A* and *a*, are integers between 1 and n. However, because numbers are symbols with no upper and lower case, it is easier to represent the resolution of Equation 2 using the alphabetic indexes instead. The argument for using alphabetic indexes is that their case can distinguish between a dominant and a recessive merged state, therefore allowing *a* and *A* to be represented together as a single vector. Two illustrative examples - for an operator with three states indexed as {'b','c','d'}, merge({'b','c','d'}) = merge('d') = 3 and merge({'b','c','C','D'}) = merge('C') = 2. The case of the merged state, 'd' and 'C' in the example, is of no consequence to the operator itself, which will respond only to its position in the ordered state vector, 2 and 3 respectively. If, in this example, the operator was something like *view_query_results()* and the index of the ordered states were {'noView','theCountOnly','yes'}, the result of the first merging might be returned as 'yes' and of the second as view 'theCountOnly'. However, if further operations are to be made on the merged result then the case of the merged state is important and needs to be retained. It is patently easier to return 'd' and 'B', or even 'yes' and 'THECOUNTONLY' than to have to specify that the merged i = 3 was a recessive outcome, whereas i = 2 was dominant, and as a result the state index 2 > 3 when Equation 2 is used.

#### Migration

The direction of the relationships between S3DB entities (Figure

2, Table

1) was conveniently defined to be the same as the propagation of operator states from domain to its instantiation (note inversion of

*rdf:subject*,

*rdf:predicate* and

*rdf:object* in relationships 5-10, Table

1). This allows the definition of a Boolean transition matrix, Equation

3, that can be applied to any instance of one or more of the seven types of s3db Entity,

*E*, ordered using their initials as

*[D, P, C, R, I, S, U]*. The numbers between brackets in the transition matrix indicate the logical tests (as numbered in Table

1) that individual instances of the seven types of entities can have between each other (Figure

2).

As described in Equation

4, this simplifies the computation of the transition of states between entities as the external product of the corresponding Boolean square matrix and the vertical vector of states assigned to each entity. For example, if a state of a

*s3db:operator* is used to describe a User relation with a certain

*s3db:collection*, and this Collection happens to both have Items and to be the Subject of a Rule, then this state will be passed to those Rules and to those Items, using relationships (4) and (5), respectively.

The process by which states are passed from one instance of an entity to another before being merged at the end of each iteration (Equation

4) is designated as state migration and is described in Equation

5. The simplest example is the migration of a singular state - if the state of an instance of a

*s3db:entity*,

*E*, is described as a singular value, say 'a', then 'a' will be passed on for the relationships verified in Equation

4. However, if the state of the operator,

*f*, is described by more than one value,

*l>*1, then the additional expressivity in state propagation can be achieved, as described by Equation

5. That generalization consists of specifying that if a state is singular (

*l =* 1), then it will be passed as is. If, on the other hand, it is plural, then the first state is used as the effective state of the subject entity and only the remaining states are passed on to the entity that is object of the valid relationship, as described in Equation

5. For example, starting with singular migration, if the state of an instance is 'a', and this instance is subject of one or more of the 12 relationships (Table

1), then the object state will merged with the migrated state 'a'. However, if the subject instance has a plural state, say 'abCd', then only 'bCd' will migrate. Note that both dominant and recessive cases are considered in the vector

*f* in Equation

5.

One last generalization of the migration process was also found to increase expressivity. The procedure described in Equation

5 was vectorized to allow simultaneous migration of states of multiple s3db operators. This is achieved by defining a second input argument for the

*migrate* procedure which identifies how many operators

*f*
_{
j
},

*j = 1,...,m*, are having their states migrated simultaneously. Since the states of each operator define m-tupples inside the state of

*n* states, this is equivalent to identifying the migrating states of

*f*
_{
j
} as being

*f*
_{
j
}
*=f[i,i+m,i+2 m,i+3 m,...,n*m]*. Accordingly, Equation

6 is equal to Equation

5 when m = 1, that is, when only one operator is being considered.

The enhanced expressiveness of the representation of multiple operator states described in Equation 6 is most useful for s3db operators that share the same states. For example, states that identify groups of users could be used as the states of multiple operators such as "view" and "edit", as is the case for the S3DB prototype (see Methods). As can be verified in the tool accompanying this manuscript, the multiple state migration allows for very short descriptions of states that span multiple operators. For example, migrate('a',3) = 'aaa', which allows for a single assignment that spans several operators. This is achieved without affecting the migration of individual statements - for example migrate('abc',3) = 'abc'- while at the same time allowing for a sweeping assignment of migrated states as in migrate('abcb',3) = 'bbb'. Note also in Equation 6 that when a operator state at position *i* is not specified, it is borrowed from the operator immediately to the left, position *i*-1. This implies that the order of the operators can be used to simplify assignments that just span a subset of them, as in migrate('abcbc',3) being 'bcc'. As always, the behavior and implementation of this functionality can be verified using the accompanying tool.

#### Percolate

The third and last function used by the state propagation procedure brings together the merge and migration functions to find the steady state solution of Equation

4. That is, when the migration of states, Equation

6, has progressed to the point where the effective state of the operator, for each and every s3db entity, no longer changes:

In the accompanying web tool this resolution is made available for any Boolean transition matrix. Although for the specific purposes of the S3DB prototype, the transition matrix *T* in Equation 4 is equal to *TS3DB* in Equation 3, there is no reason not to define, and test using the tool, the percolation of s3db operator states more broadly for arbitrary transitions.