{"id":862,"date":"2019-01-14T14:38:15","date_gmt":"2019-01-14T13:38:15","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/conversare-con-robot-voce-smart-agent-contenuti-strutturati\/"},"modified":"2019-01-14T14:38:15","modified_gmt":"2019-01-14T13:38:15","slug":"conversare-con-robot-voce-smart-agent-contenuti-strutturati","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/conversare-con-robot-voce-smart-agent-contenuti-strutturati\/","title":{"rendered":"Conversazioni con i robot: voce, smart agent e contenuti strutturati"},"content":{"rendered":"

Alla fine del 2016, Gartner ha previsto<\/a> che il 30% delle sessioni di navigazione web sarebbero state senza uno schermo entro il 2020. Sempre nello stesso anno ma precedentemente, Comscore aveva predetto<\/a> che entro il 2020 tutte le ricerche saranno ricerche vocali. Sebbene ci siano delle prove recenti<\/a> che suggeriscono che il quadro del 2020 possa essere pi\u00f9 complicato di quanto implicato da queste proiezioni a grandi linee, stiamo gi\u00e0 vedendo l’impatto che hanno le ricerche vocali, l’intelligenza artificiale e gli smart software agent come Alexa e Google Assistant sul modo vengono trovate e consumate le informazioni sul web.<\/p>\n

Oltre alla funzione di indicizzazione svolta dai motori di ricerca tradizionali, gli agenti intelligenti e gli algoritmi di ricerca basati su AI stanno ora introducendo nel mainstream due ulteriori modalit\u00e0 di accesso alle informazioni: aggregazione e inferenza. Di conseguenza, gli sforzi di progettazione che si concentrano sulla creazione di pagine visivamente efficaci non sono pi\u00f9 sufficienti per garantire l’integrit\u00e0 o l’accuratezza dei contenuti pubblicati sul web. Piuttosto, concentrandosi sulla fornitura dell’accesso alle informazioni in modo strutturato e sistematico, leggibile sia dagli uomini che dalle macchine, gli editori di contenuti possono garantire che il loro contenuto sia accessibile e accurato in questi nuovi contesti, indipendentemente dal fatto che stiano producendo chatbot o sfruttando direttamente l’intelligenza artificiale. In questo articolo, esamineremo le forme e l’impatto dei contenuti strutturati e chiuderemo con una serie di risorse che possono aiutarvi a partire con un approccio strutturato alla progettazione delle informazioni.<\/p>\n

\n

Il ruolo del contenuto strutturato<\/h2>\n

Nel loro recente libro, Designing Connected Content<\/cite><\/a>, Carrie Hane e Mike Atherton definiscono il contenuto strutturato come contenuto che \u00e8 \u201cpianificato, sviluppato e connesso al di fuori di un’interfaccia, cos\u00ec da essere pronto per qualsiasi interfaccia\u201d. Un approccio di progettazione del contenuto strutturato inquadra le risorse di contenuto, come articoli, ricette, descrizioni dei prodotti, how-to, profili, etc., non come pagine da trovare e leggere, ma come pacchetti composti da piccoli pezzi di dati di contenuto che si riferiscono tutti gli uni agli altri in modi significativi.<\/p>\n

In un processo di progettazione del contenuto strutturato, le relazioni tra i blocchi di contenuto sono definite e descritte in modo esplicito. Questo rende i blocchi di contenuto e le relazioni tra loro comprensibili dagli algoritmi. Gli algoritmi possono quindi interpretare un pacchetto di contenuto come la “pagina” che sto cercando, o remixare e adattare lo stesso contenuto per darmi un elenco di istruzioni, il numero di stelle su una recensione, la quantit\u00e0 di tempo rimasto fino alla chiusura di un ufficio e qualsiasi numero di altre risposte concise a domande specifiche.<\/p>\n

Il contenuto strutturato \u00e8 gi\u00e0 un pilastro di molti tipi di informazioni sul web. Gli elenchi di ricette, per esempio, sono stati basati su contenuti strutturati per anni. Quando cerco, per esempio, “ricetta della bouillabaisse” su Google, ho a disposizione una lista standard di link alle ricette, oltre a una panoramica delle fasi della ricetta, un’immagine e una serie di tag che descrivono una ricetta di esempio:<\/p>\n

\"Pagina<\/p>\n

Una “featured snippet” per allrecipes.com nella pagina dei risultati di Google.<\/p>\n<\/div>\n

\"Il<\/p>\n

La stessa pagina di allrecipes.com vista in Google\u2019s Structured Data Testing Tool<\/a>. Il pannello sulla destra mostra i valori machine-readable.<\/p>\n<\/div>\n

Questa visualizzazione “featured snippet” \u00e8 possibile perch\u00e9 l’editore dei contenuti, allrecipes.com, ha suddiviso questa ricetta nei pi\u00f9 piccoli frammenti significativi adatti a questo argomento e al pubblico, e ha poi espresso le informazioni relative a tali blocchi e le relazioni tra di essi in un modo machine-readable. In questo esempio, allrecipes.com ha utilizzato sia l’HTML semantico sia i dati linkati<\/a> per far s\u00ec che questo contenuto non fosse solo una pagina, ma anche dati accessibili e comprensibili che possano essere interpretati, adattati e remixati con precisione da algoritmi e smart agents. Diamo un’occhiata a ciascuno di questi elementi per vedere come lavorano insieme nei contesti di indicizzazione, aggregazione e inferenza.<\/p>\n<\/div>\n

\n

Software agent search e HTML semantico<\/h2>\n

HTML semantico \u00e8 markup ch comunica informazioni su relazioni significative tra gli elementi del documento, rispetto a semplicemente descrivere come dovrebbero apparire sullo schermo. Gli elementi semantici come i tag heading e list, per esempio, indicano che il testo che racchiudono \u00e8 un heading (<h1><\/code>) per l’insieme di elementi della lista (<li><\/code>) nell’elenco ordinato (<ol><\/code>) che segue.<\/p>\n

\"Combinazione<\/div>\n

L’HTML strutturato in questo modo \u00e8 sia di presentazione che semantico perch\u00e9 le persone conoscono l’aspetto e il significato degli heading e delle liste e gli algoritmi possono riconoscerli come elementi con relazioni definite e interpretabili.<\/p>\n

Il markup HTML che si concentra solo sugli aspetti presentational<\/em> di una “pagina” pu\u00f2 sembrare perfettamente a posto a un lettore umano ma essere completamente illeggibile per un algoritmo. Prendete, per esempio, il sito web City of Boston<\/a>, riprogettato alcuni anni fa in collaborazione con partner di progettazione e sviluppo di alto livello. Se volessi trovare informazioni su come pagare una multa per divieto di sosta, un link dalla pagina iniziale mi porta direttamente alla schermata “How to Pay a Parking Ticket” (si \u00e8 scorso per mostrare i dettagli):<\/p>\n

\"La<\/div>\n

Come umano che legge questa pagina, capisco facilmente quali siano le mie opzioni per pagare: posso pagare online, di persona, per posta o per telefono. Tuttavia, se chiedo a Google Assistant come pagare una multa per divieto di sosta a Boston, le cose diventano un po’ confuse:<\/p>\n

\"L'app<\/div>\n

Nessuno dei link forniti nei risultati di Google Assistant mi porta direttamente alla pagina “How to Pay a Parking Ticket\u201d, n\u00e9 le descrizioni mi fanno chiaramente capire che sono sulla strada giusta. (Non ho chiesto informazioni sul richiedere un’udienza). Questo accade perch\u00e9 il contenuto della pagina delle multe per divieto di sosta su City of Boston \u00e8 progettato per comunicare visivamente le relazioni di contenuto ai lettori umani, ma non \u00e8 strutturato semanticamente in modo che comunichi tali relazioni anche agli algoritmi indagatori.<\/p>\n

La pagina \u201cPay My Ticket\u201d di City of Seattle, sebbene manchi della ricercatezza dello stile visuale del sito di Boston, comunica anch’essa in maniera chiara le modalit\u00e0 di pagamento delle multe per divieto di sosta ai visitatori umani:<\/p>\n

\"La<\/div>\n

Tuttavia, l’equivalente ricerca con Google Assistant, offre un risultato molto pi\u00f9 utile di quello che abbiamo visto per Boston. In questo caso, il risultato di Google Assistant ci collega direttamente alla pagina \u201cPay My Ticket\u201d e inoltre elenca molti modi in cui posso pagare la multa: online, via posta e di persona.<\/p>\n

\"La<\/div>\n

Nonostante la semplicit\u00e0 visiva della pagina delle multe per divieto di sosta di City of Seattle, assicura in maniera pi\u00f9 efficace l’integrit\u00e0 del suo contenuto in vari contesti perch\u00e9 \u00e8 composta da contenuto strutturato e ha un markup semantico. \u201cPay My Ticket\u201d \u00e8 un heading di livello uno (<h1><\/code>) e ognuna delle opzioni sottostanti \u00e8 costituita da un heading di livello due (<h2><\/code>), che indica che si tratta di subordinate all’elemento di livello uno.<\/p>\n

\"La<\/div>\n

Questi elementi, se ben progettati, comunicano la gerarchia e le relazioni delle informazioni visivamente ai lettori e semanticamente agli algoritmi. Questa struttura consente a Google Assistant di supporre ragionevolmente che il testo in questi heading <h2><\/code> rappresenti le opzioni di pagamento sotto l’intestazione <h1><\/code> \u201cPay My Ticket\u201d.<\/p>\n

Mentre questo uso dell’HTML semantico offre vantaggi distinti rispetto allo stile di “visualizzazione della pagina” che abbiamo visto sul sito della City of Boston, la pagina di Seattle mostra anche una debolezza tipica degli approcci manuali all’HTML semantico. Noterete che, nei risultati di Google Assistant, l’opzione \u201cPay by Phone\u201d che abbiamo visto nella pagina Web non \u00e8 stata elencata. Se osserviamo il markup di questa pagina, possiamo vedere che mentre le tre opzioni trovate da Google Assistant sono racchiuse in entrambi i tag <strong><\/code> e <h2><\/code>, “Pay by Phone” \u00e8 contrassegnato solo con un <h2><\/code>. Questa irregolarit\u00e0 nella struttura semantica potrebbe essere ci\u00f2 che induce Google Assistant a omettere questa opzione dai suoi risultati.<\/p>\n

\"La<\/div>\n

Sebbene ognuno di questi elementi appaia identico a un umano vedente che stia creando questa pagina, la macchina che lo interpreta trova una differenza. Sebbene i campi di inserimento testo WYSIWYG teoricamente supportano l’HTML semantico, in pratica troppo spesso sono preda delle idiosincrasie perfino degli autori di contenuto maggiormente ben intenzionati. Rendendo la struttura dei contenuti significativa un elemento centrale del sistema di gestione dei contenuti di un sito, le organizzazioni possono creare HTML semanticamente corretto per ogni elemento, ogni volta. Questo \u00e8 anche il fondamento che consente di trarre benefici dalle ricche descrizioni delle relazioni fornite dai dati collegati.<\/p>\n<\/div>\n

\n

Linked data e aggregazione del contenuto<\/h2>\n

Oltre a trovare ed estrarre informazioni, come i passaggi di una ricetta o le opzioni di pagamento di una multa per divieto di sosta, gli algoritmi di ricerca e i software agent adesso aggregano anche il contenuto proveniente da pi\u00f9 sorgenti usando i linked data.<\/p>\n

Nella sua forma pi\u00f9 semplice, linked data<\/em> \u00e8 \u201cun insieme di best practice per collegare i dati strutturati sul web<\/a>\u201d. Linked data si estende oltre le capacit\u00e0 di base dell’HTML semantico descrivendo non solo che cosa sia un elemento di una pagina (\u201cPay My Ticket\u201d \u00e8 un <h1><\/code>), ma anche il concetto del mondo reale che quella cosa rappresenta: questo <h1><\/code> rappresenta una \u201cazione di pagamento\u201d, che eredita le caratteristiche strutturali delle \u201cazioni commerciali\u201d (lo scambio di beni e servizi con i soldi) e \u201cazioni\u201d (attivit\u00e0 svolte da un agente su un oggetto). Linked data crea una descrizione pi\u00f9 ricca e con maggiori sfumature della relazione tra gli elementi della pagina e fornisce le informazioni strutturali e concettuali che servono agli algoritmi per mettere insieme dati provenienti dalle sorgenti pi\u00f9 disparate.<\/p>\n

Supponiamo, per esempio, che io voglia raccogliere pi\u00f9 informazioni su due raccomandazioni che mi sono state fatte sui chirurghi ortopedici. Una ricerca per la prima raccomandazione, Scott Ruhlman, MD, fa emergere un insieme di link cos\u00ec come una info box Knowledge Graph<\/a> che contiene una foto, un luogo, orari, numero di telefono e recensioni dal web.<\/p>\n

\"Pagina<\/div>\n

Se passiamo la pagina del profilo del Dr. Ruhlman dello Swedish Hospital al Structured Data Testing Tool<\/a> di Google, possiamo vedere che il contenuto che lo riguarda \u00e8 strutturato in piccoli elementi discreti, ciascuno dei quali ha un markup con tipi e attributi descrittivi che comunicano sia il significato dei valori di quegli attributi sia il modo in cui si integrano nel loro complesso, il tutto in un formato machine-readable.<\/p>\n

\"Lo<\/div>\n

In questo esempio, il profilo del Dr. Ruhlman \u00e8 marcato con microdati basati sul vocabolario schema.org<\/a>. Schema.org \u00e8 un lavoro collaborativo sostenuto da Google, Yahoo, Bing e Yandex che mira a creare un linguaggio comune per le risorse digitali sul web. Questa base di contenuti strutturati fornisce la base semantica su cui \u00e8 possibile costruire relazioni di contenuto aggiuntive. La info box del Knowledge Graph, per esempio, include recensioni di Google, che non fanno parte del profilo del Dr. Ruhlman, ma che sono state aggregate in questa panoramica, che include anche una mappa interattiva, resa possibile dal fatto che la posizione dell’ufficio del Dr. Ruhlman \u00e8 machine-readable.<\/p>\n

\"La<\/div>\n

La ricerca di una seconda raccomandazione, Stacey Donion, MD, fornisce un’esperienza diversa. Come il sito City of Boston di cui sopra, il profilo di Dr. Donion sul sito web Kaiser Permanents \u00e8 perfettamente intellegibile da un lettore umano vedente. Ma poich\u00e9 il suo markup \u00e8 interamente presentational, il suo contenuto \u00e8 virtualmente invisibile ai software agents.<\/p>\n

\"La<\/div>\n

In questo esempio, possiamo vedere che Google \u00e8 in grado di trovare moltissimi link per Dr. Donion nei suoi risultati indicizzati standard, ma non \u00e8 in grado di \u201ccomprendere\u201d le informazioni su quelle fonti sufficientemente bene per presentare un risultato aggregato. In questo caso, il Knowledge Graph sa che Dr. Donion \u00e8 un medico di Kaiser Permanents, ma richiama la posizione sbagliata e il nome del medico sbagliato nel tentativo di creare una visualizzazione Knowledge Graph.<\/p>\n

Noterai anche che mentre Dr. Stacey Donion \u00e8 una corrispondenza esatta in tutti i risultati di ricerca elencati, che sono abbastanza numerosi da riempire la prima pagina dei risultati, viene mostrato un link “did you mean” per un altro medico. Stacy Donlon, MD, \u00e8 un neurologo che pratica presso MultiCare Neuroscience Center, che non \u00e8 affiliato con Kaiser Permanente. Multicare, tuttavia, fornisce profili semantici e collegati ai dati per i loro medici.<\/p>\n<\/div>\n

\n

Query vocali e inferenza del contenuto<\/h2>\n

La crescente diffusione della voce come modalit\u00e0 di accesso alle informazioni rende ancora pi\u00f9 importante fornire contenuti strutturati e comprensibili alle macchine. I voice and smart software agent non solo liberano gli utenti dalle tastiere, ma modificano il comportamento degli utenti. Secondo LSA Insider<\/a>, ci sono diverse differenze importanti tra le query vocali e le query digitate. Le query vocali tendono ad essere:<\/p>\n