Talk:Foundation ontology

From Organic Design wiki
(Redirected from Talk:Foundation Ontology)

FoundationOntologyNotes.jpg

Old nodal model notes

In the Nodal model, list space enables these semantic networks of nodes to be operated on efficiently at runtime. Node space is a particular application of list space. It defines an environment which is similar to a normal runtime object tree, except that it is global and persistent, and semantic (the keys of key:value pairs point to other nodes), but perhaps most importantly of all, the keys are processes.

Normal objects contain properties and methods which can be executes either when an event occurs, or when the instance requires it. But in a node the keys can be connected into the schedule of processing resource. The actual functionality that a node's methods take on is defined by the key, i.e. key:value pairs (associations) are actually class:instance. This is a much more high-level and intuitive way of thinking about objects. The associations in a node are its roles, resources and information and they're persistent and continuous in nature, undergoing change over time.

All organisations, no matter how complicated are still completely describable as a set of roles, resources and processes which all work in accord with a common scheduling and booking scheme.

There is a certain level of granularity in an organisations definition which can't be broken down into smaller parts - it's considered to be indivisible, or atomic. These units of indivisible work must be carried out by the people who fill the roles, and they are expected to understand and act on the instruction. The organisational system which handles all the scheduling and booking doesn't need to understand the information itself.

Computer programs are also organisations, and any software could be completely described in the terms of an organisation, the only difference would be that the roles indivisible tasks would be filled by computer functions instead of Human beings.

The idea of "generic organisation" is to have a single unified organisational system that handles the scheduling, booking, process definition/execution etc for all systems modelled within it - both real world organisations, and software applications (including itself - see self containment).

Universal machines

The ability to read and write content is all the functionality necessary to build up a turing complete system from, because the foundation functionality on top of which all higher level functionality can be defined is simply the concept of the lookup table which we've already defined for reading and writing our binary sequences. From lookup tables, zeroth-order logic can be defined, and then these logic components can be used for building arbitrarily complex patterns of functionality.

Turing machines are extremely basic symbol-manipulating devices which — despite their simplicity — can be adapted to simulate the logic of any computer that could possibly be constructed. They were described in 1936 by Alan Turing. Though they were intended to be technically feasible, Turing machines were not meant to be a practical computing technology, but a thought experiment about the limits of mechanical computation; thus they were not actually constructed. Studying their abstract machine properties yields many insights into computer science and complexity theory.

A Turing machine that is able to simulate any other Turing machine is called a Universal Turing machine (UTM, or simply a universal machine). A more mathematically-oriented definition with a similar "universal" nature was introduced by Alonzo Church, whose work on lambda calculus intertwined with Turing's in a formal theory of computation known as the Church–Turing thesis. The thesis states that Turing machines indeed capture the informal notion of effective method in logic and mathematics, and provide a precise definition of an algorithm or 'mechanical procedure'.

There are many aspects to organisations, but no matter how complex, they can all be broken down to a few common patterns and concepts. All the programming languages form a huge spectrum of such break-downs, but we don't want to create another specialists' language, we want to create a small set of concepts which are turing-complete, allowing us to represent any processes we need, but that are based completely on Human organisational needs and on Human concepts.

This universal machine shows that a concept being described by a computer program is independent of the program itself, and that the concept could be translated between any Turing complete language without any loss of meaning. But what exactly is the concept then? The concept itself is purely abstract and any description of it no matter how concise is still only a description - just like no word which means "apple" will ever actually be an apple. But we can think, feel and visualise concepts without the use of language constructs, which shows that there is some fundamental strutural way of representing them which our minds and bodies use.

Some universal Turing machines are made from only a few exceedingly simple components, for instance any computer program can be described completely with only one kind of logic operator similar to x AND y. In the project, our aim is to create such a core set of basic components with which to internally describe all the applications and organisations made within the development environment (the development environment is also an application described internally this same way). The internal language allows the system to implement itself and all its applications in any language, platform or technology as necessary.

But what is the best set of basic components to use? Ideally we'd want our internal descriptions to be more compact and exhibit a less complex structure than the languages it can implement them in, so that we can move away from specialisation and make creating and collaborating on applications and organisations more accessible. In essence, we want our internal desciption of our concepts to work in a similar way to our minds where there's no arbitrary syntax, but rather a completely structural approach is taken.

Generic organisation

Applications and organisations are essentially very simple in structure compared to the kinds of problems that computability theory and Turing machines were devised to deal with. We know from experience that such structures are already heavily recursive in that a department, branch office or even a role of an organisation can itself be seen as an organisation, and this can be carried on down into the programming structure of the applicational tools used by the organisation. So the idea is to find a set of components which apply to organisations in general which can be used recursively so that the same set of components can be used to describe all levels from programming details up to management decisions.

When we take a closer look at the workings of organisations and project management, we see a definite set of generic concepts with which to begin our unification process: budgetting, cashflow, stock, storage & distribution, scheduling, production etc. These concepts really are generic to all organisation no matter what the specifics of their operations, and we could also describe any computer application as such an organisation too. But we haven't gone to basic enough components yet because the preceeding list is really just another list of organisations which still need more refined description before our basic components are revealed.

Resource & Spectrum

Breaking down these sub-organisations moves us into more abstract teritory - booking, statistics, processing, transport, storage, which themselves can really be thought of as specifically refined versions of Resource and Spectrum.

  • Resource is the division and allocation process based on previous and future cycles from its connections into spectrum (field of cycles)
  • But the structure of spectrum is itself very similar to resource because its the booking from the field of cycles.
  • There can by any number of "clients" associated with each cycle (they're loops which are hooked into reduction).

Real-world organisation

This is primarily aimed at the small business scale at the beginning, not corporations. A number of organisations in different sectors have been observed so that some useful and complete templates can be made.

  • Computer repair
  • Network administration
  • Retail (online and shopfront)
  • Catering
  • Tuition and Lecturing
  • Functions and Seminars

All solutions and ways come from the metaphors of computerless organisations of all sorts; factories, warehouses, offices, businesses etc. It's not in any way against technology, it's simply that any system no matter how complicated doesn't need to depart from the fundamentals for completeness of description, even quantum field theory.

Concepts like space, time, energy, matter/information while being very low-level are still well known to everyone. Or higher level ones like resource, role, commitment, schedule are easily understood. It's only when we need to depart from such general terms to describe the inner workings of these things that confusion begins. But here we set up a simple system consisting of only such general terms. The aim is to have an accessible method of modelling and managing organisations in terms of this common pattern.

Taken as a whole, the system is very complex, but really it's the same pattern operating over many levels at once. Organisations modelled in this way work in harmony both within and outwards, so within the context of this project and the philosophies its based on, the words organisation and organism are practically synonymous.

An important aspect of the philosophical foundations of the project is self containment, independence. One special part of self-containment for development environments is self-description. Afterall, any runtime environment is really an organisation a lot like a factory, and since the software is about modelling organisations, it's own description can then also be its own proof of concept, from the fact that its running from that description.


Class/Instance

Nodal Reduction

In the nodal model the nodal reduction process distributes quanta of executional energy amongst the nodes in the tree of current loops starting at the root node of the node space.

These current loops can be considered as a collection of roles which perform particular jobs within their context of associations. In this way, roles can be "passed around" amongst the contexts that need them, or items needing specialised kinds of work done on them could be placed in to a context containing the roles required.

There's no actual movement involved in this "passing around" process though, because its all achieved by adjusting references to the workflow or role nodes, not manipulating the nodes themselves.