Finance and Commerce: FIBO, GS1 and schema.org
Commerce gives us three ontologies with three completely different business models, and the differences matter more than the axioms. FIBO is a consortium-governed enterprise ontology given away under a permissive licence. GS1 publishes free specifications while charging for the identifier space that makes them useful. Schema.org is a free web vocabulary whose value comes entirely from who reads it. Understanding which economics you are buying into is the difference between an integration that scales and a project that stalls at the licensing conversation.
FIBO: the enterprise ontology that actually shipped
The Financial Industry Business Ontology defines the things of interest in financial business applications and the ways they relate: legal entities and their ownership and control relationships, contracts, parties in roles, financial instruments, securities, derivatives, indices, market data concepts and the business and commerce foundations underneath. As of the 2026 first-quarter production release it contains 2,446 classes spanning Foundations, Business Entities, Finance Business and Commerce, Securities, Derivatives and Instruments.
It is hosted and sponsored by the EDM Council and also standardised through the Object Management Group. Development happens continuously in domain teams on GitHub, with formal production updates published quarterly and a browsable specification at spec.edmcouncil.org. The licence is MIT, which is worth pausing on: a consortium of banks publishes its shared financial semantics under one of the most permissive licences in software. There is no acquisition barrier at all.
What FIBO does for you concretely is provide the target model in a mapping exercise. A bank does not run FIBO; it maps trading, risk, compliance, reference data and client systems to FIBO concepts so that questions crossing those systems have one vocabulary. The contract-centric structure is the useful part: FIBO models a financial instrument as a contract between parties in roles, which is how regulation thinks, so exposure and obligation questions become graph traversals rather than reconciliation projects.
The clearest public deployment is the legal entity layer. The Global Legal Entity Identifier Foundation publishes its Golden Copy LEI reference data, both Level 1 entity data and Level 2 relationship data, as linked open data in RDF, with published ontologies whose semantics are linked to FIBO. That means anyone can pull a continuously maintained, globally scoped graph of legal entities and their parent relationships and join it to their own FIBO-mapped data without a commercial negotiation. It is the single best starting point for a finance knowledge graph proof of concept.
The honest warning: FIBO is large, and importing all of it is the most common failure. Take the modules you need, typically Business Entities and Foundations plus one instrument area, keep an explicit profile, and treat the rest as a reference you map to when the need arises.
GS1: identifiers first, semantics second
GS1 is not an ontology, it is an identification system that grew a semantic layer, and the order matters. The foundation is the identifier keys: the Global Trade Item Number for products, the Global Location Number for places and parties, the Serial Shipping Container Code for logistics units. Data capture sits on top through barcodes and electronic product code tags. Data sharing sits above that, and this is where knowledge graph practitioners come in.
EPCIS is the visibility event standard: a structured way to record what happened, when, where and why for a physical or digital object. Its event types cover object observation, aggregation into and out of containers, business transactions, transformation of inputs into outputs and association of objects with each other. The companion Core Business Vocabulary supplies the controlled terms for business steps and dispositions, so “shipped”, “received”, “in transit” and “damaged” mean the same thing across trading partners. EPCIS 2.0 was ratified in June 2022 and has been adopted as ISO/IEC 19987:2024, with the Core Business Vocabulary as ISO/IEC 19988. Version 2.0 added a JSON-LD representation, a REST API, sensor data elements and web URI identifiers, which is what turned EPCIS from an XML message standard into something you can load straight into a graph. The specifications are readable at the GS1 standards reference site.
The licensing reality is the interesting part. The specifications are free to read and implement. The identifier space is not: a company prefix, which is what makes your GTINs and GLNs globally unique, comes from GS1 member organisations on a subscription basis. So the vocabulary is open and the namespace is licensed, which is the inverse of the usual arrangement and a genuine architectural consideration if you plan to mint identifiers at scale.
The deployment proof is pharmaceutical traceability in the United States. The Drug Supply Chain Security Act required serialised item-level interoperable tracing from 27 November 2023. The FDA recommends but does not mandate a specific format, and the industry converged on EPCIS as the exchange standard, with GS1 US publishing implementation guidance to close interoperability gaps between trading partners. A national regulatory deadline delivered by an event-based semantic standard is about as concrete as supply chain ontology gets.
What breaks · the GTIN treated as the product’s identity
An integration keys everything on GTIN: one node per barcode, and every scan, order line and shipment attached to it. It works beautifully for catalogue and ordering, and then the recall arrives.
A GTIN identifies a product class, the trade item, not any particular thing on a shelf: every one of 400,000 identical units shares it. So when a single manufacturing lot must be recalled, the model has nowhere to put the answer, because lot, batch and serial are properties of instances the graph never represented, and the recall query returns “the product”, meaning all of it. The same collapse hits provenance, expiry and warranty, all of which are facts about individuals rather than about the class. This is lesson 1’s model-versus-unit ambiguity in commerce, and the standards themselves make the distinction available: GTIN for the class, serialised identifiers for the instances, with the class-instance relation modelled explicitly rather than assumed away.
Schema.org: the vocabulary the machines already read
Schema.org is the lightweight vocabulary embedded in web pages, usually as JSON-LD, that describes what a page is about: products, organisations, people, events, recipes, job postings, articles, courses. Version 30.0 was released on 25 March 2026 and the vocabulary now consists of 823 types, 1,529 properties, 19 datatypes, 96 enumerations and 535 enumeration members. It is licensed CC BY-SA 3.0 and stewarded by a community process backed by the major search companies, with the specification and examples published at schema.org.
Formally it is weak, and deliberately so: mostly types, properties and expected value ranges, with multiple domains and ranges permitted and very little logical commitment. Ontologists sneer at it, then discover it is by an enormous margin the most widely instantiated ontology in existence, because the incentive to publish is direct and commercial.
The strategic change since 2024 is that structured data has acquired a second consumer. Search engines have trimmed some traditional rich result types while confirming that structured data feeds generative search features, and the same markup that once earned a star rating in a search result now serves as a grounding signal for answer engines and AI crawlers. If your organisation cares about being cited accurately by an AI assistant, schema.org markup is the cheapest, most direct intervention available. It is an ontology deployment whose return on investment is measured in referral traffic.
| Standard | What it is and does | Maintainer | Licence and access | Real deployment |
| FIBO | Enterprise ontology of legal entities, contracts, instruments, securities and derivatives; the mapping target for internal systems | EDM Council, with standardisation through the Object Management Group | MIT licence on GitHub; quarterly production releases; 2,446 classes at 2026 Q1 | GLEIF publishes LEI Level 1 and Level 2 data as RDF linked open data with FIBO-linked semantics |
| GS1 identifier keys | Globally unique identification for products, locations, parties and logistics units | GS1 member organisations | Specifications free; company prefixes require GS1 membership subscription | Retail, healthcare and logistics identification worldwide |
| EPCIS 2.0 and CBV 2.0 | Visibility event model of what, when, where and why, with controlled business step and disposition vocabulary; JSON-LD and REST in 2.0 | GS1, adopted as ISO/IEC 19987:2024 and ISO/IEC 19988 | Specifications published openly by GS1; ISO texts paid | US Drug Supply Chain Security Act serialised traceability from 27 November 2023 |
| schema.org | Lightweight web vocabulary for pages and entities; 823 types and 1,529 properties at version 30.0, released 25 March 2026 | Community process backed by major search companies | CC BY-SA 3.0, free and public | Structured data on hundreds of millions of sites, now feeding generative search and AI answer engines |
Check yourself
Which fact belongs on the GTIN-identified trade item rather than on an individual physical unit?
- The declared net weight and pack configuration for this product line.
- The manufacturing lot number and production date.
- The best-before date printed on the pack.
- The pallet on which this item was shipped.
Show the answer, and why each wrong option is wrong
A is correct. Net weight and pack configuration are specified once for the product line and hold of every unit that bears the GTIN: they are class-level facts, which is exactly the level the GTIN identifies.
B, C and D are all instance-level and each fails differently if pushed up to the class: a lot number attached to the trade item makes every unit ever produced part of one batch, destroying the recall query; a best-before date at class level asserts that all stock expires simultaneously; and a pallet reference makes the whole product line reside in one shipment. Notice these are the same shape as attaching a pump design’s certification date to every physical pump: level confusion is not a domain quirk, it is a modelling error with a stable signature, and the fix is always to give the two levels distinct identifiers and an explicit relation.
Buy, adapt or build
Use a decision rule rather than a preference. Buy or rather adopt wholesale when the standard is also the interoperability requirement: if trading partners or a regulator expect EPCIS events or GS1 keys, there is nothing to design, only to implement correctly. Adapt when a comprehensive model exists but your questions are narrower, which is the normal FIBO situation: profile the modules you need, add your extensions in your own namespace, and record the alignment to the core so that upgrades remain possible. Build only where no credible standard covers your competitive core, and even then build on a top-level commitment rather than from nothing.
The one thing not to do is what most enterprises do: build a bespoke model that quietly duplicates 80 per cent of a public standard, then discover at integration time that nothing maps cleanly. In commerce the standards are cheap, the identifiers are the asset, and the expensive part is always the mapping you did not document. Alignment and mapping practice is the subject of the crosswalk lessons in this course, and the wider ontology training collection covers the specialist domain tracks in depth.
