Read this article in English

Nota de 03/10/2026 — a ontologia ganhou uma experiência nova. A documentação agora chama o item descrito aqui de old experience. Item novo criado pela interface já nasce na experiência nova; a antiga ainda se cria por API e CI/CD, e “The old experience of ontology retires on Jan 31, 2027.” Na nova, o grafo não carrega dado por padrão: materializar virou opt-in, e a Microsoft diz que isso substitui “the earlier framing that presented every ontology as having an automatically materialized instance graph”. A fatura passou a ter três medidores: Ontology Discovery, a 1.000 CU-segundos por leitura da definição, com releitura automática aproximadamente a cada 20 minutos enquanto a interface fica aberta; Ontology Logic and Operations, à tarifa do item filho; e Ontology AI, de consumo dinâmico. A definição virou TMDL e entra no Git; chegaram versões nomeadas — que a FAQ ainda nega —, importação de TTL, RDF e OWL e measures DAX como métricas. O que continua valendo: a visão geral diz que o consumo pode consultar a fonte ligada ao vivo, mas a página de binding ainda pede refresh manual para enxergar linha nova, e mudar o schema faz o grafo materializado reingerir todo o dado ligado. Onde há grafo, frescor segue sendo decisão de custo. O diagrama, o passo a passo, a definição em JSON e a tabela de medidores abaixo descrevem a experiência antiga; por isso as referências agora apontam para as páginas old experience, e o desenho novo está na visão geral atual.

A demonstração foi impecável: Cliente, Contrato, a relação entre os dois, uma pergunta em português e o grafo abrindo o caminho inteiro. O time de dados saiu da sala convencido de que tinha visto o vocabulário do banco virar software. Duas semanas depois, num workspace de verdade, a mesma pergunta devolveu um número que ninguém reconheceu: era o número de terça-feira. As linhas novas estavam no lakehouse desde as seis da manhã, e o grafo não sabia que elas existiam. O conserto óbvio — agendar a atualização de hora em hora — é justamente o caro: neste item, toda atualização reprocessa tudo.

Do diagrama ao item A ontologia saiu do slide. No Microsoft Fabric ela é um item de workspace, com REST API, definição em arquivos, um item filho que nasce junto sem ninguém pedir e — a parte que quase ninguém lê antes de ligar — medidores próprios na fatura de capacidade. Deixou de ser desenho para virar coisa que se implanta, se versiona e se paga.

O que é a ontologia do Fabric IQ?

É o item que traz o vocabulário da empresa para dentro do Fabric. A documentação o define como a peça que “digitally represents the enterprise vocabulary and semantic layer that unifies meaning across domains and OneLake sources”, montada com três construtos: entity types (Customer), properties (name, email) e relationships (Customer places Order). A página traz o aviso que vale para todo o resto: “This feature is in preview”.

O Fabric IQ não é um motor novo: é “a grouping of related Fabric items”, e só dois são exclusivos dele: o Planning e a ontologia.

A FAQ traça a fronteira com o vizinho que faz o trabalho pesado:

“Ontology provides a semantic layer for your enterprise vocabulary that unifies meaning across domains and OneLake sources. […] [Graph in Microsoft Fabric] is a graph solution that offers native graph storage and compute for nodes, edges, and traversals over connected data.”

Significado de um lado; armazenamento e computação do outro. Guarde essa separação: ela volta na hora da fatura, e volta invertida.

O problema que resolve

O problema é antigo e não é técnico: a mesma palavra significa coisas diferentes em sistemas diferentes. Cliente ativo no CRM não é cliente ativo no motor de crédito, e nenhum dos dois é o do relatório que vai para o comitê. A ontologia sobe a definição um andar: o conceito passa a existir acima da tabela, declarado uma vez, e a tabela vira origem do conceito, não a definição dele.

Foi essa a tese do artigo sobre ontologia de dados governados, publicado aqui em agosto. Lá o assunto era o significado acordado entre pessoas. Aqui é o artefato, a fatura e o que ele não faz.

