Information Space:
is any medium that can contain information.
The information content within an
information space is encoded within a
structured field of discernible differences.

Information Content:
is limited by both the information
space's representational resolution and the observer's
perceptual resolution. The lack of perceptual resolution results in
information content that is unavailable,
which is entropy.

Observer:
is a subjective perspective
from which an observable is defined. Also
see computational process and
system.

Subjective Perspective:
is a perspective from which there are other equally valid but
different perspectives. Hence it is a perspective on a context that
only conveys information relative to a
particular observer.

Entropy:
is structured indiscernible difference. It is information
that is unable to be meaningfully discerned.

Communication Process:
is a computational process that
structures the flow of information
between information spaces through
an information channel. The
process may change the representational format but preserves the
information
content. Communication can operate between any information
spaces or within a single information
space. Communication involves encoding information,
transmission, introduced noise from intervening
channels and decoding of information
into observables.

Information Channel: is a
simple information space that
provides a 'pipeline' through which information
flows from one information space to
another.

Observable: is information
that has been discerned and decoded by a computational
process thus resulting in something that has meaning to that
computational process. The
observable is defined from the perspective
of the observer.

Noise: is unstructured discernible
difference. It is information
that is unable to be meaningfully decoded.

Computational Process:
is a communication process that
is structured by information
(the program),
which transforms the communicated
information.
It consists of discrete computation
events. It can manifest and operate within any information
space and often operates within a single information
space to produce a computational
space. All of the above concepts involve some subjective
factor, such as 'discernible' or 'indiscernible' difference,
'observable', “observer's
perceptual” resolution and 'decoding'. Computation is the
subjective element implied by
all of these subjective
factors. For example, a single stream of information
may be entropy or noise
in relation to one computational process but a different
computational process may discern or decode the information
stream, so in relation to the latter process the stream is
information rather than entropy
or noise. Computation is the active element
within the passive information space;
it discerns the difference, decodes the observables,
and 'experiences' a programmed response that
may change an observable, which is then
encoded and communicated
(perhaps back into a computational
space). Also see observer and system.

Bandwidth:
is the quantity of information that flows
through a information channel
within a given period.

Computation Event:
is a single discrete operation within a computational
process.

Computational Space: is
an information space that is
operated on and animated by a 'resident' computational
process. It may communicate
with other information spaces or
computational spaces via information
channels. It can store and operate on information
content using information
processes.

Program:
is information content within a
computational space that
structures a computational process.

Information Process: is a
dynamic, structured pattern of information
content and program
within a computational space. Also
see system.

Transcendent Context: is
a closed computational space
wherein the perceptual resolution of the computational
process is equal to the representational resolution of the
information space,
so there is zero noise or entropy.
Within this computational space
there is information content
flowing between sub-spaces whilst being transformed by the
computational process. Thus
information objects and information
processes exist within that information
space and are animated by that computational
process thus undergoing coherent change or dynamical evolution.
The transcendent context underlies the existence of an empirical
context. In a transcendent context the only subjective
element is the single computational
process that animates the transcendent computational
space so all subjective
factors are defined from that perspective. There is therefore, in
this context, an uncontested (absolute) perspective from which to
determine all concepts and quantities so this context is considered
to be an objective context
because there are no clashes of perspective so for all intents and
purposes things are how they seem.

Objective Perspective:
is a perspective from which there are NO other valid but different
perspectives. Hence it is a perspective on a context that conveys
information relative to the sole observer
of an information space.

Empirical Context: is a
virtual space represented by information
content and animated by the computational
process within a transcendent
context. The empirical context is defined from the perspective of
information processes within the
transcendent computational
process. From within the empirical context a transcendent
information process is conceived
of as a system. The systems
have varying perceptual resolutions and are connected into a complex
network of interacting systems so from each
empirical perspective there is both entropy
and noise. Within this virtual space, from the
subjective empirical
perspective of a system embedded within the
network of systems, there are observables
and observation events. Thus systems
with observable states exist and experience
observation events within that
virtual space. In this context every system has
a subjective perspective from
which its empirical context is defined. There
is therefore, in this context, NO uncontested (absolute) perspective
from which to determine all concepts and quantities; everything is
relative. Because of this the empirical context is considered to be a
subjective context because
there are clashes of perspective and things are not how they seem.
There are many perspectives but they only reveal subjective
empirical observables that are just
partially discerned, partially decoded and largely distorted
interpretations of the absolute underlying transcendent
information.

System: is a transcendent
information process conceived of
from a general empirical
perspective. It is an observable form as
well as an observer
within the empirical
context. In this sense it has an outer
aspect and an inner aspect. It is a
participant in empirical
dynamics which are just the transcendent
dynamics conceived of from an empirical
perspective. A system is an empirical
subject and has some perspective from which various concepts and
quantities can be defined, such as information,
entropy,
noise and so on. A system is one participant
amongst many within an empirical
context, hence its definitions of concepts and quantities
is only relative to its perspective. The concept system
exists only within the empirical
context, when in the transcendent
context they are conceived of as information
processes.

Inner Aspect: of a system
is the operation of the transcendent
computational process as it
animates the system. It is conceived of from an
empirical
perspective as pure awareness, direct experience or proto
consciousness. As systems increase in
complexity the complexity of both inner
and outer aspects increases. What we call
consciousness and mind are complex
inner aspects.

Outer Aspect: is the empirical
observable form of a system's
transcendent information
content. It is a subjective
view that depends on the particular observer's
perspective. It is an object of perception and is experienced as an
object within the experiential (empirical)
context. It is an output interface by which information
is communicated
to be decoded as observables by other
systems.

Observation Event: is a
single discrete operation of a system's inner
aspect that discerns, decodes and experiences an observable.
This is an experience of present moment awareness but becomes
overlaid with empiricist
interpretation. It is conceived of from an empirical
perspective as a single moment in time and the succession of these
moments combined with the propagation of their information
through information channels
(which serve as memory) results in the empirical
experience of the flow of time.

Interaction: is a communication
process between systems that allows them to
experience each others observables and to
respond by changing their own observables.

