Omar scrive sul suo sito, Francesca sul suo, io sul mio. Lavoriamo nella stessa organizzazione, ma raccontiamo cose diverse. Anche quando il tema si incrocia, cambia il pezzo che ciascuno vede e decide di approfondire.
Poi, sotto le pagine, ci sono informazioni che tornano: chi siamo, come siamo collegati ad Advertaria, quali indirizzi identificano le persone e l’organizzazione.
Quelle informazioni devono convivere con siti che continuano a cambiare per conto proprio. È il pezzo su cui sto lavorando: costruire un contesto comune che si possa usare senza portarsi dietro tutto il resto.
La stessa persona, descritta da posti diversi
Omar parla di autori riconoscibili nella sua guida alla GEO. Francesca riprende il tema nel suo articolo su GEO e AEO, collegandolo a informazioni chiare su chi scrive e sull’attività.
Da lì viene una domanda tecnica: se più siti descrivono la stessa persona o la stessa azienda, come facciamo a mantenere coerenti i riferimenti?
Potrei ricopiare i dati in ogni sito. All’inizio funziona. Poi cambia un indirizzo, si aggiunge un profilo, una copia viene aggiornata e un’altra resta com’era. Per capire quale usare devo ricostruire la storia di tutte le copie.
Ho impostato un registro comune delle persone e dell’organizzazione. Contiene nomi, indirizzi, identificativi, ruoli nel network e relazioni. I siti possono usare quei riferimenti quando descrivono qualcosa che condividono.
Per esempio, quando il sito di Omar e quello di Francesca parlano di Advertaria nei dati strutturati, usano lo stesso identificativo dell’organizzazione. La descrizione completa dell’azienda resta sul sito dell’azienda.
I dati strutturati servono a rendere esplicito il significato delle informazioni nella pagina. In questo lavoro mi interessa che i collegamenti descrivano fatti veri, con riferimenti che riesco a mantenere.
Il registro arriva al sito attraverso un passaggio di codice
Il registro è un file JSON. Uno script lo legge e genera un file PHP nei repository dei siti collegati. Nel passaggio lascia fuori le note interne; ciascun sito legge i dati generati e costruisce i nodi schema.org che gli servono.
Lo script è già presente e le funzioni locali dei siti di Omar e Francesca usano quel file per descrivere l’organizzazione e i suoi fondatori. La pubblicazione resta un passaggio separato: generare un file sul computer non aggiorna il sito online.
Anche l’integrazione è parziale. Il mio sito usa già alcuni identificativi comuni, ma non è ancora una destinazione del generatore. Alcune informazioni personali restano nelle configurazioni dei singoli siti.
Insomma, c’è una struttura con cui lavorare. C’è anche lavoro da fare per portare i pezzi dentro quella struttura.
Condividere un riferimento lascia spazio a racconti diversi
Il ruolo di una persona nell’organizzazione e il modo in cui si presenta sul proprio sito rispondono a domande diverse. Il registro conserva il primo; la pagina personale può raccontare competenze, interessi e lavoro con parole proprie.
Lo stesso vale per i collegamenti. In schema.org, sameAs serve a indicare pagine che identificano la stessa entità: per esempio, il sito di una persona e un suo profilo ufficiale. Per esprimere il rapporto con un’organizzazione serve una relazione appropriata.
E citare un articolo è un altro collegamento ancora. Qui rimando a Omar e Francesca perché i loro testi sono il punto da cui prosegue questo ragionamento. Il lettore deve poter seguire quel passaggio e trovare qualcosa che gli serve.
Sul sito lavorano anche gli altri
Il registro risolve solo una parte del problema. Omar e Francesca lavorano sui propri siti anche con i loro agenti, mentre io seguo alcune parti comuni.
Abbiamo quindi documentato quali file appartengono al lavoro del network, quali sono condivisi e quali restano alla gestione di ciascuno. Ci sono istruzioni per orientarsi e uno spazio in cui lasciare traccia delle modifiche.
Per i caricamenti la regola comune è controllare la versione presente sul server prima di sostituirla. Una copia locale può essere perfettamente funzionante e avere perso una modifica pubblicata da qualcun altro. Il controllo serve a intercettare quella differenza mentre siamo ancora in tempo a unire il lavoro.
Qui il codice e le istruzioni cominciano a dipendere l’uno dalle altre. Se cambio il meccanismo ma lascio una descrizione vecchia, il prossimo operatore può seguire con precisione una regola che non descrive più il sito.
Nella ricognizione per questo articolo ho trovato proprio questo: riferimenti già presenti nel codice e note che li descrivono ancora come un passaggio futuro. Anche il contesto comune ha bisogno di manutenzione.
È la parte che voglio far evolvere insieme agli strumenti: far arrivare a chi lavora sul sito le informazioni che gli servono, aggiornate abbastanza da poterci fare affidamento. Poi lasciare che Omar, Francesca e io continuiamo a raccontare cose diverse.