Foundation ontology

From Organic Design wiki
Revision as of 01:25, 17 April 2016 by Nad (talk | contribs) (rv, put in wrong article)
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