Starting with PCM, which models the physical world, these models show how elements of abstraction can be successively layered in top of the basic ideas in a way which links back to the physical world. The models are built on interactions and different types of connection between entities, so first we include some definitions which support the development of the ideas.

#### 3.1. Definitions

Call a slice a contiguous subset of space-time. A slice can correspond to an entity at a point in time (or more properly within a very short interval of time), a fixed piece of space over a fixed period of time or, much more generally, an event which moves through space and time. This definition allows great flexibility in discussing information. By using slices rather than space and time separately we can apply a common approach in different cases. For example, slices are sufficiently general to support a common discussion of both nouns and verbs, the past and the future.

We also use the following to describe the physical world:

properties: each slice has a set of properties and for each property there is one or more physical processes (which we call measurement) that takes the slice as input and generates the value of the property for the slice;

entity: a type of slice corresponding to a substance;

interaction: a physical process that relates the properties of two entities.

Interactions use different physical processes including: electromagnetism (e.g., light), other waves (e.g., sound, ripples in water), physical contact (e.g., billiard balls striking each other), chemical signals in a medium (e.g., smell), gravity and radioactivity. In all of these examples, except physical contact, interaction is

directional in that a physical process is initiated in one entity and then impinges on another (or many more). In the other cases we can consider an interaction between x and y to consist of two separate directional interactions, one from x to y and the other from y to x. Call a directional interaction a

d-interaction.

Any d-interaction takes place at a specific time (or over a specific time period), but the same type of interaction may take place many times. For example, there are many examples of light being emitted from one entity and absorbed by another. Call these types of interaction or d-interaction. D-interaction or interaction types can have the same properties as interactions or d-interactions (respectively) with the exception of space-time properties. For this reason it is useful to consider the space-time properties to be relative.

Define a

pointer to be a tuple (l, v, S) for which:

Pointers can be

instantiated or not according to whether or not v isn’t ∅.

If x is a slice, then define:

the set of properties of x, P_{x} = {p_{i}: p_{i} is a pointer representing the i-th property of x};

the number of properties of x, |x| = |P_{x}|;

a disposition δ is an |x|-tuple (val (p_{1}),..., val (p_{|x|})), p_{i}∈ P_{x };

the set of all dispositions of x, or disposition space of x, Δ_{x}.

When the properties of an entity meet certain conditions, then an interaction will be triggered. If

**α** is a d-interaction type from entity x to y, then not all of the properties of x and y necessarily affect or are affected by

**α**. Define:

P_{xoα} the set of properties which can trigger **α** (“o” stands for output);

Δ_{xoα} the corresponding disposition space (the projection of Δ_{x }onto P_{xoα});

P_{yiα} the set of properties altered by **α** (“i” stands for input);

Δ_{yiα} the corresponding disposition space (the projection of Δ_{y }onto P_{yiα}).

Then for any x and y,

**α** has the following two associated functions:

the output function, o**α**: Δ_{xoα} x T → Δ_{xoα} which maps any disposition of x before **α** is output to the disposition afterwards;

the input function, i**α**: Δ_{yiα} x T → Δ_{yiα} which maps any disposition of y before **α** is input to the disposition afterwards.

We can write:

o**α**: (δ_{x}, t)→ δ_{xoα} for δ_{x} in the domain of o**α**;

i**α**: (δ_{y}, t) → δ_{yiα} for δ_{y} in the domain of i**α**.

We can define a

d-interaction function t

**α** as follows:

**α** is a

transmission if:

t**α**(δ_{x}, δ_{y}, t) = t**α**(δ_{x}, δ’_{y}, t) for all δ_{y}, δ’_{y}∈ Δ_{y} and for all t ∈ T.

The effect of a transmission does not rely on the disposition of the destination entity or time, only on the nature of the d-interaction itself. In this case we can write

Examples of transmissions include writing to computer memory and transmissions in the more usual sense (e.g., transmission of electronic messages).

Suppose that

**α**_{1}, …,

**α**_{n-1} is a series of d-interaction types connecting entities x

_{1}, ..., x

_{n}. They have the same effect as a single d-interaction if the range of one d-interaction input function is contained in or equal to the domain of the next output function. The effect on x

_{1 }and x

_{n} is the same as if there was a

d-interaction type,

**β**, connecting x

_{1 }and x

_{n}. In this case, though the

transmission function t

**β** has the following form:

t**β**: Δ_{x1oα} x…x Δ_{xioα} x…x Δ_{xniαm} → Δ_{xniαm }and t**β**(δ_{1}, …,δ_{i}, …,δ_{n}) = δ_{niαm}.

As Floridi discusses in [

2], abstraction is concerned with leaving out detail. We use the term “pattern” for this. In this case, the term is linked to the usage in the computer systems architecture world [

8] rather than the sense in which is it used by Burgin [

11], for example.

