Una piattaforma per servizi di KDD

Una piattaforma per servizi di KDD Claudia Diamantini, Maurizio Panti, Domenico Potena Università Politecnica delle Marche, Istituto di Informatica, via Brecce Bianche, 60131 Ancona, Italy {diamanti,panti,d.potena}@inform.unian.it Sommario La varietá degli strumenti e lo sviluppo continuo di nuove tecniche configura un sistema ideale di supporto alla progettazione di processi di KDD come un sistema aperto e modulare. Per raggiungere questi obiettivi, l articolo presenta l idea di un sistema di KDD come piattaforma, che sfrutta concetti e tecnologie sviluppati nell ambito della computazione cooperativa ed in particolare dei servizi web. 1 Introduzione Un processo di Knowledge Discovery in Databases (KDD) é un processo fortemente interattivo ed iterativo di manipolazione di dati con l obiettivo finale di ottenere in uscita un insieme di informazioni, precedentemente sconosciute, valide e potenzialmente utili [6]. Interattivitá e iterativitá dipendono dalla complessitá intrinseca del processo di scoperta, che é sostanzialmente di tipo goal-driven e domain dependent, e che pertanto é fortemente dipendente dall intervento umano. Un sistema di KDD pertanto deve essere pensato come un sistema di supporto alla progettazione di processi di KDD, che mette a disposizione dell utente un insieme di strumenti di base e un ambiente conveniente per il loro utilizzo. Affinché un sistema di KDD si configuri come un ambiente di progettazione conveniente, dovrá possedere le seguenti caratteristiche [8,5]: fornire ampia disponibilitá di strumenti diversi, per adattarsi a diversi domini, applicazioni, sorgenti; fornire un ambiente che permetta di gestire diverse versioni alternative di una soluzione, facilitandone la valutazione comparativa; fornire supporto sia ad utenti esperti che ad utenti inesperti, principalmente introducendo un livello concettuale di descrizione degli strumenti, rendendo il piú trasparente possibile i dettagli dell implementazione, e supportando le attivitá di scelta e di integrazione di tecniche differenti. La varietá degli strumenti e lo sviluppo continuo di nuove tecniche configura un sistema di KDD ideale come un sistema aperto e modulare, nel quale nuovi algoritmi e metodi possano essere introdotti all occorrenza. Inoltre, sono auspicabili caratteristiche di riusabilitá in quanto gli utenti del sistema non sono necessariamente esperti di implementazione e sviluppo. Modularitá, flessibilitá,

trasparenza e riuso sono le motivazioni dell introduzione di modelli computazionali distribuiti di tipo lascamente accoppiato, o cooperativo, che trovano nei Web Services l architettura di riferimento emergente [4,18]. Obiettivo di questo articolo é mostrare come il paradigma di interazione tra processi software descritto dall architettura a Web Service possa essere utilmente applicato ad un sistema di KDD, per trattare le problematiche di riusabilitá del software. Non ci occuperemo, invece, delle problematiche che sorgono quando le risorse sono fisicamente distribuite su una rete. Di conseguenza non verranno considerate componenti per l ottimizzazione delle risorse e per il trattamento di grandi quantitá di dati. Il presente lavoro trova i principali riferimenti nell ambito del Data Mining distribuito e dei Web Services. Nel primo ambito (si veda [13] per una rassegna sull argomento), sono state proposte diverse architetture per supportare applicazioni distribuite di Data Mining [3,9,14,11,12,17,2] le quali affrontano il problema da diverse prospettive. In particolare, [11,3,17] propongono sistemi che supportano il progetto e l inserimento di applicazioni personalizzate di data mining, e la loro combinazione in componenti piú complesse, utilizzando tecnologie ad oggetti. Inoltre, [17] utilizza un approccio di tipo dataflow simile a quello introdotto nel presente articolo per supportare la combinazione di componenti. Recentemente é stato proposto un sistema di KDD distribuito e parallelo che poggia sui servizi di un architettura Grid [2]. Quest ultimo approfondisce le funzionaltá per il trattamento di dati e operazioni su larga scala, mentre il presente lavoro pone l accento, oltre che sulla riusabilitá del software, anche sulla definizione di strumenti di supporto specifici alla progettazione di processi di KDD, quali la gestione dei dati intermedi, il versioning ed il controllo sintattico del processo. Le caratteristiche dei due sistemi sono tali da poter essere fuse anche alla luce della proposta OGSA [20]. La visione di modelli di data mining come servizi su Internet é introdotta in [19], al fine di facilitare l uso di tali tecniche ad utenti inesperti. Tale proposta riguarda tuttavia l uso di singoli modelli, in particolare di classificazione, mentre il concetto di piattaforma di servizi web per la progettazione di un intero processo di KDD é, allo stato delle nostre conoscenze, completamente nuovo. Nell ambito dei Web Services la direzione attuale di ricerca é quella di modellare i livelli superiori di servizio, che poggiano sul modello comunicativo fornito dall attuale tecnologia basata su XML. A tali livelli si affrontano le problematiche di composizione dei Service [7,16] e di interoperabilitá, tramite l introduzione di standard specifici [1,10] o tecniche di mediazione [15]. Nella piattaforma proposta nel presente articolo entrambe queste problematiche sono prese in considerazione, tramite l introduzione di funzionalitá per la gestione di workflow e tramite l introduzione di meccanismi per la omogenizzazione dei servizi. L articolo é organizzato come segue: nella sezione 2 si descrivono in dettaglio i requisiti richiesti ad un sistema di KDD proponendo una architettura di massima per soddisfarli. Nella sezione 3 tale architettura di massima viene specificata seguendo il modello dei Web Services. Nelle sezioni 4 e 5 vengono descritti i blocchi funzionali del sistema di KDD. La sezione 6 conclude l articolo. 2

2 Requisiti di un sistema di Knowledge Discovery in Database Seguendo [6], il processo di KDD puó essere suddiviso in 5 fasi principali: Selection, Preprocessing, Transformation, Data Mining, Interpretation/Evaluation. Ognuna di queste fasi raggruppa un insieme di attivitá omogenee: Selection: query su base di dati per selezionare il data-set di interesse; Preprocessing e Data Cleaning: filtraggio del rumore, eliminazione degli outliers, trattamento dei dati con campi mancanti, accounting di sequenze temporali; Transformation: riduzione della dimensione dello spazio degli osservati tramite proiezione (ricombinazione delle variabili) e analisi della distribuzione dei dati, individuazione di rappresentazioni invarianti dei dati; Data Mining: induzione di modelli tramite tecniche di Classificazione, Clustering, Regole associative, Regressione; Interpretation/Evaluation: rappresentazioni grafiche e tabellari dei risultati, rappresentazione simbolica dei modelli, creazione di report riassuntivi, valutazione di prestazioni. Ognuna delle attivitá elencate puó essere realizzata praticamente tramite diversi algoritmi, ad esempio l attivitá di classificazione puó essere realizzata tramite Support Vector Machines, Nearest Neighbor, C4.5 o altri. Infine, ognuno di questi algoritmi puó essere implementato in maniera differente sia dal punto di vista della logica di esecuzione, che del linguaggio, che dei dati in ingresso ed in uscita. L input/output di queste implementazioni si differenziano per sintassi e semantica, ovvero per il formato e per il loro significato. Da questa breve descrizione, si puó evincere la complessitá intrinseca della progettazione di un processo di KDD, dovuta ai numerosi gradi di libertá con cui l utente si trova a lavorare ed alla natura goal-driven e domain dependent del problema, che fa si che l utente di un sistema di KDD debba essere in grado di riconoscere gli strumenti piú adeguati per il proprio contesto, e possedere conoscenze tecniche per utilizzarli propriamente. Tuttavia, esso é tipicamente un esperto di dominio, ma non un conoscitore esperto di tutti gli algoritmi implementabili. É, quindi, auspicabile l introduzione di strumenti di supporto alla progettazione di processi di KDD, tali da garantire: trasparenza: rispetto alla implementazione, alla localizzazione e chiamata degli algoritmi e rispetto all accesso ai dati da analizzare, con la possibilitá di gestire una o piú basi di dati eterogenee e distribuite; flessibilitá: lo strumento deve gestire facilmente l introduzione di nuovi algoritmi, la modifica o la cancellazione di quelli esistenti. Deve gestire le possibili combinazioni degli algoritmi atte a formare il processo di KDD; riusabilitá dei componenti: favorire l utilizzo di algoritmi giá implementati senza modificarne il codice. facilitá d uso: proporre una interfaccia user friendly, preferibilmente di tipo grafico. É auspicabile che all utente i moduli appaiano come componenti di 3

un domino, in cui sia possibile comporre una sequenza usando, a partire da un dato modulo, solo alcuni tra gli altri moduli disponibili. In questo modo si garantisce la facilitá d uso presente nella maggior parte dei pacchetti software in commercio [5]. Inoltre, é auspicabile un supporto proattivo alla progettazione del processo, che gestisca i vincoli sulla concatenabilitá degli algoritmi e proponga prototipi possibili di processo; versioning/prototyping: con questo termine si vuole indicare la necessitá di tenere traccia degli esperimenti, gestendo in maniera efficiente i dati intermedi. Principalmente nell ottica della ricerca, é auspicabile che il sistema permetta di valutare le prestazioni ad ogni modifica dei moduli usati o del settaggio dei parametri. Figura 1. L architettura a Coordinatore. Di seguito, con il termine modulo indicheremo ogni componente software che implementi un algoritmo di KDD. D ora in poi, senza perdita di generalitá considereremo i moduli presenti in un unico repository. Per costruire un sistema di KDD, a partire dai moduli e rispettando i requisiti precedentemente esposti, é utile introdurre un architettura basata su uno strato software che si ponga ad un livello intermedio tra l analista ed i moduli stessi, che funga da coordinatore ed interprete. Tale modulo di coordinamento dovrebbe essere in grado di interrogare il repository, riconoscere e raggruppare i moduli presenti secondo le loro funzionalitá, rendere disponibili tutte queste informazioni all analista in forma comprensibile, tradurre il formato dei dati presenti nel DB nel formato di input dei moduli. L architettura che prevede questo modulo di coordinamento (il coordinatore) é schematizzato in Figura 1. Distinguendo il livello di coordinamento da quello dei moduli, si puó lavorare al fine di assicurare la flessibiliá e la riusabilitá. La presenza dell interfaccia grafica (GUI) tra il Coordinatore e l utente/analista garantisce trasparenza e facilitá d uso. Il soddisfacimento dei requisiti specifici, quali il supporto alla progettazione del processo ed il versioning, sará realizzato tramite l introduzione di funzioni specifiche del Coordinatore descritte nella sezione 4. 3 Dal WEB Service al KDD Service Per rappresentare l architettura a Coordinatore, in questa sezione analizziamo la corrispondenza tra le componenti funzionali di un sistema di KDD e quelle di una generica architettura a Web Service [4,18], che conduce all introduzione del concetto di piattaforma per servizi di KDD. 4

Una tipica architettura Web Service é costituita da tre unitá interagenti (come mostrato in Figura 2): Figura 2. Schema di un architettura basata su Web Service. Service provider, che creano i Service e li mettono a disposizione di altri utenti registrandoli presso i Service broker; Service broker, che contengono un registro dei Service pubblicati; utenti utilizzatori dei Service, che individuano i servizi a loro utili tramite i Service broker ed interagiscono con i Service provider in cui tali servizi si trovano. Questo modello computazionale si basa su tre tecnologie principali: Web Services Description Language (WSDL), Universal Description Discovery and Integration (UDDI) e Simple Object Access Protocol (SOAP). Il WSDL é un linguaggio che permette di fornire una descrizione astratta del Service e rende disponibili le informazioni sul tipo di protocollo usato, sulla posizione del Service e su come realizzare le interazioni tra le funzioni del Service. L UDDI fornisce le specifiche necessarie per la registrazione e la localizzazione del Service, tramite un elenco centralizzato di servizi, detto registro. Le informazioni consultabili nel registro sono di tre tipi: white pages: nome e dettagli per contattare il Service; yellow pages: informazioni sui Service divisi per categorie; green pages: informazioni riguardanti dati tecnici dei Service. Il SOAP, infine, é un protocollo basato su XML, che permette la comunicazione tra Service ed utente, e di effettuare chiamate alle procedure dei Service (Remote Procedure Calls, RPCs). Mostriamo, adesso, la corrispondenza tra le componenti dell architettura a Coordinatore e quelle dell architettura a Web Service. Per far questo, osserviamo, nell ambito dell architettura a Coordinatore, quali sono le interazioni tra le componenti principali: Coordinatore e moduli di KDD. Per prima cosa, il Coordinatore ricerca, tra i moduli disponibili, quelli richiesti dall utente e necessari alla costruzione ed esecuzione del processo di KDD. Successivamente alla localizzazione, deve attivare i moduli e gestire lo scambio dei dati di I/O degli stessi moduli. D altro canto, i moduli possono essere visti come singole procedure, messe a disposizione dagli sviluppatori, che descrivono le caratteristiche di funzionamento e di I/O. Possiamo quindi trattare, con riferimento alla Figura 5

2, il livello di coordinamento come un insieme di Service User e Service Broker, mentre quello dei moduli come Services. Nel precedente paragrafo, abbiamo detto che la riusabilitá é uno dei requisiti principali del sistema di KDD, che ci proponiamo di sviluppare. Ció significa la capacitá di utilizzare implementazioni sviluppate, in qualsiasi linguaggio di programmazione, e messe a disposizione da altri (sviluppatori come Service provider) senza modificarne o riscriverne il codice. Nell ipotesi che non esistano vincoli sul linguaggio di programmazione usato per la scrittura dei moduli, affinché essi possano essere visti come veri e propri Service, si vede la necessitá di introdurre un ulteriore livello tra il Coordinatore ed i moduli. Tale livello si occuperá di rendere trasparente al Coordinatore il linguaggio in cui il modulo é scritto, mostrandolo come un unico oggetto di un linguaggio object oriented. A tale livello, per ogni modulo di KDD sará pertanto introdotto un ulteriore elemento detto Wrapper. A questo punto, l insieme di modulo e relativo wrapper costituisce effettivamente il Service. Il sistema completo contenente lo schema a Coordinatore di Figura 1 ed il livello dei wrapper, definito secondo gli standard dell architettura Web Service, é denominato piattaforma per servizi di KDD (KDD Service). La Figura 3 mostra i blocchi funzionali dell architettura KDD Service e le interazioni tra essi. Nella prossima sezione descriviamo le compo- Figura 3. I blocchi funzionali dell architettura KDD Service. nenti principali del Coordinatore, mentre la descrizione dei Service é rimandata alla sezione 5. 4 I blocchi funzionali del Coordinatore In questa sezione andremo a sviluppare la descrizione del Coordinatore introdotta nel paragrafo 2. Per prima cosa preciseremo quelle che sono le funzioni che vengono richieste al Coordinatore, per poi descrivere i principali blocchi funzionali che si occupano di realizzarle e le interazioni tra essi. Presentiamo, quindi, un elenco delle funzioni che si richiedono al livello di coordinamento: 6

1. Interfacciarsi col G.U.I., per ricevere le richieste dell utente/analista e per presentare i risultati; 2. Interrogare il Repository per ricercare i Service disponibili, estraendo informazioni relative alla descrizione dei Service, alla localizzazione ed al modo in cui attivarli; 3. Supportare la costruzione del processo, fornendo all utente informazioni sui Service disponibili, sulle concatenazioni possibili e sui processi precedentemente conclusi; 4. Interrogare il database in cui sono presenti i dati da analizzare e quello in cui si trovano i dati relativi ad elaborazioni intermedie del processo attuale e di tutti quelli precedenti; 5. Tradurre il processo costruito dall utente in un workflow. Successivamente interpretarlo, quindi, verificare la correttezza sintattica ed attivare i Service necessari. A tale scopo il Coordinatore necessiterá di costrutti logici per la gestione del flusso delle istruzioni, quali quelli condizionali e quelli ciclici (sia definiti che indefiniti); Queste funzioni sono realizzate principalmente dal Workflow Manager (WFM), che interagisce con gli altri blocchi funzionali, rappresentati in Figura 3, che formano il Coordinatore: Service Broker, Link Generator, Versioning Manager e Query Manager. Il Service Broker si occupa di costruire il registro dei Service disponibili, tramite protocollo UDDI, a partire dalla descrizione astratta dei Service e relativa localizzazione. Tali informazioni sono rese disponibili dal Wrapper, che le traduce nel protocollo WSDL a partire da quelle scritte dai service provider (gli sviluppatori) nel file info, di cui tratteremo nel paragrafo successivo. Le informazioni contenute nel registro vengono utilizzate oltre che dal WFM, per valutare le concatenabilitá possibili tra i Service, dove due Service si definiscono concatenabili se l input del conseguente é una trasformazione di un sottoinsieme dell output del precedente. La valutazione delle concatenabilitá tra i moduli viene affidata al Link Generator, il quale elabora le informazioni contenute nelle Green Pages, relative alla sintassi e la semantica dell I/O dei Service, e ne memorizza i risultati nella Link Table. Il Versioning Manager é il blocco funzionale che si occupa della gestione dei processi giá eseguiti. Quest elemento ha due compiti principali: tenere traccia di tutti i processi andati in esecuzione e confrontarli con il processo che dovrá essere eseguito, per trovare sequenze in comune. Questi due obiettivi si raggiungono accedendo al Middle DB e rielaborandone i contenuti. Per interagire con le basi di dati, siano esse relative ai dati di origine o contenenti i dati intermedi, il WFM ed ilversioning Manager inviano query in un query language definito (ad es. SQL) al Query Manager. Questo blocco, si occupa di valutare la correttezza delle query e di eseguirne il codice. Per semplificare il numero di protocolli utilizzati per lo scambio di dati e per risolvere problemi di eterogeneitá, le basi di dati sono trattate esse stesse come Service. Ad esempio, mostriamo i passi per eseguire un semplice processo di classificazione tramite SVM, usando il software SVM light con un kernel RBF. Si assume che il WFM abbia estratto dalla descrizione WSDL gli operation del service (vedi 7

tab.1), sintassi e semantica dell I/O e dal Data Service lo schema dei dati (vedi tab.2). Tabella 1. service name operation name parameter data in data out SVM light SVM learn -t 2 -g 0.3 dbtrain svm model SVM light SVM classify svm model, dbtest svm predict Tabella 2. att1 att2 att3... attn 0.729195 0.542909... 1 0.638541 0.498543... 1 0.347722... -1 1. il WorkFlow viene passato in XML al Versioning Manager per estrarre informazioni su eventuali precedenti esecuzioni; < service >Data Service < operation name >Selection Query< /operation name > < input string >SELECT att1,att2,...,attn FROM...< /input string > < /service > < service >SVM light < operation name >SVM learn< /operation name > < input string >-t 2 -g 0.3 dbtrain svm model< /input string > < semantic input data map > < name >dbtrain< /name > < link > < metadata >att1< /metadata > < metadata >svm trainfile feature1 value< /metadata > < /link >... < link > < metadata >attn< /metadata > < metadata >svm trainfile classid< /metadata > < /link > < /semantic input data map > < /service >... 2. Il WFM legge la Link Table e verifica se é presente la sequenza (SVM learn, SVM classify); 3. Il WFM legge le Green Pages e traduce l input nel formato del primo operation da attivare, seguendo le associazioni semantiche create dall analista; 4. Il WFM costruisce il codice RCP-SOAP per inviare i dati di input ed attivare l operation SVM learn con, ad esempio, i parametri -t 2 -g 0.3; < SOAP : body > < m : SV M learn... > < input string xsi : type = xsd : string >-t 2 -g 0.3 dbtrain svm model < /input string > < file input xsi : type = xsd : string > 1 1:0.729195 2:0.542909 9:... 1 1:0.638541 3:0.498543 14:... -1 2:0.347722 12:0.364561 45:...... < /file input > < /m : SV M learn > < /SOAP : body > 5. Il Wrapper invia i risultati al WFM che li presenta all analista; 6. si ripetono i punti precedenti per l SVM classify; Per completare la descrizione della piattaforma, nel paragrafo successivo ci occuperemo dell ultimo livello, quello dei Service, ovvero delle coppie formate da modulo di KDD e relativo Wrapper. 8

5 I blocchi funzionali dei Service per il KDD Come giá discusso nella sezione 3, i Service sono costituiti da moduli software, scritti in un qualsiasi linguaggio di programmazione, incapsulati tramite Wrapper. Un Wrapper dovrá, pertanto, svolgere le seguenti funzioni: Prelevare dal modulo di KDD le informazioni utili alla descrizione, localizzazione ed esecuzione dello stesso; Fornire una descrizione in XML, seguendo il protocollo WSDL, del modulo a cui é associato; Creare una interfaccia per il WFM tale da rendere trasparente il linguaggio di programmazione scelto per implementare il modulo. In questo modo, il WFM interagisce con il Wrapper come con un generico Service. Gestire l esecuzione del modulo. Ció comporta la traduzione dei dati scambiati col WFM dal protocollo SOAP al formato previsto dal modulo di KDD e viceversa. Il Wrapper, pertanto, dovrá definire interfacce standard per moduli di KDD, a partire dalle informazioni sugli stessi moduli. A tal scopo, il Wrapper avrá bisogno di specifiche informazioni, di cui mostriamo un dettaglio: 1. informazioni di posizionamento: Nome del modulo; Posizionamento nel processo di KDD; Tipologia di algoritmo; Algoritmo implementato; Moduli opzionali concatenabili (tipico esempio é l approccio a wrapper per i moduli di Data Mining); 2. informazioni sull Input/Output: struttura dei dati in ingresso ed in uscita; semantica dei dati in ingresso ed in uscita; struttura e semantica dei valutatori di performance in uscita; messaggi di errore; struttura dei parametri del modulo; 3. informazioni sull implementazione: semantica dei parametri del modulo (con possibilitá di fornire valori di default e dominio di validitá); linguaggio di programmazione in cui il modulo é scritto; messaggi di errore di esecuzione; La soluzione proposta per recuperare queste informazioni é quella di accompagnare il singolo modulo di KDD con un file in cui esse siano contenute, la cui compilazione é a cura degli sviluppatori (i Service Provider). In Figura 4 descriviamo, nella notazione EBNF, una struttura di questo file (che chiameremo file info). In questa rappresentazione abbiamo diviso la parte relativa alla classificazione del modulo di KDD, le parti relative a Input e Output e quelle sull implementazione. L assioma < dependency > descrive i possibili moduli 9

Figura 4. Definizione del file info. strettamente concatenabili con quello rappresentato. Infatti, é possibile che vi siano moduli che necessitano di altri moduli per funzionare o che hanno moduli opzionali dedicati, come nel caso dei moduli di feature extraction dedicati a specifici moduli di Data Mining. Queste due realtá e ricombinazioni di esse, sono rispettivamente rappresentate dalle keyword FORCED e OPTION. In figura 5 é mostrato un generico esempio di concatenazione rappresentabile tramite l assioma < dependency >. Per quanto riguarda l Input/Output, nella struttura Figura 5. Concatenazione rappresentabile tramite l assioma < dependency > < dataio > e nelle strutture collegate, si possono leggere tutte le informazioni necessarie sui dati: tipologia del dato, range di validitá, valore di default, si- 10

gnificato, sintassi e posizionamento fisico. La forma in cui il dato si presenta in input, o in output, (<form>) é codificata nella notazione classica dell I/O del linguaggio C. Nel file info ci sono molte chiamate a < notes >, queste servono a descrivere la semantica dei dati ed il funzionamento del modulo. Infine, l assioma < language > contiene le informazioni sul linguaggio di programmazione. La precedente descrizione del file info per quanto sia dettagliata non vuole essere esaustiva delle possibili casistiche in cui ci si puó trovare nell eseguire un algoritmo di KDD. 6 Conclusioni L articolo presenta una piattaforma per la creazione, gestione, esecuzione e combinazione di processi di KDD. Le caratteristiche prese in considerazione sono principalmente quelle di: modularitá, riusabilitá, trasparenza, facilitá d uso e versioning/prototyping. Per soddisfare i primi di questi requisiti é stata studiata la corrispondenza tra le componenti funzionali di un sistema di KDD e quelle di una generica architettura a Web Service, che ha condotto all introduzione del concetto di piattaforma per servizi di KDD. Ció definisce il livello comunicativo di base della piattaforma, sul quale vengono costruite le funzionalitá specifiche del dominio. Tali funzionalitá riguardano la gestione del processo di KDD come workflow, i vincoli di concatenabilitá dei moduli, la gestione dei dati intermedi e dei processi eseguiti a supporto del confronto tra diverse soluzioni implementabili. Una caratteristica che differenzia la piattaforma presentata da una generica architettura a Web Service, é l introduzione dei wrapper nella definizione dei Service. Ció consente di definire interfacce standard per moduli di KDD scritti in qualsiasi linguaggio di programmazione, elaborando un semplice file di informazioni fornito dallo sviluppatore a corredo del modulo. Una struttura possibile per tale file informativo é discussa. Il contributo di quest articolo si inserisce nel filone di ricerca attuale sui Web Service, che vede come sviluppi significativi tutte le definizioni di standard ed interfacce per domini applicativi specifici e la definizione di modelli di workflow, tuttavia esso presenta solo una idea di massima. Tale idea dovrá essere ulteriormente sviluppata, tramite il progetto di dettaglio e l eventuale introduzione di funzionalitá non previste. Un primo prototipo del sistema é in fase di studio. Riferimenti bibliografici 1. W3C Web Services Workshop. April 2001. 2. Cannataro, M. and Talia, D. The Knowledge Grid. Comm. of the ACM, 46(1):89 93, Jan. 2003. 3. Chattratichat, J., Darlington, J., Guo, Y., Edvall, S., Koler, M. and Syed, J. An architecture for distributed enterprise data mining. HPCN Europe, 1999. 4. Curbera, F., Duftler, M., Khalaf, R. and Nagy, W. Unraveling the Web Services Web: an Introduction to SOAP, WSDL and UDDI. IEEE Internet Computing, pages 86 93, March 2002. 11

5. Elder, John and Abbott, Dean. A Comparison of Leading Data Mining Tools. In Proc. 4th Int. Conf. on Knowledge Discovery and Data Mining, Aug. 1998. 6. Fayyad, U. M., Piatetsky-Shapiro, G., Smyth, P. and Uthurusamy, R. Advances in Knowledge Discovery and Data Mining. AAAI/MIT Press, 1996. 7. Ganesarajah, Dinesh and Lupu, Emil. Workflow-based composition of Web- Services: a Business Model or a Programming Paradigm? In Proc. 6th Int. Enterprise Distributed Object Computing Conference, 2002. 8. Goebel, Michael and Gruenwald, Le. A Survey of DataMining and Knowledge Discovery Software Tools. ACM SIGKDD Explorations, 1(1):20 33, June 1999. 9. Grossman, R., Biley, S., Ramu, A., Malhi, B., Hallstrom, P., Pulleyn, I. and Qin, X. The management and mining of multiple predictive models using the predictive modeling markup language. Information and System Technology, pages 589 595, 1999. 10. Grossman, Robert, Hornik, Mark and Meyer, Gregor. Evolving Data Mining into Solutions for Insights: Data Mining Standards Initiatives. Communications of the ACM, 45(8):59 61, August 2002. 11. Kargupta, H., Hamzaoglu, I. and Stafford, B. Scalable, Distributed Data Mining using an Agent Based Architecture. In Proc. of Knowledge Discovery and Data Mining, pages 211 214, Menlo Park, 1997. 12. Krishnaswamy, S., Zaslavsky, A. and Loke, S. An architecture to support distribuited data mining services in e-commerce environments. In Proc. 2nd Int. Work. on Advance Issues of E-Commerce and Web-Based Information Systems, 2000. 13. Park, Byung-Hoon and Kargupta, Hillol. Distributed Data Mining: Algorithms, Systems, and Applications. In Nong Ye, editor, Handbook of Data Mining. Kluwer Ac. Pub., to appear. 14. Parthasarathy, S. and Subramonian, R. Facilitating data mining on a network of workstations. In P.Chan K. Kargupta, editor, Advances in distributed and parallel knowledge discovery, pages 233 258. AAAI/MIT Press, 2000. 15. Pires, P., F., Benevides, M. and Mattoso, M. Mediating Heterogeneuous Web Services. In Proc. 2003 Symposium on Applications and the Internet, 2003. 16. Preuner, G. and Schrefl, M. Integration of Web Service into Workflows through a Multi-Level Schema Architecture. In Proc. 4th Int. Work. on Advanced Issues of E-Commerce and Web-Based Information Systems, 2002. 17. Rana, O., Walker, D., Li, M., Lynden, S. and Ward, M. Paddmas: Parallel and Distributed Data Mining Application Suite. In 14th int. parallel and distributed processing symposium, pages 387 392, Cancun, 2000. 18. Roy, Jaideep and Ramanujan, Anupama. Understanding Web Service. IEEE IT Pro., pages 69 73, November 2001. 19. Sunita Sarawagi and Sree Hari Nagaralu. Data Mining Models as Services on the Internet. ACM SIGKDD Explorations, 2(1):24 28, June 2000. 20. Talia, D. The Open Grid Services Architecture: Where the Grid Meets the Web. IEEE Internet Computing, 6(6):67 71, Nov/Dec 2002. 12