Difference between revisions of "Foundation ontology"
(network and interface) |
(new structure started) |
||
| Line 1: | Line 1: | ||
| − | {{glossary}}<onlyinclude>A [[system]] of operating as an [[Evolution|evolving]] organisation is common to all nodes in the [[Ontology]], the conceptual structure of this kind of organisation that captures these principles of collaboration and [[self-governance]] is considered to be the [[Foundation Ontology]] for the [[ | + | {{glossary}}<onlyinclude>A [[system]] of operating as an [[Evolution|evolving]] organisation is common to all nodes in the [[Ontology]], the conceptual structure of this kind of organisation that captures these principles of collaboration and [[self-governance]] is considered to be the [[Foundation Ontology]] for the [[Organic Design]] system. The Foundation Ontology is a common form of organisation that spans both real-world organisation, and informational systems alike, it defines what it is to be a node in the unified [[Ontology]]. Since the Foundation Ontology defines the attributes that are common to all organisations in the [[Platform network|network]], it's important that the [[bottom line]]s designed in its [[system]] remain [[alignment|aligned]] with the [[core values]] and [[common vision]].</onlyinclude> |
| − | + | This article describes a software architecture that supports the Organic Design [[Organic Design vision statement|vision]] in accord with the [[core values]]. The general topology of this system is a nodal network where every node has a unique identifier and represents a specific persistent object. | |
| − | == The | + | == The logical layer == |
| − | + | The term ''object'' in the above short description is used in the sense of prototype-based object-oriented programming, where an object is effectively a container of properties, arbitrary content, other objects, and methods accessible via an API. So the informational structure of the object is essentially a hierarchical collection of key/value pairs like a JavaScript object. | |
| − | + | This network of objects is called the ''logical'' network layer and exists persistently regardless of the nodes coming and going in the physical layer of actual devices and processors. | |
| − | |||
| − | + | So far what we've described is quite a standard sort of network these days that's used in all sorts of projects, but one thing to bear in mind is that the ''keys'' and ''values'' (when thinking of the object as a collection of key/value pairs) can be hashes that refer to other nodes in the network, and that this is the usual way that they're used in our system. It's still fine to have keys and values of the usual textual kind too so that objects can contain any diverse content, but for the purposes of this article we should always think of them both as node references. | |
| − | + | To be more specific: The network is a peer-to-peer network of hashes similar to a DHT. The hashes are globally unique identifiers that contain an arbitrary set of related node-hashes where the connecting relation is also a node-hash (i.e. a triple-space). The target node can also be arbitrary text, or a URI allowing the nodes to effectively contain any kind of resource or content. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | == | + | == The physical layer == |
| − | + | The physical layer doesn't need to be discussed in any detail here, but suffice to say that the technologies composing the Internet of Things provides the perfect framework in which to host such objects, and ensures that any object has the ability to establish communications channels with any other object via the most efficient path. | |
| − | + | The physical layer is composed of actual real-world resources, and each of these resource-types and each physical instance of these types all have corresponding nodes in the logical network through which they are organised and managed. So we now have three conceptual sets of nodes: purely logical nodes, physical resource types and physical resource instances. | |
| − | |||
| − | + | These resources cover all types of processors, storage and bandwidth and cover all scales from processes running on a devices up to human roles working on machine. All of them are integrated into the network by having their methods connected into the logical network to be presented as a standard API that other nodes can interface with. | |
| − | The | + | == Class/Instance == |
| + | The process of creating a new node requires that it be an instance of another node, creating new completely empty nodes is not possible. This leads to the network being a tree structure with a root node. This means that all nodes in the network inherit the functionality of the root node. | ||
| − | + | Instances can have any amount of content added or even content removed, so the fact that they have to be based on something is not a limitation, but allows the network to keep track of what nodes have in common with each other and how they differ. | |
| − | |||
| − | |||
| − | + | == Relationships == | |
| + | The root node is also the one that implements the base relationship functionality that comes from a node being connected to other nodes. | ||
| − | + | The entire effect that the relationship has on the end-nodes of a relationship is done by the relationship node. This is the basis of the "action not opinion" value, the meaning of a relationship is a description of what it does. | |
| − | The | ||
| − | |||
| − | |||
| − | |||
| − | + | ... | |
| − | + | == Space == | |
| + | All the types of resource are organised into a tree, and nodes can "own" a certain amount of any of these. All these resources are able to flow around the network through channels (which are also resources) that connect the instances of resource. All these resources can be connected by their APIs with simple connector scripts (either on or off chain depending on context). Nodes can be made into complex hierarchical structures of services and contracts to represent larger-scale functionality such as organisations. | ||
| − | + | ... | |
| + | |||
| + | == Time == | ||
| + | The scheduling method by which these services interact with each other over time is encoded purely by the semantic relationships between them. This scheduling aspect covers parallel and serial structure of order as well as event-based connections. A normal schedule is a bunch of "slots" of time and resource into which specific instances are allocated. | ||
| + | |||
| + | In this system the same is true, where the slots are specified in terms of roles, and they're organised in a semantic relational network specifying order, hierarchy and events instead of just the normal linear timeslots. The nodes are the resource instances, but the way they're connected together forms the energy aspect. | ||
| + | |||
| + | == Energy == | ||
| + | An energy-oriented view of any node is available since its resource usage over time is known. This gives rise to the ability to budget (cache) and determine the total active and potential energy of a node. What products and services its possible to perform and what profit and loss this entails. | ||
| + | |||
| + | == Organisation == | ||
| + | The way all the aforementioned functionality works is encapsulated into the [[generic organisation]] node, which is the most general template for starting a new organisation, ether at the computer process scale, or the real-world people-oriented scale. | ||
| + | |||
| + | == Interface == | ||
| + | The [[viewer]] is the default generic organisation at the computer process level, and the [[trust group]] is the default real-world people-centric generic organisation. After trust groups are more refined we'll start defining [[platform]] more clearly which brings physical operating premises into the equation. | ||
== See also == | == See also == | ||
Revision as of 01:21, 17 April 2016
|
A system of operating as an evolving organisation is common to all nodes in the Ontology, the conceptual structure of this kind of organisation that captures these principles of collaboration and self-governance is considered to be the Foundation Ontology for the Organic Design system. The Foundation Ontology is a common form of organisation that spans both real-world organisation, and informational systems alike, it defines what it is to be a node in the unified Ontology. Since the Foundation Ontology defines the attributes that are common to all organisations in the network, it's important that the bottom lines designed in its system remain aligned with the core values and common vision.
This article describes a software architecture that supports the Organic Design vision in accord with the core values. The general topology of this system is a nodal network where every node has a unique identifier and represents a specific persistent object.
Contents
The logical layer
The term object in the above short description is used in the sense of prototype-based object-oriented programming, where an object is effectively a container of properties, arbitrary content, other objects, and methods accessible via an API. So the informational structure of the object is essentially a hierarchical collection of key/value pairs like a JavaScript object.
This network of objects is called the logical network layer and exists persistently regardless of the nodes coming and going in the physical layer of actual devices and processors.
So far what we've described is quite a standard sort of network these days that's used in all sorts of projects, but one thing to bear in mind is that the keys and values (when thinking of the object as a collection of key/value pairs) can be hashes that refer to other nodes in the network, and that this is the usual way that they're used in our system. It's still fine to have keys and values of the usual textual kind too so that objects can contain any diverse content, but for the purposes of this article we should always think of them both as node references.
To be more specific: The network is a peer-to-peer network of hashes similar to a DHT. The hashes are globally unique identifiers that contain an arbitrary set of related node-hashes where the connecting relation is also a node-hash (i.e. a triple-space). The target node can also be arbitrary text, or a URI allowing the nodes to effectively contain any kind of resource or content.
The physical layer
The physical layer doesn't need to be discussed in any detail here, but suffice to say that the technologies composing the Internet of Things provides the perfect framework in which to host such objects, and ensures that any object has the ability to establish communications channels with any other object via the most efficient path.
The physical layer is composed of actual real-world resources, and each of these resource-types and each physical instance of these types all have corresponding nodes in the logical network through which they are organised and managed. So we now have three conceptual sets of nodes: purely logical nodes, physical resource types and physical resource instances.
These resources cover all types of processors, storage and bandwidth and cover all scales from processes running on a devices up to human roles working on machine. All of them are integrated into the network by having their methods connected into the logical network to be presented as a standard API that other nodes can interface with.
Class/Instance
The process of creating a new node requires that it be an instance of another node, creating new completely empty nodes is not possible. This leads to the network being a tree structure with a root node. This means that all nodes in the network inherit the functionality of the root node.
Instances can have any amount of content added or even content removed, so the fact that they have to be based on something is not a limitation, but allows the network to keep track of what nodes have in common with each other and how they differ.
Relationships
The root node is also the one that implements the base relationship functionality that comes from a node being connected to other nodes.
The entire effect that the relationship has on the end-nodes of a relationship is done by the relationship node. This is the basis of the "action not opinion" value, the meaning of a relationship is a description of what it does.
...
Space
All the types of resource are organised into a tree, and nodes can "own" a certain amount of any of these. All these resources are able to flow around the network through channels (which are also resources) that connect the instances of resource. All these resources can be connected by their APIs with simple connector scripts (either on or off chain depending on context). Nodes can be made into complex hierarchical structures of services and contracts to represent larger-scale functionality such as organisations.
...
Time
The scheduling method by which these services interact with each other over time is encoded purely by the semantic relationships between them. This scheduling aspect covers parallel and serial structure of order as well as event-based connections. A normal schedule is a bunch of "slots" of time and resource into which specific instances are allocated.
In this system the same is true, where the slots are specified in terms of roles, and they're organised in a semantic relational network specifying order, hierarchy and events instead of just the normal linear timeslots. The nodes are the resource instances, but the way they're connected together forms the energy aspect.
Energy
An energy-oriented view of any node is available since its resource usage over time is known. This gives rise to the ability to budget (cache) and determine the total active and potential energy of a node. What products and services its possible to perform and what profit and loss this entails.
Organisation
The way all the aforementioned functionality works is encapsulated into the generic organisation node, which is the most general template for starting a new organisation, ether at the computer process scale, or the real-world people-oriented scale.
Interface
The viewer is the default generic organisation at the computer process level, and the trust group is the default real-world people-centric generic organisation. After trust groups are more refined we'll start defining platform more clearly which brings physical operating premises into the equation.
