CAPITOLO IV: GESTIRE LA CONOSCENZA IN RETE

4.1 Legami in rete.

Ripensando alla storia della scrittura, soprattutto nei suoi più recenti sviluppi, la si potrebbe abbastanza bene interpretare come il tentativo di porre una rete di relazioni, il più possibile esplicite e attive, fra gli elementi di un testo. Questa spinta risponde chiaramente all'idea che ogni segno costituisca con tutti gli altri una rete di rimandi ben al di là della sua più immediata posizione nell'ordine lineare di lettura.

Le implicazioni che questo approccio semiotico prometterebbe di sviluppare sono legate all'antichissima utopia di poter servirsi, nella gestione della conoscenza, di un corpo semiotico di segni completamente attivo, nel quale ogni segno dica la sua relazione con ognuno degli altri come col tutto, di un corpo semiotico che ci fornisca una esatta fotografia della realtà, essendo in grado di esplicitare la collocazione di ogni significato di segno. Questa posizione utopica richiederebbe la possibilità di servirsi: innanzi tutto di un corpo universale di segni, di tutta la testualità che universalmente sia disponibile all'uomo; inoltre della capacità di rendere esplicito l'intero rapporto di relazioni che implicitamente un segno convoglia in sé.

Evidentemente nel concreto queste due possibilità non sono realizzabili, per il semplice fatto che non si potrà mai racchiudere in un solo spazio tutta la testualità possibile e che non si sarà mai in grado di definire tutte le possibili relazioni fra un segno ed un altro. Resta il fatto che una buona critica del fenomeno della scrittura non possa mai dimenticarsi che tutta la storia e l'evolvere di questa tecnica è sottoposta a queste due grandi tensioni: l'universalità e la connettività. Quello che abbiamo, in un certo senso, fin qua tentato di fare è stato di mostrare la fondamentale rilevanza che queste due tensioni hanno nello sviluppo della scrittura e attraverso quali modalità, nel concreto della situazione tecnica odierna, esse trovino la loro attuazione.

Si è visto bene come l'idea di ipertesto si vada necessariamente a risolvere in quella di rete universale di testi e come la scarsa predittività che oggi il link offre porti all'utilizzo delle possibilità di interconnessione nelle modalità più semplici e tradizionali, con la preminenza delle funzioni di archiviazione e di ricerca. Riguardo alla questione del legame, della referenza tra segni, si è mostrato come la sola possibilità per un segno di costituire referenze diverse in un sistema non eccessivamente complesso da risultare insensato si attui nella disposizione a più livelli delle sue implicazioni, mantenendo non rigida la gerarchia dei livelli ma consentendone differenti configurazioni.

Per quanto riguarda la situazione attuale i limiti che le tensioni di universalità e di connettività devono subire possono dipendere da diversi fattori: socio-culturali, socio-economici (si pensi ad esempio a problemi come quello del diritto di autore o della effettiva diffusione della rete informatica) ma certamente quello tecnico appare il più interessante da considerare.

La rapidità della diffusione di Internet è dovuta certamente all'utilità dello strumento, alle sue implicazioni rivoluzionarie, ma non si sarebbe mai realizzata senza la presenza di un substrato tecnico facilmente diffondibile. HTML ha rappresentato lo strumento ideale per fungere da substrato. Innanzitutto, problema fondamentale in informatica, si tratta di un linguaggio fruibile da qualsiasi sistema operativo, oltre a ciò il suo utilizzo è semplice, sufficientemente intuitivo e aperto alla comprensione anche di chi non possegga particolari competenze informatiche. Queste due caratteristiche derivano dal fatto che HTML non è altro che un linguaggio di formattazione e visualizzazione di testo, un linguaggio che, partendo da un testo qualsiasi, definisce per ogni elemento la sua dimensione, forma, colore, posizione ecc… HTML (Hyper Text Markup Language) nasce dalla aggiunta dell'elemento Link che Tim Berners-Lee apportò ad una applicazione SGML (Standard Generalized Markup Language) utilizzata all'interno del CERN di Ginevra per la circolazione dei documenti. In questo modo ad un testo si applica una marcatura che ne definisce la formattazione degli elementi, tra cui la possibilità per un elemento di costituire da collegamento ad un altro documento. Il fatto che tutto avvenga nella semplice definizione ad un unico livello della marcatura rende l'utilizzo di HTML semplice, tuttavia ne compromette fin da l'inizio la potenza (Darnel, 1998, 11). Definendo il link, la formattazione, ma anche altre informazioni quali ad esempio i metadati, a uno stesso livello, il mio documento presenterà tutti questi elementi come unità rendendo difficoltosa la trasmissione, l'interscambio differenziato, di questo tipo di informazioni.

La cosa, detta così, può apparire non chiara, ma la scarsa predittività del link è in parte conseguenza di questa impossibilità in HTML di scindere i pacchetti di informazione. Se io esprimo i dati, i collegamenti e la formattazione sullo stesso documento, una volta volessi posizionare quel documento diversamente nella mia rete ipertestuale non potrò utilizzare solo le informazioni che mi servono per costituire la nuova relazione ma dovrò trascinarmi tutto il documento. In HTML i collegamenti fra documenti risultano molto spesso rozzi, nel senso che si presentano o incapaci di comunicare la reale relazione semantica che attivano o incapaci di offrire un testo che realizzi la relazione semantica promessa. Questo proprio per la rigidità del linguaggio che posiziona ogni tipo di marcatura allo stesso livello.

In pratica HTML non consente nessun tipo di ordinamento semantico dell'informazione, non è possibile definire al suo interno una struttura o stabilire quali sezioni convoglino quale tipo di dati.

La situazione è poi aggravata dal fatto che attualmente sulla rete le informazioni convogliate da un documento non si limitano a testo ed immagine ma molto spesso riguardano database, suoni, video, audio. HTML è stato chiamato a descrivere tipi differenti e specifici di informazioni, a definire relazioni complesse di collegamenti fra documenti, a trasmettere informazioni in diversi formati, cosa per la quale non era stato progettato e che ha reso evidente la sua eccessiva rigidità. Non a caso l'HTML è oggi affiancato da una miriade di supporti sul server (CGI, JAVA) che ne accrescono le potenzialità ma che acutizzano il problema della così detta balcanizzazione del Web, cioè della sua frammentazione in territori di informazione gestita da linguaggi diversi (Floyd, 2000).

Oggi per la comunità informatica si offre tuttavia una possibilità di rendere più agilmente gestibile l'informazione in Internet, come anche nelle reti locali. Questa possibilità è offerta dal linguaggio di marcatura XML (Extensible Markup Language), un linguaggio che ha come sue caratteristiche fondamentali quelle di rendere libera e personale la marcatura del testo nonché di suddividere l'informazioni finale prodotta attraverso più documenti.

4.2 Extensible Murkup Language.

XML fu sviluppato dal XML Working Group, un gruppo di lavoro costituitosi nel 1996, all'interno del World Wide Web Consortium (W3C), il consorzio di aziende e produttori informatici che ha il compito di fornire per il Web strumenti il più possibili standardizzati. Il gruppo di lavoro era presieduto da Jon Bosak della Sun Microsystems con la partecipazione attiva dell’XML Special Interest Group (precedentemente noto come SGML Working Group) anch’esso organizzato dal W3C.

L’obiettivo di questo gruppo di lavoro era di portare la potenza di SGML nel Web, possibilmente semplificandone la complicata sintassi e costruendo un linguaggio agile e flessibile (Young, 2000).

Negli obiettivi progettuali del gruppo di lavoro XML si doveva presentare come un linguaggio semplice da utilizzare su Internet, in grado di supportare un gran numero di applicazioni, compatibile con SGML, costruito in modo da poter risultare intuitivamente leggibile dal programmatore, facilitando così la rapidità di progettazione (Floyd, 2000). Questi obbiettivi sono stati raggiunti attraverso due caratteristiche di XML: innanzi tutto la libertà di marcatura, per cui liberamente un programmatore decide quale nome e quale struttura dare ai tag di marcatura, la divisione su due distinti file dei dati e della loro formattazione consente invece un'agile gestione dell'informazione.

Sostanzialmente un documento XML si costituisce di tre parti. Nel documento XML puro abbiamo unicamente i dati di testo, marcati da tag di apertura e chiusura che possono essere liberamente posti dal programmatore. In un altro documento viene invece dichiarata la struttura secondo la quale è stata espressa la marcatura dei dati. Questa dichiarazione può essere espressa o attraverso una DTD (Document Type Declaretion) o attraverso un XML Schema, cioè attraverso due differenti modalità di dichiarazione che più avanti esporremo meglio. In fine l'ultimo fondamentale stadio di definizione dell'informazione si attua nel foglio di stile, cioè in un documento che specifichi quale formattazione i dati debbano assumere. I fogli di stile possono essere espressi in più linguaggi: XSL, che è il linguaggio di formattazione costruito per XML, ma anche CSS o addirittura HTML.

Già da queste semplici osservazioni si può capire come un linguaggio di questo tipo offra un'alta flessibilità, sia nella definizione della struttura dei dati, sia nella rappresentazione. In pratica, poiché i dati sono collocati a livello diverso rispetto alla loro struttura e alla loro visualizzazione, essi possono essere trasferiti verso nuovi rapporti strutturali e verso nuove funzioni fruitive.

4.2.1 Struttura e sintassi.

Una delle caratteristiche principali dell’XML è la possibilità di fornire una struttura a un documento. La struttura fornita è sia logica che fisica. Logica nel senso che definisce ordine e gerarchia degli elementi in gioco. Fisica poiché contiene i dati effettivi utilizzati nel documento, quali il testo memorizzato nella memoria del computer, un’immagine memorizzata nel Web e così via.

Ogni documento XML deve innanzi tutto iniziare con una dichiarazione di tipo di documento, che definisce quale tipo di documento si sta iniziando a descrivere nonché la versione delle specifiche usate (Giannì, 2000). Una dichiarazione base si presenta in questo modo:

<?xml version="1.0"?>

Una dichiarazione XML può inoltre contenere una dichiarazione di codifica (encoding) e una dichiarazione di documento autonomo (standalone). La dichiarazione di codifica identifica lo schema di codifica dei caratteri, ad esempio UTF-8 o EUC-JP. La dichiarazione di documento autonomo identifica l’esistenza delle dichiarazioni di markup esterne al documento. Questo tipo di dichiarazione può assumere valore yes o no.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

Oltre a questo è molto spesso necessario inserire una dichiarazione del tipo di documento DTD al quale si fa riferimento. In pratica si rimanda ad un file nel quale si è precedentemente definita la struttura che devono possedere i tag utilizzati. Questa dichiarazione può anche essere diretta a un file esterno che contiene tutta o parte della DTD e deve essere visualizzata dopo la dichiarazione XML ma prima dell’inizio del documento (Giannì, 2000). Ad esempio:

<?xml version="1.0"?>

<!DOCTYPE Esempio SYSTEM "esempio.dtd">

Con DOCTYPE semplicemente si assegna un nome al documento, con SYSTEM si rimanda al file che contiene la DTD, cioè la dichiarazione della struttura alla quale il documento che andremo a scrivere dovrà uniformarsi.

A questo punto è possibile iniziare a scrivere il nostro documento. Tutti i dati contenuti nel mio documento dovranno essere inseriti all'interno di due tag: uno di apertura, al quale potrò assegnare qualsiasi nome, a parte ovviamente quelli già assegnati ad altri elementi, e uno di chiusura che porterà lo stesso nome di quello di apertura preceduto però da una barra obliqua (slash).

Il primo elemento, il primo tag, che verrà postò sarà l'elemento documento, spesso chiamato anche root, questo elemento conterrà tutti gli altri e tutti i dati inseriti nel documento e ad esso bisognerà fare riferimento qualora si voglia richiamare l'intero documento. E' quindi chiaro che potrà esistere un solo elemento documento, che dovrà aprirsi all'inizio e chiudersi alla fine, tutti gli altri elementi dovranno stare al suo interno e nessuno lo potrà affiancare allo stesso livello della gerarchia (Giannì, 2000).

<?xml version="1.0"?>

<!DOCTYPE Esempio SYSTEM "esempio.dtd">

<AUTORE> Paolo </AUTORE>

<TITOLO> Esempio minimo </TITOLO>

</DOCUMENTO>

Escludendo l'elemento di documento, l'elemento iniziale, tutti gli altri possono essere tranquillamente nidificati l'uno dentro l'altro. Un elemento che contiene al suo interno un altro è detto genitore dell'elemento figlio, od anche semplicemente parente. Ogni elemento secondario, cioè un elemento diverso dall’elemento di documento risiede interamente all’interno del relativo elemento principale, così :

< FIGLIO2> dati </ FIGLIO2>

</ GENITORE1>

</DOCUMENTO>

E' importante notare fin da ora come la struttura che viene a delinearsi in base a queste semplici regole sarà comunque una struttura gerarchica, o ad albero, ma mai circolare. Un elemento figlio non potrebbe mai contenere al suo interno un elemento padre. Qualora si volesse inserire un elemento vuoto, e questo può essere molto utile per segnalare dati esterni o non di testo, ci si deve ricordare che la sintassi richiede non di aprire e chiudere un tag, ma semplicemente di indicare un tag seguito da una sbarra:

<IMG />

La struttura fisica di un documento XML è costituita da tutto il contenuto del documento stesso. Questo contenuto può essere rappresentato da semplice testo come anche da altri elementi definiti entità. Le unità di memorizzazione definite entità, possono essere parte integrante del documento o possono essere esterne. La caratteristica delle entità è di venir identificate da un nome univoco e da un contenuto specifico che può essere costituito da un singolo carattere all’interno del documento o da un file esterno di grandi dimensioni. L'utilità di questo tipo di dati è quella di poter richiamare informazione esterna al file, magari dati salvati con formati diversi da quello di testo, tipo un'immagine ma anche documenti Word o Excel, oltre a ciò è possibile definire per alcune informazioni un nome univoco e quindi richiamarla in qualsiasi punto facendo riferimento al solo nome di entità. Dopo aver dichiarato la DTD, l’entità può essere utilizzata in un punto qualsiasi del documento. Un riferimento di entità indica all’elaboratore di recuperare il contenuto di un’entità, come stabilito dalla dichiarazione di entità, e di utilizzarla all’interno del documento. Sintatticamente le dichiarazioni di entità vanno all'interno della dichiarazione di documento tra due parentesi quadrate (Giannì, 2000).

Ad esempio, una dichiarazione di entità potrebbe avere questa forma:

<!DOCTYPE Esempio [

<!ENTITY autore "nome autore">

] >

Ogni volta che nel documento viene fatto riferimento a questa entità, quest’ultima verrà sostituita dal contenuto. Modificando il contenuto dell’entità nella dichiarazione la modifica avrà effetto in qualsiasi punto del documento in cui venga richiamata l’entità.

Per richiamare un'entità in un qualsiasi punto del documento è sufficiente inserire una e commerciale (&) e immettere il nome dell’entità seguito da punto e virgole (;). Ad esempio nel modo seguente:

<TITOLO> Tesi in filosofia di: &autore;</ TITOLO >

Se l'entità dichiarata è un'entità esterna, gestita da un altro programma essa è detta entità non analizzabile e richiede informazioni diverse da quelle incluse in un’entità analizzabile. Viene infatti richiesta un’annotazione che identifica il formato o il tipo di risorsa per cui l’entità viene dichiarata. Ad esempio :

<!ENTITY MiaImmagine SYSTEM "Img1.gif" NDATA GIF>

Questa dichiarazione significa che l’entità MiaImmagine è un file gestibile in formato GIF. Nella dichiarazione è pure necessario indicare quale applicazione dovrà essere attivata per la lettura di questo formato di dati. La dichiarazione di annotazione consente all’applicazione XML di gestire i file esterni. Nel caso fatto precedentemente, la dichiarazione di annotazione potrebbe assumere la forma seguente:

<!NOTATION GIF SYSTEM "/Utils/Gifview.exe">

In pratica viene indicato alla applicazione XML a quale altra applicazione rivolgersi per l'elaborazione di questo tipo di dati, ovviamente è necessario fornire un percorso completo di localizzazione della applicazione annotata.

Nel linguaggio XML alcuni caratteri sono utilizzati per contrassegnare il documento in modo specifico. Le parentesi angolari (<>) e la barra (/) sono interpretate come markup e non come dati di un carattere effettivo.

Questi e altri caratteri sono riservati per il markup e non possono essere utilizzati come contenuto. L'unica possibilità di utilizzare direttamente questi caratteri è quella di utilizzare una applicazione in grado di gestire automaticamente la transcodifica. Altrimenti se si desidera che questi caratteri siano visualizzati come dati, è necessario utilizzare determinate entità predefinite in grado di richiamare i caratteri necessari senza fare ricorso al loro effettivo codice binario che sarebbe altrimenti confuso con istruzioni sintattiche. Qui sotto riportiamo i codici di queste entità predefinite:

< < (parentesi angolare di apertura)

> > (parentesi angolare di chiusura)

&amp ; & (e commerciale)

' ‘ (apostrofo)

" " (virgolette doppie)

Ultima cosa di cui dobbiamo trattare per descrivere la sintassi XML è la possibilità di inserire all'interno degli elementi degli attributi. Gli attributi consentono di associare valori a un elemento senza che siano considerati parte del contenuto dell’elemento stesso (Giannì, 2000). In pratica di un elemento, oltre al suo contenuto, è possibile definire alcuni valori espressi negli attributi, questi valori potranno poi esseri richiamati in fase di visualizzazione senza doversi riferire all'intero contenuto dell'elemento. Possiamo immaginare di associare ad un elemento un attributo in questo modo:

<AUTORE> Manzoni </AUTORE >

<TITOLO genere="romanzo"> Promessi Sposi </TITOLO>

</ DOCUMENTO >

L’attributo "genere" all'interno dell'elemento <TITOLO> aggiunge informazione, che può essere interessante richiamare separatamente rispetto a quella contenuta nei dati fra i due tag dell'elemento. Sintatticamente l'attributo segue sempre il nome dell'elemento nel suo tag di apertura, il valore è specificato dopo l'uguale tra virgolette.