Finite & Discrete: is a
proposition that within any realisable information
space there will be a finite number of distinguishable
observables. This would mean that no
manifest form or process (system) within an
empirical
context could be infinitely large,
infinitely small, infinitely
complex or infinitely
detailed. This implies that the empirical
context will be quantised and relativistic. It also
concludes the existence of atomic systems
and precludes the existence of any actual infinity within an
empirical
space. Hence there are a finite number of atomic
systems that exhibit a finite range of discrete observables.

Infinity: Only potential infinity is
possible, for example, the space of all words of any length is
infinitely large but we only ever manifest a finite number of words
at any one time and as the words get longer it gets more difficult to
manifest them so it is fundamentally impossible to manifest an actual
infinity of words. This general principle applies to all information
processes due to their finite &
discrete information spaces,
which result in quantised and relativistic empirical
contexts.

Atomic System: is a system
that has no subsystems. It is an atomic
information process so it has only
a single atomic information
object (observable, outer
aspect) and a single atomic computational
process (observer,
inner aspect). An example of a primitive
system is a single bit in a computer. Its
atomic observable has the state zero or one
and its atomic computational process
is a simple read/write interface with the observable
so that information
can be stored or retrieved from that atomic computational
process. So an atomic system is an atomic
observable as well as an atomic observer
that is only able to discern single atomic observables.
The concept atomic system exists only within
the empirical
context, when in the transcendent
context they are conceived of as atomic information
processes that operate on atomic observables
and participate in complex networks of atomic information
processes within the transcendent
computational space.

Complex System: is the product
of a meta system transition. In
the empirical context it is a system that has
subsystems. It is a complex information
process so it has multiple atomic or complex information
objects (observables, outer
aspects) and multiple atomic or complex computational
processes (observers,
inner aspects). An example of a complex
system is a computer. Its complex observable
form can be in many different states and its complex computational
process can manifest a variety of simple and complex information
processes. So a complex system is a complex
observable as well as a complex observer
that is able to discern multiple simple and complex observables.
A complex system is composed of a network of
interacting subsystems and it participates in a
network of interacting systems to form
supersystems via a process called meta
system transition. The concept “complex system”
exists only within the empirical
context, when in the transcendent
context they are conceived of as complex information
processes which have no inherent hierarchical structure of
subprocesses within superprocesses, they are just a flat network of
atomic processes.

Meta System Transition (MST): is a process conceived of
from an empirical
perspective whereby a system's limited
perceptual resolution means that incident information
becomes entropy
and the finer detailed observables in a
complex network of systems
are blurred into a macroscopic observable
that appears to the observer
to be a single complex system. Thus it appears that a group of
subsystems have interacted and integrated into
a single complex supersystem. However in the
transcendent context nothing has
fundamentally changed, some interaction
bandwidths may change but there is still
just a field of interacting atomic
systems, only the empirical
observable changes during an MST. Therefore
MST is an empirical perceptual
illusion that causes a system to experience a
complex network of systems as a single complex
system.

SMN related concepts directly extend these general concepts and
will be defined shortly...

We need to see our deeper union with all that is, only this
understanding is a secure foundation for civilisation. If we are to
have a stable and healthy civilisation for the long term we need a
common understanding of the fundamentals of existence.

Fundamental questions need to be resolved:

Who are we? What are manifest forms?
Where are we? What is the
universe?
What is happening? What is the process of existence and
evolution?
How to respond? What is the real scope for action and
what are the most effective responses?

There are many expressions of truth but only one reality. A
healthy civilisation needs to be anchored in reality and have access
to a diversity of expressions of truth.

Fortunately many lines of thought are converging toward a unified
understanding. There is a profound unification underway of the
fundamentals of quantum physics, computer science, consciousness
research, philosophy, ancient wisdom, new age wisdom and spontaneous
group and individual realisations. There is a clear phase shift in
human consciousness that is in part being expressed as a new
understanding – a more holistic and unified understanding.

Eventually this will be distilled into a unified science that can
comprehend all aspects of reality and serve to harmonise the many
perspectives by connecting each one to a common foundation and
through this to each other.

Only then would we have secured for humanity a future free of the
kinds of atrocities that have plagued our past. If a civilisation
possesses a clear, realistic and commonly accepted understanding that
is approachable through numerous perspectives (e.g. science,
religion, mysticism, etc) then it would be unable to slide into the
kinds of mass delusions and destructive frenzies that characterise
much of history.

The shift in consciousness is happening and soon we are going to
be building a new science for a new civilisation. It is for these
reasons that I work on developing the foundations for a unified
science. Check out www.anandavala.info
or my blog
for more.

Best wishes :)
John Ringland

The System
Oriented Modelling Paradigm project is in its first phase wherein
we apply SMN to Java
so this phase could be called "System Oriented Java". It
uses the Java programming environment as the computational-space and
a Netbeans
IDE plugin as the interface, which will provide an SMN view into a
virtual model that consists of Java objects.

This gives a high level systemic IDE for the Java programming
language that will allow for the development of complex robust
systems in Java. When deployed these will be pure Java programs, but
they will be implicitly structured according to the systemic logic of
SMN.

I could imagine an analogous situation with an interface
application that provides an SMN-view into a virtual model that
consists of POSIX
operating system objects and procedures. POSIX is an international
standard that many operating systems conform to such as UNIX, Linux,
Mac OS X and also Windows using the UWIN
extension. The OS objects and procedures are shell commands, shell
scripts, programs, directories, files, devices and so on. The POSIX
OS is the computational-space and the SMN-viewer application is the
interface.

In this scenario we introduce an SMN process into the OS
environment that integrates all the various systems and processes
into higher-level systems and processes. The programs could be used
as subsystems with which to construct complex robust computing
environments. The user could interact primarily with systemic virtual
models whilst behind the scenes the native programs are integrated by
SMN to implement the low-level functionality. This could be developed
into a high level systemic human/computer interface that can operate
within any POSIX OS.

If the computational space is web content on a web-server then SMN
could animate this in a similar manner to PHP
or JSP
but in a far more systematic manner allowing for more complex dynamic
web content.

If the computational space is a network of computers then SMN
could integrate their computational power into a single coherent SMN
process. In this context the computers can seamlessly interact within
a common virtual space and if we wish we can make a super-computer
out of many regular computers or transform a super-computer into many
virtual computers.

