Segnali di entità: costruire un'identità verificabile senza Wikidata

Il punto di partenza: perché Wikidata non è la risposta per tutti

Quando si parla di identità semantica e di entity linking, Wikidata viene citata spesso come soluzione. È comprensibile: è il knowledge graph più grande e aperto del web, usato da Google, dai principali sistemi AI e da decine di motori di ricerca come fonte di fatti verificabili. Avere una voce lì significa essere un nodo nel grafo che le macchine consultano.

Il problema è che Wikidata richiede notabilità. Non è un requisito formale arbitrario ma una scelta editoriale precisa: le voci devono descrivere entità che abbiano ricevuto copertura significativa da fonti indipendenti. Un avvocato con vent'anni di esperienza, un consulente affermato nel suo settore, un'associazione di promozione sociale con progetti finanziati dall'Unione Europea: nessuno di questi supera automaticamente quella soglia. Una voce creata senza i requisiti viene rimossa. L'effetto è controproducente, e in alcuni casi lascia una traccia negativa.

Eppure il problema da risolvere è reale e indipendente da Wikidata: come fa un sistema AI a riconoscere chi sei, a separarti dai tuoi omonimi, a citarti con accuratezza? La risposta non passa necessariamente da un knowledge graph pubblico. Passa dai segnali che controlli direttamente.

Cosa fa un segnale di entità

Un segnale di entità è qualsiasi dato strutturato che aiuta un sistema AI a risolvere l'entity linking su di te o sulla tua organizzazione. Non è un testo descrittivo, non è una bio, non è un profilo social: è un dato in una forma che una macchina può leggere senza dover interpretare.

La distinzione è fondamentale. Un testo che dice "Mario Rossi è un avvocato specializzato in diritto del lavoro a Milano" è utile per un lettore umano ma ambiguo per un modello: quanti Mario Rossi avvocati ci sono? Da dove vengono queste informazioni? Sono verificabili? Un segnale di entità risolve quella ambiguità collegando il nome a riferimenti univoci, dichiarando le proprietà in un formato che non richiede interpretazione, e ancorando le affermazioni a fonti che reggono al controllo.

La logica è la stessa dell'entity linking: il modello ha bisogno che la risposta corretta sia quella più facile da trovare. I segnali sono le coordinate che rendono la risposta corretta più facile di qualunque altra.

Il markup sul sito: JSON-LD e Schema.org

Il punto di controllo più diretto è il proprio sito web. Ogni pagina può contenere markup strutturato in JSON-LD, il formato raccomandato da Google e adottato dai principali sistemi AI per leggere metadati senza doverli estrarre dal testo della pagina.

Schema.org fornisce il vocabolario: un insieme di tipi e proprietà riconosciuti che danno nome alle entità e alle loro caratteristiche. Il tipo Person descrive una persona fisica, con proprietà come name, jobTitle, worksFor, knowsAbout, sameAs. Il tipo Organization descrive un ente, con name, description, foundingDate, areaServed, sameAs. Entrambi i tipi supportano identifier, che ospita riferimenti univoci verificabili.

Il markup è invisibile al visitatore umano: vive in un blocco <script type="application/ld+json"> nell'head della pagina. Ma per un sistema AI è l'informazione più affidabile della pagina, perché è stata dichiarata esplicitamente dal proprietario del sito, non estratta da un testo ambiguo.

Le proprietà che disambiguano davvero

Non tutte le proprietà Schema.org hanno lo stesso peso per la disambiguazione. Alcune sono descrittive e aiutano a costruire il profilo; altre sono strutturalmente decisive perché individuano un'entità unica.

La proprietà sameAs è la più importante. Dichiara che l'entità descritta nel markup è la stessa che compare su un profilo o una pagina esterna. Collegare l'entità al proprio profilo LinkedIn, al proprio GitHub, al proprio sito istituzionale trasforma quei profili da pagine separate in conferme dello stesso nodo. Ogni sameAs aggiunto è un filo che connette fonti diverse a un'unica identità verificabile.

La proprietà identifier ospita codici univoci di settore: il codice ORCID per i ricercatori e gli autori, il codice fiscale o la partita IVA per i professionisti e le aziende italiane, il codice LEI per gli enti finanziari. Questi identificatori non sono nomi che si condividono con altri: sono numeri assegnati una volta sola a una sola entità. Per un sistema AI sono l'equivalente di un documento di identità.

