---
slug: oip-from-semantic-web
title: What OIP Should Take from the Semantic Web
canonical: https://miscsubjects.com/a/oip-from-semantic-web
---

<!-- hierarchy:nav -->
> **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`

