Narciso Yepes e la chiave del quindici

Narciso Yepes, diventato noto al grande pubblico per aver suonato con la sua chitarra classica il pezzo centrale della colonna sonora di Giochi Proibiti, soleva ricordare di aver imparato le basi da un grande maestro che, però, non era un chitarrista, ma un pianista, Vincente Asencio.
Asencio gli faceva sentire al pianoforte cosa doveva suonare. Quando lui gli diceva che non era possibile ripeterlo con la chitarra, Asencio gli rispondeva che, se non poteva fare nulla con quello strumento, avrebbe fatto meglio a cambiarlo. Così Yepes studiò nuove tecniche, riuscì a ripetere gli esercizi proposti, diventò uno dei massimi virtuosi del mondo, arrivando a tenere concerti con la chitarra estesa da 6 a 10 corde dal liutaio Ramirez secondo i suoi suggerimenti.

Questo aneddoto deve essere molto noto perchè è facile incontrare persone che si immedesimano in Yepes.
Qualche virtuoso esiste anche, ma non è raro vedere usare strumenti sbagliati nei modi e momenti sbagliati, con tentativi di estensione ed estremizzazione, ma senza prima averne approfondito i limiti.

Come chi cerca di usare la chiave del quindici su un bullone da 12 o un martello per svitare un dado, talvolta i risultati possono non essere quelli sperati (ben vengano le eccezioni, ovviamente!).

In questo senso, uno degli esempi più comuni nell'informatica è quello di considerare l'XML come ingrediente fondamentale e irrinunciabile. Non importa per cosa, l'importante è usarlo.

---

Qualcuno di voi sarà anche saltato sulla sedia, ma l'XML, che mi conosce, sa che non deve prendersela, dal momento che gli è ben noto che lo uso con quotidiana assiduità.

Ci frequentiamo almeno dal 1996 1998 e non se la prende se continuo a sottolineare l'ovvio, ovvero che continuare ad evidenziare che è uno standard è utile quanto confondere Java con la sua sintassi di base.

Perchè di standard, nell'XML c'è solo quello: la sintassi.
La semantica bisogna sempre implementarla, come credo sia ben noto.

Dtd o Xml Schema servono per rafforzare la sintassi, anche se a diversi livelli, ma per usare quei dati incastrati tra un tag e l'altro, serve sempre un programmatore.

Spero, infatti, sia a tutti palese che, anche usando l'xsl(t), anche se dichiarativamente, anche se tra mille limiti e salti tripli per fare cose banali in altri ambienti, stiamo sempre scrivendo regole, filtri, semplici trasformazioni, qualche controllo, ovvero: programmando.
A questo proposito, giusto per fare un esempio che mi piace sempre sottolineare, progettare una architettura multilivello, separando bene la presentation dalle business rules e poi decidere coscientemente di buttare la possibilità di usare competenze e strumenti specifici del front-end (esperti di html e javascript, grafici che costano tipicamente meno di programmatori e strumenti WYSIWYG che permettono un disegno rapido) usando xml ed xslt per generare il layout e manutenerlo è veramente un peccato.

Senza considerare che il carico (sia in termini di heap che di cpu) per il parsing ed applicazione delle regole rischia spesso di essere significativo rispetto all'utilizzo di altre tecniche (magari compilate, come una buona vecchia JSP).

Comunque, se il fatto che si debba fornire la semantica programmandola e che sia ragionevolmente sconsigliato sfruttare l'XML come base di un template engine/layout manager fossero gli unici problemi non avrei scritto questo articolo. Si tratterebbe di peccati veniali.

Ciò che mi preme sottolineare è la tendenza all'esagerazione nell'utilizzo di questo seppur utile e versatile strumento.

