Un nuovo tool per cercare dati: WolframAlpha

20 maggio 2009 marcello urbani

WolframAlpha è un nuovo strumento per cercare informazioni in rete, molto diverso da quelli cui siamo abituati. Ha ottime capacità di interpretazione della lingua naturale, calcolo, disegno di grafici e presentazione dei risultati e promette di essere un ottimo complemento a Google e Wikipedia.

WA è specializzato nel trattare informazioni numeriche o scientifiche, per cui non è un concorrente di Google più di quanto i tapis roulant lo siano delle biciclette. Infatti anzichè "search engine" si autodefinisce un "computational knowledge engine".

Il servizio è attivo da pochi giorni (è stato lanciato il 15 maggio) e Stephen Wolfram (famoso per Mathematica) giura che migliorerà col tempo, ma già ora ha capacità impressionanti (video).

''Cosa fa
''

La forza di questo prodotto è nella grande quantità di dati (soprattutto scientifici) catalogati in base al loro significato ed alla capacità di interpretare il linguaggio corrente per cercarli. Per esempio è in grado di identificare come tali, e dare informazioni dettagliate e grafici su, azioni, pianeti, città, molecole, telescopi orbitanti, inclusi gli andamenti temporali, la posizione in cielo rispetto al punto (stimato) da cui ci colleghiamo, le coordinate, la struttura, la posizione corrente. Risponde anche a domande tipo capital of burundi, distance earth moon, weather in rome (ora o alla nascita di Napoleone), ed essendo basato su Mathematica è forte in confronti e calcoli, integrali compresi. Ovviamente conosce anche il senso della vita :).

''Cosa non fa''

Non ricerca siti web, per cui cercare cose come travel, sex o news porta a definizioni da dizionario o valori azionari. Del vino o dei tartufi mi da i valori nutrizionali ma ignora l'aspetto gastronomico, e conosce solo i dettagli minimi dei film più famosi. Insomma, è pressochè inutile per gran parte delle cose che cerchiamo di solito in Google.

''Problemi (ovvero: cosa dovrebbe fare ma non fa)
''

Mentre sa dividere l'altezza dell'Everest per la lunghezza del Golden Gate, per qualche motivo non riesce a dividere la distanza Terra-Venere per quella Terra-Luna (pensa ad una cittadina texana di nome Venus!), semplicemente non capisce "distance earth venus / distance earth mars" e capisce ma non calcola "distance milan rome / 2". Curiosa poi la risposta a tax: la interpreta come "Crema, Lombardy | total sales tax rate" e mi informa che il dato non è disponibile. La risposta è chiaramente dipendente dalla mia posizione geografica.

''Note legali''

Come nota groklaw WA reclama il copyright su cio che produce: chi ne riproduce un risultato deve attribuirne la fonte (pare che in futuro vogliano anche specificare quali icone usare all' uopo...)

''Conclusione''

Sono rimasto molto impressionato dalla quantità delle informazioni disponibili, la qualità della presentazione grafica e la flessibilità nell'interpretare la lingua inglese. Mi sembra un ottimo strumento per cercare dati da enciclopedia (solo dati, non un articolo come su wiki) e non dubito che ne farò uso piuttosto spesso, ma sono scettico sui possibili miglioramenti (eccetto per la soluzione dei problemi accennati sopra, chiaramente pecche di gioventù).

La forza dello strumento viene soprattutto dalla abilità di interpretazione semantica delle informazioni, che può essere automatizzata per cose come metereologia, cartografia, mercati azionari, genetica o chimica, ma richiederebbe un intervento umano diretto per classificare tutta una serie di altre cose disponibili in rete (news, letteratura, commercio al dettaglio). Qualcosa si potrà forse fare per i dati statistici, se chi li raccoglie ha interesse a divulgarli gratuitamente. Sarà anche molto complicato ottenere la stessa capacità di capire il linguaggio naturale in altre lingue, lo sforzo richiesto è un'altro ordine di grandezza rispetto a quello per una semplice traduzione.

Insomma, credo sia un gran bel giocattolo. Come altri ho dei dubbi su quanto possa essere utile per usi seri o esteso ad informazioni meno strutturate. Spero che sia economicamente sostenibile perchè è molto efficiente nel reperire certe informazioni.

Un'ultima nota: lo sforzo di rendere più semanticamente rilevanti le informazioni reperibili in rete non è un'esclusiva di Wolfram: da anni si parla di "semantic web" e si cerca di promuovere l'uso di XML al posto di HTML. Dovrebbe essere quasi sempre possibile sostituire HTML con XML e stilesheets, ma funziona solo nei browser moderni, e non perfettamente, per cui per ora le applicazioni sono rare. Inoltre altre società, tra cui Google, stanno cercando di migliorare l' interpretazione semantica delle informazioni disponibili, di regola in modo meno radicale.

29 commenti (espandi tutti)

Basta aggiunger un planet :)