O que tornou isso urgente é que o consumidor mudou: quem lê o vocabulário agora é um agente. A camada de consulta despacha a pergunta para o motor de cada fonte — “such as GQL for Graph in Microsoft Fabric and KQL for Eventhouse” — e, por cima dela, a camada NL2Ontology converte linguagem natural em consulta estruturada. O agente que pergunta quantos contratos vencem este mês não precisa saber em que tabela isso mora. Precisa que Contrato esteja definido, ligado a dado real e atualizado.

Esse último adjetivo é o artigo inteiro.

Como funciona — passo a passo

1. Crie o item no workspace, pela interface ou por Create Ontology. Sem você pedir, nasce junto um segundo item: “When you create an ontology item, a managed Graph item is created automatically.”
2. Declare entity types e propriedades — ou gere o esqueleto a partir de um modelo semântico e ajuste à mão séries temporais, chaves e o binding das relações.
3. Declare os relationship types. Relação sem dado é permitida, mas, sem binding, ela “isn’t visualized in the entity type details”.
4. Ligue cada entidade a uma origem: tabela gerenciada de lakehouse ou eventhouse.
5. Deixe o grafo filho ingerir. Cada nó ou aresta guarda a linhagem da origem.
6. Consulte por GQL, por KQL, em linguagem natural ou por um agente via MCP.
7. Decida quando reingerir. Mudança na fonte não aparece sozinha — e é aqui que mora o custo.

O item é real: REST API, definição em arquivo e um grafo filho

É isto que muda a conversa com a engenharia. A ontologia tem sete operações de REST API — Create Ontology, Get Ontology, List Ontologies, Update Ontology, Delete Ontology, Get Ontology Definition e Update Ontology Definition —, e a criação e as operações de definição aceitam service principal e identidade gerenciada, não só usuário. Criar pede papel contributor no workspace; mexer na definição, “read and write permissions for the ontology”. Vocabulário vira código, com pipeline e sem ninguém clicando.

A definição é um pacote de arquivos — “Ontology items support the JSON format” —, e o arquivo raiz não guarda o modelo: “The DefinitionDetails file name is definition.json. It is an empty definition.” O conteúdo mora nos diretórios:

definition.json                             obrigatório · definição vazia
.platform                                   obrigatório · detalhes da plataforma
EntityTypes/{ID}/definition.json            o conceito
EntityTypes/{ID}/DataBindings/              um arquivo JSON por binding
EntityTypes/{ID}/Documents/
EntityTypes/{ID}/Overviews/
EntityTypes/{ID}/ResourceLinks/
RelationshipTypes/{ID}/
RelationshipTypes/{ID}/Contextualizations/

Esse formato contorna uma limitação que a FAQ admite com todas as letras: “No, versioning isn’t currently available.” Não existe versão no item — mas a definição sai inteira por Get Ontology Definition e volta inteira por Update Ontology Definition, com identidade de serviço. O versionamento que o produto não tem, o seu repositório tem. Só leia a letra miúda da escrita: “The update overrides the current definition.” Sobrescreve, não faz merge.

Falta a peça que amarra o resto: quem guarda o dado não é a ontologia, e sim o item filho, que “is responsible for storing and displaying data”. O vocabulário mora num item; o dado, em outro — e a conta, como se verá, segue o dado.

O refresh é full, e o frescor virou decisão de custo

O coração do assunto começa com a documentação discordando de si mesma. A visão geral traz a mesma nota duas vezes — em Data binding e em Ontology graph —, e a página de binding a repete pela terceira:

“Any updates in upstream data sources (like new rows) need to be manually refreshed before they’re visible in the ontology item.”

Na mesma visão geral, porém, cada nó ou aresta “follows a scheduled data refresh”. Manual ou agendado? A página de detalhes da entidade resolve, e a resposta é melhor que os dois lados:

Informar o grafo é simples: menu ... do graph model no workspace, Schedule, Refresh now. O mesmo painel aceita “a recurring refresh schedule for the graph model”. O agendamento existe; o que não existe é captura de mudança. O problema não é o gatilho, é a granularidade — e o aviso da mesma página dá o tamanho dela:

“We recommend batching updates for refresh instead of refreshing the graph after every individual change, as the graph does a full refresh each time. This approach has cost implications for the Graph in Microsoft Fabric item.”

Cada refresh é integral. Não há incremental nem merge de linha nova: para mostrar o dado de hoje, o grafo reingere tudo o que está ligado, e paga CPU por isso. O mesmo vale para o schema: ajustar o modelo uma propriedade por vez, ao longo da tarde, é pagar a reingestão inteira a cada ajuste.

CADÊNCIA DO REFRESH     REINGESTÕES INTEGRAIS POR DIA     DEFASAGEM MÁXIMA
uma vez por dia                       1                        ~24 h
a cada 4 horas                        6                        ~4 h
a cada hora                          24                        ~1 h
sob demanda                     imprevisível          até alguém lembrar

pipeline incremental     custo ∝ linhas que mudaram       × execuções
refresh da ontologia     custo ∝ TUDO o que está ligado   × execuções

Num pipeline normal, aumentar a frequência custa proporcional ao delta. Aqui custa proporcional ao volume inteiro, toda vez. Frescor deixou de ser parâmetro de agendador e virou decisão de custo — e decisão de custo precisa de dono antes da primeira fatura, não depois.

A fatura: quatro medidores, e quem cobra é o grafo

A página de faturamento diz sem rodeio: “Billing for ontology (preview) is in effect”. Versão prévia, cobrança valendo, quatro medidores:

O Ontology Modeling conta definições — entity types, relações, propriedades e bindings —, e a janela cobra o modelo inteiro: no exemplo oficial, com 1.000 definições, editar uma propriedade custa 1.000 × 0,5 h × 0,0039 = 1,95 CU-hora. Uma segunda operação quinze minutos depois estende a medição para 45 minutos, não 60. Mudança em bloco sai mais barata que mudança avulsa, por construção.

O medidor que mais importa é o desligado, pelo que ele redireciona: “Ontology users are only billed for logic and operations according to their underlying Fabric Graph usage.” Ingestão, refresh e consulta ao grafo caem no Graph, com outra régua:

“Graph operations are billed based on CPU uptime. Each second of uptime incurs 10 CU-seconds in cost. Each session of CPU uptime is rounded up to minutes.”

Some o armazenamento: “a minimum of 100 GB”, à taxa do OneLake Cache. No Microsoft Fabric Capacity Metrics, a operação aparece como Graph general operations — e, quando a página da ontologia ensina a conter consumo, aponta para o filho: “you can edit or disable the Graph item schedule in your workspace.”

É aqui que a separação da FAQ volta invertida. No desenho, a ontologia é o significado e o Graph, o motor. Na fatura, quem cobra é o motor, e quem acompanha só o medidor com Ontology no nome vê uma fração da conta.

O medidor de IA escala por outro eixo. Uma requisição de 2.000 tokens de entrada e 500 de saída custa 1.600 CU-segundos, e uma F64 aguentaria “over 3,456 of these requests each day”. Esse custo sobe com o que se pergunta; o da reingestão, com o que está ligado — perguntem ou não.

Onde o binding realmente chega

A visão geral promete binding com “lakehouse tables, eventhouse streams, and Power BI semantic models”. Na tela, porém, só aparecem duas opções: lakehouse table e eventhouse. As regras que decidem o desenho:

• Só tabela gerenciada, “not external tables that show in the lakehouse but reside in a different location.”
• Nada de column mapping: “The ontology graph does not support delta tables with column mapping enabled.” Ele liga sozinho quando o nome da coluna tem caracteres como vírgula, ponto e vírgula, chaves, parênteses, quebra de linha, tabulação, = ou espaço — Valor do Contrato já basta — e nas tabelas delta de modelo semântico em modo Import.
• Uma ligação estática por entidade, de origem no OneLake. Série temporal aceita várias, de eventhouse e de lakehouse.
• Chave string ou inteiro, e nome de propriedade com 1 a 26 caracteres, único entre todos os entity types.

Gerar a partir de um modelo semântico — o atalho preferido de piloto — aperta a régua:

Leia a condição do Direct Lake até o fim do parêntese:

“Supported ONLY when backing lakehouse is in a workspace with inbound public access enabled (otherwise, the ontology item is created successfully but that entity type has no data bindings)”

Criado com sucesso — e sem binding. O item e as entidades estão lá; você descobre quando a consulta volta vazia. No meu mundo, isso não é caso de borda:

Em banco e seguradora no Brasil, workspace de lakehouse com acesso público de entrada habilitado é quase inexistente. O padrão é fechado — justamente o cenário em que a geração falha em silêncio.

E, mesmo no caminho feliz, medidas e colunas calculadas não atravessam: a regra de negócio acumulada nelas continua no modelo semântico.

Onde a documentação se contradiz

Documentação de preview se move, e em velocidades diferentes. Três divergências mudam desenho:

A primeira tem explicação plausível. O esquema de binding da API só conhece LakehouseTableDataBindingProperties e EventhouseTableDataBindingProperties. Gerar o esquema a partir do modelo semântico é uma coisa; ligar dado a ele é outra, e a visão geral parece misturar as duas.

A segunda é a que eu levaria para a primeira reunião de qualquer piloto em serviços financeiros. Com colunas Decimal, diz a página de geração, “you see null values returned for those properties on all queries” — e a nota ao lado diz o que está em jogo: “Decimal is a fixed-precision numeric type that is most commonly used for representing monetary values.” Saldo, limite, prêmio, exposição: tudo Decimal. A página de binding, atualizada depois, aceita decimal como origem de double e decimal(p, s) como origem de string, e nenhum texto reconcilia as duas. Teste com valor, não com contagem de linhas: null numa propriedade não derruba consulta, volta em silêncio.

A terceira é para quem pensa em plataforma. A criação por API avisa: “If definition is omitted, the created ontology uses generation 2.” A propriedade generation do item diz qual saiu, e o exemplo de geração 2 usa model.tmdl, database.tmdl e namespaces/default.tmdl — TMDL, o formato do modelo semântico. O artigo de referência do formato não menciona geração nem TMDL. Quem automatiza precisa escolher a geração de propósito: o padrão não é o formato documentado.

Regras e agentes: a ontologia declara, outros executam

Rule é construto de ontologia; action, não. A ontologia declara a regra sobre a entidade — no glossário, algo como “If temperature ≥ 80°F” —, mas quem executa é outro item: “Rules in ontology (preview) rely on Fabric Activator and are subject to Fabric Activator costs.” E mais: “By default, ontology rules are saved to a new Fabric Activator item.” Declarou uma regra no vocabulário, ganhou um terceiro item no workspace, com fatura própria.

Action não tem verbete no glossário nem está entre os conceitos-chave da página de regras: é uma etapa do construtor e o que a regra dispara depois, como “send Teams alert”. A fronteira é limpa: a ontologia declara o que é verdade e o que merece atenção; o Activator executa o que acontece em seguida.

Com agente vale o mesmo. A ontologia não age: serve significado, inclusive como servidor MCP, com um endpoint por item:

https://api.fabric.microsoft.com/v1/mcp/dataPlane/workspaces/<workspace-ID>/items/<ontology-item-ID>/ontologyEndpoint

A página pede capacidade paga F2 ou superior (ou P1 em diante, com Fabric habilitado) e documenta só autenticação interativa: “Select Allow and sign in with your credentials”. Service principal, que a REST API do item aceita, não aparece — nem a lista de ferramentas que o servidor expõe. A ausência é informação: o catálogo se conhece conectando, não lendo.

Boas práticas para produção

• Escreva a cadência antes de ligar. Parta da defasagem que o negócio tolera: com refresh integral, o conceito mais exigente dita o ritmo — e o custo — do grafo inteiro.
• Agrupe mudanças de schema. Cada edição abre janela de modelagem e dispara reingestão completa.
• Monitore o item Graph, não só o de ontologia. No Capacity Metrics, a despesa relevante é Graph general operations, e é na agenda do Graph que se mexe quando a capacidade aperta.
• Versione a definição fora do produto. Puxe com Get Ontology Definition e promova com Update Ontology Definition, sempre o pacote completo, porque a escrita sobrescreve.
• Escolha a geração de propósito. Omitir a definição na criação produz geração 2.
• Prepare a origem antes de modelar. Tabela gerenciada, coluna sem espaço nem caractere especial, chave string ou inteiro.
• Confira o binding depois de gerar, entidade por entidade. Sem acesso público de entrada, o item nasce com sucesso e sem binding.
• Teste propriedade monetária com valor conhecido. Contagem de linhas não prova que o número voltou.
• Trate regra como item de Activator, com dono e orçamento próprios.

O que precisa estar de pé

A ordem abaixo é causal, não cronológica: cada estágio existe porque o anterior ficou de pé.

Fundação — autoridade sobre o vocabulário. Os conceitos têm dono, nome e chave declarados; a definição vive num repositório e é promovida por Update Ontology Definition com identidade de serviço; e as restrições de origem são conhecidas antes do primeiro desenho.

Está de pé quando dá para recriar a ontologia inteira num workspace vazio a partir do repositório, sem ninguém redesenhar nada na tela.

Produção com contexto — o frescor tem dono e preço. A cadência do grafo está declarada e aprovada por quem paga a capacidade; o consumo do item Graph é acompanhado à parte; mudança de schema entra em bloco; e propriedade monetária foi validada com valor, não com contagem.

Está de pé quando a pergunta “esse número é de quando?” tem resposta declarada — e quem quiser encurtá-la sabe quanto custa.

Escala e eficiência — a plataforma vira produto. Conceito novo nasce de um padrão, com convenção de nome, cadência herdada e teste de valor antes da promoção; regras caem num Activator com dono; e a postura de rede do workspace é verificada no pipeline, não na memória de alguém.

Está de pé quando um conceito novo chega à produção sem ninguém precisar lembrar qual workspace tem acesso público de entrada habilitado.

Pular estágio não acelera nada: sem o repositório, a cadência não tem o que governar; sem a cadência, escalar só multiplica a fatura.

Perguntas frequentes (FAQ)

A ontologia do Fabric é RDF ou OWL?

Nenhuma página do conjunto menciona RDF, OWL ou SPARQL — nem para confirmar, nem para negar; a própria FAQ tem só quatro perguntas. É ausência documental, não decisão anunciada. O documentado é definição em JSON — ou TMDL, no exemplo de geração 2 — e consulta em GQL, KQL e linguagem natural.

Dá para versionar a ontologia?

No produto, não: “No, versioning isn’t currently available.” Fora dele, sim: exporte e regrave a definição por API, sabendo que a gravação sobrescreve.

A ontologia em preview já cobra?

Cobra. “Billing for ontology (preview) is in effect”, com lógica e operações faturadas pelo Fabric Graph subjacente. Preview, aqui, qualifica maturidade, não gratuidade.

Conclusão

O que importa não é a ontologia ter ficado bonita na demonstração; é ela ter virado item — REST API, definição em arquivo, identidade de serviço, item filho e medidor — e entrado no território onde vivem deploy, revisão de código e orçamento.

E o preço dessa promoção aparece no lugar menos glamouroso: cada reingestão é integral. Existe agenda; não existe captura de mudança. Quem tratar frescor como configuração vai descobrir a conta no relatório de capacidade. Quem tratar como decisão de arquitetura escolhe a defasagem que o negócio tolera e paga por ela de olhos abertos.

A ontologia guarda o vocabulário. Quem emite a fatura é o grafo — e é para ele que o seu painel de capacidade deveria estar apontado.

Referências oficiais

• O que é ontologia (preview) no Microsoft Fabric — experiência nova
• O que é ontologia (preview) no Microsoft Fabric — experiência antiga
• Visão geral do Fabric IQ
• Detalhes do entity type e refresh do grafo — experiência antiga
• Faturamento e uso de capacidade da ontologia — experiência antiga
• Ligar dados à ontologia — experiência antiga
• Gerar ontologia a partir de modelo semântico — experiência antiga
• Regras na ontologia — experiência antiga
• Servidor MCP da ontologia
• Glossário da ontologia
• Perguntas frequentes da ontologia
• REST API do item de ontologia
• Formato da definição do item de ontologia — experiência antiga
• Graph in Microsoft Fabric — preço e unidades de capacidade

👉 Se você está levando a ontologia do Fabric IQ para produção — especialmente em banco ou seguradora, onde o workspace do lakehouse quase nunca tem acesso público de entrada habilitado e toda propriedade que importa é monetária, dê dono à cadência de refresh antes do primeiro conceito e teste cada binding com valor real.
Quer trocar ideia sobre ontologia, frescor de dado e custo de grafo no Fabric? Me chama no LinkedIn.