Metaspaces

<THIS SECTION IS UNDER CONSTRUCTION>

A Metaspace consists of:

• a set of TypeDescriptors of various kinds

• an ontology for defining TypeDescriptors (i.e., a meta-ontology)

• a set of agents, some of whom have a stewardship role with respect to the Metaspace

• a set of services for managing and querying the TypeDescriptors in the Metaspace

• a set of governance rules that define the protocols, values and norms for managing the Metaspace

Metaspaces provide the descriptions for the self-describing active holons that comprise the foundation of all MAP objects. TypeDescriptors contain the information DAHN Visualizers require in order to present and allow interaction with MAP Holons and provide a common vocabulary for defining the Information Access Agreements that form a part of service offers and agreements. Thus, changing the definition of a TypeDescriptor could break existing visualizers and/or Information Access Agreements. Furthermore,

It is useful to think of a Metaspace as circumscribing an ecosystem of shared services and visualizers. Reusing these visualizers and agreements across different Metaspaces is problematic (it depends on mapping layers between Metaspaces). So having a large number of Metaspaces will tend to dilute efforts at sharing visualizers and standard agreement templates. But similar even within a single Metaspace, uncontrolled evolution of Type Descriptors could result in unnecessary proliferation of nearly identical Type Descriptors that works against reuse of Visualizers or Agreement templates. For exampe, imagine if 28 different Book Holon Types were defined. Or, their were 17 different bookTitle properties provided for a Book Holon Type.

In effect, the set of Type Descriptors can be thought of as a shared resource that benefit from stewardship. For this reason, the MAP treats Metaspaces as a commons. As noted in <section reference>, according to David Bollier, a commons is "a resource plus a defined community and the protocols, values and norms devised by the community to manage needed resources." In MAP terms, the "defined community" is a We-Space consisting of a set of agents and whose memetic signature is the protocols, values and norms devised by the community.

In keeping with the MAP's open-ended architecture, multiple Metaspaces can be defined that differ in any or all of the elements listed above. This allows freedom to experiment with different approaches to defining Metaspaces.

However, there is a cost for this freedom. DAHN Visualizers and Information Access Agreements both depend upon the services and TypeDescriptions provided by a Metaspace.

Holochain hApp that stewards a set of interrelated Type Descriptors as a commons. As noted in <section reference>, according to David Bollier, a commons is "a resource plus a defined community and the protocols, values and norms devised by the community to manage needed resources." In MAP terms, the "defined community" is a We-Space consisting of a set of agents and whose memetic signature is the protocols, values and norms devised by the community.

This means that Type Descriptors are seen as resources that are stewarded by a set of agents following a set of both formal and informal governance practices. Type Descriptors are evolved via a version-on-update principle using semantic versioning. Changes to Type Descriptors are categorized as either breaking changes or non-breaking changes. For example, adding a new property to a holon type is treated as a non-breaking change. Removing a property from a holon type is a breaking change, because their may be data access agreements or visualizers that depend on the existence of the property.

Type Descriptors are evolved by agents within their own private Meta-Spaces following a model patterned after git (ref). This allows concurrent evolution of Type Descriptors. without the need for centralized coordination.

Self-Describing Holons

Design Sketch:

• descriptors define the type system, independently of any specific values. Stated another way, multiple values can reference the same type descriptor (rather than copying it).

• A holon is a self-describing, active, independently identifiable entity.

• Each holon has a type-descriptor reference, an identifier, contains a collection of self-describing properties, offers a collection of actions, and can participate in various named relationships with other holons.

• A self-describing value is a directed graph (acyclic?).

• A self-describing value is a triple consisting of a symbol, a type descriptor reference (via IRI) and a value.

• The self-describing value can be a primitive (e.g., string, float, integer), a composite, a collection or a relationship(?)

• A CompositeValue is a collection of (symbol->selfDescribingValue) pairs.

• A ValueCollection is a homogeneous collection consisting of a single collectionTypeDescriptor and a collection of values, all of the same type. This is simply a storage optimization that saves having to store the type reference in each one of the values. When iterating over the collection, returns self-describing values. Is this storage optimization worth the extra complication?

• The map-holon-happ provides storage for self-describing holons.

• Other applications connect to the map-holon-happ via delegation rather than inheritance. That is, their types do not need to inherit from the MAP type system, but must include references to the holon type.can bridge to the map-holon-happ -- they do NOT need to inherit

• Semantic versioning

• Each holon is immutable

