Paper - Modelli di utente nel customized document delivery nel Web

Giovanni Randazzo – Com 97

Università di Scienze della Comunicazione

Indirizzo in Tecnologie della Comunicazione

Memoria di licenza

Modelli di utente nel customized document

delivery nel WebUn approccio rivolto al Semantic Web

René François Ghislain Magritte (1898 - 1967)

Relatore: prof. Marco Colombetti

Anno accademico 2000/2001

Giovanni Randazzo Modelli di utente nel customized document delivery nel Web pagina 2

0. Sommario1. Introduzione pp. 6-13

1.1. Obiettivi p. 7

1.2. Contributi originali p. 9

1.3. Piano del documento p. 12

2. I sistemi di customized document delivery pp. 14-26

2.1. Definizione e caratteristiche fondamentali p. 14

2.2. Una panoramica dei servizi disponibili p. 15

2.2.1. InfoCast p. 16

2.2.2. BackWeb p. 17

2.2.3. DataChannel p. 18

2.2.4. Marimba p. 19

2.3. SwissCast p. 20

2.4. Alcuni svantaggi dei sistemi descritti p. 24

3. Il progetto SwissCast2 pp. 27-47

3.1. Caratteristiche generali p. 27

3.2. Attori p. 33

3.3. Inserimento di un nuovo documento p. 35

3.4. Moderazione dei documenti p. 38

3.5. Registrazione di un nuovo IP p. 38

3.6. Modifica della struttura di classificazione dei documenti p. 41

3.7. Registrazione di un nuovo utente p. 42

3.8. Pubblicazione dei documenti e raffinamento dei profili p. 45

4. Modello concettuale e rappresentazione XML pp. 48-70

4.1. Definizione dei DTD p. 48

4.1.1. Rappresentazione dei documenti p. 49

4.1.2. Rappresentazione degli utenti p. 50

4.1.3. Rappresentazione degli information providers p. 54

4.2. Sistemi Terminologici p. 57

4.2.1. Specifica del formalismo p. 59


4.2.2. ST dei documenti p. 61

4.2.3. ST degli utenti p. 67

4.2.4. ST degli information provider p. 69

5. Implementazione di un prototipo dimostrativo pp. 71-82

6. Conclusioni pp. 83-86

7. Bibliografia pp. 87-90

Allegati pp. 91-170

A. Descrizione formale del progetto p. 92

A.1. Use case diagram p. 93

A.2. Sequence diagrams p. 94

A.2.1. Inserimento manuale di un nuovo documento p. 94

A.2.2. Inserimento automatico di un nuovo documento p. 95

A.2.3. Moderazione dei nuovi documenti p. 96

A.2.4 Accoppiamento (matching) documenti/utenti p. 97

A.2.5. Consultazione dei nuovi documenti p. 98

A.2.6. Processo di Data Mining p. 99

A.2.7. Modifica del profilo utente p. 100

A.2.8 Registrazione di un nuovo utente p. 101

A.2.9. Registrazione di un nuovo IP da parte del Director p. 102

A.2.10. Registrazione di un nuovo IP da parte dell’IP stesso p. 103

A.2.11. Moderazione dei nuovi IP p. 104

A.2.12. Modifica della struttura di classificazione dei documenti p. 105

A.3. Collaboration diagrams p. 106

A.3.1. Inserimento manuale di un nuovo documento p. 106

A.3.2. Inserimento automatico di un nuovo documento p. 107

A.3.3. Moderazione dei nuovi documenti p. 108

A.3.4. Accoppiamento (matching) documenti/utenti p. 109

A.3.5. Consultazione dei nuovi documenti p. 110

A.3.6. Processo di Data Mining p. 111

A.3.7. Modifica del profilo utente p. 112


A.3.8. Registrazione di un nuovo utente p. 113

A.3.9. Registrazione di un nuovo IP da parte del Director p. 114

A.3.10. Registrazione di un nuovo IP da parte dell’IP stesso p. 115

A.3.11. Moderazione dei nuovi IP p. 116

A.3.12. Modifica della struttura di classificazione dei documenti p. 117

A.4. Classi p. 118

A.5. Class diagram p. 119

B. Un esempio di rappresentazione per i sistemi terminologici: SHOE p. 120

B.1. ST dei documenti p. 122

B.1.1. Descrizione in linguaggio naturale p. 122

B.1.2. Ontologie estese p. 122

B.1.3. Categorie p. 124

B.1.4. Costanti p. 125

B.1.5. Relazioni p. 129

B.1.6. Inferenze p. 131

B.1.7. Codice SHOE p. 133

B.2. ST degli utenti p. 145








B.3. ST degli Information Provider p. 159









C. Prototipo esemplificativo di alcune funzioni del sistema CD-R


1. Introduzione

Cerbero, fiera crudele e diversa,

con tre gole caninamente latra

sovra la gente che quivi è sommersa

Li occhi ha vermigli, la barba unta e atra

e ‘l ventre largo, e unghiate le mani;

graffia li spirti, ed iscoia ed isquatra.

Dante, Inferno, IV 13-18

Sino a pochi anni or sono il paradigma Push come alternativa ai poco efficaci motori di

ricerca (quali AltaVista o Yahoo) per il reperimento di informazioni sul Web sembrava

destinato ad un grande successo [Kelly & Wolf 1997]. Ma i toni entusiastici degli inizi

si sono presto smorzati; il sempre più vasto e differenziato “popolo di Internet”

(109'574'429 host calcolati nel gennaio 2001 dal Internet Software Consortium,

http:\\www.isc.org) continua a tutt’oggi ad usare massicciamente i motori di ricerca

tradizionali per ricerche puntuali sulla Rete mentre non mostra un grande interesse per i

sistemi Push generalisti. Il successo del sistema SwissCast come servizio di

informazioni nel campo specifico della ricerca scientifica [Lepori et al. 2000] mostra

invece che l’utenza apprezza proposte orientate a domini specialistici ed ad un target

ben distinto. Nel caso di SwissCast il target sono i ricercatori scientifici operanti nella

Svizzera italiana. L’offerta è quella di informazioni di alta qualità e rilevanti per gli

interessi di ciascuno di loro.

Nonostante ciò, il problema più rilevante rimane quello del raggiungimento delle

persone interessate ad un determinato tipo di informazione; l’ostacolo, su una Rete

mondiale che promette l’Information Pointcast, sembra paradossalmente essere proprio

quello della personalizzazione dell’offerta data da questi servizi.


Il problema prende idealmente la forma di un “Cerbero a tre teste”. La prima è costituita

dalle tecniche di filtraggio dei documenti, che devono permettere una ricerca efficace di

qualsiasi tipo di dato (titolo, formato, autore, soggetto, ecc.) in modo automatico; le

attuali tecniche di analisi automatica dei testi non riescono a dare prestazioni accettabili.

La seconda testa è la rilevazione degli interessi dell’utente: da una parte un’acquisizione

di tipo implicita richiede grandi volumi di dati e tempi di elaborazione non sempre

compatibili con le esigenze del servizio; dall’altra lasciare che l’utente definisca in

modo esplicito i propri interessi rischia di creare profili troppo generici e poco efficaci.

La terza testa è costituita dal processo di accoppiamento o matching delle informazioni

con gli interessi degli utenti: i formati di rappresentazione dei documenti e dei modelli

dell’utente devono essere compatibili e consistenti e permettere una ricerca semplice e

veloce dei dati combacianti.

Il presente lavoro propone una soluzione integrata rivolta all’interoperabilità semantica

e che utilizzi dei sistemi terminologici come rappresentazione esplicita del significato

dei dati in un sistema quale SwissCast. Verrà mostrato in che modo questa impostazione

permetta di rappresentare con i medesimi strumenti sia informazioni sui documenti che

informazioni sugli utenti, di definire il profilo di interessi di un utente come un

“documento tipo” che rappresenti le sue necessità e di garantire una forma di

raffinamento automatico di tali profili.

1.1. Obiettivi

Gli scopi di questa memoria di ricerca nascono dall’esigenza di trovare dei sistemi più

efficaci e precisi che migliorino l’offerta data dai servizi di customized document

delivery attualmente presenti in Rete.

L’informazione viene acquisita dall’esterno; è obiettivo dichiarato del sistema

SwissCast quello di costituire un servizio di brokerage tra i fornitori di informazioni e

gli utenti. Il termine centrale è perciò condivisione dell’informazione. Ciò che

tradizionalmente è possibile fare con Internet è condividere dei dati attraverso dei

protocolli standard (HTTP, FTP od SMTP); tali dati costituiscono la forma grafica, la


“presentazione” di una risorsa elettronica, mentre il suo significato è comprensibile solo

in quanto i destinatari di queste informazioni sono esseri umani dotati (preferibilmente)

di intelligenza. Ma cosa fare se una simile risorsa deve passare attraverso un sistema

informatico che fa da intermediario con l’utente finale? È necessario che tali dati siano,

come si dice, machine understandable.

Su questo tema l’area di ricerca denominata Semantic Web ha sviluppato diverse

metodologie e proposto protocolli e linguaggi che permettano l’interoperabilità

semantica e la condivisione della conoscenza. L’idea principale consiste nel separare il

contenuto dalla sua presentazione, creando delle descrizioni del significato di una

risorsa processabili e distinte dalla sua forma grafica; per uno stato dell’arte sulle

ricerche nel campo del Semantic Web rimando a [W3C 2001b].

Gli obiettivi di questa memoria di licenza si rifanno dunque ad un’applicazione pratica

dell’idea di “Web semantico” che, se può sembrare un po’ utopistica se rivolta all’intera

comunità mondiale online, risulta verosimilmente attuabile per piccole comunità

specialistiche come quella dei ricercatori scientifici della Svizzera italiana. Per questo

motivo col presente lavoro ci si propone di riprogettare il sistema di rappresentazione

dei dati di SwissCast in modo che esso risulti facilmente processabile e machine

understandable. I requisiti del sistema saranno individuati attravero un’analisi

preliminare dei servizi di customized document delivery attualmente presenti in Rete,

analisi che permetterà di evidenziarne i difetti e di risolverne alcuni, evitando di crearne

di nuovi.

Il nuovo sistema, SwissCast2, ha come obiettivo il miglioramento del servizio sinora

offerto, in particolare per quanto riguarda il grado di definizione di documenti e profili

utente e la rilevanza delle informazioni fornite rispetto al profilo stesso. Un secondo

obiettivo riguarda la possibilità di condividere le informazioni del sistema con altri

sistemi disponibili sul Web; diversamente detto, si vuole far sì che altri sistemi di

information retrieval possano essere in un certo senso utenti di SwissCast2 e che a sua

volta SwissCast2 possa essere un loro utente. Lo scopo finale è dunque permettere

all’applicazione la condivisione della conoscenza, sia al suo interno (tra i moduli del

sistema) sia con sistemi esterni.


Un altro obiettivo di questa memoria di licenza è lo sviluppo di un formalismo che aiuti

a rappresentare graficamente la semantica relativa alla descrizione dei dati del sistema.

Tale formalismo dovrà essere semplice ed intuitivo, processabile da un calcolatore ed

universalmente comprensibile. Per far questo dovrà utilizzare uno standard che

costituisca una piattaforma unica per lo scambio di dati e di conoscenza. Il metodo di

rappresentazione sviluppato dovrà permettere di descrivere ugualmente i documenti ed i

modelli degli utenti in modo da permettere un matching efficace.

Un ultimo ed ulteriore obiettivo di questa memoria di licenza è costituito dallo sviluppo

di un piccolo programma dimostrativo per alcuni moduli di SwissCast2, che metta in

luce l’efficacia delle scelte fatte e la loro fattibilità. Non è però tra gli scopi del lavoro

fornire un prototipo completo del sistema, ciò che va al di là del livello a cui si vuole

portare la progettazione. Si descriverà infatti il progetto del sistema sia da un punto di

vista formale che in linguaggio naturale sino ad un livello di analisi dei contenuti.

Questa scelta è motivata dalla necessità di concentrarsi sul nucleo originale della

memoria, che come si vedrà nelle prossime pagine è costituito dall’uso dei sistemi

terminologici.

1.2. Contributi originali

Le “tre teste di Cerbero” descritte prima costituiscono tre aspetti del medesimo tema: la

condivisione di informazioni o (come dicono gli anglofili) il knowledge sharing. In

realtà con conoscenza non ci si riferisce solo all’informazione in sé ma al suo contenuto,

alla sua semantica, insomma all’informazione significativa.

Ci si è quindi concentrati in questo lavoro sulla rappresentazione del contenuto

informativo dei dati del sistema, con particolare attenzione alla loro forma logica. La

struttura che ne nasce si compone di tre livelli.

Ad un primo livello i dati (siano essi relativi ad un documento o ad un utente) vengono

descritti in un formato semplice, flessibile e riconosciuto come standard: si tratta di


XML1, il linguaggio di marcaggio per metadati proposto dal W3C2. L’uso di XML

permette la processibilità dei dati e l’utilizzo dei fogli di stile XSL3 per la

trasformazione automatica delle descrizioni XML in presentazioni HTML.

Nel secondo livello si trovano i DTD4 che assicurano che i documenti XML siano

conformi ad una grammatica comune, ciò che fornisce una sintassi; la semantica di un

DTD però rimane implicita e non può essere acquisita indipendentemente da strumenti

software. Lo scambio di documenti XML, insomma, funziona bene se le parti coinvolte

sono d’accordo preliminarmente du un DTD, ma diventa problematico quando si vuole

cercare attraverso l’intero set di DTD od integrare spontaneamente informazioni da

risorse multiple. Il problema della semantica è che progettisti impegnati a descrivere lo

stesso concetto possono farlo in modi diversi e con diversi termini. Si possono

individuare quattro tipi di domini di differenza [Heflin & Hendler 2000]: differenze di

terminologia (nomi differenti sono usati per gli stessi concetti), di scope (categorie

simili possono non combaciare esattamente, le loro estensioni si intersecano ma ognuna

può avere istanze che possono non essere classificate sotto l’altra), di codifica (valori

validi per una proprietà possono essere differenti e possono essere usate scale differenti)

e di contesto (lo stesso termine è usato per definire concetti completamente diversi).

È quindi necessario un terzo livello di descrizione, che fornisca delle rappresentazioni

formali della semantica dei dati; tali rappresentazioni, chiamate a volte ontologie, sono

qui definite come sistemi terminologici5.

Il nucleo originale di questa memoria di licenza consiste nel modo in cui tali

rappresentazioni sono state progettate e nell’uso particolare che ne viene fatto

all’interno di SwissCast2. Le ontologie sviluppate per l’uso nel Web, infatti, sono

spesso semplici set di termini (è il caso del Dublin Core6) o, nel migliore dei casi, di