http://www68.wolframalpha.com/input/?i=distance+earth+planet+Venus+%2F+distance+earth+planet+mars

P.S.

L'inserimento dei link con firefox su mac osx non mi funziona. Succede anche ad altri?

P.P.S.

Ho scoperto che Adblock plus interferisce con il popup per l'inserimento dei link. Magari potete inserire una nota nella finestra dei commenti visto che è un'estensione di firefox abbastanza diffusa.

sei cremasco!?!

 

http://www72.wolframalpha.com/input/?i=x%27%3D3x%5E2%2B3x-t (pazzesco, fa anche le simpatiche riccati...)

Lumezzanese, ma non è la prima volta che il mio IP passa per cremasco.

Quanto alle riccati non le conosco, ma Alpha è basato su Mathematica, il calcolo simbolico (e non) è il suo pane.

Tax

Vincenzo Caponi 20/5/2009 - 22:36

Assuming "tax" is referring to cities | Use as a word instead

 

basta cliccare su "a word" per avere la definizione di tax e varie altre invormazioni:

tax | charge against a citizen's person or property or activity for the support of government

@checcot

grazie, bel trucco.Per la verità non ho nemmeno controllato la pagina con le istruzioni su come affinare le query.

Proverò il plus (col normale funziona), mi sa che se è mac specific sarà dura.

@Vincenzo

Ok, grazie della segnalazione.Però "Crema,Lombardy | total sales tax rate" non è una città, e comunque per termini abbastanza comuni un po' più di euristica non guasterebbe.

Sono "letti" da tutti i browsers ormai da anni ovvero la praticamente totalità dei naviganti può leggere siti fatti in questa maniera.

Il problema della ancora scarsa diffusione é più imputabile a chi i siti li realizza più che allo stato attuale delle tecnologie; é uno standard pubblicato nel 1999 ma adottato dagli sviluppatori solo di recente (3/4 anni per noi italioti, anche 6/7 per gli States). Più rimane il "parco siti" vecchi, ormai da rottamare (gli euro 0 del web per interderci) , fatti anni fa e che fa diminuire la percentuale dei siti XHTML sul totale.

Tuttavia nel 2009 nessuno, con un minimo di compentenza, si sogna di svilluppare più in HTML ma solo in XHTML.

PS. il anche vostro sito é in XHTML (anche se non passa la validazione)

Forse (e sottolineo forse) Marcello non si riferiva ad XHTML + CSS, ma ad XML + XSL, che è una cosa completamente diversa. Inoltre anche sul fronte XHTML c'è ancora molto da fare, tant'è che questo sito (che, come giustamente ricordi, è in XHTML) suggerisce come content type "Text/HTML". E non potrebbe fare altrimenti visto che, con il content type giusto terrebbe fuori IE (almento fino alla 7 lo avrebbe interpretato come XML, con la 8 non so); inoltre ci sarebbero problemi in caso di errori di validazione (come in questo caso).