MAP Type Descriptors can be thought of as having an abstract syntax. They can be used to generate various concrete syntactic representations (e.g.,Holochain DNA yaml or toml files, Javascript/Rust class definitions, or OpenAPI interface definitions, RDF/OWL, etc.).

MAP TypeDescriptors describe types. An instance of a TypeDescriptor is a description of a particular Type, not an instance of the described type. This led me to add a "descriptor layer" to the L0 Ontology, in addition to the "Type" layer. So, for example, a Holon is a Type that can have sub-types and instances. The description of the HolonType is not the Type.

In addition to the Descriptors ontology, the MAP also needs to define a Holon Type with associated property map, action map and relationship MAP so that DAHN Do I even need the Type layer? In other words, if everything in MAP has a descriptor, do I need to have a separate Type object it is an instance of? When I did this with Biraj, we generated Java declarations from the type descriptions. My vision for MAP is that we can generate (say, Holochain DNA) and/or Java/Rust class definitions, or OpenAPI interface definitions, and or UML, RDF/OWL, etc. from the descriptors.

The MAP is :

• NOT focused on semantic reasoning

• is concerned with Human understandability more than machine understandability

• NOT fundamentally concerned with SemanticInteroperability

BFO types don't have properties, per se. But the "inhere_In" relationship type can be used to associate a BFO:Quality (which corresponds to MAP "Property") to a Holon (BFO:IndependentContinuant). Also... BFO doesn't explicitly model Relationships as first class types (from whcih sub-types can be derived).

All of the above are reasons why the MAP L0/L1 Ontology perhaps needn't be derived from an ULO. To promote semantic interoperability between, we may want to allow references to ULO entities from Type Descriptors, but not sub-typed from them. For that matter, it is not clear that the MAP L0 Ontology needs Types in addition to Type Descriptors. The MAP doesn't instantiate objects directly -- holochain does based on holochain DNA.

MAP needs Types because of its own hApps (memes, resource, agents, services)

Everything in the MAP needs to be self-describing in order for DAHN to work.

But BFO demonstrates that not EVERYTHING is a Holon, Action, Property or Holon Relationship. So even though MAP and BFO goals differ, mapping the L0 types (H,A,P,HR) to the BFO demonstrates they don't form a covering set of entities -- unless Holon maps to BFO:Entity. But in that case, it broadens the definition of holon beyond Koestler's use of the term. And I don't believe Koestler ever claimed EVERYTHING is holons -- that's just been my claim. But at this point, asserting equivalence between Holon and BFO:Entity seems the best path forward. But Holon Relationship Types need descriptors also,

CEPTR/SEMTREX

The semantic tree data structure is a concise, self-describing, and fractally composable way to represent both executable code and data in the CEPTR Virtual Machine. It employees an alternating format of symbol/structure pairs, where each structure can, itself, be a symbol/structure pair. Such structures can be "embodied" with values. For example a lat:float pair (lat is symbol, float is structure) can replaced with lat:42.4056 literal value. (The fact that 42.4056 is float seems to be lost in this replacement.) The same structure is used to represent objects and properties -- i.e., they don't draw the same hard distinction between Holon and Property that I have been in the MAP.

These trees work as an interchange format. In a sense, they are combining JSONSchema into the JSON object that includes values. However, there is no obvious way to (independently) assert schema information. Consider an Address type, for example. The semantic tree for a specific address would (could) include BOTH the fact that addresses consist of street numbers, street names, city, state, country, postal code, etc. but where is this separate schema information defined? And their "symbols" don't seem to be IRI's or URL's. Their simple structure labels don't seem to support meta-information like minLength, maxLength, pattern, etc. So I'm not finding a lot of answers to my MAP Ontology design questions in either Upper-Level Ontologies or CEPTR/SEMTREX.

Consider re-factor of L0 ontology to make make properties holons. Some are primitive. Relationship semantics include containment (the related holon's existence is dependent upon it's parent holon) and reference. The related holon may have independent existence. The relationship itself can also be "owned" by the referencing or referenced holon. Consider, for example, an agent's shipping address. The address itself is a geo-location that exists independently of its current tenant. The agent contains its shipping address relationship, but not the geo-location it references. All primitive holons are contained, and in that sense, confined within the membrane of their containing holon. Agent names, however, are fully contained -- i.e., both the agent->name relationship and string holon that is the target of that relationship are contained by the agent.

Containment is important within DAHN because contained relationships and holons are visualized within the holon's membrane and down its holarchy levels. Referenced holons are shown as interconnected, but not within. (exceptions? -- can "embedded" still be a visualization action of contained holons?)

map-meta-space hApp