To make this more precise and to describe structures and connections more generally, we use an approach based on graph theory. This approach is consistent with the approach (using static schemas) used by Burgin in [

11] but allows a more natural use of some graph theory-based ideas.

An

unrooted linnet (where “linnet” stands for “linked net”) C is a tuple (V, E, N) which satisfies the following conditions:

V is a finite set of vertices;

E is a finite set of connectors;

V and E are disjoint;

N is the set of connections of D where N ⊆ {(a, e, b): a, b ∈ V ∪ E, e ∈ E};

if e ∈ E and (a, e, b), (a’, e, b’) ∈ N, then a = a’ and b = b’.

For compatibility with graph theory, if (v, e, w) is a connection with v, w ∈ V, e ∈ E then e is called an

edge (so an edge joins two vertices)

. (Since (v, e, w) is an ordered set, more properly it should be a

directed edge.) The vertices, connectors and connections of C are known as V(C), E(C) and N(C) respectively.

Define the proximity of a vertex to be 0. If (e_{1}, e, e_{2}) is a connection, then the proximity of e, prox (e), is defined as follows: if (e_{1}, e, e_{2}) is a connection then prox (e) = min(prox (e_{1}), prox (e_{2})) + 1 where min is undefined if either prox (e_{1}) or prox (e_{2}) is undefined. A connector is rooted if its proximity is defined. A linnet is an unrooted linnet in which all connectors are rooted. So in a linnet all connectors connect back to vertices.

If C and D are linnets, then (by analogy with graphs—see [

12]) C is a

sub-linnet of D and D is a

super-linnet of C if:

V(C) ⊆ V(D);

E(C) ⊆ E(D);

N(C) ⊆ N(D).

In the examples we will be interested in below, the sets V(C) and E(C) will contain pointers—call the linnet in this case pointed, otherwise unpointed. From here on only pointed linnets will be considered and the term “linnet” will apply to pointed linnets unless otherwise qualified.

When all connections in C are edges, then C is a directed graph. (More precisely and using the terminology of [

12], C is a directed multi-graph since more than one edge can connect two vertices.)

A

dynamic linnet DC is a set of linnets {C

_{i}: t

_{i} ∈ T} for which T is a set of times. Call

the vertices and connectors of DC. A dynamic directed graph (DDG) is a dynamic linnet for which each Ci is a directed graph. (Dynamic graphs are discussed in [

13].)

If C is a (pointed) linnet, then C is:

instantiated if all the pointers in V(C) and E(C) are instantiated;

uninstantiated if all the pointers in V(C) and E(C) are uninstantiated;

partially instantiated if it is not instantiated.

Call a partially instantiated linnet a

pattern (by analogy with the computer systems architecture term). Patterns are closely related to queries and searching. For example, any query in the Structured Query Language, SQL [

14], has a corresponding pattern.

Burgin provides a thorough discussion of structures in [

11]. He shows that his definition of structure, defined in terms of static schemas, is sufficiently rich to model structures associated with information. If vertices in linnets are associated with object variables in static schemas and connectors are associated with connection variables, then linnets have the same potential.

#### 3.3. Extended Connection Models

A PCM models individual d-interactions between entities, but in many cases, there are more complicated forms of connection. Suppose that:

X = {x_{j}: 1 ≤ j ≤ n} is a set of entities;

Y = {x_{j}: 1 ≤ j ≤ m} for some m < n;

Α is a set of interactions between elements of X;

A|Y = {α ∈ Α: α is an interaction between elements of Y}.

X and A induce a linnet as well as Y and A|Y. However, we can also form a linnet from X\Y and A\(A|Y) by contraction. If:

then the

contracted linnet C\e is defined as follows:

V(C\e) = (V(C) ∪ {v})\{v_{1}, v_{2}};

E(C\e) = E(C)\{e};

N(C\e) = N(C)\{n: n ∈ N(C), e ∈ n};

any occurrence of v_{1} or v_{2} in C is replaced with v in C\e;

any occurrence of e in C is replaced with v in C\e.

Since contraction can only decrease the proximity of a connector, this is a linnet.

Generalising the terminology in [

12], C\e is known as an

elementary contraction of C. A linnet D is

contractible to a linnet C, or is

a contraction of a linnet C, if C can be obtained from D by a sequence of elementary contractions. By extension we can define C\F for any subset F of edges of E(C).

So, to return to the example above, if C is the linnet induced by X and Α, F is the set of edges of C corresponding to A|Y. Then C\F is a linnet. So we can treat the set of entities Y as a single aggregated entity for which

More generally, we can support the definition of arbitrary nesting of entities.

If C

_{k} is a PCL for some time t

_{k}, and EC ={Ck} is the corresponding PCM, then we can create an