If the computational space is a set of concepts in a discourse
then SMN could systematically map these as concept maps (mind maps)
or ontologies and validate them, allowing for more complex conceptual
communication. This would use OWL
(Web Ontology Language) for clear and precise expression of ideas,
beliefs, opinions, conceptual models, plans, processes and so on. It
could lead to systemic methods for the integration of different
perspectives which would assist in conflict resolution and the
development of a unified understanding amidst a diversity of
perspectives.

If the computational space is raw computer hardware then SMN could
act as a complete operating system by reifying the various devices as
systems within a virtual space where they are integrated into a
unified systemic computing environment. The core SMN process can be
implemented on-chip (or in-silico) to produce a very fast pure-SMN
computer.

If the computational space is a modern industrial plant that is
electronically controllable, then SMN integrates all the components
of the plant and reifies the plant as a virtual system whose
behaviour can be closely monitored and controlled for greater safety
and efficiency.

SMN is a general systemic process that can be introduced into any
computational space. The project would seek to develop the general
principles whereby SMN can be applied to any electronically
controllable environment to integrate its various systems and
processes into higher-level systems and processes.

We initially implement these principles within the context of
Java. This serves as a useful tool as well as an example of how SMN
can be applied, which can help people apply SMN in other contexts.

Once the first "System Oriented Java" phase is well
underway we could then look to what other systemic context we could
apply SMN to next. Hopefully there will be others doing the same.
There would also be many other facets to the project such as,
documentation, networking, etc.

This will shortly be released as an open-source
project with some kind of a GPL
license so let me know if you want to get involved - there's a lot of
work to be done to fully define and develop this new technology and
it will be exciting to see it come together.

Best Wishes :)
John Ringland
www.anandavala.info

What is a System?

A system has two aspects, its
transcendent aspect is as a transitory pattern of transcendent
information that conditions the flow of transcendent information.
When the system is perceived from an empirical perspective by another
system within the common network of interacting systems, then it is
experienced via its observable attributes, which result in
information that flows into the observer system's inputs. This
results in an experience of a manifest form, which is the empirical
aspect.

Subsystems interact to form
supersystems; i.e. patterns dynamically merge to produce larger
patterns. Whilst the transcendent patterns are what they are the
empirical forms exist only in the eye of the beholder. A system may
interact with other systems that are considered to lie 'within'
different supersystems so it may be considered a subsystem of either,
thus there are no absolute system boundaries. Different observers may
observe different interaction channels and thereby resolve different
system boundaries thus they experience very different empirical
forms.

Why should we care to clearly know
what a system is?

We are systems formed out of
interacting subsystems and we interact to form supersystems. All
manifest forms are systems. All events and processes are system
interactions. Our transcendent part we call our 'soul' and our
empirical part we call our 'body'. The empirical universe is a
construct of the experiential aspect of systems and behind this
perceptual veil there is an information theoretic aspect. Some call
this the quantum realm, spiritual realm, Brahman (Vedic), Hundun
(Daoist), Heaven (Christ) and so on.

Everything that is and everything that
happens is the experiential aspect of a unified transcendent process.
This is analogous to the way that a virtual reality is the
experiential aspect of a unified transcendent process.

Understanding the nature of systems
leads us to an understanding of ourselves, of the universe, of what
is happening and how we should respond in order to harmoniously and
effectively participate in the process of evolution that is underway.

What fundamental questions can it
help answer?

A deep understanding of the nature of
systems can help answer all fundamental questions except one, and it
can explain why it cannot answer that one.

There is only one true mystery – What
is the true nature of the fundamental reality generative process?
A manifest form cannot approach this via enquiry; e.g. a sentient AI
character in a virtual reality could realise many things about their
situation all the way down to the computational process itself, but
they cannot realise that the computer is a particular machine sitting
in a particular room, they can only ever know the computer from
within. Similarly, we can systematically comprehend all the general
principles of our reality right down to the fundamental reality
generative process and we cannot enquire beyond that.

Holism is a metaphysical paradigm that
focuses on the whole and comprehends the parts as discernible
features – objects of perception – within the whole. Reductionism
is a metaphysical paradigm that focuses on the many parts and their
interactions and envisages the whole as the product of the many parts
and interactions. Unified system science can comprehend both
paradigms and show how they relate to each other. Similarly it can
unify duality and non-duality. Transcendent and empirical. Subjective
and objective. For these reasons I propose that a unified system
science could provide a useful conceptual framework for the
development of a unified awareness that can flower into a new
consciousness for humanity.

Best Wishes,

John Ringland

