Preferenza per i dati o preferenza per la struttura?

Preferenza per i dati o preferenza per la struttura?

Alcuni pensano che sia naturale e gratificante poter categorizzare e astrarre, mentre altri lo trovano frustrante e non necessario.

Il problema, con le tecnologie dell'informazione, è che i programmatori di computer spesso si ritrovano nella prima categoria mentre gli utenti di tali programmi spesso si ritrovano nella seconda.

Per esempio, il file system.

I file e le cartelle sono concetti che furono inventati da persone che amministravano tonnellate di informazioni cartacee e, a causa di questo, ad essi piaceva categorizzare ed astrarre...cosa che invece non fanno i normali utilizzatori! Guarda ad un'auto, un tavolo, una stanza, uno sgabuzzino...essi sono tutti ordinati perfettamente, etichettati e ben categorizzati?

Se risulta più semplice/veloce trovare qualcosa in 8 miliardi di pagine Web rispetto ai tuoi circa 100 mila file (compresi documenti, email, fotografie, etc.), vuol dire che c'è un problema.

Un altro esempio, fogli di calcolo e database.

Entrambi sono basati su tabelle, con le righe che rappresentano gli elementi e le colonne i loro attributi. Entrambi permettono relazioni, ma allo stesso tempo i fogli di calcolo sembrano strumenti non ottimali ed amatoriali per gli utenti di database mentre i database sembrano estremamente rigidi per l'utilizzatore medio di fogli di calcolo. I fogli di calcolo (non i database!) furono la ragione per la quale le persone spendevano 10 mila dollari per un personal computer negli anni '80. Nessuna sorpresa sul fatto che IBM non capì il trend.

Ancora un altro esempio: blog e CMS.

Quando realizzi un blog, tu non dici al blog dove posizionarlo. Scrivi soltanto, fai blog. Quando scrivi un diario, non scegli una pagina a caso e scrivi un indice per indicare dove localizzare quell'elemento. Cominci a scrivere da dove hai lasciato. Ad alcune persone piace categorizzare i loro post di blog, ad alcuni invece no. Alcune persone decidono cosa prevedere nei loro feed, mentre altri permettono ai loro visitatori di ricevere un feed RSS per una particolare query.

Scoperto il modello?

Le strategie che preferiscono i Dati hanno una più alta efficienza di usabilità (a parità di variabili) rispetto alle strategie che preferiscono la Struttura.

Le ragioni non sono così ovvie:

1. La strategia che preferisce i Dati è equivalente a come impariamo e a come evolve il linguaggio. Costruiamo regole, modelli, astrazioni e categorie nelle nostre menti dopo aver collezionato informazioni, non prima. Questo succede perché è più semplice imparare un liguaggio di computer partendo da esempi piuttosto che dalla sua teoria, oppure una lingua naturale con una full immersion invece di imparare tutte le regole e le eccezioni.
2. La strategia che preferisce i Dati è reversibile in modo più incrementale, la complessità nel sistema viene aggiunta più gradualmente ed è più semplice ritornare alla situazione precedente.
3. A causa dei punti precedenti, il ROI - Return on Investiment della strategia che preferisce i Dati è percepibile in modo più immediato, rendendolo così appropriato per essere più facilmente bootstrappable.

Ma poi, ci si potrebbe chiedere, perché si è così ossessionati dal design e dall'ordine? Perché è così difficile credere che un auto-organizzazione potrebbe essere utilizzata al di fuori della regno biologico come un modo per amministrare sistemi di informazione complessi?

Bisogna sottolineare una cosa importante:

Su una scala di tempo locale ed una volta che essa è stabilita, i sistemi che si basano sulla strategia che preferisce la Struttura sono più efficienti.

Questo in pratica significa che in ogni dato istante e con infinita energia per stabiliri, i sistemi che preferiscono la Struttura sono preferibili. Il problema è che il bootstrapping costa e la capacità di evolvere nel tempo di ogni dato sistema designato sono endemicamente sotto-stimati, rendendo ogni progetto che preferisce la Struttura più interessante di quelli che preferiscono i Dati, almeno per quanto riguarda il tempo di ideazione.

Ma c'è di più: sappiamo che un disordine totale non è una buon metodo di trovare le cose, così che preferire i Dati deve implicare che una successiva strutturazione sia in grado di ottenere ogni utile capacità di organizzare informazioni. Ecco dove le cose fallivano in passato: non molti credevano che potessero emergere strutture utili dai dati collezionati.

Ora guardati intorno: gli esempi di "emergenza dati" si stanno moltiplicando e gli usiamo ogni giorno. PageRank di Google, Amazon, Citeseer cocitation, del.icio.us e Flickr, Clusty, tutti questi sono esempi di sistemi che provano a far emergere strutture da dati, invece di imporre le strutture e pretendere che le persone le riempiano con i dati.

Alcuni credono che il Web Semantico è un esempio di "preferenza della struttura" ma di sicuro non è il caso...ancora, molte e molte persone davvero credono che, per avere successo, un design con "preferenza della struttura" (meglio "preferenza dell'ontologia" in questo caso) rappresenta il modo migliore per costruire l'interoperabilità.

Come forse avrai intuito, non sono d'accordo.

Penso che l'RDF sia un buon modello di dati per strutture come grafici e che sistemi complessi di vita reale tendono a mostrare strutture come grafici. Credo anche che il valore non risiede nell'ontologia utilizzata per descrivere i dati ma nell'abilità di identificare globalmente (e isolare) frammenti di informazione e nell'esistenza (o la mancanza) di relazioni fra loro.

Cerca di capirmi, alcuni vocabolari comuni (RDF, RDF Schema e Dublin Core) fanno molto per ridurre lo sforzo di bootstrapping e rendere possibile l'interoperabilità. Nello stesso tempo, credo che le persone coglieranno la palla la balzo nello spazio dell'ontologia e quando non troveranno soddisfazione, scriveranno ontologie proprie. A volte l'uso e l'abuso creeranno una sorta di Babele di piccole deviazioni che saranno processate con un approccio mentale di "preferenza dei dati". Dovrà essere creato un sitema immune, creati recipienti di fiducia, migliorate le valutazioni.

La prossima volta che spendi energia nello scrivere ontologie, o schemi di database, o XML Schema, o architettura di software, o protocolli, quei problemi 'previsti' per i quali non hai pensato ancora cose come "non ne hai bisogno", "fai la cosa più semplice che può funzionare", "lascialo semplice", "pubblicalo prima e spesso", "se non è rotto non aggiustarlo" e tutti gli altri vari consigli che ti dicono di non credere nel deisgn come il modo di risolvere i tuoi problemi.

Ma non dimenticare di pensare ai modi di far emergere le successive strutture dai dati, o sarai perduto con un semplice sistema che fallirà nella sua crescita in complessità senza deteriorarsi.