Tradotto dall’originale in inglese di Jeni Tennison (@jeniT) da Michele Barbera (@barbz79it) per Linkedopendata.it, revisione a cura di Francesca Di Donato (@ederinita).
In questo post su schema.org discuterò gli incentivi economici che influiscono sul modo in cui i motori di ricerca usano i metadati strutturati presenti sul web. Analizzerò come le funzionalità e le scelte tecniche proposte da schema.org possano creare dei problemi nel lungo periodo e parlerò del ruolo che gli standard aperti possono avere nell’evitare alle aziende responsabili di cadere nelle trappole del monopolio.
Due cose prima di entrare nel vivo della questione. La prima è il tipico avvertimento in cui preciso che queste sono mie personali opinioni. La seconda è che vi consiglio di leggere l’articolo di Rufus Pollock “Is Google the Next Microsoft? Competition, Welfare and Regulation in Internet Search“, in cui Pollock dimostra che il settore dei motori di ricerca tende naturalmente verso il monopolio a causa della particolare struttura di incentivi propria del settore. Pollock dimostra anche che tali monopoli tenderanno a essere sub-ottimali in termini di benefici pubblici. In altre parole, se sei un monopolista nel campo dei motori di ricerca, devi prendere provvedimenti per “non essere evil” (cfr “to not be evil“) poiché tutte le forze di mercato ti spingono in quella direzione.
E’ evidente che schema.org rappresenta una mossa significativa su diversi fronti del parte del monopolista attuale, Google, e malgrado io non pretenda di essere a conoscenza di alcuna informazione particolare, trovo divertente riflettere su come schema.org possa rientrare nella sua strategia generale, sulla misura in cui Google stia evitando le trappole del monopolio e su cosa questo possa significare per il Web nel suo insieme.
I motori di ricerca rispondono alle esigenze dei loro clienti: gli inserzionisti pubblicitari. Perchè allora sono interessati ai metadati strutturati? I metadati strutturati hanno almeno tre effetti positivi sui motori di ricerca:
- offrire informazione più ricca accresce l’utilità dei motori per gli utenti, questo attrae più utenti (più utenti => maggiore attenzione => più soldi dagli inserzionisti)
- offrire informazione più ricca trattiene gli utenti più a lungo sul sito, dato che i motori possono mostrare informazioni rilevanti direttamente piuttosto che forzare gli utenti ad andare a cercare questa informazione al di fuori (più tempo sul sito => maggiore attenzione dei singoli utenti => più soldi dagli inserzionisti)
- analizzare i metadati sociali estratti dalle pagine web, come i social graphs e gli interessi individuali, può aiutare la pubblicità mirata su particolari utenti (più pubblicità mirata => più pubblicità effettiva => più soldi dagli insersionisti)
E’ evidente che per i motori di ricerca i metadati strutturati presentano ampie potenzialità. Il problema dei motori consiste nello spingere gli utenti (ndt: editori di siti web) a pubblicare metadati strutturati assicurandosi che non mentano, che non rappresenti un lavoro eccessivo e che non facciano troppi errori, perché questo produce metaspazzatura.
Quindi gli incentivi per i motori di ricerca spingono nella direzione di rendere più semplice possibile agli editori l’inserimento di metadati nelle pagine web. Nell’interesse dei motori c’è anche il fatto che l’informazione che estraggono sia il più possibile basata sul contenuto visibile della pagina, dato che questo riduce l’opportunità degli utenti di mentire (o di fare errori) immettendo un valore nei metadati e un valore diverso nei contenuti della pagina. Ed è anche nel loro interesse correggere gli errori fatti dagli editori.
La trappola consiste nel fatto che perseguire ciecamente questi interessi può far emergere comportamenti anti competitivi.
Innalzare barriere all’entrata
La sezione Conformance della pagina Data Model recita (enfasi mia):
“Benché speriamo che tutto il markup che indicizzeremo sia conforme allo schema, nella pratica ci aspettiamo che una gran quantità di dati non lo siano. Ci aspettiamo che le proprietà di schema.org vengano utilizzate con nuovi tipi. Ci aspettiamo anche che spesso, al posto di un valore di proprietà di tipo Persona, Luogo, Organizzazione o qualche altra sottoclasse di Risorsa, troveremo un valore di tipo Stringa.
Nello spirito di “un po’ di semantica è meglio che niente”, accetteremo questo tipo di markup e faremo il nostro meglio per processarlo.”
Schema.org contiene diversi esempi di proprietà il cui valore dovrebbe essere interpretato come istanza di un dato tipo come date, ore, numeri, durate e altre micro-sintassi specializzate come la proprietà openingHours degli oggetti EventVenue (ndt: orari di apertura di un luogo dove si svolge un evento) oppure la proprietà interactionCount di un oggetto Articolo che (dagli esempi, ma non dalle specifiche) dovrebbe essere valorizzata con una sintassi simile a "UserTweets:65".
Tutto questo sembra abbastanza chiaro.
Tuttavia, osservando gli esempi con maggior attenzione, anche escludendo la possibilità di inserire una stringa quando lo schema prescrive un oggetto, sembra che ci sia una varietà di modi in cui è possibile esprimere il valore di una proprietà in schema.org. Ci sono esempi dove i numeri contengono virgole o sono preceduti da simboli di valuta. Le distanze sono numeri seguiti da un’ “unità di misura” senza alcuna indicazione di quali siano le unità di misura accettabili. Il contenuto di grassi (FatContent) sembra seguire un qualche tipo di sintassi che contiene un numero e una misura ma anche altre parti testuali. Anche quando i valori devono aderire a una particolare microsintassi, ci sono esempi non-standard (come le P iniziali mancanti negli intervalli temporali).
In altre parole, non c’è documentazione su come i valori delle proprietà schema.org verranno interpretati dai motori di ricerca e traspare una chiara intenzione, da parte dei motori di ricerca, di essere permissivi nel decidere cosa accettare, come se si volesse permettere agli editori di essere pigri mentre i motori massimizzano la quantità di dati che sono in grado di interpretare. La mancanza di una specifica che descriva come i valori vengono interpretati, fa sì che il solo modo per gli editori, per i validatori e per gli sviluppatori di strumenti, di comprendere come effettivamente i motori interpretino i dati, sia quello di fare esperimenti, osservare cosa succede e cercare di individuare dei pattern che tendono ad essere processati nello stesso modo dai maggiori motori di ricerca. O più probabilmente di cercare di capire come si comporterà Google (perchè perdere tempo con tutti gli altri?).
Una cosa molto simile è già successa in passato, con l’HTML prima del WHATWG. A quel tempo IE (ndt: Internet Explorer), che dominava il mercato dei browser, tendeva ad essere lasco nel decidere cosa accettare e cosa rifiutare e non c’erano chiare specifiche che descrivessero i dettagli relativi delle procedure di gestione degli errori, che dovevano essere ricostruite, un bug alla volta, dai browser compatibili. Gli strumenti WHATWG erano costretti a fare un duro lavoro di reverse engineering per decodificare delle specifiche che offrissero un certo grado di consistenza e prevedibilità per gli editori e che rendessero possibile riprodurre i comportamenti dei browser esistenti agli sviluppatori di strumenti e ai nuovi entranti nel mercato dei browser (come Google Chrome). Questo lavoro ha pagato: negli ultimi anni le quote di mercato dei browser si sono diversificate, sopratutto grazie all’ingresso sul mercato di browser mobile, e a causa dell’erosione di quote di mercato da parte di Chrome nei confronti di IE.
Nel campo dei metadati strutturati, Google si trova in una posizione dominante. Nella pratica sarà difficile che Google riveli i sistemi grazie ai quali è capace di estrarre metadati significativi dalla enorme varietà di contenuti testuali presenti sul web: Google ha diversi brevetti che proteggono alcuni casi e in altri casi (specialmente quelli nei quali l’interpretazione dipende dall’analisi del suo vasto indice di pagine web, come nel caso della traduzione del linguaggio naturale) il sistema potrebbe semplicemente non essere replicabile da terze parti.
Nessuno di questi strumenti, tra l’altro, si gioverebbe dall’utilizzare una sintassi diversa per esprimere metadati all’interno delle pagine. L’unica risposta possibile è quindi: maggior chiarezza, più dettaglio e criteri di conformità più precisi nelle specifiche del vocabolario schema.org.
Senza tale specificità, ci ritroveremmo in un mondo nel quale Bing, Facebook e tutti gli altri motori sarebbero costretti a spendere molto tempo e ingenti risorse nel cercare di fare reverse engineering delle strategie di Google per estrarre gli stessi dati. In alcuni casi essi potrebbero anche introdurre alcuni utili dettagli di interpretazione, ma è poco probabile, dato che i loro sforzi saranno concentrati nel replicare Google. Questo costituirebbe una gigantesca barriera all’entrata (come se non fosse già abbastanza grande) per eventuali nuovi motori di ricerca. Più genericamente, la mancanza di dettagli nelle specifiche pone un freno all’innovazione in questo settore.
E ovviamente editori, autori e sviluppatori di strumenti non potrebbero fare altro che arrancare nell’inseguimento.
Correggere la sintassi
Malgrado sia Google sia Yahoo! abbiano già utilizzato in passato metadati descritti con microformats e RDFa per fornire funzionalità simili, in schema.org essi tendono a deprecare il supporto a questi formati, sia utilizzando sempre microdata negli esempi, sia dichiarando esplicitamente:
“Se hai già del markup e questo viene attualmente utilizzato da Google, Microsoft o Yahoo!, il formato di markup continuerà ad essere supportato. Passare al nuovo formato di markup potrebbe essere utile in futuro perché avrai adottato un nuovo standard che è accettato da tutte e tre le aziende, ma non sei costretto a farlo.”
Qualunque tecnologia essi scelgano, il fatto che siano i monopolisti dei motori di ricerca a fare questa scelta – e la conseguente ampia adozione su scala globale attraverso il SEO (ndt: Search Engine Optimization, ottimizzazione delle pagine web per l’indicizzazione da parte dei motori di ricerca) – crea una grande barriera al cambiamento della tecnologia. Anche se le specifiche tecnologiche dovessero cambiare, i cambiamenti verrebbero probabilmente ignorati nella pratica, poiché Google (e quindi anche gli altri motori) cerca di mantenere la retro-compatibilità con gli esempi e le istruzioni pubblicate su schema.org così come sono visibili oggi.
Particolarmente dannosa è la scelta di utilizzare microdata, che è una tecnologia relativamente recente che ha appena raggiunto lo status di Last Call Working Draft nel W3C. Nella mia esperienza, il passaggio a Last Call è di solito il primo momento in cui una comunità più ampia di quella dei gruppi di lavoro comincia a valutare seriamente una tecnologia. Per creare una tecnologia e specifiche migliori, i gruppi di lavoro devono poi essere in grado di operare cambiamenti sulla base di questa valutazione.
Il risultato ultimo è di nuovo la standardisation-by-implementation (ndt: standardizzazione mediante implementazione) che nel lungo periodo ha la conseguenza negativa di limitare la competizione (non tra le tecnologie, ma tra le aziende che utilizzano quelle tecnologie) e conduce verso una situazione in cui potremmo ritrovarci a utilizzare qualcosa che è sub-ottimale per qualsiasi scopo che sia al di fuori degli obiettivi del monopolista.
Enti di standardizzazione
Lo sviluppo di schema.org può apparire come un fatto marginale, di esclusivo interesse di coloro che si occupano di SEO e metadati strutturati, ma in realtà è parte di un disegno più ampio che tocca anche gli effetti dirompenti che gli attori dominanti su internet possono scatenare. E’ praticamente impossibile per un monopolista non fare del male, non perché cerchi attivamente di farlo, ma semplicemente perché è così grande e influente che i suoi comportamenti sono molto più significativi di quelli di qualsiasi altro.
Il tipo di effetti descritti in precedenza – quelli che portano a un risultato sub-ottimale per la società nel suo insieme – sono esattamente il motivo per cui esistono regole di antitrust che controllano cartelli e monopoli. Prima o poi, come è avvenuto con Microsoft, la società esercita una forza regolativa? Ci sono già rumori di questa tempesta in arrivo.
Per lo stesso motivo esistono enti di standardizzazione come il W3C o l’IETF, che offrono politiche brevettuali royalty-free e processi ben definiti per sviluppare standard e specifiche. Può sembrare noioso aderire a tali procedure, e le aziende possono pensare che sia vantaggioso formare delle piccole cricche per fare le cose in maniera più rapida, senza essere costrette a ottenere un consenso più ampio, ma in una prospettiva più vasta gli standard aperti sviluppati all’interno di enti di standardizzazione proteggono le aziende da azioni di antitrust. Le aziende possono far leva su standard royalty-free sviluppati attraverso un processo equo e ben definito come prova che il loro agire è benevolo, e che ne dimostri una più ampia visione di responsabilità verso la società considerata nell’insieme.
Come avrebbe potuto dire Winston Churchill:
In questo mondo di peccati e dolore sono state tentate molte strade per sviluppare standard, e altre ancora ne verranno tentate. Nessuno pretende che gli enti di standardizzazione siano perfetti o totalmente saggi, ed è stato detto che sviluppare standard all’interno degli enti sia il peggior modo possibile al di fuori di tutti gli altri modi che sono stati sperimentati.
Le obiezioni a schema.org possono sembrare quelle della volpe e l’uva (ndt: L’espressione originale e’ sour grapes: uva acerba. La frase deriva dalla favola di Esopo “La volpe e l’uva”, e si riferisce al fare finta di non provare interesse per qualcosa che non si ha o non si può avere) perché non propongono l’uso di un particolare vocabolario o sintassi, ma guardano più in profondità e i problemi che schema.org solleva riguardano tutti le responsabilità dei monopoli e il ruolo degli open standard. Il parallelo con HTML, IE e microsoft fa impressione; sarà interessante vedere se le cose finiranno allo stesso modo.