The article at (http://www.codeguru.com/java/articles/162.shtml)
describes how to create a JTable where the cells can be any
Jcomponent.

A JTable “is meant to be placed in a JscrollPane.”

“Each JTable has three models: a TableModel,
TableColumnModel, and ListSelectionModel.
All table data is stored in a TableModel, normally in a
2-dimensional structure such as a 2D array or a Vector
of Vectors. TableModel implementations
specify how this data is stored, as well as manage the addition,
manipulation, and retrieval of this data. ”

Perhaps the SystemMatrix can be concepualised as a TableModel and
accessed via a JTable.

From the JTable entry of the Swing documentation at
(http://java.sun.com/developer/Books/swing2/chapter18-01.html).

“18.1.2 The TableModel Interface

abstract interface javax.swing.table.TableModel

Instances of TableModel are responsible for storing a
table's data in a 2-dimensional structure such as a 2-dimensional
array or a vector of vectors. A set of methods is declared for use in
retrieving data from a table's cells. The getValueAt()
method should retrieve data from a given row and column index as an
Object, and setValueAt() should assign the
provided data object to the specified location (if valid).
getColumnClass() should return the Class
describing the data objects stored in the specified column (used to
assign a default renderer and editor for that column), and
getColumnName() should return the String
name associated with the specified column (often used for that
column's header). The getColumnCount() and getRowCount()
methods should return the number of contained columns and rows
respectively.

Note: The getRowCount() is called frequently
by JTable for display purposes and should be designed
with efficiency in mind because of this.

The isCellEditable() method should return true
if the cell at the given row and column index can be edited. The
setValueAt() method should be designed so that if
isCellEditable() returns false, the object
at the given location will not be updated.

This model supports the attachment of TableModelListeners
(see below) which should be notified about changes to this model's
data. As expected, methods for adding and removing these listeners
are provided, addTableModelListener() and
removeTableModelListener(), and implementations are
responsible for dispatching TableModelEvents to those
registered.

Each JTable uses one TableModel instance
which can be assigned/retrieved using JTable's
setModel() and getModel() methods
respectively.”

I could use a JTable as a view into the system matrix and place
into that view either standard table cells (data input / output) for
atomic systems OR icons for conceptual system interfaces. For the
state vector the cells can be either atomic data OR icons for
conceptual system states. The rowOps are actually 'vSystem”
objects, they are either simple data OR icons for operations that are
defined elsewhere.

Some examples, all integer or double numerical data and summation
operator, all strings and concatenation operator, conceptual systems
with corresponding icons or a mixture of these.

The user can drag and drop columns around the place to rearrange
the view, the corresponding row, rowOp and state vector element is
moved as well. The columns are the only means by which the designer
can rearrange the systems in the view.

I found some great code examples for tables with all kinds of
useful enhancements like groupable rows and columns and so on...
(http://www.crionics.com/products/opensource/faq/swing_ex/SwingExamples.html)

Some useful table
extensions may be:

The object model is produced by
distilling out the whole of SMN and leave behind only the abstract
system – this is what is stored and operated on as the model –
only for visualisation and so on will it be cast into an SMN like
form. So each 'system' entity class contains the state data
(SVElement) and the output interface (SMCol). The input interface and
the sub/super class/system relations are all separate metadata that
can be merged with the system to cast it into an SMN like form –
this is a flow model where each system experiences the flow of
information from the common SV data space. Each system can only
control its own state, and external clients interact with the virtual
systems by influencing the state of wrapper systems. The influence
that the system wields in the virtual space arises due to other
systems observing its state data and responding.

This system object-model can be
distilled from the SMN model and it makes the interaction channels
between systems direct. Rather than SMElement data being mediated via
the SMN algorithm there are direct references between Java objects.

SMN takes the REST principle
all the way! Below is a quote from Building
Web Services the REST Way
(http://www.xfront.com/REST-Web-Services.html):

“Here
are the characteristics of REST:

• Client-Server:
  a pull-based interaction style: consuming components pull
  representations.
  

  
  

• Stateless:
  each request from client to server must contain all the information
  necessary to understand the request, and cannot take advantage of
  any stored context on the server.
  

  
  

• Cache:
  to improve network efficiency responses must be capable of being
  labeled as cacheable or non-cacheable.
  

  
  

• Uniform
  interface: all resources are accessed with a generic interface
  (e.g., HTTP GET, POST, PUT, DELETE).
  

  
  

• Named
  resources - the system is comprised of resources which are named
  using a URL.
  

  
  

• Interconnected
  resource representations - the representations of the resources are
  interconnected using URLs, thereby enabling a client to progress
  from one state to another.
  

  
  

• Layered components -
  intermediaries, such as proxy servers, cache servers, gateways, etc,
  can be inserted between clients and resources to support
  performance, security, etc.
  

  
  

”

Each vSystem is a client and the
server is the network of vSystems, the collective. Each client has a
particular connection from the server (input interface) through which
it receives data and a particular connection to the server
(SVElement) through its data flows on to others. Each SVElement is
read-only to all systems but the associated system, so it can only
influence the collective by changing its state in the SVELement. An
SVElement is a piece of state data that represents some systems state
within the virtual space – the system that is represented may be a
vSystem or a physical system (I.e. A wrapper) – so long as it can
synchronise some of its state with the SVElement.

Each system only has access to the
information flowing in through its input interface and cannot use any
other state, hence the systems are stateless.

Some states are static and can be
cached – is this effectively implemented by energy flow?

The uniform interface is SMN itself,
which provides a unified mathematical framework.

All systems have URIs.

SMN excels at representing
interconnected resources.

Layered components can be inserted
into the modular process.

Input not fundamental to EFSMN –
output is.

If a system object only had its
input interface explicitly defined, then it has references to other
systems from which it draws data and then uses this to change its own
state – but what then? There is no EF process to recognise which
systems depend on this state and need to be reprocessed. Hence each
system needs to have an output interface, which sends a signal down
each output channel to wake the dependent system up so that it can
process its inputs then change state then wake up downstream systems
and so on... So its a receive then nudge approach. Receive all
required data, change state then nudge any systems that are
registered as observing that state. Systems can register with other
systems to be notified of changes of state – they are then placed
in that systems output interface and they place that system in their
own input interface.

In the object model, once a system
has received some new data due to a state change followed by a change
notification, the system either (case A) pulls the other state data
that it needs via its input interface, or (case B) if no change
notice is received the state stays as before so no data is pulled.
The system then changes state, then sends its new state to all
systems in its output interface. With case B this is a push only
model where system states are cached by each system and only change
due to a change notification. Case B is good for systems that are
remote – in distant servers – and case A works best for systems
in the same memory space. Hence there is a distinction between local
and remote systems that parallels un-cachable and cachable.

The object model represents the pure
connectivity between systems whereas the SMN model also stores things
such as matrix or vector indexes which are really SMN specific. The
pure connectivity is the actual model and SMN is just a useful view
on it. SMN is a view through which systems can be comprehended via a
compact matrix interface. The actual model has no view specific data
of any kind. Each vSystem can be identified by a URI like a standard
REST system.

The SMN view can read in
interconnected networks and present them in a matrix or network view,
making it available for simulation and testing – that is the main
role of the SMN application – as a view! That means that the core
is more general. The core is a network of objects within some
computational space, whether Java objects or C++ objects or whatever
– the actual model is the pattern of connectivity – they could be
documents or OWL classes or whatever but they have some pattern of
connectivity. SMN is a view that can operate on the pattern
regardless of what the data is! That is a computer.

XML can represent the pure pattern
and this can be unserialised into any kind of instantiated object.
Meanwhile SMN can read and write XML, visualise the pattern and
provide design access to the pattern and the data embedded in it. The
actual instantiation or unserialisation of any objects is done is
some computational space such as a Java virtual machine. Lets call
this computational space the instantiator. SMN only operates on the
pattern of data, it is up to the instantiator to actually instantiate
the objects. In this sense SMN is like a general IDE for any network
of systems. It allows one to create or analyse complex networks of
any kind – it allows one to work on the network structure – the
pattern itself – separate from the actual objects that comprise the
pattern.

A new method of software development
could be to build abstract system models in SMN and produce XML
specifications of whole programs or modules. Then in any
computational environment such as Java one can unserialise the XML
and produce actual Java objects that represent the full object model
defined in the XML specification. This object model functions as the
model system – I.e. The software product. Hence it was designed as
an abstract model, stored as XML and then instantiated into any
XML-to-object enabled computational space.

I could create virtual web services
as XML models then instantiate them within JSP and PHP pages to
implement the web service. I could also create simple programs and
then instantiate them in various OO environments such as Java and
C++. They would be identical systems with identical specifications
but operating within different computational environments.

The SMN
paradigm is a general system analysis methodology to work with the
pattern or structure of complex systems. It is a general system
development and analysis methodology (plus helper applications) that
can integrate into many other frameworks. This allows people to
analyse and develop system models in many different scenarios.

SMN doesn't add any fundamentally
new technological artefact; the plugin is just a helper application
to make it easier to use the new paradigm – SMN itself is a new way
of thinking about and using our current technologies.

The proposed product of this project
is essentially an information system oriented engineering
paradigm. Rather than object oriented it is system oriented; it is SO
rather than OO. Like with OO there is no official OO application or
standard – OO is a methodology not a package – it can be
implemented in many ways e.g. Java, C++, etc. What was required for
OO to take off was a compelling reason to use it and a clear
definition, then to get people started there was an example
programming language and a compiler for that language.

What are the parallels between OO &
SO?

• Compelling Reason – SMN gives
  cyberspace a deep metaphysical foundation making systems more robust
  and functional.

  
  

• Clear Definition – SMN is
  amenable to a clear mathematical definition.

  
  

• Programming Language – The
  SMN matrix-view and network-view graphical modelling environments
  with embedded traditional technologies allow people to construct
  system models. There is also the XML model format or even existing
  programming languages could still be used – but the SMN IDE makes
  it much simpler.

  
  

• Compiler – The design
  view outputs an XML model specification that can be instantiated as
  an application instance within various frameworks. e.g. a Java
  object model. This object model can then be executed as the
  application system.

  
  

The first two would be some core
documents with subsidiary documents and a discussion around these.
The second two could, for example, be initially implemented as a
Netbeans plugin or an Eclipse plugin.

Both pairs of articles are of equal
importance!

The System Oriented Modelling
Paradigm is about more than just software, but software is an
excellent context in which to flesh out the details using a detailed
case study.

This project seeks to show that
the traditional systems approach is ad-hoc, sub-optimal and leads to
unstable systems that are wracked with conflict and tension.
Alongside this it will show that the SMN approach leads to the
creation of coherent, optimal and robust systems that are intimately
integrated and thereby function beautifully. This is profound! It
could change our whole way of thinking about and developing systems
of all kinds. It could subtly change our idea of what and where we
are!

Traditionally we have approached
modelling and system design from a perspective that is grounded in
commonsense naïve realist beliefs about the nature of systems
and the nature of the reality within which they operate. These
commonsense attitudes permeate the whole of system design principles.
SMN however builds upon a deep metaphysical foundation and provides a
unified and coherent system modelling environment within which we can
discover more realistic and realist system design methodologies.
If we come from a realist rather than a naïve realist
perspective, what kind of modelling paradigm then arises? It will be
built upon fundamentally different principles.

Maybe this project will be about
mashing together an assortment of different technologies and unifying
them within an SMN inspired framework that provides a matrix view
into the system network. Using this IDE I then construct a web
service to show how it can be used to construct systems. I can then
build a range a basic subsystems to provide a development palette.
This would then be a generalised development environment that could
be built upon any underlying framework – here I use Java. There is
very little 'actual SMN' code – SMN is the idea behind the
methodology and has only a shadowy presence in the final product.

The proposed project would weave
together existing technologies to provide a virtual system space with
coherent metaphysical properties. It can be used to weave together
various different technologies to achieve the same end. It is not
dependent on any particular technologies. It is a way of using
various existing technologies to provide a system oriented IDE and a
metaphysically coherent cyberspace.

SMN is a
conceptual model of computation – so implementing it in software is
a bit like reinventing computing. But in doing so cyberspace is given
a mathematical, system theoretic metaphysical foundation. But SMN
doesn't need to be implemented in software – it is more that
software needs to be re-imagined and re-evaluated in light of SMN.
SMN is put forward as a general model of computation and general
systems. Various lessons can be learnt from this model and then
applied to computation and engineered systems in general.

SMN is a system theoretic 'view'
through which people could interact with all kinds of instantiated
systems. By looking through the lens at various systems we can learn
about general systems and general computation.

In an SMN model, from the systems
perspective everything happens synchronistically, the surrounding
universe operates in beautiful harmony with the system and the system
doesn't have to do anything but process the data that arrives in its
input interface then change state accordingly and pass this data on
to downstream systems. It cannot change other systems states.

The conceptual difference between
traditional modelling and SMN is that functionality isn't implemented
in separate objects but is a mode of behaviour of the network of
systems. This is a totally non-egoic and non-reductionist programming
paradigm based upon system theoretic principles and in accord with
quantum physics, computational logic and mystic metaphysics.

SMN is neither a push nor pull model
– it is a flow model – there are channels and nodes, and there is
flow through the channels, which is transformed at the nodes.

A traditional program is a set of
procedures that come together at runtime to dynamically discover a
state space. This space can be inferred prior to runtime through code
analysis but it cannot be fully known until it is discovered by the
runtime functioning of the program – sometimes there are surprises
(bugs). SMN is different, in its QSMN form the programmer deals
explicitly with the state space so there are no surprises. Here we
are dealing solely with CSMN but it too is different, the entire
system is connected up in front of the designer and the flow of
dynamics through the system is explicit. The exact trajectory through
state space is still discovered at runtime but the overall topology
of the state space can be known because the dynamical flow through
the system is explicitly mapped and this model can be stepped forward
using the conceptual equivalent of higher powered matrices in SMN.

Many profound aspects of the science
of general systems and general computational processes can be
explored within the context of SMN.

The integrated system programming
approach is conceptually subtle at first, one isn't dealing with
individual systems but with a 'whole' integrated network of systems
that exhibits some collective behaviour. As a programmer one wishes
to determine what that collective behaviour will be. To do this one
must define the network of interactions between the systems and the
individual systems themselves. But the individual systems will be
quite simple because the functionality arises from the collective
behaviour of the network of systems.

The traditional approach of thinking
of separate reductionist subsystems that have a kind of “free will”
is an obvious place to start given our perceptual experience and
traditional belief systems – but upon deeper analysis this may not
be the optimal approach for general computational systems. The
traditional way leads to an ad-hoc collective of individuals acting
from their own perspective – this is a recreation of the
reductionist, materialist, mechanistic, naïve realist
perspective on reality. This approach can lead to clashes and other
systemic dysfunctions. All kinds of security and anti-deadlocking
infrastructure needs to be in place. Although the process
conceptually starts with individual “free will”, the likelihood
of clashes causes the systemic environment to become limiting to the
point that the individuals are struggling within a dysfunctional
collective system. There are many degrees of this – it may just
lead to a slightly sub-optimal solution or it may end up in system
crashes, unresponsive behaviour or software that just doesn't work
well enough or is too complex and difficult to maintain (mainly
because it is built using ad-hoc processes and is based upon naïve
metaphysical concepts).

The SMN system oriented modelling
approach thinks first of the whole and the patterns of connectivity
and flow within the whole. This sets the context within which each
individual system must operate. Only within this collective context
can any individual system be properly integrated.

A system may seem as though it has
“free will” from its perspective – it may interpret the
incoming data, make decisions, draw other data based on these
decisions and perform actions that can change the state of other
systems. But all of this is a perceptual illusion, the underlying
reality is that the entity is a complex systems and not a single
whole – there are many subsystems all integrated in a non-egoic
manner where each subsystem experiences the incident information and
changes its state accordingly. The complex collective system can seem
to have the same functionality as a traditional reductionist egoic
system but it is actually a holistic integrated system.

SMN is a work of pure and applied
computational science – it is a model of general computation. I
could explain the general framework then QSMN (state space process)
then CSMN (system network process). From these I then develop a
general system modelling framework. Along the way, many parallels
will be shown between the current computational framework and the
general principles exhibited by SMN. We will see that the current
framework is ad-hoc but remarkably close to the optimal and with
minor adjustments it can be given a deeply coherent metaphysical
grounding that will make it more robust and powerful. I won't yet
discuss the parallels with mysticism in any detail – I'll just
discuss the computational issues and hint at the parallels...

All the
traditional techniques can still be used but they are conceptualised
slightly differently. For example, with demand driven pull-based data
retrieval. Rather than one Java object (A) calling a method on
another object (B) in order to get some data, instead object A
changes some state variable that signals that it is requesting data
from system B, this is output to system B who processes it and
responds by changing its state so that the requested data is
observable in its state, this observable is then output to system A
who receives it and can carry on with the processing.

At the high levels at which humans
interact with cyberspace this pull-output foundation can be presented
in traditional ways to the extent that one could use a statement like
this one-line command:

objectA.data
= objectB.getData();

However underneath, in the lower
levels of cyberspace, the system will actually be implemented as an
energy-flow / push-output object model that is managed via SMN views.
The actual program is an SMN oriented object model and that type of
model can simulate anything – including traditional methods such as
pull-on-demand data getters.

Although it would seem that
using a one line data getter is clearly much simpler. So why even
think about SMN? What value does it provide? Why use it instead of
just using traditional methods? Because SMN provides a deep
metaphysical foundation to cyberspace, giving it system theoretic
modelling tools and a unified virtual space within which general
information systems can be integrated. At present cyberspace is an
ad-hoc technological layer within our social and physical space –
it could become a deeply coherent virtual space that can be more
effectively and harmoniously integrated with our social and physical
space.

For a system object there are six
main relational dimensions: supersystem, subsystem, superclass,
subclass, input, output. There is one main state dimension, the
system´s state.

Within the system hierarchy a system
can have any number of supersystems, subsystems, superclasses,
subclasses, inputs and outputs.

These five pieces of data completely
specify the system´s context within the model. If each system
object had this relational data then the model could be traversed in
any direction along these dimensions. For execution the model only
needs system state and output interface, but the rest are useful for
the modelling process. The other dimensions are like scafolding on a
building – they're not a part of the final product but only a part
of the process of construction. The XML model consists of a core
model that can be instantiated into the target system and then there
is the design extensions that augment the core model. These
extensions can be saved separately and combined with the core model
when required or they can be derived from the model by analysis.

When we define a logical
supersystem, e.g. ´group´ that consists of subsystems
which are ´parts´, then there is no actual system object
called ´group´, there are only the many ´parts´.
The conceptual group is just to reify the fact that the many parts
are parts of the one group. Each part can be addressed by URIs such
as ¨http://domain/group/part01¨
but in the actual model there are only the parts themselves. This is
usually defined at design time – but what if one resolved a model
from pre-existing code, to resolve the logical system hierarchy from
an analysis would be tricky – it is related to our perceptual
resolution of system boundaries in each moment of awareness,
different resolution procedures produce different sets of system
boundaries and interconnections. This makes it clear that the
perceived and imagined system hierarchy is actually a perceptual
construct that is not a part of the actual model – the model
consists of many ´parts´ but there is no ´group´
within the model itself – the ´group´ is just a
conceptual add-on to the model and is not intrinsic to it.

But for engineering purposes we want
to define and use logical system hierarchies and class hierarchies.

If one calls the URI
http://domain/group/part01
one gets the actual object within the model that represents part01.

If one calls the URI
http://domain/group there is
no object called ´group´ but instead one gets a
matrix-view of all systems that call ´group´ their
supersystem.

In this sense ´group´
represents the system model of all the parts.

Each part defines ´group´
as its supersystem but there is no system object called ´group´
- it is a conceptual system. Whenever the SMN-view reads in a model
where there are objects that define a supersystem that is not a
system object, then a conceptual system is created within the
view-logic to manage any calls to that conceptual system.

SMN models can be developed in a
modular and logically nested manner within the design-view – but
deep down in the actual model the flat matrices are spliced together
and not actually nested.

If one wished to not only create a
collection of subsystems such as ´group´ but one also
wanted to give the collective its own higher level state and
functionality (extendedGroup), this could be done by creating a new
system object called extendedGroup and defining the parts as its
subsystems. Then each part refers to extendedGroup as its
supersystem.

It might seem strange that within
a system oriented model there is no intrinsic system hierarchy but
that is the true nature of systems, a system boundary is a perceptual
construct and is not intrinsic to the ontological situation (see
notes on MST). As the patterns of interaction change between the
low-level subsystems there appears to arise many higher level systems
– but ultimately these are just patterns that arise and dissipate.
What is actually there in the model is the fundamental (atomic)
subsystems – but they are not individuals that ¨make up¨
the whole – they are just points of reference within a unified
whole.

The atomic subsystems are actual
system objects and their URIs refer to the actual object, but all
higher level systems are conceptual entities and the URI refers to
the integrated collective of atomic subsystems, which is represented
as an SMN view into these objects. A compound URI refers to a
conceptual-system-model of the subsystems. These compound systems can
be managed and put into complex hierarchies and networks but all of
this is conceptual – ultimately they are all integrated collectives
of atomic subsystems. The models can be nested within the logical
view but within the SMN model view the matrices are just spliced
together in a flat manner. The cloud of atomic systems is spliced
into the underlying model and the conceptual-system icon is placed in
the matrix-view.

So the only actual objects are the
atomic systems, which in a computational context are just the basic
data-types or native objects such as Integer, Double, String, Image
and so on. In the more complex systems there may be many arbitrarily
defined systems within the hierarchy but these are all ultimately
clouds of atomic systems. So no high level objects need to be
defined, only the atomic systems are instantiated and the higher
level systems are clouds of these atomic systems. So in Java or C++
or so on, only the atomic classes need to be defined and all manner
of high-level systems can be instantiated out of those.

Note: a
parallel – a system object in the object model is conceptually
equivalent to the RowOp in SMN – it receives the input and produces
the output. The system state is equivalent to the SVElement. The
input interface is equivalent to the matrix row. The output interface
is equivalent to the matrix column. The interaction channels are
equivalent to the SMElements. In this manner SMN and the object model
are conceptually equivalent representations of the model. In the
current computing paradigm the object model is simpler – but in an
SMN based paradigm the SMN approach would be simpler – and also
more robust and powerful because it has solid mathematical
foundations. SMN can be used to augment the current technology but
eventually the technology could integrate SMN and change – e.g.
SMN-on-a-chip powering a computer that provides an interface into an
SMN virtual space. - such a computer would no longer be a fast
calculator or a document processor – it will be a portal into a
virtual space.

The “compelling
reason” document is an analysis of the relationship
between metaphysical perspectives and modelling methodologies. I show
the limitations of the naïve realist perspective and how our
current methodology evolved from these roots. It discusses the
ramifications of a naïve realist egoic modelling paradigm. It
raises the issue of what a realist modelling methodology would be
like.

Leaving aside
all conjecture (no naïve realist assumptions), what are the
fundamentals that can be said of any model – introduce general SMN

SMN is a
conceptual model of computation – it is a reinvention of computing
from its conceptual foundations up

Then briefly
discuss QSMN as a conceptual foundation – (quantum physics is the
most widely accepted realist theory in existence)

Then discuss
CSMN in detail – (in particular its engineering applications which
are of most interest to mainstream society)

Then discuss
system modelling making software design almost WYSIWYG.

Discuss easy
distributed data access, integration of computing power, seamless
multitasking, efficient energy-flow processing, advanced analysis and
optimisations, etc.

Discuss SMN
within a computer and SMN network computing.

Adopting SMN
provides a virtual layer atop our technology stack. Discuss virtual
spaces and virtual systems. Culture arises in virtual spaces (cf
newciv article)

Discuss the
development of system science and the engineering of truly complex
systems, unification of paradigms and knowledge engineering, enough
mastery of complex systems to avert the looming global crises, deeper
insight into the fundamental mysteries of existence, overcoming
empiricism and the worst ravages of naïve realism.

The world that
we create depends largely on the vision of the world that we
entertain and the modelling practices we use to create systems. The
world that we believe we inhabit conditions the worlds that we
create. By updating and renovating our beliefs and our modelling
practices we can open up vast new potential.

These are all
good reasons to think about the modelling methodologies that we
employ and how they may be improved. They are also good reasons why
SMN can help us move in that direction.

This completes the “compelling reason” and leads into the
clear definition.

The ground work for the “clear definition”
was already laid down in the “compelling reason” document with
the introduction of general SMN, QSMN and CSMN. The clear definition
uses this as prerequisite knowledge and builds further in a
systematic manner. It is a clear, succinct, technical, mathematical
definition of SMN in all its primary manifestations within the
computational context. It also covers the technical issues of how SMN
functions and how to use it within the computational context – it
is all rather new so it needs some explanation.

The “programming language” component is really a matrix-view
GUI and a system oriented modelling methodology.
The primary product of this subproject is a document that specifies
the modelling methodology – a bit like the Bjarne Stroustrops C++
book defines the C++ language. It is a clear definition of the SMN
modelling paradigm from a designers perspective. It describes what
the paradigm is, how to think about it and how to use it. The
secondary products are documents giving detailed tutorials/examples
of its use. Encourage others to submit tutorials as they discover new
things.

The
SMN plugin is
a design and analysis 'view' that can draw upon system models in
various formats and represent them in a unified manner. It
will read in various formats that describe network structures (e.g.
XML, OWL, HTML, source code, etc) and discover the pattern of
connectivity between the systems and the properties of each system,
then visually represent this to the designer using the matrix or
network layout. Via this view the designer can access all parts of
the model to edit it and they can apply SMN analysis tools to the
model.

The SMN view could have
pseudo-nested structures where details are hidden by GUI level
nesting but the actual model is not nested. E.g. A complex subsystem
could be dropped in as an icon and clicking on its interfaces (matrix
elements) an interface wizard pops up to help construct the complex
interface. The designer is not faced with the complex underlying
matrix model but only an icon in their current model. Hence a modular
system would be very manageable with only a few icons at each level
of detail.

In some cases the subsystems will be
black-box systems where the details stop at some magnification and we
cannot see within, but with most systems you will be able to drill
deeper into the subsystem levels. Each system has an attribute that
identifies its subsystems. These references form a hierarchical
system structure that is also mirrored in the URI namespace
structure. This bottoms out at a small set of fundamental data
elements.

I explored the parallel implementation of an on-demand pull data
getter method, but what about other parallels, say for a 'for' loop?

for (int id=0; idlink]

There is an index variable (id) that increments with each loop based
on some conditions and there is something that is done within the
loop.

Consider a simple loop in SMN, there is a loopCycle system object
that can receive a loopCount intput integer. It then doesSomething()
and then decrements the loopCounter value and stores this in its own
internalLoopCounter variable. The diagonal matrix element is non-null
so this system interacts with itself – whilst ever the
internalLoopCounter is greater than zero the loopCycle system does
its thing and then decrements the internalLoopCounter – eventually
the internal counter is zero and the loopCycles stop.

This type of system could also be provided with input data and it
could produce output data, either on each cycle or at the end of the
cycles. Other variants are possible too, such as different loop tests
and different increment schemes for the loop index. This general
approach can also implement 'while' loop as well.

One major conceptual difference is that there is no simple program
flow – traditionally a single computational threads executes a
program in a linear sequence. These threads can spawn new threads and
multiple threads interact but in each situation there are threads
that scan through linear code sequences. In this traditional scheme a
segment of code is only 'live' when it is being animated by a thread.
In SMN each system is potentially live all the time.

For example, consider a traditional while loop:

while(x>0) { // x is some external variable
    doSomething(x);
}

The only condition required for the loop to be executed is that x>0
but the other implicit condition is that the computational thread is
executing this segment of code, if it isn't the loop will not be
executed. But in SMN if you create a while-loop system with only the
condition that x>0, then whenever that condition was met the
while-loop system will be operating.

In SMN the above while-loop system observes the state variable 'x'
and executes its functional payload whenever this variable meets the
activation condition.

It doesn't have to wait for the computational thread to worm
through the code and animate it – the computational thread is
always available for any system at any time.

For this same reason the program cannot get caught in loops such
as:

int x = 10;
while(x>0) [link]

This code will trap a traditional thread, break program execution and
possibly crash the program. This is not possible when using the SMN
paradigm. Not only do all systems have full immediate access to a
computational thread but the threads weave through all systems and
cannot become trapped by a particular system. If badly designed a
loop-system can still get caught in an infinite loop, and this system
will go on looping for as long as the application is running. This
will waste system resources and may disrupt the logic of the model
but it cannot interrupt the overall application. Similarly, a badly
designed machine might fall apart but it can't 'crash' the surround
“fabric of space-time”, the universe always caries on regardless.
Similarly the overall system process carries on even if the model
logic is totally dysfunctional, the reality generative framework is
untouched by this. So a system can malfunction but this cannot cause
the virtual space itself to become corrupted. This behaviour is
obvious when using the full SMN simulation engine but it is also true
of the derived object models because they are logically equivalent to
the SMN process.

We can implement input/output scoping by placing constraints on
the matrix rows and columns respectively. For example, if a class
method is declared private then only other subsystems of that class
can access it. This means that outside the class's system boundary,
that method's row and column elements are locked so that no other
system can send input to or receive output from the private
subsystems. This means that the matrix needs to store metadata for
each non-null row and column.

Consider the parallels to a typical class definition:

A class is a type of system, it defines a template from which
other systems can be instantiated and from which other templates can
'inherit' properties and extend them. A class has attributes such as
whether it is abstract, what it extends (inherits from) and what
interfaces it implements (e.g. Java interfaces). It also has data
elements that can be public, protected or private and has methods
that can be public, protected or private.

Rather than code a Java class – what would one do in SMN?

The Java class corresponds to a system template that defines a
type of system. Each data element and method is a subsystem within
that template. The attributes don't effect the structure of the
system template; they effect how that template is used – so they
are stored as metadata within the template that determines how the
template can be used in the SMN design process.

Consider an example, imagine that we wish to create a class pod
which contains a list of peas
and a method split()
which returns the list of peas.
The class extends the abstract class vegetable
so it also has the overridden abstract method eat()
which transforms the peas
into nutrients.

First consider the system vegetable
and the system eat:

Their URIs are:

http://domain.org/example/garden/vegetable

http://domain.org/example/garden/vegetable/eat

The vegetable
and vegetable/eat
systems have metadata that defines them as abstract
so they cannot be instantiated, they can only be inherited from.

The pod
system extends vegetable
so at design time, when this was defined, the IDE made a copy of
vegetable
and its subsystems, then renamed this pod.
Then the designer added the systems peas
and split.
The designer then defined the properties of these objects such as
overriding the abstract method eat(),
defining peas
as a list of pea
objects and defining split()
as a getter method for peas.

Now there is also:

http://domain.org/example/garden/pod

http://domain.org/example/garden/pod/peas

http://domain.org/example/garden/pod/split

http://domain.org/example/garden/pod/eat

http://domain.org/example/body/nutrients

These all have appropriate sub/supersystem relations. The pod
system and vegetable
system have sub/superclass relations.

Note that vegetable
can have declared (known) subsystems or undeclared (unknown)
subsystems that declare vegetable
as their superclass but are not declared as subclasses by vegetable.
All relations are like this, they only need to be declared from
either end to be considered to hold true from both ends. This helps
with extensibility. Subclasses and subsystems can declare themselves
a place within existing systems and be accepted by them even though
they are not explicitly declared by them.

Now how to implement a list object such as peas?

Each list item is a pea
system.

If peas
is an unordered collection then it could be a conceptual system.

If peas
is an ordered collection then an explicit supersystem object is
required to hold the subsystems in some order.

Consider the common case where the ordering principle is a linear
sequential list with index numbers from 0 to N-1 where N is the
number of elements. Here we need a supersystem called peas
which inherits from the List
system template which is an atomic system such as a wrapper class
around a Java array of sysURIs. This system object holds the URI of
each subsystem in an ordered array. It declares each pea
system as a subsystem. Each pea
declares peas
as its supersystem. To access the elements one uses indexed URIs such
as http://domain/example/garden/peas/0
to get the first element or if they have specific names they can be
accessed by these like so: http://domain/example/garden/peas/thisPea
.

End of exerpts from the design docs...

Hope you can see what I'm getting at. It would be amazing to see
it fully developed and helping people make holistically effective
system design decisions – these decisions influence the kind of
world that we build for ourselves and future generations.

Blessings :)