Before joining the conversation, please read and accept this Invitation to a Conversation.

Here's a posting to let you know what I'm up to lately. Like I said in the post on What exactly is SMN and how does it connect with other technologies? I've been focussing on concrete implementations lately, rather than on discussions. One project was an artistic collaboration with Glistening Deepwater, called Mystic Visions. I've explored quite deeply into semantic and web 2.0 technologies. I've implemented the core algorithm for SMN in Java and the system simulation engine now has full functionality and the models can be imported or exported as XML files (this is still in further development but will be available for download soon).

But the current project on my mind is the idea of a System Oriented Modelling Paradigm. To give you some idea of what I mean, below are some excerpts from recent design documents – they are just a brainstorm at present. If these ideas make sense to you and you want to get involved then contact me – it will soon be released as an open source project.

The project involves an analysis of general computational processes and general systems, which re-orients system modelling practices upon a coherent metaphysical foundation rather than on a commonsense naïve realist foundation. Traditional modelling practices are seen in a new light and minor optimisations are proposed that can considerably extend the potential and overall functionality of designed systems. A detailed example is given in the context of software engineering.

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 :)

Before joining the conversation, please read and accept this Invitation to a Conversation.