Le proprietà worksFor, affiliation e alumniOf collegano l'entità ad altre entità già note. Se l'organizzazione a cui sei affiliato ha una voce su Wikidata, collegarsi a quella voce trasferisce parte dell'ancoraggio. Non sei nel knowledge graph come nodo autonomo, ma sei agganciato a nodi che ci sono già.

La proprietà knowsAbout, compilata con riferimenti a termini definiti, qualifica le competenze in modo verificabile invece di affidarsi a parole chiave. La differenza tra dire "si occupa di entity linking" e collegare il termine alla sua voce Wikidata è che nel secondo caso il modello sa esattamente di cosa si sta parlando.

I profili ufficiali come ancoraggi

I profili su piattaforme riconosciute, dichiarati come sameAs nel markup, diventano ancoraggi dell'identità semantica. Non perché le piattaforme siano knowledge graph, ma perché sono fonti che i sistemi AI già indicizzano e a cui danno peso, e perché la dichiarazione esplicita del collegamento riduce l'ambiguità.

LinkedIn è il più rilevante per i professionisti: è la fonte che i modelli consultano più spesso per dati professionali aggiornati. Un profilo LinkedIn ben strutturato, collegato al proprio sito con sameAs, funziona come conferma bidirezionale: il sito dichiara che quel profilo è lo stesso nodo, e il profilo descrive il nodo con dati che il modello può leggere.

GitHub ha un valore simile per chi lavora in ambito tecnico o di ricerca: è una fonte verificabile di contributi e progetti, con una storia tracciabile. Per le organizzazioni, i profili su Charity Navigator, sul Registro Unico del Terzo Settore, sui portali istituzionali dell'Unione Europea svolgono la stessa funzione: sono riferimenti esterni autorevoli che confermano l'esistenza e le caratteristiche dell'entità.

Il principio è la ridondanza verificabile: più fonti indipendenti descrivono la stessa entità con dati coerenti, più diventa difficile per un modello confonderla con un'altra o inventare dettagli. Ogni profilo dichiarato è un vincolo che limita lo spazio di errore.

llms.txt: istruire direttamente i modelli

Esiste uno strumento più recente e meno noto che affronta il problema da una direzione diversa: il file llms.txt. Non è uno standard W3C né un vocabolario formale. È una convenzione che sta emergendo nella comunità del web semantico, analoga al robots.txt ma pensata per i modelli linguistici invece che per i crawler.

Un file llms.txt è un documento di testo posizionato alla radice del sito, in forma leggibile sia dalle macchine che dagli umani, che dichiara chi è il proprietario del sito, cosa fa, quali pagine contengono informazioni rilevanti e come le informazioni devono essere usate. Non ha la struttura formale del JSON-LD, ma ha il vantaggio di essere diretto: istruisce il modello in linguaggio naturale controllato, con un'autorevolezza che deriva dall'essere ospitato sul dominio stesso.

Il suo valore non è sostituire il markup strutturato ma integrarlo. Il JSON-LD parla al parser di un sistema AI; il llms.txt parla al modello nel momento in cui indicizza o consulta il sito. Usati insieme, coprono livelli diversi dello stesso problema: la leggibilità formale e la comprensione contestuale.

Il Solid Pod: la frontiera della sovranità del dato

C'è un livello ulteriore, ancora poco diffuso ma coerente con la direzione del web semantico: il Solid Pod. Il Protocollo Solid, sviluppato da Tim Berners-Lee, permette di archiviare i propri dati in un contenitore personale controllato dall'individuo, con accesso granulare gestito dal proprietario e non dalla piattaforma che ospita i dati.

Un Solid Pod non è un profilo social e non è un sito web nel senso tradizionale: è un punto di archiviazione di dati strutturati in RDF, accessibili secondo le regole che il proprietario stabilisce. Collegare il proprio Solid Pod all'entità descritta nel markup del sito è una dichiarazione di sovranità del dato: dice al modello dove trovare informazioni aggiornate e verificabili sotto il controllo diretto di chi le riguardano.

Siamo lontani da un'adozione diffusa, e non è realistico proporre il Solid Pod come primo passo a chi sta appena iniziando a costruire la propria identità semantica. Ma vale la pena nominarlo perché indica la direzione: meno dipendenza da intermediari, più controllo diretto sulla rappresentazione della propria entità nel web che le macchine leggono.

