Holon Data Loader #276
Replies: 15 comments 11 replies
-
|
As discussed in a July 7 meeting: |
Beta Was this translation helpful? Give feedback.
-
Revised Holon Loader DesignIf we assume tauri/Conductora client architecture we have ability to leverage the Nursery and Transient Holon Manager on the client-side via a (new) Conductora Dance interface. This interface essentially wraps the holons_core api in lightweight dances. Let's say JSON Parser maps JSON to Transient Holons that are created through Conductora Dances (whose dancer is client-side). Three Holon Types:
The Loader SchemaThe parsed JSON input is represented as Holons and Holon Relationships described by the types that are components of the HolonLoaderSchema. The JSON definition of these types is included as independently maintained comments on this Discussion. This schema defines three HolonTypes:
✅ Updated Loader Architecture OverviewClient (Tauri App)
Guest (holons_guest)
💡 Why This Works Well
🔁 Reference Resolution DanceThe
|
Beta Was this translation helpful? Give feedback.
-
Loader Property Types |
Beta Was this translation helpful? Give feedback.
-
Loader Relationship Types |
Beta Was this translation helpful? Give feedback.
-
Loader Holon Types |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that ProxyId and HolonId properties above use a |
Beta Was this translation helpful? Give feedback.
-
|
Here's the output of these types after being input into our source of truth in Airtable and processed back into JSON: |
Beta Was this translation helpful? Give feedback.
-
|
@evomimic I noticed you've been adding ".Type" or ".PropertyType" to most of your example TypeDescriptor definitions, so I used the |
Beta Was this translation helpful? Give feedback.
-
|
@owleyeview : I arrived at what I think is a good solution to the issue we discussed this morning of somehow conveying the fact that LoaderHolons will have properties and relationships not enumerated in the LoaderHolon TypeDescriptor (because, literally ANY type of Holon can be imported). Proposed SolutionI propose we follow the precedent of JSON Schema and OpenAPI and add a couple of boolean properties to HolonType definitions that indicate whether instances of that HolonType are allowed to include additional properties or additional relationships beyond those explicitly listed as InstanceProperties or InstanceRelationships for that HolonType. Extend our Metaschema
Update Definition of LoaderHolon Type.I've updated the definition of the HolonTypes for the LoaderSchema (see comment above) -- LoaderHolon sets both |
Beta Was this translation helpful? Give feedback.
-
|
@evomimic I noticed that the loader types listed here don't include |
Beta Was this translation helpful? Give feedback.
-
|
@evomimic I need some clarification around the The cardinality constraints of the A I think it would be simplest for each What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
I won't be adding related holons to the source of an inverse relationship. I will first find the declared counterpart and end up adding related holons to the target of the inverse relationship. The problem with this arrangement is that the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! One more question @evomimic : |
Beta Was this translation helpful? Give feedback.
-
|
ok I would like help build a feature to upload the core schemas on startup for the tauri app.. a feature to upload schemas via UI typescript interface using the same JsonHolonLoaderClient is a separate issue for me .. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for opening the conversation here, @nphias. I'll first provide a quick status update on the Holon Data Loader. Then I'll offer my thoughts on your specific proposal. Holon Data Loader Status UpdateTL/DR: everything is either complete or the implementation is in progress except for the JSON Parser (Issue #292) and the Validator (Issue #269) (which is on hold). The diagram at the top of this discussion for reference is still an accurate depiction of the current design.
Comments on Feature to upload the core schemas on startup for the tauri appI have both architectural and practical concerns about this proposal. Architectural Concerns
Practical Concerns
Introducing app-startup schema loading adds significant unknowns before we’ve completed the core loader pipeline. Our immediate milestone is demonstrating end-to-end loading of both types and instances via the existing Holon Data Loader.
Even if an auto-loader worked for the core schema, it wouldn’t yet solve loading of domain or instance data. We’d still need the full loader capability. Delivering 2a or 2b covers BOTH initial schema load and ad hoc loads. ⸻ Options for delivery of Issue #292I want to tease apart two things:
Item 1 needs to be implemented regardless of packaging scenario. The loader job (2c) is problematic for the reasons noted above. But I'm fine with either (2a) or (2b), whichever is easiest. For that matter, I'm also neutral on whether (2a) or (2b) is implemented in TypeScript or Rust (client) . It can't be implemented in Rust Guest, because the WASM sandbox doesn't allow access to the local file system. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Holon Data Loader Design Specification
Summary
The Holon Data Loader will convert holon data presented in JSON files into Holons and HolonRelationships that are staged and committed to a (single) MAP Space using existing MAP APIs. Because all MAP types (e.g.,
PropertyType,HolonType,RelationshipType) are themselves holons, the Holon Data Loader can be used to load TypeDescriptors just like any other data — eliminating the need for a separate type-specific loader. Input files are syntactically validated against a JSON Schema to ensure they represent well-formed holons, properties, relationships and, eventually, dances.Validation of imported and holons and their properties and relationships against their Type Descriptors is triggered by standard Holochain validation callbacks. These callback functions, implemented in the
holons_integrity_zomeinvoke shared validation functions to actually perform the validations. All Holochain dependencies are isolated in the integrity zome so that the shared validation functions have no holochain dependencies.If the target space does not already contain all required TypeDescriptors (e.g.,
BookType,title,HAS_AUTHOR), they must be included as part of the import and loaded first. Since we do not yet have deployed instances of the MAP that persist data, all types and data required for an integration Test Case must be loaded as part of the test case itself. This includes importing the MAP Schema. Thus, the test case initialization includes the following steps:All four test steps use the same Holon Data Loader. Each step imports the type descriptors needed to validate the data imported in the subsequent step.
🧠 Design Principles
🔗 Expressing Holon Relationships Using
$refIn MAP’s JSON import format, every relationship target must be expressed using the
$reffield — a concise, string-based shorthand that captures the essential reference semantics in a human-friendly format.The
$refmechanism is the only supported way to reference other holons in the import format. Internally, the loader expands$refvalues into the appropriate reference type (HolonId,temp_key, orExternalId) for resolution.🧠 Motivation: The Reference Cases We Must Support
Relationship targets may fall into one of several categories:
type:key. Otherwise, it must be assigned atemp_keyfor intra-import referencing.The
$refstring format is designed to compactly express all of these cases using a small set of idiomatic prefixes.✅ Supported
$refFormats$refFormat"#key"key"#Emerging World""#Type:Key""BookType:future-primal""id:<HolonId>""id:uhCAkYmv...""@ProxyName:Type:Key""@Library:ArticleType:climate-effects""ext:<ProxyId>:<LocalId>""ext:uhCAkProxy...:uhCAkLocal..."🔍
$refParsing Rules#temp_keyid:ext:OutboundProxyIdandLocalId@Type:KeyThe loader must interpret each
$refstring according to these rules and resolve the reference accordingly.📘 Example Usage
{ "type_name": "BookType", "temp_key": "book-001", "properties": { "title": { "type": "MapString", "value": "Future Primal" } }, "relationships": [ { "name": "AUTHORED_BY", "target": { "$ref": "PersonType:charles-eisenstein" } }, { "name": "MENTORED_BY", "target": { "$ref": "#mentor-temp-001" } }, { "name": "CITED_IN", "target": { "$ref": "@ResearchLibrary:ArticleType:climate-effects-2024" } } ] }🧩 Process Overview
The following diagram shows the Holon Data Loading process.
🧭 Step-by-Step: MAP Holon Data Loader Flow
A: AirTable -> JSON Import Files
The following steps have an "A" prefix in the diagram.
Define Holons in Airtable -- For now, we are using Airtable as our source of truth for data imports. A user or domain expert defines holons, properties, and relationships as rows in a spreadsheet-like interface. NOTE: This is just one option — other JSON generation methods are possible.
Export CSV from Airtable -- Airtable exports the holon definitions into a CSV file, which contains structured tabular data for each holon, including properties, types, and relationships.
Convert CSV to JSON -- A Jupyter Notebook (written in Python) loads the CSV file and uses the MAP Holon JSON Generator to transform the rows into JSON-formatted Holon Definitions. These definitions conform to the MAP Holon Data Loader's expected schema.
C: JsonHolonLoaderClient
This is realized as TypeScript code within a HolonsClient Tauri container. The following steps have a "C" prefix in the diagram.
2 Run the JSON Schema Validator -- Before loading, the JSON input files are validated using a JSON Schema Validator. This ensures that the file:
The validated file represents well-formed Holons, Properties, and Relationships.
Parse and Prepare Holons -- The validated JSON is parsed into a Transient HolonLoaderBundle that contains Transient LoaderHolons as BUNDLE_MEMBERS. More precisely:
create_empty_transient_holondance (C4/C5)with_propertydances to add properties about the load as a hole (C4/C5)create_empty_transient_holondance (C4/C5)with_propertiesdance (treat "key" as a property and add it also) (C4/C5)The above process is repeated until all input files have been parsed.
Invoke the Holon Data Loader -- Once all parsing is complete, the TypeScript Loader Controller issues a
loaddance request to the Dance Caller.Delegate Dance Call to Guest -- The load dance is forwarded to the Guest via the Rust Clients' Dance Call Service. This is a heavier-weight protocol that ships session_state (StagedHolons and TransientHolons) to the Guest as part of the Dance Request.
Handle Dance Response -- the response includes session_state used to "re-inflate" the Guests Nursery and TransientHolonManager
The Rust client then issues an async response back to the JsonHolonLoaderClient indicating the status of the load request. Note that session_state is NOT included in this response. Details on the load dance response remain in the Rust Client's TransientHolonManager.
D: Guest-Side Dancing
G: Guest-Side Holon Loader Processing
The Holon Loader Controller choreographs the loading process in three phases.
Phase 1: Stage Holons and Queue LoadRelationshipReferences
Phase 2: Resolve and Stage Relationships
Phase 3: Commit
import_mapper.import_mapperuses information pulled from LoaderHolons to stage and populate the properties of the actual holons to load. LoaderRelationshipReferences are queued for processing in Phase 2. Note that staging requests are delegate by the Reference Layer to the Shared Objects Layer's Nursery.reference_resolverresolves HolonReferences (and the LoaderRelationshipReferences that depend on them).add_related_holonscalls on references to the holons staged in Phase 1 can populate their Declared Relationships.loader_controllerreturns aResult<TransientReference, HolonError>. On success, theTransientReferencepoints to aHolonLoadResponse(DanceResponseType) populated withResponseStatusCode,HolonsStaged,HolonsCommitted,ErrorCount, and optionalDanceSummary, with any per-item errors attached asHAS_LOAD_ERROR → HolonError. System-level failures use theErr(HolonError)path.V: Validation
Trigger Validation -- As part of the commit, the Holochain Conductor invokes validation actions. These hit the HolonNode Validation Hooks in the
holons_integrity_zome. The implementation of these hook functions converts the data into "holochain-independent" data structures in order to invoke the shared validation functions.Run Shared Validation Logic The hooks delegate to the Shared Holons Validator, which contains:
🧪 Validation and Error Handling
$refmust resolve to a valid holon by the end of Pass 2 (after all staged holons are registered).temp_keyand referenced via"#temp-key".✅ Validation Strategy
The diagram shows validation via Integrity Zome validation hooks. However, we have determined that only a very limited form of validation is possible here. The proper validation architecture is broader than just Holon Loader Validation and it is being addressed elsewhere.
🔮 Future Enhancements
$refstringsBeta Was this translation helpful? Give feedback.
All reactions