1. Data that carries its own context
Most structured data formats tell a machine what a value is. AODM also records where it came from, how confident you are, when it is valid, and whether it was measured or inferred. Those four things are the difference between data a system can merely ingest and data it can use responsibly.
2. Stale knowledge announces itself
Validity windows are part of the format, so a figure superseded by a later revision does not keep circulating as though it were current. Expired knowledge is filtered out of present-tense queries while remaining on record, which means you can still answer “what did we believe last March, and on what basis?”
3. Quantities survive the trip
A measurement written as <aodm:value number="1.2" unit="Cel"
tolerance="0.1"/> arrives at the far end as a number, a unit and a
tolerance. Written as prose, it arrives as a string that every consumer has to parse
for itself, differently, and occasionally wrongly. Unit confusion is one of the more
expensive classes of engineering error, and this removes the opportunity for it.
4. Negation is expressible
“This component does not require coolant” and “we have no information about coolant” are different statements. Formats without an explicit negation collapse them into the same silence, and systems built on top then answer confidently where they should decline. AODM keeps them distinct, and requires that processors either honour that distinction or reject the document rather than quietly misread it.
5. Conclusions can be traced and retracted
Because inferred statements record what produced them, invalidating a source lets you find every conclusion that transitively rests on it. Without that, a retracted input leaves its consequences scattered through the knowledge base with nothing linking them back.
6. Duplicates collapse
Content digests let the same statement arriving from two pipelines be recognised as one statement. Ingest pipelines stay clean without bespoke deduplication heuristics at every entry point.
7. Lightweight and dependency-free
Markup is plain text with no runtime requirement: a few hundred bytes per tag, and
static markup that standard tooling (XPath, DOM parsers, lxml, any JSON
library) reads without special support. Nothing has to execute for the data to be
readable.
8. Formally specified and testable
An XML Schema, a JSON Schema, a written rule set for the constraints schemas cannot express, and a conformance suite that exercises them. Two named conformance levels mean an implementation can state precisely what it supports, and you can check the claim.
9. Implementation-independent
The specification is the definition, not any particular parser. Anyone can build a compatible implementation from the published documents, which is a precondition for a format becoming a standard rather than a product.
10. Backward compatible by construction
The quality features are optional attributes on existing elements, so a simple consumer that ignores them still parses documents correctly. Adopting AODM incrementally is possible: start with entities and facts, add provenance and validity as your pipeline learns to use them.
How AODM relates to existing formats
AODM is not a replacement for the semantic web stack, and it is worth being precise about where it does and does not overlap.
| Format | Relationship | Where AODM differs |
|---|---|---|
| Schema.org Microdata / RDFa / JSON-LD |
Complementary | Schema.org describes page content for search engines and is far broader in vocabulary. AODM describes knowledge, and adds provenance, confidence, validity and derivation, which Schema.org does not model. Use both: Schema.org for rich results, AODM for the data layer underneath. |
| RDF / OWL | Complementary | RDF is more expressive and has a mature reasoning ecosystem. AODM is smaller and easier to adopt, and treats provenance and uncertainty as core rather than as reification patterns. AODM triples map cleanly onto RDF when you need that power. |
| JSON-LD | Complementary |
JSON-LD is a serialisation of linked data with an @context
indirection. AODM's JSON form is a fixed, closed schema, so a consumer needs
no context resolution to know what a field means.
|
| Microformats | Alternative | Microformats overload HTML class names. AODM uses namespaced elements with a real schema and validation, and supports nesting and typed values. |
Raw JSON or XML in <script> tags |
Alternative | Ad-hoc embedded blobs have no shared schema, so every publisher invents their own shape and every consumer writes a bespoke parser. AODM standardises the shape and makes documents checkable. |
The honest summary: if you need full description-logic reasoning over a large ontology, use RDF and OWL. If you need search-engine rich results, use Schema.org. AODM is for the case in between — moving trustworthy, traceable knowledge between systems without adopting a heavyweight stack to do it.