Difference between revisions of "Foundation ontology"

From Organic Design wiki
m
(rv, put in wrong article)
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 [[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>
 
{{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 [[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 [[W:OOP|OOP]] paradigm was designed to allow software and systems to be designed where the description of the program which is interpreted and acted upon by the computer has a direct relationship with the high-level ''model'' of the system. [[W:Prototype-based language|prototype-based language]]s make objects even more isomorphic to the real world by allowing any collections of functionality and information to be used as either an [[instance]] or a [[class]] on which other instances are based. The [[web3|semantic web]] also extends the object paradigm by creating a universal concept network which can be knitted together in a uniform way to create standard ontologies.
  
== The logical layer ==
+
== The nework ==
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.
+
Computer networks are divided into two main conceptual levels, called the ''logical'' and the ''physical''. The former is the conceptual perspective such as directory or categorisation systems, and in our case the ontology. The latter is the structure of real resource making up the network such as processors, hard-drives and data connections. In our network the ''logical'' aspect is a [[web3|semantic network]] of [[node]]s, and the physical aspect is a [[peer-to-peer]] network composed of all the systems which run the [[software architecture|software]].
  
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.
+
== The interface ==
 +
The basis of interfacing with the ontology is using a "semantic browser", the equivalent of what the common browser is to the world wide web. A semantic browser is a [[viewer]] application which acts as a bidirectional interface between the ontology and the user. The ontology provides meaningful information to theviewer about how it can be interacted with by users and other services.
  
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.
+
We're currently (2012) working on a impliementing this system using the [[namecoin]] network as the [[peer-to-peer]] network of nodes because it offers inherent support for higher layers of functionality needed by [[trust group]]s such as [[privacy]] and [[trading]]. The new interface is called [[Namecoin SPA]] and is a [[Single Page Application]]. The SPA is a software pattern that's particularly well suited to a peer-to-peer nodal application.  
  
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.
+
== Semantic Structure of the Foundation Ontology (todo) ==
 +
*Globally unique references (URI)
 +
*Typed relationships between nodes (triple-space)
 +
*Relative addressing
 +
*[[Template]]s - [[class]]es and [[instance]]s and include the time aspect in their structure
  
== The physical layer ==
+
== Message oriented middlewares ==
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.
+
*[http://zguide.zeromq.org/page:all ZeroMQ]
  
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.
+
== The time aspect ==
 +
Collaborative "web 2.0" technologies such as [[w:Wiki|wiki]], [[Google Wave]], and even [[w:Blog|Blog]]s or [[Subversion]] show us the importance of incorporating the time-aspect into our systems. Project management systems, collaborative media playlists and [[groupware]] systems also have a strong time-aspect.  
  
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.
+
In fact the time aspect is fundamental to collaboration and therefore needs to be incorporated into the foundation ontology so that all aspects of the Platform can [[Evolution|evolve]] through collaboration.
  
== Class/Instance ==
+
The foundation ontology gives a [[trust group]] the ability to work like a kind of "persistent session" whereby information shared by a group is stored in a [[peer-to-peer network]] where group members can securely access and collaborate on their shared information.
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.
+
== Dichotomy ==
 +
{{:Dichotomy}}
  
 +
Every [[node]] can be seen as a context composed of other nodes which it inherits functionality from and new functionality it adds for its own specialised needs. If a node could be asked in plain English to describe itself it might say something like "I'm a combination of those things, but with these key differences".
  
== Relationships ==
+
So then each node has two general aspects, the '''container''' aspect, which concerns how it contains other nodes and inherits their functionality, and the '''contained''' aspect, which is the interface it provides to its environment (i.e. its field of action in the form of potential nodes it could be contained within) specifying what its requirements are for it to be able to be contained in other nodes.
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.
+
== Implementing System Requirements ==
 +
The next thing after this general semantic layer is defined in to define the components common to [[system]]s so that we can then start defining the higher level functionality required by the [[software architecture]] and [[platform specification]].
 +
{{section zero|System}}
 +
== Notes to merge ==
 +
We will create an ontology of content that will form the foundation structure of the network. This will be the initial high-level data set that the viewer application provides access to. We've designed a basic "template organisation" structure.
  
...
+
In any project or organisation the total number of members are always able to be divided into a hierarchy of sub-groups such as departments or roles. This hierarchy is always changing hence we use the term "[[OD:organic_group|organic group]]", because although many of the groupings are very static like the departments and roles, some of them undergo more change, such as members of particular projects or people sharing a common interest. We use the term "ontology" instead of just "hierarchy" or "taxonomy" because this structure of groups reflects the high-level reality of the organisation at any given time.
  
== Space ==
+
Each group has it's own home page, or "portal" which is tailored specifically to the needs of its members, firstly by being based on a template appropriate to the type of group it is (such as a department or a project), and secondly because it is easy for members to collaborate on what their portal should look like and which tools and resources should be available to them. Wikipedia's "Enterprise Portal" article is a good place to go for general information about this kind of portal.
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.
 
  
...
+
Some common tools used by such groups are blogs, forums, wiki pages, mailing lists, group decision-making tools (such as polls), project management tools, shared schedules, resource booking systems and online chat systems.
 
 
== 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:25, 17 April 2016

Glossary.svg This page describes a concept which is part of our glossary

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.

The OOP paradigm was designed to allow software and systems to be designed where the description of the program which is interpreted and acted upon by the computer has a direct relationship with the high-level model of the system. prototype-based languages make objects even more isomorphic to the real world by allowing any collections of functionality and information to be used as either an instance or a class on which other instances are based. The semantic web also extends the object paradigm by creating a universal concept network which can be knitted together in a uniform way to create standard ontologies.

The nework

Computer networks are divided into two main conceptual levels, called the logical and the physical. The former is the conceptual perspective such as directory or categorisation systems, and in our case the ontology. The latter is the structure of real resource making up the network such as processors, hard-drives and data connections. In our network the logical aspect is a semantic network of nodes, and the physical aspect is a peer-to-peer network composed of all the systems which run the software.

The interface

The basis of interfacing with the ontology is using a "semantic browser", the equivalent of what the common browser is to the world wide web. A semantic browser is a viewer application which acts as a bidirectional interface between the ontology and the user. The ontology provides meaningful information to theviewer about how it can be interacted with by users and other services.

We're currently (2012) working on a impliementing this system using the namecoin network as the peer-to-peer network of nodes because it offers inherent support for higher layers of functionality needed by trust groups such as privacy and trading. The new interface is called Namecoin SPA and is a Single Page Application. The SPA is a software pattern that's particularly well suited to a peer-to-peer nodal application.

Semantic Structure of the Foundation Ontology (todo)

  • Globally unique references (URI)
  • Typed relationships between nodes (triple-space)
  • Relative addressing
  • Templates - classes and instances and include the time aspect in their structure

Message oriented middlewares

The time aspect

Collaborative "web 2.0" technologies such as wiki, Google Wave, and even Blogs or Subversion show us the importance of incorporating the time-aspect into our systems. Project management systems, collaborative media playlists and groupware systems also have a strong time-aspect.

In fact the time aspect is fundamental to collaboration and therefore needs to be incorporated into the foundation ontology so that all aspects of the Platform can evolve through collaboration.

The foundation ontology gives a trust group the ability to work like a kind of "persistent session" whereby information shared by a group is stored in a peer-to-peer network where group members can securely access and collaborate on their shared information.

Dichotomy

Dichotomy is the name we give to the idea that all things in the universe are based on two fundamental objects which are related, and are themselves both based on a single primary object which is only implied but has no actualised existence. Regardless of the ultimate truth of this concept with regards to our own reality, it forms a very powerful and harmonious foundation on which to build our Foundation Ontology.

Every node can be seen as a context composed of other nodes which it inherits functionality from and new functionality it adds for its own specialised needs. If a node could be asked in plain English to describe itself it might say something like "I'm a combination of those things, but with these key differences".

So then each node has two general aspects, the container aspect, which concerns how it contains other nodes and inherits their functionality, and the contained aspect, which is the interface it provides to its environment (i.e. its field of action in the form of potential nodes it could be contained within) specifying what its requirements are for it to be able to be contained in other nodes.

Implementing System Requirements

The next thing after this general semantic layer is defined in to define the components common to systems so that we can then start defining the higher level functionality required by the software architecture and platform specification.

System: A system is a working description of entities and their interactions; i.e. an abstraction of people and the things they interact with). When a group of people work together in alignment toward a common vision, they become an organisation.

An important aspect of systems which is all too often forgotten is that it must be designed to account for the forces at play in its operating environment. In the same way that a physical machine must account in its design for forces such as gravity and momentum, so must an organisation or social mechanism account for the forces such as the conflicting goals of existing centralised systems, or peoples habits that are based on wide-spread false conceptions.

The most fundamental and dominant force is fragmentation which benefits the centralised, materialistic, self-oriented systems that emerge generally in our social mechanism in the form of the economic bottom line. So in our deployment of the common vision, we must ensure that our organisational infrastructure is properly designed to be deployed into a heavily fragmented and centralised environment which is in many cases overtly hostile to systems aligned towards unification.

The most common means that these opposed systems use to hinder alignment is through the use of legally binding contracts which in turn occur through the acceptance of benefits (i.e. there doesn't necessarily need to be a piece of paper with a signature involved for a legally binding contract to exist between parties). So independence is the key to being able to freely pursue the common vision.

In the context of OrganicDesign the group of people are a trust group and the fundamental kind of organisation they can choose to become is a Platform by implementing together the system defined by the Platform specification. [more]

Notes to merge

We will create an ontology of content that will form the foundation structure of the network. This will be the initial high-level data set that the viewer application provides access to. We've designed a basic "template organisation" structure.

In any project or organisation the total number of members are always able to be divided into a hierarchy of sub-groups such as departments or roles. This hierarchy is always changing hence we use the term "organic group", because although many of the groupings are very static like the departments and roles, some of them undergo more change, such as members of particular projects or people sharing a common interest. We use the term "ontology" instead of just "hierarchy" or "taxonomy" because this structure of groups reflects the high-level reality of the organisation at any given time.

Each group has it's own home page, or "portal" which is tailored specifically to the needs of its members, firstly by being based on a template appropriate to the type of group it is (such as a department or a project), and secondly because it is easy for members to collaborate on what their portal should look like and which tools and resources should be available to them. Wikipedia's "Enterprise Portal" article is a good place to go for general information about this kind of portal.

Some common tools used by such groups are blogs, forums, wiki pages, mailing lists, group decision-making tools (such as polls), project management tools, shared schedules, resource booking systems and online chat systems.

See also