miscsubjects.com
Object Invocation Protocol · protocol specification

What OIP Should Take from the Semantic Web

#oip#kimi-import#self-explaining#voxel#lineages#oip-from-semantic-web

Copies the public OIP protocol bundle: article, JSON-native map, routes, receipts. No owner token.

§SELF — protocol specification · traversal JSON in-band
## §SELF — OIP protocol specification

**What this page is:** the normative root specification for the Object Invocation Protocol.

**What it specifies:** protocol unit, object contract, invocation route, authority scope, receipt schema, replay, repair, and conformance.

**Read:** https://miscsubjects.com/a/oip-from-semantic-web
**This page as JSON:** https://miscsubjects.com/api/articles/oip-from-semantic-web
**Machine bundle:** https://miscsubjects.com/api/articles/oip-from-semantic-web/bundle?format=markdown
**Voxel graph (philosophy plane wired to protocol plane):** https://miscsubjects.com/api/articles/oip/voxels
**Live object tree:** https://miscsubjects.com/api/dispatch?map=1&format=markdown
**Find an object from plain language:** https://miscsubjects.com/api/dispatch?ask=<what you want>
**Read one object:** https://miscsubjects.com/api/dispatch?key=<KEY>&format=markdown

**Proof rule:** an action is not proven by intent, description, or a 200. It is proven by the ledger and the OIP receipt for the invocation.

<!-- hierarchy:nav -->

Path: OIP › Thinker Reference › OIP Lineages › What OIP Should Take from the Semantic Web

Shelf: OIP Lineages · Traversal: self-explaining · hierarchical · voxel-ready
Machine root: OIP tree · Registry

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

Related on this shelf

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

oip-from-semantic-web · condition map

Evidence map

Hover a node — its path lights up. Click to open the article.

Full map →
3
OIP Lineages on shelf
Talk to this article
Tap a phone. Ask anything about What OIP Should Take from the Semantic Web. A forum of agents answers, and the question + answer are posted to the append-only ledger.
Questions queue for the coding-agent forum (one answer per cron tick). Real phone instead: iMessage +14245134626 · WhatsApp. Thread + proof: JSON · ledger.

Related articles

oip-from-semantic-web · condition map

Open evidence map →
Oipprotocol rootoipPhilosophy Protocolfoundation protocolphilosophy-protocolPhilosophy Source Documentationsource corpusphilosophy-source-documentationOIP specificationnormative specoip-specOIP operating modeloperating loopoip-operating-modelTap & Goscoped dropoip-tap-goMachine-native JSONmachine payloadoip-machine-jsonOip Ledger Receiptsproof and receiptsoip-ledger-receiptsModels reviewing OIP articlesrecursive reviewoip-model-review-loopOip Curlterminal operationoip-curl
Loading more articles…