Onyx
Ontologies and Extensibility of the System.
We are using the same system for Attributes/Ontologies and Extensibility.
I like Ontologies -> Software Development.
Blocker:
Schemas should be a resource in the Daemon.
Resources as the primary entity.
Plan
Inodes/Resources as the unified entity. (plugin system)
To make Agents a resource and integrate them.
General-purpose resource.
Schema first class
Permissions.
Revocations.
Schemas/ontologies.
Use Case: Agent Ontologies/knowledge Graph to use the software.
Agent Import Content
Agent looks at the schema.
Agent understands that it needs an Original Author.
and adds it to the exact field.
Use Case: Seed Team Software engineer
data types, RPC
Zod, protobuf
informally defined
typescript/go multiple definitions.
Reason on code base
We need to link to this information.
Use Case: Attributes Content
Data organization.
ONE: We want schemas on our attributes Constraints.
TWO: We want to use Ontologies to Augment Seed Team collaboration
We leave fixing the mess to use our ontologies
Too many things at once:
Attributes/Constraints
Define new things
blocks
rpc
documents
typescript/go
self-describing
meta
THREE: We need to formalize the protocol.
We will apply the schema to our own concept.
Enforcement is out of the question:
We don't need to do Protocol Formal Verification from the GetGo.
FOUR: Enforcement is a typescript error for now.
FIVE: Extend the system.
Are both shaping protocol data?
document metadata schema
seed code schemas
Are both in the same data category?
document.name is protocol, or document metadata schema?
Protocol/App is
Next Steps
Eric writes a document, on Thursday Workshop.
Guidance: Alex needs to understand.
Surface the disputes.
json schemas and lexicons were insufficent
etc
What are the problems?
Merge Onyx?
Protocol changes?
no protocol changes.
We are abusing documents:
we are saying that caps or booleans are documents, and they are not.
Start using Ontologies.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime