GruppoImola

Prendo spunto da una intervista a Tim Berners Lee fatta da un giornalista di Talis, per commentare alcune frasi sparse estratte dal transcript e raccordarlo con le nostre attivita’ sul Semantic Web.

Dal transcript dell’intervista del 7 febbraio 2008 a Tim Berners Lee da parte di Paul Miller di Talis.

TBL chiarisce innanzi tutto il campo di azione del Semantic Web, che viene spesso visto come “estrazione di concetti dai testi”, cosa vera ma non rappresentativa ne’ esaustiva, ed indica che l’associare i dati (testi o dati nel senso piu’ largo) ai concetti  chiave di un’azienda o di un mondo piu’ largo puo’ essere utile e praticabile con profitto in moltissime situazioni diverse per scopi diversi. Cito:

“I think the Semantic Web is such a broad set of technologies and is going to do so many different things for different people. It is really difficult to put it on one thing. What are the steps necessary right now for the life sciences community to be able to use it for their data about proteins is probably different from which steps do we need to be able to get interoperability between repositories of library data and museum data.”
C’e’ poi una frase che mi fa particolarmente felice, perche’ conferma la visione che in Gruppoimola abbiamo sempre avuto delle tecnologie semantiche, che abbiamo interpretato come un vantaggio immediato nell’integrazione intelligente di forme diverse di dati, che permette di integrare dati da fonti diverse secondo una logica comune. Abbiamo usato queste tecnologie per integrare dati provenienti da repository diversi (file system, WebDav, blog, wiki, database) e permetterne navigazione, ricerca, elaborazione e modifica in ambienti diversi da quelli in cui i dati risiedono fisicamente, come ad esempio applicazioni e portali. Ecco la frase:

“So the Semantic Web is about integration, it is like getting power when you use the data, it is giving people in the company the ability to do queries across the huge amounts of data the company has.”
Si accusa poi di un errore nella comunicazione riguardo a cosa il Semantic Web sia, dicendo che sarebbe stato molto piu’ veloce da comprendere se avesse detto che era un approccio per la “enterprise and intra-enterprise data integration” , che e’ esattamente la visione che abbiamo praticato da quattro anni a questa parte:

“….I think, that really what we have… the message has been… it was looking too far into the future. ….
… the gain from the Semantic Web comes much before that. So maybe we should have written about enterprise and intra-enterprise data integration and scientific data integration. So, I think, data integration is the name of the game. That’s happening, it’s showing benefits. Public data as well; public data is happening and it is providing the fodder for all kinds of mashups.
So, what we should realize is that the return on investment will come much earlier when we just have got this interoperable data that we can query over.”
E alla domanda di che libro dovrebbe scrivere ora, dopo la strada gia’ fatta dalle tecnologie semantiche, cioe’ di quale e’ l’argomento da fissare e organizzare, dimostra di nuovo di essere sui nostri stessi binari, parlando esplicitamete di architettura con cui il Semantic Web si deve integrare con il resto dell’esistente:

“I would like to write a whole bunch of technical books about actually practically how to do Semantic Web things. I’d like to write a book about Semantic Web Architecture. And I’d like to write a book sort of painting the path for people in the industry, because I get a lot of questions along the lines of “OK, I read the specs, OK, but here I am, I am the CIO of a company, what does it mean for us now, what should we do?”"
Non casualmente ci siamo gia’ occupati di questo argomento e ne parliamo al JavaOne.
Il tema e’ una architettura standard di integrazione per produrre metadati e dati semantici al fine di produrre semantic web e semantic integration.

TBL enfatizza piu’ volte che non vanno creati nuovi dati in forme nuove per avere il Semantic Web: il modo di trarre vantaggio dal Semantic Web c’e’ gia’ adesso e sta nell’utilizzare dati che gia’ esistono in forme eterogenee, e’ nell’integrazione dei dati attuali, presenti nei database, nei file system, nei dati interni delle applicazioni (CRM, ERP, sistemi documentali, wiki, blog, etc.):

“So, where is the data going to come from? It’s already there. It’s in databases. So, most of this data is in databases. Often the data is already available through some kind of a Web interface.”

C’e’ un punto dell’intervista in cui TBL si sofferma sul modo in cui si produce l’RDF (cioe’ il dato standard semantico a fronte del dato proprietario nel database), che ci porta proprio sul caso d’uso dei componenti JBI per il Semantic Web, soluzione che supera la via che TBL propone, e che secondo me e’ incongruente con la visione si architettura semantica detta sopra, perche’ troppo legata alla scrittura custom di codice:

“…. Well, there’s a couple of ways of doing it. Say that you’ve got a database-type website. One way to do it is to look at it… let’s stay with the printers, for example. When you look at the website you notice there’s a page on the printer, which has got the specifications, and it’s got a little table of the properties of the printer. And there’s a PHP script somewhere, which produces that.
So, you get somebody who understands these things to write another PHP script which is totally parallel, which just expresses the same information in RDF. That’s all. “

Lo scopo dei nostri BC JBI e’ proprio quello di non dover scrivere quel codice ma di configurare il componente sull’ESB perche’ cio’ avvenga automaticamente quando si inseriscono, modificano o cancellano i dati sul database o nel repository proprietario, creando cosi’ una architettura di integrazione semantica.

Commentero’ successivamente la seconda parte dell’intervista, che e’ lunghissima e densa di argomenti interessanti da approfondire.

Claudio Bergamini

Ora e’ ufficiale. Ci e’ stato approvato lo speech al JavaOne 2008 (a San Francisco il 6 maggio) sui nuovi Binding Component JBI per il Semantic Web.

Sono componenti che partendo da metadati proprietari producono strutture standard semantiche (FOAF per le persone, DOAP per i progetti, etc.). Sono un punto chiave per integrare in architetture SOA, ed in particolare Enterprise, dati interni ed esterni anche in grossi volumi ed all’interno di processi applicativi esistenti.

Non possiamo ancora rivelare troppo di questi progetti ma maggio non e’ poi cosi’ lontano.

Questo progetto e’ il risultato dello sforzo congiunto di Imola Informatica e SensibleLogic, cioe’ tra la visione architetturale enterprise e la ricerca sulle tecnologie semantiche.

Grazie a Raffaele Spazzoli, Christian Morbidoni, Giovanni Tummarello e Michele Barbera per aver fornito idee e supporto per arrivare a questo risultato.

Finally the submission was approved. Raffaele Spazzoli from Imola Informatica will speak in JavaOne 2008 on Tuesday May 6, 2008 about a running project:

Enabling semantic web technologies with JBI. Here is the abstract.

Semantic web is a way to represent and manipulate informations that allows very high flexibility on the way the information are aggregated, accessed and presented. To leverage existing information base we need ways to get these information and translate them into a semantic form. There many standard ontologies broadly accepted like FOAF (for representing person data and person relationships), DOAP (for representing project data), Dublin Core (for representing document data) etc…. The act of transforming information from a proprietary format to a semantic representation is called RDF-alization. An ESB JBI can be the right integration middleware to perform this task because it can easily collect data in proprietary format from different sources and, by redefining RDF-alizers as JBI component, can feed semantic web enabled application.

For the Semantic Web guys JBI (Java Business Integration) is a Java Standard for Enterprise Service Bus pltforms supported by Sun, Apache, Oracle, JBoss etc. for Service Oriented Integration. Imola is already releasing a series of JBI components: JBI4cics, JBI4corba, JBI4esb included or certified for Sun OpenESB, Apache ServiceMix, and working in all the JBI compliant ESBs.

Follow this track: this is an important step to introduce semantic standards and technologies in the current Enterprise Architectures!

Dall’ ISWC 2007 International Semantic Web Conference di Busan, Korea, l’Invited Talk di Claudio Bergamini al Workshop “FIRST 2007 First Industrial Results of Semantic Technologies” dal titolo : “Introducing Semantic Web features in actual Enterprise scenarios”

Dall’evento di Sun Microsystem “Web 2.0 per le imprese” alla Pinacoteca di Brera, non solo Web 2.0 nello speech di Claudio Bergamini.

Il 3 Maggio e’ uscito su ZapThink, uno dei siti piu’ importanti che da anni fa l’advisor di quello che succede nell’IT industry su SOA, una ricerca molto interessante di Ronald Schmelzer che analizza le ragioni per cui l’adozione di SOA da parte delle aziende non abbia un boom come nell’epoca dot.com, nonostante non ci siano dubbi che questa strada sia da intraprendere con decisione.

La prima ragione e’ che riguarda le architetture, che sono una cosa difficile. La seconda che riguarda il modo in cui l’IT si comporta, nonostante i vendor cerchino di vendere il miracolo: “Despite how some vendors may portray it, you can’t just buy a product and expect it to miraculously create the Services you need and the agile architecture and organization to support them.“

E fin qui non c’e’ nulla di nuovo, e’ quanto si sta dicendo -inascoltati, peraltro- da anni.
Ma adesso viene il bello.

“What ZapThink is finding is that the primary barriers to SOA adoption do not come from business management, which by and large realize the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that), but rather from within the IT organization that resists the movement to SOA for a wide range of reasons — many of which have little relevance to the needs of the business. Even when a business has approved the investment of significant sums in their SOA projects, ZapThink has found that in many cases, their own IT organization can and will sabotage those efforts, slowing the SOA drive to a crawl.“

Perche’ e’ “IT – The Primary Barrier to SOA Adoption?“, si domanda la ricerca, se i principi di SOA sono tuttaltro che nuovi, ed escono come Best Practice proprio dalla storia dell’IT. Perche’ l’IT spesso riduce SOA ad un concetto solo tecnologico, cioe’ “IT practitioners see SOA as nothing more than Web Services and standardized middleware“. Questa convinzione e’ errata, perche’ SOA e’ “the mechanism by which Services are accessed with the architectural approach that aims to decouple the implementation from the consumption and focus on sustainable architecture that allows for continuous change, an approach that is completely technology agnostic.“

Il problema e’ che l’IT non vuole prendere in considerazione il cambio di cultura e di comportamenti che deve fare: “The move away from point-to-point integration to compositional, process-driven applications that consume Services from a broad array of assets across the enterprise requires development and management approaches based on Service domains rather than system-specific silos.“
Questo implica un modo diverso di fare IT, che deve spostarsi da “focusing on the short-term project management” a “meeting the long-term sustainable needs of the business as it changes“.
E’ nella lentezza con cui l’IT si sta rendendo conto e accettando questo cambiamento, che sta secondo la ricerca la ragione della lentezza nell’adozione di SOA.
La ragione di fondo della lentezza e’ la paura.
“All of these big movements require significant change and thus strike fear in the hearts of IT managers who find it easier to adopt one technology fad after another. It is precisely because SOA requires a fundamental change to the way IT is done that many see it as a threat.“
La ricerca spiega con dovizia di particolari le ragioni della paura, la negazione dell’inefficienza attuale, la convinzione di poter continuare come se nulla fosse cambiato, nonostante sia evidente che tutto e’ cambiato. E bolla l’atteggiamento degli IT cosi’:
”Of course, if companies solely managed by fear, we’d probably still be riding in horse-driven carriages. Innovation requires change, and change does not come without uncertainty.“

Le giustificazioni dell’immobilismo sono nella precaria professionalita’ e nel tentativo di mantenere le nicchie di potere professionale, minacciate dalla visione SOA. E’ una accusa molto dura.
“…. it seems to make obsolete their current skills“, “if someone is a mainframe expert, say, and SOA allows non-experts to build new applications that leverage all the functionality that previously could only be accessed using system-specific knowledge, then it makes sense that they would oppose the SOA movement“, sono affermazione che fanno da corollario al concetto che se la professionalita’ di qualcuno consiste nel saper dominare argomenti complessi, allora SOA che ha come effetto di semplificare e togliere i lock alle parti “tightly-coupled and inflexible”, viene ostacolata.

La tendenza a mantenere le cose complesse, dicendo che lo sono intrinsecamente e quindi non sono semplificabili, e’ giustificata solo dal voler mantenere lo status quo. In realta’ i sistemi sono piu’ complicati di quello che dovrebbero essere, per trascuratezza e conservatorismo:
“what is needed is a gross oversimplification because there’s no reason for the overly complex state of today’s IT“.
La ragione del voler mantenere le complessita’ sta nella autodifesa degli interessi obsoleti. Chi punta a questi obiettivi si oppone a SOA.

“Architects? We Don’t Need No Stinkin’ Architects“
Il negazionismo si appoggia sul propagandare una visione inattuale della architettura e degli architetti:
“Too many in IT also believe that architecture is not needed as a central and separate role from development or project management. These individuals feel that architects are theorists that pontificate from their Ivory Towers and make unfeasible recommendations without having to consider short-term time and budget limitations. For these folks in IT, the pervasive belief is that there’s time to do things over, but not do them right. After all, the business has never before invested in proper architecture and design, so why should they now?“