Per esempio, come strumento per memorizzare dati, in ambiti complessi.
Per fare un esempio pratico: non mi direte che non avete mai visto un CMS xml-based, vero?
Io ho anche visto citare questa feature come elemento distintivo di certi sistemi, laddove il pubblico (e talvolta l'oratore) non era in grado di cogliere che:

• la stessa flessibilità descrittiva si può ottenere anche con un bel database, con la stessa facilità (i casi cui mi riferisco riguardano progetti di una certa dimensione, dove non è neppure messo in dubbio che esistano altre funzionalità per cui è necessario ed irrinunciabile un bel RDBMS)
• ricercare valori di tag in XML salvati sul filesystem non è operazione propriamente performante: per risolvere questo tipo di problema è solitamente necessario ricorrere ad altre strutture architetturali (es: estrazione preventiva dei metadati e loro indicizzazione - non di rado appoggiandosi ad un RDBMS, o, talvolta, addirittura riscrivendo da capo funzionalità che sono oramai consolidate e super-performanti da anni in quei sistemi -, cache multilivello, etc. etc.)
• come sopra citato, per la famosa estensibilità garantita dall'XML bisogna programmare: lo so bene che non è sempre necessario farlo all'aggiunta di un nuovo campo in un CMS, - a patto di rimanere entro certi limiti, beninteso -, ma per quello che mi è capitato di verificare nella pratica o si rientra in situazioni quasi banali e gestibili anche più facilmente su DB, o si devono comunque battere quelle costose 10 benedette dita sui tasti.

Un altro caso tipico è la generalizzazione "hand made", tipicamente in fase di configurazione di un sistema: il costo dell'interprete vale il vantaggio della generalizzazione? ci lamentiamo della reflection e aggiungiamo un intero interprete? anzi, a volte aggiungiamo pure la reflection come modalità di costruzione di oggetti generalizzati nell'xml, da far richiamare in una Factory e/o in un Singleton allo startup?

Non so se vi siete resi conto delle risorse richieste per l'elaborazione, soprattutto usando DOM - a proposito, su .NET c'è il parser SAX, o si va solo di DOM? io non sono riuscito a trovarlo...:

• tempi per il parsing (SAX e DOM)
• tempi per costruirsi gli oggetti (automaticamente nel DOM, spesso 'a mano', più leggeri, con parser SAX based)
• heap che si riempie facilmente (che so: mai provato un out of memory in Java per import dati massivo via XML, passando da un parser DOM?)

Vediamo di esaminare anche i vantaggi, per capire dove ha senso usarlo, almeno IMHO (in italiano verrebbe IMMP, fa schifo, spero lo capiate, senza considerare che la 'M' di 'Modesto' poco mi si addice):

• la standardizzazione di questa sintassi aiuta nell'avere dei parser e ci sono molti casi in cui un parser bell'e pronto è proprio ciò che ha ordinato il dottore (per esempio, per estendere un linguaggio con tag libraries/web controls)
• esistono casi - rari e semplici, purtroppo - in cui una bella trasformazione xslt è comunque decisamente più semplice da scrivere di un programma (es.: per creare dei pdf - xsl-fo - magari a partire da un html: bisogna lavorare un po' sull'xsl, ma fare uno spider che si naviga il sito in un certo ordine e ne produce un libercolo in pdf è alla portata - mi dicono che il Mac lo faccia di default, è vero? per PC, tra gli open source, di decente ho trovato solo HTMLDOC, anche se non si naviga da solo gli url delle pagine - ; ancora: nel passaggio di dati da un sistema ad un altro, spesso è utile trasformare un XML proveniente dall'esterno in un XML in formato già gestito dal nostro sistema, per rielaborarlo senza ulteriori sviluppi e un filtro di questo tipo scritto in xsl è la morte sua).
• laddove le descrizioni dei dati (dai tracciati record alle immagini SVG) sono complesse e questi dati devono essere scambiati tra sistemi o essere alla base di programmi per cui ha poco senso aggiungere un database, l'XML è decisamente più adatto di altri formalismi (es, il vecchio EDI), essendo potenzialmente molto più ricco, espressivo e permettendo di condividere e validare la sintassi in modo più mirato.

Proviamo un piccolo riassunto di casi pratici, relativo ai punti su cui solitamente mi sento o non mi sento di usarlo:

NO

• in generale, per evitare di gestire documenti su DB (es. del CMS) o come modalità di estensione dei campi nel database: non posso fare ricerche e join in modo performante, devo parsare ed intepretare il mio file ogni volta (a meno di pre-parsing ed indicizzazioni di cui si è già parlato - ma come gestite l'indicizzazione? la delegate al DB o la gestite a mano? vi siete ricordati di indicizzare tutti gli elementi e lasciare il testo ad un motore di ricerca full-text? i valori dei tag sono codificati o si tratta di stringhe, pure inserite manualmente?). Indizi del fatto che non va così bene: a parte i tempi di sviluppo di eventuali indicizzazioni e recupero dei dati, dovete usare uno o più livelli di cache e, in caso di miss, la relativa interpretazione porta via 2 ordini di grandezza o più del tempo necessario per recuperare il dato pre-interpretato dalla cache (2 ordini di grandezza è troppo: sarebbe bene che le cache correggano 1 ordine di grandezza, altrimenti è indice di seri problemi nell'operazione fuori cache: se non ci sono alternative, fate bene ad usarle, ma se le alternative ve le siete precluse da soli...).
• XML per memorizzare oggetti:
• non vi piaceva la serializzazione nativa di Java e davvero pensate che questa sia più veloce? provate a fare un profiling e non dimenticate la gestione del versioning delle classi).
• la versione in xml potete passarla come risultato di un Web Service? in linea di principio va bene, ma usare qualcosa di già pronto - es: SOAP - e passare direttamente l'oggetto era troppo standard?
• vi serve per estendere il DB? v. sopra.
• Volete farvi da soli il vostro OODBMS? Forse è il caso di considerare qualcosa di già pronto (ma non prima di aver considerato che, comunque, si tratta di tecnologie ancora molto discusse e, come minimo, un po' immature)
  
• XML alla base dello strato di presentation: in questo caso si ha la perdita di performance per interpretazione vs. compilazione di cui ho già parlato; vi sentite più flessibili nel definire le zone del sito e le pagine? avete contato bene il costo di manutenzione, la flessibilità e quanto vi è costato realizzare un Template Manager di quel tipo, fuori da ogni standard?.

NI [situazioni da pesare, caso per caso: personalmente non ho ancora trovato una regola]

• XML come file di configurazione [rischio: overdesign (in molti casi basta un file di properties) - possibile vantaggio: flessibilità ed espressività (soprattutto quando servono diversi livelli di approfondimento)]
• XML come metadato (es.: base per Xlink o, più in generale, per il Web semantico ed RDF) [rischio: performance povere per mancanza indicizzazione o indicizzazione manuale, difficoltà nell'eseguire query, difficoltà di documentazione - possibile vantaggio: distribuibilità, laddove le performance non sono importanti, maggiore disponibilità di ambienti per eseguire parsing xml rispetto ad installare un RDBMS

SI

• XML per trasferire dati ed aumentare l'interoperabilità tra applicazioni (in tanti sostengono che sia nato per questo ;) ):


• Web Services
• base per Web 2.0, a partire da RSS/ATOM
• come sorgente dati remota (in particolare come RE in REST)
• in generale, per disaccoppiare i sistemi


• XML come base per il formato di memorizzazione di una applicazione standalone laddove usare un DB sarebbe un po' eccessivo (es: state scrivendo Open Office e decidete di salvare in dati in locale, in formato portabile, aperto e facilmente trasformabile; i vostri dati, in questo caso, tipicamente non richiedono ricerche cross tra i diversi xml, al più solo all'interno di uno stesso documento
• come base per definire nuovi linguaggi che richiedano interpretazione ed esecuzione: Apache Ant docet e certamente ha senso, dal momento che, in questi casi, comunque bisogna scrivere un parser ed un interprete e trovarsi con metà del lavoro fatto (e anche bene) non può che far piacere; altri esempi sono linguaggi che descrivono regole inferenziali (es: XML Rule Language in JBoss Rules - ex. Drools - ma, attenzione, nel manuale anche loro stessi dicono: 'There are several scenarios that XML is desirable. However, we recommend that it is not a default choice ...') o linguaggi che descrivono comportamenti che necessitano di un controllo di esecuzione (es: per definire dei workflow o - con un salto di fantasia di un centimetro e mezzo - come base per il governo di un ESB, come nel caso di BPEL).

Avete altri esempi? Avete elenchi di altri metodi architetturali usati malamente?
Non siete d'accordo su quanto ho detto dell'XML e ne volete parlare?
Beh, provate a darmi un feedback, prometto che se ne ho voglia ci penso su...

Bye

Depa

P.S.: poi magari salta fuori che avete ragione voi
P.P.S.: per quanto improbabile, intendo... ;)

[... continua ...] Leggi tutto

Come forzare un lucchetto

Sembra incredibile, ma tra le ricerche che ieri hanno portato al mio blog c'è la frase riportata nel titolo.
Quando l'ho visto mi sono chiesto se potevo aver scritto qualcosa in trance e aver svelato anche i segreti del grande Houdini
Ho ripetuto la ricerca e, come vedete dalla foto, è proprio vero: addirittura sono in cima all'elenco!
Fortunatamente sono secondo, anche se si cerca hibernate pro e contro :)

Evidentemente qualcuno cercava di capire come possa essere fuggito Marco Berry in Danger, probabilmente queste ricerche aumenteranno con le puntate del programma.
A pensarci bene poteva pure essere uno scassinatore di cassette di sicurezza. Un professionista, che ha ben chiaro che bisogna prepararsi, prima.
Beh, a quanto pare, sono io che ho rubato uno unique visitor, stavolta.

Comunque, sfruttiamo questa situazione e scriviamo anche questo post: se già ero in cima prima, ora chi mi smuove più? Gli hits sono hits, ragazzi (e lo so che la 's' finale non ci vuole, in italiano: l'ho messa apposta, per accentuare il suono sibilante dell'ultima frase).

C'è un problema in tutto questo: non sarebbe dovuto capitare. Anche per voi, dico, perchè poi vi dovete sorbire questi vaneggiamenti.

C'è forse una soluzione informatica? E' forse il Web Semantico?

---

Prima di passare alla discussione vera e propria, è necessario che vi segnali anche il secondo risultato dell'elenco (che, intanto che scrivo, è passato primo: forse anche per colpa mia): è un blog di enigmi, ma era inevitabile che a questo dovessi commentare (l'ho fatto, andate a leggervi cosa ho scritto su quel post), dal momento che era evidente che stavano parlando di informatica.