L'errore di trattarlo come un problema tecnico

A questo punto la tentazione è affidarsi a uno strumento automatico. Esistono plugin, generatori e script che producono markup JSON-LD in pochi secondi: si compilano alcuni campi, si copia il codice nella pagina, fatto. Il markup è formalmente valido, lo strumento ha funzionato.

Ma un generatore non sa quale dei tuoi omonimi sei tu. Non sceglie quali delle tue affiliazioni disambiguano davvero la tua identità. Non trova i profili autorevoli che vale la pena dichiarare come sameAs. Non decide quali competenze collegare a termini verificabili e quali lasciare come testo libero. Non conosce il tuo percorso professionale abbastanza da capire cosa va detto e cosa può essere omesso.

Questi sono giudizi, non operazioni meccaniche. Il markup è il risultato di un'analisi: cosa distingue questa entità dalle altre che portano lo stesso nome? Quali prove esistono che reggano al controllo? Dove si trovano le fonti autorevoli che confermano chi sei? La sintassi JSON-LD è l'ultimo passo, non il primo.

Come verificare che funzioni

Il test più diretto è anche quello più utile come punto di partenza. Prima di intervenire, si chiede ai principali sistemi AI — ChatGPT, Gemini, Perplexity — chi sei, cosa fai, quali sono i tuoi lavori o i tuoi progetti principali. Si annotano le risposte: cosa è corretto, cosa è mancante, cosa viene inventato, cosa appartiene a un omonimo.

Quella fotografia serve come baseline. Dopo aver costruito i segnali, si ripetono le stesse domande. Il confronto è verificabile: il modello riesce ora a separarti dai tuoi omonimi? I dati citati sono quelli dichiarati nel markup? Le affiliazioni sono corrette? Sei comparso in risposte dove prima venivi ignorato?

C'è anche un controllo tecnico immediato: il validator di Schema.org permette di verificare che il markup sia formalmente corretto e che le proprietà siano riconosciute. È un controllo necessario ma non sufficiente: un markup valido non garantisce che le scelte di contenuto siano quelle giuste per disambiguare questa specifica entità.

Non è più contenuto: è struttura diversa

Vale la pena chiarire cosa questo lavoro non richiede. Non richiede di scrivere più testi, di pubblicare più articoli, di essere più presenti sui social. Non richiede di costruire un sito più ricco o un profilo più dettagliato nel senso narrativo del termine.

Richiede di prendere ciò che già esiste, le affiliazioni, le competenze, i progetti, i risultati, e di renderlo verificabile. Di passare da una forma che un umano può leggere a una forma che una macchina può usare per prendere decisioni. È una trasformazione di struttura, non di volume.

Chi ha già una presenza digitale consolidata ha spesso più materiale verificabile di quanto pensi. Il problema non è la mancanza di dati, è che quei dati esistono in formati che i sistemi AI non riescono a usare con precisione. Costruire i segnali di entità è il lavoro di colmare quella distanza.

Da dove si parte

Il primo passo è la fotografia di partenza: chiedi ai principali sistemi AI chi sei oggi, e annota cosa descrivono con precisione, cosa inventano e dove ti confondono con un omonimo. Da quella risposta si capisce dove il processo di entity linking sta fallendo e quali segnali mancano.

Il secondo passo è l'inventario: quali prove verificabili esistono già? Quali affiliazioni sono documentate su fonti autorevoli? Quali identificatori univoci ti riguardano? Quali profili ufficiali già controlli e sono coerenti tra loro? Quello che si trova in questa fase è la materia prima dei segnali.

Il terzo passo è la struttura: tradurre quell'inventario in markup JSON-LD sul sito, in dichiarazioni sameAs coerenti tra le piattaforme, in un llms.txt che descriva l'entità in modo controllato. Ognuno di questi è un segnale in più che rende la risposta corretta più facile da trovare per qualunque sistema che cerchi di risolvere l'entity linking su di te.

Lavoro con professionisti, PMI e organizzazioni a impatto per costruire questo tipo di presenza: strutturata, verificabile, leggibile dai sistemi AI che stanno diventando il primo punto di contatto tra chi cerca e chi esiste.