Shared agreements — formalised as specifications — about how to
structure, represent, and exchange information, enabling systems
built by different people, at different times, in different places,
to work together.
What is it?
A standard is what happens when a community of engineers stops
arguing and starts agreeing. It’s a published specification that
defines a common way to solve a recurring problem: how to format
data (JSON, XML), how to transfer it (HTTP, TCP/IP), how to
represent knowledge (RDF, OWL), how to query it (SQL, SPARQL),
or how to secure it (TLS, OAuth).
Standards are not laws — no one is forced to use HTTP. But they
create network effects: the more systems adopt a standard, the
more valuable it becomes for everyone. This is why the internet
works. Your browser can talk to any web server because both agree
on HTTP. Your API can exchange data with any client because both
agree on JSON. Your knowledge graph can interoperate with other
graphs because both agree on RDF triples.1
The deeper insight is that standards are epistemological agreements.
When the W3C publishes the RDF specification, it is making a claim
about the structure of knowledge itself: that any fact can be
decomposed into a subject, a predicate, and an object. When the
IETF publishes HTTP, it is making a claim about the structure of
communication: that every interaction can be decomposed into a
request and a response. Standards don’t just solve technical
problems — they encode a community’s shared understanding of how
a problem domain is structured.2
For developers, understanding standards is not about memorising
specifications. It’s about understanding why a problem was
decomposed the way it was, and what guarantees the standard
gives you when you adopt it.
In plain terms
Standards are like the rules of a language. Grammar and vocabulary
are “standards” that let millions of people who have never met
communicate clearly. No one person invented English grammar — it
emerged from shared use and was later formalised. Technical
standards work the same way: shared patterns that emerge from
practice, get formalised by a body, and enable communication
between systems that have never met.
At a glance
The standards ecosystem (click to expand)
graph TD
A[Problem Domain] -->|community identifies recurring problem| B[Informal Conventions]
B -->|patterns stabilise| C[Draft Specification]
C -->|review and consensus| D[Published Standard]
D -->|adoption| E[Interoperable Systems]
E -->|new problems emerge| A
F[Standards Bodies]
F --> G[IETF — Internet protocols]
F --> H[W3C — Web standards]
F --> I[IEEE — Hardware and networking]
F --> J[ISO — International standards]
F --> K[ECMA — Programming languages]
style D fill:#4a9ede,color:#fff
Key: Standards emerge from practice, are formalised through
consensus, and create interoperability. The cycle is continuous —
new problems lead to new standards. Different bodies govern
different domains.
How does it work?
Why standards exist
Every domain in computing faces the same fundamental problem:
multiple independent parties need to agree on how to structure
something so their systems can interoperate. Without agreement,
every integration is a custom translation layer, every data exchange
is a negotiation, and every new participant must learn a proprietary
format.1
Without standards
With standards
Every API defines its own data format
Everyone uses JSON or XML
Every database has its own query syntax
Everyone uses SQL
Every browser-server pair has its own protocol
Everyone uses HTTP
Every knowledge system has its own schema
Shared ontologies like Schema.org
Every document links differently
URLs and hyperlinks (URI standard)
Think of it like...
Imagine if every country used a different shaped electrical plug,
a different voltage, and a different frequency. Oh wait — they
do. And it’s terrible. Now imagine if every computer system used
a different data format, a different transfer protocol, and a
different addressing scheme. Standards prevent that chaos from
spreading to software.
The anatomy of a standard
A standard typically defines:
Vocabulary — the terms and their precise meanings (e.g.,
“resource,” “representation,” “triple”)
Structure — how data is organised (e.g., Subject-Predicate-
Object in RDF, key-value pairs in JSON)
Rules — constraints on valid usage (e.g., a JSON key must be
a string, an HTTP method must be one of GET, POST, PUT, DELETE…)
Serialisation — how the structure is encoded as bytes or text
(e.g., JSON-LD serialises RDF triples as JSON)
Extensibility — how the standard can be extended without
breaking existing implementations (e.g., HTTP headers, JSON-LD
contexts)
Developer rule of thumb
When evaluating whether to adopt a standard, ask three questions:
(1) Who governs it? (2) How widely is it adopted? (3) What
guarantees does it give me? A standard governed by a respected
body, widely adopted, and with clear guarantees is almost always
worth the learning cost.
How standards are made
Different bodies follow different processes, but the pattern is
remarkably consistent:3
Stage
What happens
Example
Problem identification
Community recognises a recurring problem
”We need a standard way to represent knowledge as graphs”
Informal conventions
Practitioners develop ad-hoc solutions
Early knowledge bases use proprietary formats
Draft specification
A working group writes a formal proposal
W3C RDF Working Group publishes a draft
Community review
Open comment period, revisions, debate
Public feedback on RDF 1.0 draft
Consensus and publication
The body approves and publishes
RDF becomes a W3C Recommendation (1999, revised 2004, 2014)
Adoption and iteration
Industry implements, edge cases emerge
JSON-LD (2014) adds a JSON-friendly serialisation of RDF
The IETF process is particularly influential. Internet standards
begin as Requests for Comments (RFCs) — documents that propose
a specification and invite the community to critique it. An RFC
progresses through stages: Proposed Standard → Draft Standard →
Internet Standard. The famous motto: “We reject kings, presidents,
and voting. We believe in rough consensus and running code.”3
Concept to explore
The relationship between standards and contracts-and-interfaces
is deep: a standard is essentially a contract that the entire
community agrees to. An API contract is a standard with an
audience of two (client and server). A W3C Recommendation is a
contract with an audience of billions.
Standards as epistemological commitments
Here is the insight that connects standards to knowledge engineering.
When a community agrees on a standard, it is making a claim about
the structure of a problem domain:2
Standard
Epistemological claim
RDF
Any fact can be decomposed into (Subject, Predicate, Object)
HTTP
Any interaction can be decomposed into (Request, Response)
SQL
Any queryable data can be organised into (Tables, Rows, Columns)
JSON
Any structured data can be represented as (Objects, Arrays, Values)
TCP/IP
Any network communication can be layered into (Application, Transport, Internet, Link)
URI
Any resource can be uniquely identified by a structured string
These are not neutral engineering choices. They are ontological
commitments — decisions about what the fundamental units of a
domain are and how they relate. RDF’s Subject-Predicate-Object
structure is a philosophical position about the nature of facts.
HTTP’s Request-Response model is a philosophical position about
the nature of communication.4
Why this matters
When you adopt a standard, you are adopting its worldview. If
you represent knowledge as RDF triples, you are committing to
the view that knowledge is a graph of atomic claims. If you
represent it as JSON documents, you are committing to the view
that knowledge is a hierarchy of nested properties. These
commitments shape what your system can express, what it struggles
with, and what it cannot represent at all.
For example: choosing between RDF and JSON
You’re building a knowledge system. You must choose a format:
Weakness: relationships are implicit (embedded), cross-
document links require conventions
Neither is “better.” Each encodes a different epistemological
commitment about what knowledge looks like. Your choice
determines what questions are easy to ask and what questions
are hard.
The standards landscape for developers
Domain
Key standards
Governed by
Web
HTTP, HTML, CSS, URL
W3C, IETF
Data exchange
JSON, XML, CSV, YAML
ECMA (JSON), W3C (XML)
Knowledge representation
RDF, OWL, SPARQL, JSON-LD
W3C
Databases
SQL
ISO/IEC
Networking
TCP/IP, DNS, TLS
IETF
Programming
ECMAScript (JS), Unicode
ECMA, Unicode Consortium
AI/ML
ONNX, MLflow, PMML
Linux Foundation, W3C
Identity
OAuth 2.0, OpenID Connect, JWT
IETF, OpenID Foundation
Structured data on the web
Schema.org, JSON-LD, Microdata
Schema.org community, W3C
Why do we use it?
Key reasons
1. Interoperability. Standards let systems built by different
people, in different languages, on different platforms, communicate
without custom integration. This is the internet’s superpower.
2. Reduced cognitive load. Once you learn JSON, you can work
with every API that uses it. Once you learn SQL, you can query
every relational database. Standards are knowledge that compounds.
3. Ecosystem leverage. Standards attract tooling: parsers,
validators, libraries, editors, debuggers. Choosing a standard
means inheriting an ecosystem. Choosing a proprietary format
means building everything yourself.
4. Longevity. Proprietary formats die with their companies.
Standards outlive their creators. HTTP is from 1991. SQL is from
1974. TCP/IP is from 1983. Your code using these standards will
still work decades from now.
When do we use it?
When defining how your system exchanges data with other systems (APIs, exports, imports)
When choosing a format for storing structured knowledge (JSON, RDF, XML)
When designing a knowledge representation (ontologies, schemas, taxonomies)
When building integrations between independently developed systems
When evaluating technology choices — prefer standards-backed options over proprietary ones
When deciding how to decompose a problem domain into formal structures
Rule of thumb
Before inventing your own format, protocol, or convention, check
if a standard already exists. If it does, use it — even if it’s
not perfect. The network effects of adoption almost always
outweigh the cost of imperfect fit.
How can I think about it?
The shipping container analogy
Before the 1950s, every port loaded cargo differently. Ships were
packed by hand, unloaded by hand, and repacked for trucks and
trains. It was slow, expensive, and error-prone.
Then Malcolm McLean standardised the shipping container: a
single, uniform box that fits on ships, trucks, and trains
without repacking. The container didn’t change what was shipped —
it changed how everything connected.
Container dimensions = data format specification (JSON, XML)
Corner fittings = interface contract (API schema)
ISO standard = published specification (RFC, W3C Rec)
Standards are shipping containers for data. They don’t change
what you’re saying — they change how efficiently it can be moved,
combined, and understood by systems you’ve never met.
The musical notation analogy
Western musical notation is a standard. It encodes pitch
(vertical position), duration (note shape), dynamics (markings),
and tempo (BPM) in a format that any trained musician can read —
regardless of their instrument, language, or era.
A piece written in 1750 can be performed today because the
standard has persisted. A French violinist and a Japanese pianist
can play together because they share the notation.
Staff and clef = data structure (the schema)
Notes and rests = data values (the content)
Time signature = protocol rules (constraints)
Dynamics markings = metadata (context)
Universally readable = interoperability
Without the standard, every composer would invent their own
notation, and collaboration would be impossible. The same is
true for software systems without shared data standards.
A broken link is a placeholder for future learning, not an error.
Check your understanding
Test yourself (click to expand)
Explain — Why do standards create network effects? How
does adoption by more participants increase the value of a
standard for everyone?
Name — What are the five components that a standard
typically defines (vocabulary, structure, rules, serialisation,
extensibility)?
Distinguish — What is the difference between a standard
(a community agreement) and an API contract (a bilateral
agreement)? When might you prefer a custom contract over an
existing standard?
Interpret — RDF decomposes facts into (Subject, Predicate,
Object). JSON decomposes data into (Objects, Arrays, Values).
For a system that needs to answer multi-hop relational queries
(“what is the capital of the country that borders X?”), which
standard is a better fit, and why?
Connect — How does the concept of “epistemological
commitment” in standards relate to the concept of ontology in
knowledge engineering?
Where this concept fits
Position in the knowledge graph
graph TD
A[Software Development] --> B[Standards and Protocols]
A --> C[Software Architecture]
C --> D[Contracts and Interfaces]
B --> E[RFC Process]
B --> F[W3C Standards]
B --> G[Open vs Proprietary]
D -.->|"standards are community-wide contracts"| B
style B fill:#4a9ede,color:#fff