Aggiungendo semplicemente che i dati preceduti da questi caratteri: , sono commenti, cioè dati che non vengono analizzati dall'applicazione XML ma che semplicemente sono posti dal programmatore come propri punti di riferimento, è possibile riportare l'esempio di un listato di un ipotetico documento XML, chiamato esempio.xml, che segua in modo corretto la sintassi:

Figura 4.1 esempio.xml.

<?xml version="1.0"?>

<!DOCTYPE esempio

[

<!ENTITY tasc "tascabile economico">

<!ENTITY ill "edizione illustrata">

<!ENTITY rig "copertina rigida">

<!NOTATION IMG SYSTEM "Addobe Photoshop">

<!NOTATION DOC SYSTEM "Microsoft Word document">

<!ENTITY anelli SYSTEM "anelli.gif" NDATA IMG>

<!ENTITY foglie SYSTEM "foglie.gif" NDATA IMG>

<!ENTITY spada SYSTEM "spada.gif" NDATA IMG>

<!ENTITY an1 SYSTEM "ancap1.doc" NDATA DOC>

<!ENTITY fo1 SYSTEM "focap1.doc" NDATA DOC>

<!ENTITY ar1 SYSTEM "arcap1.doc" NDATA DOC>

]

< BOOK InStock="n" Images="anelli" Rewiews="an1">

<TITLE>Il Signore degli anelli </TITLE>

<AUTHOR Born="18**"> J.R.R. Tolkien </AUTHOR>

</BOOK>

< BOOK InStock="s" Images="foglie" Rewiews="fo1">

<TITLE> Foglie d'erba </TITLE>

<AUTHOR Born="18**"> Walt Whitman </AUTHOR>

<BINDING> Edizione esaurita </BINDING>

</BOOK>

< BOOK InStock="s" Images="spada" Rewiews="ar1">

<TITLE>Le leggende di re Artù </TITLE>

</BOOK>

</INVENTORY>

Siccome questo documento segue correttamente la sintassi è detto ben formato, nel senso che segue tutte le norme che permetteranno al computer di leggere correttamente le istruzioni esposte nel listato. Riassumendo si può dire che un documento è ben formato se segue le seguenti regole:

§ Tutti i tag di apertura e di chiusura corrispondono.

§ I tag vuoti utilizzano una sintassi XML speciale.

§ Tutti i valori degli attributi sono racchiusi tra virgolette.

§ Tutte le entità sono dichiarate.

4.2.2 Document Type Definition.

Una delle caratteristiche fondamentali di XML è quella di consentire a chi lo utilizza di costruire documenti che presentino la struttura logica che più si ritiene opportuna. La gerarchia e l'ordine degli elementi posti come marcatori dei dati del documento non è vincolata da regole rigide ma può essere definita di volta in volta in base alle proprie necessità ed intenzioni. La definizione della struttura del documento è posta nella DTD (Document Type Defintion) cioè in una dichiarazione delle regole gerarchiche che i vari elementi del documento dovranno seguire.

Accanto a documenti ben formati, cioè sintatticamente corretti, esistono quindi anche documenti validi, cioè documenti che seguono la corretta gerarchia strutturale del documento. Naturalmente un documento può essere detto valido o non valido solo in riferimento ad un dichiarazione di documento. Una DTD deve essere inserita all'interno della dichiarazione di documento di un file, tuttavia essa non deve essere fisicamente presente nel file ma è possibile richiamare per quel file una DTD esterna. Questo significa che una stessa DTD può servire per un numero indefinito di documenti. Per richiamare una DTD esterna è sufficiente richiamare al seguito della istruzione SYSTEM il nome del file nel quale è stata dichiarata la struttura del documento:

<?xml version="1.0"?>

<! DOCTIPE ESEMPIODTD SYSTEM "esempiodtd.dtd">

Per descrivere quale sintassi una DTD deve seguire esporremo subito un listato nel quale, per il file precedentemente presentato, privo solo delle entità, viene dichiarata la struttura del documento.

Figura 4.2 dtdesempio.xml.

<?xml version="1.0"?>

<!DOCTYPE DTDESEMPIO

[

<!ELEMENT INVENTORY (BOOK)*>

<!ELEMENT BOOK (TITLE, AUTHOR?, BINDING+, PAGES, PRICE)>

<!ATTLIST BOOK InStock (s | n) #REQUIRED>

<!ELEMENT TITLE (#PCDATA | SUBTITLE)>

<!ELEMENT SUBTITLE (#PCDATA)>

<!ELEMENT AUTHOR (#PCDATA)>

<!ATTLIST AUTHOR Born CDATA #IMPLIED>

<!ELEMENT BINDING (#PCDATA)>

<!ELEMENT PAGES (#PCDATA)>

<!ELEMENT PRICE (#PCDATA)>

<!ATTLIST PRICE Euro CDATA "non disponibile">

]

< BOOK InStock="n">

<TITLE>Il Signore degli anelli </TITLE>

<AUTHOR Born="18**"> J.R.R. Tolkien </AUTHOR>

<BINDING> tascabile </BINDING>

</BOOK>

< BOOK InStock="s">

<TITLE> Foglie d'erba </TITLE>

<AUTHOR Born="18**"> Walt Whitman </AUTHOR>

<BINDING> tascabile </BINDING>

<BINDING> Edizione esaurita </BINDING>

</BOOK>

< BOOK InStock="s">

<TITLE>Le leggende di re Artù </TITLE>

<BINDING> Illustrato </BINDING>

</BOOK>

</INVENTORY>

Innanzi tutto bisogna notare come la dichiarazione vada posizionata all'interno dell'elemento DOCTYPE, inserita fra due parentesi quadre (Giannì, 2000). Ogni elemento che si vorrà dichiarare seguirà questa sintassi:

<!ELEMENT nomelemento >

A seguito del nome di elemento, racchiuso fra parentesi bisognerà poi specificare che tipi di dati saranno contenuti nell'elemento. Si potrà fare riferimento o a altri elementi o a semplici dati di testo. Se si vuole dichiarare la presenza di altri elementi secondari rispetto all'elemento che si sta dichiarando semplicemente si inserirà il nome di tali elementi, separati da virgola:

<!ELEMENT BOOK (TITLE, AUTHOR, BINDING, PAGES, PRICE)>

Se si intende dichiarare che all'interno dell'elemento saranno posizionati solo dati allora si inserirà la parola chiave #PCDATA:

<!ELEMENT BINDING (#PCDATA)>

La virgola (,) sarà utilizzata per indicare una successione di elementi, qualora si voglia indicare un'alternatività si potrà separare gli elementi dichiarati attraverso il carattere pipe (|). A seguito del nome di un elemento inserito fra parentesi sarà possibile inserire i seguenti caratteri di asterisco, punto interrogativo e più. L'asterisco (*) indica che l'elemento dichiarato potrà presentarsi all'interno dell'elemento superiore nessuna o più volte. Il punto interrogativo (?) indicherà una presenza dell'elemento per nessuna o una volta. Il simbolo più (+) definirà la possibilità per l'elemento di presentarsi uno o più volte. Questi simboli possono posizionarsi anche fuori dalla parentesi ed allora avranno valore per tutti gli elementi contenuti nella parentesi (Young, 2000).

<!ELEMENT INVENTORY (BOOK)*>

<!ELEMENT BOOK (TITLE, AUTHOR?, BINDING+, PAGES, PRICE)>

<!ELEMENT TITLE (#PCDATA | SUBTITLE)>

<!ELEMENT SUBTITLE (#PCDATA)>

Ogni elemento potrà anche possedere degli attributi. Gli attributi vanno dichiarati immediatamente a seguito dell'elemento tramite questa sintassi:

<!ATTLIST nomeelemneto nomeattributo tipodidato "dichiarazionedivalore">

Il tipo di dato può essere:

§ Tipo stringa, e in questo caso si può far seguire un qualsiasi tipo di dato in formato testo. Questo tipo di attributi viene dichiarato facendo seguire al nome di attributo la parola chiave CDATA alla quale è possibile far seguire, chiuso tra virgolette, un valore di stringa predefinito:

<!ATTLIST PRICE Euro CDATA "non disponibile">

§ Tipo token, si tratta di attributi limitati in varie maniere. Ad esempio la parola chiave ID indica che l'attributo in ciascun elemento deve possedere valore univoco. ENTITY indica che il valore di attributo deve essere costituito da una entità esterna dichiarata nella DTD. MNTOKEN indica che il valore dell'attributo deve essere costituito da uno o più punti (.) trattini(-) o caratteri di sottolineatura (_).

§ Tipo numerato, in questo caso il valore dell'attributo deve appartenere ad una serie di alternative indicate nella dichiarazione:

<!ATTLIST BOOK InStock (s | n) #REQUIRED>

La dichiarazione di valore dell'attributo può assumere quattro forme:

§ Può essere semplicemente un valore predefinito indicato tra virgolette grazie alla digitazione di una stringa.

§ Può essere specificata dalla parola chiave #REQUIRED, ed in questo caso si indica che è sempre necessario dichiarare il valore di un attributo.

§ Può determinarsi in base alla parola chiave #IMPLIED, ed in questo caso si indica che il valore dell'attributo può essere assegnato come omesso.

§ Può essere eseguita utilizzando la parola chiave #FIXED seguita dalla dichiarazione di un valore predefinito messo fra virgolette. In questo caso è possibile inserire o omettere il valore di attributo, nel caso lo si omettesse automaticamente l'applicazione assegna il valore predefinito indicato tra virgolette:

<!ATTLIST BOOK InStock (s | n) #FIXED "s">

<!ATTLIST LIBRO rilegatura CDATA #FIXED "in pelle">

4.2.3 XML Schema.

La DTD fu il primo sistema di definizione della struttura di documento elaborato all'interno del W3C (World Wide Web Consortium), tuttavia ad oggi questo sistema, per quanto sia ormai largamente diffuso, comincia a mostrare i suoi limiti. Il problema fondamentale è che la DTD è costruita mediante una sintassi diversa da quella XML. Questa cosa genera due diverse difficoltà, la prima è che per analizzare un documento DTD sarà necessario un programma differente che non quello per analizzare il file XML, inoltre il riferirsi al file XML mediante una diversa sintassi rende impossibile la descrizione del nodo di un nodo (Floyd, 2000).

Le soluzioni che il W3C ha studiato per ovviare a queste difficoltà si sono basate sulla formazione di alcune definizioni di schema. Una definizione di schema è un documento XML, scritto con sintassi XML, che definisce uno schema, che vincola un altro documento ad assumere una certa forma e gerarchia. Il W3C ha formulato diverse specifiche (DCD, XML-Data, DDML) ma attualmente punta su una specifica chiamata XML Schema che si candida a sostituire nel futuro le DTD (Floyd, 2000).

In un documento XML Schema, successivamente alla dichiarazione di istruzione che definisce il documento come XML, bisogna aprire un elemento Schema, all'interno del quale si posizionerà tutta la definizione dello schema (Giannì, 2000).

<?xml version="1.0">

<Schema name="nomeschema"

xmlns="urn:schemas-microsoft-com:xml-data"

xmlns:dt="urn:schemas-microsoft-com:datatypes>

</Schema>

Dopo aver dichiarato l'apertura di un documento XML si dichiara il nome dello schema. Nei due passi successivi della apertura di documento si fa ricorso ai namespace.

I namespace sono un sistema per l'utilizzo di nuovi tipi di sintassi all'interno di XML. In pratica vengono definiti dei nomi univoci coi quali richiamare alcuni elementi che si intendono porre nel documento. Per definire questi nuovi elementi, che saranno standard per tutte le dichiarazioni che seguano lo stesso schema di namespace, si richiama una URN (Uniform Resource Names), cioè un esterno file di schema nel quale sia definito il ruolo di un determinato spazio di nomi.

Nell'esempio qui sopra abbiamo inizialmente la dichiarazione dell'URN per i namespace di XML Schema, in seguito si dichiara l'URN per l'elemento dt, data type, che verrà in seguito richiamato nella esposizione completa dello schema.

Mostriamo immediatamente un possibile listato che utilizzi degli elementi dichiarati tramite la tecnica dei namespace. In questo esempio si riporta la definizione di uno schema di catalogazione di dati relativi ad una email.

Figura 4.3 schemaesempio.xml.

<?xml version="1.0"?>

<Schema name="email" xmlns="urn:schemas-microsoft-com:xml-data"

xmlns:dt="urn:schemas-microsoft-com:datatypes">

<AttributeType name="language" dt:type="enumeration"

dt:values="Western Greek Latin Universal"/>

</ElementType>

</ElementType>

</Schema>

Si possono notare subito due cose: la struttura dichiarata è la stessa che ci si potrebbe aspettare da una DTD, tuttavia la sintassi utilizzata è abbastanza diversa. Si tratta infatti di una sintassi XML nella quale gli elementi acquistano un ruolo in virtù della dichiarazione di spazio di nome espressa a seguito dell'elemento xmlns.

Scorriamo ora il listato per cercare di capire cosa sia stato dichiarato. L’elemento To è dichiarato in modo che sia ripetuto una o più volte. I riferimenti all’elemento To sono gli attributi minOccurs="1" e maxOccurs="*", che indicano che l’elemento deve occorrere almeno una volta e che il numero di ripetizioni è illimitato (Giannì, 2000).

L’elemento From è dichiarato in modo che occorra una sola volta. I riferimenti all’elemento From sono minOccurs="1" e maxOccurs="1", che indicano che l’elemento deve occorrere una sola volta.

Gli elementi Cc e Bcc sono dichiarati in modo che gli elementi siano opzionali e occorrano più di una volta. Ambedue gli elementi devono contenere gli attributi minOccurs="0" e maxOccurs="*", che indicano che sono opzionali e che il numero di occorrenze è illimitato.

Gli elementi Subject e Body sono dichiarati in modo che gli elementi siano opzionali e che possano occorrere una sola volta. Gli attributi minOccurs="0" e maxOccurs="1" indicano che gli elementi sono opzioni e che possono apparire una sola volta.

Gli elementi Email e Bcc hanno attributi associati, con valori predefiniti dove necessario. I tipi di attributi sono dichiarati nel livello superiore del documento e vi viene fatto riferimento nelle rispettive dichiarazioni dei tipi di elemento. Non occorre dichiarare i tipi di attributi al livello superiore, poiché è sufficiente che siano dichiarazioni a livello locale.

La maggior parte degli elementi è dichiarata come elementi di testo. La maggior parte delle dichiarazioni include l’attributo content"textOnly", che indica che esse contengono solo testo. L’eccezione è rappresentata dall’elemento Email, che contiene solo sottoelementi, e dall’elemento Bcc, che contiene un attributo oltre al testo.

Ora che abbiamo osservato la dichiarazione di Schema vediamo quale ipotetico file XML potrebbe corrisponderle. Potremo così osservare in che senso si utilizza nella dichiarazione una stessa sintassi XML supportata dalla definizione di uno spazio dei nomi.

<?xml version="1.0"?>

<em:email xmlns:em="x-schema:schemaesempio.xml" language="Western"

priority="high">

<em:to>Luca-B@hotmail.com</em:to>

<em:from>Mirko-L@ hotmail.com</em:from>

<em:cc>Giusy-M@ hotmail.com</em:cc>

<em:subject>Saluti</em:subject>

<em:body>Ti mando i miei saluti</em:body>

</em:email>

La prima cosa da notare è come, nell’elemento em:email, l'elmento principale, sia presente un riferimento allo spazio del nome dello schema. Inoltre nel documento tutti i tag degli elementi contengono il prefisso em, che li identifica come parte di un namespace associato. Questo significa che l'elemento è riconosciuto dall'applicazione come legato ad una struttura di documento in virtù di due cose: il prefisso em che li rimanda ad una dichiarazione nel prologo del documento ad uno schema, nel documento dove verrà espresso lo schema apparirà a sua volta nel prologo una dichiarazione che specificherà gli elementi utilizzati come attuatori di un certo tipo di funzioni (Floyd, 2000).

Ad eccezione della presenza di una dichiarazione nel prologo e della necessità di far precedere ogni elemento da un prefisso em, il documento presenta la stessa sintassi che si ci aspetterebbe da un documento XML collegato ad una DTD.

Da queste prime osservazioni relative a uno specifico file proviamo ora a capire meglio, almeno per le sue caratteristiche fondamentali, la sintassi di uno schema.

Il tipo di elemento è dichiarato nell’elemento ElementType (Giannì, 2000). A seguito della dichiarazione del tipo di elemento si deve inserire un attributo name, che definisce il nome dell'elemento. Ad esempio:

A questo punto è necessario definire il tipo di contenuto dell'elemento. Questo può essere definito attraverso l’attributo content.

Ogni tipo di elemento può contenere una delle quattro categorie relative al contenuto: vuoto, solo testo, solo sotto elementi o una combinazione di testo e sotto elementi:

§ Empty, se l'elemento non contiene alcun tipo di contenuto

§ TextOnly, se contiene solo testo

§ EltOnly, contiene solo sotto elementi

§ Mixed, nel caso di una combinazione di testo e sotto elementi

Utilizzando l’attributo order è invece possibile specificare l'ordine di apparizione degli elementi. Order possiede questi possibili valori:

§ Seq, in questo caso gli elementi devono apparire nella stessa sequenza degli elementi a cui si fa riferimento nella dichiarazione del tipo di elemento.

§ One, almeno un sotto elemento dichiarato nella dichiarazione del tipo di

elemento deve essere contenuto nell’elemento principale.

§ All, un elemento di ogni tipo dichiarato nella dichiarazione del tipo di

elemento deve comparire come sotto elemento, ma i sotto elementi possono avere un ordine qualsiasi.

§ Many, ciascuno degli elementi dichiarati nella dichiarazione del tipo di

elemento può avere un ordine qualsiasi.

E' anche possibile applicare vincoli in modo da determinare la posizione e il numero delle volte in cui un elemento o un gruppo può essere ripetuto all’interno di un documento. Gli attributi minOccurs e maxOccurs possono essere specificati all'interno dell'elemento ElementType. L’attributo minOccurs specifica il numero minimo delle ripetizioni di un elemento, mentre maxOccurs quello massimo. L'asterisco (*) indica che il valore può ricorrere più volte.

Come valore predefinito minOccurs e maxOccurs hanno 1, questo significa che, se non specificato diversamente, gli elementi devono occorrere una sola volta all’interno di un determinato tipo di elemento. Nell’esempio che segue il gruppo deve occorrere almeno una volta, quindi anche più volte:

</group>

</ElementType>

Uno dei vantaggi di XML Schema è quello di descrivere accuratamete il tipo dei dati trattati nella dichairazione. Come gli schemi sono definiti dallo spazio dei nomi xml-data, allo stesso modo i tipi di dati sono definiti dallo spazio dei nomi datatypes, come nel seguente esempio:

<Schema name="wildflowers" xmlns="urn:schemas-microsoft-com:xml-data"

xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882">

</ElementType>

</Schema>

Un tipo di dati viene definito riferendosi ad esso con l’attributo type nello spazio dei nomi datatypes (Giannì, 2000). Nell’esempio seguente, viene specificato un tipo di dati per il tipo di attributo dateorder:

</ElementType>

4.2.4 Visualizzare XML: Extensible Stylesheet Language.

Come si sarà capito una elaborazione in XML si costruisce grazie al collegamento di più file. Come abbiamo fin ora visto in un documento possiamo posizionare i soli dati, che non hanno nessuna forma se non che sono inseriti in una gerarchia di marcatura, in un altro definiamo la struttura che più documenti dello stesso tipo possono condividere. Fino a questo punto non abbiamo ancora detto nulla della visualizzazione dei dati. Secondo la filosofia del XML la visualizzazione del dato starà in un file ben distinto dal dato stesso. Questo significa che lo stesso gruppo di dati potrà essere visualizzato diversamente a seconda del documento di visualizzazione al quale verrà correlato. Questo fatto è molto importante perché rappresenta la fondamentale differenza fra una gestione dell'informazione tramite XML piuttosto che tramite un programma, che sia di scrittura, che sia un database o che sia un documento per il Web, progettato per gestire tutto il processo di trattamento dei dati, dall'archiviazione, alla trasmissione, alla visualizzazione.

I documenti utilizzati per descrivere la visualizzazione dei dati sono detti fogli di stile. Si possono adoperare diversi linguaggi per scrivere un foglio di stile per dei dati XML. Lo stesso HTML può essere utilizzato, tramite una tecnica chiamata di Binding dei dati, per consentire la visualizzazione di documenti XML. Un altro linguaggio molto utilizzato, grazie soprattutto alla sua diffusione in ambiente HTML, è quello dei fogli di stile CSS (Young, 2000).

Tuttavia il linguaggio che il gruppo di lavoro del Consorzio ha elaborato come foglio di stile per XML è XSL (Extensible Stylesheet Language).

Sostanzialmente XSL è un linguaggio di estrazione dei dati. Questo significa che l'applicazione, in base alle istruzioni del documento, estrae i dati di un altro documento e li posiziona all'interno della sua struttura di formattazione. Come una specie di copertina che lascia trasparire solo alcuni dati, il foglio di stile XSL si posiziona sopra il documento XML e porta alla attenzione dell'utente una certa forma del documento. Questa caratteristica è fondamentale perché determina tutte le implicazioni che derivano dall'uso di questo linguaggio.

Fino a poco tempo fa non esistevano software XML che fossero in grado di visualizzare un file XML secondo quanto espresso nei principi base del progetto del consorzio W3. La situazione era quindi tale che in attesa di un processore o di un browser che supportasse completamente XML si dotevano seguire diverse strade, ad esempio visualizzare i file XML con viewer SGML, utilizzare l’Active X Msxml, generare off-line dei file HTML da sorgenti XML e XSL.

La Microsoft è l'azienda che per prima ha sviluppato due parser XML che si integrano con Microsoft Internet Explorer 5, attraverso questa versione del famoso browser Microsoft è ora possibile visualizzare i dati XML utilizzando i fogli di stile XSL come dei file HTML e indipendentemente da questi.

Per visualizzare un file XML utilizzando XSL bisogna indicare il tipo e la locazione del foglio di stile XSL con le istruzioni di elaborazione. Bisogna cioè che a partire da un file XML si colleghi questo file ad un documento XSL adatto a visualizzarne i dati. La forma base per queste istruzioni di elaborazione sono del tipo

<?xml-stylesheet type="text/xsl" href="nome.xsl"?>

Quando Internet Explorer 5 sfoglia il documento XML, elabora l’istruzione di elaborazione, scarica il foglio di stile e lo utilizza per visualizzare il documento XML. Il valore dell’attributo type descrive il tipo del foglio di stile da attuare, se XSL "text/xsl" se CSS "text/css". L’attributo href è un collegamento URL relativo al foglio di stile. Se il documento XML non contiene queste istruzioni di elaborazione, Internet Explorer 5 visualizzerà il documento XML come un albero gerarchico con il codice di vario colore.

Per quanto riguarda Netscape, che inizialmente non aveva dimostrato molto interesse verso XML, sembra essere ritornata sui suoi passi. La versione 6 del browser Navigator contiene un processore in grado di leggere e formattare i file XML.

Una prima importante implicazione dell'utilizzo di uno strumento come XSL è che si avrà la possibilità di lavorare con dei modelli di stile. Si potrà cioè definire un modello di regole di formattazione per tutti gli elementi identificati da uno stesso tag e posizionati nello stesso ordine di struttura. Questo significa che indipendentemente dal tipo e dal numero di dati presenti nel mio documento XML potrò, tramite un'unica regola di formattazione, stabilire una visualizzazione a tutti gli elementi che presentino quella marcatura e quell'ordine strutturale.

Le istruzioni utilizzate per specificare gli elementi XML a cui viene applicato il modello XSL vengono dette pattern (Giannì, 2000). Il metodo di corrispondenza dei pattern rende XSL un linguaggio di dichiarazioni in contrapposizione con i linguaggi basati sulle procedure. Questo significa che i pattern definiscono il "livello" specifico della struttura del documento da far corrispondere identificandone la gerarchia della struttura. XSL si caratterizza fortemente per essere un linguaggio che agisce su una struttura, legato all'ordine gerarchico di posizione degli elementi. Per avere un’idea della struttura di un modello, sarà sufficiente prendere in esame un semplice foglio di stile. Sarà quindi necessario creare un documento XML a cui applicare il foglio di stile:

<CD>

<TITOLO>Metamorfosi</ TITOLO >

<GRUPPO> ESTRA </ GRUPPO >

< SCAFFALE DISPONIBILE="si">5A</SCAFFALE>

</CD>

</CATALOGO>

Quindi procedere con la creazione di un foglio di stile XSL per un unico modello dell’elemento TITOLO:

<?xml version="1.0"?>

<xsl:template xmlns:xsl="uri:xsl">

<HTML>

<BODY>

<xsl:repeat for="CATALOGO/CD">

<DIV>

<xsl:get-value for="TITOLO"/>

</SPAN>

</DIV>

</xsl:repeat>

</BODY>

</HTML>

</xsl:template>

Il primo pattern specifica qualsiasi elemento CD secondario all’elemento CATALOGO. Il secondo pattern per questa regola specifica l’elemento TITOLO. In base alla regola, qualsiasi dato trovato nell’elemento del pattern verrà inserito nell’elemento SPAN a cui viene quindi applicato lo stile "font-weight:bold; font-size:20". Questo modello espresso in modo discorsivo, sarebbe formulato nel seguente modo: "Ripetere quanto segue: per ogni elemento CD secondario dell’elemento CATALOGO: prendere il valore dell’elemento TITOLO e inserirlo nell’elemento SPAN applicando il grassetto e una dimensione di carattere pari a 20" (Giannì, 2000).

Quando il documento XML viene elaborato con il foglio di stile XSL, l’elaboratore genera il seguente codice HTML:

<HTML>

<BODY>

<DIV>

Metamorfosi

</SPAN>

</DIV>

</BODY>

</HTML>

Questo ci mostra come XSL non faccia altro che estrarre una serie di dati, per inserirli all'interno di un altro tipo di documento, che può essere scritto in un linguaggio diverso da XML. In questo caso, come nella più parte, sono inseriti dati XML in un documento scritto in HTML. La cosa è molto utile perché permette di produrre un file facilmente gestibile in ambiente Web, già coerente con la tecnologia delle piattaforme nelle quali verrà adoperato.

L'esempio sopra riportato costruiva un unico modello di formattazione. Un foglio di stile a più modelli utilizza i tag <xsl:stylesheet> </xsl:stylesheet>, che a loro volta possono contenere diverse coppie di tag <xsl:template> </xsl:template> (Giannì, 2000). Ciascuna di queste coppie può essere applicata indipendentemente dalle altre. Nell’esempio che segue è possibile esaminare in modo più approfondito questa struttura:

Figura 4.4 CDesempio.xml.

<!xml version="1.0">

<?xml-stylesheet type="text/xsl" href="CDesempio.xsl"?>

<CD>

<NOMI>

<TITOLO>Metamorfosi</ TITOLO >

<GRUPPO> ESTRA </ GRUPPO >

</NOMI>

<DATI>

</DATI>

< SCAFFALE DISPONIBILE="si">5A</SCAFFALE>

</ARCHIVIAZIONE>

</CD>

</CATALOGO>

<CD>

<NOMI>

<TITOLO>2020 SpeedBall</ TITOLO >

<GRUPPO> TIMORIA </ GRUPPO >

</NOMI>

<DATI>

<PRODUZIONE ANNO="1995">POLYGRAM</ PRODUZIONE >

</DATI>

< SCAFFALE DISPONIBILE="no">5A</SCAFFALE>

</ARCHIVIAZIONE>

</CD>

</CATALOGO>

<CD>

<NOMI>

<TITOLO>Stagioni</ TITOLO >

<GRUPPO> GUCCINI FRANCESCO </ GRUPPO >

<GENERE > Cantautori Ita</ GENERE >

</NOMI>

<DATI>

</DATI>

< SCAFFALE DISPONIBILE="si">4A</SCAFFALE>

</ARCHIVIAZIONE>

</CD>

</CATALOGO>

Nel listato seguente è riportato il foglio di stile dell’esempio precedente, il quale contiene diversi modelli che vengono applicati in modo indipendente alle diverse sezioni del documento XML:

Figura 4.5 CDesempio.xsl.

<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="uri:xsl">

<xsl:template match="/">

<HTML>

<BODY>

<TD>Titolo</TD>

<TD>Autori</TD>

<TD>Genere</TD>

<TD>Produzione</TD>

<TD>Prezzo</TD>

<TD>Ubicazione</TD>

</TR>

<xsl:for-each select="CATALOGO/CD">

<TR>

<xsl:apply-templates/>

</TR>

</xsl:for-each>

</TABLE>

</BODY>

</HTML>

</xsl:template>

<xsl:template match="NOMI">

</xsl:template>

<xsl:template match="DATI">

</xsl:template>

<xsl:template match="ARCHIVIAZIONE">

</xsl:template>

</xsl:stylesheet>

Sintatticamente bisogna fare alcune annotazioni. Un foglio di stile inizia con il tag <xsl:stylesheet> e termina con il tag </xsl:stylesheet>. La sigla xmlns è una parola riservata e serve per identificare un particolare namespace; ad esempio in questo caso tutte le parole riservate che iniziano con xsl: fanno parte del vocabolario individuato dall’URL htttp://www.w3.org/TR/WD-xsl.

Dal momento che il documento XML può avere un solo elemento principale e che l’XSL è un profilo di XML, il solo elemento xsl:stylesheet consente di includere più elementi xsl:template nel foglio di stile.

Il pattern di questo modello è semplicemente "/" e definisce l’elemento principale del documento XML. E’ presente anche l’elemento xsl:for-each all’interno del modello, che definisce un altro pattern, CATALOGO/CD, e stabilisce che la struttura generata che segue deve essere applicata a ogni sezione corrispondente al pattern. All’interno di tale struttura è contenuto l’elemento xsl:apply-templates che avvia la ricerca da parte dell’elaboratore di altri modelli nel foglio di stile, ciascuno con il suo pattern. Poiché l’elemento xsl:apply-templates si trova all’interno del pattern CATALOGO/CD, gli altri modelli verranno applicati solo quando verrà trovata una corrispondenza all’interno dell’elemento. Ad esempio, il modello NOME verrà applicato solo agli elementi nella gerarchia CATALOGO/CD/NOME (Giannì, 2000).

Ricapitolando l'intero ciclo di operazioni legate alla visualizzazione di un file XML possiamo evidenziare come il processo si svolga in tre fasi fondamentali.

Inizialmente, in base alla sua stesura, il foglio di stile specifica pattern che corrispondono ai dati rilevati nel documento XML. Questi pattern fanno parte di singoli modelli che contengono strutture di output.

A questo punto un elaboratore rileva i dati che corrispondono ai pattern e li converte nella struttura di output.

Una volta elaborato l’intero foglio di stile, nella memoria del computer esiste una nuova struttura di dati basata sull’output del foglio di stile.

A questo punto dovrebbe risultare chiaro come e in che senso si dice che XSL sia un linguaggio di estrazione dei dati. Questa sua caratteristica è molto importante non solo per le operazioni di visualizzazione. XSL, nella sua specifica XSL Trasformation, è un linguaggio che viene utilizzato anche per trasformare un documento XML in un altro documento XML con struttura diversa. XSL va a reperire i nodi di struttura di un documento ed è in grado, attraverso alcune istruzioni di trasformarli in altri nodi (Floyd, 2000).

Per l'impianto complessivo del linguaggio XML questa opportunità è importantissima perché accresce notevolmente la flessibilità dei documenti che possono essere trattati in più modalità, modificando, a partire dagli stessi dati, la struttura o il linguaggio di elaborazione. Tutta la potenza di XML si gioca sulla sua flessibilità e capacità di consegnare dati facilmente integrabili in ogni sistema.

4.3 Cosa cambierà XML.

Ora che abbiamo dato una generica scorsa al funzionamento tecnico di XML cerchiamo di capire cosa è possibile fare attraverso questo linguaggio, cosa la comunità informatica si aspetta da questa tecnologia, e cosa cambierà rispetto al nostro approccio alla conoscenza e alla gestione dell'informazione. Chiunque segua, anche da lontano, le vicende di Internet, sa quanto la comunità di tutti coloro che lavorano per o attraverso la rete, si aspetti da questo nuovo metodo di supporto dei dati.

Oggi come oggi la rete presenta alcuni problemi che hanno tutto l'aspetto di doversi acutizzare. Nel precedente capitolo abbiamo esposto il problema legato ai motori di ricerca. I motori di ricerca, nel mare dei documenti collegati, si stima alcuni miliardi di pagine, diventano un passaggio sempre più obbligato per la navigazione e tuttavia sono assolutamente inadeguati a dare una completa visione della informazione contenuta su Internet, si stima che i più grandi di essi possano al massimo considerare un quinto della rete (www.searching.com).

Un altro grosso problema legato alla attuale situazione della rete è quello della scarsa permeabilità dei dati archiviati. In base alla struttura di HTML, come già abbiamo detto, ogni pagina costituisce un'unità a livello di meri dati, ma anche di formattazione e di struttura del documento. E' difficile estrarre all'interno di un nodo-pagina, un gruppo di informazioni senza doversi trascinare l'intero documento. Esistono possibilità di collegare documenti HTML a database su server, consentendo lo scambio selettivo di informazione, tuttavia questi sistemi non sono mai facilmente integrabili fra loro e si pongono come isole chiuse alla comunicazione.

Secondo alcuni la soluzione di questi problemi potrebbe arrivare dall'adozione diffusa di XML come piattaforma base per la gestione dell'informazione, sicuramente in ambiente Web, in parte su tutto l'impianto informatico. Questo perché XML possiede le maggiori caratteristiche di flessibilità e di gestionalità ad ora mai sviluppate per un linguaggio informatico. XML presenta semplicemente dei dati, molto spesso unicamente di testo, che marca per organizzare in una struttura. Questi dati possono essere poi riorganizzati e visualizzati a più maniere, attraverso semplici istruzioni in forma script. XML si adatta a tutti gli ambienti, può essere trasformato nei documenti più svariati e non costringe quindi ad adottare una nuove piattaforme di elaborazione. XML inoltre, proprio per la sua adattabilità, accompagnata alla sua natura di linguaggio di marcatura, cioè di individuazione di una struttura di documento, offre dati facilmente attingibili, organizzati in una strutturazione permeabile, riconoscibile, ma non vincolante per la visualizzazione.

Queste premesse tecniche di XML, in base ad una analisi teorica, lo porterebbero a diventare il linguaggio adatto alla costruzione di un ambiente universalmente condiviso, nel quale l'informazione possa essere trasferita con la massima funzionalità nei punti nei quali sia richiesta. Se ci pensiamo bene niente altro che la promessa programmatica dell'ipertesto, e, ancora più in generale, della scrittura. Da quanti secoli si vagheggia un sistema, una tecnologia, in grado di consentire la totale archiviazione dei dati e la possibilità di convogliarli, magari già organizzati in relazioni strutturali, dove sia necessario consultarli?

Sicuramente non è possibile a priori capire quanto una tecnologia sia in grado di compiere queste cose e quanto no. I fattori in gioco sono tantissimi, economici, sociali, tecnici, e non si può fare altro che osservare il loro sviluppo. Tuttavia è chiaro che nella comunità informatica molti credono a questa possibilità, magari con un po' dell'ingenuo entusiasmo tipico dei modernizzatori, e stanno lavorando per realizzarla.

La Microsoft punta moltissimo sulla tecnologia XML. In una recente intervista Bill Gates ha motivato il suo entusiasmo per il cambiamento che XML porterà in rete (www.internetpolicy.org/briefing/current.html).

Il padrone della Microsoft nota per prima cosa come, sotto molti punti di vista, la Rete di oggi rispecchi il vecchio modello 'T' di processore costruito e lanciato da Henry Ford, con un browser rigido e tutte le informazioni conservate in database centralizzati che vengono presentate ai singoli utenti una pagina alla volta. Le pagine Web sono ancora una immagine, una rappresentazione dei dati e non sono i dati sottostanti. Si possono acquisire molti dati ma non li si possono facilmente modificare.

La soluzione a queste rigidità, secondo Gates, verrà proprio da XML che consentirà di separare i dati sottostanti di una pagina Web dalla loro presentazione grafica. In questo modo il dato inserito nella rete sarà accessibile, anche solo parzialmente, a tutte le piattaforme. Tale stato creerà una sorta di lingua franca del Web i cui effetti saranno pressoché straordinari. Sbloccando i dati sottostanti, infatti, si consentirà di organizzarli e modificarli, trasformando così ogni pagina Web in un minidatabase programmabile. Si potrà condividere qualsiasi tipo di informazione senza dover utilizzare lo stesso linguaggio di applicazione e i singoli siti potranno interagire in modo intelligente spostando facilmente dati da un database ad un altro.

La Rete di nuova generazione sarà dunque una iper-piattaforma di calcolo e comunicazione in cui convergeranno, in maniera continua, le informazioni di tutti i database, senza una distinzione netta tra periferiche e server. Con il crollo delle barriere tra informazioni in linea e database informativi Internet della prossima generazione avrà una sola interfaccia unificata in grado di muoversi in modo trasparente tra Internet e Pc, la cosa consentirà agli utenti di esplorare, scrivere, programmare, modificare o analizzare i dati comuni, a loro piacimento.

Tim Berners-Lee da tempo lavora al concetto di Web Semantico. L'ideatore del Web fondò fin dall'inizio le sue proposte sul concetto di interazione semantica fra dati. Berners-Lee propose di costruire una rete informativa partendo dalla semplice possibilità di link unidirezionali, come sono quelli HTML. Inizialmente fu obbiettato che la capacità di costruire relazioni in un sistema del genere era troppo debole per consentire il costituirsi di una rete informativa universalmente diffusa. Berners-Lee insisteva nel dire, e nel mostrare, che il solo rimando semantico avrebbe consentito una buona capacità per correlare i documenti. Per quanto tutti conoscano i limiti della attuale Rete, la sua rigidità e la povertà del link unidirezionale, bisogna certamente convenire sul fatto che i rimandi fra documenti, basati sulla semplice relazione semantica si sono dimostrati più che sufficienti per la costruzione di una rete universale in grado di funzionare produttivamente (Darnell, 1998, 12).

Per Berners-Lee l'estensione del rimando semantico, nel semplice presentarsi di un segno, l'estensione dell'attuale sistema di rete, sarà il Web Semantico. Il Web Semantico è una realtà che non si può dire esista già, esistono applicazioni in grado di funzionare su tali principi, ma perché l'idea sia realizzata bisogna che la diffusione del sistema sia sufficientemente ampia da proporsi come nuova struttura per l'intera Rete.

L'idea del Web Semantico si basa su un concetto molto semplice, se la rete è una trama di relazioni, essere in grado di gestire, di avere una visione più ampia su di esse, significa amministrarle meglio, significa conoscere il ruolo delle singole parti. Possedendo, a un certo livello della rete, informazioni sui rapporti fra i collegamenti, e sul loro significato, si potrebbe gestire lo scambio dell'informazione in modo molto più produttivo e automatizzato.

Il gruppo di lavoro del World Wide Web Consortium, guidato appunto da Berners-Lee, lavora al progetto del Web Semantico basandosi proprio su XML, perché è visto come linguaggio adatto a gestire dell'informazione sui dati, rimanendo applicabile a tutte le piattaforme, garantendo quindi la massima capacità di diffusione.

Le premesse programmatiche di un linguaggio come XML, si è visto, sono di enorme interesse e di impatto rivoluzionario sulle nostre modalità di gestione della conoscenza. Prima di proseguire lungo l'analisi critica delle implicazioni di XML sul nostro rapporto col sapere è bene rendersi conto di come attualmente sia utilizzato questo linguaggio. Molte aspettative sono riversate su esso, molti settori stanno affidando a questo linguaggio la loro futura evoluzione. Proviamo a vedere come e per quali motivi oggi come oggi XML è scelto come supporto tecnico alla gestione di differenti problematiche comunicative.

4.3.1 Aggiornare i dati a partire da un unico modello.

Chi scrive e coordina un sito in HTML, nel caso debba modificare l'informazione contenuta nella struttura o la struttura stessa del sito, deve rivedere pagina per pagina tutto il lavoro. Se in una tabella si devono modificare dei contenuti bisogna farlo cella per cella, se un dato deve essere presente su diverse pagine, questi va ripetuto su ogni singola di esse. L'unico strumento in ausilio ai webmaster per evitare riscritture complete di ogni pagina è il copia e incolla.

La possibilità, attraverso XML, di separare i dati dalla visualizzazione e di costruire fogli di stile che lavorano su modelli, che definiscono cioè una stessa struttura per tutti gli elementi marcati dallo stesso tag, è per la gestione di un sito un grosso guadagno (Floyd, 2000).

Per fare un esempio abbastanza banale immaginiamo di dover pubblicare su internet un elenco di CD con relative informazioni essenziali. Sul mio file XML dovrei naturalmente crearmi una struttura di marcatura adatta per l'inserimento dei dati estremi relativi ad un'opera musicale. Ad esempio potrei riprodurre il listato della figura 4.4, nel quale ogni elemento CD ha come elementi secondati NOMI, DATI, ARCHIVIAZIONI, secondo una struttura di questo tipo:

<CD>

<NOMI>

<TITOLO>Metamorfosi</ TITOLO >

<GRUPPO> ESTRA </ GRUPPO >

</NOMI>

<DATI>

</DATI>

< SCAFFALE DISPONIBILE="si">5A</SCAFFALE>

</ARCHIVIAZIONE>

</CD>

Nel file XML potrò ripetere questa struttura quante volte io ritenga utile, nel foglio di stile al contrario non dovrò descrivere la formattazione per ogni singolo elemento ma solo per la struttura, automaticamente la formattazione sarà estesa a tutti gli elementi con le stesse caratteristiche. Il mio foglio di stile si presenterà quindi nella forma della figura 4.5, e avrà validità indipendentemente dal numero di elementi CD che vorrò inserire, nonché dal contenuto che ovviamente potrà essere modificato senza dover inserire ulteriori istruzioni di formattazione.

Questa possibilità è per un Webmaster molto interessante perché gli permette di costruire una sola volta la struttura di visualizzazione del sito e di modificare in seguito solo i file che descrivono i dati. Inoltre una stessa base di dati potrebbe essere offerta a utenti diversi con diverse visualizzazioni. Queste peculiarità di XML fanno presagire che lo strumento sarà abbastanza facilmente in grado di venire accolto dalla comunità dei Webmaster e che di conseguenza sarà in grado di inserirsi nel tessuto del Web con discreta rapidità.

4.3.2 I motori di ricerca.

XML è un linguaggio di marcatura e in un certo senso, vedremo in realtà non così forte, permette di aggiungere informazioni semantiche al testo:

<AUTORE> Manuel Agnelli</ AUTORE >

Il tag di marcatura permette ad un elaboratore di leggere con più facilità i dati. Questo per due motivi, primo perché, marcandoli, li individua in uno spazio, inoltre perché, tramite un vocabolario, un applicazione potrebbe anche leggere il significato del tag e sapere di dover cercare proprio quel determinato tag e non altri. Un server collegato al Web potrebbe trovare tutti i documenti in cui Manuel Agnelli è l'autore.

In realtà la cosa non è così semplice. Perché la ricerca possa funzionare in ambito sufficientemente diffuso servirebbe uno standard di marcatura, un set di tag predefiniti e condivisi per marcare le informazioni. Facendo un esempio banale, un utente che inoltrasse la ricerca servendosi della parola chiave "compositore", non troverebbe alcunchè in un documento nel quale il nome del redattore delle opere musicali fosse marcato col tag <AUTORE>. Del resto uno degli elementi di forza di XML è quello di permettere una marcatura libera, in modo da consentire a chiunque di costruire una strutturazione il più possibile consona alle proprie necessità.

Il problema della difficoltà di condividere uno standard di marcatura può essere risolto tramite la creazione di vocabolari specifici. Singole categorie professionali o gruppi omogenei di utenti potrebbero, e già esistono esempi, costruire il proprio vocabolari di marcatura. A quel punto la condivisione di documenti, o di parti di documenti, all'interno di quella comunità può essere resa notevolmente più agevole.

Un punto chiave da tener presente nella prossima evoluzione dei motori di ricerca è quello definito dallo slogan: "L'informazione ha bisogno di conoscere se stessa, ma ha anche bisogno di conoscere me". Un'applicazione con lo scopo di compiere delle ricerche o di indirizzare la navigazione dell'utente dovrebbe non solo disporre di buoni dispositivi di localizzazione delle informazioni richieste, ma dovrebbe saper partire dalla conoscenza del tipo di utente che la sta interrogando (Giannì, 2000). Conoscere i gusti, le esigenze dell'utente può notevolmente facilitare il lavoro di ricerca. Sarà quindi utile costruire vocabolari preferenziali, campi semantici degli orientamenti dell'utente. L'esigenza di una semantica è oggi fortissima nel Web.

Un altro strumento che XML offre per incrementare le potenzialità di comprensione semantica di un documento sono gli RDF (Resource Description Framework). Si tratta della possibilità di inserire per un documento una serie di metadati relativi al documento, staccati dal documento stesso. In pratica si imposta per un documento una struttura di riferimenti, esterna al documento stesso, che sia in grado di descriverlo. La cosa interessante di questa specifica XML è quella di poter permettere ad un elaboratore di conoscere il contenuto dei dati, senza dover lavorare direttamente sui dati e sulla loro immediata formulazione.

Ad oggi questo genere di strumento è molto poco utilizzato e non è ancora riuscito a penetrare con successo nel Web, tuttavia si tratta chiaramente di una possibilità in più che andrà presa in considerazione e sulla quale il W3C ha dimostrato di voler investire. Più avanti tratteremo meglio la questione relativa agli RDF, per ora basti conoscere la possibilità di inserire metadati di descrizione dei documenti.

4.3.3 Distribuire ed elaborare dati complessi.

Un esempio interessante delle potenzialità di XML è il sistema di distribuzione dei dati adottato dall'industria dei semiconduttori. Ogni grande industria nel campo dei semiconduttori deve registrare e far circolare enormi quantità di dati tecnici relative ai circuiti integrati che produce. Per abilitare lo scambio di questi dati, anni fa fu formato un consorzio, il Pinnacles Group, formato da industrie quali Intel, National Semiconductor, Philips, Texas Instrument e Hitachi (Giannì, 2000). Lo scopo del consorzio era quello di sviluppare uno specifico linguaggio di markup in ambiente SGML in grado di esprimere tutte le complesse informazioni necessarie a descrivere un circuito. SGML garantiva una piattaforma neutra per la memorizzazione dei dati, che non avrebbe penalizzato il linguaggio di applicazione di nessuna azienda, consentendo la massima interscambiabilità dei dati.

Si potrebbe pensare che l'imporsi, attraverso una straordinaria popolarità, di HTML avesse fatto cambiare idea ai membri del Pinnacles Group, ma le limitazioni di tale linguaggio li convinsero che l'idea originale fosse più corretta (Giannì, 2000). HTML ha un set tag rigido, per una descrizione complessa di un documento è invece necessario possedere un set di tag estensibile, cioè strutturabile a propria scelta.

La scelta di utilizzare un linguaggio di markup come veicolo per la distribuzione dei dati sui circuiti integrati doveva permettere, non solo la loro visualizzazione, ma anche la possibilità di lavorare al progetto dei circuiti stessi. Questo obbiettivo fu raggiunto molto bene attraverso la tecnologia dei Java applet. Un applet Java tratta dei semplici dati di testo applicando su essi un processo computazionale. In questo modo un ingegnere può accedere al sito Web di una industria di semiconduttori e scaricarsi, non solo i dati di un particolare circuito integrato, ma anche un Java applet che permette di combinare i dati in vari modi.

Negli ultimi anni non è stato difficile per il consorzio trasformare la marcatura SGML in XML. I due linguaggi sono molto simili, tuttavia XML possiede una maggior semplicità e, di conseguenza, manovrabilità.

La gestione computazionale delle informazioni relative a un circuito integrato, non è tra le operazioni più semplici per un calcolatore, tuttavia tramite XML, tramite la possibilità di costruire una marcatura a dei dati su un supporto neutro, l'operazione diventa fattibile e anche facilmente trasmissibile.

4.3.4 Sistemi informativi in rete.

Moltissime aziende, o reti di realtà aziendali, hanno tra le loro prime esigenze quelle di gestire al meglio l'informazione che deve muoversi attraverso i vari settori produttivi. Questo lavoro di organizzazione delle informazioni per una rete di utenti viene definito, con termine forse eccessivamente impegnativo, gestione della conoscenza, e oggi esistono molte società specializzate in questo settore. Chi lavora in società di questo tipo ha tipicamente un grosso problema da risolvere. Per garantire una buona trasmissibilità dei dati sarebbe necessario possedere un criterio standard di archiviazione, in questo modo un'applicazione informatica sarebbe in grado di riconoscere i dati, di trasferirli dove necessario e di elaborarli. D'altro canto ogni settore produttivo è abituato a lavorare con le proprie applicazioni informatiche e pretende di poterle gestire con la più ampia libertà. Ad esempio il settore amministrativo fonda tutto il suo lavoro su applicazioni tipo Excel, mentre quello di progettazione su programmi grafici del tutto differenti. Per fare comunicare questi due sistemi applicativi è necessario attribuire ai dati un minimo di omogeneità, del resto non è possibile sminuire la potenza delle varie applicazioni specifiche, che nate per affrontare un certo tipo di lavoro si fondano sui propri sistemi.

Generalmente la maggior parte dei dati che l'esperto di gestione della conoscenza si trova a dover trattare non sono in alcun modo organizzati. La Sotware AG, una delle più importanti società di database stima che solo un 15% dei dati memorizzati al mondo siano riconducibili ad un database, il resto, 85%, è legato ai documenti più disparati, nelle applicazioni e nelle versioni più diverse (www.softwareag.com).

Queste difficoltà possono essere rese, almeno in parte, superabili con l'adozione di un sistema di interscambio delle informazioni basato su XML. In quanto linguaggio estensibile XML consente la marcatura dell'informazione e la creazione di un vocabolario di archiviazione dei dati. La sua propria particolarità di dividere dati dalla visualizzazione permette del resto di utilizzarlo come sistema ponte tra le varie applicazioni. Vediamo alcuni esempi concreti di come sia stato utilizzato XML.

I sistemi informativi delle agenzie americane di "home health care" sono stati recentemente ricostruiti attorno a XML. Questo tipo di agenzie sono il maggior componente dell'industria medica americana e la loro importanza sta aumentando da quando politiche governative hanno spostato l'assistenza medica ospedaliera verso l'assistenza medica domestica (Giannì, 2000). Il loro scopo è quello di gestire la storia medica di un paziente, questa è rappresentata nel sistema informativo attraverso una collezione di documenti storici che rappresentano la vita medica di una persona, passata attraverso vari dottori, ospedali, farmacie e compagnie di assicurazioni. Quando un nuovo paziente entra in una agenzia, c'è l'enorme compito di prelevare tutto il materiale e di memorizzarlo nel database dell'agenzia.

L'avvento del Web diede alla comunità informatica medica la speranza di poter semplificare lo sforzo di memorizzazione delle informazioni nel database; sfortunatamente le applicazioni Web esistenti offrono modelli di soluzione a questo problema inadeguati.

Gli ospedali offrono alle agenzie una soluzione che in poche parole è così riassunta: raggiungere il sito Web dell'ospedale, accedere alla documentazione medica del paziente attraverso il browser, stampare la documentazione, a partire dalla stampa inserire manualmente i dati nel database.

Ovviamente questa soluzione non può essere ritenuta completamente soddisfacente. La forma ideale per organizzare questo tipo di lavoro dovrebbe basarsi sulla possibilità di trasferire i dati direttamente da un database all'altro.

Quando si trova di fronte ad una esigenza di questo genere tipicamente un consorzio di grandi industrie definisce una Document Type Definition (in ambiente SGML) e implementa un linguaggio di markup specifico al suo scopo; a questo punto il linguaggio è utilizzato come standard per lo scambio dei dati.

La soluzione XML è indipendente dai sistemi, dalle organizzazioni e proviene dalla decennale esperienza di SGML. Anche nel caso delle home health care si è scelto di optare per questa possibilità. L'opzione di servirsi di XML come piattaforma base per l'interscambio dei dati è stata preferita alla proposta del governo che intendeva costruire un database standard, adottabile da tutte le società impegnate in questo tipo di attività. Il giorno del rilascio della prima versione stabile di XML, l'organizzazione che raggruppa le maggiori agenzie di home health care, ha infatti annunciato lo sviluppo di Health Care Markup Language in ambiente SGML (Giannì, 2000).

Per fare ulteriori esempi di utilizzo di XML nella gestione della conoscenza si può portare il caso di Software AG, un'importante azienda di implementazione di database, che ha rilasciato già nell’Ottobre del 1999 un database XML-nativo, sul quale ha puntato tutta la sua futura competitività. Questo database, denominato Tamino, è stato pensato, secondo le dichiarazioni della società, per inserirsi negli ambienti tecnologici più disparati, andando ad utilizzare tutto ciò che è stato già implementato, in modo da poter salvaguardare gli investimenti fatti in precedenza (www.softwareag.com).

Tamino è in grado di integrare in modo trasparente tutte le sorgenti dati esterne già presenti, presentando però all’utente i dati in un unico formato standard XML. Il vantaggio di una soluzione di questo tipo è che progettare una nuova applicazione basata su XML non comporta la conversione completa di tutto il proprio patrimonio informativo.

Tamino lavora alla massima integrazione basandosi innanzi tutto su una sua personale DTD per la definizione dei documenti. Tutti i documenti che sono allacciati al database sono in ultima istanza registrati come file XML, se un documento è stato salvato per mezzo di altre applicazioni questo viene trasformato, nella strutturazione dei dati, in formato XML. Tutto ciò che il database tratta e restituisce è quindi XML. La localizzazione dei dati è basata su XPath e più precisamente su un sistema denominato X-Query, che non è altro che XPath con l'aggiunta di alcune estensioni. XPath è un'estensione di XML che fondandosi sul fatto che i documenti XML sono sempre degli alberi gerarchici, localizza i nodi in virtù della loro posizione strutturale. Se esistesse ad esempio una successione di tag di questo tipo:

<padre>

< figliofiglio1> dati </ figliofiglio1>

</figlio1>

</padre>

XPath potrebbe localizzare i dati attraverso istruzioni del tipo: "Il terzo nodo di padre", "l'elemento che ha per padre figlio1 il quale ha per padre padre", "tutti gli elementi figli di padre", "tutti gli elementi figli di padre ma non i figli di figlio1". Naturalmente tutte queste operazioni sono intergate da alcuni algoritmi di intelligenza artificiale che le rendono rapide e maggiormente efficienti.

4.3.5 Codifica di testi.

Un altro campo, molto diverso da quelli trattati in precedenza, nel quale XML promette di diventare strumento fondamentale è quello della codifica dei testi. Studi filologici, linguistici e letterari hanno la necessità di accostarsi al testo con la massima profondità e precisione. Calcolare le occorrenze dei termini, stabilirne la posizione nel testo o la morfologia assunta, sono lavori che richiedono un grosso impiego di tempo e risorse umane, in modo particolare se queste operazioni vanno compiute su un ampio corpo testuale. Non da subito la realtà umanistica si è accostata volentieri allo strumento informatico, le ricerche tradizionali sui testi, anche dopo l'introduzione delle tecnologie informatiche, hanno continuato nella maggioranza dei casi a produrre volumi cartacei. Lo stesso si può dire per la maggior parte dei cataloghi di mostre e per molti cataloghi tematici.

A partire dagli anni '80 invece gruppi di ricerca all'avanguardia hanno utilizzato i primi database per produrre archivi. Via via l'uso di strumenti computazionali per la ricerca umanistica si è sempre più raffinato, diventando oggi una vera e propria disciplina a sè stante. Negli ultimi anni, anche in questo settore, si è scelto di affidarsi a XML, giudicandolo un supporto flessibile ma potente.

Per chi si occupa della codifica dei testi, quello che interessa maggiormente di questo linguaggio risiede nella sua natura di linguaggio di marcatura, e nel fatto che si costruisca attraverso un set di tag estensibile.

La realtà più importante in questo campo è quella della TEI (Text Encoding Initiative), un progetto per la costruzione e diffusione di uno standard internazionale di codifica testuale. Il Consorzio TEI, costruito da numerose realtà, che soprattutto nel mondo anglosassone, si occupano di linguistica computazionale e di informatica applicata all'umanistica, ha iniziato a lavorare nel 1987, finanziato dalle università di Oxford e di Brown (www.tei-c.org).

Inizialmente la TEI stabilì uno standard servendosi di SGML, oggi la codifica è disponibile anche in XML, con l'obbiettivo di renderla più agevolmente fruibile, in particolare sul Web.

La TEI ha costruito sei modelli base: prosa, poesia, dramma, parlato, lessicografico, terminologico. I modelli però non sono rigidi e possono essere riadattati alle proprie particolari esigenze di codifica testuale. Esistono infatti dei moduli speciali: link, figure e tabelle, analisi strutturali, trascrizioni, note critiche, grafici matematici, corpi linguistici. I moduli possono essere combinati variabilmente, i singoli elementi di ogni modulo possono essere rinominati, modificati o anche esclusi.

Molti sono i progetti che anche in Italia stanno lavorando alla codifica di testi, o di cataloghi di testi, basandosi sugli standard TEI. Solo per fare alcuni esempi concreti citeremo alcuni progetti importanti, senza tuttavia alcuna pretesa di essere esaustivi o di aver selezionato le realtà più significative.

In ambito bibliotecario negli anni recenti si è diffuso l'uso dei database relazionali, e sono state elaborate diverse procedure di catalogazione:

§ Manus, è un'applicazione realizzata in MS Access, dall'Istituto Centrale del Catalogo Unico del Ministero per i beni librari e le attività culturali (www.iccu.sbn.it/docmano.htm).

§ Codex, è un programma realizzato in CDS/ISIS, un software di information retrieval sviluppato dall'Unesco, di cui è recentemente uscita una versione per Windows, utilizzato ad esempio dalla Regione Toscana e dalla Regione Veneto (sismel.meri.unifi.it/CODEX/codex.htm).

§ Digital Scriptorium, è invece un'applicazione realizzata in MS Access (sunsite.berkeley.edu/Scriptorium).

§ Alla British Library è un database relazionale che è servito a organizzare i dati recuperati dai cataloghi a stampa con un sistema di riconoscimento ottico dei caratteri (molcat.bl.uk)

Alcuni degli archivi prodotti con questi strumenti sono attualmente interrogabili da Web. Tuttavia la presenza di archivi diversi ha posto con forza il problema dell’interscambio dei dati, si è posto così il problema definire degli standard.

EAMMS già da molti anni si occupa di realizzare una codifica comune in SGML/XML, in collaborazione con la Text Encoding Initiative e, da qualche tempo, con il progetto MASTER (Manuscript Access through Standards for Electronic Records), progetto finanziato dall'Unione Europea (www.cta.dmu.ac.uk/projects/master).

L’introduzione del linguaggio di markup XML fornirà una soluzione ai problemi più significativi della catalogazione elettronica dei manoscritti. In primo luogo essa permette di codificare in un unico formato sia dati strutturati provenienti dai campi di database relazionali, sia informazioni espresse in prosa, un tipo di informazione alla quale gli umanisti sono abituati e che sanno gestire spesso meglio che non quella fornita da un database. L’applicazione di questo formato di catalogazione permetterà quindi di far confluire in un'unica tipologia di archivio informazioni che fino ad ora sono state gestite separatamente, con poca attenzione ad un uso economico delle risorse in campo. Questo fatto renderà la consultazione di risorse bibliografiche un'operazione molto più agevole, meno dispendiosa in tempo e denaro, ma anche enormemente più accurata e precisa, perché risorse che fino ad oggi sono rimaste separate potranno convergere.

Il CRiBeCu (Centro Ricerche Informatiche per i Beni Culturali della Scuola Normale Superiore di Pisa), nell’ambito di uno studio metodologico sugli aspetti connessi all’interazione fra strumenti informatici e discipline umanistiche, ha avviato in collaborazione con il Gruppo di Ricerca sulle Basi di Dati ed il Gruppo di Ricerca sugli Algoritmi e le Strutture Dati, una specifica attività di ricerca orientata allo studio e alla sperimentazione di nuovi algoritmi e strutture dati per l’indicizzazione ed il recupero di dati da documenti strutturati, degli aspetti inerenti la definizione di un linguaggio di interrogazione (www.cribecu.sns.it).

Il frutto di questo lavoro è stato lo sviluppo di TReSy (Text Retrieval System), un motore di ricerca testuale in grado di effettuare ricerche sia sul contenuto che sulla struttura di documenti marcati in XML.

Lo sviluppo di TReSy nasce, con l’obiettivo di fornire un motore di ricerca in grado di offrire il più ampio numero di possibilità di applicazione nei casi più svariati di analisi di fonti letterarie, rispetto agli strumenti più comunemente utilizzati nel panorama delle metodologie applicate al text retrieval, sia in ambito commerciale che di ricerca. Per supportare alcune delle esigenze nate da applicazioni umanistiche TReSy si basa su una particolare e recente struttura dati per indicizzazioni testuali, lo String B-tree, e su una struttura dati per l’indicizzazione dei marcatori, l’Interval Tree.

TReSy ad oggi è stato utilizzato per l’interrogazione di diverse opere rappresentate con XML, già rese disponibili tramite Web o in CD. In particolare il gruppo di ricerca ha lavorato su: “Le Vite” di Giorgio Vasari; le Opere, la Biblioteca e le Fonti di Giordano Bruno; il Vocabolario della Crusca; il Corpus Informatico Belloriano ed il Corpus Epigrafico Sudarabico.

Il progetto, attualmente in fase di sviluppo, si propone principalmente di integrare TreSy come parte di un Sistema per Ricerche Testuali su Documenti XML (XTReSy: eXtended Text Retrieval System), che includa, oltre alle funzionalità di base di text retrieval, una maggiore potenzialità espressiva ed un insieme di nuove strutture dati che lo supportino. Tale progetto verrà utilizzato anche nell’ambito del Progetto Europeo META-e.

Il CIBIT (Centro Interuniversitario Biblioteca Italiana Telematica) ha sviluppato una biblioteca di testi elettronici dedicata alla diffusione e allo studio della cultura italiana. Tale centro è nato nel 1997, vi aderiscono 15 università italiane: L’Aquila, Catania, Ferrara, Genova, Messina, Napoli, Padova, Pavia, Piemonte Orientale, Pisa, Roma “La Sapienza”, Siena per Stranieri, Torino, Trento, Venezia (cibit.unipi.it). Il CIBIT oggi conta su un patrimonio di circa 1500 testi.

Inizialmente la registrazione dei testi venne realizzata grazie al software DBT nella versione Java-Html, ma la necessità di rendere disponibile al più ampio numero possibile di utenti tali risorse ha portato il centro a dover riflettere sull’opportunità di continuare a mantenere i testi nella codifica proprietaria prevista dal software DBT. La prima decisione che fu presa per affrontare questa difficoltà fu di convertire il patrimonio della Biblioteca Italiana Telematica nel linguaggio SGML che, per la sua natura di standard internazionale universalmente riconosciuto, avrebbe garantito a tutti i documenti digitali appartenenti alla biblioteca, di essere riportati ad uno stesso sistema di decodifica. Per le stesse ragioni il centro ha presto deciso di adottare il sistema di codifica TEI che allo stesso modo garantisce una standardizzazione dei dati riconosciuta a livello internazionale.

Nell’ultimo anno tuttavia, quanto deciso in prima istanza, è stato rivisto. Il centro ha perciò optato per l'adozione del linguaggio XML, preferito al SGML, in quanto strumento più aggiornato e flessibile.

Nel formato XML-TEI è stato convertito un campione di testi che attualmente è sottoposto a verifica da parte di Lou Burnard, principale coordinatore del Consorzio TEI, che dovrà certificare il sistema di codifica adottato da CIBIT come conforme a TEI. Parallelamente il centro si è mosso nella realizzazione di software adeguati per la conversione automatica dei testi dal formato DBT al formato XML e nella selezione di strumentazioni informatiche adeguate che potessero supportare i collaboratori delle varie unità di ricerca nella codifica di nuovi testi.

4.3.6 Altre adozioni di XML nella gestione dell'informazione.

In altri settori ancora XML sta per essere adottato, o già lo è, come linguaggio base di un sistema di gestione della informazione. In tutti i casi le motivazioni che portano a sceglierlo nascono dalla sua particolare flessibilità, sostanzialmente dalla possibilità di poterlo utilizzare come mezzo ponte fra più applicazioni e allo stesso tempo come strumento di indicizzazione dei dati.

Facendo alcuni esempi che ci paiono significativi porteremo ancora qualche concreta esperienza di implementazione di sistemi che sfruttano XML.

In campo legislativo ad esempio il Ministero della giustizia promuove dal 1999 il progetto NIR (www.normeinrete.it). Il suo obiettivo fondamentale è la creazione di un portale Internet unico di accesso gratuito a tutta la documentazione di interesse normativo prodotta nel nostro paese e disponibile nei vari siti istituzionali. Superando le architetture centralizzate che sono state finora adottate nelle basi documentali giuridiche, il progetto NIR tenta di riprodurre anche nel sistema informatico la nuova realtà costituita da una pluralità di organismi che producono documenti normativi.

A tal fine nell'ambito del progetto NIR sono stati costituiti tre Gruppi di lavoro interistituzionali, costituiti da funzionari, informatici, giuristi, ricercatori e documentalisti. Questi gruppi hanno fondamentalmente il compito di elaborare standard per la rappresentazione dei documenti giuridici.

Il primo Gruppo si occupa di costruire un set di DTD per gli atti normativi. Il secondo deve elaborare le metainformazioni da associare ai documenti. Il terzo ha il compito di creare un sistema di URN (Uniform Resource Name).

Un settore completamente diverso nel quale è possibile sfruttare le potenzialità di XML è quello dell'apprendimento a distanza. Il Dipartimento di Informatica e Studi Aziendali e il Laboratorio di Maieutiche dell'Università degli Studi di Trento hanno costruito un prototipo per la didattica in rete che si basa fortemente su XML.

Il prototipo consente ad un docente di preparare dei materiali didattici ipermediali e di utilizzare gli stessi in un’attività di didattica a distanza in tempo reale attraverso la rete Internet.

Il prototipo è costituito da due moduli principali. Il primo modulo consente la creazione dei materiali didattici. Questo modulo, scritto in Java considera XML come la struttura dati sottostante dei materiali didattici sicché il modulo è in grado di esportare ed importare in modo naturale materiali didattici ipermediali in formato XML. Il secondo modulo consente ad un docente remoto di pilotare i materiali didattici così costruiti direttamente sulle macchine degli studenti in modo da poter decider in quale momento della lezione far entrare in azione un determinato oggetto o documento, come farlo interagire con gli altri, come modificarlo.

Oltre alla possibilità di utilizzare la rete come strumento di comunicazione a distanza la forza di questo modulo sta nel fatto che una stessa base di dati possa essere utilizzata con modalità differenti in fase di progettazione della lezione, in fase di esposizione e in fase di registrazione da parte degli studenti.

In altri termini i materiali didattici di questo tipo sono fruibili in differenti modalità: come materiali con cui un docente fa lezione a studenti remoti, come materiali attraverso i quali si assiste ad una lezione impartita da un docente remoto, come materiali tradizionale di studio.

L'uso di XML, e la definizione quindi di una DTD, ha dotato il prototipo di un paio di vantaggi non ottenibili attraverso HTML. Si è creato innanzitutto un formato interscambiabile fra qualunque piattaforma hardware e software, che, unito a Java, ha reso il prototipo pienamente multipiattaforma. E' concessa la possibilità, una volta stabilita la DTD, di importare ed esportare in maniera semplice le lezioni da e in altri ambienti editor.

4.4 Il Web Semantico.

Le potenzialità di XML non si applicano solo a sistemi informativi chiusi, limitati a certi soggetti, ad aziende o reti comunicative che condividono un comune interesse. La forte flessibilità di questo linguaggio, il fatto che consenta di lasciare i dati permeabili a più visualizzazioni, la possibilità che offre di marcare i documenti, permettendo di accederne alla struttura, fanno sperare che su questo supporto potrà organizzarsi un nuovo tipo di rete informativa globale. Una Rete capace di fornire informazione in correlazione alle richieste dell'utente, dimostrando un certo grado di comprensione dei significati trattati. L'idea di un Internet maggiormente capace di ordinare l'informazione, di garantire ricerche automatiche e precise, è da sempre l'obbiettivo di un po' tutta la comunità degli utenti, come degli addetti ai lavori.

Dopo la decima International World Wide Web Conference, tenutasi a Hong Kong nel Maggio 2001, il termine Web Semantico ha incominciato a circolare per tutta la comunità informatica, diventando oggi ormai una specie di parola d'ordine alla quale tutti, magari anche con accenti critici, si stanno adeguando (La Vecchia, 2001). Nello stesso mese usciva su Scientific American un articolo di Tim Berners-Lee, che per la frequenza delle citazioni in rete, è diventato una specie di manifesto programmatico delle intenzioni del World Wide Web Consotium, circa la costituzione nei prossimi anni di un Web più "intelligente" (www.scientificamerican.com/2001/0501issue/0501berners-lee.html).

L'idea di fondo del Web Semantico è quella di rendere la rete maggiormente in grado di capire le nostre richieste. Non in senso proprio, ovviamente, ma nel senso che i documenti non dovrebbero più risultare come delle isole di dati, ma piuttosto come dei database aperti, nei quali una risorsa applicativa sia in grado di distinguere le informazioni contenute, ricavandone solo quelle richieste.

Attualmente il Web è una realtà costituita da documenti destinati quasi esclusivamente ad essere letti da un'utenza umana. Dalle news, ai comunicati commerciali alla poesia, tutto è rintracciabile sulla rete, ma poche cose possono essere comprese da un agente non umano. Per agente si intende un software in grado di eseguire compiti definiti da un utente, senza diretto controllo da parte dell'utente stesso (www.scientificamerican.com/2001/0501issue/0501berners-lee.html).

Il Web Semantico si propone proprio di inserire nell'architettura della rete elementi in grado di consentire ad agenti informatici una certa capacità di azione. Si potrebbe ad esempio immaginare che un motore di ricerca, scorrendo le pagine in rete alla ricerca di una prenotazione aerea, fosse in grado di capire quali link portano alle pagine relative alla destinazione richiesta, quali siano i costi e gli orari dei biglietti, di confrontare tra loro le offerte e di coordinare la partenza con l'agenda dell'utente o con le limitazioni sui costi che avesse voluto impostare. Tutto questo non in virtù di sistemi di intelligenza artificiale, ma molto più semplicemente in virtù di una marcatura dei documenti e di una lingua franca, cioè di un linguaggio gestibile da tutte le applicazioni e dall'introduzione di vocabolari specifici, cioè di collezioni di frasi alle quali possano associasi relazioni ben stabilite fra gli elementi marcati.

In pratica il Web Semantico per funzionare deve poter disporre di informazione strutturata e di regole di deduzione per gestirla, in modo da accostare quelle informazioni che un'interrogazione ha richiesto (www.scientificamerican.com/2001/0501issue/0501berners-lee.html).

La forza del Web Semantico non sarà solo quella di garantire una maggiore automazione nella ricerca e nella gestione dei dati, più in generale questo progresso della Rete porterà ad una maggior potenza nel gestire la conoscenza. Di fronte ad una enorme estensione di risorse, di informazione, come è la Rete, la capacità di avvicinare quelle più interessanti diventa capacità di ottenere una maggior conoscenza. Molto spesso idee innovative si affermano nella comunità umana solo all'interno di piccoli gruppi specializzati, e, anche quando sono di eccezionale importanza, faticano diversi anni per diventare acquisizioni condivise. Il Web Semantico, attraverso una certa automazione della conoscenza, dovrebbe aumentare notevolmente la possibilità di confronto fra informazioni, fra punti di vista diversi. Ipotizzando di costruire nel Web una rete semantica di tutti gli elementi immagazzinati, potremmo addirittura giungere fino a dire che automaticamente, la rete possa definire il significato degli oggetti che tratta e aggiornare questo significato qualora venga introdotta nuova informazione.

Come si sarà capito, la base tecnica per il progresso di questo progetto sarà offerta da XML, e dai linguaggi che si strutturano a partire dalla sua sintassi. Ovviamente sistemi di ragionamento automatizzato, basati sulla marcatura dei dati e sulla definizione di uno schema di regole, esistono già da decenni nel campo dell'intelligenza artificiale, la novità di XML risiede unicamente nel fatto di offrire la possibilità di un unico sistema globale di interazione dei dati.

4.4.1 Resource Description Framework.

Il Web Semantico baserà la sua architettura su tre livelli fondamentali, ben distinti fra loro. Al primo livello abbiamo i dati, a un secondo le informazioni sui dati e le relazioni che intercorrono tra dati, i metadati, a un terzo livello vocabolari, o ontologie, che definiscono il ruolo semantico dei metadati. I dati ovviamente dovranno essere visualizzati e in questo senso si potrebbe parlare di un quarto livello.

Il primo livello, come è già stato più volte ripetuto, è affidato a XML. Le caratteristiche fondamentali di questo linguaggio permettono una marcatura dei dati, e quindi una loro individuazione dentro una struttura, nonché la possibilità di rendere trattabili i dati da più applicazioni, con più visualizzazioni.

Il secondo livello, quello dei metadati, sarà affidato, secondo le intenzioni del W3C, al linguaggio RDF (Resource Description Framework). RDF è un linguaggio per la descrizione di metadati pensato per affiancare XML. I suoi elementi costitutivi e la sua sintassi sono XML, tramite l'utilizzo di alcuni namespace sono specificate le funzioni dei suoi elementi.

RDF consente di costruire delle asserzioni relativamente ai contenuti di una pagina web, queste asserzioni si costruiscono in base a triple di soggetto, predicato e complemento oggetto. Le asserzioni fatte individuano delle relazioni fra i dati di cui trattano, ma non ancora esplicitano il significato di queste relazioni. Se dico che un soggetto è predicato di un oggetto ho individuato una relazione, ho indicato gli elementi che entrano in questa relazione, ma non ne so ancora il significato, potrei voler dire che un certo nome corrisponde all'autore di una pagina, ma anche che una pagina è indicata da un certo link, piuttosto che qualsiasi altra cosa.

Per definire il significato delle relazioni serve un ulteriore livello, quello delle così dette ontologie. Le ontologie sono dei vocabolari nei quali collezioni di frasi sono associate a concetti e in pratica a regole logiche.

Le ontologie di dominio, cioè le ontologie relative ad una collezione di documenti, possono essere scritte in vari linguaggi, il più adatto a XML è RDF Schema, ma ne esistono anche di più evoluti come DAML (DARPA Agent Markup Language). RDF, ed ancor di più le ontologie, non sono tuttavia linguaggi ancora diffusi nel Web, molti addirittura dubitano della loro capacità di espansione, ed è quindi difficile esprimersi a riguardo della effettiva forma che assumerà questa sezione del Web Semantico. Gli scettici sottolineano come un sistema di comprensione semantica dei dati in Internet richiederebbe la quasi totale riscrittura delle risorse, cosa non fattibile in un database di, non si sa nemmeno esattamente quanti, miliardi di pagine. In ogni caso il W3 Consortium punta su RDF per la gestione dei metadati e questo già garantisce a questa tecnologia un'ottima base di lancio.

Consideriamo ora brevemente il meccanismo di funzionamento di RDF, in modo da capirne meglio le potenzialità. La prima cosa da fare per scrivere un documento RDF è dichiararne la sintassi, si aprirà quindi il documento con un dichiarazione di documento XML (www.w3.org/TR/1999/REC-rdf-syntax-19990222). Successivamente si aprirà il tag per indicare la sezione all'interno della quale si andranno a scrivere i metadati RDF, poi aprendo un tag rdf:Description si inizierà la descrizione di un elemento:

<?xml version="1.0">

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:s="http://description.org/schema/">

<rdf:Description about="http://www.w3c.org/Home/Lassila">

<s:Creator>Ora Lassila</s:Creator>

</rdf:Description>

</rdf:RDF>

Aprendo la sezione RDF, per prima cosa viene indicato il namespace di RDF che permetterà di definire la sintassi degli elementi RDF. Il secondo namespace si riferisce all'ontologia utilizzata in questa descrizione dall'autore, e permetterà quindi all'applicazione di definire il senso dell'elemento s:Creator.

All'interno dell'elemento rdf:Description l'attributo about indica la risorsa della quale si sta formulando un'asserzione. L'elemento rdf:Creator fornisce i dati relativi all'asserzione fatta sulla risorsa specificata (www.w3.org/TR/1999/REC-rdf-syntax-19990222).

Il fatto fondamentale dei dati RDF è che ogni asserzione viene espressa come una relazione fra un soggetto un predicato ed un oggetto. La risorsa indicata da about è il soggetto dell'asserzione. Il predicato è l'elemento in namespace che determina un valore. L'oggetto è questo valore indicato dai dati. Nel caso sopra esposto: la risorsa http://www.w3c.org/Home/Lassila (soggetto), ha come creatore (predicato), Ora Lassila (oggetto). Tutte le dichiarazioni RDF si basano sul costruirsi di triple. In pratica, intrinsecamente, RDF supporta solo relazioni binarie, cioè relazioni fra due risorse, per istaurare relazioni di livello superiore è necessario servirsi di una risorsa intermedia in grado di fornire le rimanenti relazioni che si intendano esprimere. L'ultima raccomandazione W3C fa un esempio di questo tipo. Consideriamo come soggetto uno degli articoli di John Smith. Possiamo associare alla risorsa un codice di valore ma questo dovrà poi essere a sua volta riportata ad uno schema, cioè a sua volta dovrà fungere da soggetto per il quale un predicato specificherà un valore (www.w3.org/TR/1999/REC-rdf-syntax-19990222). Per fare questo abbiamo bisogno di dichiarare due namespace, in modo da possedere due predicati:

<rdf:RDF

xmlns:="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/metadata/dublin_core#"

xmlns:l="http://mycorp.com/schemas/my-schema#">

<rdf:Description about="http://www.webnuts.net/Jan97.html">

<dc:Subject

rdf: value="020"

l:Classification="Dewey Decimal Code"/>

</rdf:Description>

</rdf:RDF>

L'altro concetto chiave di RDF è quello di reificazione. Reificare significa riportare ad un oggetto concreto una realtà astratta. Nel caso di RDF con questo verbo si intende indicare l'azione tramite la quale un concetto, l'elemento che funge da predicato, è riportato a due localizzazioni, due nodi pagina, dei quali si esprime una relazione. La particolarità e la forza di RDF sta nel fatto di indicare delle URI (Uniform Resource Identifier), cioè degli indirizzi in grado di localizzare esattamente e senza ambiguità una ed una sola risorsa. Questo fatto è fondamentale in quanto permette di stabilire esattamente gli oggetti di cui si parla e di dichiararne poi la loro appartenenza ad un determinato concetto. In questo modo si possono confrontare le risorse in rete e capire quali esprimono lo stesso tipo di concetto in relazione a quale altra concreta risorsa.

Per capire la particolarità di questo fatto pensiamo ad un ordinario file XML. In questo caso abbiamo una serie di dati che sono marcati da elementi, dei vari elementi è poi indicata la struttura e le relazioni fra di essi. Tuttavia gli elementi che si usano, i tag che si è scelto di adoperare, per la macchina non hanno nessun significato, se non in quanto si distinguono l'uno dall'altro. Per di più, gli elementi che io ho deciso di usare per indicare un certo tipo di dati non è detto che siano utilizzati anche in altri documenti con la stessa occorrenza. In pratica il computer non può confrontare i dati di due documenti decidendo se appartengono ad uno stesso concetto, ad uno stesso tipo di relazione. In XML per lavorare coi dati devo assicurarmi che appartengano ad una stessa DTD, o ad uno stesso schema, altrimenti si può ingenerare confusione.

Nel caso di RDF i dati che sono messi in relazione, oltre a definirsi in un concetto, che sarà poi specificato nella ontologia di dominio, sono indicati in modo univoco, come risorse che nella rete hanno una ed un'unica posizione. In questo modo i dati possono essere confrontati nella maniera più produttiva, consentendo addirittura di riconoscere uno specifico dato e di accrescere la conoscenza relativamente alla sua appartenenza a un concetto.

La cosa è di fondamentale importanza perché mette in gioco la capacità di referenza dei segni nella rete. In base a quanto detto fin ora si capisce che in un certo senso i "segni", cioè i dati archiviati in rete, in una prospettiva di questo genere, avrebbero la forza di richiamare automaticamente la loro referenza.

Queste che abbiamo definito sono le caratteristiche fondamentali del linguaggio RDF. Esistono poi una serie di possibilità per potenziare queste caratteristiche. Ad esempio sono possibili varie tecniche di abbreviazione delle dichiarazioni che sostanzialmente si basano sull'idea di nidificare i namespace e di inserire all'interno dell'elemento rdf:Description più attributi. Ad esempio, attraverso i tag rdf:Bag, rdf:Sequence o rdf:Alternative, esiste la possibilità di utilizzare contenitori per racchiudere una lista di oggetti da associare ad un soggetto.

<rdf:Description about="http://www.unicatt.it/studenticorso/6.html">

<s:Students>

<rdf: Bag>

<rdf: li resource="http://www.unicatt.it/studenticorso/Mario.html"/>

<rdf: li resource="http://www.unicatt.it/studenticorso/Franceso.html"/>

<rdf: li resource="http://www.unicatt.it/studenticorso/Luca.html"/>

<rdf: li resource="http://www.unicatt.it/studenticorso/Maria.html"/>

</rdf: Bag>

</s:Students>

</rdf:Description>

</rdf:RDF>

Per fare un esempio concreto riportiamo ora un file di descrizione di metadati di foto. Describing and reterving photos using RDF è un progetto che si pone un comunissimo obbiettivo: quello di fornire una descrizione tramite metadati per un archivio di foto, facilitando così nella ricerca il reperimento della giusta immagine, senza l'obbligo di visualizzare le singole fotografie archiviate (www.w3.org/TR/2000/NOTE-photo-rdf-20000928). L'ontologia di riferimento per dichiarare i dati si basa sul Dublin Core Schema, al quale è accostato uno schema addizionale per le descrizioni tecniche. Lo schema Dublin Core è un vocabolario di termini, sviluppato dalla Dublin Core metadata initiative, per la descrizione di vocaboli, libri figure ed immagini (http://purl.oclc.org/docs/core/documents/rec-dces-19990702.htm). A questo schema è stata poi apportata una modifica introducendo uno schema per le descrizioni tecniche delle immagini. Nell'esempio sottostante il primo namespace richiama la sintassi RDF, il secondo la sintassi Dublin Core ed il terzo lo schema tecnico appositamente studiato per questo progetto. I documenti che costituiscono lo schema Dublin Core sono illustrati all'indirizzo internet http://dublincore.org/documents/dces/. Gli elementi preceduti dal prefisso DC: si rifanno ad un'ontologia Dublin Core, gli elementi preceduti da Technical: si richiamano alla ontologia Dublin Core modificata per le esigenze di risorse fotografiche. All'interno dei tag sono espressi i metadati veri e propri dichiarati per le singole immagini.

Figura 4.6 esempio RDF.

<?xml version="1.0"?>

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:DC="http://purl.oclc.org/dc/documents/rec-dces-199809.htm#"

xmlns:Technical="http://www.w3.org/2000/PhotoRDF/technical-1-0#">

<rdf:Description about="">

<DC:Coverage>Montredon-Labessonié (Tarn)</DC:Coverage>

<DC:Source>Photo</DC:Source>

<DC:Relation>Marian in the Tarn</DC:Relation>

<DC:Date>1999-06-26</DC:Date>

<DC:Description>Marian brings the sheep to the field in the morning. The lamb she carries was born that night.</DC:Description>

<DC:Publisher rdf:resource="http://www.w3.org/People/Bos/"/>

<DC:Title>Marian with sheep</DC:Title>

<DC:Type>image</DC:Type>

<DC:Format>image/jpeg</DC:Format>

<DC:Identifier>990621</DC:Identifier>

<DC:Creator rdf:resource="http://www.w3.org/People/Bos/"/>

<Technical:camera rdf:resource="http://www.w3.org/People/Bos/CanonEos"/>

</rdf:Description>

</rdf:RDF>

4.4.2 Le ontologie.

L'ontologia è un vocabolario nel quale sono espressi i significati dei termini, gli elementi dei tag, utilizzati in una descrizione. Di un elemento bisogna identificare la risorsa alla quale si riferisce, la relazione che questo elemento ha con altri e un eventuale commento sul suo significato. Date queste tre cose sarà possibile applicare delle regole di deduzione logica per stabilire, se e in che condizioni, una risorsa, cioè una pagina web, può essere collegata a un'altra. Se ad esempio un'applicazione alla ricerca di un corso di linguistica leggesse in un file di metadati che la risorsa presa in considerazione ha come autore uno studente universitario, e la sua ontologia di riferimento collegasse gli elementi "studente" come sottocategorie degli elementi "università" e tra i sottoelementi di "università" descrivesse l'elemento "corso", per l'applicazione sarebbe possibile passare dalla risorsa attribuita allo studente alla risorsa attribuita al corso usando come ponte la risorsa attribuita all'elemento "università".

Una ontologia descrive insomma delle relazione fra elementi, fra tag usati per descrivere risorse, nei metadati invece vengono descritte relazioni fra risorse.

Ad oggi esistono diversi sistemi per scrivere un'ontologia. Nei progetti del W3C l'idea è di promuovere il sistema RDF Schema, che sempre in sintassi XML e attraverso l'uso di namespace, definisce relazioni per gli elementi RDF usati nella descrizione di metadati. Ad oggi lo stadio di valutazione del consorzio definisce questo sistema Candidate Recomandation, lo stadio precedente la raccomandazione vera e propria (www.w3.org/TR/2000/CR-rdf-schema-20000327).

Il vocabolario di RDF Schema è informalmente chiamato rdfs ed è richiamato tramite il riferimento all'URI http://www.w3.org/2000/01/rdf-schema#". In questa specifica si fa ovviamente riferimento alla sintassi RDF tramite l"utilizzo del nemespace rdf, ci si riferirà quindi all'URI http://www.w3.org/1999/02/22-rdf-syntax-ns#".

Nel documento RDF Schema si dovranno specificare le gerarchie tra gli elementi e in questo modo fornire ad un agente informatico la capacità di applicare ad essi regole di deduzione.

Per indicare le relazioni fra i vari elementi ci sono varie possibilità di definire un elemento.

§ rdfs:Resource. Ogni cosa descritta attraverso gli RDF è una risorsa. Solitamente si tratta di pagine web descritte dai metadati RDF.

§ rdf:Property. La sottocategoria di rdfs:Resource è rdf:Property.

§ rdfs:Class. Rappresenta il generico concetto di categoria.

§ rdf:type. Con questo tag si indica una risorsa della sintassi RDF e si dice di questa che è parte di una classe.

§ rdfs:subClassOf. Questa proprietà indica una relazione di dipendenza tra due classi.

§ rdfs:ContraintResource. Si indica una risorsa che si oppone ad un'altra risorsa.

§ rdfs:ContraintProperty. Si indica una proprietà che si oppone ad un'altra risorsa.

§ rdfs:range. Si indica la classe, o le classi, il cui valore di una proprietà sia membro della classe.

§ rdfs:domain. Si indica una classe che possiede una priorità gerarchica rispetto alla risorsa descritta.

Un esempio di listato RDF Schema potrebbe essere il seguente (www.w3.org/TR/2000/CR-rdf-schema-20000327). In questo esempio si indica che gli elementi MotorVehicle e Person sono collegati a quello registerdTo. MotorVehicle è una sottocategoria di registerdTo. Person è un valore che può essere assunto da registerdTo. Il tipo di risorsa indicato è una proprietà in base alle regole di sintassi RDF.

<rdf:RDF xml:lang="en"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">

<rdf:Description ID="registeredTo">

<rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

<rdfs:domain rdf:resource="#MotorVehicle"/>

<rdfs:range rdf:resource="#Person"/>

</rdf:Description>

<rdf:Description ID="rearSeatLegRoom">

<rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>

<rdfs:domain rdf:resource="#PassengerVehicle"/>

<rdfs:domain rdf:resource="#Minivan"/>

<rdfs:range rdf:resource="http://www.w3.org/2000/03/example/classes#Number"/> </rdf:Description>

</rdf:RDF>

Il linguaggio RDF Schema possiede molte altre proprietà e implicazioni. In questo lavoro non intendiamo però esplicitare tutte le sue funzioni quanto più semplicemente mostrarne il meccanismo di funzionamento. Quello che è importante osservare è come il linguaggio RDF Schema sia un linguaggio che costruisce i suoi significati in virtù delle relazioni fra gli elementi utilizzati negli RDF. In pratica i metadati descrivono relazioni tra dati, in particolare fra risorse, cioè pagine web, ma il significato di queste relazioni è costituito ad un secondo livello, quello dell'ontologia, nella quale nuovamente si definiscono relazioni, ma non più tra i dati quanto tra gli elementi, i tag, usati per descrivere quei dati. Tutto questo avviene con un costante riferimento a risorse, cioè ad una localizzazione precisa e univoca di dati. Questa cosa ci mostra molto bene come il Web Semantico si fonda completamente su una distinzione di molti livelli di significazione. Il ricorso a più livelli per la trattazione dei dati si motiva nella ricerca di flessibilità e di interscambiabilità dell'informazione.

In realtà non è obbligatorio che un sistema come RDF Schema sia una ontologia, intendendo questo termine per indicare non semplice vocabolario ma una descrizione semantica degli elementi. La definizione degli elementi può essere anche solo descrittiva e non proporre alcuna relazione, alcun rapporto di significato fra gli elementi espressi. E' il caso dell'esempio fatto precedentemente dell'uso degli RDF per la catalogazione delle foto. In questo caso lo schema applicato è puramente descrittivo ed introduce solo una traduzione dei vari elementi in più linguaggi ed eventualmente un commento sul loro utilizzo. Riportiamo qui lo schema tecnico dei metadati per una foto esposti nella figura 4.6.

Figura 4.7 RDF Schema.

<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns="http://www.w3.org/TR/1999/PR-rdf-schema#">

<comment xml:lang="en">A class that represents technical

data about a photo</comment>

<comment xml:lang="fr">Une classe qui réprésente

les dates techniques sur une photo</comment>

<comment xml:lang="nl">Een class die de technische

gegevens van een foto representeert.</comment>

</Class>

<rdf:Property rdf:ID="camera">

<label xml:lang="en">Camera</label>

<label xml:lang="fr">Camera</label>

<label xml:lang="nl">Camera</label>

<comment xml:lang="en">Brand and type of camera</comment>

<comment xml:lang="fr">Marque et type de camera</comment>

<comment xml:lang="nl">Cameramerk en -type</comment>

</rdf:Property>

<rdf:Property rdf:ID="film">

<comment xml:lang="en">Brand and type of film</comment>

<comment xml:lang="fr">Marque et type de film</comment>

<comment xml:lang="nl">Filmmerk en -type</comment>

</rdf:Property>

<rdf:Property rdf:ID="lens">

<comment xml:lang="en">Brand and type of film.</comment>

<comment xml:lang="fr">Marque et type de film.</comment>

<comment xml:lang="nl">Filmmerk en -type.</comment>

</rdf:Property>

<rdf:Property rdf:ID="devel-date">

<label xml:lang="en">Development date</label>

<label xml:lang="fr">Date de developpement</label>

<label xml:lang="nl">Ontwikkeldatum</label>

<comment xml:lang="en">Date on which the film was developed.</comment>

<comment xml:lang="fr">Date a laquelle le film a été

developpée.</comment>

<comment xml:lang="nl">Datum waarop de film is ontwikkeld.</comment>

<!-- use http://www.w3.org/TR/NOTE-datetime

format: YYYY[-MM[-DD[Thh:mm[:ss[.sTZD]]]]]

example: 1999-10-01T17:53

if TZD is omitted the timezone is UTC -->

</rdf:Property>

</rdf:RDF>

Questa osservazione ci fa capire come sia fondamentale l'esplicitarsi delle relazioni fra gli elementi se si vuole ottenere un sistema che possegga delle potenzialità semantiche, cioè la capacità di trattare i dati, e non solo di trasmetterli.

Se ad esempio in una descrizione di animali io definissi la classe dei carnivori, sicuramente il leone rientrerebbe in questa classe. Il leone è legato alla classe delle prede in quanto ne è mangiatore. Le prede sono anche erbivore e si collegano a questa classe, tuttavia gli elefanti che sono erbivori non sono prede in quanto un animale per essere definito preda deve possedere delle dimensioni massime che l'elefante supera. Una volta espresse tutte queste relazioni, senza la necessità di una esplicita descrizione un agente informatico potrebbe sapere che il leone non è mangiatore di elefanti.

La cosa interessante di un sistema di questo tipo è che non è rigido. Io infatti potrei definire, in uno schema, un insieme di relazioni fra le classi ma nulla vieta che in un futuro io possa collegare quello schema ad un altro che introduca nuove relazioni. Ad esempio in un nuovo schema si potrebbe affermare che gli elefanti possono essere adulti o non adulti, e che queste due classi si distinguono per la taglia degli animali. A questo punto un agente informatico potrebbe dedurre che il leone potrebbe mangiare solo elefanti non adulti ma mai elefanti adulti.

Il sistema di specificazione delle relazioni funziona ovviamente grazie a certi elementi della sintassi RDF Schema quali rdfs:subClassOf, rdfs:ContraintResource, rdfs:ContraintProperty. Con un'altra sintassi la comunicazione fra schemi non è possibile. Un grosso problema per il Web Semantico è quindi la messa in relazione di ontologie basate su sintassi diverse. Oltre a RDF esistono altri sistemi di ontologie, come ad esempio DAML o OIL (http://lists.w3.org/Archivies/Pulic/www-rdf-logic/2000Nov/0094.html).

4.4.3 Ontologie interscambiabili.

Oltre ad avere una base di dati interscambiabile ed un linguaggio per descriverli, il Web Semantico deve fornirsi della possibilità di definire il significato di questi dati, solo così la sua capacità di ricercare, accostare e selezionare l'informazione potrà basarsi su processi automatici. Come già detto l'attribuzione di un significato agli elementi è un'operazione affidata a vocabolari, detti anche ontologie.

La prima cosa che dobbiamo senz'altro rilevare è il fatto che questo livello rimanga staccato dagli altri. La cosa ha diverse conseguenze. Innanzi tutto se la definizione del significato delle relazioni fra le risorse rimane una cosa diversa dalle relazioni, questo significa che ad uno stesso schema di relazioni si possono attribuire significati diversi, a seconda delle esigenze e delle finalità. La conseguenza di ciò è in prima battuta la possibilità di aggiornare le definizioni con le quali si lavora. Oltre a ciò la grande acquisizione è quella di poter confrontare, per una stessa risorsa, più ontologie.

Questo ultimo fatto è il maggiormente significativo. Il Web Semantico, il linea teorica, potrebbe essere anche pensato come sistema funzionante a partire da un'unica ontologia. Possedere un unico schema di definizioni permetterebbe senz'altro di rendere tutte le risorse riconducibili tra loro, tuttavia ogni tipo di definizione non prevista dal nostro schema non potrebbe essere trattata dal sistema. Un sistema centralizzato collasserebbe sulla sua rigidità perché non potrebbe essere usato per "dire" molte relazioni che magari sarebbe utile esprimere.

Il fatto di consentire la libertà a chiunque di istituire la propria ontologia è al contrario molto più vantaggioso. Gruppi specializzati, abituati a trattare un certo genere di informazione, non avranno difficoltà ad istituire la propria ontologia, le proprie definizioni di riferimento. Ogni necessità comunicativa richiede termini specifici e porta a definizioni diverse dei termini in gioco. Le varie ontologie presenti nella rete potranno poi essere confrontate fra loro, tradotte, in questo modo la forza semantica di una risorsa, la sua capacità di significare non potrà che aumentare perché vista sotto l'effetto di ontologie diverse.

Attualmente il vero problema del Web Semantico è quello di raggiunger un'adeguata capacità di confronto fra ontologie diverse. Sostanzialmente il problema è quello della traduzione, come si traduce automaticamente un linguaggio in un altro. Intuitivamente si capirà che la questione non è di banale risoluzione.

Esistono da decenni sistemi di traduzione per dati posizionati sotto campi ontologici diversi. Queste applicazioni vengono soprattutto utilizzate per far comunicare fra loro due database o per trasferire i dati di un vecchio database in una applicazione più moderna.

Il sistema utilizzato per attuare queste traduzioni si basa sulla costruzione di un campo intermedio di transito dei dati. Questo campo intermedio riconduce alla propria categorizzazione le due diverse ontologie che sta mettendo in comunicazione. Ovviamente questi schemi di traduzione devono essere aggiornati qualora le definizioni all'interno delle ontologie dovessero cambiare. In questo sta la loro più grossa debolezza. In ogni caso è anche vero che è sempre possibile inserire elementi automatici di deduzione logica per l'ampliamento delle deduzioni. Sostanzialmente i vari traduttori esistenti oggi si distinguono per il grado di spazio che la parte automatica di deduzione logica assume.

Sistemi che fanno affidamento più fortemente su regole automatiche hanno meno necessità di aggiornamento ma falliscono qualora si tenti di inserire al loro interno elementi lontani dagli schemi logici utilizzati. Sistemi che si basano su un maggior lavoro di aggiornamento funzionano solo relativamente alle relazioni tra termini che sono state inserite.

Quello che è importante sottolineare è come in ogni caso questi mezzi di traduzione sono limitati nella loro definizione formale originaria. Non si discute qua la loro funzionalità e la loro efficacia, ma la loro possibilità di raggiungere la completezza. Ogni traduttore funziona a partire da un insieme di regole formali, la sua capacità di definire significati è limitata fin dall'inizio dal sistema formale adottato, non sarà mai quindi completa. La cosa interessante nel Web Semantico, visto che si basa sulla collaborazione fra più vocabolari ontologici, è che la sua forza di definizione non è legata ad un unico sistema formale, ma si gioca su diversi livelli in collaborazione fra loro. E' in ogni caso da notare come in realtà il dispiegarsi dei livelli si fermi al quarto o quinto grado (gli RDF, due o tre ontologie in relazione fra loro, un sistema di traduzione). Il sistema è ancora lontano dall'avvicinarsi alla completezza. In ogni caso è anche da concedere che la funzionalità di uno strumento tecnico debba essere valutata sul campo, nell'uso, e non può essere decisa a priori.

In un articolo di Steffen Staab, dell'università di Karlsruhe, intitolato An Extensiblee Approach for Modeling Ontologies in RDF(S), appare molto chiaro come le soluzioni per affrontare il problema della interscambiabilità delle informazioni espresse da un'ontologia sono di due opposti generi (www.aifd.uni-karlsruhe.de/WBS). Da un lato abbiamo la costituzione di Repository ben chiare e definite, di ontologie specifiche per un argomento condivise dalle aziende, e dalle realtà che ne trattano. E' questa una soluzione che punta alla standardizzazione di un sistema formale unico. All'opposto abbiamo la possibilità di lasciare liberamente comunicare le ontologie permettendo che nel confronto si accrescano le relazioni espresse fra i termini. Si tratta di una soluzione che incentiva la massima creatività e consentirebbe di creare un sistema veramente in grado di accrescere la nostra conoscenza.

Entrambe queste soluzioni hanno pregi e difetti. La prima è funzionale ma può fallire per la sua povertà, per la sua rapidità di invecchiamento, ed il rischio che si trovi a trattare informazione per la quale il sistema non è adeguato. La seconda è più flessibile, si adegua alla molteplicità del mondo informatico, intendendo sia la molteplicità dei sistemi applicativi, sia la molteplicità di soggetti che vi accedono. E' una soluzione che consente la registrazione di nuove relazioni semantiche pur restando in uno stesso sistema sintattico. Tuttavia non sempre è funzionale, può comportare errori nel funzionamento del sistema, può creare legami non significativi, insensati o che localizzano risorse non più esistenti (il famoso Error 404). Tim Berners-Lee ha sempre sostenuto che un sistema informatico con ambizioni semantiche dovrà abituarsi ad accettare l'imprecisione e l'errore (www.scientificamerican.com/2001/0501issue/0501berners-lee.html). Questo è sicuramente vero, poiché un sistema rigido, del tipo database centrale, non può funzionare su ampia scala, il successo di Internet nasce nel momento in cui si è rotta la logica centralista, tuttavia è anche vero che attualmente, e di certo anche nel futuro, il sistema sarà un sistema misto, che si baserà in parte sulla standardizzazione e in parte sulla possibilità di creare più sistemi di relazioni delle risorse. Sicuramente già negli ultimi anni si è visto come molte aziende o gruppi di aziende si siano mossi per la creazione di propri sistemi di interscambio dei dati, che fornissero un approccio standard al genere di informazione da loro trattato.

Attualmente i sistemi di traduzione più utilizzati, quelli coi quali lavora il W3C, sono: KIF (Knowledge Interchange Format) (www.semantic-translation.com) e UML (www-db.stanford.edu/skc).

4.5 L'ontologia di una rete di comunicazione.

Abbiamo visto quali sono gli stadi fondamentali attraverso i quali dovrebbe funzionare una realtà come quella del Web Semantico. Ovviamente, si è detto, il progetto su cui sta lavorando il Consorzio, per diventare realtà, dovrà essere in grado di superare, alla prova dei fatti, lo scarto, che esiste per ogni tecnologia, fra costi richiesti e benefici prodotti. In pratica il passaggio ad un sistema semantico nel Web potrà avvenire solo se la comunità dei naviganti sentirà questa esigenza come più forte rispetto alle difficoltà che la sua introduzione necessariamente comporterà. Gli scettici sottolineano come sia impossibile pensare ad una riscrittura dell'intera rete informatica. Tuttavia bisogna dire che perché il Web Semantico decolli non è strettamente necessario che la sua diffusione coinvolga l'intera rete, è sufficiente che la diffusione sia abbastanza ampia da rendere l'utilizzo di questa risorsa interessante, col tempo la permeanza semantica non potrà che aumentare.

Se pensiamo alla possibilità di marcare i dati, di visualizzarli in maniera differente, di costruire collezioni di metadati reificando le risorse, di attribuire a questi metadati vocabolari che li interpretino, ci rendiamo conto come i dati in una rete di relazioni di questo tipo siano veramente inseriti in una semiosi attiva.

Non può non ritornarci alla mente un'affermazione che David Bolter, di certo con eccessivo ottimismo, riferiva agli ipertesti, ma che con più successo si potrebbe forse utilizzare per il Web Semantico:

Si potrebbe dire che la teoria semiologica, acquista evidenza, un'evidenza quasi triviale, nel mezzo offerto dal computer. Nei mezzi di comunicazione precedenti come il libro a stampa, il riferimento dei segni a altri segni era solo potenziale. Il computer invece, inteso come testo apparentemente capace di lettura e di scrittura provvede a se stesso la sua propria semiosi. (Bolter, 1991, 248).

Verificheremo con più precisione queste affermazioni, ma è chiaro che le implicazioni di uno strumento, come quello che sarà forse il Web Semantico sono di questo tipo.

Per la prima volta nella storia dell'umanità si prospetta l'ipotesi di possedere una universale, o almeno tendente all'universale, collezione di segni in una concreta rete di relazioni concettuali. Se dovessimo intendere in modo forte una prospettiva del processo di semiosi come di un continuo rimando fra segni, avremo qui forse la possibilità di definire in modo chiaro e univoco il significato di ogni segno.

Questa posizione apparirà intuitivamente esagerata, e così, lo si vedrà bene, è di fatto. Tuttavia, di fronte ad uno strumento di comunicazione, uno strumento di semiosi, così potente la domanda da porsi va certamente in quella direzione. Quanto una rete di segni di questo tipo accresce la comprensione delle cose? Quanto i significati di ciò che noi intendiamo potranno essere avvicinati a oggetti concreti, a dati univoci ?

Durante tutto il novecento, quasi come se si stesse per preparasi all'avvento delle reti informatiche odierne, si è discusso moltissimo su questo problema.

Secondo Umberto Eco se ogni singolo segno di un sistema si rifà a un testo siamo immediatamente portati ad una prospettiva di semiosi illimitata, basata sul concetto di interpretante. La nozione di interpretante Eco la mutua direttamente da Peirce, che la introdusse nel 1895 (Eco, 1979, 27). Peirce parte dall'idea che un segno sta in luogo di qualcosa in qualche rispetto o capacità. Esso indica nella mente di chi lo usa, sia come mittente che come destinatario, un segno equivalente o piuttosto un segno più sviluppato. Questo segno che esso indica è l'interpretante.

Sorprendentemente questa definizione del processo di semiosi ci ricorda il meccanismo di funzionamento del Web Semantico, e in particolare del sistema RDF. L'interpretante potrebbe essere benissimo definito come il predicato che relaziona due risorse.

Ma dove sta il limite di questo processo semiotico? Dove significato e significante si toccano? A queste domande abbiamo già cercato di dare una risposta nel secondo capitolo, ma ora le riprenderemo, considerando anche i risultati ottenuti, posti di fronte alla concretezza di una vera e propria rete attiva di segni.

Peirce appare sicuro che il significato di una rappresentazione non possa essere altro che una rappresentazione e perciò non sia mai del tutto possibile raggiungere un limite, non compromesso dal continuo rimando, tuttavia egli stesso rileva che dovrà pure esistere una zona di confine tra il rilevante e l'irrilevante. Chi volesse definire la parola "litio" vedrà immediatamente quanto sia difficile stabilire per questo termine una distinzione tra proprietà necessarie o solo accessorie. Il litio potrebbe essere descritto come un minerale vitreo e traslucido, che talora appare come un globulo di metallo rosato argenteo, tuttavia certamente questa definizione non completa la totalità dell'informazione relativa al termine. Ad esempio non si considera come allo stato liquido esso assuma proprietà radicalmente diverse. L'unica altra strada che ci rimane è quella di dire che per riferire un oggetto è sufficiente rilevarne l'informazione semantica necessaria a inserirlo nei termini di un discorso. In questo modo Peirce arriva a definire la nozione di interpretante finale. Esso sarebbe un'abitudine, una tendenza a agire in modo simile in circostanze simili. Ogni segno, presentandosi in situazioni analoghe, produce una risposta regolare e questa si consolida fino a diventare una legge. Questa nozione di abitudine che si è così raggiunta non deve essere limitata ad una categoria psicologica, il suo consolidarsi si origina nelle risposte che un individuo produce in circostanze date, ma, poiché queste risposte sono frutto di un accostarsi al mondo, l'abitudine manifesta una regolarità cosmologica. Questo ci dice anche che l'esperienza viene a porsi come limite ultimo della serie dei rimandi.

Questo risultato ci mostra subito chiaramente una cosa. Esiste uno scarto tra il reale che agisce ed un sistema comunicativo, un linguaggio, che tenta di definirlo. Se noi definiamo la nostra conoscenza raffinando dei concetti in base a una regolarità che cogliamo attraverso l'esperienza, in un continuo processo mai completo, allora è chiaro che la realtà rimarrà sempre un pezzo più lontano della nostra capacità di definirla. Questo ci dice che l'ontologia espressa da un sistema comunicativo, qualora anche potesse esplicitare tutta la rete dei riferimenti, sarebbe pur sempre un'ontologia di ciò che noi conosciamo, non della realtà in sé.

Qualora anche si potesse ottenere un sistema di comunicazione, completamente universale e in grado di esplicitare tutti i riferimenti, l'ontologia da esso espressa, il significato dei segni in esso contenuti, non si potrebbe mai ritenere espressione della realtà, ma al massimo di ciò che l'umanità conosce della realtà.

4.5.1 Ontologie del mondo.

Ontologia dell'essere è quella scienza che tenta di dedurre le proprietà di ciò che esiste in quanto esistente, cioè non in quanto una particolare realtà ma in quanto una realtà che, perché reale, possiede le caratteristiche di ogni reale. In questo senso l'ontologia è intrinsecamente metafisica, è lo studio più assoluto dell'ente.

Accanto a questo tipo di ontologia esistono anche le così dette ontologie regionali, ontologie che tentano una definizione delle proprietà di specifiche realtà. Addirittura il metodo delle ontologie regionali è utilizzato da alcune industrie per definire collezioni di caratteristiche degli oggetti in produzione. Come collezione di caratteristiche e di relazioni il temine è mutuato anche nel mondo informatico.

In pratica bisogna evidenziare che la definizione di un'ontologia può possedere due tipi di implicazioni. Può applicarsi alla realtà in quanto tale o a realtà specifiche.

Prendiamo ora l'esempio di un lavoro che sintetizza questi due aspetti. Nicola Guarino ha lavorato molto sul problema della definizione di collezioni di proprietà. Il suo approccio è in prima battuta filosofico ma pone molta attenzione alle applicazioni concrete in campo soprattutto informatico.

Prendiamo in considerazione l'articolo A Formal Ontology of Properties, scritto in collaborazione con Christopher Welty (www.ladseb.pd.cnr.it/infor/ontology/ontology.html). Il punto di partenza per l'analisi è stabilito nella distinzione di tre idee fondamentali: quella di identità, unità ed essenza. Per capire queste tre idee è necessario confrontarle fra loro. L'unità si distingue dall'identità in quanto si parla di unità nel caso in cui si intenda distinguere fra parti. Nel caso dell'identità il problema che ci si pone è quello della permanenza nel tempo. Come una cosa rimane se stessa? Questa domanda ne pone immediatamente un'altra: quali proprietà di una cosa possono cambiare e quali no? La risposta a questo problema si affronta definendo l'essenza di una realtà.

A partire da questi problemi Guarino definisce alcune proprietà fondamentali. Non è nostro interesse elencarle tutte ma faremo alcuni esempi significativi. Una proprietà si dice rigida se è essenziale per tutte le istanze nelle quali si presenta. Non-rigida se non è essenziale per qualcuna delle istanze. Una proprietà rigida veicola condizioni d'identità necessarie se contiene queste condizioni come variabili libere e queste condizioni confermano l'identità. Proprietà con incompatibili condizioni d'identità sono disgiunte.

Ora la cosa che ci interessa notare è che un lavoro di questo tipo può avere due implicazioni molto diverse. Le proprietà definite possono essere intese come proprietà dell'essere in quanto essere, cioè come le proprietà condivise da qualsiasi essere. In questo senso il lavoro fatto può avere un'ottima precisione ma non ci dirà mai nulla sulle realtà individuali, nel senso che tutta questa griglia di proprietà non verrà riempita da singole realtà.

Se al contrario il mio intento è quello di utilizzare questa catalogazione come schema di distinzione e comprensione di realtà individuali le cose cambiano radicalmente. Se voglio inserire degli oggetti concreti all'interno di queste catalogazioni, in quanto lo ritengo utile per la loro gestione, devo decidere, per ogni singolo oggetto che io considero, quali siano le sue caratteristiche. Questo è esattamente l'approccio col quale vengono usate le ontologie nell'industria o in informatica. Sapere dove collocare un oggetto e in che relazioni porlo con altri mi può aiutare moltissimo a gestire il lavoro che dovrò operare tramite gli oggetti, soprattutto nel caso in cui la quantità di informazione relativa agli oggetti con cui operare è molto vasta.

Di questo approccio bisogna tuttavia sottolinearne la peculiarità. Se io colloco un oggetto in una categoria, se decido di attribuirgli certe proprietà e non altre, lo potrò fare solo in base alla preconoscenza che ho di questo oggetto. Dire, ad esempio, che due oggetti hanno proprietà disgiunte significa conoscere il comportamento di questi oggetti.

Un ontologia di questo tipo non apporterà propriamente nessun accrescimento di conoscenza, al limite permetterà di coordinare meglio la propria conoscenza, riconoscendo più rapidamente identità e disgiunzioni fra oggetti.

La cosa ricorda il problema del limite dei sistemi formali, e in un certo senso del teorema di Goëdel. Un'ontologia è sostanzialmente la definizione di un sistema formale, si definiscono regole per ottenere teoremi. In questo senso nessuna ontologia che vorrà applicarsi a degli oggetti concreti basandosi su una definizione chiusa di proprietà sarà mai completa. Qualunque cosa non prevista dalla nostra preconoscenza non riuscirebbe più a definirsi in questo genere di ontologia. Costruire un sistema di sapere concreto su un'unica ontologia significa fossilizzare la conoscenza, relegarla a essere sistema chiuso.

E' sorprendente notare come questo problema sia esattamente il problema che il Web si trova ad affrontare. Il sistema più facile per possedere un sistema coerente di scambio dell'informazioni potrebbe sembrare quello di definire un'unica ontologia per tutta la rete e di concepire le comunicazioni al suo interno tutte incentrate su quel tipo di ontologia. Ma questo in realtà sarebbe un sistema molto svantaggioso, non tutti i tipi di comunicazione, non tutti i linguaggi possono essere con coerenza riportati ad una stessa ontologia. Un sistema rigido non produce mai grossa quantità di informazione. La cosa ricorda le vicende legate ai primi anni di Internet. I detrattori di questo mezzo sostenevano che senza un database centrale il sistema non avrebbe mai funzionato. Al contrario la forza di Internet fu proprio nel non proporsi come sistema centralizzato, in questo modo l'informazione aumentò a ritmi eccezionali, creando in realtà una sorta di caos informativo, ma un caos all'interno del quale è contenuto sostanzialmente tutto.

4.5.2 Livelli di referenza.

Tim Berners-Lee ha insistito molto nel sottolineare che uno degli elementi fondamentali del Web Semantico sarà la compresenza di più ontologie (www.scientificamerican.com/2001/0501issue/0501berners-lee.html). Se si vuole un sistema dinamico, capace di crescere, raffinarsi e funzionare sul scala universale bisognerà pagare il prezzo di una certa dose di incoerenza. L'imprecisione del sistema è il prezzo da pagare alla sua universalità, i messaggi di not found non verranno insomma eliminati. Tutto questo per rendere possibile l'affiancarsi di più referenze e quindi non perdere, almeno in linea programmatica, la possibilità di più definizioni, di più comprensioni di uno stesso oggetto concreto. Se crediamo che un sistema comunicativo debba accrescere la conoscenza dobbiamo consentire l'accostarsi di più schemi referenziali, se di uno stesso oggetto possediamo più definizioni e queste potranno essere accostate, all'interno di una rete di rimandi, la nostra conoscenza dell'oggetto dovrebbe solo accrescersi.

Parlando del problema della referenza nel secondo capitolo, la nostra conclusione era stata quella di dire che la referenza di un segno ad un significato si esprime su più livelli, su più meccanismi regolativi, ma questi livelli non possono intendersi come rigidi o gerarchici, lungo di essi deve essere possibile muoversi agilmente da un piano all'altro.

Quello che dovrebbe avvenire nel Web Semantico, in un sistema concreto di gestione della conoscenza, è esattamente questo. I segni, a livello più basso i bit ma possiamo partire dal considerare i dati di script delle pagine in rete, sono collegati fra loro tramite un dispiegarsi di molti livelli. Ad un livello i dati, ad un livello la visualizzazione, ad un livello i metadati, ad un livello le ontologie. Questa modalità è la modalità che nella concretezza delle cose garantisce la migliore scambiabilità e gestione del dato.

Bisogna anche ricordare che una delle particolarità del Web Semantico è quella di collegare risorse, di esprimere relazioni nodi pagina che sono localizzati in modo preciso ed univoco. Con una parola si può parlare di questo fenomeno come di reificazione delle informazioni. In una collezioni dei dati RDF si esprimono relazioni fra concrete risorse. La referenza che si costituisce è in pratica diretta.

Questo fatto ci ricorda la teoria del riferimento diretto che appare nel dibattito logico con l'obbiettivo di dare una risposta alla domanda: cosa indica un termine? La teoria falliva perché non era in grado di tener debito conto dell'inscrutabilità psicologica per cui non è precisamente possibile dire come un parlante utilizzi un significato. Nel caso del Web Semantico questo problema scompare perché sappiamo sempre a cosa ci stiamo riferendo, di che unità di informazione affermiamo qualche cosa.

Il problema nel Web Semantico si sposta nell'individuare una modalità di scambio delle definizioni date di una risorsa. Per questo nascono le ontologie, per permettere che le definizioni date di una risorsa siano inserite in un sistema di concetti, gli elementi, i tag, usati nell'ontologia, maneggiabile da un agente software.

Come si è visto la modalità di gestione delle ontologie rimane in bilico tra un sistema centralizzato e standard ed un sistema estensibile di confronto fra le relazioni semantiche poste.

Il sistema standard garantisce senso al rimando di referenze poste fra le risorse, tuttavia è vincolato da ciò che già si conosce delle cose di cui si parla, è un sistema che si fonda sulla nostra precognizione della realtà.

Il sistema estensibile provoca errori e buchi nella rete semantica, tuttavia consente un più efficace accrescimento della conoscenza, poiché sperimenta automaticamente l'accostarsi di relazioni semantiche magari mai tentate prima.

Il Web Semantico si propone quindi come un sistema semiotico forte, ma non certamente completo. Non solo per i suoi limiti tecnici, per la finitezza dei suoi strumenti, ma in quanto si costruisce su un rimando dei livelli non completamente svincolato. Si sale e scende da un livello semiotico all'altro, dai dati all'ontologia, dai metadati ai dati, ma con delle interruzioni dovute alla necessità di rifarsi a dei sistemi formali definiti, le sintassi, i domini di ontologia.

Da quando l'uomo ha iniziato a tracciare segni e a scrivere, egli ha tentato di trasferire la referenza dei concetti fuori dalla sua mente, nel tentativo di esplicitarla e renderla evidente. Internet è il primo sistema nel quale la referenza dei segni sia attiva, automatica e rapida, poco legata alla linearità alla quale era costretto il libro. Non deve essere un caso se la soluzione alla quale la storia di questo media ha portato, nel tentativo di accrescere la funzionalità del sistema di referenza e di accessibilità ai dati, sia passata attraverso il disporsi su più livelli dell'informazione. A ben vedere tutta la storia dell'informatica è un costruirsi di un livello su un altro nel tentativo di aumentare la potenza di trasmissione dei dati.

Il Web Semantico, come soluzione si costruisce proprio nella dispiegarsi in più livelli dell'informazione. Se con HTML il grosso dei dati è posto tutto su uno stesso documento con XML si attiva un processo di dislocazione delle varie parti del documento.

Molto significativo è certamente anche il fatto che le ontologie del Web Semantico possono essere plurali. La capacità di definizione di una referenza è accresciuta quando questa sia liberamente svincolata da schemi prefissati. Ovviamente c'è la necessità dell'esistenza di schemi, di regole formali per il trattamento dell'informazione e la definizione delle referenze. Una certa regolarità è la solo possibilità per costruire un'automazione, per velocizzare le procedure, tuttavia è anche necessario lasciare spazio alla possibilità del raffinarsi di questi schemi, dell'accrescersi della conoscenza. Più in generale si potrebbe dire che un sistema costruttivo, un sistema a stadi finiti, deve costruirsi sul porsi di passaggi determinati, finiti appunto, ma che, poiché questi passaggi finiti hanno sempre un limite nella capacità di agire, il sistema sia portato a rivolgersi a livelli successivi per l'accrescimento della propria potenza.

4.5.3 Ontologia in attuale.

Sostanzialmente il Web è un sistema semiotico, è un linguaggio. Potremmo definire l'ontologia espressa da un linguaggio come ontologia in attuale. Come un ontologia che esprime la realtà in virtù dell'attuale stato di conoscenza condiviso dalla comunità che fa uso del sistema semiotico. Questa affermazione applicata a Internet, e in particolare ad un Internet semantizzato, diventa particolarmente interessante. La Rete si propone infatti come il luogo di archiviazione, gestione e scambio di tutta la conoscenza umana. Internet si propone come un sistema semiotico non solo universale ma totalmente pervasivo delle nostre azioni comunicative. Non è probabilmente lontana l'era nella quale anche tutti gli oggetti fisici di nostro uso quotidiano utilizzeranno micro cip per comunicare con la rete. Si profila uno scenario futuro nel quale ogni nostra azione potrà essere accresciuta nell'efficacia da un collegamento in rete. In queste condizioni diventa veramente interessante capire quale tipo di ontologia un sistema di questo tipo ci proporrà.

Chiaramente l'ontologia espressa da un sistema di comunicazione è il frutto delle conoscenze che fino a quel momento si è stati in grado di inserire in quel sistema. Le relazioni fra gli elementi sono quelle che si sono sapute definire. Ovviamente Internet non è un sistema di primo livello, nel senso che mutua la sua struttura e i suoi dati da altri linguaggi, dal linguaggio naturale, dall'esperienza umana, da linguaggi informatici. In questo senso non si può dire che sulla Rete vengano propriamente definita la realtà. Nella Rete entrano dati sulla realtà già ampiamente strutturati, tuttavia la rete è in grado di raffinare la capacità di confronto e utilizzo di questi dati accrescendo in questo modo anche la conoscenza della realtà. Oggi come oggi questa cosa avviene in una modalità sostanzialmente indiretta: è sempre l'uomo che fa il lavoro di sintesi, la macchina fornisce solo una maggior quantità di informazione più rapidamente. Col Web Semantico l'operazione di raffinamento della conoscenza diventa in parte automatizzata perché alcune definizioni delle cose sono contenute nelle ontologie.

In ogni caso è bene tenere presente di come le possibilità di costruire realmente una rete semantica in qualche modo completamente esplicitabile, siano limitate dalle capacità tecniche degli strumenti usati.

Gli RDF ad esempio hanno tra i loro pregi la semplicità della struttura assertiva basata su triplette. Questa struttura, che mette in relazione due risorse, o una risorsa e dei dati, attraverso un concetto, ha il pregio di essere facilmente gestibile da una applicazione, in linea teorica inoltre non chiude la possibilità a nessuna tipo di schema semantico perché consente, attraverso l'utilizzo di concetti ponte di far intervenire relazioni fra più risorse, di creare schemi circolari e gerarchie complesse. Detto questo è anche chiaro che lo schema base degli RDF è comunque binario e se lo si trasforma in uno schema fra più risorse lo si riesce a fare fino a un certo grado, se si prosegue eccessivamente nella costruzione di schemi basati su rapporti binari riallacciati tramite ponti, la struttura può cominciare a diventare pesante, sia per il programmatore che deve idearla, sia per la macchina che deve interpretarla attraverso continui rimandi a risorse in rete. In definitiva gli schemi RDF sono uno strumento che semanticamente potrebbe risultare molto potente ma che di fatto possiede dei suoi limiti tecnici intrinseci.

Per quanto riguarda le ontologie, il loro limite è dettato dal fatto che solo a piccolo gruppi possono essere confrontate. Un agente software che si trovasse a dover interpretare il significato di un termine medico, sotto il dominio di un'ontologia di ditte farmaceutiche, lo confronterebbe con le richieste del suo utente, che magari cerca uno specialista per una cura, e fermerebbe li la sua operazione. Nella prassi del Web Semantico gli agenti accosteranno piccole quantità di domini di ontologie alla volta. La cosa è ovvia e naturale, nonché pratica, tuttavia impedisce di pensare ad un possibilità fattiva di esplicitare tutti i rapporti fra ontologie, e quindi di dedurre una specie di posizione assoluta, di significato pieno, del termine trattato dall'agente. Nella realtà del Web Semantico i significati dei termini saranno ricavati molto in base alla necessità contingente e poco con l'obbiettivo di trarne il migliore dei significati possibili.

I campi di dominio dei termini si sintetizzeranno unicamente a piccoli settori: non ci sarà l'esigenza ne la capacità tecnica di trarre per un termine una sorta di significato trascendentale, attribuitogli dalla rete.

Quando si dice che il Web Semantico fornirà la forma attuale dello stadio del sapere, bisogna insomma tener bene conto di tutte queste limitazioni. In primo luogo solo parzialmente la conoscenza è gestita dalla Rete, molte sono gli elementi che direttamente sono inseriti in rete dall'esterno, inoltre anche nelle migliori ipotesi di sviluppo del Web Semantico la sua capacità di trattare i dati risulterà sempre parziale. Non qualsiasi tipo di informazione, a qualsiasi livello risulterà inserita nel processo referenziale. Non tutti i dati saranno definiti da schemi ed ontologie, non tutte le sezioni del documento saranno realmente dati interscambiabili. Quello che al massimo sarà possibile concedere a Internet e di definirlo come il sistema più potente per esprimere l'attuale condizione della nostra conoscenza. Più potente non significa però più preciso. Certamente il lavoro di sintesi compiuto dalla mente umana sarà ancora per molto tempo ampiamente più profondo e significativo che non quello che farà la macchina. Sulla rapidità e quantità di informazione gestita la Rete diventerà invece un supporto rivoluzionario che permetterà certamente di accorciare i tempi di apprendimento, sia del singolo, che dell'intera comunità umana.