Extended Connection Model (ECM) by contraction. If E ⊆ E(EC) define EC

_{k} = C

_{k}\(E ∩ E(C

_{k})); EC

_{k} is an

Extended Connection Linnet (ECL). {EC

_{k}} is an ECM which we can call EC\E. With this definition, the individual components of an IE (see

Figure 1) are ECMs and the IE as whole is an ECM.

#### 3.4. Connections and Relations

PCMs and ECMs model entities and their interactions but there are other types of connection we want to consider. Consider first the properties of slices. Since properties are something that can be measured there is a physical process which takes the slice as input and creates an Information Artefact (IA) as output which represents the property.

This appears to be the start of an infinite regress. A property of one entity can be explained by a process which creates a specific property in another entity. However, the IA belongs in an ecosystem (all IAs and processes that create them belong in an ecosystem) so we will investigate ecosystems and symbols before returning to this question.

In the natural world, evolution has driven the creation of numerous ecosystems. In each case there are a set of conventions which apply to relevant IEs and what they are communicating. The scope of these conventions includes:

the symbols which are used;

the structure of IAs and the rules that apply to them;

the ways in which concepts are connected;

the syntax of IAs and how they are created;

the channels which are used to interact (and the associated sensor and actuator patterns).

Each of these elements co-evolves with the others.

Call such a set of conventions a modelling tool. Languages and Mathematics are modelling tools, for example. There is a close relationship between information ecosystems and modelling tools. We can define an information ecosystem to be the set of IEs, IAs and channels that support a particular modelling tool. (Of course, a particular ecosystem may be a subset of other ecosystems and therefore support other modelling tools.)

Use of a modelling tool requires special processing from IEs, so we can redraw the elements of the generic IE model as in

Figure 2.

**Figure 2.**
The generic IE and modelling tools.

Working memory holds transitory information as it is worked on. Analysers take the output of a sensor and convert it into a standard form appropriate to the modelling tool. Creators do the opposite for an actuator. In particular, they detect and aggregate symbols using the rules of the modelling tool.

We can define these concepts in terms of the discussion of the paper to date, starting with symbols. Suppose that:

E is a set of IEs in an ecosystem corresponding to a modelling tool M;

A is a set of IAs in the ecosystem;

AP is a pattern for each instance of the M analysers for all e ∈ E (the existence of a modelling tool and ecosystem guarantees the existence of such a pattern).

Then:

Any such δ

_{a }is then a

symbol instance and the set {δ

_{a}} is a

symbol type.

What this means is that the analysers map all “symbol” dispositions representing the symbol to the same thing and they are interchangeable in ecosystem interactions. Even when the formats are completely different, the modelling tool patterns in M ensure that they are convertible between each other. MTs also have patterns for structuring symbols in IAs and IEs so that there are MT conventions for their relative structure (e.g., sequence). Any set of symbol instances which meet such structuring requirements we call a content instance. Similarly we can define a content type. Call any disposition which is contained in a content type symbolic. Not all dispositions are symbolic.

With these definitions we can convert symbolic dispositions to symbolic content and, in later elements of MfI, refer to content within the context of a modelling tool in a way which is consistent with the earlier models about properties and entities.

So, in MfI, a

modelling tool M is a tuple (I, S, Cp, A, Ch) defined by the following:

a set of IE patterns, I = IE(M) (each including patterns for sensing, actuation, analysing, creating and connecting);

a set of symbol types, S = ST(M);

a set of content patterns, based on ST(M), Cp = CT(M);

a set of IA patterns, based on ST(M), A = IA(M);

a set of channel patterns, Ch = CH(M);

for which:

each sensor instance consistent with a pattern in IE(M) consumes IAs which are consistent with a pattern in IA(M) over a channel consistent with a pattern in CH(M);

each actuator instance consistent with a pattern in IE(M) produces IAs which are consistent with a pattern in IA(M) over a channel consistent with a pattern in CH(M);

each IA consistent with a pattern in IA(M) is consumed or produced by all IEs consistent with at least one pattern in IE(M);

each IA consistent with a pattern in IA(M) contains content consistent with at least one pattern in CT(M);

each channel consistent with a pattern in CH(M) is used by at least one IE consistent with a pattern in IE(M).

In other words, the pieces of M fit together.

From the definitions, it seems that the definitions are mutually dependent since symbols rely on modelling tools and vice versa. However, the reality is that they co-evolve over time.

If M is a modelling tool, then there is an associated

information ecosystem Eco(M) = (E, A, C) for which:

E = {e: e is an instance of some pattern in IE(M)};

A = {a: a is an instance of some pattern in IA(M)};

C = {c: c is an instance of some pattern in Chan(M)}.

Conversely, for any information ecosystem E, there is a corresponding modelling tool M = MT(E) for E = Eco(M).