1 eXtensible Markup Language [W3C 2000c]2 WWW Consortium (http://www.w3c.org)3 XML Stylesheet Language [Day 2000]4 Document Type Definition [W3C 2000b]5 Pur utilizzando per il momento i termini ontologia, terminologia e sistema terminologico come sinonimi

e in modo intuitivo, nel capitolo 4 ne verranno evidenzate le differenze6 http://www.dcmi.org


termini ordinati gerarchicamente in una struttura ad albero. Ma le esigenze del sistema

richiedevano qualcosa di più complesso e tuttavia ugualmente gestibile.

I sistemi terminologici che verranno proposti in questo lavoro sono perciò dei grafi

composti da nodi e da archi orientati, con etichette e cardinalità; ciò permette di definire

i termini usati per la descrizione dei dati attraverso relazioni complesse (non unicamente

gerarchiche) in una struttura che ricorda gli schemi Entity-Relationship delle basi di dati

o le reti semantiche usate in Intelligenza Artificiale. Queste rappresentazioni hanno due

particolarità che ne costituiscono il valore aggiunto: definizione di inferenze logiche e

riferimenti a terminologie esterne.

Il formalismo utilizzato per esprimere graficamente i sistemi terminologici, infatti, ha

permesso di definire anche delle regole generali di inferenza logica; ciò permette di

semplificare queste rappresentazioni, inserendo solo le relazioni fondamentali tra i

termini (e non necessariamente tutte quelle possibili) e lasciando al sistema il compito

di calcolare le altre attraverso le regole di inferenza, qualora sia necessario.

Come detto, il sistema è pensato per la condivisione della conoscenza. Volendo inoltre

evitare definizioni ricorsive o virtualmente infinite, ci si è limitati a definire i termini

negli schemi sino ai loro elementi di base (una stringa, un intero, una persona, ecc.); tali

elementi di base vengono poi definiti attraverso delle relazioni con sistemi terminologici

esterni a SwissCast2. Esistono infatti nel Web, come abbiamo visto prima, dei semplici

set di termini o delle ontologie, sia generaliste che specializzate per un determinato

dominio.

I sistemi terminologici di SwissCast2 si metterebbero dunque in un rapporto gerarchico

con queste terminologie, contribuendo alla creazione di una rete di conoscenza. Nasce

però a questo punto un problema di standardizzazione: non vi è infatti un accordo

globale sull’uso di un linguaggio standard per lo scambio di ontologie né vi sono

gerarchie standard a cui appogiarsi; per il momento ogni linguaggio (come nel caso di

SHOE7) ha una sua gerarchia che parte da un’ontologia di base generale che fornisce

alcuni concetti come “entità” o “relazione”. Esiste però un gruppo di lavoro della IEEE

7 Simple HTML Ontology Extentions [Heflin 1999]


che sta sviluppando la SUO8 che verrà proposta come radice standard di tutte le

gerarchie di ontologie presenti nel Web.

Si è detto che un secondo elemento di novità sta nell’uso che si fa dei sistemi

terminologici nell’applicazione SwissCast2. Rappresentare la semantica usata nella

descrizione dei dati infatti non serve solo negli scambi di informazioni verso l’esterno;

tali rappresentazioni sono infatti il punto centrale per lo scambio di dati all’interno del

sistema stesso. La semantica a cui ci si riferisce, infatti, non rimane implicita e

distribuita sull’intero sistema e nei suoi vari moduli, ma è centralizzata ed esplicita. Ciò

permette un’enorme flessibilità nella rappresentazione dei dati; ogni cambiamento nella

terminologia usata o nella struttura dei dati, infatti, si riflette solo sulla loro

rappresentazione e non richiede una riprogrammazione dei moduli del sistema, che ai

sistemi terminologici si riferiscono in modo dinamico.

1.3. Piano del documento

La presente memoria di licenza è strutturata in due parti principali: il corpo centrale del

lavoro e gli allegati. Tutto ciò che è stato posto nel capitolo degli allegati non è di

minore importanza rispetto alla parte centrale del lavoro; tutti i contributi allegati sono

infatti originali e fanno parte integrante della memoria. Si è però deciso di rendere la

descrizione principale più leggibile e non eccesivamente appesantita da schemi e codici.

Dopo questo capitolo introduttivo che riassume i temi principali della memoria di

licenza, il secondo capitolo propone un’analisi del concetto di customized document

delivery effettuato attrverso una panoramica su alcuni servizi attualmente disponibili nel

Web; in particolare si osserveranno i sistemi Infocast, BackWeb, DataChannel e

Marimba. Un’attenzione particolare verrà data al servizio SwissCast, ai suoi scopi, alle

soluzioni proposte ed ai suoi punti di successo. Un ultimo paragrafo sarà dedicato alla

8 Standard Upper Ontology IEEE P1600.1 (http://www.suo.ieee.org)


rilevazione dei difetti e delle debolezze dei sistemi analizzati nel capitolo;

quest’operazione permetterà di individuare alcuni requisiti che SwissCast2 dovrà avere.

Il terzo capitolo si propone di descrivere il progetto del sistema SwissCast2, con una

particolare attenzione alla struttura di rappresentazione dei dati; tale descrizione in

linguaggio naturale riprende le osservazioni fatte alla fine del precedente capitolo

proponendo una soluzione integrata ai difetti rilevati negli altri sistemi. Nel quarto

capitolo vengono presentate le vere e proprie strutture dei dati in maniera formale; in

particolare si fornisce il listato dei codici dei DTD e di un’esempio di descrizione di un

documento, di un utente e di un Information Provider; inoltre vengono presentati i grafi

dei sistemi terminologici relativi appunto ai documenti, agli utenti ed agli Information

Provider. Il quarto capitolo descrive invece il prototipo dimostrativo che è stato

implementato, con dettagli sulle funzioni sviluppate ed un piano completo e

commentato delle directory e dei file costituenti l’applicazione.

Dopo le conclusioni e la bibliografia (capitoli 5 e 6), l’ultima parte è dedicata agli

allegati che sono già stati citati. La sezione allegata contiene dunque la descrizione

formale in UML del progetto, in particolare con Use Case, Collaboration, Sequence e

Class Diagrams. Vi è poi un esempio di linguaggio in cui è possibile rappresentare i

sistemi terminologici; si è scelto SHOE in quanto fornisce una sufficiente espressività

per evidenziare le parti più importanti dei grafi presentati nel capitolo 4; i listati dei

codici SHOE sono corredati da commenti e descrizioni in linguaggio naturale. Infine,

viene fornita su un supporto CD-R la piccola applicazione dimostrativa di cui si è già

detto.


2. I sistemi di customized document

delivery

2.1. Definizione e caratteristiche fondamentali

Così come in molti altri casi, quando si parla di sistemi pensati per il World Wide Web,

sulla terminologia relativa ai servizi di cui si vuole qui parlare non c’è un accordo

unanime. In genere, comunque, quando si parla di customized document delivery si

intende quel tipo di servizio che mette a disposizione dei contenuti organizzati per

argomento ed assegnati in modo automatico a dei profili di utente. Attualmente vi sono

alcune applicazioni che rendono possibile la consultazione dei contenuti tramite la

notifica di nuovi documenti rilevanti, per esempio per mezzo della posta elettronica

(come in WebCast od in SwissCast) ed altre applicazioni che invece spediscono

direttamente i contenuti rilevanti agli utenti interessati. In quest’ultimo caso si parla di

servizi Push.

Concettualmente, l’invio automatico di informazioni può sembrare simile a ciò che

accade col più classico dei mass-media: la televisione. Anche nel caso dei sistemi Push

infatti, gli utenti finali non devono fare lunghe e noiose ricerche ma ricevono ciò che

viene loro inviato. Il valore aggiunto di questi servizi si concentra nei due fulcri

dell’organizzazione del contenuto e dei profili degli utenti.

Ogni informazione, infatti, può essere non solo selezionata, ma anche organizzata,

modificata, riutilizzata o conservata secondo le esigenze del sistema; l’utente riceve

sempre i contenuti con le stesse modalità ed in un formato omogeneo.

È inoltre possibile sfruttare le possibilità di interazione e di personalizzazione del

medium usato per permettere all’utente stesso di definire un proprio profilo di interessi,

modificarlo, iscriversi a canali tematici, dialogare col sistema, ecc.


Ma i sistemi di customized document delivery non sono puri e semplici strumenti

tecnologici che aiutano a trovare informazioni su Internet, o almeno non sono solo

questo. Chi fornisce questo tipo di servizio si ritiene infatti un vero e proprio broker, un

mediatore tra i fornitori di contenuti e gli utenti; si tenta infatti di colmare il divario

esistente tra i contenuti disponibili sulla Rete ed i bisogni degli utilizzatori della Rete

stessa. In questo senso si parla di information brokerage.

2.2. Una panoramica dei servizi disponibili

Tra le diverse soluzioni ideate nel mondo dei servizi di customized document delivery

sono individuabili tre diverse categorie [Cantoni et al. 1998]:

- filtered broadcasting: questi sistemi monitorano fonti di informazione, basi di

dati (d’ora in poi DB) od altre aggregazioni di contenuto ed estraggono elementi

che corrispondono a parole chiave (esempio: InfoCast)

- corporate channel broadcasting: è la soluzione più usata; gli information

providers che vogliono pubblicare le loro informazioni si appoggiano ad una

soluzione Push esistente e creano una pagina proprietaria (esempio:

DataChannel)

- content aggregator broadcasting: tali servizi collezionano informazioni da

compagnie terze, preparano il contenuto per categorie che definiscono canali ed

inviano i documenti agli utenti tramite un’architettura client-server (esempio:

BackWeb)

I servizi presi in considerazione in questa breve carrellata sono quelli che spiccano per

diffusione e rilevanza, o perché propongono soluzioni interessanti per gli obiettivi di

questo lavoro, ma si tratta naturalmente di una lista assai incompleta. Per dare

comunque un’idea di ciò che attualmente è possibile fare coi servizi presenti in Rete,

sono state scelte le seguenti applicazioni: InfoCast, BackWeb, DataChannel e Marimba.


2.2.1. InfoCast

Si tratta di un progetto TDF (Télédiffusion de France) in collaborazione con France

Telecom, che punta alla creazione di servizi Push multimediali per una qualsiasi rete di

broadcasting. In particolare, InfoCast è un prodotto di webcasting che permette agli

operatori del servizio di editare e distribuire set di informazioni collezionate sul Web,

all’interno di computers individuali o di reti aziendali locali, e ciò attraverso reti di

broadcasting: Datacast per TV analogiche, DAB o DARC per le radio e DVB per TV

digitali terrestri o satellitari. Gli strumenti di push multimediale del sistema InfoCast

permettono di strutturare contenuti multimediali (video, testo, immagini, audio, intere

pagine Web, ecc.) all’interno di canali, per trasmettere l’informazione ad alta velocità

scegliendo la rete di broadcasting più adatta.

L’architettura del sistema è composta di due strutture principali: il Centro Dati ed

InfoCast Surfer, quest’ultima installata sul PC del cliente finale.

Il Centro Dati colleziona contenuti dal Web per ordinarli in canali di Webcasting ed

amministrare tali canali per la distribuzione delle informazioni. Tale struttura è

responsabile di inviare i contenuti sulla rete di broadcasting, secondo il protocollo

necessario; il formato usato dipende dal tipo di rete. Al contrario, il formato dello

scambio di dati tra l’InfoCast Surfer ed il Centro Dati è indipendente dalla rete, ciò che

assicura la totale compatibilità del sistema con tutte le rete di broadcasting.

InfoCast Surfer riceve i dati da processare attraverso uno specifico modulo di ricezione

dalla rete. È possibile lavorare anche all’interno di una rete locale. Questo modulo può

assumere diverse forme, a seconda della natura del servizio: può essere cioè usato come

un software di consultazione personalizzata che permette la navigazione off-line, come

un pager per visualizzare messaggi urgenti oppure come un banner in cui i titoli dei

contenuti ricevuti vengono visualizzati. I criteri di filtraggio definiti dall’utente sono in

sostanza una serie di parole chiave e/o di canali tematici.


2.2.2. BackWeb

Il servizio offre un’infrastruttura aperta per lo sviluppo di applicazioni di

comunicazione automatica in Internet e di data delivery. Il sistema offre degli strumenti

per pubblicare contenuti, distribuirli, informare l’utente della loro esistenza e riportare i

risultati delle interazioni in un modo completamente automatico. BackWeb si basa su

un’architettura client-server che poggia su cinque componenti fondamentali: BackWeb

Foundation, BackWeb Client, BackWeb Server, Strumenti di sviluppo e BackWeb e-

Accelerator.

BackWeb Foundation usa l’architettura client-server con Windows NT 4.0 e Sun Solaris

per il lato server e Win32 per il client. La comunicazione avviene tramite un protocollo

proprietario, il BWTP (BackWeb Transport Protocol), che si pone nell’Application

layer sopra UDP/IP o sopra HTTP. I dati da distribuire sono organizzati dal processo di

pubblicazione in “InfoPaks” che sono collezioni di files definiti arbitrariamente. Un

InfoPak può contenere ogni numero di files in ogni formato ed ha un file che specifica

dei metadati sull’InfoPak stesso in formato XML.

BackWeb Client è esposto con un’interfaccia COM ed il server ha una documentazione

API, ciò che permette a BackWeb Foundation di essere integrato con altre applicazioni

o sistemi oppure di estendere le funzionalità già presenti. Il contenuto viene associato ai

singoli utenti sulla base di profili utenti (una scelta tra canali di contenuto); esso viene

poi inviato al computer del client in formato compresso o non compresso, oppure viene

conservato in un archivio del server. Esiste un’interfaccia utente standard di BackWeb,

ma essa può essere personalizzata o può essere utilizzata quella di un’altra applicazione.

BackWeb Server è gestito sia attraverso l’API del server o dalla BackWeb Server

Console (basata su Win32) che comunica col server attraverso TCP/IP. In questo modo

il processo di pubblicazione può essere effettuato manualmente attraverso la BackWeb

Server Console, manualmente con un’interfaccia HTML che lavori attraverso l’API del

server o automaticamente da ogni applicazione che si interfacci con l’API del server. È

possibile interfacciare anche script o programmi che permettano alle compagnie di


definire processi logici automatizzati. Alcuni tipi di questi processi sono facilitati dagli

strumenti di sviluppo già forniti dal sistema.

Strumenti di sviluppo ed API aperte facilitano il processo di integrazione

dell’architettura BackWeb con ambienti applicativi già esistenti nelle aziende, siti

Internet, Intranet, DB e sistemi legacy.

BackWeb e-Accelerator è progettato per fornire ai clienti un ambiente di lavoro

predefinito ed un’interfaccia utente che si posizionano in cima a BackWeb Foundation.

Ciò permette a molti clienti BackWeb di implementare le funzionalità di base del

sistema senza programmi aggiuntivi. Tale applicazione è basata su un DB ed è

programmata in Java (utilizza un Web Application Server con Java Server Pages, JSP).

Le funzionalità fornite da questa parte del sistema sono le seguenti:

- uno schema DB per utenti, gruppi e profili utente (Oracle e MS SQL Server)

- delle liste di distribuzione per utenti e gruppi ed amministrazione dei contenuti

- l’amministrazione degli argomenti dei contentui

- la pubblicazione dei contenuti

- un ambiente di lavoro per la personalizzazione al fine di determinare quali

argomenti o file vadano distribuiti a quali utenti

- l’amministrazione dei diritti e dei permessi

- un workflow di pubblicazione

- il reporting

- l’amministrrazione del sistema

- un’interfaccia utente basata su HTML

2.2.3. DataChannel

Il servizio offerto da DataChannel si basa su una serie di applicazioni che puntano alla

distribuzione di contenuto ed informazioni in tre aree chiave: Business-to-Employee

(B2E), Business-to Business (B2B), Application Service Providers (ASPs). Il sistema si

propone come una soluzione armonica ed integrata al problema della condivisione delle


informazioni all’interno di un’azienda. Le applicazioni si basano su XML come

piattaforma di comunicazione comune per lo scambio di dati. In questo modo chiunque

può pubblicare dati in qualsiasi tipo di formato (Excel, Word, ecc.) senza il bisogno di

rieditarli in HTML ma col semplice sistema del drag and drop. I documenti sono

organizzati in canali tematici e sono visualizzati per gli utenti attraverso uno dei client

disponibili: il client Java, il client HTML, il client Microsoft Active Channel ed il client

DataChannel “Save to the Web”.

Il server del sistema è programmato in Java e comunica con un DB attraverso un

ODBC/JDBC (Open Database Connectivity/Java Database Connectivity), può esportare

dati attraverso una grade varietà di linguaggi (XML, Java, JavaScript, HTML, ecc.) e

permette la distribuzione di ogni tipo di file indirizzabili con un URL (Uniforme

Resource Locator).

2.2.4. Marimba

Il sistema Marimba Castanet si compone di un set completo di strumenti per il Push di

informazioni su Internet. Tale sistema si basa sul concetto di canali (channels) ognuno

dei quali può essere utilizzato per distribuire informazioni HTML e/o

applicazioni/applets Java a gruppi di utenti. Castanet può essere usato per distribuire e

mantenere applicazioni software e contenuti all’interno di un’organizzazione o nel

World Wide Web, assicurando agli utenti di avere sempre ed in modo automatico le

informazioni più aggiornate. Il servizio si compone di tre componenti principali:

Castanet Tuner, Castanet Trasmitter e Castanet Repeater.

Castanet Tuner è il client dell’utente che riceve e gestisce i canali di sottoscrizione

richiesti dagli utenti stessi. I canali sono conservati localmente ed automaticamente

installati, mantenuti ed aggiornati da Castanet.

Castanet Transmitter è un server di applicazione/informazione che distribuisce e

mantiene i canali a tutti i Castanet Tuners collegati.

Castanet Repeater fornisce delle crescenti capacità di trasmissione per utenti locali o

remoti; esso può essere collocato ovunque il bisogno sia più grande: localmente, per


supportare un Trasmitter pesantemente usato, od in modo geograficamente disperso per

meglio servire gli utenti d’oltreoceano.

2.3. SwissCast

Il progetto di ricerca SwissCast è stato finanziato dal Fondo Nazionale Svizzero per la

Ricerca Scientifica nel periodo dal 1997 al 2000 nell’ambito del programma prioritario

“Strutture di informazione e comunicazione”. In questo periodo è stato diretto da

Maurizio Decina9, Eddo Rigotti10 e Fiorenzo Scaroni11.

Il progetto si proponeva di sviluppare un’applicazione che applicasse il paradigma di

“casting di informazione” e che ricoprisse il ruolo di information broker in due aree di

mercato specifiche: i prodotti farmaceutici e la ricerca scientifica. A tutt’oggi rimane

ancora attivo il solo servizio rivolto alla ricerca scientifica.

In particolare, il servizio di ricerca e sviluppo di SwissCast punta ad informare

ricercatori di lingua italiana in Svizzera sulle novità nel campo della ricerca e dello

sviluppo, focalizzandosi sui seguenti campi:

- informazioni dai maggiori programmi nazionali ed internazionali, in particolare

sulle nuove possibilità di fondi di ricerca

- informazioni sulle attività di ricerca nella parte italiana della Svizzera, in

particolare dalle due università della zona (USI e SUPSI).

Le informazioni vengono reperite dal sistema attraverso due tipi di fonti: information

provider attivi, che quindi forniscono direttamente informazioni al sistema, ed

information provider passivi, trovati tramite un motore di ricerca basato su parole

9 Professore al Politecnico di Milano e docente alla facoltà di Scienze della Comunicazione

dell’Università della Svizzera Italiana (USI)10 Professore e decano alla facoltà di Scienze della Comunicazione dell’USI11 Professore alla Scuola Universitaria Professionale della Svizzera Italiana (SUPSI) ed alla facoltà di

Scienze della Comunicazione dell’USI


chiave. L’editore del sistema12 decide se abilitare un nuovo information provider sulla

base della sua conoscenza personale e di una valutazione dell’interesse della fonte di

informazione. Di fatto l’editore svolge anche un ruolo attivo, in quanto invita dei

possibili provider a contribuire. Per il momento, comunque, non esiste una politica

formale in questo senso.

Gli information provider attualmente attivi sono i seguenti:

- il Fondo Nazionale Svizzero per la Ricerca Scientifica (FNSRS), che promuove

programmi nel settore della ricerca fondamentale

- l’Ufficio Federale della Formazione Professionale e della Tecnologia (BBT) e in

particolare la Commissione Tecnologia ed Innovazione (CTI) che sviluppano

progetti di ricerca applicata

- l’Ufficio Federale dell’Educazione e della Scienza (UFES), la Conferenza

Universitaria Svizzera (CUS) ed il Consiglio Svizzero della Scienza (CSS)

- il servizio informazione dei programmi di ricerca dell’Unione Europea

(CORDIS)

- il servizio di ricerca USI/SUPSI

I dati da CORDIS sono acquisiti automaticamente, attraverso un modulo che interroga

periodicamente il DB disponibile online e che converte le keywords di CORDIS in

quelle di SwissCast (attraverso uno schema di conversione univoca). Dalle altre

strutture si acquisiscono dati attraverso un monitoragggio costante dei siti (motore di

ricerca); le informazioni vengono inserite dal responsabile del servizio attraverso

un’opportuna interfaccia.

Le informazioni così raccolte passano dapprima attraverso un filtro che elimina le

informazioni inutili sotto la guida del direttore; quest’operazione è dunque effettuata

manualmente. I dati utili sono quelli che combaciano con almeno un profilo utente.

Anche in questo caso è l’editore che decide se attribuire un provider alla categoria

“moderato” e quindi filtrare i documenti pubblicati; tale parametro può essere

12 Attualmente l’editore del sistema SwissCast è Benedetto Lepori


modificato in seguito, se necessario. Attualmente vengono moderati i provider guest e

le informazioni acquisite da CORDIS.

Le informazioni sono poi archiviate e conservate in un DB dei documenti separato dal

DB degli utenti. Tali informazioni vengono presentate all’utente attraverso l’unità di

casting. Tale unità è a sua volta composta di un presentation editor (che permette al

direttore di comporre i documenti da spedire agli utenti) e di un server che mette tali

documenti a disposizione per la consultazione. Anche la presentazione delle

informazioni dunque, è un processo manuale. Lo schema del DB è il seguente:

user

push

subject_type

type docprofile

subject

source

active_provider

1,1

1,1

1,1

1,1

1,1

1,1

1,N

1,N

0,N 0,N

0,N 0,N

0,N

0,N

0,M

0,M

1,M

0,1

Figura 1: schema E-R del DB SwissCast

L’informazione nel DB è classificata usando uno schema di parole chiave adattato dallo

Scientific Index Code di CORDIS con qualche criterio addizionale comprendente il tipo

di informazione (notizie, manifestazioni, messe a concorso e borse di ricerca) e l’area

geografica di riferimento (Svizzera italiana, Svizzera, Unione Europea, Programmi di


Ricerca Internazionali). Tutti i documenti sono affiancati dai seguenti metadati: titolo,

descrizione, lingua (I/E/D/F), data di fine pubblicazione, data di inizio pubblicazione,

data di cancellazione dalla base dati, link ad una pagina WWW che contiene

l’informazione originale o nei dettagli, nome del provider di informazione, fonte

dell’informazione, un campo per inserire luogo e data di una manifestazione,

classificazione del documento.

Lo schema delle keywords ha la seguente struttura:

- Industria e tecnologia (Manufatturiera industriale, Elettronica e microelettronica,

Trasporti e spazio, Tecnologia e materiali di costruzione, Altre tecnologie);

- Informazione e comunicazione (Telecomunicazioni, Processamento e sistemi di

informazione, Pubblicazioni elettroniche e multimedia, Informazioni e media,

Semiotica e linguistica);

- Energia, ambiente e scienze della vita (Energia non nucleare, Energia nucleare,

Protezione dell’ambiente e gestione delle catastrofi, Sicurezza, Medicina e

salute, Biotecnologie e scienze della vita);

- Scienze della terra e scienze esatte (Agricoltura ed alimentazione, Scienze esatte,

Scienze della terra);

- Scienze economiche, sociali ed umane (Unità di misura e standard, Educazione

ed insegnamento, Economia, business e sviluppo regionale, Società e scienze

sociali, Scienze umane, Storia, Storia dell’arte, Architettura);

- Argomenti orizzontali (Politiche di ricerca e sviluppo, Legislazione e

regolamenti, Previsioni e valutazioni, Innovazioni e trasferimento di tecnologie,

Coordinazione e cooperazione, Educazione ed insegnamento, Ricerca

scientifica).

Il modello di ogni utente comprende, oltre alle aree di interesse selezionate, alcuni dati

personali, l’indirizzo di posta elettronica, il nome e la password per accedere al servizio.

Il sistema attribuisce ad ogni profilo automaticamente i documenti che corrispondono ai

criteri di classificazione selezionati, secondo la logica seguente:

- tutti e tre i criteri (soggetto, tipo, area geografica) devono corrispondere (AND)

- per ciascun criterio deve corrispondere almeno una delle caratteristiche

selezionate (OR)


L’utente viene avvertito periodicamente della presenza di nuovi documenti sul proprio

profilo. Tali documenti possono essere cancellati o mantenuti. In caso contrario essi

vengono comunque cacellati automaticamente dopo 30 giorni dalla data di

pubblicazione.

I profili sono gestiti direttamente dagli utenti, mentre non c’è un meccanismo

automatico di cancellazione in caso di non utilizzo del profilo. L’editor interviene

manualmente solo in caso di problemi particolari (ad esempio se l’indirizzo e-mail non

è più funzionante).

2.4. Alcuni svantaggi dei sistemi descritti

I sistemi di customized document delivery descritti in questo capitolo si basano su un

concetto abbastanza statico di modello dell’utente13. Essi si legano cioè a modelli

semplici e statici basati su dati inseriti direttamente dall’utente scegliendo tra categorie

generali o tra alcune parole chiave; tali scelte sono usate come una specie di modello

degli interessi dell’utente. Un tale approccio non può fornire informazioni rilevanti

senza lavoro significativo da parte dell’utente [Underwood et al. 2001]. Per ottenere

dall’applicazione Push informazioni pertinenti per gli interessi a corto termine

dell’utente, quest’ultimo deve manipolare direttamente l’applicazione (aggiornando il

suo modello e cercando nei canali di interesse o tra le parole chiave). In questi casi il

“mondo” (cioè il dominio od i domini di interesse del sistema) è considerato dinamico e

l’utente quasi statico: l’utente viene così aggiornato solo quando lo stato rilevante del

“mondo” cambia. Ma gli interessi dell’utente non sono così stabili come tali approcci

assumono che siano.

Un secondo grave problema per i sistemi di customized document delivery presenti sul

mercato è la loro rigidità nei confronti di cambiamenti rilevanti nella struttura di

rappresentazione del dominio. L’aggiunta o la rimozione di un canale tematico, così

come la modifica di alcune parole chiave, richiedono un grande lavoro di

13 Sul concetto di modello dell’utente si ritornerà nel prossimo capitolo


riprogrammazione dell’intero sistema, dalle interfacce con gli utenti alla struttura dei

DB, e rischiano di rendere inconsistenti i già presenti modelli degli utenti. Inoltre, se

anche un utente umano, avvertito di un tale cambiamento, può adattare il suo modello

preservandone la consistenza, cosa succede se l’utente è una macchina? SwissCast, per

esempio, è di fatto un utente del servizio informazioni di CORDIS, attraverso il modulo

di conversione citato prima; nel caso in cui CORDIS modificasse il proprio schema di

keywords, il modulo di SwissCast non sarebbe più in grado di funzionare correttamente

ed andrebbe riprogrammato. In queste applicazioni, quindi, la condivisione della

conoscenza può risultare un’operazione assai faticosa.

Altre difficoltà possono nascere nella gestione dei modelli da parte degli utenti; ogni

modifica nei dati personali dell’utente (per esempio un cambiamento di indirizzo di

posta elettronica) o nei suoi interessi (per esempio un ampliamento, da notizie

riguardanti la sola Svizzera a notizie provenienti da tutta l’Europa), va infatti ripetuta

per ogni servizio a cui l’utente è iscritto. Al momento, infatti, non è possibile

condividere i modelli degli utenti tra diversi sistemi a causa della mancanza di una

piattaforma comune di condivisione dei dati. E non è il solo ostacolo: la comprensione

di tali dati, infatti, è legata alla comprensione della struttura che il progettista ha dato al

DB, e che un computer non può assumere a meno che sia esplicitamente descritta. È in

altre parole necessario che sia in qualche modo comprensibile il fatto che una stringa di

caratteri x rappresenti il nome ed un’altra stringa y rappresenti invece il cognome di un

utente. Si torna dunque al problema della condivisione della conoscenza.

Ad una prima analisi, il fatto che il controllo e la modifica dei modelli degli utenti siano

completamente affidati agli utenti stessi sembra avere molti aspetti positivi; con ciò si

evita soprattutto che un modello si evolva automaticamente ed erroneamente in

direzioni non volute dall’utente del sistema; allo stato attuale, infatti, le tecnologie

adattative non lavorano molto bene con pochi dati, ambigui o dal significato poco

chiaro come possono esserlo quelli derivanti dalle azioni di un utente. Non bisogna però

esagerare nel fargli carico di compiti che richiedono tempo e pazienza. Alcuni problemi

possono per esempio nascere già nella definizione del profilo di interessi: una scelta tra

canali tematici o parole chiave troppo generici non può soddisfare le esigenze specifiche


di un utente, mentre una scelta troppo ricca od eccessiva rischia di confonderlo e

scoraggiarlo. Spesso, quindi, esso si limita ad una definizione di massima dei propri

interessi, e non sempre ha tempo o voglia di raffinarli. In sintesi: la presenza di un

sistema di raffinamento automatico dei modelli degli utenti rischia di portare il modello

lontano dai veri interessi dell’utente stesso, mentre l’assenza di un simile sistema rischia

di favorire la sclerotizzazione del modello in definizioni generiche e poco precise di tali

interessi. La totale mancanza di adattività14 non tiene inoltre conto che gli interessi di un

utente si evolvono e modificano col tempo, a volte in modo non percepito dall’utente

stesso.

La rigidità nella rappresentazione degli interessi degli utenti nei sistemi di customized

document delivery descritti in questo capitolo ha un ultimo inconveniente. Spesso

infatti, come già detto, l’utente si limita a dare delle definizioni di massima dei propri

interessi; ma alcune cose possono essere desunte a partire dai dati a disposizione. Si

tratta cioè di inferire conoscenze nuove a partire dalla conoscenza sino a quel punto

acquisita (in questo caso direttamente dall’utente). Perché un sistema sia in grado di

inferire informazioni in modo automatico è necessario che i dati di base siano

processabili da una macchina in modo semplice e (come dicono i programmatori più

acuti) performante.

Nel prossimo capitolo si cercherà di dare una risposta efficace a questi problemi

proponendo una metodologia di descrizione dei dati che si basa sulla rappresentazione

della conoscenza. Tale metodologia è stata applicata ad un progetto di reengineering del

sistema SwissCast descritto prima.

14 Per la differenza tra adattività ed adattabilità si veda il prossimo capitolo


3. Il progetto SwissCast2

3.1. Caratteristiche generali

In risposta ai problemi elencati nel capitolo precedente, il progetto che si propone in

questo lavoro deve comprendere le seguenti caratteristiche: una struttura dei dati

flessibile e machine understandable, dei modelli espliciti per i documenti, gli utenti e

gli Information Provider ed un sistema adattativo ed adattabile per i profili degli utenti

che sia in grado di basarsi su poche rilevazioni statistiche. In un sistema adattabile

l’utente può scegliere tra alcune opzioni per creare un profilo personalizzato. Un

sistema adattativo invece acquisisce la conoscenza dell’utente in modo automatico. Un

modello utente può essere adattabile o adattativo, oppure può scaturire da una

combinazione di entrambe le cose, come nel caso presente.

In genere ci si limita a modellizzare gli utenti in quanto variabile del sistema che non è

possibile conoscere in anticipo, lasciando implicita la conoscenza del dominio. Un

modello dell’utente è infatti in sostanza una fonte di conoscenza che contiene impliciti

assunzioni di quegli aspetti dell’utente che possono essere rilevanti nel comportamento

del sistema [Kobsa & Whalster 1988]. Nel sistema SwissCast2 invece, come

conseguenza di adottare un’impostazione user-centered in cui l’utente è un’integrale e

partecipante forza del processo nel sistema [Johnson 1998], si è deciso di modellare

anche gli elementi del dominio, vale a dire i documenti e gli Information Provider.

Ma il nucleo originale del presente lavoro sta nella caratteristica che risponde alle

esigenze di condivisione dei dati e di flessibilità: l’utilizzo della conoscenza. L’obiettivo

è quello di rappresentare conoscenze rilevanti sui documenti, gli Information Provider e

gli utenti ad un primo livello e, ad un ulteriore livello, di rappresentare conoscenze su

queste rappresentazioni. In altre parole, il primo livello, in cui si rappresentano i dati del

sistema utilizzando certi termini, fornisce la sintassi, mentre il secondo livello, in cui si

definiscono i termini utilizzati, fornisce la semantica della rappresentazione. Come si


vedrà in seguito, gli strumenti utilizzati (da un punto di vista logico) in questo “livello

semantico” sono stati chiamati sistemi terminologici ed hanno l’aspetto famigliare di

reti semantiche. Il sistema SwissCast2 è dunque un KBS (Knowledge Based System)

che sfrutta le potenzialità delle reti semantiche come logica del sistema stesso, ma che si

basa su XML per la rappresentazione “fisica” di tale conoscenza. Ciò permette di

adottare questo linguaggio come piattaforma comune per la condivisione di dati tra il

sistema SwissCast2 ed altri sistemi informatici e come base di scambio di dati tra i

moduli del sistema stesso. Si tratta inoltre di un linguaggio processabile, ciò che facilita

l’adattività e permette di calcolare delle inferenze in modo automatico.

Tutti i dati all’interno del sistema vengono dunque rappresentati in un formato basato su

XML (eXensible Murkup Language), un linguaggio di marcaggio derivato da SGML15

(per la sintassi del linguaggio si rimanda a [W3C 2000b]). Questa scelta permette di

raggiungere diversi obiettivi. Innanzitutto l’utilizzo di XML offre un modo semplice e

standardizzato per dividere il contenuto dalla sua forma. Ogni documento da

pubblicare, ad esempio, viene conservato all’interno del sistema assieme con la sua

descrizione, ciò che permette l’accesso semplice alle sue caratteristiche (l’autore, il

titolo, il soggetto, ecc.) in quanto tutte le descrizioni di documenti hanno la medesima

struttura definita in un unico Document Type Definition (il DTD che nell’esempio del

prossimo capitolo è chiamato “document.dtd”). Anche la forma grafica di presentazione

di questi contenuti può venire standardizzata, con l’utilizzo dei cosiddetti “fogli di stile”

XSL16 che permettono la trasformazione univoca ed automatizzata da una descrizone

XML ad una pagina HTML, come verrà descritto meglio in seguito.

Dividere il contenuto dalla sua forma permette inoltre un’enorme flessibilità nella

rappresentazione dei dati all’interno del sistema. Se la struttura di come vengono

descritti i dati (relativi a documenti, utenti ed IP) è a sua volta descritta in un formato

comprensibile da tutte le applicazioni del sistema (i sopracitati DTD, anch’essi definiti

in XML), tale struttura può essere considerata trasparente ai fini delle applicazioni

stesse e supportare in questo modo qualsiasi modifica senza che vi sia la necessità di

riprogrammare l’intero sistema. Per rendere più chiaro ciò che si intende in questo caso,

15 Stadardised Generalised Markup Language (ISO 8879) [W3C 1997]16 XML Stylesheet Language [Day 2000]


è opportuno riferirsi ad un breve esempio. Il gestore del sistema SwissCast2 vuole

aggiungere un nuovo soggetto per la categorizzazione dei documenti; questo nuovo

soggetto, “Signals elaboration” è parte sia del soggetto “Telecommunications” che di

“Electronics”. Nell’attuale sistema SwissCast sarebbe necessario modificare di fatto

l’interfaccia che permette la categorizzazione di un nuovo documento, l’interfaccia che

permette ad un utente la scelta dei soggetti per il profilo di interessi, i moduli di

inserimento dei dati nel DB e, naturalmente, i relativi campi del DB stesso. Separando e

centralizzando la descrizione dei dati, invece, l’unica modifica necessaria sarebbe quella

di aggiungere il nuovo soggetto nel file contenente la descrizione dei soggetti. Non

sarebbe quindi necessario modificare le relative applicazioni, in quanto esse farebbero

riferimento a questa descrizione centrale. In altre parole, anziché distribuire la struttura

dei dati in tutto il sistema, si centralizza la descrizione dei dati per favorirne la

flessibilità.

L’esempio sopra esposto evidenzia una necessità importante all’interno di un sistema

del genere di quello che si sta qui descrivendo. Non è infatti sufficente definire la

struttura delle rappresentazioni dei dati (tramite DTD), ma bisogna anche definire i

termini che vengono usati per effettuare tali rappresentazioni. Non basta, cioè, dire che

una caratteristica di ogni documento è il Soggetto relativo al suo contenuto, ma è

necessario anche definire che uno di questi soggetti ha come nome che lo identifica

“Signals elaboration” e che questo soggetto ha determinate relazioni con altri termini

della rappresentazione (“Signals elaboration” partOf “Electronics”, “Signals

elaboration” partOf “Telecommunications”). La somma dei termini, delle relazioni che

intercorrono tra di essi e delle regole di inferenza applicabili alle relazioni stesse è ciò

che viene qui definito, come detto, un sistema terminologico (d’ora in poi ST).

Il valore aggiunto che una tale sovrastruttura descrittiva fornisce è composto

essenzialmente da due elementi: la flessibilità e l’interoperabilità. Sulla flessibilità si è

già detto prima: naturalmente la possibilità di definire, ridefinire e modificare i termini

ed i valori accettati dal sistema senza riprogrammare l’intera applicazione constituisce

un enorme vantaggio. Con interoperabilità ci si riferisce invece al tema della

condivisione della conoscenza; una tale organizzazione della rappresentazione della

conoscenza permette non solo di rendere comprensibile a sistemi esterni i contenuti di


SwissCast2, ma anche e soprattutto di cercare, assumere ed utilizzare in modo

automatico contenuti già presenti sul Web.

La possibilità descritta sopra di modificare la struttura di descrizione dei documenti da

parte del gestore del sistema, può sollevare il problema della gestione delle revisioni dei

ST. Chi effettua la modifica, infatti, potrebbe decidere di utilizzare dei termini diversi al

posto di quelli già esistenti o di rimuoverne alcuni. Per fortuna il problema della

gestione delle revisioni ha delle soluzioni conosciute. Nelle prossime righe si farà un

breve riferimento a [Heflin & Hendler 2000]; in questo caso si fa riferimento a ciò che

qui abbiamo chiamato ST utilizzando il termine ontologia17.

La difficoltà che sorge sta nel fatto che per ogni ontologia modificata è necessario

rivedere tutti gli oggetti ad essa collegati. Vi sono essenzialmente due soluzioni.

La prima sta nel creare un’ontologia mappata MO che estende le due ontologie 1O

(quella di partenza) ed 2O (quella revisata); ad MO si assegna un ID univoco che la

distingue dalle altre; l’ontologia mappata serve a contenere regole di inferenza per

passare da 1O ad 2O (come regole del tipo “se e solo se” per cambi di terminologia).

Un secondo metodo prende in considerazione il caso in cui sia necessario risalire da 2O

ad 1O : si creano due ontologie di mappatura, '1O che mappa 2O nella terminologia di

1O ed '2O che si occupa del contrario.

Questa soluzione ignora però il problema fondamentale della sovrapposizione di

concetti, ripetendo in '1O ed in '2O tutte le parti che non sono state modificate; per

questo problema è utile creare una NO che mappi l’intersezione tra le due ontologie. Un

riassunto di queste soluzioni è fornito dalla figura 2.

17 Nel capitolo 4.2 si darà una giustificazione di questa differenza terminologica


Figura 2: gestione delle revisioni tramite mappature

A questo punto è possibile presentare in modo più dettagliato il sistema nel suo

complesso e le sue varie parti, cercando di essere il più precisi possibile, ma rifacendosi

all Appendice A per la descrizione formale del progetto tramite schemi UML18.

La struttura logica di SwissCast2 si basa su cinque macroparti fondamentali: le

interfacce col mondo esterno, gli archivi con le descrizioni dei dati, un modulo di data

mining, un cosiddetto XML engine ed i moduli che permettono l’invio di documenti

rilevanti all’utente. Lo schema della figura 3 illustra con maggior dettaglio ognuna di

queste macroparti. Ogni modulo è segnato con un rettangolo, gli archivi sono

rappresentati in azzurro mentre le interazioni ed i passaggi di dati sono segnati da frecce

mono- o bidirezionali.

18 Unified Modeling Language [Ghezzi 1991]


Figura 3: schema generale di SwissCast2


3.2. Attori

Come si può notare facilmente dallo schema della figura 3, gli attori coinvolti nei

processi del sistema sono essenzialmente di tre tipi: gli Information Provider (d’ora in

poi IP), il Director e lo User.

Gli IP sono genericamente degli attori, singole persone o, più di frequente,

organizzazioni che forniscono i contenuti e le informazioni da distribuire all’utenza del

servizio. Vi possono essere IP attivi o passivi e moderati o non moderati. Gli IP attivi

interagiscono direttamente col sistema inserendo manualmente i nuovi documenti

tramite l’apposita interfaccia. Gli IP passivi vengono invece interrogati dal sistema

tramite il modulo chiamato “motore di ricerca”; la descrizione XML degli IP permette,

come vedremo, il “mapping” automatico tra le classificazioni da questi ultimi e la

classificazione di SwissCast2, costituendo di fatto un ponte tra i due sistemi

terminologici. Gli IP moderati forniscono dei contenuti che necessitano di un controllo

da parte del responsabile del sistema (il Director) prima della loro pubblicazione; quelli

non moderati, al contrario, forniscono delle informazioni che vengono pubblicate senza

dover essere sottoposte a controllo.

Il Director è il responsabile del controllo del sistema; può anche essere più di uno

(potrebbe ad esempio esserci un responsabile specializzato per ogni settore della ricerca

scientifica). Le sue funzioni sono essenziali perché tutti i processi avvengano

correttamente: egli, come detto prima, può moderare i documenti forniti dagli IP;

inoltre, egli può modificare la struttura di classificazione dei documenti stessi ed

inserire nuovi IP. Può capitare che un Director decida di raffinare le possibiltà di

classificazione dei documenti per rendere più efficace il processo di accoppiamento

(matching) con gli interessi degli utenti o meno generiche le descrizioni fornite dagli IP

attivi; è quindi data la possibilità di modificare il ST dei documenti. In questo caso, le

modifiche apportate vengono notificate agli utenti registrati perché, se interessati,

possano raffinare ulteriormente il proprio profilo di interessi. I nuovi IP che vengono

registrati dal Director sono ovviamente passivi; in genere possono venire interrogate

basi di dati rilevanti per la ricerca scientifica che permettano un interfacciamento

automatico, come il servizio CORDIS.


Uno User è un utente generico del sistema SwissCast2; in genere il target è identificato

con i ricercatori che operano nella Svizzera Italiana, ma l’applicazione attualmente in

funzione è utilizzata anche da alcuni studenti. Ogni utente può registrarsi specificando il

proprio profilo di interessi o modificare un profilo già definito. A scadenza regolare

(ogni giorno od una volta alla settimana) gli viene notificato tramite la posta elettronica

se ci sono nuovi documenti che coincidono col profilo dell’utente in questione. Come si

vedrà in seguito, vengono rilevate alcune interazioni dell’utente col sistema per inferire

dei possibili raffinamenti del suo profilo. L’utente viene anche avvertito ogni volta che

la struttura di classificazione dei documenti viene modificata.

Vediamo ora nel dettaglio i processi coinvolti nel sistema SwissCast2; sebbene nel

prossimo capitolo ogni processo venga formalizzato tramite schemi UML19, la seguente

descrizione informale sarà utile per comprendere meglio il funzionamento di alcuni dei

moduli principali e l’organizzazione dei vari archivi dati.


3.3. Inserimento di un nuovo documento

Quando un IP attivo accede alla parte del servizio a lui dedicata per inserire i dati di un

nuovo documento, l’interfaccia che permette quest’operazione viene creata

dinamicamente; il modulo infatti interroga il ST dei documenti e preleva tutte le

caratteristiche di una DOCUMENTDEF (Document Definition), ciò che definisce

l’intero documento. La struttura del ST dei documenti è descritta nel capitolo 4.2.2.

Secondo tale struttura, i campi richiesti sono i seguenti:

Nome campo Descrizione Obbl. Car.� Tipo di valore

TITLE Titolo attribuito aldocumento

Y 1 stringa alfanumerica; icaratteri &, <, >, “ e ‘vengonoautomaticmenteconvertiti in & ,< , > , " e'

CREATOR agente generico(persona odorganizzazione)responsabile di avercreato il contenutointellettuale deldocumento

Y + stringa alfanumerica(per permettere nomi diorganizzazionicontenenti numeri); perfavorire la ricerca deidati in questo campo,la stringa vieneconvertita in “TUTTOMAIUSCOLO”; icaratteri &, <, >, “ e ‘vengonoautomaticmenteconvertiti in & ,< , > , " e'

FORMAT tipo di formato deidati in cui èdisponibile ildocumento, oltre alformato HTMLfornito da

N * una delle stringhedefinite nel ST (“txt”,“pdf”, “doc” o “html”)

� Per la cardinalità sono stati usati i seguenti simboli:

1 [1:1] ; ? [0:1] ; + [1:n] ; * [0:n]


SwissCast2SOURCE indirizzo IP di un

secondo documentoda cui il presentedocumento èderivato

N ? URL (UniformResource Locator)secondo la specificafornita dalla W3C[Berners-Lee 1998]

RIGHTS indirizzo IP delprovider diinformazioni suidiritti diriproduzione e dimodifica deldocumento

N ? come nel campoSOURCE

LANGUAGE lingua in cui ildocumento è redatto

Y 1 stringa che rappresental’acronimo della linguaa cui si fa riferimento,secondo lo standardISO 639

ABSTRACT breve riassunto deitemi del documento,utile qualora si trattidi un testoparticolarmentelungo

N ? stringha in codiceHTML valido secondola specifica HTML 2.0

CONTENT contenutointellettuale deldocumento

Y 1 come nel campoABSTRACT

CLASSIFICATION divisa in sottocampi;il sistema rileva lerelazioni di partOfche puntano ad essoe si comporta diconseguenza

1 SUBJECTCATEGORYTYPESECTORLOCATION

SUBJECT l’argomento a cui siriferisce ildocumento

Y * una delle stringhedefinite comeSUBJECT nel ST

CATEGORY categoria diinformazioni (news,borsa di ricerca, ecc.)

Y * una delle stringhedefinite comeCATEGORY nel ST

TYPE tipo di documento(bando, articolo,ecc.)

Y * una delle stringhedefinite come TYPEnel ST

SECTOR Settore della ricercaa cui ci si riferisce

Y * una delle stringhedefinite comeSECTOR nel ST

LOCATION Zona geografica acui il contenuto deldocumento si

Y * una delle stringhedefinite comeLOCATION nel ST


riferisce

In aggiunta a questi dati, per ogni documento vengono assegnate dal sistema le seguenti

informazioni in modo automatico:

Nome campo Descrizione Obb. Car.� Tipo di valore

ID è l’indirizzo delladescrizione XML deldocumento

Y 1 URI secondo laspecifica fornita dallaW3C [Berners-Lee1998]

STARTDATE data assegnataquando il documentoviene dichiaratopubblicabile

N ? complete_date secondoil formato standarddella W3C

ENDDATE data assegnataquando il documentonon persiste piùnell’archivio dipubblicazione (ingenere 30 giornidopo laSTARTDATE)

N ? come nel campoSTARTDATE

PUBLISHER IP responsabile diaver reso disponibileil documento nellasua forma attuale.

N ? URI della descrizionedell’IP negli archividel sistema

MODERATED valore booleano cheindica se ildocumento è giàstato moderato o no

Y 1 valore booleanorappresentato dallestringhe “Y” oppure“N”

I dati così raccolti vengono inviati alla XML Engine. Questo modulo si occupa di

formare dei file XML validi in accordo col DTD relativo (in questo caso è

“document.dtd”). Il file XML viene poi stoccato nel DB con le altre descrizioni di

documenti, in attesa di essere moderato. Se l’IP che ha inserito questo documento non è

moderato, il campo MODERATED viene settato subito a YES. Nel caso contrario tale

campo viene settato a NO.

� Per la cardinalità vale ciò che si è detto sopra


3.4. Moderazione dei documenti

Ogni Director può effettuare l’operazione di moderazione dei documenti in relazione a

quelli che non sono stati già moderati. Il sistema raccoglie tutte le descrizioni dei file il

cui campo MODERATED ha valore negativo ed impagina i dati contenuti in tali

descrizioni in modo che il Director possa modificarli. È possibile che si voglia

modificare la classificazione di un documento; in questo caso il sistema interroga il ST

dei documenti ed il Director può raffinare o riformulare la classificazione fatta dall’IP.

Quando il controllo è stato effettuato e confermato, il valore del campo MODERATED

viene settato a YES.

Nel momento in cui nel campo MODERATED di un documento appare il valore

positivo, scatta un processo automatico che trasforma la descrizione XML in una pagina

HTML. Questo è possibile applicando un cosiddetto “stylesheet XSL”. Uno stylesheet

specifica la presentazione di informazioni XML attraverso un albero di trasformazione;

la scelta di HTML come forma di output è arbitraria. Per una trattazione più completa

rimando a [Day 2000]. Un unico foglio di stile XSL per tutti i documenti permette una

presentazione univoca delle informazioni in essi contenuti agli utenti.

Parallelamente scatta l’operazione di matching della descrizione di questo nuovo

documento coi profili di interesse degli utenti; tale operazione verrà descritta nei

dettagli in seguito.

3.5. Registrazione di un nuovo IP

Ogni Director ha tra i suoi compiti quello di cercare attivamente nuove fonti di

informazione e nuovi IP; può di fatto proporre a degli IP di registrarsi come attivi nel

servizio SwissCast2, oppure può registrarne di passivi qualora trovi basi di dati

consultabili od interfacce XML a cui appoggiarsi. La rappresentazione dell’IP presente

nel sistema è in pratica un’immagine della sua ontologia nei termini del ST di

SwissCast2. Anche in questo caso il modulo preposto all’operazione di inserimento

interroga il ST degli IP e preleva tutte le caratteristiche di una IPDEF (Information

Provider Definition), ciò che permette di creare un’interfaccia di inserimento dati in

modo dinamico. La struttura del ST degli IP è descritta nel capitolo 4.2.4. Secondo tale

struttura, i campi richiesti sono i seguenti:


NAME nomedell’organizzazioneprovider diinformazioni

Y 1 stringa alfanumerica; icaratteri &, <, >, “ e ‘vengonoautomaticmenteconvertiti in & ,< , > , " e'

NICKNM nome abbreviatousato all’interno delsistema per riferirsiall’IP

Y 1 come nel campoNAME (4 caratteri)

SOURCE indirizzo internet delsito Web dell’IP

N ? URL (UniformResource Locator)secondo la specificafornita dalla W3C[Berners-Lee 1998]

LOGO immagine checostituisce il logo odil logotipo dell’IP

N ? il campo contiene unriferimento HTML adun’immagine (<IMGSRC=...>)

IMG riferimento all’URIdel logo

Y 1 come definito inHTML, ha un attributoSRC che contienel’URI dell’immagine

TYPE tipo di IP, attivo opassivo

Y 1 stringa con due solivalori possibili,“Active” o “Passive”

MODERATED IP moderato o nonmoderato

Y 1 valore booleano, “Y” o“N”

ACCESS definisce l’accessosicuro ai dati dell’IP

Y 1 si compone delle partiUSERNAME ePASSWORD

USERID nome di Y 1 una stringa


1 [1:1] ; ? [0:1] ; + [1:n] ; * [0:n]


identificazionedell’IP

alfanumerica (max. 12caratteri)

PASSWORD parola chiave perl’identificazionedell’IP

Y 1 una stringaalfanumerica (max. 20caratteri)

KEYWORD questo camposupport ail mappingtra il vocabolariodell’IP ed il ST diSwissCast2

N * si compone delle partiIPTERM e SCTERM

IPTERM termine delvocabolario dell’IP

Y 1 stringa alfanumerica

SCTERM termine SC2migliore in cuimappare il terminedell’IP

Y 1 uno dei valori permessiper unaDOCUMENTDEF

I dati così raccolti vengono inviati alla XML Engine. Questo modulo si occupa di

formare dei file XML validi in accordo col DTD relativo (in questo caso è “ip.dtd”). Il

file XML viene poi stoccato nell’archivio con le altre descrizioni di IP. Se l’IP inserito è

attivo, potrà autonomamente inserire nuovi documenti all’interno del sistema. La

gestione degli IP passivi avviene automaticamente per mezzo del modulo chiamato

“motore di ricerca”. A scadenza regolare (una volta al giorno) il motore di ricerca

interroga l’archivio degli IP prelevando i dati relativi a quelli passivi. Per ogni IP

passivo, il modulo avvia l’interrogazione della base di dati dell’IP stesso, assumendo

nuovi documenti e mappando la descrizione degli stessi nei termini di SwissCast2

secondo come specificato prima. I dati di ogni nuovo documento vengono poi inviati

alla XML Engine che si comporta come detto sopra.


3.6. Modifica della struttura di classificazione dei

documenti

Ad ogni Director è data la possibilità di sfruttare le capacità di adattamento e di

flessibilità del sistema. Egli può infatti intervenire nel ST dei documenti per

modificarne la struttura seguendo nuove esigenze degli utenti o sviluppi nel mondo

della ricerca scientifica; questo è particolarmente utile per la parte relativa alla

classificazione dei documenti.

Il modulo di modifica interroga il ST dei documenti e ne ottiene una rappresentazione

completa; una rappresentazione grafica possibile in sede di implementazione potrebbe

essere quella di un grafo con nodi ed archi etichettati. In ogni modo, l’interfaccia di

modifica assume la funzione di un editor grafico di questa struttura. Sarà così possibile,

per tornare all’esempio iniziale, inserire il nuovo SUBJECT “Signals elaborations”,

legandolo al grafo esistente per mezzo delle relazioni

{“Signals elaboration” partOf “Electronics”} e {“Signals elaboration” partOf

“Telecommunications”}. Ogni modifica così effettuata potrà essere “utilizzata” nella

classificazione dei nuovi documenti; la correzione dei documenti già pubblicati nella

direzione del nuovo cambiamento sarebbe, oltre che dispendiosissima, soprattutto

inutile, in quanto i profili degli utenti non possono contenere una categoria prima che

essa venga inserita nel ST! Per permettere anche ai vecchi profili il reffinamento nel

senso della nuova modifica, ogni cambiamento viene notificato agli utenti registrati,

dando loro la possibilità di correggere il proprio profilo di interessi.

3.7. Registrazione di un nuovo utente

Quando un nuovo utente chiede un account per SwissCast2, il modulo di

interfacciamento che permette quest’operazione interroga il ST degli utenti e preleva

tutte le caratteristiche di una USERDEF (User Definition), ciò che definisce un utente.

Questo permette di creare dinamicamente l’interfaccia per l’inserimento dei dati

dell’utente stesso. La struttura del ST degli utenti è descritta nel capitolo 4.2.3. Secondo

tale struttura, i campi richiesti sono i seguenti:


NAME nome dell’utente Y 1 valore composto diFIRSTNAME eLASTNAME

FIRSTNAME nome proprio Y + stringa di caratteri LASTNAME cognome Y + stringa di caratteriCITIZENOF nome del paese

di cittadinanzaY + una delle stringhe

definite comeCOUNTRYNAME nelST

BIRTHDATE data di nascita Y 1 complete_date secondoil formato standarddella W3C

GENDER genere o sesso Y 1 una delle due stringhe“M” o “F”

PROFESSION attività chedefinisce laprofessionedell’utente

N * stringa alfanumerica; icaratteri &, <, >, “ e ‘vengonoautomaticmenteconvertiti in & ,< , > , " e'

WORKSFOR organizzazioneper cui l’utentelavora od in cui èin qualche modooccupato

N * come nel campoPROFESSION

ROLE attività in cuil’utente è

N * valore composto diACTIVITYNAME e


1 [1:1] ; ? [0:1] ; + [1:n] ; * [0:n]


impegnato e chene definisce ilruolo asssuntonell’organizzazione per cui lavora

RELATEDTO

ACTIVITYNAME nome cheidentifica il ruolosvolto

Y 1 come nel campoPROFESSION

RELATEDTO organizzazione incui l’utentericopre il ruolo inquestione

N 1 come nel campoPROFESSION

ADDRESS indirizzo fisico acui sia possibileriferirsi pereventualecorrispondenza

Y 1 valore composto diEMAILADDRESS,STREETADDRESS,POSTCODE,CITYNAME,COUNTRYNAME,TELNUM e FAXNUM

EMAILADDRESS indirizzo di postaelettronica

Y 1 email_address secondolo standard RFC 822

STREETADDRESS nome della viadell’indirizzofisico

N ? come nel campoPROFESSION

POSTCODE codice diavviamentopostale


CITYNAME nome della cittào del paese


COUNTRYNAME nome dellanazione

N ? una delle stringhedefinite come Locationnel ST

TELNUM numero ditelefono

N ? stringa alfanumerica

FAXNUM numero di fax N ? stringa alfanumericaDELIVERING periodo fisso

entro cui nuovidocumentirilevanti vengonosegnalatiall'utente

Y 1 una delle due stringhe“Once a Week” o“Once a Day”

ACCESS accesso sicuro aidati dell’utente

Y 1 valore composto diUSERID ePASSWORD

USERID nome diidentificazionedell’utente

Y 1 una stringaalfanumerica (max. 12caratteri)

PASSWORD parola chiave per Y 1 una stringa


l’identificazionedell’utente

alfanumerica (max. 20caratteri)

PROFILE definisce unprofilo diinteressidell’utente

N * contiene un oggettoDOCUMENTDEF

DOCUMENTDEF definisce un“documentotipo” con lecaratteristiche diinteressedell’utente”

Y + come definito nel STcon DOCUMENTDEF

È possibile definire uno o più accessi al sistema, rimandando ad un secondo tempo la

definizione del profilo di interessi; non vi sono restrizioni per gli utenti: chiunque può

iscriversi al servizio. Ogni profilo utente può essere modificato o se ne può creare uno

nuovo. È possibile definire più di un profilo per ogni utente, oppure definire un profilo

complesso, che contiene diversi “documenti tipo” ognuno che specifichi un diverso

interesse nella ricerca scientifica. Il modulo di modifica/inserimento del profilo

interroga il ST dei documenti prelevando tutte le caratteristiche di una

DOCUMENTDEF; l’utente può specificare una particolare categoria di interesse

all’interno della struttura di categorizzazione, ma anche una particolare caratteristica del

documento stesso (ad esempio, tutti i documenti scritti da Tim Berners-Lee o solo i

documenti disponibili anche in formato pdf, ecc.). Ciò permette di definire un profilo

complesso al livello di specificazione preferito dall’utente.

Quando l’utente ha inserito tutti i dati, questi vengono inviati alla XML Engine. Questo

modulo si occupa come già detto di formare dei file XML validi in accordo col DTD

relativo (in questo caso è “user.dtd”). Il file XML con la descrizione dell’utente e del

suo profilo di interessi viene poi stoccato nell’archivio con le altre descrizioni; è pronta

a questo punto per partecipare all’operazione di matching coi nuovi documenti.


3.8. Pubblicazione dei documenti e raffinamento dei

profili

Questo processo si attiva automaticamente ogni qualvolta una (nuova) descrizione di

documento riceve al tag MODERATED il valore YES, ciò che avviene subito dopo

l’inserimento dei dati del documento da parte di un IP non moderato oppure in seguito

al controllo effettuato dal Director sui documenti da moderare. Tramite delle

interrogazioni (in XQL, come nella demo allegata, o in un linguaggio analogo) vengono

assunte le definizioni di “documenti tipo” dai profili degli utenti e confrontati con le

caratteristiche del nuovo documento. Viene così creata una lista di utenti i cui interessi

coincidono col contenuto del documento; questi dati vengono poi mandati al modulo di

notifica (notifying), il quale contiene un archivio temporaneo, chiamato archivio di

matching. Quest’archivio contiene una matrice che accoppia gli utenti coi nuovi

documenti che coincidono coi loro interessi. Seguendo le scelte dell’utente (una volta

alla settimana od una volta al giorno), gli viene inviato un messaggio di posta

elettronica che elenca i nuovi documenti di suo interesse e contenente un hyperlink alla

versione html di tali documenti (nella forma creata dallo stylesheet XSL). Ciò fatto, il

suo nome viene cancellato dall’archivio temporaneo.

L’utente può ugualmente accedere ad un’interfaccia che elenchi il titolo di tutti i

documenti a lui attribuiti col matching. Così come accade nel sistema SwissCast

attualmente disponibile, si può decidere di vedere il contenuto dei documenti oppure di

cancellarli; questa interfaccia sarà la via privilegiata di consultazione dei documenti da

parte dell’utente ed un hyperlink ad essa verrà messo in evidenza all’interno del

messaggio di notifica. Quest’interfaccia si occupa anche di rilevare alcune azioni

performate dall’utente, ed in paricolare l’azione di lettura (l’utente segue l’hyperlink

verso il documento html) e quella di cancellazione (l’utente cancella un documento

dalla sua lista). Questi dati vengono conservati in un particolare archivio (l’archivio dei

comportamenti) che per ogni utente elenca le azioni performate su un dato documento e

che serve come base del processo di data mining.

Sebbene ad ogni utente sia data la possibilità di definire un profilo complesso, è facile

prevedere che la maggior parte si limiti ad una definizione abbastanza generica dei


propri interessi. Perché il sistema funzioni in modo soddisfacente ed il sistema di

categorizzazione sia sfruttato appieno, è dunque preferibile fornire il sistema di un

modulo adattativo, che dalle azioni degli utenti inferisca determinati interessi.

A scadenza regolare (due volte al mese) si avvia automaticamente un processo di data

mining. Il modulo preposto a quest’operazione deve inferire dei raffinamenti del profilo

di un dato utente a partire da pochi suoi comportamenti. Ciò è possibile facendo

riferimento ai sistemi terminologici ed in particolare a quella parte del ST dei documenti

che definisce gli alberi di categorizzazione. Se i documenti letti e non cancellati si

concentrano in un sottoramo dell’albero si può dedurre che l’utente sia interessato solo a

quel tipo di documenti e non agli altri; ugualmente, se i documenti cancellati si

riferiscono ad un particolare sottoramo, quell’argomento può non essere di interesse per

l’utente.

Il seguente esempio chiarirà ciò che si intende dire con questo. Il professor F.M. è

docente di elettronica all’Università della Svizzera Italiana e si iscrive al servizio

SwissCast2. Nel suo unico profilo specifica che intende ricevere informazioni sulla

ricerca nel campo dell’Elettronica in tutt’Europa, per ogni categoria, settore o tipo.

Dopo due settimane di fruizione del servizio, il professor F.M. ha già ricevuto 15

documenti; ne ha cancellati 5 senza neppure leggerli e 6 dopo averli letti. Il modulo di

data mining entra in funzione: viene rilevato che i 4 documenti che il professore non ha

cancellato riguardano il campo della microelettronica e si riferiscono alla svizzera

italiana; tutti i documenti cancellati non parlano di microelettronica ma di altri campi

dell’elettronica, mentre tuti quelli letti e poi cancellati non si riferiscono alla svizzera

italiana ma ad altre regioni europee. Con ciò si deduce che sarebbe possibile un

raffinamento del profilo del professor F.M.. Vengono così inviate queste osservazioni

(per mezzo di un messaggio di posta elettronica) al professore, a cui viene chiesto di

modificare, se lo ritiene opportuno, il proprio profilo.

Le modifiche suggerite dal modulo adattativo, dunque, non vengono effettuate

automaticamente ma è richiesto il consenso dell’utente; in questo modo esso ha sempre

il controllo del proprio profilo. Di queste interazioni si occupa l’interfaccia di dialogo,

che indica all’utente quali modifiche o raffinamenti del proprio profilo gli sono

consigliate e gli da la possibilità di effettuarle semplicemente.


Ad ogni utente viene pure notificato quando un Director modifica (come abbiamo visto)

la struttura di classificazione dei documenti, in modo da dare la possibilità di raffinare il

profilo secondo le nuove categorie inserite.


4. Modello concettuale e rappresentazione

XML

4.1. Definizione dei DTD

Come detto nel capitolo precedente, tutti i dati presenti nel sistema SwissCast2 sono

rappresentati tramite eXtensible Markup Language (XML) per facilitarne la flessibilità e

l’interoperabilità. La scelta di XML come medium di condivisione della conoscenza è

stata innanzitutto guidata dalla rilevanza che tale linguaggio sta prendendo nel mondo

del “Semantic Web”. Da quando il World Wide Web Consortium (W3C) ha iniziato a

lavorare al suo sviluppo, nel 1996, XML ha assunto una forma estremamente stabile ed

universalmente accettata, avviandosi ad imporsi come standard de facto. Lo stesso

mercato del software commerciale ha iniziato a prendere in considerazione XML come

piattaforma di condivisione dei dati, e l’uscita di nuovi tools della Microsoft (come

Office XP) basati su questo linguaggio sono un ulteriore incentivo per il suo utilizzo.

Nel corso degli anni, il W3C ha pure sviluppato alcuni frameworks basati su XML ma

focalizzati alla descrizione di documenti, ed in particolare DDML20 e RDF21. Non è

ancora chiaro il futuro di questi linguaggi né essi hanno sufficiente potere espressivo per

coprire ogni esigenza del sistema SwissCast. Si è dunque optato per rappresentazioni

basate su DTD specificamente progettati per questo sistema, lasciando ai sistemi

terminologici il compito di garantire l’interoperabilità.

Partiamo dunque ad illustrare i DTD per quanto riguarda i documenti, gli utenti e gli

Information Provider. Per ognuno di questi attori viene qui di seguito fornito il codice

del relativo DTD ed un esempio di rappresentazione dei dati (cioè di istanziazione del

DTD) relativi a tale attore.

20 Documents Definition Markup Language [W3C 1999°]21 Resource Description Framework [W3C 1999c]

4.1.1. Rappresentazione dei documenti

document.dtd

<!ELEMENT DOCUMENTDEF (TITLE, CREATOR, PUBLISHER, FORMAT, ID, SOURCE?,LANGUAGE, RIGHTS?, STARTDATE?, ENDDATE?, MODERATED, ABSTRACT?,CONTENT, CLASSIFICATION)>

<!ELEMENT TITLE (#PCDATA)><!ELEMENT CREATOR (#PCDATA)><!ELEMENT PUBLISHER (#PCDATA)><!ELEMENT FORMAT (#PCDATA)><!ELEMENT ID (#PCDATA)><!ELEMENT SOURCE (#PCDATA)><!ELEMENT LANGUAGE (#PCDATA)><!ELEMENT RIGHTS (#PCDATA)><!ELEMENT STARTDATE (#PCDATA)><!ELEMENT ENDDATE (#PCDATA)><!ELEMENT MODERATED (#PCDATA)><!ELEMENT ABSTRACT (#PCDATA)><!ELEMENT CONTENT (#PCDATA)>

<!ELEMENT CLASSIFICATION (SUBJECT+, CATEGORY+, TYPE+, SECTOR+,LOCATION+)>

<!ELEMENT SUBJECT (#PCDATA)><!ELEMENT CATEGORY (#PCDATA)><!ELEMENT TYPE (#PCDATA)><!ELEMENT SECTOR (#PCDATA)><!ELEMENT LOCATION (#PCDATA)>

EsempioDoc.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE DOCUMENTDEF SYSTEM "document.dtd">

<DOCUMENTDEF>

<TITLE>Seminario Abstract State Machines 2000, Monte Verita' 19

- 24 marzo 2000</TITLE><CREATOR>Centro Stefano Franscini</CREATOR><PUBLISHER>ETH</PUBLISHER><FORMAT>html</FORMAT><ID>./../html/EsempioDoc.html</ID><SOURCE>http://www.csf-mv.ethz.ch</SOURCE><LANGUAGE>it</LANGUAGE><RIGHTS/>

<STARTDATE>03.08.2000</STARTDATE><ENDDATE/><MODERATED>YES</MODERATED>

<ABSTRACT/><CONTENT><![CDATA[Le ASM sono state proposte come un formalismo adatto amodellare algoritmi arbitrari a livelli di astrazione arbitrari.Le ASM sono state impiegate per analizzare e specificare varisistemi hardware e software, cosi' come vari linguaggi diprogrammazione.Lo scopo del workshop e' di riunire esperti del settore cheusano le ASM come formalismo pratico di specificazione, eteorici che usano le ASM come punto di partenza formale per leloro ricerche. Inoltre, il workshop e' un forum su argomentipratici e teorici che sono correlati in vario modo con le ASM.Il programma tecnico consistera' di seminari su invito,tutorials, presentazioni di articoli e dimostrazioni disoftware. I seminari su invito saranno tenuti da A. Blass, E. Boerger, G. Goos, M. Odersky, W. Reisig, e N. Shankar. Ulterioriinformazioni sono fornite sul sitohttp://www.tik.ee.ethz.ch/~asm/2000. ]]></CONTENT>

<CLASSIFICATION>

<SUBJECT>Electronics</SUBJECT><CATEGORY>Seminar</CATEGORY><TYPE>Announcement</TYPE><SECTOR>Education and training</SECTOR><LOCATION>TI</LOCATION>

</CLASSIFICATION>

</DOCUMENTDEF>

4.1.2. Rappresentazione degli utenti

user.dtd

<!ELEMENT USERDEF (FIRSTNAME+, LASTNAME+, CITIZENOF+, BIRTHDATE,GENDER, PROFESSION*, WORKSFOR*, ROLE*, ADDRESS, DELIVERING, ACCESS,PROFILE*)>

<!ELEMENT FIRSTNAME (#PCDATA)><!ELEMENT LASTNAME (#PCDATA)><!ELEMENT CITIZENOF (#PCDATA)><!ELEMENT BIRTHDATE (#PCDATA)><!ELEMENT GENDER (#PCDATA)>

<!ELEMENT PROFESSION (#PCDATA)><!ELEMENT WORKSFOR (#PCDATA)><!ELEMENT ROLE (ACTIVITYNAME, RELATEDTO)>

<!ELEMENT ACTIVITYNAME (#PCDATA)>

<!ELEMENT RELATEDTO (#PCDATA)>

<!ELEMENT ADDRESS (EMAILADDRESS, STREETADDRESS?, POSTCODE?,CITYNAME?, COUNTRYNAME?, TELNUM?, FAXNUM?)>

<!ELEMENT EMAILADDRESS (#PCDATA)><!ELEMENT STREETADDRESS (#PCDATA)><!ELEMENT POSTCODE (#PCDATA)><!ELEMENT CITYNAME (#PCDATA)><!ELEMENT COUNTRYNAME (#PCDATA)><!ELEMENT TELNUM (#PCDATA)><!ELEMENT FAXNUM (#PCDATA)>

<!ELEMENT DELIVERING (#PCDATA)><!ELEMENT ACCESS (USERID, PASSWORD)>

<!ELEMENT USERID (#PCDATA)><!ELEMENT PASSWORD (#PCDATA)>

<!ELEMENT PROFILE (DOCUMENTDEF+)><!ENTITY % DOCUMENTDEF SYSTEM "document.dtd">

%DOCUMENTDEF;<!ATTLIST PROFILE ID CDATA #REQUIRED>

EsempioUser.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE USERDEF SYSTEM "user.dtd">

<USERDEF>

<FIRSTNAME>Giovanni</FIRSTNAME><LASTNAME>Randazzo</LASTNAME><CITIZENOF>it</CITIZENOF><CITIZENOF>ch</CITIZENOF><BIRTHDATE>1975-02-18</BIRTHDATE><GENDER>M</GENDER><PROFESSION>Student</PROFESSION><PROFESSION>Webmaster</PROFESSION><WORKSFOR>USI-Universita della Svizzera Italiana</WORKSFOR><WORKSFOR>Randa Corporation</WORKSFOR><ROLE> <ACTIVITYNAME>Licenziando</ACTIVITYNAME> <RELATEDTO>USI-Universita della Svizzera

Italiana</RELATEDTO></ROLE><ROLE> <ACTIVITYNAME>Presidente</ACTIVITYNAME> <RELATEDTO>Randa Corporation</RELATEDTO></ROLE>

<ADDRESS> <EMAILADDRESS>[email protected]</EMAILADDRESS> <STREETADDRESS>via Vignoo 4</STREETADDRESS>

<POSTCODE>CH-6850</POSTCODE> <CITYNAME>Mendrisio</CITYNAME> <COUNTRYNAME>ch</COUNTRYNAME> <TELNUM>091/646.38.70</TELNUM> <FAXNUM></FAXNUM></ADDRESS>

<DELIVERING>Once a Week</DELIVERING><ACCESS> <USERID>randa</USERID> <PASSWORD>Lu23pE6</PASSWORD></ACCESS>



<PROFILE ID="r1"> <DOCUMENTDEF> <TITLE></TITLE> <CREATOR>Tim Berners Lee</CREATOR> <PUBLISHER></PUBLISHER> <FORMAT>pdf</FORMAT>

<ID></ID> <SOURCE>SDFG</SOURCE> <LANGUAGE>en</LANGUAGE> <STARTDATE></STARTDATE>

<ENDDATE></ENDDATE><MODERATED></MODERATED><ABSTRACT></ABSTRACT><CONTENT></CONTENT>

<CLASSIFICATION> <SUBJECT></SUBJECT> <CATEGORY></CATEGORY> <TYPE></TYPE> <SECTOR></SECTOR> <LOCATION></LOCATION> </CLASSIFICATION> </DOCUMENTDEF></PROFILE>

<PROFILE ID="r2"> <DOCUMENTDEF> <TITLE></TITLE> <CREATOR></CREATOR> <PUBLISHER></PUBLISHER> <FORMAT></FORMAT> <ID></ID>

<SOURCE></SOURCE> <LANGUAGE></LANGUAGE> <STARTDATE></STARTDATE>

<ENDDATE></ENDDATE><MODERATED></MODERATED><ABSTRACT></ABSTRACT><CONTENT></CONTENT>

<CLASSIFICATION> <SUBJECT>Elettronica</SUBJECT> <CATEGORY>Manifestazione</CATEGORY> <TYPE>Articolo</TYPE> <SECTOR>Educazione e training</SECTOR>

<LOCATION>Europa</LOCATION> </CLASSIFICATION> </DOCUMENTDEF></PROFILE>

<PROFILE ID="r3"> <DOCUMENTDEF> <TITLE></TITLE> <CREATOR>Tim Berners Lee</CREATOR> <PUBLISHER></PUBLISHER> <FORMAT>pdf</FORMAT> <ID></ID>

<SOURCE></SOURCE> <LANGUAGE>en</LANGUAGE> <STARTDATE></STARTDATE>

<ENDDATE></ENDDATE><MODERATED></MODERATED><ABSTRACT></ABSTRACT><CONTENT></CONTENT><CLASSIFICATION>

<SUBJECT>Electronics</SUBJECT> <CATEGORY>Innovation_technology</CATEGORY> <TYPE>Article </TYPE> <SECTOR>Education and training</SECTOR> <LOCATION>Europe</LOCATION> </CLASSIFICATION> </DOCUMENTDEF></PROFILE>



</USERDEF>

4.1.3. Rappresentazione degli information providers

ip.dtd

<!ELEMENT IPDEF (NAME, NICKNM, SOURCE?, LOGO?, TYPE, MODERATED?,ACCESS, KEYWORD*)>

<!ELEMENT NAME (#PCDATA)><!ELEMENT NICKNM (#PCDATA)><!ELEMENT SOURCE (#PCDATA)><!ELEMENT LOGO (IMG)><!ELEMENT TYPE (#PCDATA)><!ELEMENT MODERATED (#PCDATA)><!ELEMENT ACCESS (USERID, PASSWORD)><!ELEMENT KEYWORD (IPTERM, SCTERM)>

<!ELEMENT USERID (#PCDATA)><!ELEMENT PASSWORD (#PCDATA)>

<!ELEMENT IPTERM (#PCDATA)><!ELEMENT SCTERM (#PCDATA)>

<!ELEMENT IMG EMPTY><!ATTLIST IMG SRC CDATA #REQUIRED>

EsempioIP.xml

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE IPDEF SYSTEM "ip.dtd">

<IPDEF>

<NAME>CORDIS - Scientific Index Code</NAME><NICKNM>CS</NICKNM><SOURCE>http://www.cordis.com</SOURCE><LOGO><IMG SRC="logo.jpg"/></LOGO><TYPE>Passive</TYPE><MODERATED>YES</MODERATED>

<ACCESS>

<USERID>Cordis</USERID><PASSWORD>54Rt4</PASSWORD>

</ACCESS>

<KEYWORD><IPTERM>Industrial

manufacture</IPTERM><SCTERM>Industrial maufacture</SCTERM></KEYWORD><KEYWORD><IPTERM>Electronics,

microelectronics</IPTERM><SCTERM>Electronics,microelectronics</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Transport, Aerospacetechnology</IPTERM><SCTERM>Transport and aerospace</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Constructiontechnology</IPTERM><SCTERM>Construction technology andmaterials</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Materialtechnology</IPTERM><SCTERM>Construction technology andmaterials</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Other technology</IPTERM><SCTERM>Industry andtechnology</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Telecommunications</IPTERM><SCTERM>Telecommunications</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Information processing, informationsystems</IPTERM><SCTERM>Information processing, informationsystems</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Information, media</IPTERM><SCTERM>Information,media</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Fossil fuels</IPTERM><SCTERM>Non-nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Renewable sources ofenergy</IPTERM><SCTERM>Non-nuclear energy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Energy storage</IPTERM><SCTERM>Non-nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Energy transport</IPTERM><SCTERM>Non-nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Energy saving</IPTERM><SCTERM>Non-nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Other energy topics</IPTERM><SCTERM>Non-nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Nuclear fission</IPTERM><SCTERM>Nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Nuclear fusion</IPTERM><SCTERM>Nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Radiation protection</IPTERM><SCTERM>Nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Radioactive waste</IPTERM><SCTERM>Nuclearenergy</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Environmentalprotection</IPTERM><SCTERM>Environmental protection and wastemanagement</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Waste management</IPTERM><SCTERM>Environmentalprotection and waste management</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Safety</IPTERM><SCTERM>Safety</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Medicine, health</IPTERM><SCTERM>Medicine,health</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Biotechnology</IPTERM><SCTERM>Biotechnology andlife sciences</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Life sciences</IPTERM><SCTERM>Biotechnology andlife sciences</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Agricolture, food</IPTERM><SCTERM>Agricoltureand food</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Resources of thesea</IPTERM><SCTERM>Agricolture and food</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Fisheries</IPTERM><SCTERM>Agricolture andfood</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Mathematics, statistics</IPTERM><SCTERM>Exactsciences</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Earth sciences</IPTERM><SCTERM>Earthsciences</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Metereology</IPTERM><SCTERM>Earthsciences</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Measurementsmethods</IPTERM><SCTERM>Measurements and standards</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Referencematerials</IPTERM><SCTERM>Measurements andstandards</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Standards</IPTERM><SCTERM>Measurements andstandards</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Education, training</IPTERM><SCTERM>Education,training</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Economic aspects</IPTERM><SCTERM>Economy,business, regional development</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Regional development</IPTERM><SCTERM>Economy,business, regional development</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Social aspects</IPTERM><SCTERM>Economy, socialand human sciences</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Policies</IPTERM><SCTERM>R&Dpolicies</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Legislation,regulations</IPTERM><SCTERM>Legislation,regulations</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Forecasting</IPTERM><SCTERM>Forecasting andevaluation</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Evaluation</IPTERM><SCTERM>Forecasting andevaluation</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Innovation, technologytransfer</IPTERM><SCTERM>Innovation, technologytransfer</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Coordination,cooperation</IPTERM><SCTERM>oordination,cooperation</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Education, training</IPTERM><SCTERM>Education,training</SCTERM></KEYWORD>

<KEYWORD><IPTERM>Scientific research</IPTERM><SCTERM>Scientificresearch</SCTERM></KEYWORD>

</IPDEF>


4.2. Sistemi Terminologici

Come si è già detto in sede di descrizione di SwissCast2, i ST definiscono i termini e le

relazioni che possono intercorrere tra i termini usati nella rappresentazione dei dati

dell’applicazione. I termini vengono definiti attraverso relazioni con altri termini

definiti in un ST di SwissCast od altrove. Esistono infatti molti termini comuni (come

STRING o DATE) per cui si fa riferimento a set di termini disponibili sul Web. Un

esempio per i documenti è il set Dublin Core22; in altre parole, è come se si dicesse che

“il sistema usa il termine TITLE nello stesso senso in cui lo si usa nel set Dublin Core”.

Ciò facilita l’uso di vocabolari di termini in modo gerarchico, e permette una più vasta

interoperabilità.

Ci si trova qui (paradossalmente) confrontati con un problema di terminologia; perché si

usano infatti parole come “set di termini”, “vocabolari”, “sistemi terminolgici” od

“ontologie” per riferirsi più o meno alla stessa cosa? Anche in questo caso, purtroppo,

come per il termine customized document delivery, non c’è un accordo unanime. Servirà

però chiarire brevemente il significato di “ontologia”.

L’ontologia (la “scienza dell’essere”) è quella parte della metafisica che specifica le più

fondamentali categorie dell’esistenza, le elementari sostanze o strutture di cui il mondo

è fatto. L’ontologia si propone di analizzare i concetti più generali ed astratti o le

distinzioni che sottolineano ogni specifica descrizione di ogni fenomeno nel mondo, per

esempio tempo, spazio, processo, sistema, causa ed effetto, ecc.

Il termine di “ontologia (formale)” è stato adottato nel campo dell’Intelligenza

Artificiale per designare gli elementi costitutivi di cui i modelli del mondo sono fatti, il

livello di base di uno schema di rappresentazione della conoscenza. Altrimenti detto,

un’ontologia è in questo senso la specifica di una concettualizzazione, una descrizione

(come la specifica formale di un programma) dei concetti e delle relazioni che possono

22 La Dublin Core Metadata Initiative (DCMI) è un organizzazione dedicata a promuovere il diffuso

utilizzo di metadati standard per l’interoperabilità ed a sviluppare vocabolari di metadati specialistici per

descrivere risorse che permettano di sviluppare sistemi più intelligenti di reperimento di informazioni

[AAVV 2001]


esistere tra gli elementi che costituiscono la descrizione di uno specifico dominio o di

una sua parte.

Le rappresentazioni qui proposte hanno la forma di reti semantiche; sono in effetti dei

grafi con nodi ed archi. Non si tratta dunque di un semplice set di termini o di un

vocabolario (che non prevedono relazioni); l’uso del termine ontologia, però, è troppo

ambiguo e rischia di generare dei fraintendimenti col significato datogli dalla

metafisica. Si è quindi preferito battezzare questi schemi con un nome differente: tali

rappresentazioni definiscono termini ma pongono quest’ultimi in relazione fra loro e

con parte del mondo esterno; si tratta quindi di sistemi terminologici.

Un’ultima osservazione preliminare riguarda il riferimento ad ontologie o set di termini

esterni al sistema e disponibili sulla Rete. Si è infatti deciso di non inserire tali

riferimenti nei grafi che verranno proposti nelle prossime pagine. Sarebbe infatti

necessario puntare perlomeno ad un’ontologia generale standard, cosa che per il

momento non esiste. Negli allegati B.1, B.2 e B.3 è stato utilizzato il linguaggio

SHOE23 per descrivere questi ST; in quel caso ci si riferisce alla general ontology e ad

altre (document ontology, dublin core ontology) disponibili nella gerachia delle

ontologie SHOE. A livello di descrizione formale in questo capitolo si è voluto invece

rimanere indipendenti dalla forma scelta per descrivere i ST. Va comunque ricordato

che la IEEE sta lavorando alla SUO24 che dovrebbe collocarsi alla radice della gerarchia

di tutte le ontolgie presenti sul Web e che dovrebbe fornire alcuni concetti fondamentali

come “entity”, “relationship”, “string”, “integer”, ecc. Il progetto ha come scopo

specificare un’ontologia generale che potrà essere utilizzata per applicazioni di data

interoperability, ricerca di informazioni, inferenze automatiche e processamento in

linguaggio naturale.

23 Simple HTML Ontology Extentions [Heflin 1999]24 Standard Upper Ontology IEEE P1600.1 (http://www.suo.ieee.org)


4.2.1. Specifica del formalismo

Prima di proporre gli schemi nelle prossime pagine, è necessario definire in modo

formale il significato dei segni grafici utilizzati per rappresentare i ST. Per far questo

viene usato un linguaggio predicativo del primo ordine. È importante specificare che per

ogni ST vale l’assunzione del mondo chiuso: tutti i fatti relativi ai simboli espressi nel

sistema e che non sono esplicitamente asseriti, non sussistono ovvero sono da

considerarsi falsi. Nelle formule seguenti i simboli A, B, C, P, Q ed R sono dei

predicati, mentre i simboli !� e '� vengono definiti in questo modo:

)(' xxP� def� � �yxyPxPyx �� )()(

)(! xxP� def� )(')( xxPxxP ��

� �)()( xBxAx ��

)(aB

� �� ),()()( xyPartOfyAyxBx ��

� �� ),()()( yxRyByxAx ��

� �� ),()(!)( yxRyByxAx ��

� �� ),()(')( yxRyByxAx ��

A causa dell’assunzione del mondo chiuso

è necessario specificare che una relazione

può sussistere.


Per le inferenze vale il seguente formalismo, descritto in linguaggio naturale in quanto

deducibile dalle definizioni precedenti.

La freccia tratteggiata nello schema indica

che essa è dedotta dalle altre due.


4.2.2. ST dei documenti


4.2.3. ST degli utenti


4.2.4. ST degli information provider


5. Implementazione di un prototipo

dimostrativo

Nel CD-R indicato come allegato C viene fornita un’applicazione dimostrativa di alcune

funzioni del sistema SwissCast2. L’obiettivo di questo piccolo programma non è quello

di rappresentare un prototipo completo del servizio descritto in questa memoria di

licenza, ma di mostrare direttamente l’efficacia e la fattibilità delle tecniche e degli

strumenti sviluppati nei capitoli precedenti. La figura 4 mostra quali parti del sistema si

ritrovano nell’applicazione, e quali sono le funzioni implementate.

Gli archivi delle descrizioni XML di documenti, utenti ed IP contengono ciò che si è

visto nel capitolo 4, vale a dire i DTD (Document.dtd, User.dtd, ip.dtd), le descrizioni

vere e proprie (i file .xml) ed il foglio di stile che permette la conversione dei file XML

in file HTML (Document.xsl). Anche i ST che si ritrovano nell’applicazione sono quelli

già descritti nel capitolo 4 e la forma prescelta, come già detto in precedenza, è quella di

documenti SHOE; i codici completi con una descrizione in linguaggio naturale per ogni

ST si trova anche nell’allegato B.

Il prototipo è stato programmato in Java e funziona simulando un’applicazione di rete e

l’interfaccia di un browser Microsoft Explorer. Sarebbe stato possibile utilizzare

direttamente il browser in questione implementando le funzioni in alcune Applet Java,

ma questo avrebbe impedito l’outputstreaming25 e quindi la scrittura dei nuovi file

XML ed HTML. Si è optato perciò per la semplicità e l’utilizzabilità off-line

dell’applicazione da qualsiasi processore. Si consiglia di copiare l’intero programma su

un’unità locale con permessi di lettura e scrittura e di farlo girare a partire dal file

Autorun.bat.

25 Si tratta di una limitazione di sicurezza delle Applet Java, aggirabile solo con l’utilizzo di un server

come “ponte” ed una struttura a Socket


Figura 4 : parti del sistema implementati nel prototipo di dimostrazione


L’inserimento di un nuovo documento appare come una form tradizionale; la parte

interessante di questa funzione è in realtà quella che non si vede: il modulo, infatti,

costruisce la maschera di inserimento dei dati in modo dinamico, interrogando il ST dei

documenti per ricavare ciò che costituisce la descrizione di un documento. È stato

innanzitutto necessario programmare un parser per i file SHOE, dal momento che non

ne esistevano di sufficientmente efficaci in Java. Il parser così programmato ha diverse

pecche, tra cui quella di costruirsi una rappresentazione dei dati contenuti nel file SHOE

strutturata ad albero (e non, come sarebbe necessario per i ST, a grafo); questa soluzione

permette comunque di raggiungere alcuni importanti obiettivi, come la visualizzazione

della form di inserimento dei dati e la possibilità di definire la classificazione del

documento scegliendo tra una serie gerarchicamente ordinata di keywords (si veda

l’esempio nella figura 5).

Figura 5: scelta del soggetto di classificazione del documento da un albero ricavato dal ST

Alla fine del processo di inserimento dei dati, un nuovo documento XML viene posto

nell’archivio dei documenti col tag MODERATED a valore NO.


Il modulo di moderazione dei documenti interroga inizialmente l’archivio dei

documenti e ricava una lista dei documenti ancora da moderare (il tag MODERATED

deve avere valore NO). La selezione di uno dei documenti dalla lista provoca la

visualizzazione di una sua anteprima così come verrà proposto agli utenti; l’anteprima è

un file HTML temporaneo creato con un foglio di stile XSL. È inoltre possibile

modificare qualsiasi dato del documento e vederne un’anteprima coi dati così corretti.

Alla fine della moderazione, il file XSL viene aggiornato coi nuovi dati ed il valore del

tag MODERATED viene settato a YES; viene inoltre creato un file HTML tramite il

folgio di stile XSL, pronto per essere consultato dagli utenti.

Similmente all’inserimento dei dati di un documento, il modulo di inserimento dei

dati di un nuovo utente interroga il ST degli utenti e ne ricava la form relativa; si noti

che nella definizione del profilo è possibile specificare i vincoli per molte caratteristiche

del documento (CREATOR, FORMAT, ecc.) e non solo per la sua categorizzazione.

Allo stesso modo, è possibile modificare qualunque dato personale o del profilo di un

utente. Alla fine di questi processi l’applicazione crea un file XML e lo pone

nell’archivio degli utenti.

La funzione di accoppiamento (matching) dei profili coi documenti è stata

implementata in modo da rendere visibile la matrice di accoppiamento ed i dati relativi

ad utenti e documenti presi in considerazione. L’applicazione consulta gli archivi degli

utenti e dei documenti ed accoppia ad ogni utente quei documenti che corrispondono al

loro profilo; si noti che un valore specificato come vincolo nel profilo dell’utente deve

corrispondere al valore del tag corrispondente nella descrizione del documento o ad una

sua parte (cioè ad un termine che abbia una relazione di PartOf col valore specificato

dall’utente).

Viene qui di seguito fornita una descrizione della struttura a directory del prototipo ed

un breve commento della funzione di ogni file che essa contiene:

./Swisscast2/Autorun.bat Questo file setta correttamente ilPATH ed il CLASSPATH edavvia l’applicazione


./Swisscast2/archivi/DataPrev.xsl È il foglio di stile usato per lapresentazione dei dati nelmodulo di matching

./Swisscast2/archivi/Document/Document.xsl

./Swisscast2/archivi/Document/Subdocument.xslSono i fogli di stile chetrasformano i file XML in pagineHTML

./Swisscast2/archivi/Document/html/ Contiene tutti i documentiHTML deirvati dalle descrizioniXML moderate

./Swisscast2/archivi/Document/html/imgs/ Contiene le immagini usate nellepagine HTML

./Swisscast2/archivi/Document/xml/ Contiene le descrizioni XML deidocumenti

./Swisscast2/archivi/dtds/Document.dtd

./Swisscast2/archivi/dtds/ip.dtd

./Swisscast2/archivi/dtds/User.dtd

Sono i DTD relativi alledescrizioni XML

./Swisscast2/archivi/Ip/xml/ Contiene le descrizioni XMLdegli IP

./Swisscast2/archivi/User/xml/ Contiene le descrizioni XMLdegli utenti

./Swisscast2/imgs/ Contiene le imagini necessarieper visualizzare l’anteprima deidati

./Swisscast2/logo/ Contiene i logo degli IP registrati

./Swisscast2/memory/DocumentCount.mem

./Swisscast2/memory/IpCount.mem

./Swisscast2/memory/UserCount.mem

Questi file tengono traccia delnumero di documenti, utenti edip registrati nel sistema, in mododa indicizzarne i nomicorrettamente

./Swisscast2/Moduli/rt.jar Quest’archivio contiene iprincipali packages di Java2

./Swisscast2/Moduli/java.exe Attiva la Java Virtual Machine

./Swisscast2/Moduli/MainInterface.class E’ la classe che contiene ilmetodo main e che implemental’interfaccia di navigazionedell’applicazione

./Swisscast2/Moduli/InsertDoc.class Implementa il pannello diinserimento dati per i documenti;carica lo schema di descrizionedei documenti attraversoSTParser

./Swisscast2/Moduli/InsertUser.class Implementa il pannello diinserimento dati per gli utenti;carica lo schema di descrizionedegli utenti e del loro profilo diinteressi attraverso STParser


./Swisscast2/Moduli/STParser.class Carica lo schema di descrizionedel ST specificato attraversoOntologyReader in una strutturaad albero

./Swisscast2/Moduli/OntologyReader.class Estende un Reader che legge ilfile SHOE, lo scompone inparole chiave ed implementa laricerca

./Swisscast2/Moduli/Tree.class Implementa una semplicestruttura ad albero e può ritornareun corrispettivo JTree per lavisualizzazione

./Swisscast2/Moduli/Node.class Implementa un nodo dell’alberocon un nome, un valore, un padre(null se è la radice) e dei rami(null se è una foglia)

./Swisscast2/Moduli/EditView.class È un piccolo editor di testo chepermette di inserire dei valorinell’ABSTRACT o comeCONTENT

./Swisscast2/Moduli/TreeView.class Permette la scelta di uno o piùvalori da un JTree.

./Swisscast2/Moduli/ProfileEditor.class

./Swisscast2/Moduli/ProfilePanel.class

./Swisscast2/Moduli/ProfilePanelEditor.class

Queste tre classi implementanodei pannelli che definiscano ilprofilo di un utente, in modo deltutto simile all’inserimento didati per un documento (il profilodi un utente è infatti undocumento-tipo)

./Swisscast2/Moduli/DataModerationPanel.class

./Swisscast2/Moduli/ModEditview.class

./Swisscast2/Moduli/ModerationList.class

./Swisscast2/Moduli/ModTreeView.class

Queste classi implementano ilmodulo moderazione deidocumenti ed i pannelli chepresentano la lista dei documentida moderare, un’anteprima delloro aspetto grafico e l’editor deidati

./Swisscast2/Moduli/MatchingModule.class

./Swisscast2/Moduli/MatchingPanel.classQueste classi implementano ilmodulo di accoppiamento deiprofili coi documenti

./Swisscast2/Moduli/XMLParser.class Questa classe implementa unparser per i file XML che utilizzaun DocumentReader

./Swisscast2/Moduli/DocumentReader.class Questo Reader legge un fileXML ed implementa la ricercadei tag e dei loro valori


./Swisscast2/Moduli/XMLEngine.class Questo motore trasforma unalbero di dati (in input) in un fileXML (in output) coerente colDTD relativo

./Swisscast2/Moduli/SCWriter.class Scrive sul supporto usatodall’applicazione

./Swisscast2/Moduli/UserLogin.class Implementa un login chepermette la scelta tra i vari utentiiscritti nel prototipo per editarneil profilo

./Swisscast2/Moduli/SCStyleSheet.class Permette di applicare un foglio distile ad un documento XML eritorna il rispettivo file HTML

./Swisscast2/Moduli/Counter.class

./Swisscast2/Moduli/DelTemp.class

./Swisscast2/Moduli/DefaultPanel.class

Queste classi implementanopiccole funzioni secondarie,necessarie per il correttofunzionamento del programma

./Swisscast2/Moduli/DocButtonHandler.class

./Swisscast2/Moduli/DocEditHandler.class

./Swisscast2/Moduli/DocSubmitHandler.class

./Swisscast2/Moduli/EditViewHandler.class

./Swisscast2/Moduli/ListHandler.class

./Swisscast2/Moduli/LoginHandler.class

./Swisscast2/Moduli/MatchingHandler.class

./Swisscast2/Moduli/ModButtonHanlder.class

./Swisscast2/Moduli/ModEditViewHandler.class

./Swisscast2/Moduli/ModerationHandler.class

./Swisscast2/Moduli/ModSubmitHandler.class

./Swisscast2/Moduli/ModTreeViewHandler.class

./Swisscast2/Moduli/ProfileButtonHanlder.class

./Swisscast2/Moduli/ProfileEditHandler.class

./Swisscast2/Moduli/ProfilePanelHandler.class

./Swisscast2/Moduli/ProfilePButtonHandler.class

./Swisscast2/Moduli/ProfilePWinHandler.class

./Swisscast2/Moduli/ProfileTreeButtonHandler.class

./Swisscast2/Moduli/ProfileWinHandler.class

./Swisscast2/Moduli/SelectionListener.class

./Swisscast2/Moduli/TreeViewHandler.class

./Swisscast2/Moduli/UserButtonHandler.class

./Swisscast2/Moduli/UserSubmitHandler.class

./Swisscast2/Moduli/UserSubmitPHandler.class

Queste classi implementano gliEventHandler di bottoni, alberi emenu contenuti nell’applicazione

./Swisscast2/Moduli/com/icl/saxon/StyleSheet.class Questa classe del packagecom.icl.saxon è stata modificataperché non venga eseguital’operazione System.exit(0) allafine della trasformazione

./Swisscast2/Moduli/com/icl/saxon/saxon.jar Quest’archivio contiene l’interopackage com.icl.saxon,responsabile del funzionamentodi StyleSheet

./Swisscast2/Moduli/imgs/ Contiene le immagini necessarieper la visualizzazionedell’interfaccia principale

./Swisscast2/Moduli/sources/ Contiene tutti i file sorgenti(.java) dell’applicazione

./Swisscast2/Moduli/temp/ Ospita temporaneamente leanteprime dei dati visualizzatenell’applicazione

./Swisscast2/ontologies Si tratta dei tre file chedescrivono i ST in SHOE (vedasil’allegato B)

Per rendere più chiaro il funzionamento del prototipo sarà a questo punto utile proporre

un esempio che segua il percorso dei dati lungo tutta l’applicazione nelle varie funzioni

implementate. Poniamo il caso di voler inserire un documento su una rivoluzionaria

scoperta nel campo della microelettronica.

Il modulo che gestisce l’interfaccia verso l’IP per l’inserimento dei dati (“InsertDoc”)

interroga il ST dei documenti inizializzando un “STParser”, che implementa un parser

per file SHOE. La classe “STParser” utilizza un “OntologyReader” per leggere la

struttura del file SHOE; nei fatti, il reader in questione divide il documento in parole

chiave, come nell’esempio che segue:

<DEF-RELATION NAME="TITLE"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="STRING" POS="TO"></DEF-RELATION>

[#DEF-RELATION#] [#NAME#] [#TITLE#][#DEF-ARG#] [#TYPE#] [#DOCUMENTDEF#] [#POS#] [#FROM#][#DEF-ARG#] [#TYPE#] [#STRING#] [#POS#] [#TO#][#/DEF-RELATION#]

Quest’operazione non viene però effettuata subito all’inizializzazione di un

“OntologyReader” ma, per questioni di efficacia, man mano che si cerca un termine


all’interno del ST. Inizialmente il parser cerca nell’ontologia il termine utilizzato per

descrivere un documento; perciò, tra tutte le relazioni (segnate da [#DEF-RELATION#]), si

cerca quella che abbia come nome [#Description#] e come punto di partenza [#Document#].

Si trova così che il termine utilizzato per la descrizione di un documento è

DOCUMENTDEF. Questo termine costituisce il nodo di partenza (“Node”) della struttura

ad albero (“Tree”) in cui il parser trasforma il ST. In seguito la classe “STParser” cerca

i nomi di tutte le relazioni che partono da DOCUMENTDEF e li appende alla radice

dell’albero. La terza operazione del parser è rilevare le parti (le relazioni con NAME

uguale a partOf) del termine target di ognuna di queste relazioni; per quanto riguarda

CLASSIFICATION, per esempio, il termine target Classification ha cinque parti: SUBJECT,

CATEGORY, TYPE, SECTOR e LOCATION. Queste parti vengono appese ai relativi rami

dell’albero, che a questo punto ha la seguente struttura:

DOCUMENTDEF└TITLE└CREATOR└PUBLISHER└FORMAT└ID└SOURCE└RIGHTS└LANGUAGE└STARTDATE└ENDDATE└MODERATED└ABSTRACT└CONTENT└CLASSIFICATION

└SUBJECT└CATEGORY└TYPE└SECTOR└LOCATION

L’ultima operazione effettuata dal parser è quella di riconoscere eventuali istanze di

ogni foglia dell’albero; la relazione MODERATED, per esempio ha come elemento target

TRUTH, il quale ha a sua volta due istanze: YES e NO. Ciò significa che il termine

MODERATED può assumere esclusivamente questi due valori26. La classe “STParser”

cerca perciò nel ST ogni dichiarazione indicata con DEF-CONSTANT, ne assume il nome

(origine di una relazione di instanceOf) e la categoria a cui è associata (nel caso

26 Si noti che dal momento che il parser non rileva la cardinalità delle relazioni, lo schema che ne deriva

non specifica che le due istanze debbano essere mutulamente esclusive


esemplificato si tratta del termine TRUTH). L’albero così creato rappresenta la struttura

descrittiva di un documento e viene ritornato alla classe “InsertDoc”, la quale può così

visualizzare la maschera di inserimento dei dati. Nel caso in cui una foglia dell’albero

abbia delle istanze già specificate, viene visualizzato un bottone (“Choose a value...”)

che permette di scegliere uno o più valori da un JTree (javax.swing.JTree) che

rispecchia la struttura gerarchica di tali istanze (si veda l’esempio della figura 5).

A questo punto l’IP può inserire in modo semplice ed intuitivo i dati relativi al

documento in questione (si veda come esempio il Document5) e può inviarli al sistema

tramite il tasto “SUBMIT”. Il modulo “InsertDoc” assegna i valori inseriti ad ogni

foglia dell’albero che rappresenta lo schema di definizione di un documento e poi lo

invia al modulo chiamato “XMLEngine”. A questo punto avviene la trasformazione

dell’albero in un file XML (in accordo col DTD dei documenti); tale file XML viene

posto nell’archivio dei documenti (../archivi/Document/xml/). Si ricorda che a questo

punto il tag MODERATED ha valore NO per default. Tutte le operazioni sin qui descritte

per l’inserimento di un documento si ripetono in modo analogo per l’inserimento dei

dati e del profilo di un nuovo utente.

Il modulo “ModerationList” permette di visualizzare la lista dei documenti da moderare,

una loro anteprima grafica ed una maschera di modifica dei dati del documento. Tale

modulo legge tutti i file XML presenti nell’archivio dei documenti e ritiene i nomi di

quei file che hanno NO come valore del tag MODERATED. Nel caso vi siano file con

questa caratteristica, una lista dei suddetti nomi viene presentata all’utente; la selezione

di uno di questi provoca poi la visualizzazione di un’anteprima grafica ottenuta

trasformando il file XML in un file HTML tramite un foglio di stile. Il foglio di stile in

questione è “SubDocument.xsl” (che crea la sola tabella coi dati del documento

tralasciando le barre dei menu) e viene applicato dal modulo “SCStyleSheet”;

quest’ultimo modulo utilizza una classe della libreria com.icl.saxon (“StyleSheet.class”)

per effettuare la trasformazione vera e propria. Il file HTML così creato viene posto in

una cartella temporanea, il cui contenuto viene cancellato alla selezione di una nuova

funzione od all’uscita dall’applicazione. Il modulo di moderazione richiama poi un

“DataModerationPanel” che si comporta esattamente come un modulo di inserimento


dati “InsertDoc”; la differenza sta nel fatto che i campi visualizzati hanno i valori letti

dal relativo file XML. La lettura dei dati dal file XML è affidata alla classe

“XMLParser”; il metodo “getValueOf(String s)” di quest’ultima classe ritorna il valore

tel tag chiamato “s”. Questo parser utilizza un “DocumentReader” per leggere il nome

dei tag ed il loro valore dal file XML.

I dati del documento così modificati possono essere visualizzati in anteprima tramite il

tasto “PREVIEW” (viene creato un file XML temporaneo a partire dai valori contenuti

nei campi ed un nuovo file HTML temporaneo a partire da quel documento XML)

oppure possono essere confermati come pronti per la pubblicazione tramite il tasto

“SUBMIT”. Il “SUBMIT” del “DataModerationPanel” aggiorna il file XML

nell’archivio coi nuovi dati e lo trasfomra in un file HTML che viene posto nel relativo

archivio (../archivi/Document/html/); per la conversione viene usato il foglio di stile

chiamato “Dcoument.xsl” che crea il documento HTML completo di barre dei menu.

Il modulo di accoppiamento “MatchingPanel” fornisce, in aggiunta alle sue funzionalità

di base, un’interfaccia che mostra la matrice di accoppiamento tra gli utenti ed i

documenti sotto forma di un JTree; la selezione di un utente o di un documento

dall’albero provoca la visualizzazione dei suoi dati sullo schermo. La vera e propria

operazione di matching è effettuata dalla classe “MatchingModule” ed è piuttosto

semplice, dal momento che i profili degli utenti sono definiti come dei “documenti

tipo”. Attraverso un “XMLParser” viene letto il profilo di interessi di ogni utente e

confrontato con ciascun documento presente nell’archivio. I valori specificati nel profilo

di un utente sono considerati come vincoli per l’attribuzione di un documento a quel

profilo; è cioé necessario che nel documento siano presenti i termini specificati nel

profilo od una loro parte (le parti sono riconosciute caricando lo schema di descrizione

di un documento come descritto per il modulo “InsertDoc”).

L’esempio che viene infine presentato nella pagina seguente attribuisce il documento

“DocumentX” al profilo dell’utente “UserX”.


6. Conclusioni

L’invenzione è 1% ispirazione e 99%

traspirazione.

Thomas Edison

Gli obiettivi della presente memoria di licenza si articolavano essenzialmente in due

parti: lo sviluppo di un sistema di rappresentazione della conoscenza rivolto al Semantic

Web che risolvesse in modo coerente i problemi di knowledge sharing sollevati dai

servizi di reperimento dell’informazione attualmente disponibili sul Web; l’applicazione

di tale sistema ad un oggetto concreto ed in particolare al servizio SwissCast.

Questi due macroobiettivi contenevano a loro volta dei sottoobiettivi necessari al loro

raggiungimento. Nella prima parte del lavoro si è quindi operata un’analisi preliminare

delle applicazioni di customized document delivery concentrandosi poi sull’analisi del

sistema SwissCast ed evidenzandone i difetti. È stato così possibile individuare una

serie di requisiti essenziali per rendere più efficaci le metodologie di filtraggio delle

informazioni, di individuazione degli interessi degli utenti e di notifica di informazioni

rilevanti a tali utenti. Si è quindi deciso che il sistema dovesse permettere la

processabilità dei dati relativi ai documenti ed ai profili degli utenti; la descrizione dei

dati doveva inoltre favorire la condivisione di tali dati tra i moduli del sistema come

anche tra il sistema ed altri servizi presenti in Rete.

Tali dati sono perciò stati rappresentati per mezzo del linguaggio di marcaggio XML,

che costituisce ormai uno standard piuttosto stabile e che è lo strumento centrale in

molte applicazioni rivolte alla condivisione della conoscenza; l’insistenza della W3C e

di alcune grosse multinazionali del software (segnatamente la Microsoft) su questo tipo

di formato ne fanno la scelta appropriata per gli scopi qui espressi.

Ogni descrizione XML di un documento, utente od Information Provider fa capo al suo

relativo DTD (document.dtd, user.dtd od ip.dtd) che stabilisce una sintassi comune ed

uniforme per ciascuna descrizione.


Questo non è però stato sufficiente per raggiungere completamente l’obiettivo di

condivisione dei dati; infatti se i DTD definiscono una sintassi, la semantica dei dati

stessi rimane implicita ed in un certo senso “distribuita” tra i vari moduli del sistema ed

infine dipendente da essi; ogni singola modifica della terminologia di descrizione dei

dati o della loro struttura semantica avrebbe così comportato la necessità di una

riprogrammazione dell’applicazione; inoltre, limitandosi a questo primo livello di

rappresentazione, per condividere informazioni da e per altri sistemi sarebbe stato

necessario accordarsi sull’uso di un DTD comune.

È dunque nata la necessità di definire in modo esplicito la semantica dei dati, vale a dire

il significato dei termini utilizzati per la loro descrizione. A questo scopo sono stati

utilizzati quelli che in genere vengono chiamate “ontologie” e che qui sono stati definiti

“sistemi terminologici”. Il modo di rappresentare i ST ha costituito la parte originale

della memoria di licenza. Nei pochi casi in cui infatti si trovano delle “ontologie” nel

Web esse hanno la forma di un semplice set di termini (è il caso del set Dublin Core) o,

nel migliore dei casi, di termini ordinati gerarchicamente in una struttura ad albero. Ciò

che era qui necessario, invece, richiedeva l’uso di relazioni complesse per la definizione

dei termini e la loro comprensibilità; si è dunque usato un grafo di nodi ed archi

orientati con etichette e cardinalità. Il formalismo grafico doveva essere semplice ed

intuitivo, ma consentire il pieno potere espressivo che era richiesto. Si è per questo

optato per un formalismo famigliare a chi si occupa di rappresentazione della

conoscenza, che ricordasse le reti semantiche usate nell’Intelligenza Artificiale o gli

schemi Entity-Relationship delle basi di dati. Tale formalismo ha permesso di esprimere

anche regole generali di inferenza applicabili agli schemi che permettessero di

rappresentare solo le relazioni fondamentali tra i termini e non necessariamente tutte

quelle possibili.

A questo punto, anche i grafi che definivano la semantica delle descrizioni dei dati, oltre

che le descrizioni stesse, dovevano soddisfare i criteri di processabilità e di

comprensibilità per un computer risolte prima con l’utilizzo di XML. Anche in questo

caso, dunque, si trattava di rappresentare dei dati in formato XML. Qui, però, non ci si

poteva affidare ad un ST ulteriore per definire i termini della descrizione: in ogni


definizione formale è necessario trovare degli assiomi. Nel mondo del Semantic Web

questo riporta ad un imperativo spesso deluso, quello dell’utilizzo di standard. Per la

definizione di ontologie, purtroppo, non esistono però standard riconosciuti; alcune

proposte includono OIL27, SHOE28, RDF29 e KIF30. Alcuni di questi (come RDF) pur

essendo molto interessanti come proposta, non sono sufficientemente espressivi; altri

invece (come SHOE) non sono completamente compatibili con XML ma preferiscono

basarsi su HTML; altri ancora (come KIF) non sono neppure linguaggi di marcaggio.

Non si è voluto quindi integrare la rappresentazione machine understandable dei ST nel

corpo principale della memoria, ma comunque fornire un esempio negli allegati

utilizzando il linguaggio SHOE, sufficientemente espressivo e comunque facilmente ed

automaticamente traducibile in qualsiasi altro linguaggio di marcaggio che estenda

SGML.

Il lavoro è dunque continuato applicando queste tecniche al fine di migliorare un

sistema già esistente; la scelta di SwissCast è naturalmente stata dettata dal fatto che si

tratta di un progetto universitario e segnatamente dell’Università della Svizzera Italiana;

tutte le strutture e gli algoritmi utilizzati erano dunque facilmente conoscibili, e le

proposte di miglioramento del servizio bene accette (per stessa ammissione dei

responsabili Benedetto Lepori e Riccardo Mazza). Applicare scelte teoriche ad una

situazione concreta ha permesso di valutare la bontà di tali scelte, almeno a livello

progettuale. L’uso di ST per esplicitare la semantica della descrizione dei dati si è infatti

rivelata ottima per assicurare la flessibilità dell’intero sistema, permettendo di

progettare i singoli moduli in modo indipendente dalla struttura dei dati stessi. Una

prova più pratica di questa flessibilità si trova nella applicazione di dimostrazione

allegata alla memoria di licenza e descritta in modo più preciso nel capitolo 5.

Si può dunque dire che gli obiettivi che il presente lavoro si proponeva sono stati

raggiunti in modo soddisfacente. Rimane naturalmente molto lavoro da fare per rendere

27 Ontology Interchange Format [Cover 2001]28 Simple HTML Ontology Extentions [Heflin 1999]29 Resource Description Framework [W3C 1999c]30 Knowledge Interchange Format [IEEE 2000]


il progetto proposto effetttivamente implementabile: gli schemi UML proposti nella

sezione A degli allegati infatti descrivono i requisiti che il sistema deve avere ma

diverse domande non hanno ancora risposta. È possibile rinunciare in modo così netto ai

vantaggi a livello di prestazioni fornite da un DB relazionale? Quali tecniche è possibile

utilizzare per un efficace Data Mining così come è stato descritto? Quali standard si

imporranno per la rappresentazione di ontologie sul Web? È verosimile prevedere nel

futuro un “Web semantico” o si tratta solo di un’utopia?

Dare una risposta concreta a queste domande presuppone la convergenza di diverse

competenze professionali e di diversi aspetti della ricerca scientifica. La speranza che

mi sento infine di esprimere è che questo tipo di interdisciplinarità vengano sempre più

promosse e che i problemi di coordinazione e comunicazione tra i diversi campi

specialisti siano superati, anche grazie ad istituzioni come l’Università della Svizzera

Italiana.


7. Bibliografia

� AAVV (2001). Dublin Core Metadata Initiative (DCMI) overview [on line]. URL:http://dublincore.org/about/ [14.03.2001].

� AAVV. Backweb: technology overview [on line]. URL: http://www.backweb.com[03.04.2001].

� AAVV. DataChannel: Information in motion [on line]. URL:http://www.datachannel.com [03.04.2001].

� Angebaud, D. (2001). Webcasting: the InfoCast solution [on line]. URL.http://www.infocast.ccett.fr [07.07.2001].

� Berners-Lee, T., Fielding, R., Irvine, U. C. & Masinter, L. (1998). UniformResource Identifiers (URIs): generic syntax [on line]. URL:http://www.ietf.org/rfc/rfc2396.txt [21.03.2001].

� Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Frystyk, H.,Thatte, S. & winer, D. (2000). SOAP: Simple Object Access Protocol [on line].URL: http://msdn.microsoft.com/xml/general/soapspec.asp [10.04.2001].

� Bray, Tim (2001). What is RDF? [on line]. URL:http://www.xml.com/pub/a/2001/01/24/rdf.html [14.03.2001].

� Brin, S. & Page, L. (2000).The anatomy of a large scale hypertextual Web searchengine.

� Cantoni, L. (2000). Shall technology lead communication or vice-versa?. Explitinteractive, 4.

� Cantoni, L., Dal Degan, N., Lepori, B., Mazza, R. & Scaroni, F (1998). Push on theNet: between market and technology. Market analysis and user needs; analysis ofavailable technologies [on line]. URL: http://www.swisscast.net/documents.htm[13.03.2001].

� Cantoni, L., Jannuzzi, P., Lepori, B. & Mazza, R. (1999). Delivering relevantinformation to interested users: general philosophy, system architecture & technicalrealisation of the Swisscast push service [on line]. URL: http://www.swisscast.net[13.03.2001].

� Catledge, L.D. & Pitkow, J.E.(1998). Characterizing browsing strategies in theworld-Wide Web.

� Chai, wei & Vercoe, Barry. Using user models in music information retrievalsystems [on line]. URL: http://www.media.mit.edu [22.03.2001].

� Chandrasekaran, B. Josephson, J.R. & Benjamins, V. R. (1999). What areontologies and why do we need them?. IEEE Intelligent Systems, 20-26.

� Connolly, D., Khare, R. & Rifkin, A. (1998). The evolution of Web documents: theascent of XML [on line]. URL: http.//www.cs.caltech.eu/~adam/papers/xml/ascent-of-xml.html [22.03.2001].

� Cover, R. (2000). Ontology and Conceptual Knowledge Markup Languages [online]. URL: http://xml.coverpages.org/ [03.04.2001].

� Cover, R. (2000). XML and CORBA [on line]. URL:http://xml.coverpages.org/xmlAndCORBA.html [10.04.2001].

� Cover, R. (2001). Ontology interchange format (OIL) [on line]. URL:http://xml.coverpages.org [03.04.2001].


� Day, D. R. (2000). Hands-on XSL: XSL for fun and diversion [on line]. URL:http://www-4.ibm.com/software/developer/library/hands-on-xsl [03.05.2001].

� Debevc, M. & Spasovski, J. (1994). Simplified decision algorithm for documentsfiltering on the WWW.

� Decina, M., Cantoni, L., Jannuzzi, P., Lepori, B. & Mazza, R. (1999). TheSwissCast project: building a push service, between communication issues andtechnology [on line]. URL: http://www.ted.cmis.csiro.au/sigir99/decina[15.03.2001].

� DeRose, S. J. (1999). XML Linkin: an introduction [on line]. http://www.w3.org[14.03.2001].

� Duivestein, S. (2000). Using SOAP [on line]. URL:http://www.pinnaclepublishing.com/AW/AWmag.nfs/ [10.04.2001].

� Dumbill, E. (2000). Distributed XML [on line]. URL: http://www.xml.com[06.03.2001].

� Dumbill, E. (2000). Putting RDF to work [on line]. URL:http://www.xml.com[06.03.2001].

� Foltz, P. W. & Dumais, S. T. (1992). Personalized information delivery: an analysisof information filtering methods. Communications of the ACM, 35(12), 51-60.

� Foltz, Peter W. & Dumais, Susan T. (1992). Personalized information delivery: ananalysis of information filtering methods. Communications of the ACM, 35(12), 51-60.

� Ghezzi, C, Jazayeri, M. & Mandiroli, D. (1991). Fundamentals od SoftwareEngineering. Prentice Hall.

� Grosso, P. (2000). XSL Concepts and pratical Use. In: XML Europe 2000, Paris,France [on line]. URL: http://www.sun.com [14.03.2001].

� Guarino, N., Masolo, c. & Vetere, G. (1999). Ontoseek: content-based access to theweb. IEEE Inteeligent Systems, 70-80.

� Heflin, J & Hendler J. (2000). Dynamic ontologies on the web [on line]. URL:http://www.aaai.org [14.03.2001].

� Heflin, J, Hendler J. & Luke, S. (1999). SHOE: A knowledge representationlanguage for internet applications, technical report [on line]. URL:http://www.cs.umd.edu/projects/plus/SHOE [14.03.2001].

� Heflin, J, Hendler J. & Luke, S. (2000). Applying ontology to the Web: a case study[on line]. URL: http://www.cs.umd.edu/ [14.03.2001].

� Heflin, J. & Hendler, J. (2000). Semantic Interoperability on the Web. In: ExtremeMarkup Languages 2000.

� IEEE (2001). Standard Upper Ontology Knowledge Interchange Format [on line].URL: http://suo.ieee.org/suo-kif.html [10.08.2001].

� ISO/IEC (2000). Overview of the MPEG-7 Standard. ISO/IEC JTC1/SC29/WG11N3445, Geneva.

� Joachims, T., Freitag, D. & Mitchell, T. (1996). WebWatcher: A tour guide for theWorld Wide Web.

� Johnson, R. (1998). User-centered Technology: A rethorical theory for computers &others mundane artifacts. New York: State university of NY Press.

� Kay, J. & Kummerfeld, R. J. (1994). Customization and delivery of multimediainformation. In: Proceedings of MULITCOM ’94, Vancouver, Nov 1994.


� Kelly, K & Wolf, G. (1997). Push! [on line]. URL:http://www.wired.com/wired/archive/5.03/ff_push_pr.html [09.03.2001].

� Kobsa, A. & Wahlster, W. (1989). User Models in Dialog Systems. Heidelberg:Springer.

� Konopnicki, D. & Shmueli, O. (1997). W3QS: A query system for the World.WideWeb [on line]. URL: http://www.cs.technion.ac.il [03.04.2001].

� Lassila, O. (1997). Introduction to RDF metadata [on line]. URL:http://www.w3.org/TR/NOTE-rdf-simple-intro-971113.html [06.03.2001].

� Lepori, B. (2000). Customized Delivery in the R&D information. In: Conference onCurrent Research information Services, Helsinki, 25-27 May 2000.

� Lepori, B., Cantoni, L., Jannuzzi, P., Mazza, R. & Tardini, S. (2000).L’applicazione Swisscast nel campo della ricerca scientifica: risultati della fase ditest e valutazione da parte degli utenti [on line]. URL: http://www.swisscast.net[05.03.2001].

� Luke, S., Spector, L. & Rager, D. (1996). Ontology-based knowledge discovery onthe World-Wide Web. In: Proceedings of the workshop on Internet-basedInformation Systems AAAI-96, Portland (Oregon), 1996.

� Martin, P. & Eklund, P. (2000). Knowledge representation and reuse on the WWW:conventions, RDF extentions and simple notations [on line]. URL:http://meganesia.int.gu.edu.au/~phmartin/WebKB/doc/papers/www9/ [09.03.2001].

� Mazza, R. (2001). Swisscast: technical specification [non pubblicato].� Miller, E., Miller, P. & Brickley, D. (1999). Guidance on expressing the Dublin

Core within the Resource Description Framework (RDF) [on line]. URL:http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/ [09.03.2001].

� Oard, D.W. (1997), The state of the art in text filtering. User modeling and user-adapted interaction, 7, 141-178.

� Ramanathan, S. & Rangan, P. V. (1994). Architectures for Personalized MultimediaServices. IEEE MultiMedia, 1(1).

� Robie, J. (1999). XQL Tutorial [on line]. URL: http://xml.coverpages.org[03.04.2001].

� Staab, S. Erdmann, M., Maedche, A. & Decker S. (2000). An extesible approach formodeling ontologies in RDF(S) [on line]. URL: http://www.aifb.uni-karlsruhe.de/WBS [14.03.2001].

� Stanley, T. (1996). Intelligent searching agents on the web [on line]. URL:http://www.ariadne.ac.uk/issue7/search-engines/ [27.03.2001].

� Swain, M.J., Frankel, C. & Athitson, V. (1997). WebSeer: an image search enginefor the World Wide Web.

� Underwood, George M., Maglio, Paul P. & Barrett, Rob. User-centered push fortimely information delivery [on line]. URL: http://www7.scu.edu.au/programme/fullpapers/1894/com1894.htm [22.02.01].

� W3C (1997). A brief SGML tutorial [on line]. URL: http://www.w3.org/TR/WD-html40-970708/intro/sgmltut.html [22.03.2001].

� W3C (1998). XML-QL: A query language for XML [on line]. URL:http://www.w3.or/TR/NOTE-xml-ql [03.04.2001].

� W3C (1999a). Document Definition Markup Language (DDML) Specification,Version 1.0 [on line]. URL: http://www.w3.org/TR/NOTE-ddml/ [06.03.2001].


� W3C (1999b). Namespaces in XML [on line]. URL:http://www.w3.org/TR/1999/REC-xml-names-19990114/ [09.03.2001].

� W3C (1999c). RDF Schema specification [on line]. URL:http://www.w3.org/TR/1999/PR-rdf-schema-19990303/ [21.03.2001].

� W3C (1999d). Resource Description Framework (RDF) model and syntaxspecification: W3C recommendation 22 february 1999 [on line]. URL:http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ [21.03.2001].

� W3C (1999e). XML Pointer Language (XPointer) [on line]. URL:http://www.w3.org/TR/1999/WD-xptr-19991206/ [22.03.2001].

� W3C (1999f). XML Schema requirements [on line]. URL:http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215/ [06.03.2001].

� W3C (2000a). Amaya Activity Statement [on line]. URL:http://www.w3.org/Amaya/Activity.html [14.03.2001].

� W3C (2000b). Extensible Markup Language (XML) 1.0 (Second Edition): W3CRecommendation 6 october 2000 [on line]. URL: http://www.w3.org/TR/REC-xml/[06.03.2001].

� W3C (2000c). XML Linking Language (XLink) Version 1.0 [on line]. URL:http://www.w3.org/TR/xlink [30.03.2001].

� W3C (2000d). XML Schema part 0: Primer [on line]. URL:http://www.w3.org/TR/xmlschema-0/ [05.03.2001].

� W3C (2001a). Amaya overview [on line]. URL: http://www.w3.org [14.03.2001].� W3C (2001b). Metadata activity statement [on line]. URL:http://www.w3.org

[06.03.2001].


La differenza tra la teoria e la pratica tende ad

essere molto piccola in teoria, ma in pratica è

molto grande.

Anonimo

La presente sezione presenta alcuni documenti originali che costituiscono un supporto

ed un completamento alla parte principale della memoria di licenza. Questi allegati sono

stati citati nel corso dell’esposizine del lavoro, e vanno considerati come parte

integrante del lavoro stesso.

Verrà dunque presentata una descrizione formale del progetto, che ripercorre il capitolo

3 attraverso l’uso di schemi UML, in particolare uno Use Case Diagram, dei Sequence

Diagrams, dei Collaboration Diagrams, una lista delle classi ed il loro Class Diagram.

In seguito verrà proposto un codice che rappresenti in formato SHOE i ST visti nel

capitolo 4; tale codice è corredato da spiegazioni in linguaggio naturale ed in esso

risultano visibili i riferimenti ad ontologie esterne per la definizione di alcuni termini di

base.

Infine, trova posto un propotipo dimostrativo di alcuni moduli e funzioni del sistema

SwissCast2. Il prototipo è allegato con l’utilizzo di un supporto CD-R ed include le

funzioni esposte nel capitolo 5. Si consiglia di copiare l’intero contenuto del CD-R sul

proprio disco fisso prima di eseguire il programma, in modo da rendere possibile la

scrittura dei file XML. L’applicazione prende avvio con l’esecuzione del file

Autorun.bat.


A. Descrizione formale del progetto

Il sistema SwissCast2 è stato descritto nel capitolo 3 di questo lavoro di memoria

attraverso schemi non formali e spiegazioni in linguaggio naturale. Naturalmente sono

stati affrontati solo gli aspetti salienti, concentrandosi sul nucleo originale del progetto,

vale a dire la rappresentazione della conoscenza nei ST. In questo capitolo l’intero

progetto verrà nuovamente descritto utilizzando uno strumento molto più preciso,

formale e standard: UML31. In particolare verranno utilizzate le seguenti viste che

permettono di affrontare i requisiti del sistema da un punto di vista concettuale (la

progettazione “fisica” del sistema non è tra gli obiettivi di questo lavoro):

Come si vedrà, è stato dato un particolare risalto alle viste dei processi; questi ultimi

infatti sono quelli maggiormante dettagliati sin dal capitolo 3 in quanto mostrano gli

aspetti originali del lavoro. Gli altri schemi, ed in particolare il Class Diagram, sono

facilmente riconducibili al sistema SwissCast attualmente disponibile in Rete.



A.1 Use Case Diagram


A.2. Sequence Diagrams

A.2.1. Inserimento manuale di un nuovo documento


A.2.2. Inserimento automatico di un nuovo documento


A.2.3. Moderazione dei nuovi documenti


A.2.4. Accoppiamento (matching) documenti/utenti


A.2.5. Consultazione dei nuovi documenti


A.2.6. Processo di Data Mining


A.2.7. Modifica del profilo utente


A.2.8. Registrazione di un nuovo utente


A.2.9. Registrazione di un nuovo IP da parte del Director


A.2.10. Registrazione di un nuovo IP da parte dell’IP stesso


A.2.11. Moderazione dei nuovi IP


A.2.12. Modifica della struttura di classificazione dei documenti


A.3. Collaboration diagrams

A.3.1. Inserimento manuale di un nuovo documento


A.3.2. Inserimento automatico di un nuovo documento


A.3.3. Moderazione dei nuovi documenti


A.3.4. Accoppiamento (matching) documenti/utenti


A.3.5. Consultazione dei nuovi documenti


A.3.6. Processo di Data Mining


A.3.7. Modifica del profilo utente


A.3.8. Registrazione di un nuovo utente


A.3.9. Registrazione di un nuovo IP da parte del Director


A.3.10. Registrazione di un nuovo IP da parte dell’IP stesso


A.3.11. Moderazione dei nuovi IP


A.3.12. Modifica della struttura di classificazione dei documenti


A.4. Classi


A.5. Class diagram


B. Un esempio di rappresentazione per i

sistemi terminologici: SHOE32

Nel capitolo 4.2 sono stati presentati i ST del sistema SwissCast2 come dei grafi con

nodi ed archi etichettati, definendo in modo formale le convenzioni grafiche usate.

Naturalmente una rappresentazione grafica di quel tipo descrive l’aspetto logico del ST,

comprensibile da un essere umano ma non machine understandable. A livello “fisico”,

quindi, i ST vanno rappresentati attraverso un linguaggio; tale linguaggio dev’essere

basato su XML per le ragioni esposte nel capitolo 3. Il principio a cui ci si riferisce è il

medesimo: la separazione del contenuto dalla presentazione.

Negli ultimi anni sono stati sviluppati diversi formalismi e linguaggi volti a permettere

la condivisione di conoscenza (come OIL33) e tra questi alcuni basati su XML, come

RDF34. Quest’ultimo si propone di specificare semantiche per dati basati su XML in un

modo standardizzato ed interoperabile. RDF non è un vero e proprio linguaggio ma un

modello di dati o di istanze di metadati; la specifica delle semantiche è aiutata dalla

struttura logica a grafo o a rete semantica. Ma RDF non ha parti che permettano alias

locali per proprietà e classi, ciò che sarebbe necessario in quanto è impossibile

raggiungere un consenso su scala planetaria per i nomi degli schemi. In RDF non c’è

modo per dichiarare un’equivalenza e non esistono meccanismi per definire assiomi

generali (come la transitività o l’opposizione). Per questo motivo si è scelto in questa

sede di usare un linguaggio che avesse più potere espressivo: SHOE.

SHOE è un linguaggio di rappresentazione della conoscenza basato su ontologie e

progettato per il Web. Per permettere la compatibilità con gli attuali standard Web,

SHOE è definito come un’aplicazione di SGML35; la sua sintassi estende il DTD di

HTML. Per questo motivo è facilmente traducibile in qualsiasi altro linguaggio basato

32 Simple HTML Ontology Extentions [Heflin 1999]33 Ontology Interchange Format [Cover 2001]34 Resource Description Framework [W3C 1999c]35 Stadardised Generalised Markup Language (ISO 8879) [W3C 1997]


su SGML. Le regole di inferenza SHOE possono essere ridotte a clausole di Horn, ciò

che permette di prendere vantaggio dagli algoritmi sviluppati per i programmi datalog.

Nei prossimi paragrafi verrà fornita una descrizione in linguaggio naturale della

struttura dei file SHOE che descrivono i ST dei documenti, degli utenti e degli IP, oltre

naturalmente ai relativi codici di SwissCastDoc-ont.html, di SwissCastUser-ont.html e

di SwissCastIP-ont.html.


B.1. ST dei documenti

B.1.1. Descrizione in linguaggio naturale

Id SwissCastDoc-ont

Versione 1.0

Descrizione Questo vocabolario definisce i termini e le relazioni usate per

descrivere i documenti del sistema SwissCast; esso fa riferimento

ad un set di termini molto diffuso, il ‘DublinCore Elements Set’.

Dato che nell’esempio che segue viene utilizzato SHOE come

linguaggio di descrizione, questo vocabolario farà riferimento (in

modo non vincolante) alla ‘Base Ontology’ ed alla ‘General

Ontology’ già definite nella gerachia SHOE.

Ultima revisione 2001-10-10

B.1.2. Ontologie estese

dublin-core-ontology (dc:)

http://www.cs.umd.edu/projects/plus/SHOE/onts/dublin.html

base-ontology (b:)

http://www.cs.umd.edu/projects/plus/SHOE/base1.0.html

general-ontology (g:)

http://www.cs.umd.edu/projects/plus/SHOE/general1.0.html

document-ontology (d:)

http://www.cs.umd.edu/projects/plus/SHOE/document.html

base SwissCastDoc

b:STRING STRING

b:DATE DATE


b:TRUTH TRUTH

general SwissCastDoc

g:Agent Agent

document SwissCastDoc

d:Document Document

dublin-core SwissCastDoc

dc:title TITLE

dc:creator CREATOR

dc:publisher PUBLISHER

dc:format FORMAT

dc:identifier ID

dc:source SOURCE

dc:rights RIGHTS

dc:language LANGUAGE

dc:description ABSTRACT

dc:subject SUBJECT

dc:type TYPE

dc:coverage LOCATION


B.1.3. Categorie

La seguente lista di termini descrive le categorie usate in questo vocabolario ed il loro

significato.

STRING – Una stringa come definita nella specifica HTML 2.0

DATE – Una stringa alfanumerica che definisce una data completa nel formato standard

della W3C

TRUTH – Una stringa booleana, con due soli possibili valori: YES e NO

URI – Una stringa che rappresenta un identificatore univoco come definito della

specifica W3C

Document – Entità che ci si propone di descrivere

DOCUMENTDEF – Descrizione del documento all’interno del sistema

Text – Una stringa di caratteri che ammette anche tags HTML

Language – Lingua in cui è scritto il contenuto del documento

Format_type – Tipi di formati elettronici disponibili del documento

Agent – Un’entità che performa una qualche azione

AgentName – Stringa che rappresenta il nome dell’agente in questione

Person – Agent: un essere umano

Organisation – Agent: una o più persone che lavorano assieme ed hanno un obiettivo

comune

CLASSIFICATION – Definisce la classificazione del documento; è composta dalle

seguenti parti:

SUBJECT – Argomento di riferimento del documento

CATEGORY – Categoria in cui rientra il contenuto del documento

TYPE – Tipo di contenuto del documento

SECTOR – Settore della ricerca realtivo al documento

LOCATION – Area geografica a cui si riferisce il documento


B.1.4. Costanti

Vengono definiti quattro gruppi di costanti: le lingue, i tipi di formato ed i valori

booleani e le classificazioni:

- Le lingue in cui il documento è redatto sono definite secondo gli acronimi dello

standard ISO 639; sono istanze della categoria Language:

o it Italiano

o en Inglese

o fr Francese

o de Tedesco

- I tipi di formato elettronico in cui un documento potrebbe essere disponibile

sono istanze di Format_type e vengono indicati come segue:

o txt formato plain text senza segni di formattazione

o pdf formato Acrobat pdf

o doc formato Microsoft Word

o html formato HTML [solo per le pagine Web originali]

- I valori booleani sono istanze di TRUTH e possono essere solo due:

o YES valore positivo, TRUE

o NO valore negativo, FALSE

- Le classificazioni sono tutte le istanze di SUBJECT, CATEGORY, SECTOR,

TYPE e LOCATION:

o SUBJECT; i diversi soggetti e le loro parti (anch’esse istanze di

SUBJECT):

� Industry and technology

� Industrial manufacture

� Transport and aeropsace

� Construction technology and materials


� Electronics and microelectronics

o Electronics

o Microelectronics

� Information and communication

� Telecommunications

� Multimedia and electronic publishing

� Information, media

� Semiotics and linguistics

� Information processing and information systems

� Energy, environment and life sciences

� Non-nuclear energy

� Nuclear energy

� Environmental protection and waste management

� Safety

� Medicine, health

� Biotechnology and life sciences

� Exact and earth sciences

� Agricolture and food

� Exact sciences

� Earth sciences

� Economy and human sciences

� Measurements and standards

� Education, training

� Economy, business, regional development

� Society and social sciences

� Human sciences, history, history of arts

� Signals elaboration

o CATEGORY; le categorie e le loro parti (pure istanze di CATEGORY):

� Competition annoucement

� University competition

� Corporate competition


� News

� Research grant

� Display

� Conference

� Seminar

� Exhibition

� Lecture

o SECTOR; i settori della ricerca:

� R&D policies

� Forecasting and evaluation

� Legislation, regulations

� Innovation, technology transfer

� Coordination, cooperation

� Education and training

� Scientific research

o TYPE; i tipi di documento:

� Public notice

� Article

� Report

� Annoucement

� Interview

o LOCATION; le aree geografiche rispondono agli acronimi internazionali

della ISO:

� Europe il continente europeo

� CEE la comunità economica europea

o fr Francia

o it Italia

o uk Regno Unito

o de Germania

� ch Svizzera

o TI Canton Ticino

o BE Canton Berna


o GE Canton Ginevra

o GR Canton Grigioni

o ZH Canton Zutigo

� International gli altri continenti

� us Stati Uniti d’America

� ca Canada

� jp Giappone


B.1.5. Relazioni

Description(Document, DOCUMENTDEF)

TITLE(DOCUMENTDEF, STRING)

CREATOR(DOCUMENTDEF, AgentName)

PUBLISHER(DOCUMENTDEF, AgentName)

ISA(AgentName, String)

Name(Agent, AgentName)

ISA(Person, Agent)

ISA(Organisation, Agent)

FORMAT(DOCUMENTDEF, Format_type)

InstanceOf(txt, Format-type)

InstanceOf(pdf, Format-type)

InstanceOf(doc, Format-type)

InstanceOf(html, Format-type)

ID(DOCUMENTDEF, URI)

SOURCE(DOCUMENTDEF, URI)

RIGHTS(DOCUMENTDEF, URI)

ISA(URI, STRING)

LANGUAGE(DOCUMENTDEF, Language)

InstanceOf(it, Language)

InstanceOf(en, Language)

InstanceOf(fr, Language)

InstanceOf(de, Language)

STARTDATE(DOCUMENTDEF, DATE)

ENDDATE(DOCUMENTDEF, DATE)

MODERATED(DOCUMENTDEF, TRUTH)

InstanceOf(YES, TRUTH)

InsanceOf(NO, TRUTH)

ABSTRACT(DOCUMENTDEF, Text)

CONTENT(DOCUMENTDEF, Text)


ISA(Text, STRING)

CLASSIFICATION(DOCUMENTDEF, Classification)

partOf(SUBJECT, Classification)

partOf(CATEGORY, Classification)

partOf(TYPE, Classification)

partOf(SECTOR, Classification)

partOf(LOCATION, Classification)

instanceOf(Industry and technology, SUBJECT)

...

partOf(Industrial manufactura, Industry and technology)

...


B.1.6. Inferenze

Le seguenti regole di inferenza generali permettono di operare con tecniche quale il

calcolo dei predicati sulle descrizioni dei dcumenti che si appoggiano a questo

vocabolario.

a) Transitività di ISA

if

(?x ISA ?y)

(?y ISA ?z)

then

(?x ISA ?z)

b) Transitività di partOf

if

(?x partOf ?y)

(?y partOf ?z)

then

(?x partOf ?z)

c) Istanze in gerarchie

if

(?x instanceOf ?y)

(?y ISA ?z)

then

(?x instanceOf ?z)

d) Parti di istanze


if

(?x partOf ?y)

(?y instanceOf ?z)

then

(?x instanceOf ?z)

e) Gerarchie di parti

if

(?x ISA ?y)

(?y partOf ?z)

then

(?x partOf ?z)

B.1.7. Codice SHOE

<HTML><HEAD><TITLE>Vocabolario relazionale per Documenti SwissCast</TITLE><BODY><CENTER><H1>Vocabolario relazionale per DocumentiSwissCast</H1></CENTER> Questo documento contiene all'interno del suo codice una sezioneche descrive i termini e le relazioni usate per descrivere i documentidel sistema SwissCast. Il codice è stato annotato per permetterne unalettura più agevole.Questa implementazione è intesa quale esempio di rappresentazionedi ontologia. Sarà possibile utilizzare qualsiasi altro linguaggiobasato su XML (anche traducendo a partire dal presentedocumento). <CENTER> ********************************************************</CENTER>



<ONTOLOGY id="SwissCastDoc-ont"DECLARATORS="http://www.swisscast.org/ontologies/SwissCastDoc-ont.html" DESCRIPTION="Termini e relazioni per descrivere i documentiSwissCast" VERSION="1.0">



<USE-ONTOLOGY id=base-ontology VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/base1.0.html"PREFIX="b"><USE-ONTOLOGY id=general-ont VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/general1.0.html"PREFIX="g"><USE-ONTOLOGY id=document-ont VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/document1.0.html"PREFIX="d"><USE-ONTOLOGY id=dublin-core-ontology VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/dublin.html"PREFIX="dc">



<DEF-RENAME TO="SCEntity" FROM="b.SHOEEntity"><DEF-RENAME TO="STRING" FROM="b.STRING"><DEF-RENAME TO="DATE" FROM="b.DATE"><DEF-RENAME TO="TRUTH" FROM="b.TRUTH">

<DEF-RENAME TO="Agent" FROM="g.Agent">

<DEF-RENAME TO="Document" FROM="d.Document">

<DEF-RENAME TO="TITLE" FROM="dc.title"><DEF-RENAME TO="CREATOR" FROM="dc.creator"><DEF-RENAME TO="PUBLISHER" FROM="dc.publisher"><DEF-RENAME TO="FORMAT" FROM="dc.format"><DEF-RENAME TO="ID" FROM="dc.identifier"><DEF-RENAME TO="SOURCE" FROM="dc.source"><DEF-RENAME TO="RIGHTS" FROM="dc.rights"><DEF-RENAME TO="LANGUAGE" FROM="dc.language"><DEF-RENAME TO="SUBJECT" FROM="dc.subject"><DEF-RENAME TO="TYPE" FROM="dc.type"><DEF-RENAME TO="LOCATION" FROM="dc.coverage">



<DEF-CATEGORY NAME="DOCUMENTDEF" ISA="SCEntity">

<DEF-CATEGORY NAME="URI" ISA="STRING"><DEF-CATEGORY NAME="Text" ISA="STRING"><DEF-CATEGORY NAME="AgentName" ISA="STRING">

<DEF-CATEGORY NAME="Person" ISA="Agent"><DEF-CATEGORY NAME="Organisation" ISA="Agent">

<DEF-CATEGORY NAME="Language" ISA="SCEntity"><DEF-CATEGORY NAME="Format_type" ISA="SCEntity">

<DEF-CATEGORY NAME="Classification" ISA="SCEntity"><DEF-CATEGORY NAME="CATEGORY" ISA="SCEntity"><DEF-CATEGORY NAME="SECTOR" ISA="SCEntity">



<DEF-CONSTANT NAME="it" CATEGORY="Language"><DEF-CONSTANT NAME="en" CATEGORY="Language"><DEF-CONSTANT NAME="fr" CATEGORY="Language"><DEF-CONSTANT NAME="de" CATEGORY="Language">

<DEF-CONSTANT NAME="txt" CATEGORY="Format_type"><DEF-CONSTANT NAME="pdf" CATEGORY="Format_type"><DEF-CONSTANT NAME="doc" CATEGORY="Format_type"><DEF-CONSTANT NAME="html" CATEGORY="Format_type">

<DEF-CONSTANT NAME="YES" CATEGORY="TRUTH"><DEF-CONSTANT NAME="NO" CATEGORY="TRUTH">

<DEF-CONSTANT NAME="Industry and technology" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Industrial manufacture" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Transport and aerospace" CATEGORY="SUBJECT">

<DEF-CONSTANT NAME="Construction technology and materials"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Electronics and microelectornics"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Electronics" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Microelectronics" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Information and communication" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Telecommunications" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Multimedia and electronic publishing"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Information, media" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Semiotics and linguistics" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Information processing and information systems"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Energy, environment and life sciences"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Non-nuclear energy" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Nuclear energy" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Environmental protection and waste management"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Safety" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Medicine, health" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Biotechnology and life sciences"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Exact and earth sciences" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Agricolture and food" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Exact sciences" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Earth sciences" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Economy and human sciences" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Measurements and standards" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Education, training" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Economy, business, regional development"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Society and social sciences" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Human sciences, history, history of arts"CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Signals elaboration" CATEGORY="SUBJECT"><DEF-CONSTANT NAME="Competition announcement" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="University competition" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="Corporate competition" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="News" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="Research grant" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="Display" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="Conference" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="Seminar" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="Exhibition" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="Lecture" CATEGORY="CATEGORY"><DEF-CONSTANT NAME="R&D policies" CATEGORY="SECTOR"><DEF-CONSTANT NAME="Forecasting and evaluation" CATEGORY="SECTOR"><DEF-CONSTANT NAME="Legislation, regulations" CATEGORY="SECTOR"><DEF-CONSTANT NAME="Innovation, technology transfer"CATEGORY="SECTOR"><DEF-CONSTANT NAME="Coordination, cooperation" CATEGORY="SECTOR"><DEF-CONSTANT NAME="Education and training" CATEGORY="SECTOR"><DEF-CONSTANT NAME="Scientific research" CATEGORY="SECTOR"><DEF-CONSTANT NAME="Public notice" CATEGORY="TYPE">

<DEF-CONSTANT NAME="Article" CATEGORY="TYPE"><DEF-CONSTANT NAME="Report" CATEGORY="TYPE"><DEF-CONSTANT NAME="Annoucement" CATEGORY="TYPE"><DEF-CONSTANT NAME="Interview" CATEGORY="TYPE"><DEF-CONSTANT NAME="Europe" CATEGORY="LOCATION"><DEF-CONSTANT NAME="International" CATEGORY="LOCATION"><DEF-CONSTANT NAME="CEE" CATEGORY="LOCATION"><DEF-CONSTANT NAME="ch" CATEGORY="LOCATION"><DEF-CONSTANT NAME="BE" CATEGORY="LOCATION"><DEF-CONSTANT NAME="TI" CATEGORY="LOCATION"><DEF-CONSTANT NAME="GE" CATEGORY="LOCATION"><DEF-CONSTANT NAME="GR" CATEGORY="LOCATION"><DEF-CONSTANT NAME="ZH" CATEGORY="LOCATION"><DEF-CONSTANT NAME="de" CATEGORY="LOCATION"><DEF-CONSTANT NAME="fr" CATEGORY="LOCATION"><DEF-CONSTANT NAME="it" CATEGORY="LOCATION"><DEF-CONSTANT NAME="uk" CATEGORY="LOCATION"><DEF-CONSTANT NAME="ca" CATEGORY="LOCATION"><DEF-CONSTANT NAME="jp" CATEGORY="LOCATION"><DEF-CONSTANT NAME="us" CATEGORY="LOCATION">



<DEF-RELATION NAME="Description"><DEF-ARG TYPE="Document" POS="FROM"><DEF-ARG TYPE="DOCUMENTDEF" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="TITLE"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="STRING" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="CREATOR"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="AgentName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PUBLISHER"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="AgentName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="Name"><DEF-ARG TYPE="Agent" POS="FROM"><DEF-ARG TYPE="AgentName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="FORMAT"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="Format_type" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="txt" POS="FROM"><DEF-ARG TYPE="Format_type" POS="TO">

</DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="pdf" POS="FROM"><DEF-ARG TYPE="Format_type" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="doc" POS="FROM"><DEF-ARG TYPE="Format_type" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="html" POS="FROM"><DEF-ARG TYPE="Format_type" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="ID"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="URI" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="SOURCE"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="URI" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="RIGHTS"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="URI" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="LANGUAGE"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="Language" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="it" POS="FROM"><DEF-ARG TYPE="LANGUAGE" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="en" POS="FROM"><DEF-ARG TYPE="LANGUAGE" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="fr" POS="FROM"><DEF-ARG TYPE="LANGUAGE" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="de" POS="FROM"><DEF-ARG TYPE="LANGUAGE" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="STARTDATE"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM">

<DEF-ARG TYPE="DATE" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="ENDDATE"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="DATE" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="MODERATED"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="TRUTH" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="YES" POS="FROM"><DEF-ARG TYPE="TRUTH" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="instanceOf"><DEF-ARG TYPE="NO" POS="FROM"><DEF-ARG TYPE="TRUTH" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="ABSTRACT"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="Text" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="CONTENT"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="Text" POS="TO"></DEF-RELATION>



<DEF-RELATION NAME="CLASSIFICATION"><DEF-ARG TYPE="DOCUMENTDEF" POS="FROM"><DEF-ARG TYPE="Classification" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="SUBJECT" POS="FROM"><DEF-ARG TYPE="Classification" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="CATEGORY" POS="FROM"><DEF-ARG TYPE="Classification" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="TYPE" POS="FROM"><DEF-ARG TYPE="Classification" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="SECTOR" POS="FROM">

<DEF-ARG TYPE="Classification" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="LOCATION" POS="FROM"><DEF-ARG TYPE="Classification" POS="TO"></DEF-RELATION>



<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Industrial manufacture" POS="FROM"><DEF-ARG TYPE="Industry and technology" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Transport and aerospace" POS="FROM"><DEF-ARG TYPE="Industry and technology" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Construction technology and materials"

POS="FROM"><DEF-ARG TYPE="Industry and technology" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Electronics and microelectronics" POS="FROM"><DEF-ARG TYPE="Industry and technology" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Electronics" POS="FROM"><DEF-ARG TYPE="Electronics and microelectronics" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Microelectronics" POS="FROM"><DEF-ARG TYPE="Electronics and microelectronics" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Telecommunications" POS="FROM"><DEF-ARG TYPE="Information and communication" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Multimedia and electronic publishing" POS="FROM"><DEF-ARG TYPE="Information and communication" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Information, media" POS="FROM"><DEF-ARG TYPE="Information and communication" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Semitics and linguistics" POS="FROM"><DEF-ARG TYPE="Information and communication" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Information processing and information systems"

POS="FROM"><DEF-ARG TYPE="Information and communication" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Non-nuclear energy" POS="FROM"><DEF-ARG TYPE="Energy, environment and life sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Nuclear energy" POS="FROM"><DEF-ARG TYPE="Energy, environment and life sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Environmental protection and waste management"

POS="FROM"><DEF-ARG TYPE="Energy, environment and life sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Safety" POS="FROM"><DEF-ARG TYPE="Energy, environment and life sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Medicine, health" POS="FROM"><DEF-ARG TYPE="Energy, environment and life sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Biotechnology and life sciences" POS="FROM"><DEF-ARG TYPE="Energy, environment and life sciences" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Agricolture and food" POS="FROM"><DEF-ARG TYPE="Exact and earth sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Exact sciences" POS="FROM"><DEF-ARG TYPE="Exact and earth sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Earth sciences" POS="FROM"><DEF-ARG TYPE="Exact and earth sciences" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Measurements and standards" POS="FROM"><DEF-ARG TYPE="Economy, social and human sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Education, training" POS="FROM"><DEF-ARG TYPE="Economy, social and human sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Economy, business, regional development"

POS="FROM"><DEF-ARG TYPE="Economy, social and human sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Society and social sciences" POS="FROM"><DEF-ARG TYPE="Economy, social and human sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf">

<DEF-ARG TYPE="Human sciences, history, history of arts"POS="FROM">

<DEF-ARG TYPE="Economy, social and human sciences" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Architecture" POS="FROM"><DEF-ARG TYPE="Economy, social and human sciences" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Signals elaboration" POS="FROM"><DEF-ARG TYPE="Electronics and microelectronics" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Signals elaboration" POS="FROM"><DEF-ARG TYPE="Telecommunications" POS="TO"></DEF-RELATION>



<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="University competition" POS="FROM"><DEF-ARG TYPE="Competition annoucement" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Corporate competition" POS="FROM"><DEF-ARG TYPE="Competition annoucement" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Conference" POS="FROM"><DEF-ARG TYPE="Display" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Seminar" POS="FROM"><DEF-ARG TYPE="Display" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Exhibition" POS="FROM"><DEF-ARG TYPE="Display" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="Lecture" POS="FROM"><DEF-ARG TYPE="Display" POS="TO"></DEF-RELATION>



// Non è stata definita nessuna relazione differente da "instanceOfTYPE" in questa sezione



// Non è stata definita nessuna relazione differente da "instanceOfSECTOR" in questa sezione

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="CEE" POS="FROM"><DEF-ARG TYPE="Europe" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="de" POS="FROM"><DEF-ARG TYPE="CEE" POS="TO"><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="fr" POS="FROM"><DEF-ARG TYPE="CEE" POS="TO"><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="it" POS="FROM"><DEF-ARG TYPE="CEE" POS="TO"><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="uk" POS="FROM"><DEF-ARG TYPE="CEE" POS="TO">

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="ch" POS="FROM"><DEF-ARG TYPE="Europe" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="BE" POS="FROM"><DEF-ARG TYPE="ch" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="GE" POS="FROM"><DEF-ARG TYPE="ch" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="GR" POS="FROM"><DEF-ARG TYPE="ch" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="TI" POS="FROM"><DEF-ARG TYPE="ch" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="ZH" POS="FROM"><DEF-ARG TYPE="ch" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="partOf"><DEF-ARG TYPE="ca" POS="FROM"><DEF-ARG TYPE="Not_Europe" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="jp" POS="FROM"><DEF-ARG TYPE="Not_Europe" POS="TO"></DEF-RELATION><DEF-RELATION NAME="partOf"><DEF-ARG TYPE="us" POS="FROM"><DEF-ARG TYPE="Not_Europe" POS="TO"></DEF-RELATION>

<DEF-INFERENCE DESCRIPTION="Transitività della relazione ISA"><INF-IF>

<RELATION NAME="ISA"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="y"></RELATION><RELATION NAME="ISA"><ARG POS="FROM" VAR VALUE="y"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-IF><INF-THEN>

<RELATION NAME="ISA"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-THEN></DEF-INFERENCE>

<DEF-INFERENCE DESCRIPTION="Transitività della relazione partOf"><INF-IF>

<RELATION NAME="partOf"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="y"></RELATION><RELATION NAME="partOf"><ARG POS="FROM" VAR VALUE="y"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-IF><INF-THEN>

<RELATION NAME="partOf"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="z"></RELATION>


<DEF-INFERENCE DESCRIPTION="Istanze in gerarchie"><INF-IF>

<RELATION NAME="instanceOf"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="y"></RELATION><RELATION NAME="ISA"><ARG POS="FROM" VAR VALUE="y"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-IF><INF-THEN>

<RELATION NAME="instanceOf"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="z"></RELATION>

<DEF-INFERENCE DESCRIPTION="Parti di istanze"><INF-IF>

<RELATION NAME="partOf"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="y"></RELATION><RELATION NAME="instanceOf"><ARG POS="FROM" VAR VALUE="y"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-IF><INF-THEN>



<DEF-INFERENCE DESCRIPTION="Gerarchie di parti"><INF-IF>

<RELATION NAME="ISA"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="y"></RELATION><RELATION NAME="partOf"><ARG POS="FROM" VAR VALUE="y"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-IF><INF-THEN>



</ONTOLOGY>

</BODY></HTML>


B.2. ST degli utenti


Id SwissCastUser-ont

Versione 1.0


descrivere gli utenti del sistema SwissCast. Dato che

nell’esempio che segue viene utilizzato SHOE come linguaggio di

descrizione, questo vocabolario farà riferimento (in modo non

vincolante) alla ‘Base Ontology’ ed alla ‘General Ontology’ già

definite nella gerachia SHOE. Il presente vocabolario si riferisce

inoltre a termini definiti nel sistema terminologico dei documenti

SwissCast (SwissCastDoc-ont).



base-ontology (b:)




personal-ontology (p:)

http://www.cs.umd.edu/projects/plus/SHOE/personal1.0.html

SwissCastDoc-ont (s:)

http://www.swisscast.org/ontologies/SwissCastDoc-ont.html

base SwissCastUser

b:STRING STRING

b:DATE DATE


b:name UserName

general SwissCastUser

g:Address Address

g:Agent Agent

g:Organisation Organisation

g:Activity Activity

g:Work Work

g:Person Person

personal SwissCastUser

p:Gender Sex

SwissCastDoc-ont SwissCastUser

s:DOCUMENTDEF DOCUMENTDEFs:LOCATION LOCATION


B.2.3. Categorie


significato.


DATE – Una stringa alfanumerica che definisce una data completa nel formato standard

della W3C


Person – Agent: un essere umano

Activity – Un’attività performata dall’utente

User – Persona che utilizza il servizio e che ci si propone di descrivere

USERDEF – Descrizione dell’utente all’interno del sistema

UserName – Nome dell’utente

Sex – Il genere (maschile o femminile) dell’utente

Nation – La nazione di cui l’utente è cittadino

Address – Recapito dell’utente

COUNTRYNAME – Nome di uno stato

STREETADDRESS - Via

POSTCODE - CAP

CITYNAME – Nome di una città

City - Città

TELNUM – Numero di telefono

FAXNUM – Numero di Fax

EMAILADDRESS – Indirizzo di posta elettronica



comune

OrgName – Nome dell’organizzazione in cui lavora l’utente

Work – Activity: La professione dell’utente (titolo di studio od abilità professionale)

WorkName – Stringa che identifica la professione dell’utente

ACTIVITYNAME – Nome dell’attività che definisce il ruolo ricoperto dall’utente

nell’organizzazione per cui opera

Periodicity – Scadenza con cui l’utente vuol essere avvertito della presenza di

documenti rilevanti

Key – Combinazione di sicurezza per accedere ai dati dell’utente

USERID – Login

PASSWORD - Parola chiave

LOCATION – Un luogo geografico

DOCUMENTDEF – Definizione di un “documento tipo” che racchiude gli interessi dell’utente


B.2.4. Costanti

Vengono definiti due gruppi di costanti: i generi e le periodicità:

- I generi non possono che essere due:

o M Maschile

o F Femminile

- Le periodicità sono per il momento due:

o Once a Week Una volta alla settimana

o Once a Day Una volta al giorno

Per il nome degli stati (come parte di un indirizzo od indicanti la cittadinanza) valgono

le costanti definite nel ST dei documenti.


B.2.5. Relazioni

ISA(Person, Agent)

ISA(User, Person)

Description(User, USERDEF)

LASTNAME(USERDEF, UserName)

FIRSTNAME(USERDEF, UserName)

ISA (UserName, STRING)

CITIZENOF(USERDEF, COUNTRYNAME)

ISA(COUNTRYNAME, LOCATION)

BIRTHDATE(USERDEF, DATE)

GENDER(USERDEF, Sex)

InstanceOf(M, Sex)

InstanceOf(F, Sex)

PROFESSION(USERDEF, WorkName)

ISA(WorkName, STRING)

Name(Work, WorkName)

ISA(Work, Activity)

WORKSFOR(USERDEF, OrgName)

ISA(OrgName, STRING)

Name(Organisation, OrgName)


ROLE(USERDEF, ACTIVITYNAME)

ISA(ACTIVITYNAME, STRING)

Name(Activity, ACTIVITYNAME)

RELATEDTO(Activity, Organisation)

ADDRESS(USERDEF, Address)

PartOf(COUNTRYNAME, Address)

PartOf(STREETADDRESS, Address)

PartOf(POSTCODE, Address)

PartOf(CITYNAME, Address)

Name(City, CITYNAME)


ISA(CITYNAME, STRING)

PartOf(TELNUM, Address)

PartOf(FAXNUM, Address)

PartOf(EMAILADDRESS, Address)

DELIVERING(USERDEF, Periodicity)

InstanceOf(Once a Week, Periodicity)

InctanceOf(Once a Day, Periodicity)

ACCESS(USERDEF, Key)

PartOf(USERID, Key)

PartOf(PASSWORD, Key)

ISA(USERID, STRING)

ISA(PASSWORD, STRING)

PROFILE(USERDEF, DOCUMENTDEF)


B.2.6. Inferenze

Le seguenti regole di inferenza generali permettono di operare con tecniche quale il

calcolo dei predicati sulle descrizioni dei dcumenti che si appoggiano a questo

vocabolario.


if

(?x ISA ?y)

(?y ISA ?z)

then

(?x ISA ?z)


if

(?x partOf ?y)

(?y partOf ?z)

then

(?x partOf ?z)


if

(?x instanceOf ?y)

(?y ISA ?z)

then

(?x instanceOf ?z)

d) Relazione Name e RELATEDTO

if

(?x Name ?y)

(?a Name ?b)


(?x RELATEDTO ?a)

then

(?y RELATEDTO ?b)

e) Chi ha un ruolo lavora

if

(?x ROLE ?y)

(?y RELATEDTO ?z)

then(?x WORKSFOR ?z)

B.2.7. Codice SHOE

<HTML><HEAD><TITLE>Vocabolario relazionale per Utenti SwissCast</TITLE><BODY><CENTER><H1>Vocabolario relazionale per DocumentiSwissCast</H1></CENTER> Questo documento contiene all'interno del suo codice una sezioneche descrive i termini e le relazioni usate per descrivere i datirelativi agli utenti del del sistema SwissCast. Il codice è statoannotato per permetterne una lettura più agevole.Questa implementazione è intesa quale esempio di rappresentazionedi ontologia. Sarà possibile utilizzare qualsiasi altro linguaggiobasato su XML (anche traducendo a partire dal presentedocumento). <CENTER> ********************************************************</CENTER>


<ONTOLOGY id=SwissCastUser-ontDECLARATORS="http://www.swisscast.org/ontologies/SwissCastUser-ont.html" DESCRIPTION="Termini e relazioni per descrivere gli utentidi SwissCast" VERSION="1.0">


<USE-ONTOLOGY id=base-ontology VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/base1.0.html"PREFIX="b"><USE-ONTOLOGY id=general-ont VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/general1.0.html"PREFIX="g"><USE-ONTOLOGY id=personal-ont VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/personal1.0.html"PREFIX="p"><USE-ONTOLOGY id=SwissCastDoc-ont VERSION="1.0"URL="http://www.swisscast.org/ontologies/SwissCastDoc-ont.html"PREFIX="s">


<DEF-RENAME TO="STRING" FROM="b.STRING"><DEF-RENAME TO="DATE" FROM="b.DATE"><DEF-RENAME TO="UserName" FROM="b.name">

<DEF-RENAME TO="Address" FROM="g.Address"><DEF-RENAME TO="Agent" FROM="g.Agent"><DEF-RENAME TO="Organisation" FROM="g.Organisation"><DEF-RENAME TO="Activity" FROM="g.Activity"><DEF-RENAME TO="Work" FROM="g.Work"><DEF-RENAME TO="Person" FROM="g.Person">

<DEF-RENAME TO="Sex" FROM="p.Gender">

<DEF-RENAME TO="DOCUMENTDEF" FROM="s.DOCUMENTDEF"><DEF-RENAME TO="LOCATION" FROM="s.LOCATION"><DEF-RENAME TO="SCEntity" FROM="s.SCEntity">


<DEF-CATEGORY NAME="USERDEF" ISA="SCEntity"><DEF-CATEGORY NAME="STREETADDRESS" ISA="SCEntity"><DEF-CATEGORY NAME="POSTCODE" ISA="SCEntity"><DEF-CATEGORY NAME="CITYNAME" ISA="SCEntity"><DEF-CATEGORY NAME="TELNUM" ISA="SCEntity"><DEF-CATEGORY NAME="FAXNUM" ISA="SCEntity"><DEF-CATEGORY NAME="EMAILADDRESS" ISA="SCEntity"><DEF-CATEGORY NAME="Periodicity" ISA="SCEntity"><DEF-CATEGORY NAME="Key" ISA="SCEntity">

<DEF-CATEGORY NAME="Person" ISA="Agent"><DEF-CATEGORY NAME="User" ISA="Person">

<DEF-CATEGORY NAME="UserName" ISA="STRING"><DEF-CATEGORY NAME="WorkName" ISA="STRING"><DEF-CATEGORY NAME="OrgName" ISA="STRING"><DEF-CATEGORY NAME="ActivityName" ISA="STRING"><DEF-CATEGORY NAME="CITYNAME" ISA="STRING"><DEF-CATEGORY NAME="USERID" ISA="STRING"><DEF-CATEGORY NAME="PASSWORD" ISA="STRING">

<DEF-CATEGORY NAME="City" ISA="SCEntity">

<DEF-CATEGORY NAME="COUTRYNAME" ISA="LOCATION"><DEF-CATEGORY NAME="Work" ISA="Activity"><DEF-CATEGORY NAME="Organisation" ISA="Agent">



<DEF-CONSTANT NAME="M" CATEGORY="Sex"><DEF-CONSTANT NAME="F" CATEGORY="Sex">

<DEF-CONSTANT NAME="Once a Week" CATEGORY="Periodicity"><DEF-CONSTANT NAME="Once a Day" CATEGORY="Periodicity">


<DEF-RELATION NAME="Description"><DEF-ARG TYPE="User" POS="FROM"><DEF-ARG TYPE="USERDEF" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="LASTNAME">

<DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="UserName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="FirstName"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="UserName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="CITIZENOF"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="COUNTRYNAME" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="BIRTHDATE"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="DATE" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="GENDER"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="Sex" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PROFESSION"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="WorkName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="Name"><DEF-ARG TYPE="Work" POS="FROM"><DEF-ARG TYPE="WorkName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="WORKSFOR"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="OrgName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="Name"><DEF-ARG TYPE="Organisation" POS="FROM"><DEF-ARG TYPE="OrgName" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="ROLE"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="ACTIVITYNAME" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="Name"><DEF-ARG TYPE="Activity" POS="FROM"><DEF-ARG TYPE="ACTIVITYNAME" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="REALTEDTO"><DEF-ARG TYPE="Activity" POS="FROM"><DEF-ARG TYPE="Organisation" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="ADDRESS"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="COUNTRYNAME" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="STREETADDRESS" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="POSTCODE" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="CITYNAME" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="Name"><DEF-ARG TYPE="City" POS="FROM"><DEF-ARG TYPE="CITYNAME" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="TELNUM" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="FAXNUM" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="EMAILADDRESS" POS="FROM"><DEF-ARG TYPE="Address" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="DELIVERING"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="Periodicity" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="ACCESS"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="Key" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="USERID" POS="FROM"><DEF-ARG TYPE="Key" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="PASSWORD" POS="FROM"><DEF-ARG TYPE="Key" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PROFILE"><DEF-ARG TYPE="USERDEF" POS="FROM"><DEF-ARG TYPE="DOCUMENTDEF" POS="TO"></DEF-RELATION>



<RELATION NAME="ISA"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="y"></RELATION><RELATION NAME="ISA"><ARG POS="FROM" VAR VALUE="y"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-IF><INF-THEN>





</INF-IF><INF-THEN>




<RELATION NAME="instanceOf"><ARG POS="FROM" VAR VALUE="x"><ARG POS="TO" VAR VALUE="y"></RELATION><RELATION NAME="ISA">


B.3. ST degli Information Provider


Id SwissCastIP-ont

Versione 1.0


descrivere gli IPs del sistema SwissCast. Dato che nell’esempio

che segue viene utilizzato SHOE come linguaggio di descrizione,

questo vocabolario farà riferimento (in modo non vincolante)

alla ‘Base Ontology’ ed alla ‘General Ontolog’y già definite

nella gerachia SHOE. Il presente vocabolario si riferisce inoltre

a termini definiti nei sistemi terminologici dei documenti e degli

utenti SwissCast (SwissCastDoc-ont, SwissCastUser-ont).



base-ontology (b:)




SwissCastDoc-ont (sd:)


SwissCastUser-ont (su:)


base SwissCastIP

b:STRING STRING

b:TRUTH TRUTH


b:name Name

general SwissCastIP

g:Image Image

SwissCastDoc-ont SwissCastIP

sd:URI URI

SwissCastUser-ont SwissCastIP

su:Agent Agent

su:Organisation Organisation

su:Key Key

su:USERID USERIDsu:PASSWORD PASSWORD


B.3.3. Categorie


significato.


TRUTH – Una stringa booleana, con due soli possibili valori: YES e NO

URI – Una stringa che rappresenta un identificatore univoco come definito della

specifica W3C



comune

Information Provider – Organisation: fornitore di informazioni per il sistema SwissCast

IPDEF – Descrizione dell’IP all’interno del sistema

Name – Nome dell’IP

Image – Immagine che costituisce il Logo od il Logotipo del provider

Key – Combinazione di sicurezza per accedere ai dati dell’IP

USERID – Login

PASSWORD - Parola chiave

Provider Type – Tipo di provider, Attivo o Passivo

IPTERM – Termine del vocabolario dell’IP o sua parola chiaveSCTERM – Termine del vocabolario dei documenti SwissCast


B.3.4. Costanti

Vengono definiti due gruppi di costanti: i tipi di provider e le costanti booleane:

- I tipi di provider possono essere due:

o Active

o Passive

- I valori booleani possono essere solo due:

o YES valore positivo, TRUE

o NO valore negativo, FALSE


B.3.5. Relazioni


ISA(Information Provider, Organisation)

Description(Information Provider, IPDEF)

NAME(IPDEF, Name)

NICKNM(IPDEF, Name)

ISA(Name, STRING)

SOURCE(IPDEF,URI)

LOGO(IPDEF,Image)

TYPE(IPDEF, Provider Type)

InstanceOf(Active, Provider Type)

InstanceOf(Passive, Provider Type)

MODERATED(IPDEF, TRUTH)

InstanceOf(Y, TRUTH)

InstanceOf(N, TRUTH)

ACCESS(IPDEF, Key)

PartOf(USERID, Key)

PartOf(PASSWORD, Key)

ISA(USERID, STRING)

ISA(PASSWORD, STRING)

KEYWORD(IPDEF, IPTERM)MAPPEDTO(IPTERM, SCTERM)


B.3.6. Inferenze


if

(?x ISA ?y)

(?y ISA ?z)

then

(?x ISA ?z)


if

(?x partOf ?y)

(?y partOf ?z)

then

(?x partOf ?z)


if

(?x instanceOf ?y)

(?y ISA ?z)

then

(?x instanceOf ?z)

d) Gerarchie di parti

if

(?x ISA ?y)

(?y partOf ?z`)

then

(?x partOf ?z)

B.3.7. Codice SHOE

<HTML><HEAD><TITLE>Vocabolario relazionale per Information Providers diSwissCast</TITLE><BODY><CENTER><H1>Vocabolario relazionale per Information Providers (IPs) diSwissCast</H1></CENTER> Questo documento contiene all'interno del suo codice una sezioneche descrive i termini e le relazioni usate per descrivere gli IPs delsistema SwissCast. Il codice è stato annotato per permetterne unalettura più agevole.Questa implementazione è intesa quale esempio di rappresentazionedi ontologia. Sarà possibile utilizzare qualsiasi altro linguaggiobasato su XML (anche traducendo a partire dal presentedocumento). <CENTER> ********************************************************</CENTER>


<ONTOLOGY id=SwissCastIP-ontDECLARATORS="http://www.swisscast.org/ontologies/SwissCastIP-ont.html"DESCRIPTION="Termini e relazioni per descrivere gli IPs di SwissCast"VERSION="1.0">


<USE-ONTOLOGY id=base-ontology VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/base1.0.html"PREFIX="b"><USE-ONTOLOGY id=general-ont VERSION="1.0"URL="http://www.cs.umd.edu/projects/plus/SHOE/onts/general1.0.html"PREFIX="g"><USE-ONTOLOGY id=SwissCastDoc-ont VERSION="1.0"URL="http://www.swisscast.org/ontologies/SwissCastDoc-ont.html"PREFIX="sd"><USE-ONTOLOGY id=SwissCastUser-ont VERSION="1.0"URL="http://www.swisscast.org/ontologies/SwissCastUser-ont.html"PREFIX="su">


<DEF-RENAME TO="STRING" FROM="b.STRING"><DEF-RENAME TO="TRUTH" FROM="b.TRUTH"><DEF-RENAME TO="Name" FROM="b.Name">

<DEF-RENAME TO="Image" FROM="g.Image">

<DEF-RENAME TO="URI" FROM="sd.URI">

<DEF-RENAME TO="Agent" FROM="su.Agent"><DEF-RENAME TO="Organisation" FROM="su.Organisation"><DEF-RENAME TO="Key" FROM="su.Key"><DEF-RENAME TO="USERID" FROM="su.USERID"><DEF-RENAME TO="PASSWORD" FROM="su.PASSWORD"><DEF-RENAME TO="SCEntity" FROM="su.SCEntity">


<DEF-CATEGORY NAME="Provider Type" ISA="SCEntity"><DEF-CATEGORY NAME="IPTERM" ISA="SCEntity"><DEF-CATEGORY NAME="SCTERM" ISA="SCEntity">

<DEF-CATEGORY NAME="Organisation" ISA="Agent"><DEF-CATEGORY NAME="Information Provider" ISA="Organisation">



<DEF-CONSTANT NAME="Active" CATEGORY="Provider Type"><DEF-CONSTANT NAME="Passive" CATEGORY="Provider Type">

<DEF-CONSTANT NAME="YES" CATEGORY="TRUTH"><DEF-CONSTANT NAME="NO" CATEGORY="TRUTH">


<DEF-RELATION NAME="Description"><DEF-ARG TYPE="Information Provider" POS="FROM"><DEF-ARG TYPE="IPDEF" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="NAME"><DEF-ARG TYPE="IPDEF" POS="FROM"><DEF-ARG TYPE="Name" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="NICKNM"><DEF-ARG TYPE="IPDEF" POS="FROM"><DEF-ARG TYPE="Name" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="SOURCE"><DEF-ARG TYPE="IPDEF" POS="FROM"><DEF-ARG TYPE="URI" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="LOGO"><DEF-ARG TYPE="IPDEF" POS="FROM"><DEF-ARG TYPE="Image" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="TYPE"><DEF-ARG TYPE="IPDEF" POS="FROM"><DEF-ARG TYPE="Provider Type" POS="TO">

</DEF-RELATION>

<DEF-RELATION NAME="InstanceOf"><DEF-ARG TYPE="Active" POS="FROM"><DEF-ARG TYPE="Provider Type" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="InstanceOf"><DEF-ARG TYPE="Passive" POS="FROM"><DEF-ARG TYPE="Provider Type" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="MODERATED"><DEF-ARG TYPE="IPDEF" POS="FROM"><DEF-ARG TYPE="TRUTH" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="InstanceOf"><DEF-ARG TYPE="Y" POS="FROM"><DEF-ARG TYPE="TRUTH" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="InstanceOf"><DEF-ARG TYPE="N" POS="FROM"><DEF-ARG TYPE="TRUTH" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="ACCESS"><DEF-ARG TYPE="IPDEF" POS="FROM"><DEF-ARG TYPE="Key" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="USERID" POS="FROM"><DEF-ARG TYPE="Key" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="PartOf"><DEF-ARG TYPE="PASSWORD" POS="FROM"><DEF-ARG TYPE="Key" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="KEYWORD"><DEF-ARG TYPE="IPDEf" POS="FROM"><DEF-ARG TYPE="IPTERM" POS="TO"></DEF-RELATION>

<DEF-RELATION NAME="MAPPEDTO"><DEF-ARG TYPE="IPTERM" POS="FROM"><DEF-ARG TYPE="SCTERM" POS="TO"></DEF-RELATION>



<RELATION NAME="ISA">

</RELATION><RELATION NAME="partOf"><ARG POS="FROM" VAR VALUE="y"><ARG POS="TO" VAR VALUE="z"></RELATION>

</INF-IF><INF-THEN>



</ONTOLOGY>

</BODY></HTML>

Paper - Modelli di utente nel customized document delivery nel Web

Documents

Transcript of Paper - Modelli di utente nel customized document delivery nel Web