O sembrava solo a me? Davvero non distinguo più vita e informatica?

Torniamo al Web Semantico.
Come introduzione vi consiglio una presentazione della Dott.ssa Mordonini, usato in un seminario nell'Università di Bologna, molto chiaro ed esteso.

Provo giusto a riassumere due o tre punti essenziali, da dilettante dell'argomento e con un occhio, al solito, alle implementazioni pratiche:

• il Web contiene un numero enorme di informazioni che non sempre riusciamo a raggiungere come vorremmo (e fin qui, lo sapevate già, l'ho riportato solo per vedere se eravate svegli e mi stavate seguendo)


• il problema è legato al fatto che il Web è oggi costituito solo da legami sintattici (URI) e non semantici. Ovvero, le pagine sono, tipicamente, collegate tra loro senza una spiegazione del significato del link, che possa essere utilizzata da un computer.


• non basta aggiungere dei tag, simili a quelli che trovate nei vari blog, per aggiungere questo significato: è necessario un maggior formalismo per permettere di applicare algoritmi inferenziali.

Parentesi.

Le slide chiariscono che Web Semantico non è Intelligenza Artificiale (AI), ma più avanti ricordano che sono necessarie capacità inferenziali (correttamente evidenziando che in questo ambito, ci interessa particolarmente la deduzione e non l'abduzione o l'induzione).

Probabilmente è corretto, ma solo in senso stretto e formale, e cercando di dare ragione a Douglas Hofstadter che, nel suo oramai-letto-anche-dai-sassi (se non lo avete fatto, è un po' tardi: per quanto sia un libro grandioso - vinse anche il premio Pulitzer - è del 1979, un po' datato, visto l'argomento) Gödel, Escher, Bach - Un'eterna ghirlanda brillante sosteneva che

l'Intelligenza Artificiale è tutto ciò che non ancora non è stato fatto

perchè

tutto ciò che le macchine hanno imparato a fare e che (prima che lo facessero) era ritenuto segno di comportamento intelligente, non viene ritenuto più tale una volta che le macchine lo fanno

Fine Parentesi.

Le slide proseguono con una ben chiara distinzione tra semplici tassonomie, tesauri (es: Wordnet) e ontologie (es: OpenCyc).

Vorrei evitare di appesantire ancora, ma sono costretto a due rapidi pprofondimenti, altrimenti non si capisce più nulla, (rivedremo entrambi gli argomenti in prossimi post in maggior dettaglio):

• Wordnet è un vocabolario semantico, organizzato in Synset, ovvero insiemi di sinonimi. Ovvero: come certamente sapete le parole (i lemmi) possono avere diversi sinonimi. I dizionari dei sinonimi e dei contrari dei tempi della scuola sono un primo passo in questa direzione, ma hanno la brutta tendenza a mettere assieme sinonimi anche con significati differenti (non tutti, ma quelli che si comportano bene non ci stanno, nella cartella) ed è, comunque, difficile, fare dei controlli incrociati di congruenza senza averli in formato elettronico. I Synset, invece, sono insiemi di sinonimi con lo stesso significato. Per fare un esempio, il lemma prova comparirà in diversi Synset, insieme ai suoi sinonimi. Per es:
  
  
  • prova, evidenza, ... (nel senso di prova giudiziaria)
  • prova, esperimento, ...
  • prova, esame, ...
  • etc. etc.
    
  Ogni Synset rappresenta, quindi, nella pratica, un concetto diverso.


• Di OpenCyc vi ho già parlato, e ne riparleremo più avanti, è troppo complesso per spiegarlo in 2 righe - spero riuscirete a dormire la sera, nel frattempo. Per ora ci basterà dire (tagliandola spessa) che la principale differenza rispetto a Wordnet sta, soprattutto, nell'aggiunta della capacità inferenziale e di informazioni necessarie a supportarla (Knowledge Base, una base di conoscenza, abbreviata con KB). Peraltro esiste, nella KB di OpenCyc, una esplicita relazione con Wordnet e le relazioni tra i lemmi ed i loro significati (esistono anche relazioni implicite, basate sulla struttura delle informazioni, ma non sono, solitamente, mappabili 1:1 con facilità).

A questo punto del post voi siete stremati, anche se io ho a malapena finito la premessa.
Questa volta, però, non vi grazio, altrimenti non arriveremo mai al punto.
Inoltre non ho ancora sentito suonare la campanella.

Per portare tutte queste considerazioni sul Web, è necessario un linguaggio che permetta di aggiungere informazioni strutturate alle pagine.

La proposta più consolidata, ad oggi, la si trova in un insieme di linguaggi formali (per lo più basati sull'XML) che, a diverso livello, permettono di definire le proprietà che descrivono i documenti (risorse identificabili da un URI) e di ricercarle.
Sempre andandoci giù pesante con le semplificazioni, si tratta di:

• RDF: attraverso triple [soggetto, predicato, oggetto], anche complesse e composte (es: un oggetto può essere, a sua volta, una tripla - si parla di reificazione), si forniscono proprietà al documento


• RDFS (RDF Schema): permette di descrivere le classi dell'RDF (ovvero, serve per definire meta-informazioni riguardanti i componenti della tripla di cui sopra), specificandone relazioni e vincoli


• OWL (Ontology Web Language): siccome la coppia di cui sopra ha solo un limitato potere espressivo, viene proposto (via W3C e sempre nel contesto RDF) questo linguaggio, con l'intento di permettere di eseguire delle inferenze


• SPARQL: il linguaggio W3C per eseguire query sull'RDF, di fatto una sorta di SQL portato su queste tecnologie

Niente male, come stack (non sono in grado di valutarlo ora, anche per mancanza di tempo, ma pongo lo stesso la domanda per chi fosse in grado di rispondermi: non sarebbe più semplice usare un solo linguaggio come CycL, quello usato per OpenCyc? è veramente più complesso da imparare, o stiamo solo nascondendoci dietro alla sintassi per problemi più seri che interessano la semantica? anche l'espressività ne guadagnerebbe, o no? non piace il fatto che si tratti di una proposta di una sola azienda e che il gap per creare simili motori sia difficile da colmare?)

A questi dobbiamo aggiungere un vocabolario condiviso. Qualcuno suggerisce che URI che puntano alla Wikipedia potrebbero fare al caso, altri (compreso il W3C) propongono vocabolari più specifici.

E' importante notare che non si tratta di sola teoria, ma esistono già tool che trattano queste problematiche (es: Jena, un framework per il Web Semantico in Java, che è in grado di gestire RDF, RDFS, OWL, SPARQL e contiene già un motore inferenziale - realizzato dagli HP Labs, ma presenta licenza apache-like).

Tutto risolto? Veramente no: restano aperti problemi pratici importanti:

• bisogna comunque partire da informazioni corrette, alla base, altrimenti otterremo ragionamenti non corretti. Ovvero, anche in perfetta buona fede è facile ricadere nelle ambiguità del linguaggio naturale. In generale, per costruire una ontologia in un ambito ristretto, tipico di una Intranet e limitandosi ad argomenti tecnici, ci possono volere mesi/uomo (infatti, sono allo studio classificazioni automatiche). Approfondiremo meglio questi aspetti quando parleremo dell'enorme sforzo portato avanti su OpenCyc (anche se in ambito più complesso ed esteso, ovvero sulla KB alla base del senso comune) e delle best practice che da là sono emerse. Vi anticipo che non è pane per Web Designer, ma per ingegneri della conoscenza. Questa sola considerazione fa parecchio pensare, IMHO, sulla possibilità di utilizzare nel breve le tecniche fin qui descritte su Internet in modo produttivo.


• anche supponendo che le informazioni siano corrette alla fonte, come possiamo dare all'utente finale degli strumenti semplici da usare che gli permettano di eseguire ricerche mirate? Di fargli usare SPARQL non se ne parla nemmeno (sarebbe come dire: smettiamo di fare interfacce grafiche per i vostri gestionali, imparatevi l'SQL e arrangiatevi a farvi le query da soli). Non è che l'utente finale preferirà
  una risposta potenzialmente errata e sporca (che, tutto sommato, capita più raramente di quanto si voglia far credere, soprattutto in ambiti ristretti, che sono quelli su cui oggi è affrontabile un discorso di ontologie) tipica di un motore di ricerca, che trovarsi di fronte ad interfacce complesse da utilizzare?


• veridicità ed affidabilità delle informazioni: dovremmo prevedere una sorta di certificatore? quante risorse potrebbero servire per validare tutti i documenti immessi? Serve, comunque, un confronto semantico, altrimenti ricadiamo nella semplice verifica incrociata, già eseguita dai principali motori di ricerca, tra meta tag nell'head dell'HTML con quanto contenuto nel body

L'abbiamo presa da un punto di vista più serio della volta che vi ho parlato dell'AIML, ma i risultati sono quasi gli stessi: forse serve qualcosa di più potente ed automatizzabile. Ancora una volta, è un mio parere personalissimo, rischiamo di dover ricadere verso ambiti più legati all'AI. Quanto siamo lontano dal far comprendere il linguaggio al computer?

Forse meno di quanto pensate.
Forse più di quanto penso io (bisogna ben tenere in conto il teorema di Hofstadter -

Ci vuole sempre di più di quello che ti aspetti, anche se tieni in conto la Legge di Hofstadter

- per tacer di Murphy).

Come già minacciato, per finire quelli che sono sopravvissuti a questo post, torneremo ancora su questi argomenti parlando almeno di Wordnet (e suo figlio, Eurowordnet, che potrebbe tornare utile per le traduzioni - potendo comprare la licenza, s'intende...), Conceptual Dependency di Shank e OpenCyc.

Se un giorno di questi sono di buona magari vi parlo di approcci più leggeri, per iniziare a fare qualcosa, per esempio utilizzando bene Lucene, anche con le nuove funzionalità di stemming recepite da Snowball, ma non contateci troppo.

Bye

Depa

[... continua ...] Leggi tutto