A bet on a match may look like a single line on a screen: two teams, a price and a button. For a data system, however, that line hides several different objects that must be identified and connected correctly. There is the sporting event itself, the betting market attached to that event, the possible outcomes inside that market, and changing attributes such as odds or market status. In sport suisse, this structure can be understood through the language of ontologies. In simple terms, an ontology defines what kinds of things exist in a domain and how those things relate to one another. The goal is not to make betting terminology more academic. It is to make the data precise enough that different systems can understand the same event in the same way.
This distinction becomes important as soon as information comes from more than one source. A match-data provider, bookmaker, statistics service and results feed may all describe the same football match differently. One source may use a club’s full legal name, another a short name, while a third relies on an internal identifier. If the systems only compare visible text, they can easily treat one real-world event as several different objects. A semantic model solves the problem by separating the entity from the label used to display it.
The event is the anchor
The first object is the event. In football, that might be a scheduled match between two teams at a specific time in a particular competition. In tennis, it could be a match between two players. The important point is that the event is not the bet itself. It exists independently of whether any betting market is offered around it.
A useful event model therefore needs stable identity. Team names alone are not enough, because the same teams may meet several times in one season. Date alone is not enough either, because several competitions can schedule matches on the same day. Competition, participants, scheduled time and identifiers together help distinguish one event from another. Changes must also be represented correctly. If kick-off is moved, the event usually remains the same event with an updated time rather than becoming a new object.
That sounds obvious to a human reader because context fills the gaps automatically. Software does not have that luxury. If one feed reports a match at 19:00 UTC and another at 20:00 local time, the system must know whether those records describe the same event. Ontology design forces developers to define that relationship explicitly.
A market is a question about the event
Once the event is identified, the next layer is the market. A market is essentially a structured question about what may happen. “Who will win the match?” is one market. “Will the total number of goals exceed 2.5?” is another. “What will the exact score be?” is a third. All of them refer to the same underlying sporting event, but they ask different questions about it.
This separation is crucial because markets have their own identities and rules. A match-winner market cannot be merged with a total-goals market simply because both belong to the same fixture. Each market also has parameters. An over/under market with a line of 2.5 is different from one with a line of 3.5. A first-half result is different from a full-time result even when the participants are identical.
In sport suisse, a semantic model can therefore express a hierarchy: one event may have many markets, and every market must specify exactly what aspect of the event it describes. This becomes especially useful when data is exchanged between APIs. Rather than relying on free-text labels such as “Match Result”, “1X2” or “Full Time Result”, systems can map those labels to the same underlying concept.
Outcomes are answers, not events
Every market contains possible outcomes. If the market asks who will win a tennis match, the outcomes might be Player A or Player B. If the market asks whether total goals will be above or below 2.5, the outcomes are Over 2.5 and Under 2.5. Outcomes therefore belong to markets rather than directly to events.
This distinction prevents a common modelling error. “Team A wins” sounds like an event, but in betting data it may be an outcome inside a particular market. The same team might also appear in other markets: to score first, to lead at half-time or to win with a handicap. The participant is the same entity, but its role changes depending on the market.
Odds should normally be treated as properties associated with an outcome at a particular moment rather than as the outcome itself. The outcome “Team A wins” can remain stable while its price changes many times before the match. Separating identity from price makes it possible to store price history, compare providers and update live values without creating a new outcome every time the odds move.
Time and status turn static data into live data
Betting data is rarely static. Events are scheduled, delayed, started, suspended and completed. Markets may be opened, temporarily suspended, reopened or settled. Odds can change continuously. A useful ontology therefore needs more than nouns; it also needs states and time.
Consider a match that is postponed. The event may still exist, but markets linked to it could be suspended. If the event later receives a new date, those markets might reopen. A data model that only knows “event” and “outcome” cannot describe this lifecycle clearly. Status must be represented as its own property with agreed meanings.
The same applies to settlement. A market does not simply disappear when the match ends. It reaches a state in which one or more outcomes are determined according to the market rules. That distinction is especially important when feeds disagree temporarily or when a result is corrected. A semantic system should be able to represent the sporting result, the market status and the settlement decision as related but separate facts.
This is where ontology work becomes practical rather than theoretical. Live systems need to know whether a value is current, historical, suspended or final. Without those distinctions, an API may deliver technically valid data that another service interprets incorrectly.
Shared meaning matters more than shared wording
The real value of an ontology appears when several systems need to exchange information. Two providers do not need to use identical labels if both map their terms to the same concepts. “Home Win”, “1”, and “Team A to Win” can all represent the same outcome if the relationship to the event and market is defined clearly.
This is the principle behind semantic interoperability. Instead of forcing every database to use the same visible vocabulary, systems agree on identity and relationships. The display language can vary while the meaning underneath remains stable. For multilingual environments, this becomes particularly useful because labels can change without changing the entity itself.
The same principle helps with historical data. Club names change, competitions are renamed and providers update their terminology. Stable identifiers and explicit relationships preserve continuity. A search for an older event does not fail simply because the display label used at the time differs from the one used today.
Seen this way, a bet is not one piece of data but a small graph. An event connects to participants and a competition. Markets connect to the event. Outcomes connect to markets. Odds attach to outcomes at particular times, while statuses describe how events and markets move through their lifecycle. That structure may be invisible to the end user, but it is what allows different systems to exchange, update and interpret the same information consistently.
An ontology therefore does more than organise terminology. It defines where one concept ends and another begins. In sport suisse, separating event, market and outcome prevents a simple interface from hiding important distinctions in the underlying data. The bet the user sees may fit on one line, but the machine-readable version works because every part of that line has a defined identity, role and relationship to the rest. The same structure also clarifies what odds are not. A price attached to an outcome is the bookmaker’s offer, which includes a margin, rather than a forecast that the outcome will happen. Understanding the data does not make any result certain, so betting is best treated as paid entertainment with a budget decided in advance, without increasing stakes to recover earlier losses.
