Conteúdo desenvolvido por SerinewsSeu evento gera dados o tempo todo: inscrições, crachás lidos, estandes vendidos, cotas de patrocínio, leads, pesquisas. Quase sempre eles ficam espalhados em sistemas que não conversam. Este curso ensina a organizar tudo isso num modelo único, que responde as perguntas que mais importam para o negócio: quem vai renovar, quanto valeu para o expositor e onde está o dinheiro deixado na mesa.
O metro quadrado mais caro é o sem dados.
Todo organizador já ouviu de um expositor: "o cliente certo não estava lá". Talvez estivesse. Só não com o crachá que se imaginava. Talvez estivesse fora do radar. Ou talvez nem tenha sido convidado.
Nada substitui o olho no olho, e eventos continuam sendo a maior plataforma de relacionamento do mercado. Mas o que o expositor investe de verdade não é só dinheiro: é tempo. Quando o mercado começa a escolher onde gastar suas horas, ele passa a exigir prova. E prova se faz com dados.
A maior feira de informática dos anos 1990, com cerca de 200 mil visitantes no auge. As grandes empresas foram saindo e a última edição foi em 2003.
Já foi a maior feira de tecnologia do mundo. Depois de anos perdendo público e expositores, foi encerrada em 2018.
A principal feira de relojoaria. As grandes marcas saíram reclamando de custo alto e pouco retorno, e passaram a fazer o próprio evento.
Referência mundial em fotografia por 70 anos, suspensa por tempo indeterminado em 2020.
A grande vitrine dos games. As editoras passaram a lançar seus jogos em transmissões próprias pela internet, e o evento foi encerrado em 2023.
Cada caso teve vários motivos: mudanças no mercado, custos, a chegada do digital. Mas em todos o ponto em comum é o mesmo. O expositor encontrou um caminho mais rápido, mais segmentado ou mais barato até o mesmo cliente, e o organizador não tinha números para provar o contrário a tempo.
O evento não morre de uma vez. Ele morre primeiro na cabeça de alguns bons clientes, quando eles percebem que encontram os mesmos contatos por outros canais.
Cuidar dos dados do seu evento é a forma de garantir que ele continue existindo. É disso que este curso trata.
A Ontologia é o mapa da empresa em linguagem de negócio: as coisas que existem (substantivos), como elas se ligam, e o que se pode fazer com elas (verbos), tudo conectado aos dados reais.
Pense em como uma empresa guarda informação hoje. Tem uma planilha de expositores, um CRM com contatos, um sistema financeiro com contratos, uma base de credenciamento de visitantes. Cada sistema chama a mesma coisa por um nome diferente, guarda numa tabela diferente, com colunas cifradas tipo cd_cli, id_exp_2, vl_ctr.
Quem quer responder uma pergunta simples ("quais expositores da feira de março ainda não pagaram e já confirmaram estande?") precisa saber onde está cada tabela, como cruzar uma com a outra, e o que cada coluna significa. Isso vive na cabeça de duas ou três pessoas.
A Ontologia resolve isso criando uma camada por cima de todos esses dados onde as coisas têm o nome que o negócio usa: existe um Expositor, existe uma Feira, existe um Contrato. Eles se ligam: um Expositor assina Contratos, um Contrato é de uma Feira. E existem verbos: Reservar estande, Registrar pagamento.
Muita gente chama isso de gêmeo digital do negócio. Para um organizador, é o retrato vivo do evento: cada expositor, cada visitante, cada contrato e cada contrapartida, conectados. Pessoas, aplicativos e agentes de IA passam a trabalhar em cima desse mapa, e não mais em cima de planilhas soltas.
Antes de falar de modelo, vale olhar para o que você já coleta. Um evento médio gera dados em pelo menos sete lugares:
| Onde está | O que guarda |
|---|---|
| Inscrição e credenciamento | Quem se inscreveu, categoria, cargo, empresa, valor pago |
| Controle de acesso | Quem entrou de fato, em que dia e horário, por qual portão |
| App ou leitura de leads | Quais visitantes cada expositor escaneou no estande |
| CRM comercial | Negociação de estandes e cotas, propostas, contatos dos expositores |
| Financeiro | Contratos, parcelas, inadimplência |
| Pesquisas | Satisfação e NPS de visitantes e expositores |
| Marketing | Base de e-mails, campanhas, origem de cada inscrição |
O problema não é falta de dado. É que a mesma pessoa aparece três vezes, com e-mails diferentes, em três sistemas. A mesma empresa é expositora num sistema, patrocinadora em outro e tem 40 funcionários visitantes num terceiro, e ninguém consegue ver isso junto.
E qualidade de dado aparece no resultado. Num portfólio de feiras B2B que acompanhamos, a taxa de abertura dos e-mails para visitantes e expositores mais que dobrou em quatro anos. Não foi por causa de nenhuma campanha genial: a base ficou mais limpa, sem duplicidades, e mais bem segmentada. Na mesma época, o desempenho variou muito de uma feira para outra dentro do mesmo portfólio, e por isso vale medir evento por evento.
A ontologia resolve exatamente isso: um único Visitante, uma única Empresa, ligados a tudo o que fizeram em todas as edições.
Toda boa modelagem começa por perguntas de negócio. Estas são as que mais aparecem para organizadores, e o que o modelo precisa ter para respondê-las:
| Pergunta | O que o modelo precisa ter |
|---|---|
| Quais expositores vão renovar para a próxima edição? | Contrato por Edição, histórico de renovação e o que cada expositor recebeu (leads, visitas) |
| Quanto o evento valeu para cada expositor? | Lead ligando Expositor a Visitante, com cargo e segmento do visitante |
| Quantos inscritos não apareceram? | Inscrição e Acesso ligados ao mesmo Visitante |
| Que público cada expositor quer encontrar? | Público-alvo no Expositor e perfil (cargo, segmento, porte) no Visitante |
| Entregamos tudo o que vendemos aos patrocinadores? | Cota com suas Contrapartidas, cada uma com prazo e situação |
| Quais empresas visitam muito e nunca expuseram? | Visitante ligado a Empresa, a mesma Empresa que pode virar Expositor |
Repare na última linha. Com os dados separados, essa lista de oportunidades comerciais é invisível. Com a ontologia, ela sai com um filtro.
Feira competitiva não é a que tem o corredor mais cheio. É a que entrega ao expositor um cliente novo por um custo menor que o de qualquer outro canal. O seu expositor faz essa conta, mesmo sem perceber. Poucas organizadoras fazem.
Veja o funil de um expositor típico de um estande de 75 m² (números de exemplo, na ordem de grandeza que aparece no mercado):
Se esse expositor investiu R$ 200 mil no evento (estande, montagem, equipe, viagem), cada cliente custou R$ 12.500. Esse é o CAC da feira, o custo de aquisição de cliente. Se o mesmo expositor consegue clientes parecidos por R$ 8 mil com anúncios segmentados ou com uma equipe de pré-vendas, a sua feira perdeu a disputa, mesmo que o corredor estivesse cheio.
E tem um agravante: quando ninguém cuida do perfil do público, a qualificação média do visitante cai a cada edição, e o CAC do expositor sobe junto. Teste no simulador abaixo.
| Edição | % com perfil | CAC da feira |
|---|
Simulador ilustrativo. Os valores iniciais são exemplos; troque pelos números de um expositor real seu.
Para fazer essa conta com números de verdade, edição após edição, o seu modelo precisa ter algumas peças. É aqui que a modelagem deixa de ser assunto de TI e vira estratégia:
| Indicador de competitividade | De onde vem no modelo |
|---|---|
| Qualificação do público | Visitante com cargo, segmento e porte da Empresa, comparados ao público-alvo de cada Expositor |
| Contatos qualificados por expositor | Lead ligando Expositor e Visitante, filtrado pelo perfil |
| CAC da feira | Investimento do expositor (no Contrato ou informado por ele) dividido pelos negócios que ele declarar na pesquisa pós-evento |
| Tendência entre edições | Tudo isso ligado à Edição, para comparar um ano com o outro |
| Risco de não renovação | riscoDeChurn(expositor) combinando leads, satisfação e histórico |
Com isso em mãos, a organizadora muda o que vende. Ela deixa de vender metro quadrado e passa a vender previsibilidade de negócio: "no ano passado, empresas do seu segmento receberam em média tantos contatos com este perfil". Esse é o melhor argumento de renovação que existe.
Duas observações de quem já fez isso na prática. Primeiro, inteligência de dados custa pouco perto do que está em jogo: dividido pelos estandes e visitantes de um evento médio, fica em poucos reais por visitante. Basta um contrato a mais para pagar o investimento muitas vezes. Segundo, isso não amadurece numa edição só: a passagem de "volume de público" para "jornada de relacionamento" costuma levar de dois a três anos. Quem começa depois que os bons expositores já foram embora, começa tarde.
Isto é o mesmo dado visto de duas formas. Alterne entre elas.
tb_ctr_2026.csv (sistema financeiro)
| id_ctr | cd_cli | cd_evt | nr_est | vl_ctr | st | dt_ass |
|---|---|---|---|---|---|---|
| C-8812 | 40221 | AUR-2026 | B14 | 48000.00 | 2 | 2026-01-19 |
| C-8813 | 40517 | AUR-2026 | A02 | 112500.00 | 1 | 2026-01-22 |
| C-8820 | 40221 | BRV-2026 | C07 | 51000.00 | 1 | 2026-02-03 |
O que é st = 2? Quem é o cliente 40221? Qual feira é AUR-2026? Para saber, você precisa abrir outras três tabelas e perguntar para alguém.
O mesmo registro, agora com nome, significado, vizinhos e as ações que alguém pode tomar. Você clica no Expositor e vê todos os contratos dele, em todas as feiras. (Nomes e valores fictícios.)
Repare que o dado não mudou. Continua vindo da mesma tabela do financeiro. O que a Ontologia fez foi dar significado a ele: traduziu códigos, nomeou colunas, ligou com outros dados e pendurou ações. Esse é o trabalho inteiro, repetido para cada coisa importante do negócio.
Toda ontologia operacional é montada com estas peças. Entenda bem cada uma, porque o resto é combinação delas.
É a definição de uma "coisa" do negócio: Expositor, Feira, Estande, Visitante. Cada tipo de objeto é alimentado por um dataset (uma tabela da sua base de dados), e cada linha dessa tabela vira um objeto. A tabela de expositores com 1.200 linhas vira 1.200 objetos Expositor.
Todo tipo de objeto precisa de uma chave primária (primary key): uma coluna que identifica cada objeto de forma única e que não muda com o tempo, como o CNPJ ou um código interno. E tem um título (title key): a propriedade que aparece como nome do objeto na tela, como a razão social.
Analogia: o tipo de objeto é o molde; cada objeto é uma peça saída do molde.
As características do objeto: nome, CNPJ, segmento, cidade, valor do contrato, data. Cada propriedade vem de uma coluna do dataset, mas com nome legível e tipo definido (texto, número, data, geolocalização, etc.). É aqui que st = 2 vira Situação: Pago.
A relação entre dois tipos de objeto. Todo link tem uma cardinalidade, e acertar isso é metade do trabalho de modelagem:
Links são o que permite navegar: sair de uma Feira, ver seus Expositores, ver os Contratos deles, ver quais estão atrasados. Sem escrever nenhum cruzamento de tabela.
É aqui que uma ontologia operacional se diferencia de um simples catálogo de dados. Uma ação é uma mudança autorizada no mundo: criar, editar ou apagar objetos e links, de forma controlada. Uma ação tem:
Quando uma ação muda um objeto, a edição é gravada pela Ontologia por cima do dado original (writeback). O dataset de origem não é sobrescrito; a Ontologia junta as duas coisas e mostra o estado atual. E fica registrado quem fez, quando e o quê.
Código (TypeScript ou Python) que roda em cima dos objetos. Serve para três coisas:
Uma "forma em comum" que vários tipos de objeto compartilham. Expositor, Visitante e Patrocinador são coisas diferentes, mas todos têm nome, e-mail, empresa e telefone. Você cria a interface Contato com essas propriedades, e qualquer aplicativo ou ação que trabalhe com "Contato" funciona com os três. Isso evita construir a mesma tela três vezes.
Conjunto de objetos (object set). Não é um bloco que você define, mas você vai ouvir o termo o tempo todo: é qualquer grupo de objetos resultante de um filtro ou navegação. "Expositores do segmento têxtil com contrato em aberto" é um object set. Aplicativos, análises e IA trabalham passando object sets de um lado para o outro.
Assim fica um modelo simples, mas realista, para uma empresa que organiza feiras. Leia o desenho seguindo as setas.
Quatro decisões desse desenho valem a pena entender, porque são exatamente o tipo de escolha que separa iniciante de especialista:
Dá para pensar a ontologia em três camadas. Elas ajudam a entender por que isso é mais que um catálogo de dados.
O que existe. Objetos, propriedades e links. É a parte que dá significado ao dado. Responde "quantos expositores do segmento têxtil temos na feira de março?".
O que se pode fazer. Ações, regras e integrações com sistemas. É a parte que transforma análise em operação. Você não só vê que o expositor está inadimplente: você clica em Enviar cobrança e a ação acontece, registrada.
Como decidir. Funções, modelos, simulações e IA usando as duas camadas anteriores. "Se eu abrir mais um pavilhão, quantos estandes vendo a mais?" "Quais expositores têm maior risco de não renovar?" A decisão tomada volta como ação, e o resultado dela vira dado novo. O ciclo se fecha.
Para um organizador, isso fica concreto: o modelo mostra que um expositor recebeu poucos leads (semântica), uma função calcula o risco de ele não renovar (dinâmica), e o comercial dispara a ação Oferecer reposicionamento de estande antes que ele desista (cinética).
Guarde este ciclo, porque ele é a ideia central de uma ontologia operacional: dado → decisão → ação → dado novo, tudo no mesmo lugar. A maioria das ferramentas de dados para em "dado → painel". O painel mostra o problema e a pessoa vai resolver em outro sistema, sem registro.
Entender o caminho evita muita confusão. É sempre assim:
Erro clássico de iniciante: mapear a tabela do jeito que ela veio do sistema. Se a tabela bruta tem 80 colunas com nomes cifrados e linhas duplicadas, o tipo de objeto vai herdar tudo isso. A ontologia boa nasce de um dataset já limpo e pensado para ela. O trabalho de pipeline vem antes.
Você não precisa de uma plataforma cara para começar. O raciocínio de modelagem vale para uma planilha bem estruturada, um Airtable ou um banco de dados simples. Mas é bom conhecer as ferramentas que as plataformas maiores oferecem em cima da ontologia, porque elas mostram até onde o modelo pode ir.
Para quem tem time de tecnologia. Um exemplo de como isso tudo se encaixa: com um SDK de ontologia, o código de um sistema externo fica assim. Repare que você fala com Expositores e Contratos, nunca com tabelas.
// Busca expositores têxteis com contrato pendente na feira de março const pendentes = await client(Expositor) .where({ segmento: { $eq: "Têxtil" } }) .pivotTo("contratos") .where({ situacao: { $eq: "Pendente" }, feiraId: { $eq: "AUR-2026" } }) .fetchPage(); // Dispara a ação, que aplica as regras e permissões definidas na ontologia await client(registrarPagamento).applyAction({ contrato: "C-8813", valor: 112500, });
Código ilustrativo. A forma exata dos métodos depende da plataforma e do SDK usados.
Quando você pede para um modelo de IA "ver quais expositores estão atrasados e mandar cobrança", ele precisa de três coisas que um chat solto não tem:
st = 2 é "pago". A ontologia sabe, e entrega isso pronto. Isso reduz muito a chance de a IA inventar ou cruzar dado errado.Por isso a ontologia é vista como a camada que torna a IA utilizável em operação real. O modelo de linguagem é o "cérebro" trocável; a ontologia é o mapa do negócio e o conjunto de mãos autorizadas.
As permissões ficam na própria ontologia e valem em qualquer ferramenta que a use. Elas podem ser definidas em vários níveis:
Plataformas mais maduras também usam marcações (markings): etiquetas como "dados pessoais" que acompanham o dado por onde ele passa, inclusive em derivados. Se uma tabela tem CPF marcado, qualquer coisa calculada a partir dela herda a restrição. Isso é essencial para LGPD, especialmente na leitura de leads: o visitante precisa ter consentido em compartilhar seus dados com o expositor, e esse consentimento deve ser uma propriedade registrada, não uma suposição.
Para conversar como especialista, você precisa saber que a palavra existe há muito tempo e significa coisas parecidas, mas não iguais:
| Sentido | O que é | Diferença para a ontologia operacional |
|---|---|---|
| Filosofia | Ramo que estuda "o que existe" e como as coisas se classificam. | A origem do nome. A ontologia operacional aplica a ideia a uma empresa. |
| Web semântica | Padrões como RDF e OWL para descrever conceitos e relações, com foco em interoperabilidade e inferência lógica ("todo X é Y, logo..."). | A ontologia operacional quase não usa inferência lógica. O foco é operação: dados reais, ações e aplicativos. |
| Grafo de conhecimento | Rede de entidades e relações, usada por buscadores e por IA (ex.: Neo4j, Wikidata). | Parecido na parte semântica. A ontologia operacional adiciona ações, permissões e escrita, que um grafo puro normalmente não tem. |
| Camada semântica de BI | Métricas e dimensões padronizadas para relatórios (ex.: dbt Semantic Layer, LookML). | Serve para ler e medir. Não tem a camada cinética de agir. |
Resumo para guardar: a ontologia deste guia é operacional. Ela existe para pessoas e IA tomarem decisões e agirem, não só para descrever ou medir.
Esta é a parte que faz alguém virar especialista. A ferramenta se aprende em semanas; modelar bem leva prática. As regras que mais importam:
Cliente_PJ. O teste: um diretor que nunca viu o sistema entende a tela?Leia o cenário e escreva, antes de abrir a resposta, quais objetos, links e ações você criaria.
Cenário. Você organiza um congresso médico anual com área de exposição. Os participantes se inscrevem em categorias (médico, residente, estudante), escolhem sessões científicas e recebem um crachá com QR code. Os expositores usam um aplicativo para escanear o crachá de quem visita o estande. Os patrocinadores compram cotas (Ouro, Prata, Bronze) com contrapartidas: logo no site, sessão patrocinada, e-mail para a base de inscritos. Você quer provar para cada expositor quantos contatos qualificados ele recebeu e garantir que toda contrapartida prometida foi entregue.
Objetos: Evento Edição Participante Inscrição Sessão Empresa Expositor Lead Cota Contrapartida
Links: Evento tem Edições (1:N) · Participante faz Inscrições (1:N) · Inscrição é da Edição (N:1) · Inscrição escolhe Sessões (N:N) · Expositor é a Empresa (N:1) · Lead captado por Expositor e de Participante · Empresa compra Cota (1:N) · Cota prevê Contrapartidas (1:N)
Ações: Credenciar participante · Registrar lead · Marcar contrapartida como entregue · Renovar cota
Função: leadsQualificados(expositor), que conta só os leads de médicos da especialidade que o expositor quer atingir.
As decisões que importam:
Se você chegou perto disso, já está pensando como modelador. Se colocou tudo num objeto só, releia "Objeto ou propriedade?".
Cada uma testa um conceito que aparece no dia a dia. A explicação aparece quando você responde.
0 de 12 respondidasLer isto te dá o vocabulário e o modelo mental. Quem domina o assunto é quem já modelou vários eventos e viu o que quebra. O caminho prático para a sua próxima edição:
Conteúdo desenvolvido por SerinewsYour event generates data all the time: registrations, scanned badges, booths sold, sponsorship packages, leads, surveys. Most of the time it sits scattered across systems that don't talk to each other. This course teaches you to organize all of it in a single model that answers the questions that matter most to the business: who will renew, how much the event was worth to each exhibitor, and where money is being left on the table.
The most expensive square meter is the one without data.
Every organizer has heard it from an exhibitor: "the right customer wasn't there." Maybe they were. Just not with the badge you expected. Maybe they were off the radar. Or maybe they were never invited.
Nothing replaces meeting face to face, and events are still the biggest relationship platform in the market. But what exhibitors really invest is not just money. It is time. When the market starts choosing where to spend its hours, it starts demanding proof. And proof is built with data.
The biggest computer fair of the 1990s, with about 200,000 visitors at its peak. The big companies gradually pulled out and the last edition was in 2003.
Once the largest technology fair in the world. After years of losing visitors and exhibitors, it was shut down in 2018.
The leading watch and jewelry fair. The big brands left, complaining of high costs and low returns, and started running their own events.
The world reference in photography for 70 years, suspended indefinitely in 2020.
The great showcase for video games. Publishers started launching their games on their own online broadcasts, and the event was shut down in 2023.
Each case had several causes: market shifts, costs, the arrival of digital. But they all share one thing. The exhibitor found a faster, more targeted or cheaper path to the same customer, and the organizer didn't have the numbers to prove otherwise in time.
An event doesn't die all at once. It dies first in the minds of a few good customers, when they realize they can reach the same contacts through other channels.
Taking care of your event's data is how you make sure it keeps existing. That is what this course is about.
The Ontology is a map of the company in business language: the things that exist (nouns), how they connect, and what you can do with them (verbs), all connected to real data.
Think about how a company stores information today. There is an exhibitor spreadsheet, a CRM with contacts, a finance system with contracts, a visitor registration database. Each system calls the same thing by a different name and stores it in a different table, with cryptic columns like cd_cli, id_exp_2, vl_ctr.
Anyone who wants to answer a simple question ("which exhibitors at the March fair haven't paid yet but have already confirmed a booth?") needs to know where each table is, how to join one with another, and what each column means. That knowledge lives in the heads of two or three people.
The Ontology solves this by creating a layer on top of all that data where things have the names the business uses: there is an Exhibitor, there is a Fair, there is a Contract. They connect: an Exhibitor signs Contracts, a Contract is for a Fair. And there are verbs: Book booth, Register payment.
Many people call this the business's digital twin. For an organizer, it is a living picture of the event: every exhibitor, every visitor, every contract and every sponsor deliverable, all connected. People, apps and AI agents start working on top of this map instead of on loose spreadsheets.
Before talking about the model, it's worth looking at what you already collect. An average event generates data in at least seven places:
| Where it is | What it stores |
|---|---|
| Registration and accreditation | Who registered, category, job title, company, amount paid |
| Access control | Who actually came in, on what day and time, through which gate |
| Lead retrieval app | Which visitors each exhibitor scanned at the booth |
| Sales CRM | Booth and sponsorship negotiations, proposals, exhibitor contacts |
| Finance | Contracts, installments, overdue payments |
| Surveys | Satisfaction and NPS from visitors and exhibitors |
| Marketing | Email list, campaigns, source of each registration |
The problem isn't a lack of data. It's that the same person shows up three times, with different emails, in three systems. The same company is an exhibitor in one system, a sponsor in another and has 40 employees visiting in a third, and nobody can see all of it together.
And data quality shows up in results. In a portfolio of B2B fairs we follow, the open rate of emails to visitors and exhibitors more than doubled in four years. It wasn't thanks to some brilliant campaign: the database got cleaner, with no duplicates, and better segmented. Over the same period, performance varied a lot from one fair to another within the same portfolio, which is why it pays to measure event by event.
The ontology solves exactly this: a single Visitor, a single Company, linked to everything they did across every edition.
Every good model starts with business questions. These are the ones organizers ask most, and what the model needs in order to answer them:
| Question | What the model needs |
|---|---|
| Which exhibitors will renew for the next edition? | Contract per Edition, renewal history and what each exhibitor received (leads, visits) |
| How much was the event worth to each exhibitor? | Lead linking Exhibitor to Visitor, with the visitor's job title and segment |
| How many registrants didn't show up? | Registration and Entry linked to the same Visitor |
| What audience does each exhibitor want to meet? | Target audience on the Exhibitor and profile (job title, segment, company size) on the Visitor |
| Did we deliver everything we sold to sponsors? | Package with its Deliverables, each with a deadline and status |
| Which companies visit a lot and have never exhibited? | Visitor linked to Company, the same Company that can become an Exhibitor |
Look at the last row. With the data kept separate, this list of sales opportunities is invisible. With the ontology, it comes out of a single filter.
A competitive fair is not the one with the most crowded aisles. It's the one that delivers a new customer to the exhibitor at a lower cost than any other channel. Your exhibitor does this math, even without noticing. Few organizers do.
Here is the funnel of a typical exhibitor with a 75 m² booth (example numbers, in the order of magnitude seen in the market):
If this exhibitor invested R$ 200,000 in the event (booth, build, staff, travel), each customer cost R$ 12,500. That is the fair's CAC, the customer acquisition cost. If the same exhibitor can get similar customers for R$ 8,000 with targeted ads or a pre-sales team, your fair has lost the contest, even if the aisles were full.
And there's a catch: when nobody looks after the audience profile, the average visitor qualification drops with every edition, and the exhibitor's CAC rises with it. Try it in the simulator below.
| Edition | % with profile | Fair CAC |
|---|
Illustrative simulator. The starting values are examples; replace them with the numbers of one of your real exhibitors.
To do this math with real numbers, edition after edition, your model needs a few pieces. This is where modeling stops being an IT topic and becomes strategy:
| Competitiveness indicator | Where it comes from in the model |
|---|---|
| Audience qualification | Visitor with job title, segment and size of the Company, compared to each Exhibitor's target audience |
| Qualified contacts per exhibitor | Lead linking Exhibitor and Visitor, filtered by profile |
| Fair CAC | The exhibitor's investment (from the Contract or reported by them) divided by the deals they report in the post-event survey |
| Trend across editions | All of this linked to the Edition, to compare one year with another |
| Non-renewal risk | churnRisk(exhibitor) combining leads, satisfaction and history |
With this in hand, the organizer changes what it sells. It stops selling square meters and starts selling business predictability: "last year, companies in your segment received on average this many contacts with this profile." That is the best renewal argument there is.
Two notes from people who have done this in practice. First, data intelligence costs little compared to what's at stake: spread across the booths and visitors of an average event, it comes to a few reais per visitor. A single extra contract pays for the investment many times over. Second, this doesn't mature in one edition: the shift from "audience volume" to "relationship journey" usually takes two to three years. Those who start after the good exhibitors have already left are starting too late.
This is the same data seen in two ways. Switch between them.
tb_ctr_2026.csv (finance system)
| id_ctr | cd_cli | cd_evt | nr_est | vl_ctr | st | dt_ass |
|---|---|---|---|---|---|---|
| C-8812 | 40221 | AUR-2026 | B14 | 48000.00 | 2 | 2026-01-19 |
| C-8813 | 40517 | AUR-2026 | A02 | 112500.00 | 1 | 2026-01-22 |
| C-8820 | 40221 | BRV-2026 | C07 | 51000.00 | 1 | 2026-02-03 |
What does st = 2 mean? Who is customer 40221? Which fair is AUR-2026? To find out, you need to open three other tables and ask someone.
The same record, now with a name, a meaning, neighbors and the actions someone can take. You click the Exhibitor and see all of its contracts, across every fair. (Fictional names and amounts.)
Notice that the data didn't change. It still comes from the same finance table. What the Ontology did was give it meaning: it translated codes, named columns, linked it to other data and attached actions. That is the whole job, repeated for every important thing in the business.
Every operational ontology is built from these pieces. Understand each one well, because everything else is a combination of them.
It is the definition of a business "thing": Exhibitor, Fair, Booth, Visitor. Each object type is backed by a dataset (a table in your database), and each row of that table becomes an object. The exhibitor table with 1,200 rows becomes 1,200 Exhibitor objects.
Every object type needs a primary key: a column that uniquely identifies each object and doesn't change over time, like the company tax ID (CNPJ) or an internal code. It also has a title key: the property that shows up as the object's name on screen, like the legal company name.
Analogy: the object type is the mold; each object is a piece that comes out of the mold.
The object's characteristics: name, CNPJ, segment, city, contract amount, date. Each property comes from a column in the dataset, but with a readable name and a defined type (text, number, date, geolocation, etc.). This is where st = 2 becomes Status: Paid.
The relationship between two object types. Every link has a cardinality, and getting it right is half the modeling work:
Links are what let you navigate: start from a Fair, see its Exhibitors, see their Contracts, see which ones are overdue. Without writing a single table join.
This is where an operational ontology differs from a simple data catalog. An action is an authorized change in the world: creating, editing or deleting objects and links, in a controlled way. An action has:
When an action changes an object, the edit is stored by the Ontology on top of the original data (writeback). The source dataset is not overwritten; the Ontology combines the two and shows the current state. And it records who did what, and when.
Code (TypeScript or Python) that runs on top of objects. It serves three purposes:
A "common shape" that several object types share. Exhibitor, Visitor and Sponsor are different things, but they all have a name, email, company and phone. You create the Contact interface with those properties, and any app or action that works with "Contact" works with all three. This saves you from building the same screen three times.
Object set. It isn't a block you define, but you will hear the term all the time: it is any group of objects that results from a filter or navigation. "Textile exhibitors with an open contract" is an object set. Apps, analyses and AI work by passing object sets back and forth.
This is what a simple but realistic model looks like for a company that organizes fairs. Read the drawing by following the arrows.
Four decisions in this drawing are worth understanding, because they are exactly the kind of choice that separates a beginner from an expert:
You can think of the ontology in three layers. They help explain why this is more than a data catalog.
What exists. Objects, properties and links. This is the part that gives data meaning. It answers "how many textile exhibitors do we have at the March fair?".
What you can do. Actions, rules and integrations with systems. This is the part that turns analysis into operations. You don't just see that the exhibitor is behind on payments: you click Send payment reminder and the action happens, on record.
How to decide. Functions, models, simulations and AI using the two previous layers. "If I open one more hall, how many more booths will I sell?" "Which exhibitors are most at risk of not renewing?" The decision comes back as an action, and its result becomes new data. The loop closes.
For an organizer, this gets concrete: the model shows that an exhibitor received few leads (semantic), a function calculates the risk that they won't renew (dynamic), and the sales team triggers the action Offer booth repositioning before they give up (kinetic).
Remember this loop, because it is the core idea of an operational ontology: data → decision → action → new data, all in the same place. Most data tools stop at "data → dashboard". The dashboard shows the problem and the person goes off to fix it in another system, with no record.
Understanding the path avoids a lot of confusion. It always goes like this:
Classic beginner mistake: mapping the table exactly as it came from the system. If the raw table has 80 columns with cryptic names and duplicate rows, the object type will inherit all of that. A good ontology starts from a dataset that is already clean and designed for it. The pipeline work comes first.
You don't need an expensive platform to get started. The modeling logic works for a well-structured spreadsheet, an Airtable base or a simple database. But it's good to know the tools that larger platforms offer on top of the ontology, because they show how far the model can go.
For those with a tech team. Here is an example of how it all fits together: with an ontology SDK, the code of an external system looks like this. Notice that you talk to Exhibitors and Contracts, never to tables.
// Find textile exhibitors with a pending contract at the March fair const pending = await client(Exhibitor) .where({ segment: { $eq: "Textile" } }) .pivotTo("contracts") .where({ status: { $eq: "Pending" }, fairId: { $eq: "AUR-2026" } }) .fetchPage(); // Trigger the action, which applies the rules and permissions defined in the ontology await client(registerPayment).applyAction({ contract: "C-8813", amount: 112500, });
Illustrative code. The exact shape of the methods depends on the platform and SDK used.
When you ask an AI model to "check which exhibitors are behind on payments and send them a reminder", it needs three things that a standalone chat doesn't have:
st = 2 means "paid". The ontology knows, and hands that over ready to use. This greatly reduces the chance of the AI making things up or joining data the wrong way.That's why the ontology is seen as the layer that makes AI usable in real operations. The language model is the swappable "brain"; the ontology is the map of the business and the set of authorized hands.
Permissions live in the ontology itself and apply in any tool that uses it. They can be set at several levels:
More mature platforms also use markings: labels such as "personal data" that follow the data wherever it goes, including into derived data. If a table has a marked CPF (personal tax ID), anything calculated from it inherits the restriction. This is essential for the LGPD (Brazil's data protection law), especially in lead retrieval: the visitor must have consented to share their data with the exhibitor, and that consent must be a recorded property, not an assumption.
To talk like an expert, you need to know that the word has been around for a long time and means similar, but not identical, things:
| Meaning | What it is | Difference from the operational ontology |
|---|---|---|
| Philosophy | The branch that studies "what exists" and how things are classified. | The origin of the name. The operational ontology applies the idea to a company. |
| Semantic web | Standards like RDF and OWL for describing concepts and relationships, focused on interoperability and logical inference ("every X is a Y, therefore..."). | The operational ontology barely uses logical inference. The focus is operations: real data, actions and apps. |
| Knowledge graph | A network of entities and relationships, used by search engines and AI (e.g. Neo4j, Wikidata). | Similar in the semantic part. The operational ontology adds actions, permissions and writeback, which a pure graph usually doesn't have. |
| BI semantic layer | Standardized metrics and dimensions for reports (e.g. dbt Semantic Layer, LookML). | It is for reading and measuring. It doesn't have the kinetic layer for acting. |
Summary to remember: the ontology in this guide is operational. It exists so that people and AI can make decisions and act, not just describe or measure.
This is the part that turns someone into an expert. You can learn the tool in weeks; modeling well takes practice. The rules that matter most:
Cliente_PJ. The test: does a director who has never seen the system understand the screen?Read the scenario and, before opening the answer, write down which objects, links and actions you would create.
Scenario. You organize an annual medical congress with an exhibition area. Attendees register in categories (physician, resident, student), choose scientific sessions and get a badge with a QR code. Exhibitors use an app to scan the badges of people who visit their booth. Sponsors buy packages (Gold, Silver, Bronze) with deliverables: logo on the website, a sponsored session, an email to the registrant list. You want to prove to each exhibitor how many qualified contacts they received and make sure every promised deliverable was delivered.
Objects: Event Edition Attendee Registration Session Company Exhibitor Lead Package Deliverable
Links: Event has Editions (1:N) · Attendee makes Registrations (1:N) · Registration is for Edition (N:1) · Registration chooses Sessions (N:N) · Exhibitor is the Company (N:1) · Lead captured by Exhibitor and of Attendee · Company buys Package (1:N) · Package includes Deliverables (1:N)
Actions: Check in attendee · Register lead · Mark deliverable as delivered · Renew package
Function: qualifiedLeads(exhibitor), which counts only the leads from physicians in the specialty the exhibitor wants to reach.
The decisions that matter:
If you came close to this, you're already thinking like a modeler. If you put everything into a single object, reread "Object or property?".
Each one tests a concept that comes up in day-to-day work. The explanation appears when you answer.
0 of 12 answeredReading this gives you the vocabulary and the mental model. The people who master the subject are the ones who have modeled many events and seen what breaks. The practical path for your next edition:
Ihre Veranstaltung erzeugt ständig Daten: Anmeldungen, gescannte Badges, verkaufte Stände, Sponsoring-Pakete, Leads, Umfragen. Fast immer liegen sie verstreut in Systemen, die nicht miteinander sprechen. Dieser Kurs zeigt, wie Sie all das in einem einzigen Modell ordnen, das die Fragen beantwortet, die für das Geschäft am meisten zählen: Wer verlängert, was hat es dem Aussteller gebracht und wo bleibt Geld liegen?
Der teuerste Quadratmeter ist der ohne Daten.
Jeder Veranstalter hat es schon von einem Aussteller gehört: „Der richtige Kunde war nicht da.“ Vielleicht war er da. Nur nicht mit dem Badge, das man erwartet hatte. Vielleicht war er nicht auf dem Radar. Oder er wurde gar nicht erst eingeladen.
Nichts ersetzt das persönliche Gespräch, und Veranstaltungen sind weiterhin die größte Beziehungsplattform des Marktes. Doch was der Aussteller wirklich investiert, ist nicht nur Geld, sondern Zeit. Sobald der Markt auswählt, wo er seine Stunden verbringt, verlangt er Beweise. Und Beweise liefern Daten.
Die größte Computermesse der 1990er-Jahre, mit rund 200.000 Besuchern auf dem Höhepunkt. Die großen Unternehmen zogen sich nach und nach zurück, die letzte Ausgabe fand 2003 statt.
Einst die größte Technologiemesse der Welt. Nach Jahren mit sinkenden Besucher- und Ausstellerzahlen wurde sie 2018 eingestellt.
Die wichtigste Uhrenmesse. Die großen Marken gingen und klagten über hohe Kosten und geringen Ertrag. Sie veranstalten inzwischen eigene Events.
70 Jahre lang die Weltleitmesse der Fotografie, 2020 auf unbestimmte Zeit ausgesetzt.
Das große Schaufenster der Games-Branche. Die Publisher stellten ihre Spiele zunehmend in eigenen Online-Streams vor, und die Veranstaltung wurde 2023 eingestellt.
Jeder Fall hatte mehrere Gründe: Marktveränderungen, Kosten, die Digitalisierung. Doch der gemeinsame Nenner ist überall derselbe. Der Aussteller fand einen schnelleren, gezielteren oder günstigeren Weg zum selben Kunden, und der Veranstalter hatte nicht rechtzeitig Zahlen, um das Gegenteil zu belegen.
Eine Veranstaltung stirbt nicht auf einen Schlag. Sie stirbt zuerst in den Köpfen einiger guter Kunden, wenn diese merken, dass sie dieselben Kontakte über andere Kanäle erreichen.
Wer sich um die Daten seiner Veranstaltung kümmert, sichert ihren Fortbestand. Darum geht es in diesem Kurs.
Die Ontologie ist die Landkarte des Unternehmens in der Sprache des Geschäfts: die Dinge, die es gibt (Substantive), wie sie zusammenhängen und was man mit ihnen tun kann (Verben), alles verbunden mit den echten Daten.
Denken Sie daran, wie ein Unternehmen heute Informationen speichert. Es gibt eine Ausstellerliste in Excel, ein CRM mit Kontakten, ein Finanzsystem mit Verträgen, eine Datenbank für die Besucherakkreditierung. Jedes System nennt dieselbe Sache anders, speichert sie in einer anderen Tabelle, mit kryptischen Spalten wie cd_cli, id_exp_2, vl_ctr.
Wer eine einfache Frage beantworten will („Welche Aussteller der März-Messe haben noch nicht bezahlt, aber ihren Stand schon bestätigt?“), muss wissen, wo jede Tabelle liegt, wie man sie miteinander verknüpft und was jede Spalte bedeutet. Dieses Wissen steckt in den Köpfen von zwei oder drei Personen.
Die Ontologie löst das mit einer Schicht über all diesen Daten, in der die Dinge so heißen, wie das Geschäft sie nennt: Es gibt einen Aussteller, eine Messe, einen Vertrag. Sie sind verbunden: Ein Aussteller unterzeichnet Verträge, ein Vertrag gehört zu einer Messe. Und es gibt Verben: Stand reservieren, Zahlung erfassen.
Viele nennen das den digitalen Zwilling des Geschäfts. Für einen Veranstalter ist es das lebendige Abbild der Veranstaltung: jeder Aussteller, jeder Besucher, jeder Vertrag und jede Gegenleistung, miteinander verbunden. Menschen, Anwendungen und KI-Agenten arbeiten dann auf dieser Landkarte statt auf losen Tabellen.
Bevor wir über Modelle sprechen, lohnt ein Blick auf das, was Sie bereits erfassen. Eine durchschnittliche Veranstaltung erzeugt Daten an mindestens sieben Stellen:
| Wo es liegt | Was es speichert |
|---|---|
| Anmeldung und Akkreditierung | Wer sich angemeldet hat, Kategorie, Position, Unternehmen, bezahlter Betrag |
| Einlasskontrolle | Wer tatsächlich kam, an welchem Tag, um welche Uhrzeit, durch welchen Eingang |
| App oder Lead-Scanner | Welche Besucher jeder Aussteller am Stand gescannt hat |
| Vertriebs-CRM | Verhandlungen über Stände und Pakete, Angebote, Kontakte der Aussteller |
| Finanzen | Verträge, Raten, Zahlungsausfälle |
| Umfragen | Zufriedenheit und NPS von Besuchern und Ausstellern |
| Marketing | E-Mail-Verteiler, Kampagnen, Herkunft jeder Anmeldung |
Das Problem ist nicht der Mangel an Daten. Das Problem ist, dass dieselbe Person dreimal auftaucht, mit verschiedenen E-Mail-Adressen, in drei Systemen. Dasselbe Unternehmen ist in einem System Aussteller, in einem anderen Sponsor und hat in einem dritten 40 Mitarbeiter als Besucher, und niemand sieht das zusammen.
Und Datenqualität zeigt sich im Ergebnis. In einem B2B-Messeportfolio, das wir begleiten, hat sich die Öffnungsrate der E-Mails an Besucher und Aussteller in vier Jahren mehr als verdoppelt. Das lag an keiner genialen Kampagne: Die Datenbasis wurde sauberer, ohne Dubletten, und besser segmentiert. Im selben Zeitraum schwankten die Ergebnisse von Messe zu Messe im selben Portfolio stark. Deshalb lohnt es sich, jede Veranstaltung einzeln zu messen.
Genau das löst die Ontologie: ein einziger Besucher, ein einziges Unternehmen, verbunden mit allem, was sie in allen Ausgaben getan haben.
Jede gute Modellierung beginnt mit Geschäftsfragen. Das sind die häufigsten bei Veranstaltern, und das braucht das Modell, um sie zu beantworten:
| Frage | Was das Modell braucht |
|---|---|
| Welche Aussteller verlängern für die nächste Ausgabe? | Vertrag pro Ausgabe, Verlängerungshistorie und was jeder Aussteller bekommen hat (Leads, Besuche) |
| Was war die Veranstaltung jedem Aussteller wert? | Lead, der Aussteller mit Besucher verbindet, mit Position und Branche des Besuchers |
| Wie viele Angemeldete sind nicht erschienen? | Anmeldung und Einlass, verbunden mit demselben Besucher |
| Welches Publikum will jeder Aussteller treffen? | Zielgruppe beim Aussteller und Profil (Position, Branche, Größe) beim Besucher |
| Haben wir den Sponsoren alles geliefert, was wir verkauft haben? | Paket mit seinen Gegenleistungen, jede mit Frist und Status |
| Welche Unternehmen besuchen oft, haben aber nie ausgestellt? | Besucher verbunden mit Unternehmen, demselben Unternehmen, das Aussteller werden kann |
Achten Sie auf die letzte Zeile. Mit getrennten Daten ist diese Liste an Vertriebschancen unsichtbar. Mit der Ontologie ist sie einen Filter entfernt.
Eine wettbewerbsfähige Messe ist nicht die mit dem vollsten Gang. Es ist die, die dem Aussteller einen Neukunden zu geringeren Kosten bringt als jeder andere Kanal. Ihr Aussteller macht diese Rechnung, auch ohne es zu merken. Nur wenige Veranstalter machen sie.
Sehen Sie sich den Trichter eines typischen Ausstellers mit einem 75-m²-Stand an (Beispielzahlen in der Größenordnung, die am Markt üblich ist):
Hat dieser Aussteller R$ 200.000 in die Veranstaltung investiert (Stand, Aufbau, Personal, Reise), kostete jeder Kunde R$ 12.500. Das sind die CAC der Messe, die Kundenakquisitionskosten. Bekommt derselbe Aussteller ähnliche Kunden für R$ 8.000 über gezielte Anzeigen oder ein Pre-Sales-Team, hat Ihre Messe den Vergleich verloren, auch wenn der Gang voll war.
Und es kommt noch etwas hinzu: Wenn sich niemand um das Besucherprofil kümmert, sinkt die durchschnittliche Qualifikation der Besucher mit jeder Ausgabe, und die CAC des Ausstellers steigen mit. Testen Sie es im Simulator unten.
| Ausgabe | % mit Profil | CAC der Messe |
|---|
Illustrativer Simulator. Die Startwerte sind Beispiele; ersetzen Sie sie durch die Zahlen eines Ihrer echten Aussteller.
Um diese Rechnung mit echten Zahlen zu machen, Ausgabe für Ausgabe, braucht Ihr Modell einige Bausteine. Hier hört Modellierung auf, ein IT-Thema zu sein, und wird zur Strategie:
| Kennzahl der Wettbewerbsfähigkeit | Woher sie im Modell kommt |
|---|---|
| Qualifikation des Publikums | Besucher mit Position, Branche und Größe des Unternehmens, verglichen mit der Zielgruppe jedes Ausstellers |
| Qualifizierte Kontakte pro Aussteller | Lead, der Aussteller und Besucher verbindet, nach Profil gefiltert |
| CAC der Messe | Investition des Ausstellers (im Vertrag oder von ihm angegeben) geteilt durch die Abschlüsse, die er in der Umfrage nach der Veranstaltung angibt |
| Trend über die Ausgaben | All das verbunden mit der Ausgabe, um ein Jahr mit dem anderen zu vergleichen |
| Risiko der Nichtverlängerung | churnRisiko(aussteller), das Leads, Zufriedenheit und Historie kombiniert |
Damit ändert der Veranstalter, was er verkauft. Er verkauft nicht mehr Quadratmeter, sondern planbare Geschäftsergebnisse: „Im letzten Jahr erhielten Unternehmen Ihrer Branche im Schnitt so viele Kontakte mit diesem Profil.“ Ein besseres Argument für die Verlängerung gibt es nicht.
Zwei Beobachtungen aus der Praxis. Erstens kostet Datenintelligenz wenig im Vergleich zu dem, was auf dem Spiel steht: Umgelegt auf die Stände und Besucher einer durchschnittlichen Veranstaltung sind es wenige Reais pro Besucher. Ein einziger zusätzlicher Vertrag zahlt die Investition um ein Vielfaches zurück. Zweitens reift das nicht in einer einzigen Ausgabe: Der Wandel von „Besuchervolumen“ zu „Beziehungsreise“ dauert meist zwei bis drei Jahre. Wer erst anfängt, wenn die guten Aussteller schon gegangen sind, fängt zu spät an.
Das sind dieselben Daten in zwei Ansichten. Wechseln Sie zwischen ihnen.
tb_ctr_2026.csv (Finanzsystem)
| id_ctr | cd_cli | cd_evt | nr_est | vl_ctr | st | dt_ass |
|---|---|---|---|---|---|---|
| C-8812 | 40221 | AUR-2026 | B14 | 48000.00 | 2 | 2026-01-19 |
| C-8813 | 40517 | AUR-2026 | A02 | 112500.00 | 1 | 2026-01-22 |
| C-8820 | 40221 | BRV-2026 | C07 | 51000.00 | 1 | 2026-02-03 |
Was bedeutet st = 2? Wer ist Kunde 40221? Welche Messe ist AUR-2026? Um das herauszufinden, müssen Sie drei weitere Tabellen öffnen und jemanden fragen.
Derselbe Datensatz, jetzt mit Namen, Bedeutung, Nachbarn und den Aktionen, die jemand ausführen kann. Sie klicken auf den Aussteller und sehen alle seine Verträge, auf allen Messen. (Namen und Werte erfunden.)
Beachten Sie: Die Daten haben sich nicht verändert. Sie kommen weiterhin aus derselben Tabelle der Finanzabteilung. Die Ontologie hat ihnen Bedeutung gegeben: Codes übersetzt, Spalten benannt, mit anderen Daten verknüpft und Aktionen angehängt. Das ist die ganze Arbeit, wiederholt für jedes wichtige Ding im Geschäft.
Jede operative Ontologie wird aus diesen Bausteinen gebaut. Verstehen Sie jeden gut, denn alles andere ist eine Kombination daraus.
Die Definition eines „Dings“ im Geschäft: Aussteller, Messe, Stand, Besucher. Jeder Objekttyp wird von einem Dataset gespeist (einer Tabelle Ihrer Datenbank), und jede Zeile dieser Tabelle wird zu einem Objekt. Die Ausstellertabelle mit 1.200 Zeilen wird zu 1.200 Aussteller-Objekten.
Jeder Objekttyp braucht einen Primärschlüssel (primary key): eine Spalte, die jedes Objekt eindeutig identifiziert und sich mit der Zeit nicht ändert, etwa die CNPJ oder ein interner Code. Und er hat einen Titel (title key): die Eigenschaft, die als Name des Objekts auf dem Bildschirm erscheint, etwa der Firmenname.
Analogie: Der Objekttyp ist die Form; jedes Objekt ist ein Stück aus dieser Form.
Die Merkmale des Objekts: Name, CNPJ, Branche, Stadt, Vertragswert, Datum. Jede Eigenschaft stammt aus einer Spalte des Datasets, aber mit lesbarem Namen und festgelegtem Typ (Text, Zahl, Datum, Geoposition usw.). Hier wird aus st = 2 ein Status: Bezahlt.
Die Beziehung zwischen zwei Objekttypen. Jeder Link hat eine Kardinalität, und sie richtig festzulegen, ist die halbe Modellierungsarbeit:
Links ermöglichen das Navigieren: von einer Messe zu ihren Ausstellern, zu deren Verträgen, zu den überfälligen. Ganz ohne Tabellen-Joins zu schreiben.
Hier unterscheidet sich eine operative Ontologie von einem einfachen Datenkatalog. Eine Aktion ist eine autorisierte Veränderung in der Welt: Objekte und Links anlegen, bearbeiten oder löschen, kontrolliert. Eine Aktion hat:
Wenn eine Aktion ein Objekt ändert, speichert die Ontologie die Änderung über den Originaldaten (Writeback). Das Quell-Dataset wird nicht überschrieben; die Ontologie führt beides zusammen und zeigt den aktuellen Stand. Und es wird festgehalten, wer was wann getan hat.
Code (TypeScript oder Python), der auf den Objekten läuft. Er dient drei Zwecken:
Eine „gemeinsame Form“, die mehrere Objekttypen teilen. Aussteller, Besucher und Sponsor sind verschiedene Dinge, aber alle haben Name, E-Mail, Unternehmen und Telefon. Sie legen das Interface Kontakt mit diesen Eigenschaften an, und jede Anwendung oder Aktion, die mit „Kontakt“ arbeitet, funktioniert mit allen dreien. So bauen Sie nicht dreimal dieselbe Maske.
Objektmenge (object set). Kein Baustein, den Sie definieren, aber Sie werden den Begriff ständig hören: Es ist jede Gruppe von Objekten, die aus einem Filter oder einer Navigation entsteht. „Aussteller der Textilbranche mit offenem Vertrag“ ist ein Object Set. Anwendungen, Analysen und KI arbeiten, indem sie Object Sets hin und her reichen.
So sieht ein einfaches, aber realistisches Modell für ein Unternehmen aus, das Messen veranstaltet. Lesen Sie die Zeichnung entlang der Pfeile.
Vier Entscheidungen in dieser Zeichnung lohnen sich zu verstehen, denn genau solche Entscheidungen trennen Einsteiger von Experten:
Man kann sich die Ontologie in drei Ebenen vorstellen. Sie helfen zu verstehen, warum sie mehr ist als ein Datenkatalog.
Was es gibt. Objekte, Eigenschaften und Links. Dieser Teil gibt den Daten Bedeutung. Er beantwortet: „Wie viele Aussteller aus der Textilbranche haben wir auf der März-Messe?“
Was man tun kann. Aktionen, Regeln und Integrationen mit Systemen. Dieser Teil macht aus Analyse Betrieb. Sie sehen nicht nur, dass der Aussteller im Zahlungsverzug ist: Sie klicken auf Mahnung senden, und die Aktion wird ausgeführt und protokolliert.
Wie man entscheidet. Funktionen, Modelle, Simulationen und KI auf Basis der beiden anderen Ebenen. „Wenn ich eine weitere Halle öffne, wie viele Stände verkaufe ich zusätzlich?“ „Welche Aussteller haben das höchste Risiko, nicht zu verlängern?“ Die getroffene Entscheidung kommt als Aktion zurück, und ihr Ergebnis wird zu neuen Daten. Der Kreis schließt sich.
Für einen Veranstalter wird das konkret: Das Modell zeigt, dass ein Aussteller wenige Leads bekommen hat (Semantik), eine Funktion berechnet das Risiko, dass er nicht verlängert (Dynamik), und der Vertrieb löst die Aktion Standverlegung anbieten aus, bevor er abspringt (Kinetik).
Merken Sie sich diesen Kreislauf, denn er ist die Kernidee einer operativen Ontologie: Daten → Entscheidung → Aktion → neue Daten, alles am selben Ort. Die meisten Datenwerkzeuge hören bei „Daten → Dashboard“ auf. Das Dashboard zeigt das Problem, und die Person löst es in einem anderen System, ohne Protokoll.
Wer den Weg versteht, vermeidet viel Verwirrung. Er ist immer gleich:
Klassischer Einsteigerfehler: die Tabelle so abbilden, wie sie aus dem System kommt. Hat die Rohtabelle 80 Spalten mit kryptischen Namen und doppelte Zeilen, erbt der Objekttyp all das. Eine gute Ontologie entsteht aus einem bereits bereinigten Dataset, das für sie gedacht ist. Die Pipeline-Arbeit kommt zuerst.
Für den Einstieg brauchen Sie keine teure Plattform. Die Denkweise der Modellierung gilt auch für eine gut strukturierte Tabelle, ein Airtable oder eine einfache Datenbank. Es lohnt sich aber, die Werkzeuge zu kennen, die größere Plattformen auf der Ontologie anbieten, denn sie zeigen, wie weit das Modell reichen kann.
Für alle mit eigenem Tech-Team. Ein Beispiel, wie all das zusammenpasst: Mit einem Ontologie-SDK sieht der Code eines externen Systems so aus. Beachten Sie, dass Sie mit Ausstellern und Verträgen sprechen, nie mit Tabellen.
// Sucht Aussteller aus der Textilbranche mit offenem Vertrag auf der März-Messe const pending = await client(Exhibitor) .where({ segment: { $eq: "Textile" } }) .pivotTo("contracts") .where({ status: { $eq: "Pending" }, fairId: { $eq: "AUR-2026" } }) .fetchPage(); // Löst die Aktion aus, die die in der Ontologie definierten Regeln und Berechtigungen anwendet await client(registerPayment).applyAction({ contract: "C-8813", amount: 112500, });
Illustrativer Code. Die genaue Form der Methoden hängt von der verwendeten Plattform und dem SDK ab.
Wenn Sie ein KI-Modell bitten, „nachzusehen, welche Aussteller im Verzug sind, und eine Mahnung zu schicken“, braucht es drei Dinge, die ein loser Chat nicht hat:
st = 2 „bezahlt“ heißt. Die Ontologie weiß es und liefert das fertig mit. Das senkt deutlich das Risiko, dass die KI etwas erfindet oder Daten falsch verknüpft.Deshalb gilt die Ontologie als die Schicht, die KI im echten Betrieb nutzbar macht. Das Sprachmodell ist das austauschbare „Gehirn“; die Ontologie ist die Landkarte des Geschäfts und die Gesamtheit der autorisierten Hände.
Die Berechtigungen liegen in der Ontologie selbst und gelten in jedem Werkzeug, das sie nutzt. Sie lassen sich auf mehreren Ebenen festlegen:
Reifere Plattformen nutzen außerdem Markierungen (markings): Etiketten wie „personenbezogene Daten“, die die Daten überallhin begleiten, auch in abgeleitete Daten. Hat eine Tabelle eine markierte CPF, erbt alles, was daraus berechnet wird, die Einschränkung. Das ist für die LGPD unverzichtbar, besonders beim Lead-Scanning: Der Besucher muss eingewilligt haben, seine Daten mit dem Aussteller zu teilen, und diese Einwilligung muss eine erfasste Eigenschaft sein, keine Annahme.
Um wie ein Experte mitreden zu können, sollten Sie wissen, dass das Wort schon lange existiert und Ähnliches, aber nicht Gleiches bedeutet:
| Bedeutung | Was es ist | Unterschied zur operativen Ontologie |
|---|---|---|
| Philosophie | Disziplin, die untersucht, „was es gibt“ und wie sich Dinge einordnen lassen. | Der Ursprung des Namens. Die operative Ontologie wendet die Idee auf ein Unternehmen an. |
| Semantic Web | Standards wie RDF und OWL zur Beschreibung von Konzepten und Beziehungen, mit Fokus auf Interoperabilität und logischer Inferenz („jedes X ist ein Y, also …“). | Die operative Ontologie nutzt kaum logische Inferenz. Der Fokus liegt auf dem Betrieb: echte Daten, Aktionen und Anwendungen. |
| Knowledge Graph | Netz aus Entitäten und Beziehungen, genutzt von Suchmaschinen und KI (z. B. Neo4j, Wikidata). | Ähnlich im semantischen Teil. Die operative Ontologie ergänzt Aktionen, Berechtigungen und Schreiben, die ein reiner Graph normalerweise nicht hat. |
| Semantische BI-Schicht | Standardisierte Kennzahlen und Dimensionen für Berichte (z. B. dbt Semantic Layer, LookML). | Dient zum Lesen und Messen. Ihr fehlt die kinetische Ebene des Handelns. |
Zum Merken: Die Ontologie in diesem Leitfaden ist operativ. Sie existiert, damit Menschen und KI entscheiden und handeln, nicht nur, um zu beschreiben oder zu messen.
Dieser Teil macht jemanden zum Experten. Das Werkzeug lernt man in Wochen; gut zu modellieren braucht Übung. Die wichtigsten Regeln:
Cliente_PJ. Der Test: Versteht ein Geschäftsführer, der das System nie gesehen hat, die Maske?Lesen Sie das Szenario und schreiben Sie auf, bevor Sie die Lösung öffnen, welche Objekte, Links und Aktionen Sie anlegen würden.
Szenario. Sie veranstalten einen jährlichen Medizinkongress mit Ausstellungsbereich. Die Teilnehmer melden sich in Kategorien an (Arzt, Assistenzarzt, Student), wählen wissenschaftliche Sessions und erhalten ein Badge mit QR-Code. Die Aussteller scannen per App das Badge der Standbesucher. Die Sponsoren kaufen Pakete (Gold, Silber, Bronze) mit Gegenleistungen: Logo auf der Website, gesponserte Session, E-Mail an die Angemeldeten. Sie wollen jedem Aussteller belegen, wie viele qualifizierte Kontakte er erhalten hat, und sicherstellen, dass jede versprochene Gegenleistung erbracht wurde.
Objekte: Veranstaltung Ausgabe Teilnehmer Anmeldung Session Unternehmen Aussteller Lead Paket Gegenleistung
Links: Veranstaltung hat Ausgaben (1:N) · Teilnehmer tätigt Anmeldungen (1:N) · Anmeldung gehört zur Ausgabe (N:1) · Anmeldung wählt Sessions (N:N) · Aussteller ist das Unternehmen (N:1) · Lead erfasst von Aussteller und von Teilnehmer · Unternehmen kauft Paket (1:N) · Paket sieht vor Gegenleistungen (1:N)
Aktionen: Teilnehmer akkreditieren · Lead erfassen · Gegenleistung als erbracht markieren · Paket verlängern
Funktion: qualifizierteLeads(aussteller), die nur die Leads von Ärzten der Fachrichtung zählt, die der Aussteller erreichen will.
Die Entscheidungen, die zählen:
Wenn Sie nah dran waren, denken Sie schon wie ein Modellierer. Wenn Sie alles in ein einziges Objekt gepackt haben, lesen Sie „Objekt oder Eigenschaft?“ noch einmal.
Jede prüft ein Konzept, das im Alltag vorkommt. Die Erklärung erscheint, sobald Sie antworten.
0 von 12 beantwortetDiese Lektüre gibt Ihnen das Vokabular und das Denkmodell. Wirklich beherrscht das Thema, wer schon viele Veranstaltungen modelliert und gesehen hat, was bricht. Der praktische Weg für Ihre nächste Ausgabe:
Il tuo evento genera dati di continuo: iscrizioni, badge letti, stand venduti, pacchetti di sponsorizzazione, lead, sondaggi. Quasi sempre restano sparsi in sistemi che non si parlano. Questo corso insegna a organizzare tutto in un unico modello, che risponde alle domande che contano di più per il business: chi rinnoverà, quanto ha reso all'espositore e dove si stanno lasciando soldi sul tavolo.
Il metro quadrato più caro è quello senza dati.
Ogni organizzatore se l'è sentito dire da un espositore: "il cliente giusto non c'era". Forse c'era. Solo non con il badge che ci si aspettava. Forse era fuori dal radar. O forse non era nemmeno stato invitato.
Niente sostituisce il faccia a faccia, e gli eventi restano la più grande piattaforma di relazioni del mercato. Ma ciò che l'espositore investe davvero non è solo denaro: è tempo. Quando il mercato comincia a scegliere dove spendere le proprie ore, inizia a pretendere prove. E le prove si fanno con i dati.
La più grande fiera dell'informatica degli anni '90, con circa 200 mila visitatori all'apice. Le grandi aziende se ne sono andate una dopo l'altra e l'ultima edizione si è tenuta nel 2003.
È stata la più grande fiera tecnologica del mondo. Dopo anni di calo di pubblico ed espositori, è stata chiusa nel 2018.
La principale fiera dell'orologeria. I grandi marchi se ne sono andati lamentando costi alti e scarso ritorno, e hanno iniziato a organizzare un evento proprio.
Punto di riferimento mondiale della fotografia per 70 anni, sospesa a tempo indeterminato nel 2020.
La grande vetrina dei videogiochi. Gli editori hanno iniziato a presentare i loro giochi con dirette proprie su internet, e l'evento è stato chiuso nel 2023.
Ogni caso ha avuto più cause: cambiamenti del mercato, costi, l'arrivo del digitale. Ma in tutti il punto in comune è lo stesso. L'espositore ha trovato una strada più rapida, più mirata o più economica per arrivare allo stesso cliente, e l'organizzatore non aveva numeri per dimostrare il contrario in tempo.
L'evento non muore di colpo. Muore prima nella testa di alcuni buoni clienti, quando si accorgono di trovare gli stessi contatti attraverso altri canali.
Curare i dati del tuo evento è il modo per garantire che continui a esistere. Questo corso parla proprio di questo.
L'Ontologia è la mappa dell'azienda nel linguaggio del business: le cose che esistono (sostantivi), come si collegano e cosa si può fare con esse (verbi), tutto collegato ai dati reali.
Pensa a come un'azienda conserva le informazioni oggi. C'è un foglio di calcolo degli espositori, un CRM con i contatti, un sistema amministrativo con i contratti, una base di accreditamento dei visitatori. Ogni sistema chiama la stessa cosa con un nome diverso, la conserva in una tabella diversa, con colonne criptiche tipo cd_cli, id_exp_2, vl_ctr.
Chi vuole rispondere a una domanda semplice ("quali espositori della fiera di marzo non hanno ancora pagato e hanno già confermato lo stand?") deve sapere dove si trova ogni tabella, come incrociarle e cosa significa ogni colonna. Queste conoscenze vivono nella testa di due o tre persone.
L'Ontologia risolve il problema creando un livello sopra tutti questi dati, dove le cose hanno il nome che usa il business: esiste un Espositore, esiste una Fiera, esiste un Contratto. Sono collegati: un Espositore firma Contratti, un Contratto è di una Fiera. Ed esistono i verbi: Prenotare stand, Registrare pagamento.
Molti lo chiamano gemello digitale del business. Per un organizzatore è il ritratto vivo dell'evento: ogni espositore, ogni visitatore, ogni contratto e ogni controprestazione, collegati. Persone, applicazioni e agenti di IA lavorano su questa mappa, e non più su fogli di calcolo sparsi.
Prima di parlare di modello, conviene guardare a ciò che già raccogli. Un evento medio genera dati in almeno sette posti:
| Dove si trova | Cosa contiene |
|---|---|
| Iscrizione e accreditamento | Chi si è iscritto, categoria, ruolo, azienda, importo pagato |
| Controllo accessi | Chi è entrato davvero, in che giorno e a che ora, da quale ingresso |
| App o scansione lead | Quali visitatori ogni espositore ha scansionato allo stand |
| CRM commerciale | Trattative per stand e pacchetti, proposte, contatti degli espositori |
| Amministrazione | Contratti, rate, insoluti |
| Sondaggi | Soddisfazione e NPS di visitatori ed espositori |
| Marketing | Database e-mail, campagne, provenienza di ogni iscrizione |
Il problema non è la mancanza di dati. È che la stessa persona compare tre volte, con e-mail diverse, in tre sistemi. La stessa azienda è espositrice in un sistema, sponsor in un altro e ha 40 dipendenti visitatori in un terzo, e nessuno riesce a vedere tutto insieme.
E la qualità dei dati si vede nei risultati. In un portafoglio di fiere B2B che seguiamo, il tasso di apertura delle e-mail a visitatori ed espositori è più che raddoppiato in quattro anni. Non per merito di qualche campagna geniale: il database è diventato più pulito, senza duplicati, e meglio segmentato. Nello stesso periodo, le prestazioni sono variate molto da una fiera all'altra all'interno dello stesso portafoglio, ed è per questo che conviene misurare evento per evento.
L'ontologia risolve proprio questo: un unico Visitatore, un'unica Azienda, collegati a tutto ciò che hanno fatto in tutte le edizioni.
Ogni buona modellazione parte da domande di business. Queste sono le più frequenti per gli organizzatori, insieme a ciò che il modello deve avere per rispondere:
| Domanda | Cosa deve avere il modello |
|---|---|
| Quali espositori rinnoveranno per la prossima edizione? | Contratto per Edizione, storico dei rinnovi e cosa ha ricevuto ogni espositore (lead, visite) |
| Quanto ha reso l'evento a ogni espositore? | Lead che collega Espositore e Visitatore, con ruolo e settore del visitatore |
| Quanti iscritti non si sono presentati? | Iscrizione e Accesso collegati allo stesso Visitatore |
| Quale pubblico vuole incontrare ogni espositore? | Pubblico target nell'Espositore e profilo (ruolo, settore, dimensione) nel Visitatore |
| Abbiamo consegnato agli sponsor tutto ciò che abbiamo venduto? | Pacchetto con le sue Controprestazioni, ognuna con scadenza e stato |
| Quali aziende visitano molto e non hanno mai esposto? | Visitatore collegato a Azienda, la stessa Azienda che può diventare Espositore |
Guarda l'ultima riga. Con i dati separati, questa lista di opportunità commerciali è invisibile. Con l'ontologia, basta un filtro.
Una fiera competitiva non è quella con il corridoio più pieno. È quella che porta all'espositore un nuovo cliente a un costo inferiore a quello di qualsiasi altro canale. Il tuo espositore fa questo conto, anche senza accorgersene. Pochi organizzatori lo fanno.
Ecco il funnel di un espositore tipico con uno stand di 75 m² (numeri di esempio, nell'ordine di grandezza che si vede sul mercato):
Se questo espositore ha investito R$ 200 mila nell'evento (stand, allestimento, personale, viaggio), ogni cliente gli è costato R$ 12.500. Questo è il CAC della fiera, il costo di acquisizione cliente. Se lo stesso espositore ottiene clienti simili a R$ 8 mila con annunci mirati o con un team di prevendita, la tua fiera ha perso la sfida, anche se il corridoio era pieno.
E c'è un'aggravante: quando nessuno cura il profilo del pubblico, la qualificazione media del visitatore cala a ogni edizione, e il CAC dell'espositore sale di pari passo. Provalo nel simulatore qui sotto.
| Edizione | % con profilo | CAC della fiera |
|---|
Simulatore illustrativo. I valori iniziali sono esempi; sostituiscili con i numeri di un tuo espositore reale.
Per fare questo conto con numeri veri, edizione dopo edizione, il tuo modello deve avere alcuni pezzi. È qui che la modellazione smette di essere una questione IT e diventa strategia:
| Indicatore di competitività | Da dove viene nel modello |
|---|---|
| Qualificazione del pubblico | Visitatore con ruolo, settore e dimensione dell'Azienda, confrontati con il pubblico target di ogni Espositore |
| Contatti qualificati per espositore | Lead che collega Espositore e Visitatore, filtrato per profilo |
| CAC della fiera | Investimento dell'espositore (nel Contratto o dichiarato da lui) diviso per gli affari che dichiara nel sondaggio post-evento |
| Tendenza tra edizioni | Tutto questo collegato all'Edizione, per confrontare un anno con l'altro |
| Rischio di mancato rinnovo | rischioChurn(espositore) che combina lead, soddisfazione e storico |
Con questi dati in mano, l'organizzatore cambia ciò che vende. Smette di vendere metri quadrati e inizia a vendere prevedibilità di business: "l'anno scorso, le aziende del tuo settore hanno ricevuto in media tanti contatti con questo profilo". È il miglior argomento di rinnovo che esista.
Due osservazioni di chi l'ha già fatto sul campo. Primo, l'intelligenza dei dati costa poco rispetto a ciò che c'è in gioco: divisa per gli stand e i visitatori di un evento medio, si riduce a pochi reais per visitatore. Basta un contratto in più per ripagare l'investimento molte volte. Secondo, non matura in una sola edizione: il passaggio da "volume di pubblico" a "percorso di relazione" richiede di solito da due a tre anni. Chi comincia quando i buoni espositori se ne sono già andati, comincia tardi.
Questo è lo stesso dato visto in due modi. Passa dall'uno all'altro.
tb_ctr_2026.csv (sistema amministrativo)
| id_ctr | cd_cli | cd_evt | nr_est | vl_ctr | st | dt_ass |
|---|---|---|---|---|---|---|
| C-8812 | 40221 | AUR-2026 | B14 | 48000.00 | 2 | 2026-01-19 |
| C-8813 | 40517 | AUR-2026 | A02 | 112500.00 | 1 | 2026-01-22 |
| C-8820 | 40221 | BRV-2026 | C07 | 51000.00 | 1 | 2026-02-03 |
Cosa significa st = 2? Chi è il cliente 40221? Quale fiera è AUR-2026? Per saperlo devi aprire altre tre tabelle e chiedere a qualcuno.
Lo stesso record, ora con nome, significato, vicini e le azioni che qualcuno può compiere. Clicchi sull'Espositore e vedi tutti i suoi contratti, in tutte le fiere. (Nomi e valori fittizi.)
Nota che il dato non è cambiato. Continua ad arrivare dalla stessa tabella dell'amministrazione. Quello che l'Ontologia ha fatto è dargli significato: ha tradotto i codici, dato un nome alle colonne, lo ha collegato ad altri dati e gli ha agganciato delle azioni. Questo è tutto il lavoro, ripetuto per ogni cosa importante del business.
Ogni ontologia operativa è costruita con questi pezzi. Capiscili bene uno per uno, perché il resto è una loro combinazione.
È la definizione di una "cosa" del business: Espositore, Fiera, Stand, Visitatore. Ogni tipo di oggetto è alimentato da un dataset (una tabella del tuo database), e ogni riga di quella tabella diventa un oggetto. La tabella degli espositori con 1.200 righe diventa 1.200 oggetti Espositore.
Ogni tipo di oggetto ha bisogno di una chiave primaria (primary key): una colonna che identifica ogni oggetto in modo univoco e che non cambia nel tempo, come il codice fiscale aziendale (CNPJ) o un codice interno. E ha un titolo (title key): la proprietà che compare come nome dell'oggetto sullo schermo, come la ragione sociale.
Analogia: il tipo di oggetto è lo stampo; ogni oggetto è un pezzo uscito dallo stampo.
Le caratteristiche dell'oggetto: nome, CNPJ, settore, città, importo del contratto, data. Ogni proprietà viene da una colonna del dataset, ma con un nome leggibile e un tipo definito (testo, numero, data, geolocalizzazione, ecc.). È qui che st = 2 diventa Stato: Pagato.
La relazione tra due tipi di oggetto. Ogni link ha una cardinalità, e azzeccarla è metà del lavoro di modellazione:
I link sono ciò che permette di navigare: partire da una Fiera, vedere i suoi Espositori, vedere i loro Contratti, vedere quali sono in ritardo. Senza scrivere alcun incrocio tra tabelle.
È qui che un'ontologia operativa si distingue da un semplice catalogo di dati. Un'azione è un cambiamento autorizzato nel mondo: creare, modificare o eliminare oggetti e link, in modo controllato. Un'azione ha:
Quando un'azione modifica un oggetto, la modifica viene registrata dall'Ontologia sopra il dato originale (writeback). Il dataset di origine non viene sovrascritto; l'Ontologia unisce le due cose e mostra lo stato attuale. E resta traccia di chi ha fatto cosa, e quando.
Codice (TypeScript o Python) che gira sugli oggetti. Serve a tre cose:
Una "forma comune" condivisa da più tipi di oggetto. Espositore, Visitatore e Sponsor sono cose diverse, ma hanno tutti nome, e-mail, azienda e telefono. Crei l'interfaccia Contatto con queste proprietà, e qualsiasi applicazione o azione che lavori con "Contatto" funziona con tutti e tre. Così eviti di costruire la stessa schermata tre volte.
Insieme di oggetti (object set). Non è un blocco che definisci, ma sentirai il termine di continuo: è qualsiasi gruppo di oggetti risultante da un filtro o da una navigazione. "Espositori del settore tessile con contratto aperto" è un object set. Applicazioni, analisi e IA lavorano passandosi object set da una parte all'altra.
Ecco come appare un modello semplice, ma realistico, per un'azienda che organizza fiere. Leggi il disegno seguendo le frecce.
Quattro decisioni di questo disegno vale la pena capirle, perché sono esattamente il tipo di scelta che separa il principiante dall'esperto:
Si può pensare l'ontologia in tre livelli. Aiutano a capire perché è più di un catalogo di dati.
Cosa esiste. Oggetti, proprietà e link. È la parte che dà significato al dato. Risponde a "quanti espositori del settore tessile abbiamo nella fiera di marzo?".
Cosa si può fare. Azioni, regole e integrazioni con i sistemi. È la parte che trasforma l'analisi in operatività. Non vedi solo che l'espositore è insolvente: clicchi su Inviare sollecito e l'azione avviene, registrata.
Come decidere. Funzioni, modelli, simulazioni e IA che usano i due livelli precedenti. "Se apro un altro padiglione, quanti stand in più vendo?" "Quali espositori hanno il rischio più alto di non rinnovare?" La decisione presa torna come azione, e il suo risultato diventa un nuovo dato. Il ciclo si chiude.
Per un organizzatore diventa concreto: il modello mostra che un espositore ha ricevuto pochi lead (semantica), una funzione calcola il rischio che non rinnovi (dinamica), e il commerciale avvia l'azione Offrire riposizionamento dello stand prima che rinunci (cinetica).
Ricorda questo ciclo, perché è l'idea centrale di un'ontologia operativa: dato → decisione → azione → nuovo dato, tutto nello stesso posto. La maggior parte degli strumenti di dati si ferma a "dato → dashboard". La dashboard mostra il problema e la persona va a risolverlo in un altro sistema, senza traccia.
Capire il percorso evita molta confusione. Funziona sempre così:
Errore classico da principiante: mappare la tabella così come arriva dal sistema. Se la tabella grezza ha 80 colonne con nomi criptici e righe duplicate, il tipo di oggetto erediterà tutto questo. Una buona ontologia nasce da un dataset già pulito e pensato per lei. Il lavoro di pipeline viene prima.
Non ti serve una piattaforma costosa per iniziare. Il ragionamento di modellazione vale per un foglio di calcolo ben strutturato, un Airtable o un semplice database. Ma è utile conoscere gli strumenti che le piattaforme più grandi offrono sopra l'ontologia, perché mostrano fin dove può arrivare il modello.
Per chi ha un team tecnico. Un esempio di come tutto si incastra: con un SDK di ontologia, il codice di un sistema esterno appare così. Nota che parli con Espositori e Contratti, mai con tabelle.
// Cerca gli espositori tessili con contratto in sospeso nella fiera di marzo const pending = await client(Exhibitor) .where({ segment: { $eq: "Textile" } }) .pivotTo("contracts") .where({ status: { $eq: "Pending" }, fairId: { $eq: "AUR-2026" } }) .fetchPage(); // Avvia l'azione, che applica le regole e i permessi definiti nell'ontologia await client(registerPayment).applyAction({ contract: "C-8813", amount: 112500, });
Codice illustrativo. La forma esatta dei metodi dipende dalla piattaforma e dall'SDK utilizzati.
Quando chiedi a un modello di IA di "vedere quali espositori sono in ritardo e inviare un sollecito", gli servono tre cose che una chat isolata non ha:
st = 2 vuol dire "pagato". L'ontologia lo sa, e glielo fornisce già pronto. Questo riduce molto il rischio che l'IA inventi o incroci dati in modo sbagliato.Per questo l'ontologia è vista come il livello che rende l'IA utilizzabile nell'operatività reale. Il modello linguistico è il "cervello" sostituibile; l'ontologia è la mappa del business e l'insieme delle mani autorizzate.
I permessi stanno nell'ontologia stessa e valgono in qualsiasi strumento che la usi. Si possono definire a più livelli:
Le piattaforme più mature usano anche le marcature (markings): etichette come "dati personali" che accompagnano il dato ovunque passi, anche nei derivati. Se una tabella ha il codice fiscale (CPF) marcato, qualsiasi cosa calcolata a partire da essa eredita la restrizione. Questo è essenziale per la LGPD (la legge brasiliana sulla protezione dei dati), soprattutto nella scansione dei lead: il visitatore deve aver acconsentito a condividere i suoi dati con l'espositore, e questo consenso deve essere una proprietà registrata, non un'ipotesi.
Per parlare da esperto, devi sapere che la parola esiste da molto tempo e indica cose simili, ma non uguali:
| Significato | Che cos'è | Differenza rispetto all'ontologia operativa |
|---|---|---|
| Filosofia | Branca che studia "ciò che esiste" e come si classificano le cose. | L'origine del nome. L'ontologia operativa applica l'idea a un'azienda. |
| Web semantico | Standard come RDF e OWL per descrivere concetti e relazioni, con focus su interoperabilità e inferenza logica ("ogni X è Y, quindi..."). | L'ontologia operativa usa pochissimo l'inferenza logica. Il focus è l'operatività: dati reali, azioni e applicazioni. |
| Knowledge graph | Rete di entità e relazioni, usata dai motori di ricerca e dall'IA (es.: Neo4j, Wikidata). | Simile nella parte semantica. L'ontologia operativa aggiunge azioni, permessi e scrittura, che un grafo puro di solito non ha. |
| Livello semantico di BI | Metriche e dimensioni standardizzate per i report (es.: dbt Semantic Layer, LookML). | Serve a leggere e misurare. Non ha il livello cinetico per agire. |
In sintesi: l'ontologia di questa guida è operativa. Esiste perché persone e IA prendano decisioni e agiscano, non solo per descrivere o misurare.
Questa è la parte che rende qualcuno un esperto. Lo strumento si impara in settimane; modellare bene richiede pratica. Le regole che contano di più:
Cliente_PJ. Il test: un direttore che non ha mai visto il sistema capisce la schermata?Leggi lo scenario e scrivi, prima di aprire la risposta, quali oggetti, link e azioni creeresti.
Scenario. Organizzi un congresso medico annuale con un'area espositiva. I partecipanti si iscrivono per categorie (medico, specializzando, studente), scelgono le sessioni scientifiche e ricevono un badge con QR code. Gli espositori usano un'app per scansionare il badge di chi visita lo stand. Gli sponsor acquistano pacchetti (Oro, Argento, Bronzo) con controprestazioni: logo sul sito, sessione sponsorizzata, e-mail al database degli iscritti. Vuoi dimostrare a ogni espositore quanti contatti qualificati ha ricevuto e garantire che ogni controprestazione promessa sia stata consegnata.
Oggetti: Evento Edizione Partecipante Iscrizione Sessione Azienda Espositore Lead Pacchetto Controprestazione
Link: Evento ha Edizioni (1:N) · Partecipante fa Iscrizioni (1:N) · Iscrizione appartiene a Edizione (N:1) · Iscrizione sceglie Sessioni (N:N) · Espositore corrisponde a Azienda (N:1) · Lead raccolto da Espositore e di Partecipante · Azienda acquista Pacchetto (1:N) · Pacchetto prevede Controprestazioni (1:N)
Azioni: Accreditare partecipante · Registrare lead · Segnare controprestazione come consegnata · Rinnovare pacchetto
Funzione: leadQualificati(espositore), che conta solo i lead di medici della specializzazione che l'espositore vuole raggiungere.
Le decisioni che contano:
Se ci sei andato vicino, stai già pensando da modellatore. Se hai messo tutto in un solo oggetto, rileggi "Oggetto o proprietà?".
Ognuna mette alla prova un concetto che compare nel lavoro di tutti i giorni. La spiegazione appare quando rispondi.
0 di 12 risposteLeggere questa pagina ti dà il vocabolario e il modello mentale. Chi padroneggia l'argomento è chi ha già modellato molti eventi e ha visto cosa si rompe. Il percorso pratico per la tua prossima edizione: