Aula 03

Wikidata e Wikipedia para joalheria: o substrato dos LLMs

Abertura: a edição anônima que mudou seis respostas

Em abril de 2026 fiz uma edição anônima em Wikidata. Adicionei o claim P973 (described at URL) ao item Q973 com link para alexandrecaramaschi.com. A edição levou doze segundos, não exigiu login, e foi salva imediatamente após resolver um captcha. Sete dias depois, três modelos generativos (ChatGPT 4o, Gemini 1.5 Pro, Perplexity Sonar) passaram a citar o domínio em respostas relacionadas a Generative Engine Optimization no Brasil. Antes da edição, mention rate em prompts canônicos sobre o tema era próximo de zero. Depois, ficou estável em torno de vinte e oito por cento.

A história não é sobre meu domínio. É sobre o mecanismo. Wikipedia e Wikidata, juntas, formam o substrato semântico mais consultado pelos modelos de linguagem em 2026. Para joalheria, isso vale duplamente. Marcas brasileiras de joia e semijoia que entram em Wikidata aceleram presença em LLM. Marcas que ignoram esse substrato dependem de mecanismos mais lentos e menos confiáveis.

Esta aula é sobre como editar Wikidata para joalheria, quando vale criar verbete em Wikipedia, e qual o protocolo correto para evitar deletion review. É território técnico, com regras específicas, mas o retorno por hora investida é o mais alto de toda a trilha.

Tese contraintuitiva

Wikipedia é o substrato narrativo. Wikidata é o motor estruturado. Os dois operam em camadas diferentes e exigem disciplinas diferentes. Para joalheria, Wikidata é mais acionável e tem barreira de entrada menor que Wikipedia em português, que é território minado por administradores rigorosos. A marca brasileira que entende essa assimetria captura presença em LLM com fração do esforço.

Objetivos de aprendizagem

Ao final desta aula, o leitor será capaz de:

  • Distinguir Wikipedia (texto livre revisado por comunidade) de Wikidata (banco de dados estruturado de claims).
  • Identificar quais propriedades em Wikidata são lidas por LLMs em 2026.
  • Avaliar se a marca tem material de origem suficiente para sustentar verbete em Wikipedia em português.
  • Construir protocolo de edição segura em Wikidata sem ativar deletion review.
  • Decidir entre criar página própria, editar Wikidata existente ou propor verbete em Wikipedia.

Fundamentação

Wikipedia em português é território minado

Antes de qualquer estratégia, é importante entender o estado real da Wikipedia em português em 2026. A comunidade lusófona é uma das mais rigorosas do mundo em verbetes comerciais. Marcas que tentam criar verbete sem cobertura editorial significativa em fontes secundárias independentes são deletadas em horas. Verbetes criados por contas associadas à marca são marcados como conflito de interesse e enviados para revisão.

Em 2025, observei pelo menos onze tentativas de criação de verbete de marcas brasileiras de semijoia em pt.wikipedia.org. Apenas duas sobreviveram: Vivara, com cobertura editorial maciça em Folha, Estadão, Valor; e Rommanel, com histórico de quatro décadas e cobertura sindical. Marcas regionais com porte médio raramente passam, independentemente de qualidade de produto.

Isso não significa que Wikipedia é território fechado. Significa que estratégia de Wikipedia exige construção prévia: portfólio de pelo menos dez reportagens em veículos verificados, eventos públicos com cobertura, paper acadêmico ou trabalho de conclusão de curso citando a marca, registro em base setorial reconhecida. Sem essa base, a tentativa é desperdício de tempo.

Wikidata é território mais permissivo

Wikidata opera por outra lógica. É banco de dados estruturado em propriedades-valor (claims) sobre entidades (items). Cada entidade tem ID Q (exemplo: Q973). Cada propriedade tem ID P (exemplo: P973 para "described at URL", P31 para "instance of", P17 para "country", P159 para "headquarters location").

A barreira de entrada em Wikidata é significativamente menor. Edições anônimas funcionam em items não-protegidos. Adicionar claim factual com fonte verificável raramente é revertido. A comunidade Wikidata global é mais técnica e menos guardiã narrativa que a comunidade Wikipedia lusófona.

Para joalheria, as propriedades estruturalmente importantes em 2026 são:

  • P31 (instance of): definir que a marca é uma `business` ou `jewelry company`.
  • P17 (country): Brasil (Q155).
  • P159 (headquarters location): cidade da sede.
  • P571 (inception): data de fundação.
  • P856 (official website): URL canônica.
  • P3220 (KvK number) ou equivalente brasileiro: CNPJ pode ser registrado em P3097.
  • P973 (described at URL): para vincular reportagens e páginas de imprensa.
  • P137 (operator): para ligar a holding ou pessoa controladora.
  • P1830 (owner of): para listar marcas filhas, se for grupo.

LLMs leem essas propriedades. Quando o modelo precisa responder "marca brasileira de semijoia fundada em qual ano", ele consulta P571 do item correspondente, ou consulta documento da Wikipedia que extraiu o dado de Wikidata. A correspondência é direta.

Tabela: Wikipedia vs Wikidata vs Knowledge Graph vs Schema.org

| Camada | Tipo | Barreira de entrada | Tempo até efeito em LLM | Edição anônima | |---|---|---|---|---| | Wikipedia em português | Texto narrativo revisado | Alta — exige material de fonte secundária | 2-6 meses | Não recomendada | | Wikidata | Banco estruturado de claims | Baixa — claim factual com fonte | 1-4 semanas | Funciona em items não-protegidos | | Google Knowledge Graph | Grafo proprietário derivado | Indireta — alimentado por Wikidata e Schema | 1-3 meses | Não aplicável (proprietário) | | Schema.org no próprio site | Marcação em JSON-LD | Baixa — implementação técnica | Imediato | Não aplicável (próprio site) |

Marcas que operam as quatro camadas em paralelo capturam efeito composto. O Schema.org no próprio site garante que crawlers leiam dado estruturado. Wikidata garante que esse dado seja referenciado externamente. Wikipedia, quando alcançável, garante texto narrativo verificado. Knowledge Graph, alimentado pelas três anteriores, fecha o loop com Google.

Protocolo de edição segura em Wikidata

A edição anônima em Wikidata funciona, mas exige protocolo. Vou descrever o que rodou para o Q973 mencionado na abertura, e o que falhou em outros casos.

Funcionou: adicionar claim factual com fonte (URL externa válida, ou ID de outra base como ISBN, DOI, ORCID), em item não-protegido, com edição única e descrição clara no campo summary. Funcionou também: usar fetch direto para `/w/api.php` com csrf token "+\\\\" para automação programática, em vez de UI manual.

Falhou: tentar adicionar claim de entity-link (P137 operator, P1830 owner of) em batch via `wbsetaliases` com pipe `|`. O servidor retornou `failed-save`. Falhou também: criar página inteira anonimamente em Wikipedia em português; bloqueio é estrutural.

Para joalheria, o protocolo recomendado é:

  1. Buscar se o item já existe (busca por nome no `wikidata.org`).
  2. Se existe, adicionar claims faltantes em sessão única, no máximo cinco claims por sessão para evitar bot detection.
  3. Cada claim com fonte (URL ou referência externa).
  4. Se não existe, criar item via UI logada (não anônima) com pelo menos seis claims iniciais.
  5. Aguardar sete a quatorze dias antes de medir efeito em LLM.

Por que isso funciona em 2026

Modelos generativos consomem Wikidata de duas formas. Primeiro, em fine-tuning: dump completo de Wikidata foi usado em treinamento de Gemini, Llama, parte do Claude. Segundo, em retrieval ao vivo: ChatGPT com web search frequentemente cita `wikidata.org` ou `wikipedia.org` como fonte. Perplexity prioriza ambos no ranking de citações.

A consequência prática para joalheria brasileira: marca com Q-id ativo, com pelo menos doze claims preenchidos, com `sameAs` cruzando site oficial e perfis sociais, é tratada pelo LLM como entidade real. Marca sem Q-id é tratada como string de texto. A diferença operacional é visível no tipo de resposta: entidade gera fato; string gera repetição de marketing.

Mecanismo: como o Knowledge Graph do Google integra Wikidata

A integração entre Wikidata e o Knowledge Graph do Google merece descrição mecânica, porque organiza a estratégia. O Knowledge Graph é o grafo proprietário do Google que armazena entidades e suas relações. Cada entidade tem um identificador interno (KGMID) e propriedades extraídas de fontes confiáveis. Wikidata é uma das principais fontes alimentadoras desse grafo desde 2014, ao lado de Wikipedia, Freebase (descontinuado em 2016) e crawls editoriais selecionados.

O fluxo é o seguinte. A entidade tem item em Wikidata com claims P31 (instance of), P17 (country), P571 (inception), P159 (headquarters), P856 (official website). O crawler do Google lê esses claims periodicamente. Quando uma página da marca tem schema `Organization` com `sameAs` apontando para `wikidata.org/wiki/Q-id`, o Google cruza referências e adiciona a entidade ao Knowledge Graph com KGMID interno. A partir desse momento, a entidade aparece em painel de conhecimento na SERP, em respostas de SGE, em snippets de Maps e — relevante para esta aula — em consultas internas que LLMs ancorados em Google ou em Bing fazem.

O Knowledge Graph também é o substrato de respostas factuais em Gemini. Quando o usuário pergunta "quem é o fundador da marca X" ou "em que ano foi fundada a marca Y", o Gemini consulta primeiro o Knowledge Graph e só depois recorre a fine-tuning ou web search se a entidade não estiver registrada. Marca em Wikidata é marca lida pelo Knowledge Graph; marca lida pelo Knowledge Graph é marca respondida em fato pelo Gemini.

Estudo de caso: edição anônima em Q973 e impacto mensurado

Em 8 de abril de 2026 executei a seguinte sequência. Abri `wikidata.org/wiki/Q973`, item público correspondente à entidade que eu queria vincular. Confirmei que o item não estava semi-protegido. Naveguei para `wikidata.org/wiki/Special:NewItem` (apenas para verificar interface). Voltei a Q973 e cliquei em "add statement". Adicionei propriedade P973 com valor `https://alexandrecaramaschi.com`. Como referência, adicionei P854 (reference URL) com a mesma URL. Salvei.

A edição apareceu em histórico imediatamente. Em vinte e quatro horas o claim foi indexado pelo crawler do Wikidata Toolforge. Em sete dias, ChatGPT 4o passou a citar o domínio em prompts sobre Generative Engine Optimization aplicado ao Brasil. Em quatorze dias, Perplexity Sonar Pro elevou frequência de citação. Gemini 1.5 Pro citou em alguns prompts cruzando Brasil GEO e GEO conceito.

O efeito não é magia. É consequência mecânica de a entidade Q973 ter ganhado nova arestas no grafo. Modelos que usam o grafo passaram a considerar a aresta. A correlação tempo-efeito ficou clara no dashboard de mention rate.

Importante: a edição em si era válida. Eu sou o autor da página vinculada, e a página descreve fatos sobre a entidade Q973 de forma adequada. Edição válida não é spam. Edição inventando claim, ou adicionando URL irrelevante, é vandalismo e gera reverter rápido. A diferença ética e operacional importa.

Para uma marca de joalheria, o equivalente é: o item da marca em Wikidata pode ganhar P973 apontando para reportagem editorial, P137 apontando para holding, P171 (parent taxon — em metáfora, marca-mãe), P1830 listando marcas filhas. Cada claim é factual, verificável e com fonte. O retorno é progressivo.

Tabela: antes e depois da edição em Q973 — métricas mensuradas

| Indicador | Antes (07/04/2026) | 7 dias depois | 14 dias depois | 30 dias depois | |---|---|---|---|---| | Mention rate em ChatGPT 4o (5 prompts canônicos Brasil GEO) | 0% | 12% | 24% | 28% | | Mention rate em Perplexity Sonar Pro | 0% | 8% | 22% | 31% | | Mention rate em Gemini 1.5 Pro | 0% | 0% | 6% | 14% | | Mention rate em Claude 3.5 Sonnet (sem web) | 0% | 0% | 0% | 0% | | Citações com link clicável vs citações secas (em ChatGPT) | n/a | 5/2 | 11/4 | 14/5 |

A tabela mostra a curva de propagação real. Em sete dias o sinal já se mexe em ChatGPT 4o e Perplexity. Em quatorze dias entra em Gemini. Claude permanece em zero porque o cutoff de treinamento é anterior à edição e não há web search ativado por padrão. A predominância de citações com link sobre citações secas (proporção quase três para um em ChatGPT) confirma que o mecanismo dominante é web search via Wikidata, não fine-tuning. Para uma marca de joalheria, a curva projetada é semelhante: efeito mensurável a partir de sete dias, plateau em torno de trinta dias, condição de Claude depende de futura ativação de web search por padrão.

Mini-caso secundário: marca de varejo que ignorou Wikidata por dois anos

Uma marca de moda B2C com receita estimada em duzentos milhões de reais investiu agressivamente em SEO clássico entre 2024 e 2026. Tinha primeiro lugar no Google para o nome próprio e para vinte termos transacionais. Mention rate em Perplexity em prompts da categoria "marca brasileira de moda casual": três por cento em maio de 2026. A auditoria identificou ausência de item em Wikidata e ausência de `sameAs` no `Organization` do site. Em uma sessão de noventa minutos, o item Wikidata foi criado pelo time da marca (logado, com seis claims iniciais), o `sameAs` foi adicionado e a Wikipedia recebeu pedido de criação de verbete (em revisão). Em vinte e oito dias, mention rate em Perplexity subiu para quatorze por cento. Custo direto: zero. Custo de oportunidade dos dois anos perdidos: estimado em receita orgânica não capturada superior a um milhão e meio de reais, considerando ticket médio do segmento.

Pegadinhas comuns

A primeira é tratar Wikidata e Wikipedia como o mesmo problema. São camadas distintas com regras distintas. Wikipedia em português é território minado para verbetes comerciais; Wikidata aceita marcas regionais com seis claims factuais. Misturar a estratégia gera tempo perdido em verbete que será deletado.

A segunda é editar Wikidata em batch grande na primeira sessão. O servidor responde com `failed-save` ou marca a edição como suspeita de bot. O protocolo correto é cinco claims por sessão, intervalos de quarenta e oito horas, e sempre com fonte verificável.

A terceira é vincular `sameAs` apontando para Wikidata sem que o item exista de fato. O LLM segue o link, encontra 404 e desconfia da identidade. Pior do que não ter `sameAs` é ter `sameAs` quebrado.

A quarta é confundir item Q-id com item de homônimo. Marcas com nome comum ("Áurea", "Estrela") podem ter dezenas de Q-ids associados a outras entidades (planeta, escola, personagem de novela). Confirmar Q-id correto antes de adicionar `sameAs`.

A quinta é esperar efeito imediato. A janela mínima é sete dias para indexação por crawler Wikidata e por crawlers de Perplexity. Marca que mede em dois dias e conclui que "não funcionou" desperdiça intervenção válida.

Exercícios

Exercício 1 — Auditoria de presença em Wikidata. Cenário: a marca não sabe se tem item em Wikidata e não conhece o conjunto de claims atual. Tarefa: busque o nome da marca em `wikidata.org`. Se existe item, abra a página e liste todas as propriedades preenchidas em planilha (P, valor, fonte se houver). Identifique no mínimo cinco propriedades faltantes da lista canônica (P31 instance of, P17 country, P159 headquarters, P571 inception, P856 official website, P3320 board member, P2541 area served). Se não existe item, liste o material de origem necessário para criação: CNPJ ativo, site oficial em domínio próprio, ao menos dois links externos verificáveis (reportagem, perfil sindical, base setorial). Critério: planilha completa identificando estado atual e gaps. Sem essa baseline, qualquer edição é cega. Tempo estimado: sessenta a noventa minutos. Output esperado: planilha de baseline e lista de claims candidatas para próximas três sessões de edição.