Tuttavia nel 2009 nessuno, con un minimo di compentenza, si sogna di svilluppare più in HTML ma solo in XHTML.

Non è proprio così: la home page di Google è in HTML (nota nei sorgenti i tag br non autochiudenti).

Premesso che mi occupo di tutt'altro (SAP) e mi interesso di queste cose solo a livello amatoriale, sono d'accordo che il problema è più nella cultura degli sviluppatori che nella tecnologia,ma con alcuni caveat:

  1. come suggerisce Paolo, pensavo più a XML+XSL che ad XHTML+CSS (che ha poco a che fare con la semantica dei contenuti).E' una tecnologia molto meno diffusa di XHTML.
  2. sulla carta la tecnologia è matura, ma molti browser hanno problemi di rendering. Già sui CSS ricordo vagamente dei test che mettevano in crisi sia firefox 2 che IE 7.Errori minori, certo, ma molti utenti usano ancora cose tipo IE6

Ovviamente poi molti non hanno interesse a rendere facilmente interpretabili le informazioni che pubblicano, e molti altri son basati su applicativi o toolkit basati su vecchia tecnologia e non hanno un buon motivo per cambiare.

Premesso che una volta mi occupavo proprio di questo per mestiere posso precisarti più o meno come stanno le cose oggi

  1. I test di cui parli sono i cosiddetti Acid Test (li trovi facilmente in giro)
  2. Le versioni 1 e 2 di tali test sono superati in maniera più o meno brillante dalle ultime versioni dei browser
  3. Con IE8 (l'unico browser che soffre ancora di questi problemi) sembra che gran parte dei problemi siano superati, anche se restano aperte parecchie incompatibilità con il prossimo CSS3
  4. purtroppo IE6 ha ancora un quinto circa di utilizzatori e IE7 è uno dei due browser più usati (insieme a Firefox 3): quindi di tali benefici non si può ancora fruire...
  5. Il problema non credo che dipenda da una cattiva volontà di chi pubblica: pian piano le persone si adegueranno ai nuovi SW messi a disposizione. L'uso dei CMS favorisce in tal senso l'operazione; quando gli utenti si renderanno conto dei vantaggi connessi alla pubblicazione di contenuti semanticamente strutturati probabilmente vedremo un esplodere di simili tecnologie.

Stiamo scivolando paurosamente OT, spero di chiudere con questa.

Sulla tecnologia siamo d'accordo: finchè non saremo migrati quasi tutti (diciamo al 90-95%) su IE8,FF3 o gli equivalenti Opera/Chrome/Konqueror/..., questa tecnologia sarà una curiosità da laboratorio, o al più potranno trovare applicazioni in siti ad uso interno di qualche ente.

Quanto alla volontà di chi pubblica pensaci meglio: finchè hai in mente i CMS va bene, ma roba come yahoo finance o IMDB vivono di pubblicità, credo sian più tentati dall' idea di mettere un capcha che dal formattare tutto in XML.

Stiamo scivolando paurosamente OT, spero di chiudere con questa.

Permettimi di correggerti: questa una volta era la mia materia, stavo scrivendo una tesi di dottorato su questo tema, anni fa. Qui parliamo di web semantico: l'XHTML è stato un primo tentativo di organizzare semanticamente i contenuti delle pagine web. Spero di averlo spiegato bene nell'altro ramo del thread. Se i browser non si fossero evoluti sarebbe stato difficile ipotizzare una simile direzione. Come ho spiegato nello stesso ramo queste tecnologie non sono una curiosità da laboratorio, ma una realtà industriale utilizzata dalla più grande azienda che lavora per il web: Google.

Quanto alla volontà di chi pubblica pensaci meglio: finchè hai in mente i CMS va bene, ma roba come yahoo finance o IMDB vivono di pubblicità, credo sian più tentati dall' idea di mettere un capcha che dal formattare tutto in XML.

Penso che ci sia stato un fraintendimento: intendevo dire che i CMS usati ad esempio per i blog consentono ad un utente non esperto di creare pagine web in XHTML + CSS, che renderizzano correttamente i contenuti. Ciò sarebbe stato difficilmente ipotizzabile con tecnologie di 5 anni fa, tanto per fare un esempio. D'altro canto avere dei browser che oggi sono in grado di comprendere perfettamente un tag h1 con il relativo CSS, consente alle persone di evitare di rendere lo stesso contenuto con una serie di tag p, font e quant'altro: in altre parole consente di organizzare le pagine semanticamente.

Per i CMS mi hai convinto, e d'altronde dubito ci si possa spingere molto oltre con la semantica in quel contesto.

Quanto a google però il fatto che generi l' XHTML tramite XML (come spieghi sotto ad Andrea) per me è irrilevante: se voglio estrarre informazioni dalla ricerca devo farmi un bel po' di parsing, e difficilmente otterrò un risultato affidabile.

Senza il problema della compatibilità all' indietro potrebbe spedirmi l' XML risparmiando un sacco di banda e di CPU sui suoi server, qualcosa di concettualmente simile a questo (primo esempio capitato a tiro).E più ancora che da Google mi piacerebbe avere risposte simili da siti tipo IMDB, skyscanner o Venere.

So che XML è molto usato nei backend e nelle interfacce intercompany, ma credo che ci si potrà davvero divertire se e quando cominceremo a vederlo sul frontend.

Concordo al 100% con quanto hai detto: l'esempio che avevo riportato serviva solo a ricordare come in verità certi concetti siano usciti dai laboratori. L'XHTML è solo il primo passo: guarda un po' quanto si è fatto in termini di nuovi tag semantici sull'HTML 5 (qui trovi un articolo dell'IBM a riguardo, con un esempio chiarificatore); altri tag sono stato introdotti per tentare di superare l'annosa questione della proprietà intellettuale sui codec (tema caro a Michele Boldrin): su quest'ultimo aspetto pare che la battaglia sia persa (o, comunque, non vinta del tutto).

Purtroppo pare che IE6 abbia ancora il 20% del mercato, e addirittura il 40 di quello corporate.

Per la mia esperienza i sistemi corporate spesso dipendono da interfacce activex molto delicate, aggiornare il browser è un lavoraccio.

Purtroppo sì e dipende quasi esclusivamente dai sistemi corporate. Personalmente se mi chiedessero di progettare oggi un portale general purpose che deve andare in rete tra 6 mesi direi al mio web editor di escludere il supporto ad IE6; e, se la data va spostata di qualche mese in avanti, farei qualche pensierino anche ad escludere IE7.

IE6 crollerà verticalmente entro fine anno; intanto i grandi portali per la distribuzione dei video stanno già sperimentando i nuovi tag HTML5 con OGG come riportato qui (nei commenti qualcuno fa notare che anche youtube sta cominciando). Insomma, forse quella speranza di Michele sui brevetti smetterà di essere utopia (almeno per l'audio / video).

IE6 crollerà verticalmente entro fine anno

Non credo, almeno in ambito corporate.

Qui siamo sul mio terreno: ho visto un sacco di interfacce utente fatte in HTML+activex integrate in un'applicazione (stile Norton antivirus per intenderci), ed un sacco di applicazioni custom fatte con librerie oscene che funzionano solo con IE6 (ad esempio i primi framework SAP avevano questi problemi). Prima di aggiornare IE devono adattare tutte 'ste cosette, quando va bene basta aggiornare qualche pacchetto (e in ambito corporate costa), quando va male riscrivere applicazioni funzionanti basate su framework obsoleti (di regola, anni uomo di sviluppo).Quando gli amministratori sanno il fatto loro spesso fanno un piano dal semestrale al pluriennale per questo genere di upgrade, e non di rado viene cassato perchè costoso.

Convincere piccole aziende e privati all' upgrade è facile perchè non hanno grandi costi da affrontare, per le grandi aziende è complicato.

Per nfa IE6 ha una share appena sotto al 10%

Quanto a google però il fatto che generi l' XHTML tramite XML (come spieghi sotto ad Andrea) per me è irrilevante: se voglio estrarre informazioni dalla ricerca devo farmi un bel po' di parsing, e difficilmente otterrò un risultato affidabile.

Per evitare web scraping c'e' OpenSearch, che con varianti e' supportato da diversi motori di ricerca tra cui Yahoo, e vari protocolli RESTful proprietari (pes., quello di Google e' documentato qui).

Yahoo sta anche promuovendo per le sue API l'uso del protocollo JSONP, che contrariamente a XHR permette di operare cross-site, p.es. mettendo il codice JavaScript su un sito (o anche il disco del client acceduto con URL "file:") e scaricare i risultati da un'altro sito senza dover fare proxying. E in JavaScript il parsing del formato JSON e' molto piu' facile di quello di XML.

PS. il anche vostro sito é in XHTML (anche se non passa la validazione) 

Premetto che mi occupo di altro (Economics) e seguo queste cose solo in modo amatoriale :) ... voglio precisare che è pressoché impossibile avere un sito con XHTML che passa la validazione e allo stesso tempo aperto a contributi di lettori che fanno copy/paste da altri siti (che hanno a cuore XML come i cavoli a merenda) nei commenti, o collaboratori che inseriscono, spesso, articoli incollati da documenti word  (curioso osservare un caso recente in cui word ha inserito kilobites di codice "nascosto" all'inizio dell'articolo rendendo la homepage semi-invisibile a chi la aprisse con alcune versioni recenti di internet explorer). 

Non voglio iniziare una diatriba sull'uso di XML, ma la home page di google e' in HTML, so what? A cosa servirebbe XML/XHTML in quel caso, se non a sprecare risorse (bandwidth) in modo inutile? Il punto che voglio fare è che XML/XHTML non è la lingua della bibbia o di dio, e serve ad uno scopo preciso: facilitare lo scambio di dati e l'interoperabilità fra diversi siti. Questo però non è lo scopo primario della homepage di Google ne' di nfa, quindi non cerco scuse se il sito non è costituito al 100% da xhtml valido. Renderlo valido comporterebbe l'uso, anzi, lo spreco, di risorse che non abbiamo. Per quanto mi riguarda, l'interoperabilità fra nfa e altri siti si fa tramite rss feed. Se il feed non è xml valido, avrei piacere di saperlo, ma credo lo sia, quindi per quanto mi riguarda sono a posto con la coscienza. 

 

Per la verità riuscire a rendere compatibile almeno la parte riguardante il contenuto dell'articolo non è difficile. Per i commenti ci sono degli editor WYSIWYG che consentono anche di "pulire" i copia e incolla da Word (o Writer, per par condicio): il che vale anche per i collaboratori che scrivono articoli.

La home page di Google è in HTML perché deve essere visibile da TUTTI: quindi usa tecnologie vecchissime, cosa che può sembrare strana visto che Google è all'avanguardia sul web. Per nfa direi che lo scopo è proprio quello di fornire contenuti fruibili e semanticamente strutturati; per di più ad esempio questa pagina non passa la valdazione XHTML principalmente perché c'è una doppia apertura del tag p.

Per il discorso RSS feed concordo: del resto un domani, forse, avremo strumenti che ci faranno capire perché è importante che anche i nostri articoli debbano essere semanticamente strutturati; oggi con gli aggregatori RSS abbiamo capito una parte dei vantaggi. Domani potremmo capire lo stesso per il contenuto degli articoli.

Per i commenti ci sono degli editor WYSIWYG

Certo che ci sono, e noi usiamo uno di questi. Che poi siano facili da inserire, funzionino in tutti i casi, etc... altro paio di maniche. Queste sono le risorse che non abbiamo di cui parlavo. 

Riguardo la struttura semantica, il problema e' il rapporto costi (che sono tutti miei) e benefici. Sinceramente, davvero e' la fine del mondo che uno usi <b>  invece che <strong> E quali sarebbero i mille vantaggi dell'usare header tags come <h1> piuttosto che markup visuale? E non sono tutti problemi risolvibili programmaticamente. Alcuni si', sono d'accordo. Ma se un browser attuale riesce a prendere questa pagina con i suoi due <p> iniziali e renderla correttamente, perche' non ci dovrebbero riuscire browsers e crawlers futuri?

Quanto a xml, io sono convinto che sia un obbrobrio pazzesco; mi correggo: penso che pensare di catalogare tutto lo scibile in xml sia un'idea obbrobriosa. Per certi scopi e' molto utile, ma col senno di poi si sa che c'erano (ci sono) soluzioni meno pesanti. Oramai ce lo teniamo, ma non insisterei che vada usato sempre e in tutti i casi. La pagina di google va benissimo cosi' com'e', e non solo perche' e' compatibile con browsers antichi. 


<em>

<em>

Certo che ci sono, e noi usiamo uno di questi. Che poi siano facili da inserire, funzionino in tutti i casi, etc... altro paio di maniche. Queste sono le risorse che non abbiamo di cui parlavo.

No, scusa, io vedo un pulsante di "Clean messy Code": esistono altri editor che hanno proprio la funzione di "Incolla da Word" che funzionano di sicuro, li ho anche usati in alcuni CMS che ho progettato e implementato.

Riguardo la struttura semantica, il problema e' il rapporto costi (che sono tutti miei) e benefici. Sinceramente, davvero e' la fine del mondo che uno usi <b>  invece che <strong> E quali sarebbero i mille vantaggi dell'usare header tags come <h1> piuttosto che markup visuale? E non sono tutti problemi risolvibili programmaticamente.

E' un problema se vuoi suddividere il contenuto dalla presentazione: il tag b che è deprecato anche nel futuro HTML5 serve per rendere il testo in grassetto, quindi non ha nulla a che fare con la semantica della frase. Il tag strong, invece, serve a dare forza a ciò che è in esso contenuto: per browser visuali esso equivarrà ad un grassetto (o ad altro: dipende da come lo imposti nel css). Nei browser vocali sarà "renderizzato" con una voce narrante più forte. Analogo discorso vale per l'h1 (per altro presente anche in HTML): posso rendere lo stesso effetto grafico con un p o uno span con una serie di attributi che faranno sì che il testo in esso contenuto sia grande, in grassetto e avrà una buona spaziatura. Ma perderò il contenuto semantico: quello che è racchiuso nel tag h1 è il titolo principale della pagina.

Alcuni si', sono d'accordo. Ma se un browser attuale riesce a prendere questa pagina con i suoi due <p> iniziali e renderla correttamente, perche' non ci dovrebbero riuscire browsers e crawlers futuri?

Giusta osservazione: la verità è che lo scopo dell'XHTML è tentare di avvicinare verso l'XML e verso una maggiore separazione tra contenuto e separazione; tentare di avvicinare i produttori di contenuto al concetto che la pagina vada semanticamente organizzata.

Quanto a xml, io sono convinto che sia un obbrobrio pazzesco; mi correggo: penso che pensare di catalogare tutto lo scibile in xml sia un'idea obbrobriosa. Per certi scopi e' molto utile, ma col senno di poi si sa che c'erano (ci sono) soluzioni meno pesanti. Oramai ce lo teniamo, ma non insisterei che vada usato sempre e in tutti i casi. La pagina di google va benissimo cosi' com'e', e non solo perche' e' compatibile con browsers antichi.

Boh, sono opinioni personali; un linguaggio di mark up vale un altro, l'importante è arricchire sempre più i contenuti con tag che consentono di organizzare lo stesso in maniera semantica; uno degli obiettivi dell'HTML5 è anche quello. Ad oggi la tecnologia c'è, è sviluppata ed assestata e l'XML viene usato per fare di tutto. In verità ti dico che, a parte la prima pagina, Google è non solo tutto in XHTML, ma è tutto in XML + XLS. Solo che la trasformazione viene fatta dai server di Google in XHTML. Te lo dico perché, essendo il gestore di un noto portale della PA, ho avuto la possibilità di vedere in azione e configurare il motore di ricerca di Google: quando effettui una ricerca il risultato ti è fornito in XML e viene traformato in XHTML attraverso un XLS dal server di Google, che tra l'altro ottimizza anche in base al borwser che usi.

Che editor hai usato scusa? Noi usiamo tinymce, e ha anch'esso un funzione "paste from word", che pero' ho tolto perche' , primo, funzionava a seconda delle versioni, secondo, la gente non la usava mai. Potrei reinserirla, mi dicono l'editor viene aggiornato abbastanza frequentemente, ma si tratta tutti di costi, in termini di tempo, che preferisco usare per scrivere, o giocare con mia figlia, visto che il sito cosi' com'e' funziona benone, a parte i commenti che oramai vorrei venissero caricati dinamicamente. Cio' di cui veramente avremmo bisogno e' un grafico che ridisegnasse il tutto. 

Anch'io sono concettualmente molto a favore di xhtml e markup semantico, ma tutto ha un costo.  

Dovrei andare a memoria: mi sembra FCKeditor, ma potrei sbagliarmi (l'ultima volta che me ne occupai risale al 2005, ma so che continua ad essere usato; ricordo anche che all'epoca non funzionava con Opera).

Concordo pienamente con il discorso dei costi; e anche con quello sul restyling grafico: le pagine sono troppo larghe e si fa fatica a leggerle: purtroppo sono un ingegnere e la grafica decisamente non è il mio mestiere. Un'altra cosa che mi pacerebbe avere è la possibilità di capire quando un commento è già stato letto dall'utente (almeno se si è loggati). Quando le discussioni diventano parecchio corpose diventano difficili da seguire (ok, mi fermo perché siamo davvero OT).

Le pagine sono resizeable, quindi la scelta di quanto larga fare la pagina e' tutta tua. Una misura dei commenti gia letti ce l'hai nella homepage dal blocco ultimi commenti. Se sei loggato, appaiono in arancione i commenti apparsi dopo che hai caricato la homepage l'ultima volta (se la differenza di tempo e' maggiore di 15 minuti). 