With these pieces in place we can now continue the discussion started earlier about relations and types of connection. Any property of a slice or slices or relation between any number of slices corresponds to a physical process as shown in the following

Table 1.

**Table 1.**
Types of connection as physical processes.
# | Type of connection | Equivalent as physical process |
---|

1 | Physical process instance | Physical process instance (as in PCMs or ECMs) |

2 | m slices satisfy relation | There is an ecosystem process, which is an instance of a modelling tool pattern, which takes m slices as input and generates a content instance which is part of the content type “true” as output when the relation is satisfied |

3 | m slices have a property | There is an ecosystem process, which is an instance of a modelling tool pattern, which takes m slices as input and generates a content instance which is part of the ecosystem content type as output representing the value of the property |

For any connection of types two and three in the table, we can say that the connection supports entities and processes of particular types if the corresponding physical process or process type (in the right hand column of the table) requires the corresponding ecosystem patterns.

#### 3.5. Virtual Connection Models

Virtual Connection Models (VCMs) differ from PCMs and ECMs in that the types of connection shown in

Table 1 are included and ecosystem content, as described above, is also represented. These ideas are applied to the generic IE model. The term “virtual” is used because, with the exception of connections representing physical process instances, the additional types of connection represent “what ifs”. They define what would happen if a particular process type was applied to particular slices.

Let C be a content type corresponding to some connections defined in the manner of

Table 1. We can define the Virtual Connection Linnet (VCL), C

_{k}, for entities {x

_{i}} and their d-interactions {e

_{j}} and connections C at time t

_{k} in the following way.

let v(x_{ik}) be the pointer with label x_{i} and value δ_{xik}, where δ_{xik} is the disposition of x_{i }at time t_{k};

let e(e_{jk}) be the pointer with label e_{j} and value δ_{ejk}, where δ_{ejk} is the disposition of e_{j }at time t_{k};

let c(c_{lk}) be a pointer with label lab(c(c_{lk})) ∈ C and value representing the relevant ecosystem process;

let V(C_{k}) = ∪_{i} {v(x_{i})}, E_{1}(C_{k}) = ∪_{j} {e(e_{jk})}, E_{2}(C_{k}) = ∪_{l} {c(c_{lk})} and E(C_{k}) = E_{1}(C_{k}) ∪ E_{2}(C_{k});

N_{1}(C_{k}) = {(v, e, w}: v, w ∈ V(C_{k}), e ∈ E_{1}(C_{k}), the d-interaction represented by e connects the entities represented by v and w};

N_{2}(C_{k}) = {(x, e, y}: x, y ∈ V(C_{k}) ∪ E(C_{k}), e ∈ E_{2}(C_{k}), the process represented by e supports x and y};

N(C_{k}) = N_{1}(C_{k}) ∪ N_{2}(C_{k});

C_{k} = (V(C_{k}), E(C_{k}), N(C_{k})).

A set of such VCLs for a set of times {t

_{k}} is a dynamic linnet called

a Virtual Connection Model (VCM). Note that any PCM or ECM is also a VCM.

Figure 3 shows the relationship between a generic IE and its environment with the interfaces between elements numbered.

**Figure 3.**
A generic IE in the context of Virtual Connection Models (VCM).

The different stages are as follows:

- (1)
Environment input: an input interaction with the environment;

- (2)
IA input: an input interaction with the environment in which the source of the input is an IA;

- (3)
Converted input: the input converted into a form which can be manipulated by the IE;

- (4)
MT-converted input: the input converted into a form consistent with the relevant modelling tool (if any);

- (5)
Memories: material collected from memory;

- (6)
Attention: the short-term picture created by the IE in working memory;

- (7)
MT-converted output: output converted into a form consistent with the rules of a modelling tool;

- (8)
Converted output, environment output, IA output: the reverse of the corresponding input.

In a VCM we can model memory by defining the inputs and outputs in terms of linnets. In principle (and subject to physical limitations) any linnet can be stored, but it is important to note that there are two different types. The output from an analyser is symbolic, whereas environment input is not.

Storage of these different types corresponds to different types of human and computer memory. Humans have semantic memory and episodic memory [

15]. Computer databases include symbolic records and also binary large objects (things like media files). For IEs in general we use the terms

symbolic memory and

event memory to distinguish between them.

Retrieval of memories faces a combinatorial problem so selection pressures demand a way of specifying a manageable portion. In computing, languages like SQL [

14] have been defined for that purpose. In MfI, queries are based on patterns which are linnets in which there is the potential for pointers to be uninstantiated. The response to a query is an aggregated linnet which contains copies of linnets in memory that match the pattern. The scope of the query pattern has a large impact on the results. A larger linnet pattern (in the sense of super-linnet) will constrain the search more.