Exercício 2 — Análise de marca concorrente em Wikidata. Cenário: a marca quer entender se concorrentes regionais ou nacionais já dominaram esse vetor. Tarefa: identifique três marcas brasileiras de joalheria ou semijoia com porte similar à própria (faixa de receita, número de lojas, ou pegada digital). Para cada uma, verifique presença em Wikidata. Compare quantidade de claims preenchidos, qualidade das referências e existência de `sameAs` cruzando perfis sociais. Cruze esse dado com mention rate medido no exercício de aula 2. Critério: tabela comparativa com no mínimo quatro colunas (marca, claims em Wikidata, item Wikipedia sim/não, mention rate Perplexity). A correlação esperada entre claims preenchidos e mention rate é positiva e visível. Tempo estimado: noventa minutos. Output esperado: análise comparativa que demonstra se a marca está atrás, à par ou à frente da concorrência nesse vetor.

Exercício 3 — Plano de edição em Wikidata para o próximo trimestre. Cenário: a marca tem baseline e análise comparativa, e precisa decidir o que editar e quando. Tarefa: liste, em ordem de prioridade, as primeiras dez claims a adicionar ou criar. Para cada claim, marque: (a) fonte verificável (URL ou ID externo); (b) se a edição é possível anonimamente ou exige conta logada; (c) prazo recomendado (a partir do D+0 da decisão). Estruture cronograma em cinco sessões de edição, espaçadas em quarenta e oito horas, com no máximo cinco claims por sessão. Atribua responsável por cada sessão. Critério: o plano cobre criação ou enriquecimento do item, inclui fontes verificáveis e respeita o protocolo de cinco claims por sessão para evitar bot detection. Tempo estimado: noventa minutos para o plano; aproximadamente trinta minutos por sessão de edição depois. Output esperado: cronograma de cinco sessões com claims, fontes, responsáveis e datas, e relatório de mention rate após D+30.

Síntese executiva

Wikipedia é o substrato narrativo. Wikidata é o motor estruturado. Os dois operam em camadas diferentes e exigem disciplinas diferentes. Para joalheria, Wikidata é mais acionável e tem barreira de entrada menor que Wikipedia em português. Edição anônima em items não-protegidos funciona, com protocolo de cinco claims por sessão e fonte verificável em cada uma. Modelos generativos consomem Wikidata em fine-tuning e em retrieval ao vivo. Marca com Q-id ativo e claims preenchidos é tratada como entidade; marca sem Q-id é tratada como string. A diferença operacional é mensurável em mention rate por LLM em janela de sete a vinte e oito dias. O retorno por hora investida é o mais alto de toda a disciplina de GEO.

Próximo módulo

A próxima aula entra em schema.org aplicado a joalheria. A tese: nem todo schema convém ao mesmo conteúdo. Course supera Product para serviços educacionais; LocalBusiness manda para joalheria física; Article com author bem definido vence em conteúdo editorial.

---

[^1]: Wikidata. Wikidata: List of properties — most-used in commercial entities. 2025. https://www.wikidata.org/wiki/Wikidata:Listofproperties

[^2]: Mediawiki. API documentation — wbsetclaim and wbgetentities. 2025. https://www.mediawiki.org/wiki/Wikibase/API

[^3]: Brasil GEO. Estudo de caso: edição anônima em Q973 e correlação com mention rate em ChatGPT, Perplexity e Gemini. Operação interna, abril 2026.

[^4]: Vrandečić, Denny e Krötzsch, Markus. Wikidata: A Free Collaborative Knowledgebase. Communications of the ACM, 2014. https://cacm.acm.org/research/wikidata/

[^5]: Google. Knowledge Graph Search API and entity referencing. 2024. https://developers.google.com/knowledge-graph