# What OIP Should Take from the Semantic Web slug: oip-from-semantic-web · https://miscsubjects.com/a/oip-from-semantic-web · tags: oip, kimi-import, self-explaining, voxel, lineages, oip-from-semantic-web · updated 2026-07-17T02:36:13.081Z > **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [OIP Lineages](https://miscsubjects.com/a/oip-from-lineages) › **What OIP Should Take from the Semantic Web** > > **Shelf:** OIP Lineages · **Traversal:** self-explaining · hierarchical · voxel-ready > **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1) # What OIP Should Take from the Semantic Web ## §SELF — oip-from-semantic-web **What this page is:** A list of Semantic Web technologies and principles that OIP adopts, plus the parts OIP explicitly rejects. **What it explains:** How machine-readable web data standards apply to OIP objects and why OIP uses only a subset. **Why read it:** To understand why OIP objects are described the way they are — and why some Semantic Web technologies are left out. ### What the Semantic Web Is The Semantic Web is Tim Berners-Lee's vision (articulated 2001–2010 and beyond) of a web where data is structured so machines can read and process it directly. Instead of HTML pages meant for human eyes, the Semantic Web publishes data in formats (RDF, JSON-LD) that software can parse, link, and reason over. The core idea: give every piece of data a persistent URI, describe it in a standard vocabulary, and link it to other data so machines can traverse the graph. ### Why It Matters The web succeeded for humans because pages link to each other. The Semantic Web attempted the same for machines. It partially succeeded: JSON-LD is widely used, schema.org markup is common, and Linked Data principles power knowledge graphs at major organizations. It partially failed: the full stack (OWL reasoning, RDF/XML, SPARQL endpoints at scale) proved too complex and slow for general use. OIP takes the parts that worked and discards the parts that did not. ### The Key Idea OIP objects should be describable in standard, machine-readable formats so any tool — not just OIP-native models — can discover what an object does, what parameters it accepts, and how to invoke it. The description format should be parseable by existing Linked Data tools. The description should not require a heavy reasoning engine or a complex ontology stack to interpret. ### What OIP Takes from the Semantic Web **JSON-LD for object descriptions.** JSON-LD (JavaScript Object Notation for Linked Data) is a JSON format that embeds semantic context. An OIP object contract written in JSON-LD is parseable as ordinary JSON by simple tools and as Linked Data by Semantic Web tools. This gives interoperability for free: a model can read it as JSON; a knowledge graph can ingest it as RDF. No format conversion needed. **URI as identity.** In the Semantic Web, a URI (Uniform Resource Identifier) is not just an address you look up. It is the permanent identifier of the thing itself. OIP applies this: every object, every receipt, every capability has a URI. The URI is the name of the entity. If you have the URI, you can refer to the entity unambiguously forever. **Graph traversal.** The Semantic Web organizes data as a graph of triples — subject, predicate, object. OIP's voxel graph (the structure of objects, receipts, and their relationships) should be exportable as RDF triples. An external tool should be able to query the graph with SPARQL-like queries: find all receipts for this object, find all objects created by this model, find all capabilities derived from this parent token. The graph is queryable. **Linked Data principles.** Tim Berners-Lee defined four Linked Data principles: (1) use HTTP URIs as identifiers; (2) return useful information when those URIs are looked up; (3) include links to other URIs; (4) use standard formats (RDF, JSON-LD). OIP follows all four. An OIP object URI returns the object's contract and current state when dereferenced. The contract includes URIs linking to related objects, receipts, and capabilities. **Hydra vocabulary.** Hydra is a lightweight vocabulary for describing web APIs in RDF. OIP uses Hydra's `Operation`, `supportedProperty`, and `statusCodes` to describe object contracts. `Operation` declares what actions an object supports. `supportedProperty` declares what parameters each action requires. `statusCodes` declares what responses the object can return. A model reading the contract knows, without trial and error, how to interact with the object. ### What OIP Does Not Take from the Semantic Web **OWL reasoning.** OWL (Web Ontology Language) is a formal language for defining complex ontologies and performing logical inference. It is powerful but slow. OWL reasoning engines can take seconds or minutes to classify a moderately complex ontology. This is acceptable for offline knowledge-base construction. It is unacceptable for runtime model interaction. OIP does not use OWL reasoning. **RDF/XML.** RDF/XML is the original W3C standard format for RDF data. It is verbose, difficult to read, and unpopular. JSON-LD supersedes it for all practical purposes. OIP uses JSON-LD exclusively. No RDF/XML. **The full Semantic Web stack.** The complete Semantic Web vision includes multiple layers: URIs, Unicode, XML, RDF, RDF Schema, OWL, rules, proof, trust. Each layer adds complexity. OIP takes the bottom layers (URIs, JSON-LD/RDF, basic vocabularies) and stops. It does not implement the upper layers because they add machinery without adding value for model-to-model interaction. ### The Boundary OIP takes the parts of the Semantic Web that make objects discoverable and interoperable. OIP leaves the parts that add complexity without practical value for runtime execution. The test is simple: if a technology helps a model find an object, understand its contract, and invoke it — OIP uses it. If the technology is designed for offline reasoning, ontology engineering, or philosophical completeness — OIP does not. ### Sources - Berners-Lee, Tim, James Hendler, and Ora Lassila. "The Semantic Web." *Scientific American,* 2001. (Original vision statement.) - Berners-Lee, Tim. "Linked Data — Design Issues." W3C, 2006. (The four Linked Data principles.) - Lanthaler, Markus, and Christian Gütl. "On Using JSON-LD to Create Evolvable RESTful Services." *WWW Companion,* 2012. (JSON-LD for API descriptions.) - Lanthaler, Markus. "Creating 3rd Generation Web APIs with Hydra." *WWW Companion,* 2013. (Hydra vocabulary.) --- ## Up the tree - [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry - [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map - [OIP Lineages shelf](https://miscsubjects.com/a/oip-from-lineages) — siblings on this shelf - [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels - [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol) ## Related on this shelf - [What OIP Should Take from Capability Security](https://miscsubjects.com/a/oip-from-capability-security) - [What OIP Should Take from REST](https://miscsubjects.com/a/oip-from-rest) ## Machine surfaces - Public page: `https://miscsubjects.com/a/oip-from-semantic-web` - JSON article: `https://miscsubjects.com/api/articles/oip-from-semantic-web` - OIP ask: `https://miscsubjects.com/api/dispatch?ask=What%20OIP%20Should%20Take%20from%20the%20Semantic%20Web` --- # What OIP Should Take from REST slug: oip-from-rest · https://miscsubjects.com/a/oip-from-rest · tags: oip, kimi-import, self-explaining, voxel, lineages, oip-from-rest · updated 2026-07-17T02:36:12.886Z > **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [OIP Lineages](https://miscsubjects.com/a/oip-from-lineages) › **What OIP Should Take from REST** > > **Shelf:** OIP Lineages · **Traversal:** self-explaining · hierarchical · voxel-ready > **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1) # What OIP Should Take from REST ## §SELF — oip-from-rest **What this page is:** A breakdown of which REST architectural principles OIP adopts, which it rejects, and what OIP adds that REST lacks. **What it explains:** REST's five core constraints and how OIP applies each one to model-to-model interaction. **Why read it:** To understand why OIP's design choices are not arbitrary — they extend a proven architectural style. ### What REST Is REST (Representational State Transfer) is an architectural style for networked systems defined by Roy Fielding in his 2000 doctoral dissertation. A RESTful system organizes interaction around resources, each identified by a URL, manipulated through a small set of uniform operations, and represented in a standard format. The server does not store client state between requests. ### Why It Matters REST became the dominant architecture for web APIs because it scales. Statelessness lets servers handle any request without knowing prior history. Uniform interfaces let clients interact with any resource the same way. Cacheability reduces load. These properties matter more, not less, when the clients are autonomous models rather than human-driven applications. ### The Key Idea OIP treats every model-deployed object as a resource and every interaction as a stateless, cacheable, self-describing operation against that resource. OIP does not copy REST wholesale. OIP extends REST's constraints to fit a world where the clients are models, the operations are work objects, and the proof of execution is a first-class entity. ### What OIP Takes from REST **The uniform interface.** REST says one endpoint handles all operations on all resources. OIP takes this to its limit: a single dispatch door (`/api/dispatch`) receives every invocation. The specific operation is determined by the capability token and object key carried in the request, not by the URL path. One door. All objects. **Statelessness.** Every request contains all information needed to process it. The server stores no client session, no connection context, no remembered state. OIP follows this: every invocation carries the full capability token and the full object key. The server does not need to know who sent the request or what they did before. The request is self-sufficient. **Resource identification.** Every resource in REST has a unique URL. OIP extends this: every object has a unique URL, every receipt has a unique URL, every capability token is bound to a unique object URL. The URL is not just an address. It is the permanent identity of the thing. **HATEOAS (Hypermedia as the Engine of Application State).** REST responses contain links to possible next actions, so a client can navigate the API without prior knowledge of its structure. OIP's §SELF blocks and capability records serve the same function for model consumption. A model receives a capability record and knows, from that record alone, what operations it can perform and where to send the next request. The response carries its own navigation instructions. **Cacheability.** REST responses carry metadata indicating whether they can be cached and for how long. OIP receipts are immutable — once created, they never change. An immutable receipt is infinitely cacheable. Any cache, anywhere, can store it forever without risk of stale data. ### What OIP Does Not Take from REST REST's emphasis on CRUD (Create, Read, Update, Delete). CRUD assumes the resources are data records to be stored and modified. OIP's objects are not data resources. They are work objects — running processes, active capabilities, executable contracts. An OIP object performs work; it is not a row in a table. The CRUD mindset misleads because it treats everything as storage. OIP treats everything as execution. ### What OIP Adds That REST Lacked **Capability tokens.** REST relies on external authentication (API keys, OAuth, session cookies) to decide who can do what. OIP embeds the authority in the token itself. The capability token is the permission. This is capability security, not identity security. **Receipts.** REST has no native concept of proof of execution. A REST response is a reply; an OIP receipt is a permanent, verifiable record that an operation occurred, signed by the executing object, stored at a URL, and referenceable forever. **Replay and repair.** REST operations are fire-and-forget. If a request fails, the client retries blindly. OIP's receipt lineage lets a caller trace an operation through every stage, detect where it diverged from expectation, and repair the specific failed step without re-executing the whole chain. **Model-readable contracts.** REST APIs require human-readable documentation (OpenAPI specs, etc.) that a model cannot interpret at runtime. OIP object contracts are structured so a model can read them, understand what operations are available, what parameters each requires, and what responses each produces — all without human intervention. ### Sources - Fielding, Roy Thomas. *Architectural Styles and the Design of Network-based Software Architectures.* Doctoral dissertation, University of California, Irvine, 2000. (Chapter 5 defines REST.) --- ## Up the tree - [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry - [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map - [OIP Lineages shelf](https://miscsubjects.com/a/oip-from-lineages) — siblings on this shelf - [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels - [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol) ## Related on this shelf - [What OIP Should Take from Capability Security](https://miscsubjects.com/a/oip-from-capability-security) - [What OIP Should Take from the Semantic Web](https://miscsubjects.com/a/oip-from-semantic-web) ## Machine surfaces - Public page: `https://miscsubjects.com/a/oip-from-rest` - JSON article: `https://miscsubjects.com/api/articles/oip-from-rest` - OIP ask: `https://miscsubjects.com/api/dispatch?ask=What%20OIP%20Should%20Take%20from%20REST` --- # OIP — OIP Lineages slug: oip-from-lineages · https://miscsubjects.com/a/oip-from-lineages · tags: oip, shelf, lineages, hierarchy, self-explaining, kimi-import · updated 2026-07-17T02:36:12.508Z > **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › **OIP Lineages** > > **Shelf size:** 3 self-explaining articles # OIP Lineages ## §SELF — oip-from-lineages **What this page is:** the shelf index for OIP Lineages in the OIP Thinker Reference tree. **What it explains:** every article on this shelf, linked for traversal. **Why read it:** enter one conceptual neighborhood without scanning the full hub. ## Articles on this shelf - [What OIP Should Take from Capability Security](https://miscsubjects.com/a/oip-from-capability-security) - [What OIP Should Take from REST](https://miscsubjects.com/a/oip-from-rest) - [What OIP Should Take from the Semantic Web](https://miscsubjects.com/a/oip-from-semantic-web) ## Up the tree - [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) - [OIP root](https://miscsubjects.com/a/oip) ## Sibling shelves - [Thinkers](https://miscsubjects.com/a/oip-thinkers) - [Protocol Concepts](https://miscsubjects.com/a/oip-protocol-concepts) - [OIP Lineages](https://miscsubjects.com/a/oip-from-lineages) - [Token Drop Guides](https://miscsubjects.com/a/oip-token-drop-guides) --- # What OIP Should Take from Capability Security slug: oip-from-capability-security · https://miscsubjects.com/a/oip-from-capability-security · tags: oip, kimi-import, self-explaining, voxel, lineages, oip-from-capability-security · updated 2026-07-17T02:36:12.249Z > **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [OIP Lineages](https://miscsubjects.com/a/oip-from-lineages) › **What OIP Should Take from Capability Security** > > **Shelf:** OIP Lineages · **Traversal:** self-explaining · hierarchical · voxel-ready > **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1) # What OIP Should Take from Capability Security ## §SELF — oip-from-capability-security **What this page is:** A list of capability security principles that OIP adopts and the additions OIP makes to the model. **What it explains:** How capability-based access control works and why OIP uses it instead of identity-based security. **Why read it:** To understand why OIP tokens work the way they do — and why they are safer than passwords or API keys. ### What Capability Security Is Capability security is an access control model where possession of a reference (a capability) grants the right to use a resource. There is no separate permission check, no role lookup, no identity verification. If you hold the capability, you have the authority. If you do not hold it, you do not. The model was formalized in operating systems research (Hydra, EROS, Capsicum) and later adapted for distributed systems. ### Why It Matters Identity-based security (username/password, ACLs, role lists) requires the server to know who you are and look up what you are allowed to do. This creates a central point of failure, a privacy leak, and a bottleneck. Capability security removes the identity lookup entirely. Authority travels with the request. This matters for OIP because models are not people. A model does not have a username. A model has a token. The token is the identity and the permission in one object. ### The Key Idea A capability token in OIP is an unforgeable, scoped, delegable, revocable reference to an object. It is not a password. It is not a session cookie. It is a cryptographic token that says: "whoever presents this may perform exactly these operations on exactly this object." The server does not check who you are. The server checks only that the token is valid and that the requested operation falls within the token's scope. ### What OIP Takes from Capability Security **Possession conveys authority.** The capability token is the permission. No separate ACL. No role check. No identity verification. If a model holds the token, it can invoke the object. If it does not hold the token, it cannot. The server does not need to know the model's name, origin, or trust level. It checks the token. **Unforgeable references.** Capability tokens are cryptographically random. They cannot be guessed, enumerated, or manufactured by clients. Only the server that issues a token can create valid tokens. Each token is bound at creation to a specific object and a specific scope. **Safe delegation.** A model that holds a token can pass it to another model. The receiving model gains exactly the authority encoded in the token — no more. It cannot use the token to access other objects. It cannot expand the token's scope. Delegation transfers only what the token already permits. **Attenuation.** A token holder can create a child token that is strictly narrower than the parent: fewer allowed operations, shorter expiry, fewer uses, tighter constraints. The child cannot exceed the parent. OIP v0.8 enforces this: every child token is a subset of its parent's scope. A model can give away only what it has, and only in a more limited form. **The confused deputy problem solved.** In identity-based systems, a trusted process operates with its own full authority. If an attacker tricks that process into performing an action on the attacker's behalf, the process uses its own authority to do something the attacker could not do directly. This is the confused deputy attack. Capability security eliminates it: authority is in the token, not in the process. A model presents a token; the server checks only that token. The model cannot act beyond any token it holds. **Membrane revocation.** Revoking a parent token invalidates all tokens derived from it — the entire subtree. OIP v0.8 implements subtree revocation. If a top-level token is revoked, every child, grandchild, and descendant token becomes invalid immediately. This makes revocation complete: there are no orphaned capabilities floating in the system. ### What OIP Adds to Capability Security **Web-native transport.** Classical capability systems were built for operating systems or closed networks. OIP uses URLs for objects, HTTP for transport, and JSON for messages. Capabilities travel over the same infrastructure as the rest of the web. **Receipt-based proof.** Traditional capability systems grant access but produce no record of use. OIP generates a signed receipt for every invocation. The receipt proves that the capability was exercised, by whom, when, and with what result. This transforms capabilities from access keys into auditable instruments. **Model-readable contracts.** Classical capabilities are opaque references — a number, a handle, a pointer. OIP capability records include structured metadata: what operations the token permits, what parameters each accepts, what the object returns. A model can read this metadata and understand what it is allowed to do without human documentation. **The convergence framework.** Capability security alone does not specify how multiple models coordinate their work. OIP adds the convergence framework: a protocol for models to propose, evaluate, and converge on shared outputs while each retains its own tokens and authority. Capabilities enable the security; convergence enables the coordination. ### Sources - Dennis, Jack B., and Earl C. Van Horn. "Programming Semantics for Multiprogrammed Computations." *Communications of the ACM,* 1966. (Early capability concept.) - Levy, Henry M. *Capability-Based Computer Systems.* Digital Press, 1984. (Comprehensive history.) - Miller, Mark S., et al. "Capability Myths Demolished." *SAPIR,* 2003. (Addresses common objections to capability security.) --- ## Up the tree - [OIP root](https://miscsubjects.com/a/oip) — protocol root, zero-context entry - [Thinker Reference hub](https://miscsubjects.com/a/oip-thinker-reference) — full hierarchy map - [OIP Lineages shelf](https://miscsubjects.com/a/oip-from-lineages) — siblings on this shelf - [Voxel graph article](https://miscsubjects.com/a/what-is-voxel-graph) — how pages link as voxels - [Self-describing protocol](https://miscsubjects.com/a/what-is-self-describing-protocol) ## Related on this shelf - [What OIP Should Take from REST](https://miscsubjects.com/a/oip-from-rest) - [What OIP Should Take from the Semantic Web](https://miscsubjects.com/a/oip-from-semantic-web) ## Machine surfaces - Public page: `https://miscsubjects.com/a/oip-from-capability-security` - JSON article: `https://miscsubjects.com/api/articles/oip-from-capability-security` - OIP ask: `https://miscsubjects.com/api/dispatch?ask=What%20OIP%20Should%20Take%20from%20Capability%20Security`