L’osservazione si allarga a questo punto alla organizzazione attuale di molti IT, antagonista dell’azienda.
“These organizations not only represent their IT systems as silos, but also segregate their management teams in system-focused silos as well. There is no incentive to share Services in an organization that separates budget and responsibility for individual projects in silos. Trying to build a shared Service that cuts across the domains of multiple systems as well as organizational hierarchy is potentially doomed for failure when issues of budget and control can’t be rectified. Such organizations not only need to adopt SOA from a technology and methodology perspective, but should also Service-orient their organizational structure.“
Il ruolo delle architetture e’ invece centrale:
” …and so architecture teams must have supervision, control, and responsibility for the outcome of the SOA efforts of the whole organization.“
“A functional IT organization empowers architecture groups with budget and authority. As further evidence of that, most CIOs are not performing the role they should be – as strategic managers of the architecture of the organization. …. The valuable CIO is one that sees and plans the strategic value of IT, leveraging SOA and enterprise architecture as the central mission of the IT organization as it provides continued benefit to the business as an asset, rather simply fighting fires and responding tactically, inflexibly, and imprecisely to the needs of the business, thus treating IT as a cost center.“

Mi sembra che questa considerazione trovi corrispondenza nella visione dell’IT cosi’ diffusa in Italia, ed e’ esattamente cio’ di cui tutti gli addetti IT si lamentano.
Quindi la conclusione e’ che non basta convincere il business ad adottare SOA, ma “companies need to address the latent resistance, hostility, resentment, and fear in the IT organization that will effectively prevent SOA adoption and success.“

Quindi i nemici sono in casa, e chi e’ causa del suo mal pianga se’ stesso.

Delphi, Visual Basic, Eclipse, NetBeans, MS Visual Studio… cosa hanno in comune ? Sono ambienti di sviluppo per la creazione di applicativi con uno o più linguaggi software che richiedono l’installazione sul proprio PC. Bene. E come definiamo quindi un ambiente di lavoro per la costruzione di applicativi business che non richiede né un linguaggio di programmazione né un IDE da installare sul proprio PC ? Coghead, l’ultimo nato in questa famiglia di strumenti per il Web Enterprise 2.0 viene definito da TechCrunch Online Application Building. CNNMoney.com lo include nella lista degli 11 Disruptors, ovvero nelle 11 compagnie che con le loro 11 nuove idee “will change everything”. Definizione a parte, analizziamo brevemente l’architettura, le potenzialità e la filosofia alla base di questo strumento.

Il primo impatto è abbastanza sorprendente: da anni siamo abituati a cercare il tasto download per poter prima scaricare e poi installare l’IDE. Obsoleto. Il tasto download, una volta registrati, diventa Launch Application; il Browser è l’ambiente di lavoro, ovvero, basta avere un PC e una connessione Internet per poter accedere ovunque ai propri progetti. Lo sviluppo di applicazioni è interamente basato sull’utilizzo di widget, ovvero componenti grafici (testo, date, combobox, tabelle etc ..) e relative proprietà. Ogni componente è parte di una Collection, può essere associato ad un modello di dati, e come tale richiamabile da altre Form. Ad esempio, la Collection Utente, ha il componente Nome, Cognome e Email. A questi dati, è possibile accedere da altre Form con la notazione Utente/Nome, Utente/Cognome etc. Per provare lo strumento, abbiamo costruito un semplice applicativo per la gestione dei consuntivi e delle note spese dei consulenti, creando una serie di Form collegate tra loro. Impressionante. Circa 30 minuti per imparare ad utilizzare lo strumento, seguendo pratici Tutorial ed alcune ore per il design, la realizzazione e il test

Tutto questo è molto interessante, ma sarebbe limitativo se finisse qui. Il prodotto sarebbe adatto solo per lo sviluppo di front end relativamente semplici, con un numero limitato di dati. Il vero punto di forza di Coghead è la sua predisposizione naturale verso la global SOA, ovvero l’integrazione dello strumento con i Web Services (dichiarato ma non attualmente disponibile nella beta preview cui abbiamo avuto accesso). La possibilità di integrazione del front end con i servizi SOA aziendali cambia notevolmente la natura e gli scenari di utilizzo dello strumento, collocandolo in una fascia di applicativi per l’Enterprise 2.0. Lo strumento diventa quindi un valido candidato per la realizzazione rapida di tutti quei servizi aziendali che non richiedono, per loro natura, un ciclo di sviluppo classico, e che hanno come requisiti velocità e bassi costi di realizzazione, accessibilità via Web e condivisione sicura dei dati.

Non vi sono ancora informazioni dettagliate sul modello di licenza di Coghead, e siamo ancora ad una versione abbastanza instabile del prodotto, ma se queste sono le premesse, www.coghead.com è sicuramente un bookmark da aggiungere alla top list, da monitorare attentamente nei prossimi mesi.

Coghead: mixup your mind !!

