Why not just use Schema.org or JSON-LD?

Because they answer a different question. Schema.org and JSON-LD describe what a thing is. AODM describes what a thing is and how much you should trust the claim — where it came from, how certain it is, when it was true, and whether anyone observed it or a machine inferred it.

If you are marking up a product page so Google shows a price and a star rating, use Schema.org. It is mature, universally supported, and AODM does not replace it. If you are moving knowledge between systems — a retrieval pipeline, a model, a graph database, an engineering record — and something downstream will act on that knowledge, the trust metadata is the part you cannot afford to lose. That is the gap AODM fills.

The concrete difference

Here is the same claim in both formats. In JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "PropertyValue",
  "name": "Temperature rise under load",
  "value": "1.2"
}

A consumer learns there is a value of 1.2. It does not learn the unit, who measured it, how confident anyone is, when the measurement was taken, or whether a later revision superseded it. Every one of those has to be carried out-of-band, and every consumer invents its own convention for doing so.

The same claim in AODM:

<aodm:fact id="temp-rise" about="engine" valid-from="2026-01-15">
  Temperature rise under sustained load.
  <aodm:value number="1.2" unit="Cel" tolerance="0.1"/>
  <aodm:source uri="https://example.com/report-24" retrieved="2026-01-15"/>
  <aodm:confidence value="0.9"/>
</aodm:fact>

Degrees Celsius, plus or minus 0.1, from a named report retrieved on a known date, 90% confidence, valid from January 2026. A system reading this can decide whether to rely on it. A system reading the JSON-LD above can only decide whether to believe it, which is not the same thing.

What the alternatives do not model

Why not RDF, then?

RDF can express all of this. Provenance has PROV-O, uncertainty can be reified, temporal validity can be modelled. The objection is not capability, it is cost: doing it properly means named graphs, reification or RDF-star, an ontology stack, and a team that knows all of it. Most of the systems that need this — a RAG pipeline, an ingest job, an engineering export — will not pay that cost, so in practice they carry no provenance at all.

AODM makes the common case cheap. Seven elements, a schema, and provenance you get by default rather than by modelling effort. If you outgrow it, AODM maps onto RDF cleanly — entities and relationships are already subject-predicate-object triples.

Why not just put it in a vector database?

A vector store answers “what text resembles this query.” It does not answer “is this still true,” “who said it,” or “what else breaks if this source turns out to be wrong.” Embeddings also bind your knowledge to a particular model: re-embed with a different one and the representation is gone. AODM persists knowledge in a form that outlives the model that read it.

When you should not use AODM

It is worth being explicit, because a standard that claims to fit everything fits nothing:

• You need search engine rich results. Use Schema.org. AODM does nothing for you here.
• You need full description-logic reasoning over a large formal ontology. Use OWL.
• Your data has no trust dimension — no sources, no uncertainty, nothing that expires. Then AODM's main advantage is inert, and plain JSON is simpler.
• You need a mature ecosystem today. AODM is a young specification. Schema.org has two decades and every major search engine behind it. That is a real argument and you should weigh it.

The one-sentence version