Easter eggs

luigi pisano 21/5/2009 - 10:43

Ovviamente è già partita la caccia alle Easter eggs... cose tipo "To be or not to be?", "what's the meaning of life?", "hello", etc...  :o)

XML

michele boldrin 21/5/2009 - 16:43

Temo che una delle ragioni per la lenta diffusione/adozione di XML siano problemi di questo tipo. Questa volta il brevetto ha punito MS, di solito va dall'altro lato. Ma, be it as it may, l'effetto si vede.

Re: XML

marcello urbani 21/5/2009 - 17:40

Sui brevetti siamo d'accordo, ma non credo contino molto in questo caso: la tecnologia rilevante è stata pubblicata da W3C anni fa, XML è abbastanza neutrale alla questione, tranne per il fatto che promette molto da anni e probabilmente un sacco di gente si è affannata a brevettare l'acqua calda per poter poi denunciare qualcuno che ci si lava.

Volevo solo segnalare che c'é un nuovo add on per Firefox che permette di visualizzare i risultati di una query su Google e Wolfram Alpha sulla stessa pagina contemporaneamente.

Inoltre se qualcuno e'interessato a dati riguardanti l'America, c'e' un nuovo sito mi sembra molto promettente: www.data.gov

Inizia una nuova discussione

Login o registrati per inviare commenti