Per chi volesse provare il prodotto è opportuno avvisare che, per motivi di performance,l’accesso alla versione beta è ancora limitato. I nuovi account sono rilasciati con il contagocce, e possono intercorrere diverse settimane tra la richiesta e l’effettiva abilitazione.
La beta pubblica, aperta a tutti, dovrebbe essere disponibile in tarda primavera.

Yahoo! ha rilasciato l’altro ieri Yahoo! Pipes, una interfaccia per il visual editing e la manipolazione e la ricostruzione dei feed.

Yahoo! Pipes permette agli utenti registrati di Yahoo! di ricevere input e filtrare i risultati. Si puo’ prendere il feed di un filtro sui vostri bookmark di del.icio.us, aggiungere i vostri ultimi blog post, cercare le foto che si riferiscono allo stesso argomento e assemblare il tutto.

E’ fantastico il modo in cui l’interfaccia permette di usare moduli gia’ costruti da voi o da altri, di rendere quello che avete prodotto accessibile con JSON, RSS, Atom, condividere tutto, clonare i moduli che gia’ esistono ed in qualche modo vi possono essere utili.

Global SOA e’ sempre piu’ vera.

Non c’e’ dubbio che il 2006 sia stato un anno caratterizzato dalla nascita di una quantita’ di applicazioni web come non si vedeva da tempo. Centinaia e centinaia siti dedicati ad applicazioni originali, che vedono spesso la collaborazione con l’utente come arma per la creazione di contenuti, che diventano a loro volta la ragione di interesse al sito.
Tutto questo non sarebbe stato possibile senza il maturare della qualita’ dell’interazione dei siti web dovuti all’arricchirsi e all’affinarsi delle tecnologie Ajax, che stanno eliminando la barriera tra interfacce ricche proprietarie e le interfacce web.

Ogni giorno vengono annunciati e rilasciati decine di applicazioni nuove, ripetitive, nella speranza di ognuno di uscire dall’anonimato e diventare la “Next Big Thing”, prendere una montagna di soldi da una societa’ di Venture Capital per poi finire comprata da Google o Yahoo per cifre da sogno.

C’e’ una vivacita’ tale che si giustificano decini di siti che elencano classificano e qualificano quanto di nuovo nasce e quali applicazioni sopravvivono. Per chi volesse allinearsi un posto ideale sono i due siti craeti da Michael Arrington, Techcrunch e Crunchnotes, dove vi potrete fare una idea di cosa succede giornalmente. Qualcosa di simile viene fatto da Mashable, di Pete Cashmore.
Due si staccano per qualita’ tra gli altri nel classificare e gestire la lista aggiornata, ma sempre parziale, delle applicazioni Web 2.0: sono il celeberrimo eHub di Emily Chang e EVERYTHING 2.0 di Bob Stumpel.

Un tentativo carino e in stile Web 2.0, anche se meno ricco di contenuti e’ go2web20.

L’essere sulla notizia e’ fondamentale nei momenti in cui c’e’ un livello di effervescenza come quello attuale, e per questo ci sono i feed sul Wiki di Gruppoimola.

Una applicazione veramente accattivante mette tutti i feed caldi riguardanti WEb 2.0 su una pagina web, e’ l’ormai celebre Original Signal - Transmitting Web 2.0.

Rientro da SWAP2006.
Sicuramente un successo e una occasione per reincontrare persone interessanti.
Il Semantic Web continua a ricercare e crescere ma quest’anno ho visto una influenza “semplificatrice” che forse è frutto di quanto sta succedendo nel mondo Internet: Web2.0 e i Social Web stanno influenzando i progetti di Semantic Web dal punto di vista delle interfacce, del tentativo di arrivare a delle soluzioni usabili, di produrre open source di valore.
Ecco i Proceedings.

Personalmente ecco gli interventi che mi hanno più interessato:

Semantic Turkey di Donato Griesi, Maria Teresa Pazienza, Armando Stellato

The Rhizomer Experience, un Wiki Semantico presentato da Roberto García e Rosa Gil

The DODA Ontology: Lightweight Integration of Semantic Data Access Technologies di Christian Morbidoni, Giovanni Tummarello, Michele Nucci, Richard Cyganiak

di cui avrò modo di parlare in seguito.

E’ stata una bella occasione anche per parlare di futuro di Web 2.0 e Semantic Web con Danny Ayers (Flickr me!) , autore di Professional Web 2.0 Programming soprattutto nelle pause e davanti alla splendida cucina toscana. Spero di convincerlo a diventare un articolista di MokaByte.