UNIVERSITÀ DEGLI STUDI ROMA TRE Sviluppo di un

UNIVERSITÀ DEGLI STUDI ROMA TRE
FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA IN INGEGNERIA ELETTRONICA
Tesi di Laurea
Sviluppo di un sistema di gestione di metadati per la
descrizione dei contenuti di un archivio televisivo digitale
Candidato: Donato Biscaglia
Co-relatore
Relatore
2° Relatore
Ing.
Chiar.mo Prof.
Chiar.mo Prof.
Francesco Romano
Alessandro Neri
Claudio Palma
Anno Accademico 2001-2002
ABSTRACT
La tesi è stata svolta presso le strutture ed i laboratori dalla Scuola di
Formazione Superiore ELIS di Roma, nell'ambito del progetto Internet TV
commissionato dalla Rai Radio Televisione Italiana a “Vivai D’Impresa”, una
iniziativa della medesima ELIS.
La RAI impiega diversi archivi multimediali per conservare e ricercare le
trasmissioni, tra i quali l'archivio digitale Teca Fast. Questo enorme
patrimonio può essere utilizzato con mezzi tradizionali ed ancor meglio
sfruttando la rete Internet, che con la larga banda e le tecnologie legate ad essa
permette di ricevere grandi quantità di dati (ad esempio i filmati). I contenuti
audiovisivi di Teca Fast provengono dalle tre reti nazionali (Rai uno, Rai due
e Rai tre) e sono accessibili attraverso una rete intranet ad alta velocità, che
connette alcune redazioni attrezzate per la produzione di programmi come i
telegiornali. I motori di ricerca utilizzati in RAI per individuare una
determinata risorsa presentano alcune carenze che limitano l’efficacia delle
ricerche. Tali carenze sono tra l'altro dovute alla mancanza di
standardizzazione sulla struttura dei documenti di descrizione e alla presenza
di numerosi campi descrittivi a testo libero nella documentazione.Partendo dai
risultati ottenuti dalla prima edizione, il progetto è stato indirizzato allo
sviluppo di una applicazione Mpeg-7 mirata alla diffusione di risorse
audiovisive in rete geografica. Le risorse televisive, su cui utilizzare
l'applicazione, sono stati i telegiornali trasmessi dalle tre reti nazionali,
suddivisi in base alle notizie di ciascun servizio.
Inizialmente si sono ripercorsi i passi fondamentali del lavoro precedente per
comprendere la struttura di Teca Fast e per acquisire competenze sulle
infrastrutture Web e sulle tecnologie XML. Infatti le tecnologie, attualmente
impiegate sui metadati audiovisivi, sono per la maggior parte applicazioni del
linguaggio XML (eXtensible Markup Language), perchè per la creazione di
base dati XML propone strumenti più potenti e flessibili delle tradizionali
tecnologie (database relazionali oppure ad oggetti).
In seguito si è rivolta l'attenzione verso lo standard ISO Mpeg-7, sviluppato
dal gruppo Moving Picture Expert Group (MPEG), che è indirizzato alla
creazione e alla gestione di descrizioni per contenuti multimediali, a
differenza dei precedenti standard Mpeg rivolti più alla loro codifica.
La fase successiva del progetto è stata centrata sulle modalità di estrazione e
descrizione delle informazioni. Dopo numerosi contatti con ricercatori, che
lavorano intorno allo standard Mpeg7, si sono aperte alcune strade, ma solo
una ha avuto alla fine una base concreta. Il centro ricerche della nota società
di software RICOH Co ci ha fornito una versione del loro software, Movie
Tool versione beta, in grado di descrivere la risorsa audiovisiva attraverso il
documento Mpeg7 e di estrapolare alcune informazioni particolari.
pag. II
In seguito si è passati alla definizione di una nuova struttura dati per
l'inserimento di caratteristiche di più basso livello, aumentando così il
dettaglio del metadato, e all’implementazione del modello di documento in un
Data Base Management System XML nativo.
Nel progetto Internet TV si è definita la procedura di estrazione del metadato
per la descrizione di risorse audiovisive. Per tale descrizione, si è preso spunto
dalle informazioni contenute nel Catalogo Multimediale e nel Server SQL di
Teca Fast. Il software Movie Tool ha consentito di automatizzare in parte la
catalogazione della mediateca.
La piattaforma software, in cui inserire i documenti Mpeg7, è stata Tamino
XML DB della società Software AG. Oltre al Database XML, sono
configurati un Web Server Apache e il Java Servlet Apache, rispettivamente
per la gestione delle risorse tramite interfaccia di comunicazione http standard
e per l’elaborazione, lato server, delle pagine di risposta XML.
Successivamente i metadati sono stati inseriti nel DB utilizzando l'interfaccia
Web di gestione, che permette sia l'inserimento che l'eliminazione dei dati.
Sulla base del DataBase realizzato, si sono state progettate le interfacce per
l’interrogazione del DBMS, con funzionalità di ricerca avanzate utilizzando
funzioni Javascript ed oggetti ActiveX. Nel recuperare una determinata risorsa
AV in un preciso campo del documento Mpeg-7, si possono utilizzare
condizioni multiple, che permettono di effettuare ricerche più puntuali nella
struttura dei documenti di descrizione.
L’applicazione, su cui è stato possibile effettuare test dimostrativi delle
funzionalità del sistema, è stata denominata "TV NEWS ARCHIVE". Il
risultato delle interrogazioni mostra la descrizione della risorsa audiovisiva
(informazioni di palinsesto, sul formato, sui singoli servizi....) e può
visualizzare il contenuto delle singole sequenze audiovisive. Il server di
streaming utilizzato per questo scopo è “Real Server”, che permette una
maggiore flessibilità ed efficienza nella visualizzazione del video. Il servizio
fornito all’utente prescinde da conoscenze sullo standard Mpeg-7 o sulle
tecnologie XML.
In conclusione l'applicazione Mpeg-7 "TV NEWS ARCHIVE" è un sistema
completo per l'estrazione e la gestione di un archivio televisivo digitale dal
punto di vista dei Metadati proponendosi come importante esempio di
applicazione di "standard aperti".
pag. III
INDICE
CAPITOLO 1 TECNOLOGIA, INFORMAZIONE,
COMUNICAZIONE............................................................................................. 4
1.1 INTRODUZIONE....................................................................................... 4
1.2 LE TECNOLOGIE DI STREAMING...................................................... 5
1.3 LA LARGA BANDA .................................................................................. 6
1.4 IL DIGITALE TERRESTRE IN ITALIA ............................................... 7
CAPITOLO 2 GLI ARCHIVI AUDIOVISIVI...................................... 9
2.1 GLI ARCHIVI AUDIOVISIVI DIGITALI ............................................. 9
2.2 IL SISTEMA TECHE RAI ...................................................................... 12
2.2.1 IL CATALOGO MULTIMEDIALE .................................................. 16
2.2.2 L'ORGANIZZAZIONE DEL CATALOGO ...................................... 18
2.2.3 L’ACQUISIZIONE DEI DOCUMENTI MULTIMEDIALI ............. 18
2.3 L'ARCHITETTURA DELLA TECA FAST RAI.................................. 20
2.3.1 OPERAZIONI DI INSERIMENTO DEI CONTENUTI.................... 22
2.3.2 OPERAZIONI DI RICHIESTA DEI CONTENUTI .......................... 23
2.3.3 IL DATABASE DELLA TECA FAST .............................................. 24
2.4 I METADATI ............................................................................................ 25
2.4.1 INTEROPERABILITÀ DEI METADATI ......................................... 26
2.4.2 I METADATI AUDIOVISIVI............................................................ 27
2.4.3 NUOVE ESIGENZE PER I METADATI AUDIOVISIVI ................ 29
CAPITOLO 3 IL METALINGUAGGIO XML................................... 32
3.1 LE ORIGINI DEL LINGUAGGIO XML .............................................. 32
3.2 LE TECNOLOGIE XML ........................................................................ 34
3.2.1 DOCUMENT TYPE DEFINITION ................................................... 34
3.2.2 XML SCHEMA .................................................................................. 36
3.2.3 XPATH ............................................................................................... 40
3.2.4 INTERROGAZIONI IN XML............................................................ 43
3.2.5 VISUALIZZAZIONE DI DOCUMENTI XML................................. 45
3.3 IL MODELLO DEI DATI XML ............................................................. 49
3.3.1 IL MODELLO XML E IL MODELLO RELAZIONALE................. 50
3.3.2 DIFFERENZE TRA DBMS XML NATIVO E TRADIZIONALE ... 52
3.4 PROGRAMMARE CON XML ............................................................... 54
3.4.1 PARSERS STANDARD .................................................................... 55
pag.
1
CAPITOLO 4 MPEG-7 : MULTIMEDIA CONTENT
DESCRIPTION INTERFACE .......................................................................... 57
4.1 CONSIDERAZIONI PRELIMINARI .................................................... 57
4.2 INTRODUZIONE ALLO STANDARD MPEG-7................................. 57
4.2.1 STRUTTURA DEI MULTIMEDIA DESCRIPTION SCHEMES .... 60
4.2.2 GLI STRUMENTI BASE DELLO SCHEMA ................................... 64
4.2.3 DECOMPOSIZIONI STRUTTURALI DEI SEGMENTI ................. 78
4.3 ESTRAZIONE DELLE INFORMAZIONI ........................................... 83
4.3.1 MODALITÀ DI ESTRAZIONE ........................................................ 83
4.4 GENERAZIONE DEL DOCUMENTO MPEG-7 ................................. 87
4.4.1 L’ELEMENTO DESCRIPTIONMETADATA.................................. 89
4.4.2 L’ELEMENTO MEDIALOCATOR: LOCALIZZAZIONE
TEMPORALE E FISICA DELL’AUDIOVISIVO. ..................................... 92
4.4.3 L’ELEMENTO STRUCTURALUNIT: IL RUOLO DEL
SEGMENTO AV .......................................................................................... 96
4.4.4 L’ELEMENTO CREATIONINFORMATION: CREAZIONE E
CLASSIFICAZIONE.................................................................................... 97
4.4.5 L’ELEMENTO USAGEINFORMATION: USO DEL CONTENUTO
AUDIOVISIVO .......................................................................................... 105
4.4.6 L’ELEMENTO MEDIATIME ......................................................... 108
4.4.7 L’ELEMENTO MEDIASOURCEDECOMPOSITION :
DESCRIZIONE FISICA DEL CONTENUTO .......................................... 112
4.4.8 L’ELEMENTO TEMPORALDECOMPOSITION : DESCRIZIONE
DELLE SINGOLE SEQUENZE ................................................................ 118
CAPITOLO 5 REALIZZAZIONE DI APPLICAZIONE MPEG-7
"TV NEWS ARCHIVE".................................................................................. 124
5.1 ARCHITETTURA DEL PROTOTIPO................................................ 124
5.2 IL DBMS "TAMINO": ARCHITETTURA E COMPONENTI........ 126
5.2.1 CARATTERISTICHE PRINCIPALI DEL DATABASE TAMINO
XML:........................................................................................................... 127
5.2.2 LA PIATTAFORMA........................................................................ 129
5.2.3 X-MACHINE.................................................................................... 130
5.2.4 L’AMMINISTRATORE DEL SERVER ......................................... 132
5.2.5 PROCEDURA DI CREAZIONE DEL DB PROTOTIPO ............... 132
5.3 DESCRIZIONE DELLA RISORSA AUDIOVISIVA......................... 135
5.4 GESTIONE DEL DATABASE.............................................................. 136
5.4.1 INTERFACCIA INTERATTIVA DI GESTIONE DOCUMENTI.. 137
5.5 INTERFACCE DI QUERY ................................................................... 139
5.5.1 OPERAZIONI DI QUERY IN RETE ATTRAVERSO UN DBMS
NATIVO XML ........................................................................................... 139
pag.
2
5.5.2 IMPLEMENTAZIONE DI XML NEL WEB................................... 141
5.5.3 COSTRUZIONE DELLE INTERFACCE........................................ 144
5.5.4 INTERFACCIA DI INTERROGAZIONE SULL’INTERO TG...... 145
5.5.5 INTERFACCIA DI INTERROGAZIONE SUI SINGOLI SERVIZI
..................................................................................................................... 149
CAPITOLO 6 CONCLUSIONI E SVILUPPI DEL PROGETTO .. 152
BIBLIOGRAFIA, RISORSE IN RETE.......................................................... 154
APPENDICE A: LISTATO DEL DOCUMENTO DESCRITTIVO
REALIZZATO SECONDO MPEG-7 MDS................................................... 157
APPENDICE B LISTATI DEL CODICE DELLE INTERFACCE WEB.. 166
APPENDICE C LISTATI DEL CODICE DEI FOGLI DI STILE XSL..... 174
APPENDICE D TERMINI E DEFINIZIONI:.............................................. 188
pag.
3
CAPITOLO 1
TECNOLOGIA, INFORMAZIONE,
COMUNICAZIONE
1.1 INTRODUZIONE
Nel panorama economico dell’Unione Europea e in particolare dell’Italia, il
settore ICT (Information and Communication Technology) ha assunto un ruolo di
primo piano, e se ne può trovare agevolmente conferma nella crescente richiesta
di nuovi servizi da parte degli utenti.
Questo settore, nato dalla convergenza delle Telecomunicazioni e
dell’Informatica, è caratterizzato da un mercato a competitività crescente e da una
continua diminuzione del costo delle tecnologie di base (microprocessori,
memorie, larghezza di banda delle connessioni). Oggi si sta evolvendo dai
tradizionali aspetti applicativi, al nuovo ambiente Web-Oriented, rivolto al
business elettronico. L’elemento trainante in questa rivoluzione è Internet che
rende di fatto possibile accedere alle informazioni da qualsiasi posto in qualsiasi
momento.
Sono state create nuove opportunità nel campo della struttura delle reti, basti
pensare alle rivoluzioni della telefonia mobile e della telefonia su reti IP o alla
televisione su Internet, e parallelamente anche nel settore delle applicazioni come
nel caso del commercio elettronico. Oggi si dispone di un ambiente di rete
distribuito capillarmente a livello aziendale e domestico, in grado di supportare lo
sviluppo e la promozione di servizi multimediali interattivi.
Il telelavoro, l’e-learning, le reti tra università e centri di ricerca, i servizi
telematici per le Piccole e Medie Imprese, il monitoraggio ambientale, i servizi in
rete per la Pubblica Amministrazione, la telemedicina e la telediagnosi, sono solo
alcune delle tecnologie che possono divenire elemento trainante per l’intero
tessuto sociale e, al tempo stesso, stimolare la crescita, la competitività e
l’occupazione.
L’industria informatica sta attraversando una nuova fase. Dopo il primo ciclo dei
grandi elaboratori e delle reti di minicomputer dipartimentali (caratterizzato dallo
sviluppo di applicazioni centralizzate accessibili da terminali non intelligenti) il
secondo ciclo, che ha caratterizzato sostanzialmente l’ultimo decennio, ha visto
l’avvento dell’architettura client-server, con l’affermazione del personal
computer, dei sistemi aperti, delle reti locali e dei sistemi distribuiti come
conseguenza di una netta discontinuità tecnologica.
Il nuovo ciclo è quello che vede la straordinaria crescita di Internet e del network
computing, caratterizzato dall’evoluzione delle architetture distribuite, dei nuovi
ambienti di sviluppo quali Java, dal consolidamento delle tecnologie object
pag.
4
oriented in ambiente distribuito, da un nuovo livello di sicurezza e dalla presenza
di nuove applicazioni e servizi che hanno già cominciato a rivoluzionare il nostro
modello di vita. Basti guardare alla massiccia diffusione della telefonia attraverso
sistemi radiomobili, o alla richiesta di connettività a crescente larghezza di banda
dettata dalla diffusione di Internet e dei contenuti multimediali in formato digitale.
Multimedialità e convergenza portano a ridurre le distanze tra reti di
telecomuncizioni e reti informatiche destinate a fondersi progressivamente: la
complessità delle reti di telecomunicazione è così destinata ad aumentare. Una
gestione della complessità che permetta di mantenere un’elevata affidabilità dei
servizi con un grado di qualità fornita garantito, sarà una delle sfide tecnologiche
dei prossimi anni.
1.2 LE TECNOLOGIE DI STREAMING
Con la diffusione delle tecnologie di streaming ha consentito una maggiore
distribuzione dei contenuti multimediali in rete, in quanto hanno gradualmente
arricchito Internet, da un ambiente di pagine statiche con solo testo a un ambiente
real-time che offre contenuti multimediali. Le tecnologie streaming stanno
cambiando profondamente il modo e le forme in cui i creatori e i proprietari di
contenuti possono raggiungere il pubblico.
Lo streaming consente di trasferire i dati attraverso un flusso continuo su reti ‘best
effort’ e di presentarli sul client durante il trasferimento delle informazioni. Lo
streaming, ovvero le applicazioni client che lo supportano, consente la fruizione
di un filmato o di un brano audio, o anche di trasmissioni continue simili alla
trasmissioni televisive tradizionali, di eventi sia registrati (eliminando i lunghi
tempi di attesa per il downloading di dati completo) sia in diretta live.
Tali tecnologie sono alla base di un’ampia gamma di servizi multimediali "a
richiesta", che spaziano dalla formazione, all'informazione e all'intrattenimento: i
siti commerciali possono presentare cataloghi multimediali di prodotti, i portali di
formazione possono fornire lezioni basate su materiali video e audio, il pubblico
può usufruire di film o video clip musicali collegandosi a servizi di
intrattenimento in rete.
La tecnologia streaming utilizza algoritmi avanzati di compressione di segnali
audio e video ed altre tecnologie (molte delle quali sviluppate su piattaforme
software proprietarie) che consentono di negoziare l’ampiezza di banda, la
gestione dinamica di connessioni, la correzione di errori e il pre-buffering.
Le tecnologie streaming basate su connessioni Unicast non consentono un uso
efficace delle risorse di rete. Con l’IP Multicast, che consente l’invio di dati a
server distribuiti su una rete speciale di router con software abilitato, si è in grado
di distribuire flussi continui di dati a molti riceventi simultaneamente con
minimizzazione dell’ampiezza di banda occupata sulle singole connessioni. Una
pag.
5
modalità idonea per applicazioni Internet a uso intenso di dati, come
videoconferenze tra diversi utenti, trasmissioni televisive.
1.3 LA LARGA BANDA
Tornando allo scenario ICT ed in particolare alla connettività, uno degli elementi
chiave per il futuro dei new media è la larga banda.
Attualmente si registra una crescente domanda di accessi a larga banda,
supportata non solo dall’aumento del traffico dati per clienti affari, ma anche dalla
diffusa richiesta di servizi multimediali per i clienti residenziali (lo streaming
multimediale, i brani musicali MP3 e la messaggistica personale sono solo alcuni
esempi).
E' ormai diffusa la possibilità di fornire servizi di trasporto dati video digitali in
rete in alternativa o a complemento delle tecniche basate sulla trasmissione via
etere o via satellite (vedi iniziative come quella di Fastweb che propone nelle
grandi città Tv di alta qualità via Internet ad alta banda). Ed è proprio la richiesta
di nuovi servizi che ha portato ad un ripensamento delle modalità di sviluppo e
innovazione delle reti di accesso, alla luce delle possibilità offerte dallo sviluppo
delle tecnologie pertinenti.
Il mercato spinge i fornitori di accesso all’identificazione delle soluzioni
infrastrutturali che permettano di contenere i costi dell’innovazione, e che
garantiscano al contempo livelli di qualità adeguati alle diverse tipologie di
servizi. Importante è dunque l’ottimizzazione di soluzioni per l’accesso in grado
di coniugare al meglio la disponibilità di risorse delle reti in rame esistenti e le
potenzialità offerte dall’impiego delle fibre ottiche. Il successo di queste soluzioni
consente a gestori e costruttori la fornitura di nuovi sistemi di telecomunicazioni,
in grado di fornire servizi evoluti con costi contenuti e con un conseguente
stimolo del mercato.
Il futuro della Rete e delle sue future applicazioni passa inevitabilmente per una
radicale rivoluzione tecnologica chiamata broadband (letteralmente “banda
larga”); la necessità di questa rivoluzione è evidente a tutti: la capacità attuale dei
sistemi di trasmissione dei dati basati su reti sostanzialmente analogiche è
insufficiente per consentire piena integrazione e convergenza tra Internet e
contenuti multimediali, interattivi, audio(e)visivi.
L’attuale velocità delle trasmissioni su reti tradizionali varia dai 56 Kbps (kilobit
per secondo) di un comune modem ai pochi centinaia di Kbps delle linee ADSL,
di fatto tali capacità trasmissive sono assolutamente insufficienti per gestire
qualsiasi forma di fruizione audiovisiva e multimediale on line (streaming media,
video on demand, I-TV, gaming on line).
pag.
6
I “colli di bottiglia” di cui sono disseminate le classiche reti telefoniche
analogiche basate sulla tecnologia del doppino in rame vengono progressivamente
aggirati con tecnologie più efficienti di modulazione del segnale.
Questo nuovo orizzonte tecnologico coinvolge in maniera trasversale e sinergica
vari tipi di mercati ed aziende, dalle imprese di software, impegnate nella ricerca
di sistemi di compressione dei file sempre più efficaci e “leggeri”, ai granddi
gestori di reti di telecomunicazioni interessate a fornire servizi di connessione più
mirati ed efficienti ed a decongestionare le reti telefoniche; di fatto, uno dei settori
naturalmente più coinvolto nella sfida del broadband è quello dei costruttori di
reti, il cosiddetto mercato del “communications equipment”.
1.4 IL DIGITALE TERRESTRE IN ITALIA
Il processo di espansione del DTT (Digital Terrestial Television) è rapido e
nonostante gli investimenti da sostenere le potenzialità di mercato sono
favorevoli.
A differenza del digitale satellitare che oggi raggiunge circa il 20% delle famiglie
italiane (una quota ancora più bassa di quella stimata per Internet che connette
ormai oltre il 50% dei nuclei familiari), la copertura del DTT potrebbe
rapidamente raggiungere il 92% del territorio proprio in virtù di un costo per gli
utenti assai contenuto, che al contrario per il digitale satellitare, è stato mantenuto
artificialmente elevatissimo, riducendone la penetrazione.
Le aziende TV stanno pianificando ingenti investimenti per trasformare gli
impianti analogici e renderli compatibili con i nuovi standard. Il tempo previsto
per sostituire completamente la trasmissione analogica dovrebbe essere di cinque
anni, per essere in linea con quanto previsto in Francia e Germania che
completeranno la transizione al DTT entro il 2010.
Bisogna considerare che con il DTT l’etere televisivo si ampia enormemente e
dove oggi passa una sola rete in futuro ne avremo cinque. Per esempio Rai e
Mediaset ne potranno avere 15 a testa. Anche per le piccole emittenti cresceranno
le opportunità che potranno aumentare attraverso forme consortili per la gestione
di un bouquet di frequenze. La televisione commerciale potrebbe sfruttare
l'ampliamento delle frequenze anche per rafforzare il circuito del commercio
elettronico, sempre attraverso un maggiore sfruttamento del rapporto tra TV e
Internet.
La capacità di cogliere l'occasione dipenderà infatti da quanto l'azienda
radiotelevisiva italiana sarà capace di innovare le proprie strategie.
Anche la RAI ha investito di recente sulla presenza in Internet, per sfruttare
l'immenso patrimoni di contenuti di cui dispone. Alcuni segni di vitalità ci sono e
riguardano varie sperimentazioni, come RAI News o quelle su RAI Educational
pag.
7
(che ai programmi educativi accompagna una sperimentazione su servizi di
Internet TV e che proprio nella logica da servizio pubblico ha istallato oltre
cinquemila parabole digitali nelle scuole per farne centri di formazione a distanza
per docenti e cittadini sfruttando la combinazione tra web e satellite) o, ancora
quelle realizzate su Rai Tre (tra cui spicca l'esperienza di okkupati.rai.it sito
collegato all'omonima trasmissione settimanale dedicata ai temi del lavoro e della
formazione che ormai ha mensilmente più di centoventi mila utenti mensili per
oltre 1,2 milioni di pagine viste).
Grazie alle tecnologie digitali potrebbero aprirsi nuovi scenari e nuovi assetti.
L'evento conciliatore sembra essere legato al DTT, il Digital Terrestrial
Television cioè la televisione digitale che sostituirà presto l'attuale TV analogica e
che, sfruttando le antenne tradizionali, senza parabola senza altri fili e con
decoder permetterà di ricevere la nuova televisione digitale.
Anche se esistono numerose barriere tecnologiche che limitano il rapporto tra
televisione digitale ed Internet, la diffusione storica del primo e quella
esponenziale del secondo rendono il loro incontro decisivo per lo sviluppo della
comunicazione.
Tuttavia oggi è coscienti del fatto che i due media possano avere un sviluppo
separato, e le difficoltà di oggi celano in realtà una grande vitalità che si manifesta
nell'emersione di nuove soluzioni e nuovi prodotti. Il digitale terrestre rappresenta
per tutto lo scenario televisivo italiano ed in particolare per la RAI una "grande
occasione".
Perché è Internet che fa la differenza, è la rete che potrà portare le "famiglie” a
dotarsi di “televisori intelligenti" e soprattutto che permetterà loro di fruire di
nuovi servizi televisivi interattivi. Sarà l'integrazione digitale nelle sue molteplici
forme e canali a creare nuove opportunità e nuove prospettive per il mercato
televisivo e il DTT solo uno degli spazi potenziali per sperimentare tale rapporto.
pag.
8
CAPITOLO 2
GLI ARCHIVI AUDIOVISIVI
2.1 GLI ARCHIVI AUDIOVISIVI DIGITALI
Gli archivi digitali sono straordinari strumenti per la conservazione ed il
riordinamento dei dati. Uno dei motivi per cui i processi di archiviazione
sembrano diventare, sempre più, di importanza vitale deriva dal fatto che ognuno
di noi ha a che fare, ogni giorno, con una grande mole di informazioni.
Inoltre con la diffusione crescente delle nuove tecnologie di accesso, della
multimedialità via mobile internet, della Tv Digitale terrestre, via Internet, o via
tradizionale satellitare, si è riscontrata la necessità di una semplificazione e
automazione dei processi di gestione e fornitura dei contenuti audio, audiovideo, e
multimediali in genere.
Non si sa come gestire un enorme patrimonio appartenente a editori, produttori,
emittenti televisive e radiofoniche: una grande quantità di archivi multimediali,
collezioni di immagini, musica, audiovisivi, che necessitano di ambienti di
sviluppo adatti alle nuove richieste da parte dei nuovi media digitali.
Oltre a preservarli, è fondamentale anche la loro organizzazione e accessibilità
perché poter ricercare e estrarre contenuti di archivio costi abbastanza poco da
poter affrontare un discorso di commercio dei contenuti di archivio.
L’organizzazione è importante anche per l’archiviazione dei nuovi contenuti che
ogni giorno, in quantità enormi, vengono prodotti in tutto il mondo, basti pensare
per esempio ai servizi web basati sulla fornitura di documenti o immagini, che
devono essere comunque organizzati ed essere rintracciabili sulla rete. Dietro il
Web, dietro i nuovi media, dietro i nuovi servizi di rete, sempre si nasconde un
archivio e un sistema informativo che lo amministra e lo interfaccia con la rete.
Gli archivi possono essere di tipo tradizionale (cartelle e cassetti etichettati) o
digitali (quando il contenuto è disponibile sotto forma di bit), ma questi ultimi
sono senza dubbio degli strumenti straordinari per la conservazione ed il
riordinamento dei dati.
In particolare nella rete internet si hanno innumerevoli risorse informative, ma
spesso sono ingestibili. Fondamentale non è avere una quantità sterminata di
informazioni e risorse, quanto strumenti efficaci per effettuare ricerche e scelte,
ed è inoltre necessario dare un ordine ai dati secondo filo conduttore unico. Gli
archivi indubbiamente sono di aiuto nella ricerca di un criterio di classificazione.
Il corrispondente informatico di questo tipo di archivio è la base di dati, o data
base: un insieme di informazioni memorizzate su supporti digitali, come l’hard
disk di un personal computer. C’è un altra importante conseguenza legata
all’archiviazione digitale. Con la digitalizzazione il prodotto originato su un
pag.
9
qualsiasi supporto ‘fisico’ o media, dai libri, ai filmati amatoriali, alla musica e ai
film cinematografici, alle fotografie, possono essere convertiti in un documento
digitale e trattati come un insieme ordinato di bit, memorizzati, trasportati,
codificati come bit, ovvero come una serie di 0 e di 1.
Possiamo dunque disporre per tutti questi documenti ‘digitalizzati’ degli strumenti
di ordinamento e gestione dei dati tipici del mondo informatico. In più con la
digitalizzazione si garantisce una forte affidabilità nella conservazione dei dati.
Le informazioni digitali acquisite infatti non perdono di qualità col tempo proprio
perché scorrelate dal supporto. Un filmato digitalizzato manterrà per sempre la
qualità con cui è stato originariamente acquisito dal supporto analogico originale
e potrà essere agevolmente conservato grazie alla possibilità di effettuare copie
perfette dell’informazione digitale. Rapidità di accesso, facilità nella
consultazione, vasta documentazione disponibile in uno spazio ristretto sono
quindi i vantaggi più cospicui dell’archiviazione digitale su quella tradizionale.
A tutto ciò va aggiunto, naturalmente, l’uso multimediale in senso tecnico che
questo tipo di catalogazione ci offre: la possibilità di rendere utilizzabile, dentro
un unico supporto digitale, l’intera attività di un medium, dalle sue origini ad
oggi.
Un esempio è proprio quello che sta avvenendo per i programmi della televisione
e della radio pubbliche in Italia, attraverso la realizzazione delle Teche Rai. A
quasi mezzo secolo di attività la Rai Radio Televisione Italiana ha messo a punto
un complesso sistema di archiviazione digitale di tutto il materiale radiofonico e
televisivo prodotto sino ad oggi.
Essa sta concentrando i propri sforzi sulla messa a punto di processi di
archiviazione e gestione dei contenuti giornalmente prodotti nonché del vasto
archivio storico esistente. Teche Rai, una nuova struttura creata ad hoc alcuni anni
fa per gestire i processi di conservazione, catalogazione e digitalizzazione sia
degli archivi che dei programmi quotidianamente prodotti, prevede di terminare la
trasformazione in formato digitale di tutto il patrimonio video e audio dell'azienda
entro pochi anni.
Tra gli obiettivi delle Teche Rai c’è quello di favorire una produzione televisiva
digitale più veloce ed economica (abbassamento dei costi e tempi di richiesta,
consegna e lavorazione dei materiali audiovisivi dall’archivio originali).
Il progetto di archiviazione digitale delle Teche Rai è molto ambizioso e in linea
con le più importanti linee progettuali dei maggiori broadcaster in tutto il mondo.
Con la razionalizzazione e digitalizzazione degli archivi la televisione pubblica
italiana si
Le innovazioni dell’archivio si ripercuotono direttamente sulla produzione dei
programmi: la regia può connettersi in rete informatica direttamente con l'archivio
pag. 10
digitale Teca Fast di Rai e richiedere le risorse, intese come sequenze video,
necessarie alla produzione. Il cambiamento interessa dunque anche la confezione
dei programmi stessi, e il montaggio.
Attualmente con il Catalogo Multimediale di Teche Rai è possibile attingere a
documenti testuali, foto digitalizzate, programmi radio e sequenze video
codificate in MPEG-4 (un archivio sull’archivio o sistema di archivi di diversi
media). I giornalisti e gli operatori possono visionare i video digitalizzati e
archiviati in un database centrale interrogabile e direttamente accessibile
attraverso le postazioni delle redazioni connesse alla intranet aziendale e cercare
negli archivi tutti i video per i quali sono disponibili delle descrizioni o una
qualche catalogazione, utilizzando un normale web browser.
Una volta individuati e raccolti i video i giornalisti potranno richiedere una copia
degli originali (per materiali su supporto audiovisivo tradizionale) o editarli e
trasmetterli ad alta qualità televisiva attraverso i video server disponibili (per
materiali presenti nella teca digitale, la Teca Fast).
E sempre in Italia anche la società Mediaset ha investito per la convergenza tra tv
e web. Con l’implementazione di un sistema di archiviazione e gestione dei video
,esso permette di indicizzare in un data base centrale i video trasmessi dalle testate
Mediaset previa trasformazione degli stessi in un formato video MPEG4 che può
essere facilmente diffuso attraverso Internet.
L’esempio seguito è quello dell'americana CNN, impegnata da tempo nello
sviluppo di nuovi processi per la gestione e l'archiviazione dei contenuti in
formato digitale, utilizzando i sistemi di Virage. Un altro archivio audiovisivo di
grande importanza, tornando in Italia, è quello dell’istituto LUCE, dove sono
conservati numerosi cinegiornali e documentari, con materiale che va dagli albori
della cinematografia fino agli anni ottanta della cronaca italiana e già da decenni è
aperto a storici, registi e ricercatori nazionali e internazionali.
La catalogazione digitale dell’archivio, con la parallela digitalizzazione dei
supporti filmici, consente alla LUCE di dare un ordinamento alle centinaia di
migliaia di notizie che formano la trama di un immenso tessuto di immagini.
Il mercato dei contenuti per un archivio audiovisivo (RAI e LUCE ne sono solo
due esempi) è naturalmente orientato alla vendita di diritti su materiali da
destinare a diversi media, dai diritti di trasmissione televisiva, di packaging home
video, di utilizzo in montaggi cinematografici, confezionamento di CD-ROM e
applicazioni multimediali, diritti di trasmissione via satellite, pay tv, web.
In generale l’industria dei media ha scoperto nel Web un formidabile strumento
per gestire e condividere anche a distanza il proprio tesoro più prezioso - gli
archivi di programmi, articoli, musiche, effetti speciali e così via (le mediateche
pag. 11
insomma) - consentendo in tal modo un decentramento e uno snellimento
notevole dei cicli di programmazione.
2.2 IL SISTEMA TECHE RAI
Il patrimonio di archivio della televisione pubblica nazionale si trova distribuito
su diverse strutture sul territorio nazionale. L’archivio principale è l’archivio Teca
Master o Teca Centrale, che raccoglie nella sede di Roma una quantità
impressionante di supporti audiovisivi di diverso tipo, dalle pellicole alle cassette
video analogiche e digitali.
L’archivio è di dimensioni ragguardevoli e viene gestito attraverso un sistema
automatico che movimenta i contenitori di supporti archiviati con delle gru
robotizzate. Nelle tre tabelle che seguono è possibile conoscere alcuni dati
indicativi della consistenza del patrimonio storico della Rai, secondo quanto
riportato in un documento divulgativo distribuito lo scorso ottobre da Rai Teche:
Tabella 1 : CONSISTENZA PATRIMONIO TELEVISIVO Anno 2000
TRASMESSO
STORICO
TECA CENTRALE – CSS1 (1954/1997) 368.000 Ore ca.
TECA NAZIONALE SPORT (C/O
CPTV MI 1954/1997)
TRASMESSO
QUOTIDIANO
PROGRAMMI,
TELEVISIONE
SPORT DAL 1998
TECHE DI SEDE REGIONALE
137.000 Ore ca.
E oltre 52.000 Ore
oltre 97.000 Ore ca.
TOTALE
oltre 654.000 Ore
GREZZO GIRATO TG NAZIONALI
15.000 Ore ca.
TG REGIONALI
40.000 Ore ca.
pag. 12
Tabella 2: PATRIMONIO AREA RADIOFONICA NAZIONALE Anno
2000
ARCHIVIO
NASTRI
ESECUZIONI MUSICALI
30.000 Ore ca.
GIORNALE RADIO
60.000 Ore ca.
PROGRAMMI
200.000 Ore ca.
290.000 Ore ca.
TOTALE
ARCHIVI
CARTACEI
DISCHI D’ACQUISTO
900.000 Brani ca.
COPIONI
50.000 Documenti ca.
SPARTITI, PARTITURE, PARTI 120.000 Documenti ca.
D’ORCHESTRA e LIBRETTI
Tabella 3 : PATRIMONI DI BIBLIO-MEDIATECA RAI – Anno 2000
ALTRI
MATERIALI
LIBRI
60.000 unità ca.
RIVISTE
500 RACCOLTE
GIORNALI QUOTIDIANI
50 RACCOLTE
PRODOTTI EDITORIALI SU CD- Oltre 150 PRODOTTI
ROM
FOTOTECA
NAZIONALE
ARCHIVIO RAI
300.000 Foto
ARCHIVIO EX RADIOCORRIERE 900.000 Foto
pag. 13
Oltre ad una serie di iniziative di recupero dei materiali di archivio, come il
riversamento su supporti video digitali delle vecchie cassette deteriorate,
parallelamente le Teche RAI perseguono l’obiettivo del completamento di un
Catalogo Multimediale.
Il Catalogo Multimediale è un sistema che offre funzionalità di ricerca sul
palinsesto televisivo Rai, riportando documentazione testuale e anteprime di
immagini, audio e video estratti in bassa qualità dai materiali televisivi stessi, ed è
interfacciato opportunamente ad un sistema informatico che è in grado di
effettuare richieste di materiali filmati di archivio alle diverse sedi connesse alla
rete aziendale. Si tratta di un sistema accessibile on-line con un comune browser
dall’interno della rete intranet RAI per fini produttivi, purtroppo solo in piccola
parte i suoi contenuti sono resi accesibili al pubblico esterno, attraverso il sito
internet delle teche.
Ogni archivio delle Teche RAI presenta un sistema informativo interno per la
gestione delle risorse, spesso si tratta di sistemi diversi che adottano modelli di
descrizione dei materiali differenti. Con il Catalogo Multimediale e il sistema
Octopus sempre di Rai è possibile effettuare ricerche dalla intranet Rai sui
contenuti catalogati dai diversi archivi nazionali.
Il Catalogo Multimediale, progettato dal Centro Ricerche Rai, è stato uno dei
primi sistemi evoluti di catalogazione di materiale audiovisivo di un grande
broadcaster in Europa, basato su un data base relazionale a oggetti, e in buona
parte automatizzato (le operazioni di documentazione e di correzione dei tagli
delle scene sono affidate a operatori esperti e società di documentazione).
La Teca Fast, parte integrante del sistema Teche, è la videoteca digitale di Rai,
inizialmente progettata per contenere materiale digitalizzato a media qualità, è
stata poi elevata al rango di unica teca digitale per l’accesso “veloce” a risorse di
archivio. Questa comprende una architettura di codifica automatica del materiale
televisivo trasmesso in diretta dai tre canali nazionali di Rai, con una connessione
ai banchi di messa in onda e al riferimento temporale dell’Istituto Galileo Ferraris,
che insieme consentono di riconoscere automaticamente l’inizio di ogni
programma trasmesso (escludendo le pubblicità) e codificando esattamente anche
l’orario di trasmissione.
La Teca Fast offre funzionalità di accesso on-line ai contenuti, tramite
un’architettura client-server e reti ad alta capacità in fibra ottica per il trasporto
delle sequenze codificate, e ha l'obiettivo di fornire il materiale in qualità
utilizzabile per le hard news, per le produzioni tematiche e ad uso broadband, con
funzioni anche di disaster recovery, di premontaggio, e obiettivi di evoluzione
verso il montaggio virtuale dalla stessa consolle del ricercatore o montatore. Il
formato utilizzato per la codifica e l’archiviazione di materiale audiovisivo nella
Teca Fast è MPEG-2 a 10 Mbit/s.
pag. 14
Il lavoro di recupero, documentazione e catalogazione multimediale di quello che
è stato trasmesso in passato richiede ancora alcuni anni di lavoro, e quindi saranno
importanti le strategie e le tecniche adottate per i processi intrapresi, importanti
per consentire alla Rai di disporre integralmente del patrimonio audiovisivo che il
servizio pubblico italiano ha trasmesso in televisione e in radio dalle sue origini.
Questo patrimonio, la cui consistenza è indicata nelle tabelle sopra riportate, potrà
essere reso consultabile con estrema facilità attraverso la rete con un comune
browser con funzionalità multimediali, strumento sul quale dovrà essere possibile
non solo effettuare ricerche testuali efficienti, ma anche ricerche basate sul
contenuto mediale, oltre ad una estrema semplicità nell’accesso e ottenimento
delle risorse dei diversi archivi di storico e trasmesso.
Per facilitare il lavoro anche nelle fasi transitorie è stato realizzato un motore di
ricerca integrato (Octopus) in grado di connettersi in contemporanea a tutti gli
archivi testuali tradizionali aziendali. Il sistema consente anche di salvare le
ricerche in un proprio profilo utente. Soffre ovviamente di un problema basilare:
la diversità non solo dei sistemi informativi dei vari archivi, ma anche dei modelli
di descrizione, catalogazione, identificazione delle numerose risorse.
Figura 1 :
IL SISTEMA TECHE RAI
La riorganizzazione delle Teche e la creazione del Catalogo sono finalizzati a
fornire a programmisti, autori, giornalisti strumenti sempre migliori per eliminare
i lunghi tempi di visione del materiale sui videoregistratori o nelle salette dedicate
pag. 15
e, attraverso le funzionalità messe a disposizione dalla Teca Fast della Divisione
Produzione, è possibile richiedere le sequenze dei programmi di loro interesse. La
valorizzazione dei materiali di teca si traduce in vantaggi sulla produzione: per i
canali via etere l'uso dell'archivio già lo scorso anno era aumentato oltre del 10%.
Altro aspetto è la valorizzazione dei materiali di teca per le offerte della Rai sui
nuovi media: l'archivio oggi alimenta interi canali tematici satellitari. Per quanto
riguarda l'offerta satellitare in chiaro vediamo alcuni esempi: l'archivio
contribuisce per circa il 50 % a formare il palinsesto del canale satellitare RAI
Educational, con l'offerta per le mediateche scolastiche attraverso il programma
integrato con internet Mosaico e con le due intere giornate del sabato e della
domenica, in cui viene offerto il meglio della programmazione di prosa. Anche
per il canale sat Sport vengono preparate due ore settimanali di repertorio sportivo
storico.
La Rai ha la possibilità di far fruttare al meglio il suo archivio sul nuovo mercato
digitale, grazie al suo grande patrimonio di contenuti in costante crescita è
decisamente in una posizione di forza rispetto a tutti i suoi competitori, non
soltanto italiani. Questo significa anche per l’azienda un grande impegno e la
necessità di organizzare con tecniche sempre più all’avanguardia la gestione del
complesso sistema teche.
Di archivio e di documentazione all’interno dell’azienda non si è parlato per molti
anni in passato, quando l'unico concetto in vigore era quello di magazzino, da
utilizzare per le emergenze e da movimentare il meno possibile. Adesso la Rai si
trova in condizioni di poter affermare il recupero quasi completo del suo materiale
dopo alcuni anni di lavoro organizzativo e di ricerca.
2.2.1 IL CATALOGO MULTIMEDIALE
Negli anni scorsi, è stato avviato un progetto interdipartimentale con lo scopo di
digitalizzare e ricatalogare tutti i materiali posseduti e prodotti dalla RAI. Il
progetto è stato suddiviso in diversi sotto-progetti, tra i quali lo sviluppo del sopra
citato Catalogo Multimediale e di una teca televisiva digitale - la Teca Fast.
I tempi di accesso all’archivio Centrale tradizionale e la procedura complessiva,
dalla consultazione del catalogo per la documentazione fino alla consegna dei
programma, vengono ora ridotti drasticamente con l’implementazione e uso del
Catalogo Multimediale e della Teca Fast automatizzata. Il sistema è disponibile
agli utenti interni come produttori, registi, giornalisti e, in generale, a tutti coloro
che operano nel settore della produzione.
Il catalogo è nato come strumento di ricerca che consenta agli utenti di
individuare le sequenze audiovisive desiderate nell’immensa mole di materiali
archiviati, in grado di scendere alla singola inquadratura del filmato, sempre nel
tentativo di eliminare progressivamente la necessità di visionare i materiali su
supporto video per la scelta dei brani.
pag. 16
Per tale motivo, all’interno del catalogo non sono contenute solo informazioni di
tipo testuale, ma anche le fotografie correlate ai programmi televisivi e i segmenti
audio associati. La descrizione del Catalogo fa riferimento di solito alla
documentazione del materiale televisivo ma può essere applicata anche, con
piccole modifiche, alla radio e alle fotografie.
Il catalogo e le teche devono inoltre essere mantenute “allineate” in modo che
l’utente, dopo avere consultato il catalogo ed individuato i segmenti dei
programmi di interesse, possa inviare i codici di identificazione relativi alla teca
appropriata (“ordini di lavoro”) e ricevere una copia del materiale scelto
eliminando completamente la necessità di visionare i materiali.
Risulta tuttavia più facile ottenere l’allineamento tra il catalogo e le teche per
quelle parti del catalogo che vengono realizzate utilizzando i materiali di
documentazione già presenti nelle teche, nel qual caso l’identificazione del
materiale e i riferimenti temporali corretti possono essere determinati
immediatamente. Invece, nel caso di un inserimento parallelo nel catalogo e nelle
teche di materiale registrato in precedenza, o di contributi trasmessi in diretta,
l’allineamento tra il catalogo e le teche rappresenta un’operazione molto
complessa.
Il catalogo prevede la consultazione contemporanea da parte di numerosi utenti,
attraverso interfacce web accessibili dalla rete intranet della RAI mediante un
comune browser. L’accesso alle risorse di Teche (cioè alle funzionalità di
richiesta on-line di materiali di Teca Fast e Teca Master) è ristretto a un numero
limitato di persone che operano nell’ambiente della produzione, questo sia per
motivi di tutela del materiale, che allo scopo di mantenere sotto controllo il carico
della rete. I materiali selezionati possono essere consegnati all’utente richiedente
in diversi formati, a seconda del collegamento disponibile: sotto forma di file
(Teca Fast) o sotto forma di nastri video (Teca Master).
In contrasto con la Teca Master, che contiene video in formato digitale e
analogico memorizzati su supporti video convenzionali e non è gestita in modo
completamente automatico, l’archivio Teca Fast Utilizza una tecnologia
completamente digitale e automatizzata . Si è scelto un modo versatile e sicuro di
memorizzazione e di gestione dei materiali audiovisivi, in grado di garantire per
esempio l’indipendenza dai formati, difficilmente ottenibile con le
apparecchiature audio-video dedicate.
Nella Teca Fast il materiale è organizzato in file e memorizzato su due diversi
livelli di memoria, Il primo livello è rappresentato dallo memorizzazione su hard
disk accessibili on-line, mentre il secondo livello è costituito da memorie su
nastro automatiche. Un processo di caching gestisce il trasferimento tra il primo e
il secondo livello di memoria.
pag. 17
L’utilizzazione di due livelli della memoria è stata suggerita in fase di
progettazione del sistema dall’analisi costi-prestazioni. Infatti, a causa della
grande quantità di materiale video, una memoria basata solamente su hard disk
audiovideo risulterebbe estremamente costosa. In questo modo però i tempi di
accesso del materiale immagazzinato su nastri possono risultare molto più lenti e
non soddisfacenti in taluni casi, come in quello particolare di un grande numero di
accessi contemporanei alle risorse archiviate.
2.2.2 L'ORGANIZZAZIONE DEL CATALOGO
I compiti che attualmente deve svolgere il Catalogo Multimediale sono
essenzialmente due: l’interazione coi documentatori, per svolgere il ruolo
fondamentale di deposito degli oggetti multimediali e delle informazioni raccolte
e generate durante le diverse fasi del processo di documentazione, e il supporto
alle funzioni di ricerca, navigazione e visione veloce della documentazione e delle
anteprime per arrivare fino all’ordine di consegna del prodotto finale all’utente.
In conseguenza delle diverse limitazioni correlate ai due ruoli assegnati al
catalogo, è stata scelta un’architettura basata su due sottosistemi accoppiati:
•
il primo sottosistema, detto Catalogo di Documentazione, si occupa
dell’acquisizione dell’oggetto multimediale (estrazione dei cambi scena
dal flusso televisivo trasmesso dai canali nazionali) e delle fase di
documentazione e della convalida;
•
il secondo sottosistema, detto Catalogo delle Pubblicazioni, è il sistema
visibile agli utenti, che riceve i documenti di palinsesto opportunamente
descritti e convalidati, e offre le funzionalità di ricerca, navigazione e
anteprima audio e immagini, con le sopramenzionate connessioni in rete
alle teche per l’invio delle richieste di ordine o download del contenuto
selezionato (funzione detta di grabber).
2.2.3 L’ACQUISIZIONE DEI DOCUMENTI MULTIMEDIALI
L’acquisizione dei materiali multimediali di descrizione dei programmi, come le
immagini di cambio-scena delle sequenze video o l’anteprima in formato audio
compresso a bassa qualità, è un’operazione affidata ad apposite workstation
biprocessore che, ricevendo come input un segnale video composito e un
riferimento temporale, svolgono in tempo reale la digitalizzazione e compressione
dell’audio, rivelazione delle modifiche delle inquadrature, estrazione di un
fotogramma principale per ciascuna inquadratura, associazione del tempo di inizio
e della durata dell’inquadratura a ogni fotogramma principale.
Quando la stazione di acquisizione è alimentata con il segnale in diretta relativo a
un canale di trasmissione tv, e non è disponibile in tale fase alcuna informazione
sul programma, l’identificazione dei fotogrammi principali e dell’audio avviene
sulla base dei loro tempi di acquisizione ed è, quindi, spesso necesaria
pag. 18
un’elaborazione e una lavorazione ulteriore da parte di personale specializzato per
le operazioni di suddivisione del flusso di immagini estratte dallo stream in
opportuni item di programma.
Il flusso di documenti di descrizione o item di programma viene poi inviato ad
una serie di server connessi in rete ad alta velocità con le società di
documentazione. Queste ultime si occupano della documentazione (inserimento
delle informazioni sul titolo del programma riconosciuto, autori, partecipanti,
contributori, e una serie di altre informazioni come riassunti testuali dei
contenuti). Qui si trova un fattore critico del sistema, che richiederebbe
l’implementazione di un modello di descrizione unico e standard, e di tesauri e
dizionari per limitare la dispersione terminologica delle descrizioni.
In effetti l’assenza di uno standard per la descrizione dei metadati audiovisivi
rende ancora eterogenee e poco consistenti le operazioni di documentazione, che
presentano gradi di approfondimento molto variabili a seconda del tipo di
programma, delle informazioni in possesso di ogni operatore o società che
realizza l’immissione dei dati e che rimanda indietro i documenti completati
destinati ai server del Catalogo di Documentazione.
Chi si occupa dello sviluppo del catalogo riconosce la necessità di studiare
soluzioni per l’implementazione di strutture dati di descrizione conformi ad un
modello standard, consistente e portabile che faccia da base ottimale per
l’implementazione delle informazioni di descrizione, garantendone un valore
anche maggiore in vista di possibili riutilizzi del materiale di catalogo per servizi
di ricerca e produzione accessibili anche dall’esterno della rete aziendale, e inoltre
che consenta l’interoperabilità con diversi sistemi di ricerca.
In casi come questo si comprende immediatamente l’importanza dell’uso di
strutture dati e linguaggi di descrizione puntualmente definiti, potenti nella
ricchezza espressiva, ma anche stabili sufficientemente da garantire la completa
comprensibilità e accessibilità anche a sistemi di ricerca esterni, pilotati da sistemi
automatici o da esseri umani che effettuano ricerche.
Mpeg-7 offre una buona parte delle soluzioni. In più standardizza e diffonde una
serie di strumenti su cui basare applicazioni per la descrizione molto accurata
degli oggetti multimediali.
Secondo il punto di vista proposto da Mpeg-7, tutte le sequenze audiovisive
possono essere scomposte e descritte ai minimi termini e in diverse modalità.
Dal punto di vista delle caratteristiche di basso livello, come i segnali, le texture, i
colori, le forme degli oggetti riconoscibili, il moto e le relazioni di questi oggetti,
fino alle caratteristiche di più alto livello, come la descrizione di strutture
semantiche, la descrizione strutturata dei concetti, delle azioni descritte in un
pag. 19
contenuto multimediale, e molto altro, oltre naturalmente ad una lunga serie di
strumenti per la descrizione basata sui metadati tradizionali testuali.
Tali metadati sono appunto l'oggetto dello studio e della realizzazione del
progetto descritto in questa tesi, e delineati nella parte riguardante i Multimedia
Description Schemes (MDS) dell’Mpeg-7. Un’altra necessità è quella di stabilire
(creandolo ex-novo od utilizzandone uno preesistente) l’uso di uno o più tesauri
per l’utilizzo di terminologia e dizionari ad hoc per l’applicazione.
Tornando al catalogo multimediale, come accennato il flusso continuo di oggetti
multimediali acquisiti dal sistema di estrazione cambi-scena e anteprime è
preventivamente elaborato prima del passaggio ai documentatori e al Catalogo di
Documentazione, con lo scopo di creare le item di programma da inserire nel
database. Attualmente, questa operazione è eseguita manualmente, supportata
dalle informazioni riguardo ai tempi di inizio e di fine della trasmissione di ogni
programma, caricati in modo automatico da un database amministrativo.
La precisione disponibile nelle informazioni temporali, sufficiente per le
operazioni amministrative, non è adeguata a una segmentazione completamente
automatica dei programmi; per tale motivo, è necessaria la presenza di un
operatore allo scopo di selezionare in modo preciso i punti di taglio.
Questo passo è semplificato nella catena di digitalizzazione per materiali di
repertorio in quanto esiste molto spesso una corrispondenza biunivoca tra i nastri
e i programmi, anche se non sempre è cosi’ (spesso si incontrano casi di singoli
supporti video di archivio che contengono più programmi differenti).
2.3 L'ARCHITETTURA DELLA TECA FAST RAI
La Teca Fast Rai opera la digitalizzazione dei materiali audiovisi di Archivio e di
materiali trasmessi dalle tre reti televisive nazionali RAI, costantemente. Gli
utenti del sistema, in una prima fase solo operatori che accedono agli studi di
montaggio attrezzati in azienda, possono usufruire di funzionalità di accesso in
rete ad alta velocità alle risorse digitalizzate, con un servizio chiamato di VTR
(Video Tape Recorder) virtuale.
Tra i servizi che la Teca Fast fornisce vi è l’interfacciamento con i sistemi di
descrizione del palinsesto dell’emittente (l’interfaccia di “Palinsesto” accessibile
sul sito intranet di ricerca), e con i banchi di messa in onda per il recupero del
segnale audiovideo e delle informazioni di identificazione del programma. Il
sistema impiega inoltre dei video server per consentire l’accesso simultaneo di più
utenti ad una stessa risorsa di archivio.
Il formato utilizzato per la codifica digitale e l’archiviazione dei filmati è
l’algoritmo di compressione MPEG2 ML@MP 4:2:2 a 10 Mbit/s, che consente di
mantenere una qualità audiovisiva più che sufficiente per la produzione broadcast,
pag. 20
insieme ad una considerevole riduzione dei costi di archiviazione (minor spazio
occupato anche fisicamente dai supporti di memorizzazione e dagli archivi
robotizzati che li gestiscono).
Per garantire un allineamento con il materiale presente nell’archivio Teca Master
analogico viene utilizzato il riferimento al time code assoluto riferito all’orologio
nucleare dell’Istituto Galileo Ferraris di Torino, sia per quanto concerne i filmati
di archivio sia per quelli generati dal sistema automatico che si occupa di
digitalizzare i segnali di messa in onda in diretta sui canali nazionali.
Con i servizi implementati nell’architettura dell’archivio Teca Fast l’utente
connesso al sistema può visionare o riversare le sequenze audiovisive, con
comandi tipici di un videoregistratore, con le tipiche funzionalità di
visualizzazione del time code sincrono con il filmato, oltre alla visualizzazione
delle sequenze video a schermo pieno, con audio di qualità elevata.
Non è il sistema di Teca Fast a fornire direttamente funzionalità di editing in
remoto, che spetta alla attrezzature di edizione nelle workstation di studio, nella
fase successiva al riversamento delle risorse di teca. Il modello del sistema
utilizzato è client-server e destinato alla fornitura del servizio alla rete interna
aziendale di Rai, con possibili estensioni web.
La distribuzione del video digitale compresso in alta qualità è infatti limitata al
livello di area locale. Le tre sedi Rai di Roma sono connesse in fiber channel via
TCP/IP e dispongono di propri apparati di codifica e decodifica in locale. Il
sistema di acquisizione è composto da un video server collegato alla libreria (dei
dati su cassette digitali) robotizzata, a un sistema di archiviazione gerarchico in
architettura SAN (Storage Area Network) e dalle apparecchiature specializzate
nella codifica dei canali audiovisivi nel formato prescelto MPEG2.
La libreria dati a nastri digitali è gestita automaticamante da un server Sun,
attraverso dei silos robotizzati, ognuno in grado di gestire circa 6.000 supporti a
nastro digitale, con una dotazione di dieci drive di accesso ad alto bit rate (circa
10 MB/s).
Le connessioni ad alta velocità per il trasporto del video codificato avviene
tramite una dozzina di schede per il collegamento a una rete di codific e
visualizzazione in modalità fiber channel switched.
La codifica dei flussi audiovideo di sorgente viene eseguita da una o più
apparecchiature Tektronix Profile, nel formato MPEG-2 4:2:2 previsto. Il compito
del video server si limita al solo trasferimento dei dati da e verso i Tektronix
Profile ai quali è demandata la funzione di encoding e decoding.
pag. 21
2.3.1 OPERAZIONI DI INSERIMENTO DEI CONTENUTI
Nel caso dell’operazione di inserimento di contenuti audiovisivi nell’archivio
Teca Fast, lo schema di processo è quello esemplificato nella figura seguente,
dove il modulo Tektronix Profile del video server viene alimentato dalla sorgente
audio/video preesistente, effettua la codifica dei dati raccolti in formato MPEG
4:2:2 in opportuni file che vengono trasferiti attraverso la propria scheda fiber al
modulo Silicon Graphics Origin 2000 del sistema di gestione DHSM (Dynamic
Hierarchical Storage Management).
Figura 2 : SISTEMA TECA FAST: SCHEMA CONCETTUALE DELLE
OPERAZIONI DI INSERIMENTO
Qui i files vengono trasmessi attraverso un’altra scheda fiber channel Genroco al
sistema RAID, dal quale passa ai dispositivi di scrittura-lettura su nastro digitale
per l’archiviazione.
Quindi per la comunicazione viene impiegata la rete fiber channel, mentre nella
fase finale di trasferimento dei file dal sistema RAID ai lettori a nastro viene
impiegato un canale SCSI differenziale.
pag. 22
2.3.2 OPERAZIONI DI RICHIESTA DEI CONTENUTI
Nel caso della richiesta di play-out di risorse dell’archivio, il modulo Tektronix
Profile del video server si va ad alimentare con i file conservati sul sistema RAID
e prelevati dalla libreria a nastri robotizzata.
Confrontando i dati di controllo presenti nelle tabelle del DBMS, il file richiesto
viene trasmesso al Tektronix Profile , all’ingresso il file viene preso da un’altra
scheda fiber channel e inviato tramite un cavo audio/video in uscita agli apparati
di saletta e da qui eventualmente ad un’uscita su monitor PAL di sala. La
comunicazione avviene su rete fiber channel, e come nel processo inverso di
inserimento di contenuti in archivio, il trasferimento dei file dalla libreria a nastri
robotizzata al sistema RAID avviene invece su canale SCSI differenziale. Il flusso
di play-out è schematizzato nella figura seguente.
Figura 3 : SISTEMA TECA FAST : SCHEMA CONCETTUALE OPERAZIONI DI
RICHIESTA DEI CONTENUTI DALL’ARCHIVIO
I supporti di memorizzazione utilizzati sono di tipo gerarchico-dinamico
(DHSM): una libreria di nastri, un sistema di dischi, un sistema di database.
L’archivio di tutti i file video è memorizzato nella libreria di nastri. I dischi sono
invece utilizzati come supporto di memorizzazione dei file video più richiesti
(Video Cache), per evitare di doverli ricaricare tutte le volte dal nastro con
conseguente saturazione della banda di uscita della libreria di nastri,
compensando in tal modo il ritardo dovuto ai lunghi tempi di accesso dei nastri.
pag. 23
Il sistema di dischi RAID alloca per la componente di codifica e paly-out dischi in
grado di contenere fino a 72 GB, corrispondenti a circa 12 ore effettive di
registrazione video. A livello del software, il sistema centrale è ripartito su quattro
ambienti distinti in comunicazione tra loro attraverso un software demone definito
come “Agente” che ha il controllo delle comunicazioni con i Tektronix Profile.
L’Agente intercetta e reinstrada tutte le richieste che pervengono alla Teca Fast.
Le richieste provenienti dagli utenti attraverso l’interfaccia al DBMS e il Query
Manager vengono reinstradate verso un Device Manager per il prelievo dei dati
dalla libreria dati robotizzata ovvero al Profile Manager per il trasferimento dei
dati richiesti.
Viceversa le richieste provenienti dal Profile Manager, tipicamente di ingestion
vengono reinstradate al DHSM per il trasferimento su disco e da qui al Device
Manager per l’archiviazione su nastro. Il Device Manager, a sua volta, è
composto dal Tape Manager che contiene il vero e proprio driver che pilota il
lettore, TMFBASE.
La gestione del sistema RAID e del traffico I/O su relativi moduli, dischi e
partizioni è affidata al DHSM (Dynamic Hierarchical Storage Manager) al cui
interno è contenuta l’applicazione che genera il processo Main da cui si origina il
software demone Agente.
Sia l’inserimento di audiovisivo che il play-out video per l’utente vengono gestiti
da un software realizzato appositamente. Il riversamento del materiale avviene in
maniera automatica con codifica in tempo reale.
2.3.3 IL DATABASE DELLA TECA FAST
Il database che si interfaccia col sistema di acquisizione e codifica della Teca Fast
è un database SQL relazionale puro e contiene informazioni sui contenuti della
Teca Fast e sullo stato delle attività (vale a dire come memoria temporanea del
sistema).
Quest’ultima funzione permette di evitare il ricorso a protocolli di comunicazione
per la sincronizzazione e la gestione di tutti i computer riservando banda. I vari
elementi del sistema agiscono quindi come macchine “disaccoppiate” con
funzionalità che possono svolgersi in modo indipendente dagli eventi che si
verificano al di fuori del proprio campo di azione. La gestione di questo DBMS è
affidata anch’essa al DHSM.
Sui client della Teca Veloce è installato un software realizzato appositamente che
consente di visionare e riversare sequenze video e di ascoltare l’audio associato,
impiegando le principali funzioni disponibili per un VTR (play, stop/still, fast
forward/rewind, ecc.) comparabili a quelli ottenibili dall’impiego di strumenti
tradizionali (visualizzazione time code, video a schermo pieno, a 25 frame/sec.
garantiti, audio stereo di qualità elevata - MPEG Layer II - , etc.).
pag. 24
Il software installato sulle postazioni client prevede anche un’applicazione per la
manipolazione del clip su Tektronix Profile con la possibilità di impiegare un
modulo di controllo per postazioni dotate di centralina video e uno per postazioni
prive di centralina video.
L’interrogazione dell’archivio e la richiesta di informazioni sullo stato delle
richieste avviene attraverso un’interfaccia grafica, e il software client si
interfaccia con il DBMS relazionale, un Microsoft SQL Server 7.
Per effettuare richieste di contenuti audiovisivi archiviati, il client deve inviare al
DBMS solamente poche informazioni riguardanti, per quanto riguarda i contenuti
codificati dai tre canali televisivi nazionali di Rai, la data di trasmissione sulla
rete, l’identificatore della rete di emittenza, l’orario di inizio trasmissione della
sequanza di interesse (un istante qualsiasi della giornata di trasmissione, con la
precisione del secondo) e l’orario di fine della sequenza da estrarre. Sono queste
le informazioni che forniscono all’atto della richiesta di materiale in Teca Fast
anche i sistemi di ricerca accessibili con Octopus e Catalogo Multimediale.
Il prototipo di Repository di Metadati Mpeg-7 richiesto nell’ambito di questo
lavoro di tesi, deve essere anch’esso in grado di effettuare richieste a Teca Fast
fornendo la quadrupletta di dati sopra indicata al sistema DBMS SQL Server.
2.4 I METADATI
I metadati favoriscono la ricerca e il reperimento delle risorse, informative o
materiali nel senso più stretto, ecco perché stanno assumendo un'importanza
critica, quasi paragonabile a quella del contenuto che descrivono o che
permettono di gestire. Ogni tipo di contenuto o collezione ( che sia un libro o una
biblioteca, un archivio di applicazioni software di pubblico dominio, i miliardi di
pagine web memorizzate nei web server dislocati su tutta la rete Internet, gli stock
alimentari di un grande magazzino) ha la necessità di essere catalogata per poterla
ricercare.
In particolare i metadati favoriscono lo scambio di dati e risorse, necessarie sia
per il commercio tradizionale e che per quello elettronico. Proprio il commercio
elettronico dipende maggiormente rispetto al commercio tradizionale dal modo
con cui le cose vengono identificate e dai termini in cui queste vengono descritte
(i cosidetti metadati o dati sui dati).
I metadati devono fornire una grande affidabilità, fino ad oggi pressoché assente,
per l'identificazione e descrizione di risorse e diritti d'uso, visto che con la crescita
dello scambio di informazioni nell'e-commerce si verifica un crescente interesse
per la promozione e standardizzazione di diversi modelli di descrizione basati sui
metadati.
pag. 25
Molto spesso la risorsa in gioco (un film, un'opera multimediale, un software)
presenta una certa complessità, e con essa diventa sempre più difficile identificare
i diritti d'autore (ad esempio se in un film vi sono degli spezzoni presi da un
archivio audiovisivo, o se in un programma tv vengono utilizzate sequenze video
di diverse fonti e proprietari).
Per esempio una singola opera audiovisiva digitale può essere divisa in centinaia
o addirittura migliaia di componenti separati.Ognuna di queste è identificata da
una diversa proprietà intellettuale, che potrebbe avere dei diritti d’uso e contenere
informazioni riguardanti l'autore, i contributori, l'organizzazione che si occupa
della distribuzione, i collegamenti ad uno o più archivi. Possono esservi foto,
audio registrato, filmati, grafica sintetica, testo e applicazioni software, alcune
magari presenti solo in parte o in forma modificata.
La modularità delle informazioni contenute negli schemi di descrizione è una
delle caratteristiche che sono dunque importanti per un insieme di metadati utili a
descrivere risorse di archivio. Si individuano delle entità di base per la descrizione
di un oggetto che contengono informazioni specifiche su di esso (ad esempio le
informazioni di creazione e produzione, quelle di pubblicazione). Ognuna di
queste necessita della propria sintassi e di un insieme di identificatori per ciascuna
proprietà.
I metadati nell'ambiente digitale possono quindi essere visti come un insieme di
moduli informativi, magari anche prodotti in posti diversi e per scopi diversi, che
devono anche essere facilmente riutilizzabili e connessi in qualche modo con il
contenuto cui si riferiscono.
2.4.1 INTEROPERABILITÀ DEI METADATI
L'interoperabilità è ritenuta un'altra caratteristica fondamentale per dei set di
metadati, e consente di utilizzare le informazioni di descrizione create in diversi
contesti e di scambiarle nei modi il più possibile automatizzati.
I metadati (dati di tutti i tipi relativi alle creazioni, ai ruoli che le creano e
utilizzano, e alle transazioni che supportano tali utilizzi).devono poter
interoperare liberamente anche in questi casi per facilitare lo scambio di
informazioni e la loro salvaguardia.
Per esempio chi inserisce i metadati riguardanti la proprietà intellettuale (il
responsabile della documentazione di un filmato di archivio per esempio)
potrebbe volere la certezza che l'accuratezza e la veridicità delle informazioni
allegate (spesso con costi ingenti) sopravvivano intatte attraverso varie
negoziazioni.
Un altro problema riscontrato è quello dell'identità semantica che non si risole con
strumenti nati nell'ambito del web, come il metalinguaggio XML (eXtensible
Markup Language) e RDF (Resource Description Framework) e i loro derivati,
pag. 26
ma solo con lo sviluppo di identificatori unici e l'impiego massiccio e
standardizzato di metadati, si potranno superare le barriere al commercio dei
contenuti.
Sistemi per l'identificazione univoca delle risorse sono in via di sviluppo da parte
di alcuni degli organismi come il gruppo Mpeg.
2.4.2 I METADATI AUDIOVISIVI
Rispetto al settore bibliografico, lo sviluppo di dizionari di metadati e schemi di
metadati per i supporti audiovisivi è un'ambito applicativo relativamente giovane,
nel quale non si è raggiunto uno standard formale.
Sono già stati sviluppati degli schemi standard specializzati e in certi casi questi
sono già operativi, ma sono modelli non comunemente accettati nella totalità del
settore audiovisivo.
E' necessario individuare due aspetti correlati per poter definire uno schema di
metadati per un sistema di gestione di media nell'ambito della produzione. In
primo luogo il sistema deve soddisfare i requisiti specifici dell'organizzazione
operante nel campo audiovisivo per cui il sistema stesso dovrà operare; in
secondo luogo gli stessi protocolli e gli stessi standard andrebbero modellati
tenendosi il più vicino possibile agli schemi internazionali e agli standard per
poter aumentare il grado di interoperabilità e facilitare lo scambio di documenti
audiovisivi scala nazionale ed internazionale.
Alcune aziende hanno provato ad imporre il loro standard, ma senza successo.
Vedremo adesso alcuni esempi di metadati sviluppati da diverse compagnie che
operano nel settore audiovisivo.
Per la produzione e la distribuzione di prodotti digitali televisivi e radio il
dizionario dei metadati SMPTE e le funzioni guida fornite per l'ingegnerizzazione
di sistemi sono un possibile punto di riferimento.
Per la categoria di metadati descrittivi un importante punto di riferimento sono
anche le funzioni di Dublin Core, di cui se ne parlerà in seguito.
Lo Standard Media Exchange Framework (SMEF) della BBC viene a volte
utilizzato con modello di dati di riferimento per gli ambienti della produzione
broadcast e per i sistemi di gestione dei media.
Forse con le attività del gruppo MPEG-7, oramai standard internazionale, e che
sono state oggetto di approfondito studio per la parte riguardante i metadati
nell’ambito di questo lavoro, si è giunti allo sviluppo di schemi per il contenuto
audiovisivo in ambiente professionale. L’uso di strutture dati Mpeg-7 per
metadati audiovisivi è ampiamente illustrato nel capitolo 4.
pag. 27
Attualmente non vi è uno scambio di informazioni centralizzato, sistematico e
efficiente tra i vari progetti e comunità locali, internazionali e nazionali che
riguardano e contribuiscono allo sviluppo di schemi per i metadati audiovisivi.
I comitati di standardizzazione lavorano lentamente e i broadcaster e i produttori
dall'altro lato - a causa del rapido avanzare delle tecnologie - hanno necessità di
mettere qualcosa in atto e non possono attendere ogni nuova versione degli
standard.
Nasce così la difficoltà di tenere di pari passo il lavoro che viene svolto dai vari
organismi di standardizzazione, i progetti pilota e le altre iniziative sul piano del
tempo, dei risultati e degli scopi.
Un altro problema è la comunicazione tra le varie comunità che contribuiscono
alla creazione degli schemi, spesso inadeguata, sia all'interno, a livello di una
stessa azienda, che a livello internazionale. Problemi di comunicazione possono
essere causati dalle diverse professionalità in gioco (degli ambiti tecnico,
archivista, di produzione), i diversi background dei contributori che necessitano di
integrare i requisiti per arrivare ad uno schema interoperabile.
Altre problematiche più specifiche sono facilmente riconoscibili:
•
Soddisfare le richieste dell'utenza attraverso i vari settori della produzione
audiovisiva.
•
Standardizzare i processi di produzione, distribuzione e archiviazione di
audiovisivi e le procedure di lavorazione.
•
Standardizzare le strutture dati e i modelli dei dati, le entità e gli attributi.
•
Standardizzare i campi di tipo e i valori ammessi.
•
Sviluppare identificatori unici globalmente riconosciuti, per il contenuto
audiovisivo da collegare al materiale immagazzinato con la relativa
documentazione nel processo di produzione audiovisiva.
•
Rendere gli schemi interoperabili compatibili con piu’ lingue.
•
Comprendere ed integrare le varie categorie e tipi di metadati nell'ambito
dell'audiovisivo, inclusi i metadati riguardanti il processo di registrazione, i
metadati tecnici, i metadati relativi alla produzione e le categorie descrittive.
•
Integrare gli archivi e i cataloghi preesistenti nel settore digitale.
pag. 28
2.4.3 NUOVE ESIGENZE PER I METADATI AUDIOVISIVI
Ogni ambiente di produzione audiovisiva spesso possiede delle procedure e
requisiti particolari e questi devono essere inclusi negli schemi e nei modelli di
dati dell'azienda. Oltre a questo, le realtà possono differire nelle modalità con cui
avviene lo scambio di informazioni dal punto di vista dei diritti di copyright e
dello sfruttamento commerciale.
In altri casi gli schemi ad uso interno contengono informazioni dettagliate sulle
procedure aziendali interne e i processi di lavorazione e possono quindi risultare
non condivisibili liberamente in altri ambienti.
E' per ragioni come questa che iniziative come EBU P/Meta (di European
Broadcaster Union), che lavorano per trovare una connessione ai requisiti, schemi
e modelli di vari broadcaster con gli standard internazionali, sono di importanza
fondamentale.
Per poter promuovere l'interoperabilità da subito, sarebbe davvero utile stabilire
piattaforme professionali in cui i broadcaster e gli altri produttori di audiovisivi
possano acquisire informazioni dettagliate ed obiettive su quale lavoro è già stato
svolto e quali schemi sono disponibili come modello di riferimento. Attualmente
gran parte dei progetti pilota che si stanno portando avanti all'interno delle
emittenti includono lo sviluppo e l’uso di schemi di metadati.
Spinti dalla rapida crescita della produzione digitale di materiali audiovisivi e
dalla mancanza di schemi e standard comuni utilizzabili, gran parte delle
compagnie televisive stanno sviluppando i propri schemi di metadati.
Durante questo processo spesso queste partono dalla formulazione di specifiche
locali e definiscono i processi e flussi di dati del proprio caso particolare.
Successivamente devono cercare delle estensioni per poter armonizzare e
mappare i propri modelli proprietari con gli standard esistenti o in via di rilascio.
Nuovi broadcaster commerciali che non posseggono archivi o cataloghi pregressi,
attualmente tendono a posizionarsi in prima linea nello sviluppo dei sistemi,
lavorando spesso in ambienti completamente digitali, e utilizzando modelli
proprietari e dizionari di metadati.
Tra broadcaster, produttori di audiovisivi, e altri soggetti nel campo degli
audiovisivi cresce rapidamente la consapevolezza che l'interoperabilità tra
strumenti di descrizione aziendali di questo e di altri settori sia un requisito
importante.
Si è registrato più volte il fallimento nell'adozione degli standard internazionali
nella prima fase di sviluppo dei sistemi, ad indicare l'effettiva inadeguatezza e
inefficienza dei sistemi proprietari sviluppati localmente.
pag. 29
Adattare successivamente i sistemi sviluppati in ambito proprietario risulta un
impegno intensivo e costoso e la graduale implementazione degli standard in casi
come questo tende spesso a seguire più la tecnologia che le necessità dell'utente
dei sistemi.
L’obiettivo del nuovo standard MPEG-7 ("Multimedia Content Description
Interface") è proprio quello di specificare un set standard di descrittori e schemi di
descrizione (e un linguaggio per crearne di nuovi o estenderli) per descrivere il
contenuto delle informazioni audiovisive, e multimediali in genere.
Dalla letteratura sullo standard e sulle base richieste maturate nell’ambito delle
applicazioni illustrate, si sono riconosciute alcune delle specifiche necessarie per
uno schema di metadata per il video:
1- La Definizione di strutture gerarchiche: lo schema deve ad esempio
consentire la definizione di una struttura in cui il documento “descrizione
dell’audiovisivo”, o “descrizione di una collezione audiovisiva” siano
posizionati ad un livello alto. Questi a loro volta possono contenere
sequenze, ognuna delle quali può essere costituita da scene, che
contengono shots (riprese), a loro volta costituite da frames, costituiti da
oggetti o attori. In MPEG-7 si può scendere ad una descrizione di livello
davvero basso, con degli strumenti di descrizione per segmenti spazio
temporali individuati all’interno delle sequenze o delle singole immagini,
e delle caratteristiche dei segnali audio e video.
2- Ogni livello (o classe) nella gerarchia deve poter possedere solo degli
attributi specifici.
3- Deve essere possibile specificare sottoclassi con l’ereditarietà degli
attributi e degli elementi dalle classi superiori nelle inferiori. Inoltre le
sottoclassi devono essere in grado di avere i loro attributi ed elementi
addizionali. Questo consente un efficiente riutilizzo e customizzazione
degli schemi di documento.
4- Deve essere possibile limitare i valori degli attributi a certi tipi di dati. I
tipi di dati supportati devono includere tipi di dati primitivi come gli
schemi, i tipi di dato enumerato, i vocabolari controllati, i tipi di files, i
localizzatori di risorsa come le URI e i tipi di dato complessi (istogrammi
del colore, vettori 3D, grafi, valori RGB, etc..) così come tipi di dato e
schemi alternativi per particolari attributi.
5- Deve essere rappresentabile la cardinalità degli attributi, ad esempio se un
attributo può avere zero, uno o più valori.
6- Lo schema deve essere in grado di supportare la specifica di caratteristiche
Spazio-Temporali come l’inizio e la fine di segmenti video e la loro
durata. In maniera simile deve essere in grado di supportare
pag. 30
rappresentazioni spaziali, come delle regioni di un’immagine o il moto
lungo una traiettoria.
7- La possibilità di rappresentare relazioni di tipo spaziale, temporale e
concettuale. Relazioni spaziali come la vicinanza di due oggetti e
temporali come segmenti in sequenza o parallelo.
8- Una delle specifiche che si richiedono è che le descrizioni e lo schema
stesso siano comprensibili alla lettura da parte di un essere umano.
9- Non da ultimo la disponibilità di tecnologie di supporto come parsers (in
grado di validare le descrizioni inserite), databases e linguaggi di query.
Questi requisiti sono stati utilizzati nella definizione dei requisiti dello standard
MPEG-7, e nello specifico della seconda parte, la MPEG-7 DDL Description
Definition Language che definisce il linguaggio per la definizione ed estensione
degli schemi di descrizione e descrittori, basato essenzialmente sull’ XML
Schema versione 1.0 di W3C da cui si discosta esclusivamente per la definizione
di alcuni tipi di dato aggiuntivi per la rappresentazione del tempo e della durata.
pag. 31
CAPITOLO 3
IL METALINGUAGGIO XML
3.1 LE ORIGINI DEL LINGUAGGIO XML
Affrontiamo ora le tecnologie alla base della diffusione del web e dei contenuti
multimediali in rete, partendo dal nuovo standard per lo scambio di informazioni
sul quale si basa anche la specifica di Mpeg-7.
Si entra nel vasto dominio di applicazione XML, l’eXtensible Markup language
che ha preso origine dall’SGML (Standard Generalized Markup Language).
Parlando di XML si deve affrontare anche la sua Document Type Definition
(DTD) che è quasi identica alle SGML DTD. Lo standard SGML, pubblicato nel
1986, definisce un metalinguaggio per un formato di documenti portabile e
indipendente dalla piattaforma con l’enfasi posta sui documenti.
L’XML, rilasciato nel febbraio del 1998, è stato progettato per ovviare alle
carenze di HTML, viene utilizzato molto spesso come lingua franca nell’ambiente
Internet, come un formato comune per scambiare e immagazzinare non solo
documenti ma ogni tipo di contenuto.
Nel mercato del commercio elettronico in particolare, XML non ha a che fare –
come SGML – principalmente con documenti destinati alla lettura da parte di
esseri umani: i documenti XML devono essere leggibili e comprensibili da parte
dei sistemi informatici oltre che dall’uomo.
Nella gestione elettronica della catena del valore i documenti XML che sono
trasmessi da diversi partners commerciali sono generati da un sistema informatico
e interpretati da un altro sistema informatico diverso dal primo.
Nei mercati digitali aperti, si prevede che i cataloghi e la lista dei prezzi debbano
essere presentati in una forma tale che li renda accessibili alla ricerca da parte
degli agenti software. Quello che XML deve gestire in questi ambiti è una
combinazione di un punto di vista del “documento” insieme ad un punto di vista
dei “dati”, che è proprio dei database tradizionali.
I documenti XML hanno una sintassi semplice. Seguendo poche semplici regole
sull’uso dei tag è possibile costruire documenti ben-formati, e viene richiesto ad
un processore XML di processare un documento ben-formato (segnalando e
rifiutando ogni documento che non lo sia).
Grazie alla sua estensibilità, l’XML consente l’aggiunta di etichette – i tag – al
documento che descrive il contenuto degli elementi del documento stesso. Questo
consente ad esempio ai motori di ricerca di effettuare ricerche su specifici
pag. 32
elementi, come per esempio il titolo di un libro, la descrizione del libro,l’autore
del libro etc.
Al contrario, i tag in HTML descrivono le modalità di presentazione di un
elemento: se è grassetto o corsivo, se deve avere il carattere di testa,etc. In XML
un elemento che contiene le informazioni sul autore può ad esempio essere
etichettato con i tag <Autore></Autore>.
Questa viene chiamata etichettatura semantica poiché i tag e i nomi degli attributi
descrivono il significato di ogni elemento e attributo, che sono comprensibili
anche ad un lettore umano.
Per un generico processore XML il nome di un tag non ha alcun significato. Un
tag è solo un tag, ed un elemento di testo è solo un elemento di testo. Questo
perché un generico processore XML non ha conoscenza della semantica del
documento. Paradossalmente, i processori HTML come ad esempio i browser
web, conoscono la semantica dei tag HTML molto bene: essi devono ad esempio
sapere che il testo racchiuso tra i tag <b> </b> deve essere visualizzato in
grassetto.
Attualmente l’HTML (Hyper Text Markup Language) ha la diffusione maggiore
rispetto a qualunque altro formato di codifica documenti per il grande numero di
documenti prodotti.
Il World Wide Web Consortium (W3C) ha infatti rilasciato come
raccomandazione successiva le specifiche di XHTML 1.0 (eXtensible HyperText
Markup Language), che si potrebbe definire come un ponte tra il mondo HTML e
quello di XML: XHTML non è altro se non un’applicazione di XML, definita
attraverso una XML DTD (Document Type Definition) e un XML namespace.
XHTML 1.0 ripropone le funzionalità di HTML in un modello XML.
Allo stesso tempo XHTML costituisce l’inizio di un processo di convergenza per i
documenti sul web. Si prevede infatti di combinare XHTML e WML (Wireless
Markup Language) in un unico standard consistente. WML è il formato dei
documenti utilizzati nel protocollo WAP per gli apparati cellulari, e anche
quest’ultimo, come XHTML, si basa su XML.
Questo significa che tutte le tecnologie ed applicazioni XML attualmente in
sviluppo, come Browsers, Parsers, software di editing, API (Application Program
Interface), server Database, si rivelano utili a supportare anche XHTML e WAP.
La tecnologia XML sarà dunque una tecnologia chiave della prossima
generazione delle applicazioni web, su reti mobili e fisse.
Diversamente da quanto previsto da HTML, per XML la presentazione del
contenuto non è l’unica applicazione (come pure nel caso della raccomandazione
XHTML). Inoltre ci sono diversi standard relativi all’XML che si stanno
imponendo, e l’XML è la tecnologia che ben si sposa con la ricerca di soluzioni
pag. 33
efficaci per l’interoperabilità di sistemi per l’immagazzinamento e la gestione dei
dati.
Sono presenti standard come XSL per la visualizzazione dei contenuti, XPATH
per la navigazione delle strutture dati, XPOINTER per la creazione di link evoluti,
o XML Schema per la definizione di tipi di documenti, e rappresentano solo
alcuni degli strumenti creati sulla base di XML e che ne fanno un metalinguaggio
potente.
3.2 LE TECNOLOGIE XML
In questa parte verranno introdotti i concetti principali riguardanti le tecnologie
XML e la loro applicazione alle Basi di Dati.
Le tradizionali pagine HTML sono solitamente memorizzate come in file “piani”,
cosa che non è certo adeguata alle potenzialità di XML. L’accesso a parti di
documento (tramite gli elementi), le ricerche su caratteristiche qualificate, la
composizione dinamica da documenti originali interconnessi, tutte queste
operazioni richiedono la potenza elaborativa di un DBMS (Data Base
Management System). Per aiutare nella gestione di documenti XML vengono
introdotte delle tecnologie, ognuna delle quali permette di approfondire un aspetto
sull’elaborazione dei documenti XML.
3.2.1 DOCUMENT TYPE DEFINITION
Un metodo molto comune per dichiarare la semantica degli oggetti di dati ad una
generica applicazione informatica è quello di definire dei vincoli sui dati. (In
SQL, per esempio, i vincoli sono definiti attraverso le regole di integrità e le
limitazioni. Questo consente ad un processore SQL di rifiutare le operazioni di
aggiornamento non valide. In un certo senso il processore SQL comprende la
semantica dei dati.)
In XML la possibilità di inserire dei vincoli nei documenti è minima. Un
documento XML senza un Document Type Definition (DTD) non ha alcun
vincolo. In questo caso il processore XML verifica solamente la correttezza
sintattica: il documento si dice quindi “ben-formato”. Se viene fornito un DTD
con il documento, allora il processore XML può verificare se il documento
aderisce alla struttura definita nella DTD. Se la verifica è positiva il documento si
dice “Valido”.
Le DTD consentono la definizione di alcuni vincoli strutturali. Per esempio esse
possono stabilire che un certo elemento o attributo devono esistere nel
documento. Si può dare un vincolo ad esempio per un elemento di Autore,
stabilendo che esso possa contenere solo dati di tipo carattere.
pag. 34
Si può inoltre stabilire che abbia un attributo “nato_il” :
<Autore nato_il=’1704-05-19’> Dante Alighieri </prezzo>
Per la maggior parte delle applicazioni tuttavia questi vincoli non sono sufficienti.
Le DTD infatti riconoscono solo i dati di tipo carattere generici (PCDATA), le
enumerazioni di valori (potrebbe ad esempio essere possibile enumerare tutte le
possibili valute di denaro), e possono anche essere usati alcuni tipi di dati specifici
di XML (ID, IDREF, IDREFS, ENTITY, ENTITIES, NMTOKEN,
NMTOKENS, NOTATION) . Questa è un’eredità del passato SGML con il suo
approccio orientato al documento.
Si possono riassumere alcuni dei problemi che sorgono quando tutti gli elementi
vengono considerati come testo. Per esempio:
•
Il numero a virgola mobile “7.3e-6” sarebbe riconosciuto come maggiore
di “1.6e+19”.
•
Il numero negativo “-3” sarebbe considerato più piccolo di “-6”.
•
Due elementi numerici con lo stesso valore ma diversa formattazione non
verrebbero considerati uguali. Per esempio il numero di telefono (011)
732878 sarebbe considerato diverso da 011-732 878.
•
Il confronto dei valori delle date e date aritmetiche è praticamente
impossibile.
•
Se si incontra un elemento <prezzo> 150,000 </prezzo> non è possibile
sapere come interpretarlo. In un contesto internazionale sarebbe
interpretato come “CentoCinquantaMila”, ma in un contesto europeo
dovremmo leggerlo come “CentoCinquanta”.
Vi sono severe restrizioni, soprattutto nell’ambito del commercio elettronico, per
cui gran parte dei dati contiene numeri, date, e altri dati con un tipo particolare.
L’introduzione dei tipi di dato in XML risulta quindi di grande aiuto alla
creazione ed interpretazione dei dati per il business. Questo serve a potenziare
anche l’usabilità di un linguaggio di query.
Ma oltre alla mancanza dei tipi di dato la DTD soffre di altre mancanze. Essa
infatti non fornisce un supporto adeguato per la modularizzazione e il riuso degli
schemi di documento. Le stesse definizioni devono essere inserite ogni volta, cosa
che non rende tanto difficile la creazione di schemi con DTD quanto piuttosto il
loro mantenimento.
pag. 35
Infine le DTD non sono documenti XML ma seguono una sintassi diversa. Quindi
tutti gli strumenti software utilizzati per i documenti XML non possono essere
impiegati per creare, editare, effettuare il parsing o l’interpretazione delle DTD.
3.2.2 XML SCHEMA
Tutte le motivazioni esposte sulle carenze delle DTD hanno spinto allo sviluppo
di un nuovo metodo di definizione per gli schemi XML. Negli ultimi tre anni sono
stati presentati e messi in discussione alcuni linguaggi per la definizione di schemi
per XML. Come risultato si è giunti al rilascio dell’ XML Schema pubblicato dal
W3C. Adesso XML Schema è definitivo e considerato stabile (è stata da poco
rilasciata la raccomandazione dal W3C) ma anche il Working Draft, rilasciato
nell’aprile del 2000 era sufficientemente stabile.
Analizzando il punto di vista adottato da XML Schema per i tipi di dato si può
osservare che il sistema dei tipi di XML schema si basa sul concetto duale dello
Spazio dei Valori e dello Spazio Lessicale: uno Spazio dei Valori è una collezione
astratta di valori permessi per i tipi di dato. Ogni valore nello spazio dei valori
può avere diverse rappresentazioni testuali nello spazio lessicale. La
rappresentazione lessicale è ciò che appare nel documento XML. La definizione
dei tipi di dato definisce appunto la corrispondenza tra i due spazi di valori e
lessicale.
Ogni tipo di dato è definito da un certo numero di sfaccettature:
•
Le caratteristiche fondamentali definiscono le proprietà di base di ogni
tipo di dato. Sono “facet” fondamentali ad esempio Equal, Order, Bounds,
Cardinality, Numeric.
•
Caratteristiche di vincolo o non fondamentali sono lenght, minLenght,
maxLenght, pattern, enumeration, maxInclusive, maxExclusive,
minInclusive, minExclusive, precision, scale, encoding, duration, period.
•
XML Schema definisce anche un ricco insieme di tipi di dato predefiniti.
Alcuni di questi tipi di dato sono primitive, ad esempio non fanno
riferimento alla definizione di altri tipi di dato.
Altri sono derivati da preesistenti tipi primitivi o da altri tipi di dato derivati.
•
I tipi di dato primitivi predefiniti comprendono i tipi già noti nelle DTD
(come ID, IDREF, etc. per gli attributi) ma introducono anche nuovi tipi di
dato sia per gli attributi che per gli elementi: string, boolean, float, double,
decimal, timeDuration, recurringDuration, binary, uriReference, QName.
•
I tipi di dato predefiniti di tipo derivato sono language, Name, NCName,
integer, nonPositiveInteger, negativeInteger, long, int, short, byte,
nonNegativeInteger,
unsignedLong,
unsignedInt,
unsignedShort,
pag. 36
unsignedByte, positiveInteger, timeInstant, time, timePeriod, date, month,
year, century, recurringDate, recurringDay ma includono anche tipi di dato
presi dalle DTD (IDREFS, NMTOKEN, etc. per gli attributi)
Figura 4 :
LA GERARCHIA DEI TIPI IN XML SCHEMA
I tipi di dato definiti dagli utenti consentono ai progettisti di schemi di creare tipi
di dato personalizzati. Questi possono essere definiti in diversi modi:
Per enumerazione: per esempio è possibile definire un tipo di dato
“colorePerNome” enumerando i possibili valori: rosso, verde, blu, etc.
<simpleType name=”colorePerNome” base=”string”>
<enumeration value=”rosso”/>
<enumeration value=”verde”/>
<enumeration value=”blu”/>
<!-- tutti gli altri colori a seguire .. -->
</simpleType>
pag. 37
Si noti che una enumerazione si basa sempre sul vincolo di un altro tipo di dato
preesistente, in questo caso “string”.
Per derivazione di un tipo di dato da un tipo di dato predefinito e da un altro tipo
di dato definito dall’utente. Metodi possibili per la derivazione sono la
“restrizione” (consiste nell’aggiungere altri vincoli alle caratteristiche di un tipo) e
la “lista” (consiste nel costruire una lista da diversi valori atomici). Per esempio è
possibile definire un tipo di dato coloreRgb derivandolo dal tipo di dato
predefinito unsignedShort.
<simpleType
derivedBy=”list”/>
name=”unsignedShortList”
base=”unsignedShort”
<simpleType name=”coloreRgb” base=”unsignedShortList”>
<lenght value=”3”/>
</simpleType>
Questa definizione permette di utilizzare la rappresentazione del colore nella
forma di terne: per esempio 0 255 0. In questo modo i tipi di dato definiti
dall’utente sono sempre derivati da altri tipi di dati. La loro definizione deve far
riferimento ad un tipo predefinito o ad un atro tipo definito dall’utente.
I tipi di dato complesso sono specificati come definizioni di elemento. Queste
mettono in relazione le definizioni di elementi come date nelle DTD, ma
introducono vincoli aggiuntivi. I tipi di dato complessi possono essere definiti
anche per:
Estensione. In questo caso elementi o attributi addizionali vengono aggiunti ad
un elemento base. Nell’esempio riportato il tipo di dato base è “decimal”. Il tipo
di dato complesso “prezzo” è costruito aggiungendo un attributo “valuta” del tipo
“string”. La definizione di sopra permette l’uso di elementi XML come <prezzo
valuta=’ITL’>10000</prezzo>
Restrizione. In questo caso si costruiscono tipi complessi aggiungendo vincoli ad
una definizione di elemento preesistente. Per esempio è possibile limitare il
numero delle occorrenze di un elemento o specificare un tipo per un
sottoelemento dove non sono stati fissati precedentemente dei vincoli.
La definizione di tipi di dato complessi in XML Schema include le possibilità che
sono messe a disposizione con il modello dei gruppi conosciuto nei DTD. Gli
pag. 38
elementi possono essere definiti come: Empty. L’elemento non deve avere
contenuto, ma può avere degli attributi.
Gruppi “choice” e “sequence”. L’elemento può contenere solamente una o più
occorrenze di un elemento o di un modello di gruppo. Un modello di gruppo
consiste di un tipo di composizione (sequence, choice, all) che combina le
definizioni di altri elementi.
"Mixed" consente la definizione di elementi che contengono sia dati a caratteri
che elementi figli. Gli elementi “mixed” di XML Schema differiscono dagli
elementi mixed del DTD in quanto essi definiscono un ordine ed un numero degli
elementi figli.
I tipi di dato definiti con XML Schema possono essere utilizzati nelle definizioni
di elementi ed attributi di uno schema di documento XML. Ma è anche possibile
usare i tipi di dati nei documenti XML in maniera più dinamica e mirata: è
possibile far riferimento a definizioni di tipi di dato direttamente dall’interno di un
tag di elemento. Questo consente di utilizzare i tipi di dato anche per i documenti
XML per i quali non sono stati definiti schemi o DTD.
Questo viene fatto specificando un attributo “xsi:type” (il prefisso xsi identifica il
namespace o spazio dei nomi per le istanze di XML Schema) nel tag
dell’elemento e fornendo come valore la URL che si riferisce alla definizione dei
tipi:
<?xml version="1.0"?>
<ordine xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
dataOrdine="2000-04-07">
<inviareA xsi:type='http://www.grtn.it/schemaordine/indirizzo'>
<nome>Davide Spadoni</nome>
<via>via tomino 79</via>
<citta>Roma</citta>
<CAP>00142</CAP>
</inviareA>
</ordine>
pag. 39
In questo esempio nel documento non viene specificato uno schema. Vi è invece
un riferimento alla definizione di tipo complesso “indirizzo” dato per l’elemento
“inviareA”. Questo consente ai processori XML di verificare l’elemento con la
definizione del tipo “indirizzo”.
3.2.3 XPATH
A causa della struttura annidata dei documenti XML e per il fatto che XML
consente la ripetizione degli elementi, il linguaggio XPath deve fornire dei mezzi
per specificare le relazioni gerarchiche, le relazioni di sequenza, e le posizioni.
XPath ha anche degli specificatori di asse, come parent::, ancestor::, child::,
descendant::, following::, namespace::, etc.
La sintassi di XPath permette di definire le parti di un documento XML. Tuttavia
quella che viene impiegata maggiormente nelle query è la sintassi abbreviata, che
è possibile vedere nella tabella successiva.
Alcuni operatori di XPath
(esempi tratti dal documento XML precedente)
(prima parte)
Espressione Semantica
di Query
Esempio
del /libro
Risultato
/Q1
Nodo radice
documento
//Q1
Un
elemento //edizione
arbitrario
del
documento
Tutti gli elementi <edizione> in
ogni documento
Q1/Q2
Relazione
figlio
Tutti gli elementi <edizione>
che sono figli diretti del nodo
radice <libro>
Q1//Q2
Relazione
antenato/discendent
e
/libro//isbn
Tutti gli elementi <isbn> che
sono discendenti del nodo radice
<libro>
@
Attributo
@anno
Tutti gli attributi anno=
.
Nodo corrente
.//@ANNO
Tutti gli attributi anno che sono
discendenti del nodo corrente
..
Nodo genitore
..//@ANNO
Tutti gli attributi anno che sono
discendenti del nodo genitore
padre- /libro/edizione
Tutti i documenti con il nodo
radice <libro>
pag. 40
Oltre agli operatori XPath supporta una serie di funzioni, per verificare delle
condizioni, per tradurre e confrontare il contenuto. Poiché Xpath riconosce solo
quattro tipi di dato (insieme di nodi o node-set, stringa, numerico, booleano) ci
sono funzioni diverse per ognuno di questi tipi di dato.
Poiché ogni contenuto in un documento XML è costituito di caratteri, i confronti
lavorano basandosi ‘di default’ sulle stringhe. Per esempio l’espressione “24” <
“7” risulta vera secondo questa logica, perchè è il valore della stringa ad essere
confrontato e non i numeri.
Per confrontare i nodi sulla base dei numeri è necessario convertirli
precedentemente ai valori numerici:
number(“24”) < number(“7”) risulta allora falso.
Il confronto tra stringhe si basa su Unicode. Questo vuol dire anche che i
confronti tra stringhe sono sempre case sensitive.
Tutti questi operatori e funzioni possono essere utilizzati per formulare i criteri di
selezione specificati in filtri. I filtri ([]) sono paragonabili alla clausola WHERE
in SQL. Per esempio:
/libro[contains(titolo, ‘Zero’)]//isbn
Qui il criterio di selezione tra le parentesi quadre è applicato al nodo radice
(libro). Questo fa si che Xpath restituisca gli elementi <isbn> di tutti i documenti
<libro> che hanno un elemento figlio diretto <titolo> che contiene la sottostringa
‘Zero’.
L’espressione del filtro tra le parentesi quadre è essa stessa una espressione
Xpath. In modo simile ad SQL, Xpath consente l’annidamento delle espressioni di
query.
Ogni espressione Xpath è applicata riferendosi al contesto attuale come definito
dalla posizione dell’espressione del filtro. Nell’esempio di sopra l’espressione
filtro viene applicata al nodo <libro>, quindi tutte le espressioni Xpath contenute
nelle parentesi quadre sono relative al nodo <libro>. Segue una tabella con alcuni
esempi di uso delle funzioni di Xpath.
Gran parte dei linguaggi di query utilizzati oggi per XML fanno riferimento in
qualche modo ad XPath. Poiché XPath non è in grado di caratterizzare i costrutti
tipici che si trovano nei linguaggi di query dei database, le implementazioni
pratiche del linguaggio di query estendono le funzionalità di Xpath. Ad esempio
nel DBMS XML utilizzato in questa realizzazione viene fornito il supporto ad una
versione di XQL che utilizza gran parte della sintassi base di XPath.
pag. 41
Infine è opportuno introdurre i tipi di dato. Come è stato detto tutti i dati in XML
sono sotto forma di stringhe. La Document Type Definition (DTD) non permette
la definizione di tipi di elementi o attributi.
Alcune funzioni di Xpath
(con esempi tratti dal documento XML precedente)
Espressione
Query
di Semantica
Esempio
Risultato
last()
/libro/edizione[1, last()]
Numero
dell’ultimo nodo
nel
contesto
corrente
position ()
Posizione del nodo /libro/edizione[position() Terza edizione di un
corrente
nel = 3]
libro
contesto
del
genitore
count (insieme- Numero dei nodi Count(/libro/edizione)
di-nodi)
nell’insieme
di
nodi
Prima
ed
ultima
edizione di un libro
Numero delle edizioni
not (oggetto)
i
nodi
Tutti i nodi del /libro/edizione[not(@ann Tutti
<edizione>
esclusi
contesto
attuale o=‘1978’)]
quelli del 1978
escludi
quelli
contenuti
nell’operando
true(), false()
Valori
booleani /libro/edizione[false()]
vero e falso
number (oggetto) Converte al valore Number(@anno) > 1997
numerico
Restituisce una lista di
nodi vuota
Vero se l’attributo
anno contiene un
numero maggiore di
1997
Sum (insieme-di- Somma i valori Sum(/libro//prezzo) div Calcola il prezzo
nodi)
numerici di un count(/libro//prezzo)
medio di tutti i libri
insieme di nodi
pag. 42
3.2.4 INTERROGAZIONI IN XML
In questa parte si introducono i metodi di interrogazione (o Query) per le sorgenti
di dati in XML. Come sopra anche in questo caso verrà analizzato un semplice
esempio.
I documenti XML che verranno analizzati negli esempi successivi sono i seguenti:
<?XML version="1.0"?>
<!DOCTYPE librocat SYSTEM "http://www.libri.it/librocat.dtd">
<libro>
<titolo> Doppio Sogno </titolo>
<autore> Arthur Schnitzler </autore>
<edizione anno=1998>
<casaeditrice> Adelphi </casaeditrice>
<isbn>0-0703-2809-76</isbn>
<prezzo valuta=EUR>6.5</prezzo>
</edizione>
<edizione anno=1977>
<caseditrice> Morgante </casaeditrice>
<isbn>0-41-524089-4</isbn>
<prezzo valuta=ITL>1376</prezzo>
</edizione>
</libro>
Di solito quando si parla di “query” si fa riferimento ad SQL. SQL viene
utilizzato come abbiamo visto per accedere alle tabelle o a combinazioni di esse
in database relazionali.
Ma con XML la situazione è molto diversa. Un documento XML combina già di
per se diversi elementi informativi in un’unica entità fisica. Mentre in SQL
l’enfasi si pone sulla capacità di combinare dati da differenti tabelle normalizzate
in un unico risultato, in XML l’enfasi si pone nell’estrazione dei singoli elementi
in un documento.
Esiste uno standard in grado di fare proprio questo. XPath è la raccomandazione
attuale del W3C e viene usata in molti altri standard come XSL, Xpointer, Xlink,
pag. 43
etc., come la tecnologia base per l’indirizzamento di singoli elementi all’interno
di un documento.
Una semplice query effettuata secondo lo standard Xpath è ad esempio la
seguente:
/libro/edizione/casaeditrice
che indirizza tutti gli elementi casaeditrice contenuti negli elementi edizione nel
documento libro.
Si può notare la familiarità dell’espressione con il tradizionale path dei file
utilizzato in UNIX o nella specifica delle URL (Uniform Resource Locator).
L’unica differenza è che qui si indirizza un elemento in un documento e non un
file in una struttura a directory o una pagina web in un sito web.
Le somiglianze sintattiche di un’espressione Xpath con un file path o una URL
suggeriscono che Xpath può essere utilizzato non solo per l’estrazione degli
elementi in un documento ma anche essere ben impiegata per effettuare ricerche
di documenti in un server nativo XML.
Nei paragrafi successivi si vedrà che un intero sito web o il contenuto di un server
XML potrebbe essere visto come un singolo documento XML.
Una sorgente di dati può essere vista come un grande documento contenente tutti
gli altri documenti come suoi elementi. Basti ricordare che una directory per un
sito web costituisce una struttura ad albero, così come ogni documento presenta
anch’esso una struttura ad albero.
La ricerca di documenti da un sito può essere espressa in linguaggio simile
selezionando gli elementi da un documento. Si ha dunque una visione consistente
dei dati dal livello del sito web fino al livello del documento.
Questo rende Xpath un linguaggio di query eccellente. Un esempio:
www......it/serverxml/libreria/libro/edizione/casaeditrice
In questo caso “www.....it” specifica un dominio web, “serverxml” il server db che
gestisce i documenti XML nativi, “libreria”è una collezione di documenti XML, e
i restanti elementi del Path sono quelli visti precedentemente.
Se si possiede una cospicua libreria di libri, il risultato di una query del genere è
sostanzialmente il seguente: prendi gli elementi casaeditrice di tutti i libri
immagazzinati nella libreria.
Alcune caratteristiche del linguaggio XPath vengono utilizzate proprio per
effettuare query. Una implementazione di XPath è supportata dall’interfaccia
pag. 44
DOM di Microsoft, da XSL e da altri standard vicini a XML, ed è utilizzata nel
prototipo, come vedremo in seguito.
3.2.5 VISUALIZZAZIONE DI DOCUMENTI XML
Si è introdotto già il concetto secondo il quale in XML il contenuto informativo è
separato dalla sua rappresentazione. Progettato per includere le funzionalità dei
CSS (Cascading Stile Sheets) e DSSSL (Document Style Semantic &
Specification Language), l’XSL (eXtensible Stylesheet Language) ha come
compito specifico quello di essere il linguaggio di formattazione per XML.
Formattare le informazioni è un compito fondamentale. Nel trasferire certe
informazioni ad un’altra persona attraverso un documento (a anche attraverso la
voce), abbiamo bisogno di formattare le nostre informazioni in un qualche modo
che dipende dal mezzo che intendiamo impiegare. Nel fare ciò rendiamo più
comprensibile e leggibile il materiale al destinatario.
L’informazione ricevuta differisce quasi sempre dall’informazione originale in
quanto il canale informativo (il supporto) potrebbe non essere adatto a trasferire
tutte le sfumature dell’informazione originale, o perchè le conoscenze di base di
mittente e destinatario sono diverse.
Il processo di comunicazione è in realtà molto più complesso: prima di inviare
informazione, il mittente applica una trasformazione ai dati per poterli rendere
maggiormente comprensibili al destinatario. Questa trasformazione dipende dal
modello che lui possiede del destinatario. Basti pensare al modo con cui
generalmente un adulto si rivolge ad un bambino piccolo, ben diverso dal modo
con cui un politico si rivolge ai giornalisti.
Quindi la formattazione e l’abbellimento sono processi applicati non
all’informazione originale ma ad una sua forma trasformata.
In questo si riconosce il modello di processamento dell’XSL:
XSL = transformation + formatting
Questi compiti vengono svolti separatamente in XSL. Sono tre i documenti
rilasciati dal W3C per XSL, i primi due riguardano la trasformazione e l’ultimo la
formattazione:
•
Xpath definisce le modalità di selezione degli elementi in un documento
XML.
•
XSLT definisce la modalità di trasformazione dell’albero XML sorgente
in un albero richiesto.
pag. 45
•
XSL FO definisce la parte restante, cioè gli strumenti di formattazione.
In XSLT gli elementi di controllo principali sono le regole di modello, dei
“template”. Per comprendere come funzionano queste regole, è utile conoscere
come lavora un sistema esperto basato su regole: XSLT è un linguaggio
dichiarativo.
Ogni regola di modello consta di un elemento di intestazione e di un corpo.
L’elemento intestazione (match=) specifica una espressione Xpath per il
confronto con un modello. Quando un processore XSL elabora un documento,
esso parte dal nodo radice della struttura ad albero del documento. Esso verifica
che le regole del modello siano verificate o meno dal nodo radice. Se si
riconoscono più regole verificate dal nodo, viene selezionata la regola che
combacia meglio:
I Formatting Objects (il cui prefisso è “fo:” ) vengono trascritti sul canale di
uscita. Insieme con le decorazioni questi vengono elaborati dal processore di
formattazione.
Le istruzioni XSL (il cui prefisso è “xsl:” ) vengono eseguite. In particolare,
l’istruzione “xsl:apply-templates” ripete il processo di confronto per la lista di
nodi corrente (o per una lista di nodi specificata esplicitamente). Altre istruzioni
“xsl:” forniscono strutture di controllo addizionali come esecuzione condizionale
o loop.
L’istruzione “xsl:value-of” scrive il contenuto del nodo corrente (o di un nodo
esplicitamente specificato) sull’uscita.
Listato di esempio
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
<xsl:template match="/">
<!—intestazione della regola template, percorso per il nodo radice -->
<HTML>
<!-- qui inizia l’output generato -->
<BODY>
<TABLE BORDER="2" CELLPADDING="6" STYLE="margin-left:1.5cm;">
<TR>
<TH>Anno</TH>
<TH>Mese</TH>
pag. 46
<TH>Giorno</TH>
</TR>
<!—segue il loop sui prodotti attraverso dettaglioProdotto -->
<xsl:for-each select="Data">
<TR>
<TD STYLE="letter-spacing:8pt; font-size:24pt;">
<xsl:value-of select="/Data/Anno/"/>
</TD>
<!-- inserisce l'anno -->
<TD><xsl:value-of select="mese"/>
</TD>
<!-- inserisce il mese-->
<TD><I><xsl:value-of select="giorno"/></I>
</TD>
<!-- inserisce il numero del giorno -->
</TR>
< /xsl:for-each>
<!-- termina il loop -->
</TABLE>
</BODY>
</HTML>
</xsl:template>
</xsl:stylesheet>
Questo esempio trasforma un elenco di date in una tabella HTML. Il foglio di stile
contiene solamente una singola regola di template che si confronta con il nodo
radice. Viene usato una dichiarazione for-each per effettuare il vaglio di tutte le
date con un loop. Poichè l’uscita è in HTML, gli fo , formatting objects, non sono
usati ma viene applicata della formattazione CSS.
XSLT consente la parametrizzazione delle regole di template con le variabili.
Questo permette il riutilizzo delle regole esistenti per diversi scopi , fornendo
differenti parametri. Possono essere definite delle variabili a livello di regola o a
livello globale.
pag. 47
L’uso delle variabili in XSLT dimostra anche le limitazioni dell’XSLT stesso: in
effetti non si tratta di un linguaggio di programmazione “general purpose”. Il
modello elaborativo di XSLT è privo di stato e i valori sono assegnati ad una
variabile quando questa variabile viene definita (variabile di default), oppure
quando un parametro viene passato ad una regola di template.
In particolare, non è presente in XSLT un operatore di assegnazione. Questo
rende il modello di elaborazione semplice, ma non permette di utilizzare le
variabili per effettuare conteggi.
Formatting Objects
Questa parte della specifica è la più ampia in termini di documentazione, ma è
anche quella con la struttura più semplice.
XSL definisce più di cinquanta formatting object. Questi descrivono gli elementi
dell’uscita formattata e sono organizzati in gruppi:
•
Pagination e Layout Formatting Objects: Questi oggetti definiscono i master
di pagina e le sequenze di pagine. Sono possibili più master di pagina (per la
prima pagina, l’ultima, pagine pari e dispari, pagine vuote). Si ricordi che
XSL non è usato solo per formattare l’uscita su di uno schermo ma anche per
formati di uscita su stampa.
•
Block Formatting Objects: Questi sono oggetti che sono utilizzati al di fuori
dei blocchi di oggetti e che includono il blocco oggetto stesso, ma anche
grafica e regole. I block object tipicamente contengono linee di testo, simili
ad un paragrafo di un word processor, ma sono molto più versatili.
•
Inline Formatting Objects: Questi sono oggetti inseriti all’interno dei block
object. Essi includono testo, grafica o regole. Vengono applicate delle parole
di intestazione a tutti i f.o. inline.
•
List Formatting Objects: Sono oggetti usati per costruire liste.
•
Table Formatting Objects: Oggetti usati per costruire tabelle.
•
Link e Multi Formatting Objects: Questi oggetti comprendono il semplice
oggetto “link” (simile ad un link HTML) ed un insieme di oggetti “multi” che
consentono al contenuto di venire nascosto o visualizzato, di cambiarne le
proprietà, etc. a seconda dell’interazione con l’utente. Per esempio potrebbe
essere possibile ampliare la piccola stampa (solo) di un contratto di licenza
quando l’utente clicca con il puntatore del mouse sull’icona di una lente di
ingrandimento, o cliccare su un nodo per far collassare un braccio dell’albero,
nascondere una tabella dei contenuti quando lo richiede l’utente, o leggere un
paragrafo ad alta voce con un sintetizzatore quando l’utente seleziona la
funzione di lettura audio.
pag. 48
•
Out-of-Line Formatting Objects: Questi sono oggetti che non appaiono nella
posizione dove sono definiti ma nella posizione subito successiva. Questi
comprendono gli oggetti flottanti e le note a piè di pagina.
Nel confronto con il preesistente standard CSS, si vede che XSL fornisce una
gestione migliore e specializzata per i documenti XML. Tra le nuove
caratteristiche vi sono la paginazione, il supporto per l’internazionalizzazione, e le
trasformazioni dipendenti dal contenuto (come nell’esempio sopra riportato). Con
HTML e CSS tali funzionalità richiedono l’uso di JavaScript o di pagine web
dinamicamente generate dal server.
Il supporto dell’XSL da parte dei browser è tuttavia ancora poco diffuso. Sulla
versione 5 di Internet Explorer di Microsoft viene implementata una versione
working draft di XSLT, mentre la raccomandazione finale XSLT 1.0 viene
implementata nella versione più recente IE5.5. Quest’implementazione si basa su
modulo MSXSL.DLL che rende effetivamente XSL un servizio del sistema
operativo. Qui non sono supportati tuttavia i Formatting Objects.
Ci vorranno alcuni anni perché la maggior parte dei browser web installati siano
in grado di elaborare XSL.
Questo rende XSL di interesse soprattutto dal lato server per i prossimi anni. I
fogli di stile XSLT saranno utilizzati per convertire le pagine XML ad HTML
prima di inviarle al client. Il codice HTML così generato può contenere elementi
di formattazione CSS ulteriori per fornire un output più sofisticato.
3.3 IL MODELLO DEI DATI XML
Abbiamo precedentemente discusso le caratteristiche del linguaggio Xpath, ora è
necessario chiarire alcuni aspetti del modello dei dati XML. Le seguenti
caratteristiche differenziano il modello dei dati XML dal modello dei dati
relazionale:
•
Metadati come le etichette (tags) e i nomi degli attributi sono contenuti nei
documenti.
•
I documenti XML hanno una struttura ad albero.
•
Gli elementi dei documenti possono essere annidati e contenere degli attributi.
•
Sono permessi più elementi con stessi tag in uno stesso documento.
•
Sono rilevanti la sequenza e la posizione.
pag. 49
Diversamente da SQL, un linguaggio di query per XML deve essere dunque in
grado di navigare la gerarchia degli elementi e indirizzare gli elementi tramite la
posizione e la sequenza.
Nell’accedere ad un documento, XPath guarda al documento come ad una
struttura ad albero fatta di nodi. Sul livello concettuale un nodo può essere l’entità
stessa del documento, ogni elemento o attributo, una processing instruction (PI) o
un commento. Il documento stesso costituisce il nodo radice, che contiene una
lista di nodi che sono figli diretti del nodo radice. Questi nodi possono a loro volta
contenere una lista di nodi e così via. Questo approccio unificante alla struttura
dei documenti XML rende XPath semplice e potente.
Figura 5 :
STRUTTURA DELL’ESEMPIO DEL <LIBRO>.
Nella figura riferite alla struttura del "LIBRO" è stato evidenziato <edizione> con
un segno + per indicare l’occorrenza di più edizioni. Gli attributi sono presentati
come figli degli elementi che li possiedono e sono identificati dal carattere @.
Sul livello fisico XPath non prescrive un formato fisso per i nodi. Un nodo può
essere rappresentato da testo XML, da un sottoalbero DOM (Document Object
Model), da alcune strutture dati che descrivono delle sottoregioni nel documento,
etc.
3.3.1 IL MODELLO XML E IL MODELLO RELAZIONALE
Il modello dei dati relazionale si basa sulle tabelle. Le tabelle contengono i dati
relazionati, anche chiamati “Relazioni”, ed è proprio per questo che i DBMS che
si basano su questa teoria si indicano con l’acronimo RDBMS (Relational
DBMS).
pag. 50
Le relazioni rappresentano le entità che si ritiene essere interessanti nel database.
Ogni istanza dell'entità troverà posto in una tupla della relazione, mentre gli
attributi della relazione rappresenteranno le proprietà dell'entità.
Per strutturare un Database relazionale sono necessarie delle operazioni di
normalizzazione delle tabelle, ad esempio per la rimozione di alcune anomalie.
Ma la normalizzazione è un processo oneroso dal punto di vista della
progettazione e manutenzione dello schema della base di dati, ed inoltre introduce
dei problemi di integrità dei dati.
Dopo la normalizzazione il RDBMS non ha informazioni riguardo la struttura dei
complessi oggetti informativi originali e non può controllare la loro integrità
strutturale. Gli RDBMS (Relational DataBase Management System) risolvono
questo problema reintroducendo informazioni strutturali nella forma di vincoli di
integrità e limitatori, che consentono al RDBMS di controllare l’integrità delle
relazioni chiave mentre vengono effettuate operazioni di aggiornamento.
Comunque, questo introduce un “overhead” cioè aumento della complessità
elaborativa.
La modalità con cui XML memorizza le informazioni non richiede uno schema
perché tutti gli elementi informativi hanno un loro nome. In XML i dati sono
modellati come in un albero ordinato ed etichettato. I nodi dell’albero sono gli
elementi informativi, i dati, ma possono anche consistere di attributi, processing
information (PI), o commenti.
Gli oggetti XML sono auto descrittivi: essi contengono tutte le informazioni
necessarie per le interrogazioni e per la navigazione nei singoli elementi. In tal
modo XML richiede una quantità di spazio molto maggiore rispetto al modello
relazionale, ma è possibile effettuare una compressione. L’uso dei “tags”
comporta però grandi vantaggi quando si deve aggiungere un elemento. Per un
RDBMS, al contrario, si rende necessario modificare lo schema relazionale,
operazione che nei casi più complessi comporta una onerosa reiterazione dei passi
di normalizzazione e il progetto di un nuovo database può rendersi necessario. In
XML, quindi, non c’è bisogno della normalizzazione.
Di fatto un oggetto XML potrebbe da solo contenere l’intero database, ma
comunque è consigliabile solo per database di dimensioni molto piccole. Nel
database di un’impresa è tuttavia necessario spezzare un insieme molto ampio di
dati in diversi oggetti più piccoli e connetterli con dei link. Un link è un
riferimento diretto, mentre un JOIN relazionale deve richiedere il confronto del
contenuto di una chiave esterna e di una chiave primaria. Dunque XML consente
agli elementi ridondanti di essere isolati e di sostituire le loro occorrenze con dei
link.
La forza di XML tuttavia sta nella capacità di immagazzinare in modo flessibile le
informazioni complesse e strutturate. Si può comprendere il dilemma con cui ci si
pag. 51
deve confrontare oggi nella scelta e utilizzo di un RDBMS per documenti di tipo
XML.: un intero documento XML può essere memorizzato in un unico oggetto,
rendendo in tal caso impossibile indicizzare i singoli elementi. Oppure il
documento può essere decomposto in singoli elementi che sono indicizzati
separatamente. Le operazioni di retrieval dei dati devono quindi leggere tutti gli
elementi separatamente e riunirli insieme, con un’operazione costosa in termini
prestazionali. L’RDBMS deve dunque ricostruire il “puzzle” dei dati ogni volta.
Inoltre le regole di integrità e l’imposizione di limiti sono necessari per
conservare l’integrità dell’oggetto.
Un altro problema è il “locking”: durante un processo di aggiornamento un
documento deve essere bloccato (locked) per evitare che altri utenti tentino
l’accesso ad esso. In un RDBMS in cui un documento (come ad esempio un
documento XML) è spezzato in numerosi pezzi, ogni singolo pezzo deve essere
bloccato separatamente. Ecco perché diverse aziende di software hanno proposto
la commercializzazione di server nativi XML. Un server nativo XML (ovvero
XDBMS) può offrire operazioni di ricerca note all’ambiente degli RDBMS.
Un XDBMS offre una maggiore flessibilità in quanto è possibile inserire nuovi
tags XML “al volo” – nessun aggiornamento dello schema è richiesto. Allo stesso
tempo il server può mantenere un livello di performance pari ad una lettura per
ogni documento (o anche meno grazie a tecniche di caching). I Benchmarks
dimostrano che i servers XML nativi possono superare gli RDBMS nelle
prestazioni di un ordine di grandezza, ovviamente nel caso in cui vengano
utilizzati per la memorizzazione di complessi oggetti XML.
3.3.2 DIFFERENZE TRA DBMS XML NATIVO E TRADIZIONALE
L’introduzione e l’integrazione delle tecnologie XML rappresentano uno dei
maggiori passi avanti nella gestione e nello scambio dei dati attraverso ambienti
internet-intranet. Per questi aspetti, già analizzati nei capitoli precedenti,
prendiamo in esame solo quelli applicativi necessari per l’implementazione del
prototipo.
In passato XML è stato spesso incompreso e etichettato come semplice successore
di HTML. In realtà questo linguaggio è destinato a permanere (sotto forma ad
esempio di XHTML) nella parte di formattazione e visualizzazione di documenti
web. Mentre XML si occupa della gestione dei dati relativi alla pubblicazione
(pubblicazione via web, wap, set-top-box, terminali di vario tipo o anche formati
di stampa etc.). XML ha grandi vantaggi immediati nella gestione e scambio di
risorse di archivio, con particolare riferimento alla rappresentazione di ogni tipo
di struttura dati. Nel seguito si riportano alcune considerazioni sull’uso di una
piattaforma per la gestione dei metadati basata su XML nativo.
•
XML è un metalinguaggio che può definire e descrivere ogni tipo di
informazione ed è per definizione estensibile. Utenti singoli, gruppi di lavoro,
e organismi di standardizzazione utilizzano XML come un tipo di grammatica
indipendente dalla piattaforma per definire linguaggi basati sui marcatori.
pag. 52
•
Si basa sul testo ed è facile da leggere: i documenti possono essere compresi
sia dalle applicazioni che da utenti umani. Sempre per definizione il contenuto
di documenti XML è etichettato con i tag, che specificano quale tipo di
informazione è contenuta all’interno di un elemento del documento. Con
l'utilizzo di questi tag i documenti XML possono essere compresi anche se
non si dispone dell’applicazione che li ha generati.
•
E’ ideale per i documenti contenenti informazioni strutturate gerarchicamente.
Gli elementi dei documenti XML possono essere annidati per costruire
strutture informative complesse. In linea di principio è possibile convertire
documenti XML con una struttura complessa in modo da utilizzare DBMS a
tecnologia relazionale, ma si tratta di un’operazione tutt’altro che ottimale. Per
esempio, mappare elementi XML con il contenuto di tabelle relazionali è un
processo molto spesso lento e che richiede un grande sforzo di
normalizzazione e ottimizzazione.
Figura 6 :
CONFRONTO TRA UN DBMS RELAZIONALE E UN DBMS XML
NATIVO PER LA GESTIONE DI DATI DESCRITTI IN LINGUAGGIO XML
•
XML è indipendente dalla modalità di presentazione: separa il contenuto del
documento dalla sua visualizzazione. I fogli di stile definiscono come gli
elementi del documento devono essere formattati per l’uscita verso una varietà
di terminali o supporti di visualizzazione. Gli standard associati ad XML
consentono, come abbiamo visto nei capitoli precedenti, la personalizzazione
di un dato elemento informativo senza la necessità di modificare il contenuto
del documento originale.
•
XML è multilingua, basato sulla codifica UNICODE. La capacità di
rappresentare caratteri in quasi tutti i linguaggi mondiali – inclusi il Cinese e il
Giapponese – facilita enormemente lo scambio di dati e documenti in un
comunità globale.
•
L’uso di un linguaggio standard come XML favorisce l’integrazione degli
aspetti di business abbattendo gran parte delle barriere al commercio
elettronico: Le attuali soluzioni di Electronic Data Interchange (EDI) sono
pag. 53
difficili e costose da implementare e mantenere. Con l’uso di tecnologie XML
ci si avvantaggia della flessibilità nella definizione di vocabolari specifici per
settori industriali, e diviene anche possibile per le piccole e medie imprese
accedere alle reti EDI utilizzando standard semplici ed economici basati su
Internet.
•
E’ un metalinguaggio aperto e lo standard viene supportato da tutti i grandi
produttori software: compagnie come IBM, Microsoft, Oracle, Sun
Microsystem, e la stessa Software AG che è stata una delle prime a realizzare
un sistema con un engine XML nativo. Tutte queste aziende hanno
pesantemente investito sull’XML e sono attive nel contribuire al processo di
standardizzazione.
Questi sono solo alcuni degli aspetti che giustificano l’impiego di un Server XML
nativo per la gestione di strutture dati basate completamente su XML, poiché,
come abbiamo ampliamente visto, lo standard Mpeg-7 e in particolare il
Description Definition Language e il Multimedia Description Schemes sono
completamente basati su questo linguaggio.
La piattaforma software, Tamino di Software AG, è proprio un Information
Server basato su XML, che gestisce in modo nativo il formato XML per
memorizzare ed estrarre dati di ogni tipo. Utilizzando l’XML come una “metaStruttura”, il server DBMS XML Tamino consente di comporre le informazioni
da dati che possono essere originati da differenti sistemi di memorizzazione e
DBMS.
3.4 PROGRAMMARE CON XML
Si è visto come il linguaggio di stile XSL possa essere utilizzato per trasformare e
formattare un documento XML. Esso risulta di particolare interesse nelle
operazioni di visualizzazione o stampa di documenti XML, ma non consente la
comprensione di un documento XML da parte di un programma.
Discutiamo le Application Program Interface (API) per XML. Non è infatti di
interesse esclusivo dei web browser ma anche delle applicazioni poter elaborare
XML. Attualmente risulta difficile utilizzare diffusamente XML, come abbiamo
detto, nella maggioranza dei browser web. XML risulta di grande aiuto per la sua
portabilità e la flessibilità con cui il formato dei documenti può essere cambiato: è
uno strumento ideale per l’interoperabilità delle applicazioni, utilissima
nell’ambito del business.
Mentre i dati sono formattati solitamente in formato binario (come nel caso dei
dati EDI o dei dati provenienti da un database relazionale), i dati XML sono
testuali. Per valutare un documento XML è quindi necessario effettuare il parsing
del documento e convertirlo in formato binario che possa essere elaborato più
agevolmente da un’applicazione. Questo procedimento può essere equiparato al
parsing del codice sorgente del programma di un elaboratore: le informazioni
pag. 54
testuali sono tradotte in formato binario che può essere interpretato dalla
macchina.
3.4.1 PARSERS STANDARD
Ci sono due diversi metodi di base standardizzati per effettuare il parsing di un
documento XML. Uno è il Simple API for XML (SAX) e un secondo è il
Document Object Model (DOM).
La Simple API for XML (SAX)
La SAX una API (Application Program Interface lo standard per il parsing eventbased di XML. SAX non è uno standard W3C ma è stato sviluppato
congiuntamente dai membri della mailing-list XML-DEV. Sono di pubblico
dominio le versioni Java e C++ dei parser SAX.
Essendo un parser basato sugli eventi, SAX scansiona un documento in maniera
sequenziale. Quando una unità sintattica viene riconosciuta il parser informa il
chiamante (callback) di questo evento. Il gestore del documento che chiama il
SAX e che viene informato di questi eventi può decidere cosa fare: ignorare
l’evento, modificare lo stato dell’applicazione, o fermare il parsing.
Gli eventi supportati da SAX sono: startDocument, endDocument, startElement,
characters, ignorableWhitespace, e processingInstruction.
Il vantaggio della tecnica SAX è che il parser non richiede molte risorse: non
necessita di tenere tutto il documento in memoria, in quanto lo legge in maniera
sequenziale, carattere per carattere. Per il programmatore la API di SAX è la più
semplice non c’è un gran numero di tipi di evento da dover gestire. Comunque,
per il parsing un documento complesso può essere richiesto un certo sforzo di
programmazione.
Document Object Model (DOM)
DOM è una interfaccia di programmazione completa per documenti HTML e
XML. Utilizzando DOM i programmatori possono creare o caricare documenti
XML, navigare la loro struttura, e ricercare, aggiungere, modificare, o cancellare
elementi e contenuto. DOM è progettato per essere usato con qualunque
linguaggio di programmazione. DOM lavora in maniera completamente diversa
rispetto al SAX.
Quando DOM legge un documento esso analizza la struttura completa del
documento e costruisce un albero di tutti i nodi del documento nella memoria. Il
controllo viene restituito al processo chiamante solo dopo aver elaborato tutto il
documento. L’applicazione può allora usare la API DOM per navigare l’albero e
ricercare ed estrarre contenuto, modificare i nodi, cancellarli, o inserirne di nuovi.
pag. 55
Il vantaggio del DOM è che l’intera struttura del documento viene presentata alla
applicazione chiamante, che può dunque navigare avanti e indietro liberamente
nei nodi del documento, cosa impossibile con SAX. Le applicazioni possono
anche modificare i documenti o creare nuovi documenti.
La API DOM è molto ricca di funzionalità (l’interfaccia Element da sola ha 27
metodi diversi e DOM ha 17 diverse interfacce, vedremo il dettaglio
successivamente). Sia SAX che DOM sono parser standard che trattano i
documenti XML al livello di XML generico, così che il processo di parsing è
indipendente dalla specifica classe di documento. Alcune implementazioni di
SAX e DOM possono verificare il documento elaborato per la sua validità
verificandolo assieme alla specifica DTD o XML Schema.
pag. 56
CAPITOLO 4
MPEG-7 : MULTIMEDIA CONTENT DESCRIPTION
INTERFACE
4.1 CONSIDERAZIONI PRELIMINARI
Il primo obiettivo dell’MPEG-7, chiamato “Multimedia Content Description
Interface” (ISO/IEC 15938), è quello di definire gli schemi per la descrizione del
contenuto o degli standards di metadati adatti a risorse multimediali anche
complesse al fine di consentire una agevole ricerca di documenti audiovisivi
all’interno di un archivio digitale.
Nell’ambito del progetto Internet TV fase2 Vivai D’Impresa-Elis, si è
approfondito il problema dell’identificazione di un set base di strumenti dello
standard MPEG-7 necessari alla descrizione dei contenuti di un archivio video
digitale, come TecaFast della RAI si è sviluppata l'architettura di un sistema di
descrizione Mpeg-7 iniziato nella prima fase di progetto In questo capitolo si
mostrerà la producedura utilizzata per descrivere i servizi giornalistici trasmessi
dalle tre reti nazionali della RAI.
4.2 INTRODUZIONE ALLO STANDARD MPEG-7
Lo standard MPEG-7 fornisce una serie di strumenti (descrittori, schemi di
descrizione, un linguaggio per la definizione di descrittori, sistemi per la codifica,
trasporto, aggiornamento e navigazione di descrizioni strutturate, etc..) per lo
sviluppo di applicazioni di descrizione multimediale che possono essere
immagazzinate (on-line oppure off-line) o trasmesse (ad es. broadcasting).
MPEG-7 si propone di operare indifferentemente in ambiente real-time (Inline
nella semantica dello standard) o non real-time (in documenti esterni alla risorsa
multimediale che viene descritta).
Agire in un ambiente real-time o Inline vuol dire associare le descrizioni MPEG-7
direttamente al codice che rappresenta il contenuto nel momento in cui
quest'ultimo viene catturato o codificato opportunamente.
Per sfruttare tutte le potenzialità delle descrizioni MPEG-7 sono indubbiamente
necessari degli applicativi per l’estrazione automatica degli attributi, una modalità
che non sempre è possibile.
Più alto è il livello di astrazione, più difficoltosa si rivela l'estrazione automatica
degli attributi, fino a diventare impossibile (un esempio sono le informazioni sulla
creazione del contenuto, come autore, titolo, contributori, che non possono essere
estratte dal contenuto stesso); diventa quindi di chiara utilità l’uso di eventuali
pag. 57
strumenti di estrazione interattivi, ma solo per un dato tipo di attributi di basso
livello. Comunque gli algoritmi di estrazione automatica degli attributi, non
compaiono all'interno del campo di azione dello standard.
La principale ragione di questa scelta è che la standardizzazione di tali algoritmi
non è richiesta per garantire l'interoperabilità. Allo stesso tempo si lascia spazio,
in questo modo, alla competizione industriale. Anche i motori di ricerca non sono
specificati all'interno del campo di azione dello standard, sta agli svlippatori di
applicazioni Mpeg-7 definire le modalità.
Consideriamo l'esempio di una informazione visiva: un livello di astrazione più
basso, potrebbe essere rappresentato dalla descrizione di forma, dimensioni,
texture, colore, movimento (traiettoria) e posizione. Per l'audio lo stesso si può
dire per tonalità, ritmo, cambi di ritmo.
Ad un livello di astrazione più alto possiamo trovare informazioni sulla
semantica: potremmo descrivere uno scenario, dove compare un signore che parla
sulla destra, una foglia che cade a terra sulla sinistra, ed infine un sottofondo
sonoro frutto del passaggio di un jet nel cielo. Tutte queste descrizioni sono
ovviamente codificate in maniera da rendere efficiente la ricerca dello scenario.
Lo standard, al di là di questo esempio, prevede anche livelli di astrazione
intermedi. Il livello di astrazione va messo in relazione con le differenti modalità
di estrazione degli attributi: molti attributi di basso livello possono essere estratti
in modo completamente automatico, mentre attributi di alto livello necessitano di
una più alta interazione umana.
Dopo aver fornito una descrizione del materiale, può essere richiesto di includere
altre informazioni sui dati multimediali in nostro possesso. Alcune informazioni
rilevanti sono ad esempio quelle di:
FORMATO: Un esempio di formato è il tipo di codifica usato (JPEG,
1.
MPEG2, altri), oppure la mole totale di dati. Queste informazioni permettono di
stabilire se l'utente è in grado di leggere il materiale.
ACCESSO AL MATERIALE: Questa voce può tenere in considerazione
2.
aspetti quali informazioni sul copyright o prezzo del materiale.
CLASSIFICAZIONE: Può includere la catalogazione del contenuto
3.
all'interno di categorie predefinite.
LINKS AD ALTRO MATERIALE RILEVANTE: Questo tipo di
4.
informazione può velocizzare la ricerca da parte di un utente di materiale
correlato.
CONTESTO: Nel caso di contenuti di natura non cinematografica o più
5.
in generale non fittizia, se questi sono registrati è molto importante conoscere in
pag. 58
quale occasione è avvenuta la registrazione (per esempio una determinata partita
di pallavolo delle olimpiadi del 2002).
In molti casi è utile ricorrere ad informazioni testuali per le descrizioni di un
materiale audiovisivo. Un esempio dell'utilità di tale accorgimento è dato
dall'aggiunta di metadati fondamentali come il nome dell'autore, il titolo di un
film, l'indicazione di un luogo, la data di trasmissione o pubblicazione.
Come preannunciato i dati di tipo Mpeg-7 possono essere fisicamente localizzati
assieme al materiale audiovisivo cui si riferiscono: in particolare essi si possono
trovare nello stesso flusso di dati, o possono essere memorizzati nella stessa
periferica, ma le descrizioni degli oggetti di interesse potrebbero essere situate da
qualche altra parte sul globo.
Lo standard Mpeg-7 è stato programmato in 7-parti:
Parte
1
2
3
4
5
6
7
Titolo
Systems
Description Definition Language
Visual
Audio
Multimedia Description Schemes
Reference SW
Conformance
Il contenuto tecnico delle parti è il seguente:
•
System fornisce la struttura dello standard, il trasporto del contenuto Mpeg-7
ed il formato binario del contenuto Mpeg7
•
Description Definition Language permette generare i descrittori e gli schemi
di descrizione
•
Visual fornisce i descrittori standard e gli schemi di descrizione che sono
puramente visivo
•
Audio fornisce i descrittori e gli schemi standard di descrizione che sono
puramente audio
•
Multimedia Description Schemes (MDS) fornisce i descrittori e gli schemi
standard di descrizione che non sono nè visivi nè audio
•
Reference software ha lo stesso valore normativo di quello di Mpeg-4 e
possono essere usati per i prodotti alle stesse circostanze
La parte di interesse dello standard per la nostra applicazione è il MDS, che
fornisce i descrittori necessari sia per descrivere la struttura logica della risorsa
audiovisiva sia per identificare le sue caratteristiche.
pag. 59
Le librerie digitali (cataloghi di immagini, dizionari musicali…), i servizi di
multimedia directory (una sorta di Pagine Gialle multimediali), la selezione di
servizi di broadcasting (canali radio e televisivi) e il Multimedia editing (servizi di
informazione elettronica personalizzati) possono trarre indubbio vantaggio
dall’utilizzo degli strumenti dello standard MPEG-7.
I descrittori MPEG-7 consentono di costruire applicazioni per la gestione di
contenuti multimediali anche molto complessi, costituiti da oggetti diversi
relazionati tra di loro tramite relazioni di tempo e di spazio (sequenze o
presentazione di contenuti in parallelo, esempio audio, video immagini e
animazioni 3d) o relazioni di struttura (è possibile definire una collezione di
contenuti multimediali come immagini con delle relazioni descritte da un grafo) e
relazioni di tipo semantico (descrivere le azioni degli oggetti in un video ad
esempio un’azione di “dribbling” in una sequenza che riprende un goal su un
campo di calcio) o anche descrivere dei concetti.
In realtà la vera potenzialità di un’infrastruttura multimediale sta proprio nel
fornire degli automatismi e meccanismi intelligenti di elaborazione e
comunicazione tra dispositivi elettronici, come nel caso dell'elaborazione
intelligente delle immagini (per applicazioni di sorveglianza, visione intelligente,
riconoscimento di forme), della conversione del formato dei dati (ad esempio la
conversione automatica del parlato di un filmato in testo per gli audiolesi, la
ricerca di informazione di vario tipo su documenti multimediali di particolare
interesse per l'utente secondo un profilo, oppure operazioni di controllo e
filtraggio per ricevere solo quei dati che soddisfano le scelte dell'utente).
Sarà necessaria una forma di rappresentazione delle informazioni multimediali
che possa permettere un certo grado di interpretazione sul significato delle
informazioni che sono trasmesse ad un dispositivo.
4.2.1 STRUTTURA DEI MULTIMEDIA DESCRIPTION SCHEMES
Gli strumenti di descrizione, mostrati nella figura seguente, sono strutturati
principalmente sulla base delle funzionalità che forniscono.
Al livello inferiore della figura seguente si possono trovare gli elementi base. Si
tratta degli Schema Tools (elemento radice, elemento di livello superiore e
packages), i tipi di dato basilari (basic datatypes), le strutture matematiche,
collegamenti e localizzatori di supporto (linking and media localization) , e
strumenti come Schemi di Descrizione (DSs) di base, che si possono trovare come
componenti elementari o DSs più complessi.
Partendo da questo livello, possono essere definiti gli elementi di descrizione del
contenuto e di gestione (content description & management). Questi strumenti di
descrizione descrivono il contenuto di un singolo documento multimediale da
diversi punti di vista. Attualmente cinque punti di vista sono definiti: creazione e
Produzione, Media, Utilizzo, Aspetti Strutturali e Aspetti Semantici. I primi tre
strumenti di descrizione indirizzano principalmente le informazioni relative alla
pag. 60
gestione del contenuto (content management) mentre le ultime due sono più
dedicate alla descrizione di informazione percepibile (content description).
Content
organization
Models
Collections
User
interaction
Navigation
&
Access
Creation &
Production
Media
Content
management
Usage
Structural
aspects
Summaries
Views
Views
Content
description
Semantic
aspects
User
Preferences
User
History
Variations
Basic elements
Schema
Tools
Basic
datatypes
Links &
media
Basic
Tools
Figura 7 : VISTA D’INSIEME DEGLI STRUMENTI DI MPEG-7 MDS
Vediamo più in dettaglio gli strumenti generali di Mpeg-7:
•
Basic Element fornisce specifici data-types e strutture matematiche come
vettori e matrici che sono importanti per la descrizione di contenuto audio –
video. Sono anche inclusi in Basic Elements costrutti per il collegamento ai
media files e per localizzare i segmenti, regioni e altro. Molti dei basic
elements specificano elementi necessari alla descrizione del contenuto come
la descrizione di tempo, persone, individui, gruppi, organizzazioni e altre
annotazioni testuali.
•
Content Management descrive differenti aspetti della creazione e
produzione, codifica del media, formati di files, memorizzazione e uso del
contenuto.
•
Content description specifica elementi per descrivere la struttura ( regions,
video frames, segmenti audio) e la semantica (oggetti, eventi, nozioni
astratte).
•
Navigation and Access definisce decomposizioni, partizioni e sommari per
facilitare la navigazione e il reperimento del contenuto multimediale.
pag. 61
•
Content Organization fornisce gli strumenti per modellare e organizzare
collezioni di contenuti audio-video e collezioni di descrizioni.
•
User Interaction definisce gli strumenti per descrivere le preferenze
dell’utente e la storia dell’uso del materiale multimediale.
Con la seguente tabella si definiscono in maniera più precisa le funzionalità di
ogni gruppo di strumenti di descrizione per il Content Management e il Content
description:
Insieme di
strumenti di
descrizione
Funzionalità
Media
Descrizione del supporto di memorizzazione: formato di
memorizzazione, la codifica del contenuto multimediale,
l’identificazione del supporto.
Creazione e
Produzione
(Creation)
Metadati che descrivono la creazione e produzione del
contenuto: tipiche caratteristiche sono il titolo, il creatore,
la classificazione, lo scopo della creazione, etc. Questa
informazione è in gran parte generata dall’autore dal
momento che non è possibile estrarla dal contenuto.
Utilizzo (Usage)
Metadati relativi all’uso del contenuto: caratteristiche
tipiche sono i proprietari dei diritti, i diritti di accesso,
pubblicazione, e le informazioni finanziarie. Tale
informazione è molto probabilmente soggetta a variazioni
nel ciclo di vita del contenuto multimediale.
Aspetti Strutturali
Descrizione del contenuto multimediale dal punto di vista
della sua struttura: la descrizione è strutturata intorno ai
segmenti che rappresentano i componenti fisici spaziali,
temporali o spazio-temporali del contenuto multimediale.
Ogni segmento può essere descritto da caratteristiche
basate sui segnali (signal based: come colore, texture,
forma, moto, e caratteristiche audio) e alcune elementari
informazioni semantiche.
Aspetti Semantici
Descrizione del contenuto multimediale dal punto di vista
della sua semantica e delle nozioni concettuali. Questo si
basa sui concetti di oggetti, eventi, concetti astratti e loro
relazioni.
Questi cinque insiemi di strumenti di descrizione sono stati presentati come entità
distinte. Come vedremo nel seguito, questi sono correlati e possono essere
parzialmente incluse in ogni altro. Per esempio gli elementi Media, Utilizzo o
pag. 62
Creazione e Produzione possono essere allegati a singoli segmenti coinvolti nella
descrizione strutturale del contenuto. A seconda dell’applicazione, alcune aree
della descrizione del contenuto possono essere enfatizzate ed altre possono essere
minimizzate o scartate.
Accanto alla diretta descrizione del contenuto fornita dai cinque insiemi di
strumenti di descrizione appena descritti, sono stati definiti anche strumenti per la
navigazione e l’accesso: il Browsing è supportato dagli strumenti di descrizione di
riassunto o “summary description tools” ed è anche fornita informazione circa le
possibili variazioni del contenuto. Variazioni del contenuto multimediale possono
sostituire l’originale, se necessario, per adattare diverse presentazioni
multimediali alle capacità dei terminali clienti, alle condizioni della rete o alle
preferenze dell’utente.
La tabella seguente riporta la terminologica considerata e ne specifica il
significato nell’ambito di Mpeg-7 MDS.
Terminologia Base
Descrizione
Datatype
indica un elemento di descrizione del dominio
multimediale e che corrisponde a un tipo di base
riutilizzabile
Descriptor (D)
indica un elemento di descrizione che rappresenta una
caratteristica multimediale o un attributo o un gruppo di
attributi di un’entità multimediale.
Description Schemes un elemento di descrizione che rappresenta entità o
(DS)
relazioni nel dominio multimediale. Uno Schema di
Descrizione possiede informazioni descrittive e può
partecipare a relazioni molti-a-uno con altri elementi di
descrizione
Audio-visivo (Audio- Si riferisce al contenuto che consiste sia in audio che
visual)
video
Caratteristica
(Feature)
Proprietà del contenuto multimediale che significa
qualcosa per un osservatore umano, come ad esempio il
colore “color” o la trama “texture”.
Multimedia
Fa riferimento al contenuto che comprende un contenuto
o sua modalità o tipi di contenuto, come immagini,
audio, video, modelli 3D, inchiostro elettronico, e altro.
pag. 63
4.2.2 GLI STRUMENTI BASE DELLO SCHEMA
Il primo elemento dei Basic Element, Schema Tools, specifica l’organizzazione
del tipo di gerarchia base dei Descriptors e dei Descriprion Schemes, gli elementi
di MPEG-7, sia a livello di radice che ad alto livello, i cosidetti “task-oriented”.
Oltre agli element radice e di alto livello, in questa parte si definiscono strumenti
di descrizione di diverse entità di contenuto multimediale che dovrebbero essere
usati in congiunzione con lo specifico tipo di livello superiore della descrizione
del contenuto per formare delle descrizioni complete di diversi tipi di contenuto
multimediale, come ad esempio immagini, video, audio, miscellanea
multimediale, collezioni, e così via.
Infine, viene specificato uno strumento Package che dovrebbe essere usato per
descrivere un’organizzazione dei Descriptors e dei Descrition Schemes per
un’applicazione, così come uno strumento Description Metadata da usare per
descrivere i metadati riguardanti la descrizione stessa.
Gli strumenti specificati in questa parte dell’MPEG-7 MCD sono indicati nella
tabella seguente.
Lista degli Schema Tools
Strumento
Funzionalità
Tipi di base (Base Forma la gerarchia di tipo base per gli strumenti di
Types)
descrizione – Descriptors, Descrition Schemes, e Header.
Elemento Radice Descrive il Wrapper (intestazione) iniziale o l’elemento
(Root Element)
radice dei documenti e delle unità di descrizione
(description units) che rappresentano istanze valide dello
schema.
Tipi di livello Forma i modelli di contenuto degli elementi di livello
superiore
(Top- superiore che seguono l’elemento radice per le descrizioni.
level Types)
Multimedia
Content Entities
Descrivono diversi tipi di contentuo multimediale come ad
esempio immagini, video, audio, loro combinazioni,
collezioni, e altro.
Packages
Descrivono un’organizzazione o confezionamento dei
Descriptors e Description Schemes per un’applicazione.
Description
Metadata
Descrivono i metadati riguardanti le descrizioni.
pag. 64
I concetti di elemento radice, elementi di livello superiore, elementi globali, tipi
globali, e altri concetti sono definiti come segue:
•
Schema valid description: una descrizione che è sintatticamente valida in
accordo con lo schema definito in ISO/IEC 15938-5.
•
Description document: una completa descrizione che è completa nel senso di
provvedere una completa, indipendente descrizione del contenuto
multimediale per un’applicazione.
•
Description unit: una unità di descrizione valida secondo lo schema e che
trasporta informazione parziale o aggiuntiva per un’applicazione. Le unità
descrittive possono essere usate in specifiche applicazioni dove il client
richiede in maniera additiva parti di una descrizione completa da un server.
Le “description units” possono anche essere usate nel contesto della
distribuzione in streaming delle descrizioni.
•
Root element (elemento radice): l’elemento iniziale di una istanza di
documento o una description unit valida secondo lo schema.
•
Top-level type (tipo di livello superiore): serve come intestazione di
definizione di strumenti per un particolare “task” di descrizione.
•
Top-level element (elemento di livello superiore): un elemento che
immediatamente segue l’elemento radice, che determina se la descrizione
fornisce una istanza di documento o una description unit validi secondo lo
schema.
•
Global element: un elemento dello schema che è dichiarato al livello globale.
•
Global Type: un modello o tipo di contenuto definito immediatamente
trasformando l’elemento <schema>.
•
Package: un’organizzazione di Descriptors e di Description Schemes che
impacchetta gli strumenti per un’applicazione.
E' possibile osservare nella figura seguente l’organizzazione gerarchica dei tipi di
base degli strumenti di descrizione.
Nella sottosezione Mpeg7RootType sono definiti i seguenti tipi di base:
•
Mpeg7RootType: fornisce il tipo astratto di base della gerarchia dei tipi.
Description Schemes, Descriptors e Header derivano da Mpeg7RootType.
L’elemento radice Mpeg7 contiene un elemento del tipo Mpeg7RootType.
o Dtype: estende Mpeg7RootType per fornire un tipo astratto di base per
Descriptors visuali e audio. Tutti gli Mpeg7 Descriptors si basano su
Dtype.
ƒ
VisualDType: estende Dtype per fornire un tipo astratto di
base per i Descriptors visuali. Tutti i “visual descriptors” che
devono essere usati nel descrivere segmenti visuali derivano da
VisualDType.
pag. 65
ƒ
AudioDType: estende Dtype per fornire un tipo astratto base
per i Descriptors Audio. Tutti i Descriptors audio che vengono
usati nella descrizione di segmenti audio derivano da
AudioType.
o DSType: estende Mpeg7RootType per fornire un tipo astratto base
per i Description Schemes visuali e audio. Tutti i Description Schemes
derivano da DSType.
ƒ
VisualDSType: estende DSType per fornire un tipo astratto
base per i Description Schemes di tipo “visual”. Tutti i
Description Schemes che sono usati nel descrivere i segmenti
visivi derivano da VisualDSType.
ƒ
AudioDSType: estende DSType per fornire un tipo astratto
base per i Description Schemes di tipo “audio”. Tutti i
Description Schemes audio che sono usati per descrivere
segmenti audio derivano da AudioDSType.
o HeaderType: estende Mpeg7RootType per fornire un tipo astratto
base per descrivere le intestazioni nelle descrizioni. L’intestazione è
destinata
a raccogliere l’informazione comune ai componenti
(chiamata “body part”) della descrizione e può essere istanziata senza
alcun elemento DSType
Figura 8 : ORGANIZZAZIONE DEI TIPI DI BASE DI MPEG7ROOTTYPE,
DSTYPE, DTYPE, E HEADERTYPE.
Mpeg-7 fornisce un elemento radice per ogni tipo di descrizione, da utilizzare
come elemento iniziale di una descrizione. Segue il listato con la definizione del
tipo dell’elemento radice Mpeg7.
pag. 66
Definizione di Mpeg7Type e dichiarazione dell’elemento Mpeg7
<!-- ################################################ -->
<!-- Definizione di Mpeg7Type
-->
<!-- ################################################ -->
<complexType name="Mpeg7Type" abstract="true">
<sequence>
<element name="DescriptionMetadata" type="mpeg7:DescriptionMetadataType"
minOccurs="0"/>
</sequence>
<attribute ref="xml:lang" use="optional"/>
</complexType>
<!-- ################################################ -->
<!-- Dichiarazione dell’elemento Mpeg-7
-->
<!-- ################################################ -->
<element name="Mpeg7">
<complexType>
<complexContent>
<extension base="mpeg7:Mpeg7Type">
<choice>
<element name="DescriptionUnit"
type="mpeg7:Mpeg7RootType"/>
<choice minOccurs="1" maxOccurs="unbounded">
<element name="ContentDescription"
type="mpeg7:ContentDescriptionType"/>
<element name="ContentManagement"
type="mpeg7:ContentManagementType"/>
</choice>
</choice>
<attribute name="type" use="default" value="descriptionUnit">
<simpleType>
<restriction base="string">
<enumeration value="descriptionUnit"/>
<enumeration value="complete"/>
</restriction>
</simpleType>
</attribute>
</extension>
</complexContent>
pag. 67
</complexType>
</element>
La semantica di Mpeg7Type:
Nome
Definizione
Mpeg7Type
Utilizzato come tipo dell’elemento radice di MPEG-7.
DescriptionMetadata
Descrive i metadati per le descrizioni contenute
all’interno dell’elemento radice (opzionale). I metadati
della descrizione si propagano (si applicano) alle
descrizioni contenute all’interno dell’elemento radice,
finchè non vengono specificati nuovi metadati della
descrizione per qualche parte interna.
xml:lang
Identifica il linguaggio del contenuto della descrizione
(è opzionale).
Identifica il tipo della descrizione. Questo attributo può
avere uno dei seguenti valori:
Type
descriptionUnit – la descrizione è una unità descrittiva
con una struttura valida.
complete – la descrizione è una descrizione completa
con una struttra valida secondo lo schema.
Il valore di default,
descriptionUnit.
ove
non
specificato,
è
I due tipi di descrizioni di schema validi sono: la descrizione completa di
documenti (complete), oppure quelle parzioali tramite istanze che portano
informazioni parziali o aggiuntive per un’applicazione, che sono chiamate unità di
descrizione o “description units”.
Vengono ora descritti i tipi di livello superiore, che vengono impiegati per la
definizione degli elementi ‘Top level’. Questi fanno la loro comparsa subito dopo
l’elemento radice Mpeg7 in un’istanza di documento valida secondo lo schema
Mpeg7 MDS. I tipi di livello superiore includono in maniera selettiva alcuni
strumenti dello schema che sono adatti ad alcuni compiti di descrizione specifici.
pag. 68
La semantica dell’elemento radice Mpeg7:
Nome
Definizione
Mpeg7
Fa da elemento radice di una descrizione.
DescriptionUnit
Descrive una istanza di uno degli strumenti Mpeg-7.
ContentDescription
Descrive dati multimediali o astrazioni di contenuto
multimediale
(opzionale).
ContentDescription
corrisponde al tipo di base astratto di differenti modelli
per la descrizione dei diversi tipi e astrazioni di
contenuto multimediale.
ContentManagement
Descrive la gestione dei dati multimediali (è opzionale).
ContentManagement corrisponde al tipo astratto di base
dei differenti modelli per la descrizione della gestione di
contenuto multimediale.
Figura 9 : DIAGRAMMA DELL’ELEMENTO RADICE MPEG7.
Vengono definiti i seguenti elementi "Top Level":
•
BasicDescription (astratto): fornisce la specifica di una base astratta per i
tipi di livello superiore ContentDescription e ContentManagement.
•
ContentDescription (astratto): fornisce la specifica di una base astratta per i
tipi di livello superiore ContentEntity e ContentAbstraction per la descrizione
di contenuto multimediale.
•
ContentEntity: fornisce un modello di contenitore per descrivere diversi tipi
di entità di contenuto multimediale come immagini, video, audio, collezioni,
etc.
•
ContentAbstraction (astratta): fornisce la specifica di una base astratta per
vari tipi di livello superiore per la descrizione di contenuti multimediali
pag. 69
(questi tipi sono WorldDescription; ModelDescription; SummaryDescription;
ViewDescription; VariationDescription)
•
ContentManagement (astratto): fornisce la specifica di una base astratta per i
tipi di livello superiore seguenti per la descrizione delle operazioni di gestione
dei contenuti multimediali:
•
UserDescription: fornisce un modello di contenitore per la descrizione di un
utente in un sistema multimediale.
•
CreationDescription: fornisce un modello di contenitore per la descrizione
del processo di creazione del contenuto multimediale.
•
UsageDescription: fornisce un modello di contenitore per la descrizione dei
modi d’uso di un contenuto multimediale.
•
ClassificationDescription: fornisce un modello di contenitore per la
descrizione di uno schema di classificazione relativo al contenuto
multimediale.
I tipi di livello superiore sono organizzati secondo la gerarchia mostrata nella
figura seguente.
B asic
D escriptio n
(astratto)
C ontent
D escriptio n
(astratto)
C ontent
E ntity
C ontent
M anag em ent
(astratto)
C ontent
A bstractio n
(astratto)
- UserD escription
- CreationDescription
- UsageDescription
- ClassificationDescription
Audio-Visual
- Imtaget
- W orldDescription
- V ideo
- Sum m aryDescription
- View Description
- A udio
- A udioV isual
- M ixedC ontent
- C ontentC ollection
Figura 10 :
- M odelDescription
- VariationDescription
ORGANIZZAZIONE DELLA GERARCHIA DEI TIPI PER I TIPI DI
LIVELLO SUPERIORE.
Gli elementi Mpeg7 utilizzano i tipi di livello superiore per ContentDescription e
ContentManagement. I tipi di dato BasicDescription costituiscono i tipi di dato
pag. 70
astratto base della gerarchia. Al di sotto di BasicDescription, i tipi di livello
superiore (top-level types nella documentazione originale) sono divisi in due
percorsi di derivazione: Content Description e Content Management.
ContentDescription descrive il contenuto multimediale e le sue astrazioni,
fornendo una specifica di base per i tipi top-level ContentEntity e
ContentAbstraction.
Nel listato finale dello schema MDS è possibile trovare tutte le definizione dei
tipi, e anche la sintassi del tipo ContentDescription.
La semantica di ContentEntityType:
Nome
Definizione
ContentEntityType
Descrive un contenuto multimediale.
MultimediaContent
Descrive l’istanza di un contenuto multimediale.
Figura 11 : DIAGRAMMA DI CONTENTENTITYTYPE
Da MultimediaContent derivano i diversi strumenti di descrizione che
corrispondono ad altrettanti diversi tipi di contenuto multimediale: immagini,
video, audio, audiovisivi, mix di contenuti multimediali, programmi e segnali.
Analizziamo ora la semantica di MultimediaContentType e dei tipi derivati di
nostro interesse per l’applicazione oggetto di studio.
Nelle tabelle sequenti viene definito MultimediaContentType, quindi i tipi e dli
elementi che possono essere instanziati. Tra questi troviamo:
pag. 71
VideoType:
Nome
Definizione
VideoType
Descrive un video.
Video
Descrive un’istanza di un video.
AudioType:
Nome
Definizione
AudioType
Descrive l’audio.
Audio
Descrive un’istanza di contenuto audio.
AudioVisualType:
Nome
Definizione
AudioVisualType
Descrive contenuto audiovisivo.
AudioVisual
Descrive un’istanza di contenuto audiovisivo.
Nello schema MultimediaType sono inoltre presenti MultimediaCollectionType,
MultimediaProgramType, SignalType, ElectronikInkType, VideoEditingType
sempre derivati da MultimediaContentType.
Il seguente esempio illustra l’uso di MultimediaContent per la creazione della
descrizione di un audiovisivo. In seguito è riportato il codice xml che definisce i
MultimediaContent DS di interesse.
pag. 72
Sintassi di MultimediaContent DS
<!-- ################################################################ -->
<!-- Definizione dei Multimedia Content Entity DSs di interesse -->
<!-- ################################################################ -->
<complexType name="MultimediaContentType" abstract="true">
<complexContent>
<extension base="mpeg7:DSType">
</extension>
</complexContent>
</complexType>
<!-- . . . segue . . . -->
<!-- il codice completo si trova nel listato di MDS Schema -->
<!--
presente in appendice
-->
<!-- . . . segue . . . -->
<complexType name="AudioVisualType">
<complexContent>
<extension base="mpeg7:MultimediaContentType">
<sequence>
<element name="AudioVisual"
type="mpeg7:AudioVisualSegmentType"/>
</sequence>
</extension>
</complexContent>
</complextype>
L'elemento principale della parte di Content Description è il Segment DS che
indirizza la descrizione degli aspetti fisici e logici del contenuto audiovisuale. I
Segment DSs possono essere usati per formare strutture ad albero dei segmenti.
Un segmento rappresenta una sezione di un istanza di contenuto audiovisivo. Il
Segment DS è definito come una classe astratta (nel senso della programmazione
ad oggetti) ed ha nove sotto classi principali: Multimedia Segment DS,
AudioVisual Region DS, AudioVisual Segment DS, Audio Segment DS, Still
Region DS, Still Region3D DS, Moving Region DS, Video Segment DS e Ink
Segment DS.
Ogni segmento può essere descritto da informazioni sulla sua creazione (Creation
Information), sull'uso (Usage Information), sul media (Media Information) e da
annotazioni testuali (Textual Annotation), ed inoltre un segmento può essere
decomposto in sotto-segmenti attraverso Segment Decomposition DS.
Il description scheme di tipo astratto Segment DS è ricorsivo e può essere
suddiviso in sottosegmenti e questi possono formare una gerarchia (struttura ad
albero). La struttura ad albero dei segmenti che ne risulta viene utilizzata per
pag. 73
definire il media sorgente, e la struttura temporale e/o spaziale del contenuto
audiovisivo.
Per esempio un programma video può essere segmentato temporalmente in vari
livelli di scene, shots, e microsegmenti; una tavola dei contenuti può essere
generata basandosi su questa struttura. E strategie simili possono essere usate per i
segmenti spaziali e spazio-temporali.
Un segmento può inoltre essere suddiviso in vari media sorgenti come per
esempio diverse tracce audio o vari punti di vista da diverse inquadrature. La
suddivisione gerarchica è utile per delineare efficienti strategie di ricerca (ricerche
globali o ricerche locali) e permette inoltre alla descrizione di essere scalabile: un
segmento può essere descritto dal suo diretto set di descrittori e DSs (schemi di
descrizione) ma può anche essere descritto dall'unione dei descrittori e delle DSs
relativi ai suoi sottoelementi. Da notare è che un segmento può essere suddiviso in
diversi sottosegmenti di diverso tipo, per esempio un segmento video può essere
decomposto in regioni in movimento che possono essere a loro volta decomposte
in regioni statiche.
Nell’ambito di questo lavoro si fa riferimento al tipo di dato complesso
AudioVisualType, che, come possiamo vedere dal codice che lo definisce (in xml
secondo il linguaggio DDL di Mpeg-7) istanzia un elemento “AudioVisual” di
tipo AudioVisualSegmentType.
Nel seguente listato è riportata la sintassi di AudioVisualSegment DS.
Sintassi di AudioVisualSegment DS
<!-- ############################################### -->
<!--
Definizione di AudioVisualSegment DS
-->
<!-- ############################################### -->
<complexType name="AudioVisualSegmentType">
<complexContent>
<extension base="mpeg7:SegmentType">
<sequence>
<element name="MediaTime" type="mpeg7:MediaTimeType"
minOccurs="0"/>
<element name="TemporalMask" type="mpeg7:TemporalMaskType"
minOccurs="0"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="SpatialDecomposition"
type="mpeg7:AudioVisualSegmentSpatialDecompositionType"/>
<element name="TemporalDecomposition"
type="mpeg7:AudioVisualSegmentTemporalDecompositionType"/>
<element name="SpatioTemporalDecomposition"
type="mpeg7:AudioVisualSegmentSpatioTemporalDecompositionType"/>
pag. 74
<element name="MediaSourceDecomposition"
type="mpeg7:AudioVisualSegmentMediaSourceDecompositionType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
La semantica di AudioVisualSegmentType è riportata nella tabella successiva.
Nome
Definizione
AudioVisualSegmentType
Descrive un intervallo temporale o un segmento di
informazione
audiovisiva,
che
corrisponde
all’insieme di campioni audio e frames video nello
stesso intervallo temporale o segmento (il segmento
audiovisivo può anche non essere connesso
temporalmente).
MediaTime
Descrive la localizzazione temporale del segmento
audiovisivo attraverso la specifica del tempo di inizio
e della durata del segmento. Se il segmento non è
connesso temporalmente, la durata dovrebbe essere
pari o maggiore alla somma delle durate dei segmenti
temporali connessi all’interno del segmento
audiovisivo complessivo.
L’elemento MediaTime include a sua volta un
elemento
MediaTimePoint
e
un
elemento
MediaDuration opzionale.
TemporalMask
Descrive la composizione di componenti connessi
che formano un segmento audiovisivo non-connesso
(è opzionale).
Se è assente, il segmento è composto dal solo
intervallo connesso nel tempo definito dall’elemento
MediaTime.
Se presente, il segmento fa riferimento all’insieme di
sotto intervalli non sovrapposti nel tempo definiti
dall’elemento TemporalMask.
SpatialDecomposition
Descrive una decomposizione spaziale del segmento
pag. 75
Nome
Definizione
audiovisivo in uno o più sotto-segmenti (opzionale).
TemporalDecomposition Descrive una decomposizione temporale del
segmento audiovisivo in uno o più sotto-segmenti
(opzionale).
SpatioTemporalDecomposition
Descrive una decomposizione spazio-temporale del
segmento audiovisivo in uno o più sotto-segmenti
(opzionale).
MediaSourceDecomposition
Descrive una decomposizione in sorgenti di diversi
media del segmento audiovisivo in uno o più sottosegmenti (opzionale).
Figura 12 : DIAGRAMMA DI AUDIOVISUALSEGMENTTYPE.
pag. 76
Nel seguente esempio viene illustrato l’uso di AudioVisualSegment DS per la
descrizione di un segmento audiovisivo costituito da due tracce audio ed una
traccia video. In questo esempio, il segmento audiovisivo Domenica_In_AVS
rappresenta l’intera sequenza video che è scomposta in due segmenti audio,
Domenica_In _Track1AS e Domenica_In _Track2AS, e una sequenza video,
TelegiornaleTG1_VS, che corrispondono rispettivamente alle sorgenti audio e
video. Ogni segmento è connesso nel tempo e/o nello spazio.
<!-— Esempio di decomposizione temporale del segmento audiovisivo -->
<!-- chiamato Domenica_In _AVS -->
<AudioVisualSegment id=" Domenica_In _AVS">
<TextAnnotation>
<FreeTextAnnotation> Varietà televisivo nazionale </FreeTextAnnotation>
</TextAnnotation>
<MediaTime>
<MediaTimePoint>T00:00:00</MediaTimePoint>
<MediaDuration>PT1H20M30S</MediaDuration>
</MediaTime>
<!-- descrizione di MediaSourceDecomposition:
Domenica_In _AVS è la sorgente scomposta in segmenti video e audio:
* Domenica_In _VS: start = 0:0:0, duration =1 h, 20 mins, 30 secs
* Domenica_In _AS: start = 0:0:0, duration =1 h, 20 mins, 30 secs-->
<MediaSourceDecomposition gap="false" overlap="false">
<VideoSegment id=" Domenica_In _VS ">
<MediaTime>
<MediaTimePoint>T00:00:00</MediaTimePoint>
<MediaDuration>PT1H20M30S</MediaDuration>
</MediaTime>
<GOFGOPColor> ... </GOFGOPColor>
</VideoSegment>
<AudioSegment id=" Domenica_In _Track1AS">
<MediaTime>
<MediaTimePoint>T00:00:00</MediaTimePoint>
<MediaDuration>PT20M30S</MediaDuration>
</MediaTime>
</AudioSegment>
<AudioSegment id=" Domenica_In _Track2AS">
<MediaTime>
<MediaTimePoint>T00:20:30</MediaTimePoint>
pag. 77
<MediaDuration>PT1H0M0S</MediaDuration>
</MediaTime>
</AudioSegment>
</MediaSourceDecomposition>
</AudioVisualSegment>
4.2.3 DECOMPOSIZIONI STRUTTURALI DEI SEGMENTI
Questa parte specifica gli strumenti per la descrizione delle decomposizioni
strutturali dei segmenti.
Come abbiamo accennato in precedenza, il Segment DS può essere suddiviso in
sottosegmenti e questi possono formare una gerarchia (struttura ad albero). La
struttura ad albero dei segmenti che ne risulta viene utilizzata per definire il
media sorgente, e la struttura temporale e/o spaziale del contenuto audiovisivo. A
seconda del tipo di decomposizione si intende adottare, cambiano gli strumenti di
descrizione.
La figura in basso mostra l'organizzazione degli strumenti per la descrizione delle
decomposizioni strutturali dei segmenti.
Segment
Decomposition DS
(abstract)
SpatialSegment
Decomposition DS
(abstract)
StillRegionSpatialDecomposition DS
StillRegion3DSpatialDecomposition DS
VideoSegmentSpatialDecomposition DS
MovingRegionSpatialDecomposition DS
AudioVisualSegmentSpatialDecomposition DS
TemporalSegment
Decomposition DS
(abstract)
VideoSegmentTemporalDecomposition DS
MovingRegionTemporalDecomposition DS
InkSegmentTemporalDecomposition DS
AudioSegmentTemporalDecomposition DS
AudioVisualSegmentTemporalDecomposition DS
AudioVisualRegionTemporalDecomposition DS
AnalyticEditedVideoSegmentTemporalDecomposition DS
MediaSource
SegmentDecomposition DS
(abstract)
SpatioTemporal
SegmentDecompositio
n
VideoSegmentMediaSourceDecomposition DS
MovingRegionMediaSourceDecomposition DS
InkSegmentMediaSourceDecomposition DS
AudioSegmentMediaSourceDecomposition DS
AudioVisualSegmentMediaSourceDecompositio
n DS
MultimediaSegmentMediaSourceDecomposition
VideoSegmentSpatioTemporalDecomposition DS
MovingRegionSpatioTemporalDecomposition DS
AudioVisualSegmentSpatioTemporalDecomposition DS
AudioVisualRegionSpatioTemporalDecomposition DS
AnalyticEditedVideoSegmentSpatioTemporalDecomposition DS
Figura 13 : VISIONE GENERALE DEGLI STRUMENTI PER LA
DECOMPOSIZIONE DEI SEGMENTI.
pag. 78
Il SegmentDecomposition DS è un tipo astratto che descrive una decomposizione
gerarchica di un segmento.
Il SpatialSegmentDecomposition DS, il
TemporalSegmentDecomposition DS, lo SpatioTemporalSegmentDecomposition
DS ed il MediaSourceSegment-Decomposition DS sono SegmentDecomposition
specializzati e sono definiti come tipi astratti che descrivono decomposizioni
spaziali, temporali, spatio-temporali e di media sorgente rispettivamente.
Possono, inoltre, descrivere le decomposizioni gerarchiche ad albero di segmento
tale da formare un indice di contenuti per il video.
Di seguito si definisce la semantica di SegmentDecompositionType.
Name
Definition
SegmentDecompositionType
Questo tipo è il tipo astratto che descrive una
decomposizione gerarchica di un segmento.
Una decomposizione di segmento richiede che
l'unione dei limiti definiti dai sub-segments non
si estende oltre i limiti definiti dal segmento del
genitore.
Criteria
Indica il criterio usato nella decomposizione di
segmento (facoltativa). Per esempio, il criterio
poteva essere "color" o " camera motion and
texture ".
Overlap
Indica se i segmenti che derivano dalla
decomposizione di segmento coincidono o
meno a tempo e/o lo spazio. Il valore dell’
attributo di default è "falso".
Gap
Indica se i segmenti che derivano dalla
decomposizione di segmento lasciano gap
rispetto
al
segmento
genitore.
Una
decomposizione di segmento si dice che ha un
gap se l'unione dei sub-segments decomposti
del figlio non corrisponde esattamente al
segmento genitore. Il valore di questo attributo
è "falso" di default.
Semantica di TemporalSegmentDecompositionType:
Name
Definition
TemporalSegmentDecompositionType
E' un tipo astratto che descrive una
decompositione temporale
pag. 79
Semantics of the MediaSourceSegmentDecompositionType:
Name
Definition
MediaSoruceSegmentDecompositionType
E' un tipo astratto che descrive una
decompositione dal punto del
media.
Il SegmentDecomposition DSs specializzato descrive la decomposizione ricorsiva
di un segmento che può formare una gerarchia dell'albero dei segmenti. Per
esempio, la descrizione dell'albero di segmento di un video è in grado di
descrivere la segmentazione temporale gerarchica del video in scene, nei shot e
nei sub shot per formare un indice basato sulla struttura relativa. Il
SegmentDecomposition DSs specializzato inoltre descrive la decomposizione di
un segmento in diverse tracce, per esempio si consideri il contenuto multimediale
che contiene le tracce audio multiple per stereo surround e tracce video multiple
per differenti punti di vista della macchina fotografica.
Il SegmentDecomposition DSs specializzato può descrivere la decomposizione
del contenuto multimediale nelle diverse fonti audio e video dei media. Sono
previsti quattro tipi di base di decomposizioni di segmento, cioè, spaziale,
temporale, spatio-temporale e di media source, definiti come tipi derivati di
SegmentDecomposition
DS:
lo
SpatialSegmentDecomposition,
il
TemporalSegmentDecomposition, lo SpatioTemporalSegmentDecomposition ed
il
MediaSourceSegmentDecomposition
DSs,
rispettivamente.
Nelle
decomposizioni temporali il SegmentDecomposition DS richiede di verificare le
dimensioni dal segmento figlio rispetto a quelle del segmento genitore. Per
esempio, nella decomposizione temporale del segmento genitore nella la figura
18.a in tre segmenti figli, i segmenti figli non si estendono oltre l'intervallo
temporale specificato per il segmento genitore. Tuttavia, la decomposizione di un
segmento può avere le lacune o sovrapposizioni fra i segmenti derivando dalla
decomposizione come segue:
a) No gaps, no overlaps
b) No gaps, overlaps
c) Gaps, no overlaps
d) Gaps, overlaps
La figura 18 mostra esempi di esposizioni delle decomposizioni dei segmenti
temporali che illustrano i concetti delle lacune e delle sovrapposizioni.
La figura 18.a e la figura 18.b descrivono le decomposizioni che non hanno le
lacune o sovrapposizioni. In entrambi i casi l'unione dei sub-segmenti figli
corrisponde esattamente al segmento genitore e l'intersezione fra i sub-segmenti
del bambino è vuota. Ciò si applica anche in questo caso come appare la figura
18.b, in cui il genitore non è collegato con se stesso. La figura 18.c mostra una
decomposizione con le lacune ma nessun sovrapposizioni. Per concludere, la
pag. 80
figura 18.d illustra un caso più complesso dove il genitore si compone di due
componenti collegati ed è decomposto con le lacune e le sovrapposizioni dei tre
figli: il primo è composto di due componenti collegati, mentre i due figli restanti
si compongono di singolo segmento collegato. Questi esempi inoltre dimostrano il
fatto che la connettività di segmento è indipendente dalla decomposizione di
segmento: un segmento non-collegato può essere decomposto senza le lacune e un
segmento collegato può essere decomposto con le lacune.
Segmento padre: segmento unico
Segmento padre:due segmenti connessi
Tempo
Tempo
seg.Padre.
seg.Padre.
seg. figlio
seg. figlio
a)
c)
Decomposizione in 3 segmenti senza
gap ne overlap
b)
Decomposizione in 4 segmenti senza
gap ne overlap
Tempo
Tempo
seg.Padre
seg.Padre
seg. figlio.
seg. figlio.
Decomposizione in 3 segmenti con
gap ma senza overlap
Decomposizione in 3 segmenti con
gap e overlap
d)
Figura 14 : ESEMPIO DI DECOMPOSIZIONI TEMPORALI: A) E B)
DECOMPOSIZIONI SENZA GAPS O OVERLAPS; C) E D) DECOMPOSIZIONI
CON GAPS O OVERLAPS.
Si noti che un segmento può essere decomposto in uno o più sub-segmenti di tipi
differenti, per esempio un video segmento può essere decomposto nelle still
regions and moving regions , che possono essere decomposte nelle still regions
allo stesso tempo. Tuttavia, non tutte le combinazioni del tipo di segmento
genitore, del tipo di decomposizione e del tipo di segmento figlio sono valide.
Per esempio, un segmento audio può essere decomposto soltanto nel tempo o nel
media in altri segmenti audio; la decomposizione spaziale di un segmento audio
nelle still regions è non valida. Un altro esempio una still region può essere
decomposta soltanto nello spazio in altre still region incluse i testi di immagine. Il
pag. 81
Mosaic DS è un caso speciale di StillRegion DS, che non può essere il risultato di
alcuna decomposizione di segmento.
Gli strumenti di decomposizione di un segmento AV si estendono da quelli base
di decomposizione di segmento. Gli strumenti di decomposizione di segmento
AV descrivono la decomposizione di un segmento AV in uno o più sub-segments
nello spazio, nel tempo, o in entrambe o e nel media source.
Sintassi degli strumenti di decomposizione degli AudioVisual Segment:
<!-- ######################################################### -->
<!-- Definizione di AudioVisualSegmentTemporalDecomposition DS -->
<!-- ######################################################### -->
<complexType name="AudioVisualSegmentTemporalDecompositionType">
<complexContent>
<extension base="mpeg7:TemporalSegmentDecompositionType">
<choice minOccurs="1" maxOccurs="unbounded">
<element name="AudioVisualSegment"
type="mpeg7:AudioVisualSegmentType"/>
<element name="AudioVisualSegmentRef"
type="mpeg7:ReferenceType"/>
<element name="AudioVisualRegion"
type="mpeg7:AudioVisualRegionType"/>
<element name="AudioVisualRegionRef"
type="mpeg7:ReferenceType"/>
</choice>
</extension>
</complexContent>
</complexType>
<!-- ################################################################ -->
<!-- Definizione di AudioVisualSegmentMediaSourceDecomposition DS
-->
<!-- ################################################################ -->
<complexType name="AudioVisualSegmentMediaSourceDecompositionType">
<complexContent>
<extension base="mpeg7:MediaSourceSegmentDecompositionType">
<choice minOccurs="1" maxOccurs="unbounded">
<element name="AudioVisualSegment"
type="mpeg7:AudioVisualSegmentType"/>
pag. 82
<element name="AudioVisualSegmentRef"
type="mpeg7:ReferenceType"/>
<element name="VideoSegment"
type="mpeg7:VideoSegmentType"/>
<element name="VideoSegmentRef"
type="mpeg7:ReferenceType"/>
<element name="AudioSegment"
type="mpeg7:AudioSegmentType"/>
<element name="AudioSegmentRef"
type="mpeg7:ReferenceType"/>
</choice>
</extension>
</complexContent>
</complexType>
4.3 ESTRAZIONE DELLE INFORMAZIONI
La risorsa audiovisiva scelta per la nostra descrizione è un telegiornale.
L'obbiettivo principale è, secondo le problematiche di documentezione dagli
archivi Rai, la possibilità di riuscire a catalogare ogni sottosequenza logica
importante del contenuto audiovisivo preso come esempio (es. Servizio), così da
poter ricercarle individualmente e in un secondo momento riutilizzarle. Nella
definizione di una struttura dati Mpeg-7 MDS adatta allo scopo si è individuato
come fondamentale la necessità di riconoscere gli strumenti per l’identificazione e
localizzazione della risorsa base memorizzata in un archivio digitale. Gli
strumenti di Mpeg-7 consentono , quindi, di fare riferimento direttamente ai files
audiovisivi codificati in MPEG.
La catalogazione verrà effettuata sul contenuto del singolo servizio, dando una
completa descrizione con diversi livelli di astrazione. Saranno presenti sia
informazione necessarie per identificare l'intero programma televisivo ( il
Telegiornale) sia una descrizione delle singole sequenze.
4.3.1 MODALITÀ DI ESTRAZIONE
Per la descrizione della risorsa audiovisiva è stato scelto Movie Tool, nato per
aiutare ricercatori o disegnatori di applicazioni Mpeg7. Movie Tool è uno
strumento in fase di primo rilascio per la sperimantazione in grado di per creare
descrizioni di un contenuto video conforme alla sintassi Mpeg7. Ricoh vuole in
questo modo contribuire all’avanzamento delle attività di ricerca relative a Mpeg7
e incoraggiarne l’uso distribuendo Movie Tool alla comunità di Mpeg7, per
supportare ricercatori o disegnatori di applicazioni Mpeg7.
Usando MovieTool, l'utente (amministratore o documentatori di archivi digitale)
può generare la struttura logica di descrizione mentre visiona il video. Inoltre si
pag. 83
hanno funzioni per editare file XML contenenti la descrizione Mpeg-7. Sarà
necessario inserire manualmente tutte le informazioni riguardanti il contenuto,
l’utilizzo e la produzione della risorsa audiovisiva grazie all'aiuto di un Mpeg7
editor che permette di aggiungere altri descrittori secondo lo schema MDS.
Le informazioni che possono essere ricavate in modo automatico sono gli
intervalli temporali generati dalla segmentazione video, la struttura di
decomposizione del video e le informazioni sul profilo del media.
Un vantaggio importante nell’integrare MovieTool in questa fase di sviluppo è
che il documentatore può vedere rapidamente e facilmente la corrispondenza fra
le descrizioni Mpeg-7 e la struttura di ogni sequenza video. Le descrizioni
possono essere aggiunte per ogni sequenza e diventare parti del file Mpeg-7.
Inoltre è possibile caricare un'istanza Mpeg-7 conforme allo Schema e
visualizzarne la struttura logica, cioè il modo in cui si è descritto un particolare
contenuto video.
Si elencano di seguito tutte le funzionalità ricercate in questa integrazione:
•
La generazione di una descrizione Mpeg-7 al caricamento di file video.
•
L'ottenimento di indizi visivi per aiutare l'utente nella generazione della
struttura del video.
•
·Inserimento automatico della struttura nella descrizione Mpeg-7.
•
·Assistenza visiva nel mostrare le relazioni fra la struttura e la descrizione
Mpeg-7.
•
Scelta tra diverse etichette Mpeg-7 disponibili.
•
·Controllo della convalida delle descrizioni Mpeg-7 in conformità con lo
schema Mpeg-7.
•
Possibilità di descrivere tutti i metadati definiti in Mpeg-7.
•
Capacità di accoglire tutti i cambiamenti ed estensioni futuri fatti per lo
schema Mpeg-7.
Nella figura viene illustrato il componente Composer Window in cui si possono
visualizzare tre diversi aspetti dello stesso file Mpeg:
pag. 84
Figura 15 : COMPOSER WINDOW
Le informazioni fisiche del file (per esempio dimensioni e formato del file) sono
visualizzate nella Physical File View. Il valore dell'attributo “criteria”
AudioVisualSegmentMediaSourceDecompositionType è in questo caso
“physical”.
Le informazioni sulla struttura logica di un video sono visualizzate nella `Logical
Structure File View’. Il punto importante è che il valore dell'attributo “criteria” di
AudioVisualSegmentTemporalDecompositionType è "structure" e questo
elemento ha Audio-VisualSegmentType come elemento figlio. In MovieTool, la
struttura gerarchica di descrizione è individuata tramite l’ uso ricorsivo di
AudioVisualSegmentTemporalDecompositionType
e
di
AudioVisualSegmentType (in figura abbiamo tre livelli gerarchici B,C e D ).
E' possibile accedere ad informazioni sui frame chiave, visualizzate nella `Spatial
Key View’. Fondamentale notare che il valore dell'attributo "criteria"
VideoSegmentTemporalDecomposi-tionType è “spatialkey” ed il rapporto fra il
frame
chiave
e
la
struttura
logica
è
descritto
usando
BinaryOtherSegmentRelationType e BinaryTemporalSegmentRelation Type.
pag. 85
Figura 16 : COMPOSER WINDOW
Dopo aver caricato un file video nella Composer Window, si può segmentarlo e
visualizzarne l'operazione, come mostrato nella figura precedente.
Abbiamo vari livelli nella struttura logica. Il primo di questo rappresenta l'intero
video senza modifiche alcune. I livelli inferiori indicano quali modifiche sono
state apportate alla struttura logica del file Mpeg.
Per generare una tal struttura, MovieTool fornisce le seguenti funzioni:
•
Segmentazione automatica basata sul confronto della caratteristica dei
singoli frame all'interno di una scena.(cambio scena)
•
Segmentazione manuale mentre si osservava il video.·
•
Segmentazione basata sulle informazioni posizionali quali il numero di
frame o il tempo della struttura.
E' possibile, quindi, operare una qualsiasi segmentazione video e generare in
maniera assistita il documento Mpeg7, in quanto il componente interpreterà
automaticamente la struttura logica generata come descrizione Mpeg-7. In
riferimento alla figura 21 a destra c’è la descrizione Mpeg-7, a sinistra c’è lo
schema che definisce la sintassi Mpeg-7. Con questo avanzato software è
possibile documentatore di cambiare la struttura logica di descrizione nella Video
Composer Window, di visualizzare subito il documento Mpeg-7 senza dovere
riferirsi ai particolari della sintassi Mpeg-7.
pag. 86
Figura 17 : MPEG-7 EDITOR WINDOW
Quando la descrizione è completa, il file è conservato come un file Mpeg-7 con
una estensione "xml". Mpeg-7 fornisce un'ampia varietà di tag per risolvere tutte
le circostanze possibili. La sintassi per questi tag è data nel file dello schema
Mpeg-7. Il tool integrato può inoltre rispondere ai cambiamenti futuri o
espansioni allo schema Mpeg-7. Questo rappresenta un importante passo avanti
nello sviluppo di un progetto che nella sua prima fase non prevedeva la codifica
da estrazione assistita o semiautomatica di informazioni Mpeg-7.
4.4 GENERAZIONE DEL DOCUMENTO MPEG-7
Sulla base delle argomentazioni affrontate è stato costruito un primo esempio di
descrizione che potrà servire da base per le possibili estensioni utili allo sviluppo
di un archivio di contenuti audiovisivi secondo le esigenze riscontrate
nell’ambiente applicativo della Teca Fast Rai. Tale esempio di descrizione è stato
applicato a tre telegiornali trasmessi e codificati dalle reti nazionali RAI. La
struttura gerarchica del documento Mpeg-7, come viene interpretata da Movie
Tool nella Composer Window, è mostrata in figura.
pag. 87
Figura 18 : DESCRIZIONE DELLA DDL (DESCRIPTION DEFINITION
LANGUAGE) DI MPEG-7 IN MOVIE TOOL
La figura di seguito mostra in modo particolareggiato la struttura del documento
di descrizione Mpeg-7 del programma televisivo (Telegiornale) preso in esame:
pag. 88
Figura 19 : SCHEMA SEMPLIFICATO CHE ILLUSTRA LA STRUTTURA DATI
AD ALBERO PER LA DESCRIZIONE BASATA SU METADATI DEL
PROGRAMMA CREATO.
Facendo riferimento all’introduzione fatta sui tipi di dato, i descrittori e i DS
(description schemes) base impiegati da Mpeg-7 MDS Schema, vediamo ora nel
dettaglio i singoli strumenti di descrizione che sono stati implementati nella
costruzione della struttura dati del documento.
4.4.1 L’ELEMENTO DESCRIPTIONMETADATA
Partendo dall’elemento radice analizziamo tutta la struttura e il tipo di
informazioni che sono state inserite. Dopo l’elemento radice MPEG7, si trova
l’elemento DescriptionMetadata.
pag. 89
Figura 20 : STRUTTURA DATI DEL DOCUMENTO DI DESCRIZIONE:
DETTAGLIO DELL'ELEMENTO DESCRIPTIONMETADATA
DescriptionMetadata fa riferimento a DescriptionMetadata DS per descrivere le
informazioni riguardanti la descrizione stessa (metadati sui metadati).
Il DescriptionMetadata DS può essere inserito in uno strumento di descrizione nel
modo mostrato nello schema di figura, e riporta informazioni riguardanti
l’identificazione della descrizione (privata o pubblica), la creazione della
descrizione, e i diritti associati alla descrizione stessa (che diventa un contenuto di
valore).
La semantica di DescriptionMetadata DS viene riportata nella seguente tabella.
pag. 90
Nome
Descrizione
Version
Specifica la versione della descrizione alla quale questo DS
viene allegato. Il formato per l’informazione di versione è
dipendente dal tipo di applicazione (e comunque opzionale).
LastUpdated
Specifica l’istante in cui è stato aggiornato per l’ultima volta
l’informazione di descrizione alla quale questo DS viene
allegato (è opzionale).
Comment
Descrive i commenti riguardo alla descrizione a cui viene
allegato tale DS, utilizzando una annotazione di tipo testuale
(Opzionale).
PublicIdentifier
Identifica la descrizione alla quale viene allegato questo DS
utilizzando un identificatore pubblico, unico a livello globale
(è opzionale).
Questo identificatore può essere usato per identificare
univocamente le descrizioni e non dipende dal file o dal
flusso in cui la descrizione compare, o ogni altro
incorporamento fisico di metadati. Diversi identificatori
pubblici possono essere associati ad una descrizione.
Creator
Descrive un autore della descrizione cui viene alegato questo
DS (è opzionale).
Questo può essere una persona, un’organizzazione, o
un’applicazione software che genera automaticamente i
metadati. Diversi creatori sono consentiti se i metadati sono
stati creati come risultato della cooperazione di diversi
soggetti.
CreationLocation
Descrive la località in cui la descrizione cui è allegato tale
DS è stata creata.
CreationTime
Descrive l’istante in cui la descrizione cui tale DS è allegato
è stata creata.
Instrument
Le apparecchiature/procedure e I parametri di settaggio
utilizzati per la creazione dei metadati, così come gli
strumenti utilizzati per l’estrazione dei metadati o i parametri
di estrazione (è opzionale).
Rights
Descrive I diritti associati con la descrizione cui tale DS
(Description Metadata DS) è allegato e come tale descrizione
può essere utilizzata (è opzionale).
pag. 91
Il codice implementato nel documento
DescriptionMetadata nel seguente listato:
è
visibile
per
la
parte
di
<DescriptionMetadata id="descriptionMetadata-36">
<Comment>
<FreeTextAnnotation>Descrizione delle
contenuto audiovisivo di un telegiornale RAI</FreeTextAnnotation>
informazioni
descrittive
del
</Comment>
<Creator>
<Agent xsi:type="PersonType" id="agent-37">
<Name>
<GivenName>Donato Biscaglia
</GivenName>
</Name>
</Agent>
<Instrument>
<Tool id="tool-38"
href="urn:ricoh:mmVISION:DescriptionToolCS:2">
<Name>MovieTool</Name>
</Tool>
</Instrument>
</Creator>
<CreationTime>2002-06-10T11:13:00:000:00</CreationTime>
</DescriptionMetadata>
4.4.2 L’ELEMENTO MEDIALOCATOR: LOCALIZZAZIONE TEMPORALE
E FISICA DELL’AUDIOVISIVO.
Il descrittore MediaLocator è stato inserito per contenere le informazioni sulla
localizzazione temporale o fisica della risorsa multimediale.
Come mostrato in precedenza, il primo degli elementi figli di AudioVisual, nella
struttura dati costruita per il prototipo, è MediaLocator, nel quale vengono
racchiuse informazioni sulla localizzazione temporale dell'intero telegiornale
come la data e l’ora di trasmissione sulla rete nazionale pubblica (uno dei tre
canali televisivi RAI ad esempio). In seguito verrà utilizzato per collegare
fisicamente il contenuto multimediale, come l’indirizzo del server dove risiede la
risorsa fisica.
pag. 92
Figura 21 : STRUTTURA DATI DEL DOCUMENTO DI DESCRIZIONE:
DETTAGLIO DELL'ELEMENTO MEDIALOCATOR
Le informazioni di inizio trasmissione (data e ora) e sulla locazione fisica della
sequenza sono fondamentali per l’individuazione della risorsa attraverso gli
attuali sistemi di richiesta audiovisivi all’interno degli archivi RAI.
In particolare per specifica di progetto dettata dai responsabili dell’archivio
digitale Teca Fast le due informazioni temporali di time code di inizio e data di
trasmissione sono necessarie per poter effettuare una richiesta del programma
individuato attraverso una connessione intranet al sistema Teca Fast (assieme
all’altra informazione fondamentale dell’identificatore del canale televisivo sul
quale è stato trasmesso il programma).
In questo particolare caso il descrittore è utilizzato per indicare le informazioni di
inizio trasmissione (data e ora). Come si vedrà in seguito , quando si analizzerà la
struttura logica (divisione in sequenze), MediaLocator potrà indicare invece
l’indirizzo del server dove risiede la risorsa fisica.
pag. 93
L’elemento AudioVisual consente di istanziare un elemento figlio proprio di tipo
MediaLocator, che risulta quindi molto utile per l’identificazione ad un livello
gerarchico sufficientemente elevato di queste informazioni fondamentali.
Media Locators
Per collegare fisicamente le descrizioni al contenuto in generale, un meccanismo
di riferimento denominato il MediaLocatorType è specificato. Il MediaLocator
permette di riferirsi alla descrizione del media con due meccanismi: il MediaUri
ed l'InlineMedia. Il MediaUri è usato per individuare un media esterno, mentre l'
InlineMedia include il contenuto in se stesso. Nel caso di una localizzazione del
media esterno dal MediaUri lo StreamID può essere specificato per identificare un
flusso all'interno del contenuto multimediale.
Per localizzare temporalmente la risorsa audiovisiva si utilizza
il
TemporalSegmentLocatorType che può instaziare ulteriormente MediaTime o
BytePosition per individuare le parti del media. Inoltre una combinazione di
TemporalSegmentLocatorType può essere usata per localizzare i segmenti di
audiovisivi.
Analizziamo la semantica di MediaLocatorType e di TemporalSegmentLocator
Datatype che è considerata un espansione di MediaLocator Datatype.
Semantica di MediaLocatorType:
Nome
Definizione
MediaLocatorType
Specifica la posizione del media. La posizione del media
può essere o specificata facendo riferimento ad media
esterno usando l'elemento di MediaUri o includendo i
dati all'interno della descrizione come l' InlineMedia. Un
flusso particolare all'interno del media costituito da flussi
multipli può essere specificato usando l'elemento di
StreamID. Se non c'è nessuno StreamID presente, è
presupposto che il media contenga soltanto un singolo
flusso, o che tutti i flussi nei dati di mezzi sono
individuati simultaneamente.
MediaUri
Specifica la posizione dei dati esterni di mezzi di media
(facoltativi).
InlineMedia
Specifica i dati in-linea di mezzi inclusi nella descrizione
(facoltativa).
StreamID
Identifica un flusso particolare contenuto nel media che è
costituito da flussi multipli (facoltativi).
pag. 94
Semantica di TemporalSegmentLocatorType:
Nome
Definizione
TemporalSegmentLocatorType
Specifica la posizione dei dati temporali del
media come il video e l'audio.
Una
localizzazione del media all'interno di una
data informazione temporale del media può
essere specificata usando il MediaTime o
l'elemento di BytePosition.
Se nè il
MediaTime nè l'elemento di BytePosition
sono instaziati, un intero dato temporale del
media è localizzato.
MediaTime
Specifica la localizzazione di un parziale
segmento temporale all'interno di una data
informazione temporale del media usando
un punto temporale o un punto temporale e
una durata (facoltativa). Se soltanto il punto
temporale è specificato, il segmento è
“open-ended ", cioè, il periodo di fine del
segmento corrisponde al periodo di
conclusione del contenuto della risorsa
multimediale.
Esempio di MediaLocator Datatype
<myTemporalSegmentLocator>
<MediaUri>http://www.mpeg7.org/demo.mpg</MediaUri>
<MediaTime>
<MediaRelTimePoint timeBase="../../MediaUri">
PT3S</MediaRelTimePoint>
<MediaDuration>PT10S</MediaDuration>
</MediaTime>
</myTemporalSegmentLocator>
<myMediaLocator>
<MediaUri>http://www.mpeg7.org/demo.mp4</MediaUri>
<StreamID>1</StreamID>
</myMediaLocator>
<myImageLocator>
<MediaUri>http://www.mpeg7.org/demo.ppm</MediaUri>
<BytePosition offset="1024"/>
</myImageLocator>
pag. 95
Nel primo esempio la posizione di video segmento è specificata dal URI di video
file e del relativo tempo di inizio rispetto all'inizio del file e della durata del
segmento. Nel secondo esempio, il MediaLocator si riferisce ad un flusso
particolare all'interno di un file Mpeg-4. Nel terzo esempio, il media è
semplicemente localizzato usando un byte-offset hanno dall'inizio del file
conosciuto.
4.4.3 L’ELEMENTO STRUCTURALUNIT: IL RUOLO DEL SEGMENTO AV
StructuralUnit descrive il ruolo del segmento nella struttura dell' intero contenuto
multimediale a cui appartiene. Le unità strutturali del contenuto multimediale
dipendono dalla classificazione del contenuto multimediale, notizie o per
esempio, di movie, (veda la forma nella classificazione DS). Per esempio, la
notizia, il sommario ed il rapporto possono essere le unità strutturali in un
programma di notizie; la storia, la scena ed il colpo hanno potuto essere le unità
strutturali in un movie.
Figura 22 : STRUTTURA DATI DEL DOCUMENTO DI DESCRIZIONE:
DETTAGLIO DELL'ELEMENT STRUCTURALUNIT
pag. 96
I possibili valori di StructuralUnit:
“logical” : si riferisce all’intera struttura logica individuata nella Composer
Window
“phisical” : si riferisce al file fisico individuato nella Composer Window
“description”: si riferisce alla descrizione vera e propria della risorsa audiovisiva
creata nel Mpeg-7 Editor
“structure” : si riferisce alla descrizione della struttura logica in cui è stata divisa
le risorsa audiovisiva
L'elemento StructuralUnit del prototipo di documento costruito
<StructuralUnit id="structuralUnit-27" href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en"> logical</Name>
</StructuralUnit>
4.4.4 L’ELEMENTO CREATIONINFORMATION: CREAZIONE E
CLASSIFICAZIONE
I metadati riguardanti la creazione (titolo, regia, produttore, etc.) e la
classificazione (format, genere, etc.) del programma televisivo sono contenuti
nell’elemento CreationInformation della struttura dati progettata.
Nella figura seguente si vede in un primo dettaglio che tali informazioni sono
suddivise in due sottoblocchi separati, inglobate negli elementi Creation e
Classification.
pag. 97
Figura 23 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO
CREATIONINFORMATION.
Si fa riferimento agli strumenti di descrizione necessari alla descrizione di
metadata generati da operatori umani o estratti da altri database riguardanti il
processo di generazione/produzione del contenuto multimediale, nel nostro caso
del programma televisivo.
Gli strumenti specificati in questa parte dal documento MDS Schema Mpeg-7
(versione FCD) sono i seguenti:
Il CreationInformation DS contiene:
•
Informazioni riguardanti il processo di creazione che non possono essere
percepite nel materiale audiovisivo o multimediale ( ad esempio l’autore
della sceneggiatura, il regista, il personaggio, il target di utenza, etc.) e
informazioni sul processo di creazione che si percepisce nel contenuto
multimediale ( ad esempio gli attori nel video, i musicisti in un concerto).
•
Le informazioni di classificazione ( ad esempio l’audience, il genere, la
fasci di età consigliata, etc.)
pag. 98
Questo DS può essere allegato ad ogni elemento di tipo Segment DS. Invece, una
descrizione completa può contenere segmenti che sono annotati con un dettaglio
maggiore e questi segmenti possono essere stati prodotti e utilizzati
indipendentemente e/o in diversi materiali multimediali e segmenti.
Sintassi di CreationInformation DS
<!-- ################################################ -->
<!-- Definizione CreationInformation DS
-->
<!-- ################################################ -->
<complexType name="CreationInformationType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="Creation" type="mpeg7:CreationType"/>
<element name="Classification" type="mpeg7:ClassificationType"
minOccurs="0"/>
<element
type="mpeg7:RelatedMaterialType" minOccurs="0" maxOccurs="unbounded"/>
name="RelatedMaterial"
</sequence>
</extension>
</complexContent>
</complexType>
Semantica di CreationInformationType:
Nome
Definizione
CreationInformationType
Descrive le caratteristiche legate alla creazione del
contenuto multimediale.
Creation
Descrive da chi, quando, dove, etc. il contenuto
multimediale è stato creato.
Classification
Descrive la classificazione orientata all’utente e
orientata al servizio del contenuto multimediale.
RelatedMaterial
Descrive informazioni addizionali circa il materiale
cui si fa riferimento nel contenuto multimediale.
pag. 99
Un diagramma di CreationType viene riportato nella seguente figura:
Figura 24 : DIAGRAMMA DI CREATIONTYPE
Di seguito viene riportata la struttura dell'elemento Creation del documento di
descrizione.
Figura 25 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO : DETTAGLIO DELL’ELEMENTO CREATION.
pag.100
La semantica di CreationType:
Nome
Definizione
CreationType
Descrive la creazione del contenuto, incluse location,
date, azioni, materiali, personale dello staff (tecnico e
artistico) e organizzazioni coinvolte.
Title
Descrive un titolo testuale del contenuto multimediale.
Sono consentiti diversi titoli. Questi possono
corrispondere a differenti tipi (indicati dall’attributo
tipo) o a differenti linguaggi (indicati dall’attributo
xml:lang).
TitleMedia
Descrive un titolo non testuale, ma multimediale del
contenuto multimediale stesso. Questo serve da
identificatore multimediale della risorsa descritta. Può
contenere un titolo sotto forma di una immagine, un clip
audio, e/o un video.
Abstract
Descrive un abstract del contenuto multimediale.
Creator
Descrive un creatore del contenuto multimediale. Esso
consente di descrivere persone, organizzazioni, gruppi,
etc. coinvolti nella creazione assieme col ruolo
ricoperto.
CreationCoordinates
Descrive il posto e la data di creazione del contenuto
multimediale.
CreationLocation
Descrive la location in cui è stato creato il contenuto
multimediale.
CreationDate
Descrive la data o il periodo in cui il contenuto
multimediale è stato creato.
Semantica di TitleType:
Nome
Definizione
TitleType
Indica il titolo testuale del contenuto multimediale.
type
Attributo di Title che indica il tipo di titolo testuale, secondo
pag.101
Nome
Definizione
la lista di valori seguente:
main – Il titolo è il titolo principale dato dal creatore. Questo
è il tipo predefinito per il titolo.
secondary – Il titolo è il titolo secondario dato dal creatore.
alternative – Il titolo è un titolo alternativo dato dal creatore.
original – Il titolo è quello originale dato dal creatore.
popular – Il titolo è un titolo popolare dato dal pubblico e dai
media.
Semantica di CreatorType:
Nome
Definizione
CreatorType
Descrive il creatore del contenuto multimediale o della
descrizione. Il creatore può essere una persona (o più), o un
gruppo (o più gruppi), o una o piu’ organizzazioni coinvolte
nel processo di creazione.
Role
Descrive il ruolo giocato dal creatore nel processo di
creazione. Un esempio di schema di classificazione per
questo elemento è MPEG7RoleCS.
Agent
Descrive l’agente (persona, organizzazione o gruppo)
coinvolto nella creazione.
Character
Descrive il nome di un personaggio di finzione (character)
che è parte del contenuto multimediale o che specifica un
ruolo interpretato da un attore. Può essere associato ad un
creatore piu’ di un descrittore di personaggio (character).
Instrument
Descrive l’apparecchiatura o lo strumento impiegato dal
creatore.
pag.102
Figura 26 : DIAGRAMMI DEL TIPO DI DATO CREATORTYPE E
DELL’ELEMENTO ISTANZIATO CREATOR.
Passando all’elemento Classification, lo schema di descrizione a cui si riferisce
all’interno di Mpeg-7 Multimedia Description Shemes è Classification DS.
Questo descrive le informazioni di classificazione del contenuto multimediale. Le
descrizioni risultanti facilitano la ricerca e filtraggio di contenuti multimediali
basandosi sulle preferenze dell’utente ( come ad esempio lingua, stile, genere,
etc.) e le classificazioni orientate al servizio ( come ad esempio scopo, fasce d’età,
segmentazione del mercato, recensione da parte dei media, etc.).
Nella figura seguente si vede un primo dettaglio dei componenti dell’elemento
Classification istanziati nel documento del prototipo.
Figura 27 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO CLASSIFICATION.
pag.103
La semantica di ClassificationType, per la parte di interesse per l’applicazione, è
la seguente:
Nome
Definizione
ClassificationType Descrive la classificazione del contenuto multimediale.
Form
Descrive il tipo di produzione del documento, come ad
esempio, film, telegiornale (news), programma, magazine,
documentario, etc. Un esempio di schema di classificazione
reale è TVAnytime_v0.1FormatCS.
Genre
Descrive di cosa si occupa il contenuto multimediale
(classificazione piu’ ampia) come ad esempio sport,
politica, economia, etc.
Subject
Descrive il soggetto (classificazione specifica) del
contenuto multimediale. Il soggetto consente una
annotazione testuale per la classificazione del contenuto.
Language
Descrive una lingua dei dialoghi del programma.
Release
Descrive la data e la nazione cui fa riferimento la release
del contenuto multimediale.
Date
Indica la data in cui il contenuto è stato rilasciato per la
prima volta. Questa data può essere diversa dalla data o date
in cui è stato creato.
Target
Descrive il target del contenuto multimediale in termini di
classificazione di mercato, età e nazionalità.
Age
Descrive l’intervallo di età del target di utenti per il
contenuto.
Country
Descrive la nazione alla quale il contenuto è destinato.
Semantica di GenreType:
Nome
Definizione
GenreType
Descrive il genere (classificazione più ampia) del contenuto
multimediale. Un esempio di schema di classificazione è
TVAnytime_v0.1ContentCS.
Type
Indica il tipo del genere del contenuto. I tipi di genere sono
pag.104
Nome
Definizione
definiti come segue:
main – Il genere è il principale, o primario. Questo è il
valore di default.
secondary – Il genere specificato è un genere secondario,
come un sottogenere.
other – Il genere specificato è un genere alternativo, come
un genere definito o utilizzato da terze parti.
4.4.5 L’ELEMENTO USAGEINFORMATION: USO DEL CONTENUTO
AUDIOVISIVO
L’elemento UsageInformation fa riferimento alla parte di descrizione che
specifica le informazioni riguardo l’uso del contenuto multimediale.
Nella figura seguente è possibile vedere la collocazione gerarchica di tale
elemento nella struttura del documento Mpeg-7 di descrizione del programma di
esempio .
Figura 28 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO USAGEINFORMATION.
Si fa riferimento agli strumenti di descrizione della parte Usage di MDS Schema,
che sono:
Gli Usage Tool descrivono I metadati riguardo all’uso del contenuto
multimediale. UsageInformation DS include un descrittore Rights, uno o nessun
FinancialResults DS, e diversi Availability DSs e associati UsageRecord DS.
•
Rights D contiene riferimenti ai proprietari dei diritti per poter ottenere
informazioni sui diritti.
pag.105
•
Financial D contiene la descrizione dei costi e dei ricavi generati dal
contenuto multimediale.
•
Availability DS descrive i dettagli riguardanti la disponibilità del contenuto
multimediale per l’uso.
•
UsageRecord DS descrive i dettagli concernenti l’uso del contenuto
multimediale.
E’ importante notare che la descrizione di UsageInformation DS incorporerà
nuove descrizioni ogni volta che il contenuto multimediale verrà utilizzato (ad
esempio in UsageRecord DS, in Income nel Financial D), o quando vi saranno
nuove modalità di accesso al contenuto stesso (Availability DS).
Potenzialmente gli strumenti messi a disposizione consentono l’aggiunta di nuove
descrizioni ogni volta che il contenuto viene usato (ad esempio UsageRecord,
Income), o quando vi sono nuove modalità di accesso disponibili per il contenuto
per alcuni tipi di applicazioni, se richiesto. In tal caso, la dimensione della
descrizione potrebbe crescere in modo significativo. Queste informazioni
dovrebbero essere tenute in conto nel progettare sistemi e applicazioni che usano
tali descrizioni.
Nel seguente listato è riportata la definizione di UsageInformation DS:
Sintassi di UsageInformation DS
<!-- ################################################ -->
<!-- definizione di UsageInformation DS
-->
<!-- ################################################ -->
<complexType name="UsageInformationType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="Rights" type="mpeg7:RightsType"/>
<element name="FinancialResults" type="mpeg7:FinancialType"
minOccurs="0"/>
<element name="Availability" type="mpeg7:AvailabilityType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="UsageRecord" type="mpeg7:UsageRecordType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
pag.106
La semantica di UsageInformationType è la seguente:
Nome
Definizione
UsageInformationType
Descrive le caratteristiche d’uso del contenuto
multimediale.
Rights
Descrive le informazioni riguardanti I proprietari dei
diritti del contenuto multimediale descritto, e come
tale contenuto può essere fruito.
FinancialResults
Descrive il costo della creazione del contenuto
multimediale e il ricavo che esso ha generato. I ricavi
variano col tempo.
Availability
Descrive dove, quando, come, e da parte di chi il
contenuto multimediale può essere utilizzato.
UsageRecord
Descrive dove, quando, come, e da chi il contenuto
multimediale è stato usato in precedenza.
Il descrittore Rights D descrive le connessioni coi proprietari dei diritti d’autore
del contenuto multimediale (IPR, Intellectual Property Rights) e i diritti di accesso
(Access Rights).
La proprietà dei diritti è dinamica e in quanto tale può passare da un proprietario
ad un altro. Per esempio, i diritti per una produzione televisiva (o parte di essa)
sono spesso licenziati e assegnati. Per consentire a dei sistemi informatici di
rilevare la situazione attuale dei diritti, Rights DS trasporta un identificatore che
può essere interpretato attraverso una apposita agenzia.
Per gli scopi della gestione dei diritti (peraltro oggetto di un successivo lavoro di
sviluppo da parte dei committenti di questa sperimentazione) tali agenzie e
sistemi devono progressivamente essere in grado di abilitare i proprietari di diritti
d’autore a dichiarare l’identità del proprietario attuale dei diritti stessi.
In questa prima fase si intende la proprietà dei diritti come un’entità trattata
staticamente, prevedendo inizialmente che tali informazioni vengano inserite
all’atto della creazione della descrizione del contenuto audiovisivo di un
programma. Si prevede in successive revisioni di approfondire questa tematica di
grande interesse per i proprietari di diritti sui contenuti di grandi dimensioni come
la RAI.
Un esempio di implementazione dell’elemento UsageInformation, con gli
elementi selezionati per il prototipo, è indicato del seguito.
pag.107
Elemento usageInformation
<UsageInformation>
<Rights>
<RightsId>
<IDOrganization>
<Name>Rai Produzione Radio
Televisiva (esempio)</Name>
</IDOrganization>
<IDName>
<Name>Rai TV Rights
(esempio)</Name>
</IDName>
<UniqueID>RAICANALE1-TV001-ITALY335666548(esempio)</UniqueID>
</RightsId>
</Rights>
</UsageInformation>
4.4.6 L’ELEMENTO MEDIATIME
Come mostrato dalla seguente figura, l’ultimo degli elementi figli di AudioVisual,
nella struttura dati costruita per il prototipo, è MediaTime, nel quale vengono
racchiuse informazioni temporali per la corretta descrizione del programma
televisivo. Le informazioni temporali vengono inserite automaticamente inserite
dal software Movie Tool ; infatti quando si costruisce la struttura logica, vengono
automaticamente mappati i segmenti nel documento MPEG7 inserendo i
riferimenti di inizio e durata della sequenza.
Figura 29 : STRUTTURA DATI DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO MEDIATIME.
pag.108
Le informazioni di inizio e durata della sequenza sono fondamentali per
l’individuazione della risorsa attraverso il motore di ricerca implementato nel
corso di questo progetto .
In particolare per specifica di progetto le due informazioni temporali sono
necessarie per poter visualizzare un determinato sevizio del TG individuato
attraverso una connessione remota al Server di streaming.
Passando ad una descrizione generale del tipo MediaTime, esso specifica una
nozione del tempo che è codificato con il media descritto. Per l’individuazione
degli intervalli di tempo, il tipo di dato MediaTime è composto di due elementi, il
tempo di inizio e la durata. Se deve essere specificato un solo riferimento
temporale, la durata può essere omessa.
La semantica di MediaTimeType è la seguente:
Nome
Definizione
MediaTimeType
Uno schema di descrizione per la specifica di un
riferimento temporale del media o di un intervallo
temporale del media, che utilizza I descrittori seguenti
per specificare il tempo.
MediaTimePoint
Un elemento che specifica un riferimento temporale
del media utilizzando la data Gregoriana e il tempo
giornaliero.
MediaRelTimePoint
Un elemento che specifica un riferimento temporale
del media utilizzando un numero di giorni e l’ora
giornaliera.
MediaRelIncrTimepoint Un elemento che specifica un riferimento temporale
nel media relativo ad una base dei tempi che conta le
unità temporali.
MediaDuration
Un elemento che specifica la durata di un periodo di
tempo del media fornendo i giorni e l’orario
(opzionale).
MediaIncrDuration
Un elemento che specifica la durata di un periodo di
tempo del media contando le unità temporali.
pag.109
Il tipo di dato MediaTime utilizza due diverse modalità per descrivere un
riferimento temporale o un periodo:
•
Utilizzando il formato Gregoriano di data e orario (MediaTimePoint,
MediaRelTimePoint, MediaDuration).
•
Contando le unità temporali specificate attraverso degli attributi
(MediaRelIncrTimePoint, MediaIncrDuration). Nel caso di segmanti
video, queste unità temporali possono corrispondere al frame rate.
Un diagramma della struttura di mediaTimeType viene riportato nella seguente
figura:
Figura 30 : DIAGRAMMA DEL TIPO DI DATO MEDIATIMETYPE.
Il tipo di dato MediaRelTimePoint specifica l' istante di inizio, secondo l’orario
Gregoriano. Il formato si basa sulla norma ISO 8601. Le frazioni di secondo sono
specificate secondo il tipo di dato timePoint.
Sintassi del tipo di dato mediaRelTimePointType
<!-- ################################################ -->
<!-- Definizione del tipo di dato mediaRelTimePointType -->
<!-- ################################################ -->
<simpleType name="mediaRelTimePointType">
<restriction base="mpeg7:basicTimePointType">
<pattern value="-?(\d+(\-\d{2}(\-\d{2})?)?)?
(T\d{2}(:\d{2}(:\d{2}(:\d+)?)?)?)?(F\d+)?"/>
</restriction>
</simpleType>
Il tipo di dato mediaRelTimePointType specifica un riferimento temporale del
media utilizzando la data e l’orario Gregoriani senza specificare il TZD, Time
Zone Difference (a questo proposito si rimanda alla definizione del tipo di dato
TimePoint nel listato completo di MDS Schema Mpeg-7 documento FCD
N3966).
Il formato del valore di MediaRelTimePoint è:
YYYY-MM-DDThh:mm:ss:nnn FNNN.
pag.110
I simboli utilizzati per le cifre dei corrispondenti elementi di data e tempo sono i
seguenti:
•
Y: Year, Anno che può essere un numero variabile di cifre, (la data può anche
essere omessa)
•
M: Month, Mese.
•
D:Day, Giorno.
•
h: hour, ora.
•
m: minute, minuto.
•
s: second, secondo.
•
n: numero di frazioni, nnn può essere un numero arbitrario di cifre tra 0 e
NNN-1 (NNN e con esso nnn possono avere un numero di cifre arbitrario).
•
N: numero di frazioni di un secondo che vengono tenute in conto da nnn.
NNN può avere un numero arbitrario di cifre non limitato a tre.
Vengono utilizzati anche dei delimitatori per la specifica dell’orario (T) e il
numero delle frazioni di secondo (F).
Parallelamente alla specifica della data Gregoriana, per consentire una precisione
maggiore del secondo, è disponibile la specifica del time code di orario con il
conteggio del numero (nnn) delle frazioni di secondo (FNNN). Se viene utilizzato
il conteggio delle frazioni, il numero di frazioni che costituiscono un singolo
secondo (FNNN) deve essere specificato insieme al numero di conteggio delle
frazioni (nnn). Attraverso FNNN si definisce intervallo di valori del numero
conteggiato di frazioni di secondo (nnn). Quindi l’intervallo di valori di ‘nnn’ è
limitato tra 0 e FNNN-1.
Il tipo di dato MediaIncrDuration specifica viene utilizzato sia per definire la
durata dell'intero video sia per le singole sequenze. Il suo valore è espresso in
frame. Per poter ottenere un formato di tempo compatibile con i parametri
utilizzati da Real Server è necessario convertire il valore espresso da
MediaIncrDuration. Il formato fa riferimento ad un sottoinsieme della norma ISO
8601 (per ridurre i problemi di conversione). Le frazioni di secondo sono
specificate in accordo al tipo di dato timePoint.
Sintassi del tipo di dato mediaIncrDuration
<!-- ################################################ -->
<!-- Definition of the MediaIncrDuration Datatype -->
<!-- ################################################ -->
<complexType name="MediaIncrDurationType">
<simpleContent>
<extension base="integer">
<attribute name="timeUnit" type="mpeg7:mediaDurationType"
use="optional"/>
pag.111
</extension>
</simpleContent>
</complexType>
La sua semantica è riportata nella tabella seguente:
Name
Definition
MediaIncrDurationType
E’ un tipo di dato che specifica la durata di un
periodo di tempo rispettando l’unita di misura del
tempo utilizzata.
TimeUnit
Questo attributo specifica la durata del più piccolo
intervallo temporale che si può avere. Il
MediaIncrDuration specifica la durata di un
intervallo temporale con multipli di questo time
unit.
L’elemento MediaTime implementato nel prtotipo di documento è il seguente:
<MediaTime>
<MediaRelTimePoint> P0DT0H28M7S0N25F</MediaTimePoint>
<MediaDuration timeunit=” P0DT0H0M0S1N25F”>5302</MediaDuration>
</MediaTime>
4.4.7 L’ELEMENTO MEDIASOURCEDECOMPOSITION : DESCRIZIONE
FISICA DEL CONTENUTO
Le informazioni fisiche del file (per esempio dimensioni e formato) vengono
individuate con l'uso di AudioVisualSegmentMediaSourceDecomposition Type.
Queste permettono di visionare il tipo formato e supporto, oltre ad una serie di
parametri sulla codifica ( es. frame rate), del contenuto video. Viene distinta dal
resto del documento Mpeg7 ed individuata grazie a MediaSourceDecomposition.
I suoi attributi sono, come per gli altri descrittori di decomposizione, “criteria”, il
cui valore è “physical” (utilizzato per identificare che le informazioni descrittive
riguardano il file fisico), “overlap” e ”gap”.
Per descrivere tali informazioni si utilizza l’elemento MediaInformation,
elemento figlio di AudioVisual, che viene instanziato subito dopo
MediaSourceDecomposition.
pag.112
E’ possibile vedere in dettaglio nello schema di figura:
Figura 31 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO MEDIAINFORMATION.
Il contenuto delle descrizione MPEG-7 può essere disponibile in diverse modalità,
formati, schemi di codifica, e di esso possono essere disponibili diverse istanze.
Per esempio un evento sportivo può essere registrato in due diverse modalità,
audio e audiovideo. Ognuna di queste due modalità può essere codificata con
diversi algoritmi di codifica. Questo comporta la creazione di diversi profili del
media. Inoltre possono essere rese disponibili diverse istanze o copie di uno stesso
contenuto multimediale per una data codifica.
La figura seguente illustra i concetti di modalità, profilo e istanza.
pag.113
Usage Information
Creation Information
Media Information
Media Instance
Descriptions
Content Entity
Usage Information
Creation Information
Media Information
Record
Original
Instance
Reality
Record
Copy
(in the same profile)
Content Entity
Copy
Original
Instance
Copy
(to a different
profile)
Copied
Instance
Master Profile
(to a different
profile)
Copy
Copied
Instance
Copied
Instance
(in the same profile)
Copied
Instance
describes
Media Profile
describes
Media Instance
Figura 32 : PUNTO DI VISTA DI MPEG-7 PER LA DESCRIZIONE (MODELLO
DI CONTENT ENTITY, PROFILO E ISTANZA)
I Media Information Tools descrivono le informazioni riguardanti il media
specifico della risorsa multimediale. Il MediaInformation DS è incentrato attorno
ad un identificatore per l'entità di contenuto e ad un set di parametri di codifica
raggruppati in profili. Il MediaIdentification DS permette la descrizione dell'entità
del contenuto. Le diverse istanze di MediaProfile DS permettono la descrizione di
diversi parametri di codifica per differenti profili.
La descrizione del supporto o media viene dunque incapsulata in MPEG-7
attraverso il MediaInformation DS. Questo è composto da un MediaIdentification
DS opzionale e da uno o più MediaProfile DSs.I
Il MediaProfile DS è composto di: un descrittore MediaFormat opzionale, un
MediaTrascodingHints D opzionale, un MediaQuality D opzionale, e zero o più
MediaInstance DSs.
E’ presente anche uno schema di descrizione (DS) ComponetMediaProfile che
permette la descrizione di profili di media multiplexati, che sono Media Profiles
di contenuti multimediali composti da altri contenuti mediali come ad esempio i
differenti oggetti multimediali in uno stream MPEG-4 o il video stream e gli
stream audio multilingue in un DVD; un altro esempio possono essere i differenti
video streams che provengono da diverse telecamere in un video stream
multiplexato.
Lo strumento utilizzato è dunque in questa parte il descrittore MediaInformation,
che identifica e descrive le informazioni specifiche del supporto e del formato del
pag.114
contenuto multimediale. Il listato con la sintassi di MediaInformation DS è il
seguente:
Sintassi di MediaInformation DS
<!-- ################################################ -->
<!-- definizione di MediaInformation DS
-->
<!-- ################################################ -->
<complexType name="MediaInformationType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="MediaIdentification"
type="mpeg7:MediaIdentificationType"
minOccurs="0"/>
<element
minOccurs="1" maxOccurs="unbounded"/>
name="MediaProfile"
type="mpeg7:MediaProfileType"
</sequence>
</extension>
</complexContent>
</complexType>
La semantica di MediaInformationType:
Nome
Definizione
MediaInformationType Descrive il
multimediale.
formato
fisico
dell’informazione
MediaIdentification
Identifica l’entita di contenuto multimediale che
rappresenta una realtà.
MediaProfile
Descrive un Media Profile del contenuto multimediale.
Il descrittore MediaIdentification identifica il contenuto multimediale
indipendentemente dalle differenti istanze che sono disponibili. I diversi Media
Profile di un contenuto multimediale sono descritti attraverso il loro elemento di
descrizione MediaProfile e per ogni profilo ci possono essere diverse istanze di
media disponibili (come vedremo tra poco).
Il description scheme MediaProfile descrive un profilo del contenuto
multimediale oggetto della descrizione.
pag.115
Il concetto di profilo fa riferimento alle diverse variazioni che possono essere
prodotte da un supporto mediale originale o master, a seconda dei valori scelti di
volta in volta per la codifica, il formato di memorizzazione, etc. Il profilo
corrispondente al documento multimediale originale o ad una sua copia master
viene considerato come il profilo master o “master media profile”. Per ogni
profilo possono esserci una o piu’ istanze del profilo master.
La semantica di MediaProfileType è la seguente:
Nome
Definizione
MediaProfileType
Descrive il profilo del supporto del contenuto
multimediale oggetto della descrizione.
ComponentMediaProfile
Descrive uno dei Media profile componenti di un
Media Profile multiplexato, tale cioè da descrivere
un contenuto multimediale che si presenta composto
di diversi contenuti multimediali.
MediaFormat
Descrive il formato del Media Profile.
MediaTranscodingHints
Descrive i suggerimenti di trascodifica per il Media
Profile.
MediaQuality
Descrive la qualità del segnale corrispondente al
dato profilo.
MediaInstance
Identifica e localizza una istanza (Media Instance)
del Media Profile.
Master
Indica se il Media Profile corrisponde all’originale o
al profilo master dell’entità di contenuto
multimediale.
La ricorsività del MediaProfile consente la descrizione di flussi multiplexati, vale
a dire flussi multimediali composti di diversi flussi componenti. Tipici esempi
includono:
•
I diversi oggetti multimediali in un flusso MPEG-4.
•
I diversi flussi audio presenti in un DVD da sincronizzare con il video per
il supporto ai vari lunguaggi
Un flusso video multiplexato contenente diversi flussi audio e video (sincronizzati
nel loro insieme) che provengono da differenti microfoni e videocamere, che
possa consentire all’utente di selezionare diversi punti di vista di uno stesso
evento.
pag.116
Il descrittore MediaFormat (il tipo che definisce l’omonimo elemento
MediaFormat istanziato nel nostro documento di descrizione) fornisce
informazioni relative al formato del file e ai parametri di codifica del
MediaProfile.
Nella figura seguente si mostra in dettaglio l'elemento MediaFormat instaziato :
Figura 33 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO MEDIAFORMAT.
Importante è analizzarne la semantica, ricca di elementi che descrivono il formato
dell’istanza di contenuto multimediale (nel nostro caso del programma
audiovisivo codificato nell’archivio digitale Teca Fast):
Semantica di MediaFormatType:
Nome
Definizione
MediaFormatType Descrive il formato e i parametri di codifica del
MediaProfile.
Content
Identifica il media presente nel contenuto multimediale.
Medium
Descrive il supporto di memorizzazione fisica sul quale il
Mediaprofile è memorizzato. Un esempio di schema di
classificazione è MPEG7MediumCS.
FileFormat
Descrive il formato file del MediaProfile. Esempi di schemi
di classificazione per i valori di questo elemento sono
pag.117
Nome
Definizione
MPEG7FileFormatCS e IPTCMimeTypeCS.
FileSize
Indica la dimensione in bytes del file in cui il MediaProfile
è memorizzato.
System
Descrive il formato del profilo del media a livello
broadcast, un esempio di valore è il sistema televisivo
“PAL”, un esempio di schema di classificazione è
MPEG7SystemCS.
BitRate
Indica il bit rate nominale in bit/s del Media Profile.
VisualCoding
Descrive la codifica
MediaProfile.
della
componente
visiva
del
Se una entità di contenuto è audiovisiva, VisualCoding e
AudioCoding sono entrambe utilizzati.
VisualCoding/For
mat
Descrive il formato di codifica della componente video del
MediaProfile. Come sopra, se una entità di contenuto
multimediale è audiovisiva, VisualCoding e AudioCoding
sono entrambe utilizzati. Un esempio di schema di
classificazione è MPEG7VisualCodingFormatCS.
aspectRatio
Descrive l’aspect ratio (fattore di forma) dei pixel
(larghezza/altezza).
Frame
Descrive il frame dell’immagine e i frame video.
height
Indica l’altezza delle immagini e dei frames in pixel.
Width
Indica la larghezza delle immagini e dei frames in pixel. Il
quoziente di larghezza e altezza è il fattore di forma del
campionamento, che è come il fattore di forma
dell’immagine ottica se il pixel è quadrato.
Rate
Indica il frame rate in Hz.
La sintassi completa di MediaInformation D è presente e nel capitolo 8 (Media
Description Tools) del documento.
4.4.8 L’ELEMENTO TEMPORALDECOMPOSITION : DESCRIZIONE
DELLE SINGOLE SEQUENZE
Analizziamo adesso in dettaglio come è possibile descrivere le singole sequenze
video che vengono individuate nella Composer Window del tool di estrazione. E’
pag.118
fondamentale riuscire ad avere una struttura flessibile e semplice così da permette
query il più possibile precise. Nel nostro caso le sequenze individuano il singolo
servizio giornalistico. La possibilità di ricercare e visualizzare singole sequenze
video rende questa applicazione, come da specifiche RAI, utilizzabile come
prototipo di riferimento, il cui scopo è quello di dare un'alternativa ai vecchi
motori di ricerca.
La struttura logica del video viene dinamicamente mappata nel documento
Mpeg7. I riferimenti temporali di inizio e durata della sequenza sono
automaticamente inseriti nel documento Mpeg7. TemporalDecompositionDs è il
descrittore che identifica come vogliamo dividere la risorsa audiovisiva. In
questo caso l’attributo “criteria” ha come valore “structure” in quanto identifica la
struttura logica. Seguono anche gli atributi “overlap” e “gap” il cui valore per
entrambi è “true”, ciò significa che non vi è né sovrapposizione tra le sequenze
presenza di spazi vuoti tra le sequenze.
Sono instaziati, dopo l’elemento Temporal Decomposition, sei Audio Visual
Segment che individuano le singole sequenze video. Si è scelto di descrivere in
questo test tre servizi e le tre introduzioni relative. Negli AudioVisualSegment si
immagazzinano le informazioni sulle singole sequenze utilizzando, come per
l’intera risorsa, gli strumenti CreationInformation, Mediatime, MediaLocator,
TextAnnotation. Si mostrerà nei listati XML sola una delle sei sequenze (le altre
descrizioni sono visionabili in APPENDICE)
Figura 34 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO
TEMPORALDECOMPOSITION.
Analizziamo in dettaglio i singoli elementi che descrivono il servizio
giornalistico. Si mostrerà la struttura di ogni singolo descrittore e un listato di
esempio in XML di un servizio:
pag.119
1. MediaLocator: contiene informazioni sulla localizzazione della risorsa
fisica. Si inserisce il collegamento al video e al frame chiave.
Figura 35 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO MEDIALOCATOR.
L’elemento MediaLocator nel prototipo di documento:
<MediaLocator type="TemporalSegmentLocatorType">
<Image>http://62.110.204.10/tecaprova/Frame/tg1/tg1serv1.jpg</Image>
<MediaUri>rtsp://62.110.204.10:554/tg1.rm</MediaUri>
</MediaLocator>
2. StructuralUnit: descrive il ruolo del segmento nella struttura del
documento, in questo caso si attribuisce il valore “description” in quanto
il segmento AV si riferisce proprio alla descrizione.
L’elemento StructuralUnit nel prototipo di documento:
<StructuralUnit id="structuralUnit-27"
href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en"> structure </Name>
</StructuralUnit>
3. CreationInformation: contiene informazioni sulla creazione (nome
giornalista ed emittente) e sulla classificazione ( genere del servizio ).
pag.120
Figura 36 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO
CREATIONINFORMATION.
L’elemento CreationInformation nel prototipo di documento:
<CreationInformation id="creationInformation-57">
<Creation id="creation-58">
<Title>Servizio 1</Title>
<Creator>
<Role type="GenreType" id="role-87"
href="TecaFastXmCreatorCS">
<Name>Giornalista</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>Dino Corgona'
</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role
type="GenreType"
id="role-87"
href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
pag.121
<GivenName>RAI_UNO
</GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationDate>
<TimePoint>2002-06-04T14:10:00:000:00
</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-61">
<Genre id="genre-62" href="TecaFastXmGenreCS">
<Name>Politica Estera</Name>
</Genre>
</Classification>
</CreationInformation>
4. TextAnnotation : Contiene un abstract del singolo servizio
Figura 37 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO TEXTANNOTATION.
pag.122
L’elemento TextAnnotation nel prototipo di documento:
<TextAnnotation>
<FreeTextAnnotation>A Kanasky in Canada vertice del G8
</FreeTextAnnotation>
</TextAnnotation>
5. MediaTime : Descrive l’intervallo temporale in cui si trova il singolo
servizio. L'inizio (rispetto all'intero telegiornale) e la durata del servizio
giornalistico vengono inserite automaticamente dal tool di acquisizione.
6. Questi parametri vengono successivamente passati al server di streaming
per poter visualizzare la singola sequenza (servizio giornalistico)
descritta.
Figura 38 : STRUTTURA DEL DOCUMENTO DI DESCRIZIONE
IMPLEMENTATO: DETTAGLIO DELL’ELEMENTO MEDIATIME.
L’elemento MediaTime nel prototipo di documento:
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">P0DT0H0M2
0S20N25F</MediaRelTimePoint>
<MediaIncrDuration
timeUnit="P0DT0H0M0S1N25F">1596</MediaIncrDuration>
</MediaTime>
pag.123
CAPITOLO 5
REALIZZAZIONE DI APPLICAZIONE MPEG-7
"TV NEWS ARCHIVE"
Nel Capitolo precedente sono state esposti lo standard di descrizione Mpeg-7 e le
modalità di costruzione del modello di descrizione, con gli strumenti del
Multimedia Description Scheme Mpeg-7 (MDS Schema versione FCD).
Applicando lo standard Mpeg-7 al nostro progetto, il risultato è la creazione di
una struttura dati e la definizione di un profilo applicativo per la descrizione e
gestione di metadati audiovisivi, riferiti all’entità “telegiornale”
Successivamente, come verrà mostrato in questo capitolo, si è passati alla
implementazione del prototipo. Il sistema creato completa il lavoro iniziato nella
prima edizione dei Vivai d’Impresa e ne aumenta le potenzialità, rendendolo un
sistema completo e applicabile ad una prima sperimentazione sul campo. Data la
complessità della struttura dati individuata è stato utilizzato come software il
Tamino XML DataBase Server, un DBMS (Database Management System) che
implementa tecnologie native XML; invece per la distribuzione dei contenuti
audiovisivi si è utilizzato un server di streaming, Real Server.
5.1 ARCHITETTURA DEL PROTOTIPO
Per lo realizzazione del progetto i passi principali sono stati i seguenti:
1) Descrizione della risorsa audiovisiva secondo lo standard Mpeg-7
2) Implementazione del DB XML nativo
3) Inserimento dei documenti Mpeg-7 nel database nativo XML
4) Costruzione delle interfacce di interrogazione del database
Il sistema prevede l'estrazione dei metadati delle risorse audiovisive, secondo le
specifiche Mpeg-7, ed il loro inserimento nel DB. E’ stato possibile interagire con
il server DB XML utilizzando le interfacce Web implementate, che possono
anche recuperare le informazioni con query su parametri precisi.
Il risultato, visualizzato dal browser Web, mostra la descrizione sulle risorse
audiovisive trovate, con la possibilità di visualizzare il contenuto audiovisivo in
video streaming. Il server di streaming utilizzato per questo scopo è “Real Server
8”, che permette una maggiore flessibilità ed efficienza nel collegamento e nella
visualizzazione del video rispetto ad un Web Server.
L’obiettivo principale raggiunto è stato di rendere l’applicazione completamente
trasparente alla piattaforma, così da poter essere adattata anche per altre esigenze.
Un altro obiettivo raggiunto è stato quello di fornire all’utente documentatore o
utente di archivio un servizio facile da utilizzare senza la necessità di avere
conoscenze sullo standard Mpeg-7 o sulle tecnologie XML.
pag.124
Figura 39 : L’ARCHITETTURA DEL SISTEMA PROTOTIPALE MPEG-7
Nell'implementare le interfacce di query si è pensato a definire una struttura a più
livelli. I due tipi di query sono mostrati nella figura seguente.
pag.125
Figura 40 : STRUTTURA MULTILIVELLO (TELEGIORNALE-SERVIZI) PER
LE INTERROGAZIONI
La prima query sul telegiornale recupera tutti i documenti Mpeg-7 che rispondono
ai parametri della form. La pagina Web di risposta, processando lato server il file
XML con un foglio di stile XSL, visualizza l'elenco dei TG. Il foglio di stile
costruisce il link (estraendo l'"id" del documento) che permette di visualizare la
scheda del TG trovato.
La seconda query sul servizio recupera tutte le parti dei documenti Mpeg-7 (i
singoli servizi) che rispondono ai parametri della form. La pagina Web di risposta
mostra una tabella con l'elenco dei servizi. Il foglio di stile XSL compone il link
che permette di visualizare la scheda del TG a cui il servizio appartiene.
5.2 IL DBMS "TAMINO": ARCHITETTURA E COMPONENTI
Tamino, che sta per “Transaction Architecture for the Management of INternet
Objects” offre da subito un ambiente di sviluppo completamente orientato ai
servizi Internet/Intranet (una delle specifiche principali di progetto). Le
informazioni memorizzate nel server DB XML vengono da subito rese disponibili
come “Internet Objects” accessibili non solo tramite comandi innestati nella URL,
ma anche con delle URL assolute che puntano direttamente ai documenti XML
archiviati come se fossero memorizzati direttamente nel file system del server
web.
Inoltre la piattaforma implementa funzionalità avanzate di accesso e scambio dati
con tutti i principali DBMS, oltre ad avere un DBMS SQL interno oltre al DBMS
XML nativo, risultando anche in questo senso un sistema preferenziale per le
esigenze dell’azienda committente del prototipo, come le Teche Rai, che
necessitano di accedere e scambiare dati con i diversi sistemi preesistenti nei vari
archivi e con le organizzazioni verso le quali si intendono offrire applicazioni web
pag.126
based (nel caso specifico acquirenti di contenuti e diritti televisivi, società di
documentazione e operatori della produzione audiovisiva).
Nella figura seguente viene mostrata schematicamente l’architettura della
piattaforma software Tamino utilizzata per il prototipo, a livello di componenti di
sistema e protocolli, linguaggi e standard impiegati.
Figura 41 : INTERFACCE (DOM – DOCUMENT OBJECT MODEL),
PROTOCOLLI STANDARD (HTTP) E COMPONENTI (X-PORT)
5.2.1 CARATTERISTICHE PRINCIPALI DEL DATABASE TAMINO XML:
La parte di elaborazione XML utilizza HTTP come protocollo di comunicazione
per lo scambio dati. Tamino offre anche il supporto a connessioni sicure con un
suo server sicuro HTTP, ma può lavorare anche con server HTTP preesistenti.
Tamino supporta ISAPI, NSAPI, cosi come le Apache API per la comunicazione
via web.
Il linguaggio di query implementato nella versione attuale è X-Query, che ha una
sintassi basata sulle specifiche di Xpath. Inoltre supporta l’elaborazione dei fogli
di stile utilizzando oggetti XML (XSL, CSS) in modalità server side (attraverso
l’impiego di servlet Java). Supporta l’uso degli XML namespace.
Implementa il Document Object Model (DOM) standard ed esteso (funzionalità
specifiche della piattaforma). Interfaccia i DBMS esterni tramite il componente
X-Node che utilizza ODBC. Supporta anche SQL dinamico ed embedded (per
programmi C) con il SQL Engine interno.
pag.127
Nella figura seguente si vede la struttura a strati della piattaforma impiegata.
Figura 42 : VISTA A LIVELLI DELLA PIATTAFORMA
Diverse API consentito di accedere a Tamino da differenti ambienti di
programmazione (Java, C++, ...). Alcune forniscono i comandi di elaborazione e
inserimento documenti, definizione schemi di struttura ed elaborazione di query,
che verranno in seguito mostrate nell’implementazione delle interfacce web
realizzate per il prototipo. E‘ possibile eseguire in remoto tutte le classiche
funzioni di amministrazione grazie ad esempio al System Management Hub che
vedremo successivamente in dettaglio.
Il componente principale del Server XML è X-Machine composto a sua volta di
un Parser, un interprete di interrogazioni in linguaggio Xquery-Xpath, un Object
Processor e un Object Composer, rispettivamente per l’elaborazione e costruzione
di oggetti dati in formato XML, il Data Map per la descrizione delle strutture dati,
ed un XML Data Store nativo. Le loro funzionalità verranno approfondite in
seguito nell’analisi di X-Machine, e sono riportate nella figura seguente.
pag.128
Figura 43 : COMPONENTI E PROTOCOLLI DI COMUNICAZIONE DELLA
PIATTAFORMA TAMINO SERVER.
La comunicazione con il sistema Tamino avviene tramite una interfaccia http
standard. Al momento dell’installazione il DBMS Tamino viene connesso con il
web server (nel nostro caso Apache WebServer 1.3.12) attraverso il modulo XPort. Tamino viene richiamato attraverso una URL della forma
<< http://webserver/tamino/taminodbname >>
dove al posto di “webserver” nel nostro caso viene utilizzato l’indirizzo IP del
server su cui è installato Tamino e gli altri componenti, ma che generalmente
indica il nome di dominio del server web, mentre “tamino” è un nome fissato
durante l’installazione, e “taminodbname” è il nome del DataBase Tamino a cui
viene indirizzata la richiesta sotto forma di URL.
Alla chiamata, il server web attiva il modulo X-Port che passa la richiesta con una
comunicazione TCP/IP al database indirizzato. Il numero di porta IP per la
comunicazione tra il componente X-Port e il database viene definito all’atto
dell’installazione del database e non dovrebbe essere utilizzato da nessun’altra
applicazione.
5.2.2 LA PIATTAFORMA
La piattaforma hardware/software impiegata per il server su cui gira il DBMS
XML Tamino e gli altri servizi come il web server e i servlet Java è la seguente.
pag.129
Configurazione
del
Server
impiegato
(Progetto Internet Tv 2– Vivai d’Impresa)
per
il
prototipo:
Hardware:
Processore Pentium III 800 Mhz di clock, Memoria RAM 512 Mbytes,
Disco fisso Eide Ultra Ata 10 Gbytes, Monitor 17 pollici flat panel HP-LG,
Connessione a rete di alimentazione con backup, Scheda di rete Ethernet
10/100 Mbit/sec, Connessione di rete con linea HDSL 2 Mbit/sec dedicata
verso la dorsale Interbusiness con indirizzo IP pubblico.
Software:
Sistema operativo Microsoft Windows 2000 Professional, Web server:
Apache WebServer 1.3.12, Servlets: Apache Jserv 1.1, Ambiente Java: JRE
1.2.2, Browser HTML: Microsoft Internet Explorer 5.5, Parser XML :
Microsoft MSXML v.3.0, TAMINO XML DB Server Development Edition
v.2.2.9 di Software AG, System Management HUB di Software AG, XTS
Proxy Server, Real Server 8.0, Software di editing codice HTML:
Macromedia Dreamveawer 3.0, Software editing e validazione XML, DTD e
XML Schema: XML SPY v.3.5, Software di editing codice testuale:
UltraEdit v.8.1, Ricoch Movie Tool β
Il server possiede un proprio indirizzo IP pubblico ed è connesso alla rete internet
tramite una linea HDSL dedicata, con velocità di connessione 2 Mbit/sec,
interconnessa alla dorsale di rete Interbusiness di Telecom Italia.
5.2.3 X-MACHINE
Tra le funzionalità base del server DBMS Tamino c’è l’immagazzinamento di dati
in formato XML, che non subisce operazioni di conversione in altri formati dati,
come ad esempio le tabelle relazionali.
Questa funzionalità è fornita dal componente fondamentale della piattaforma,
chiamato X-Machine. Esso si occupa di memorizzare e gestire oggetti XML (ben
formati o validi) all’interno di XML Data Store. X-Machine è in grado di gestire
anche dati non-XML (come testo, file binari) e integra le informazioni contenute
in sorgenti dati e applicazioni esterne attraverso il componente X-Node.
L’accesso ai documenti XML archiviati avviene utilizzando il linguaggio di
interrogazione Xpath, con alcune estensioni. E’ possibile vedere uno schema
dell’architettura di X-Machine nella figura seguente:
pag.130
Figura 44 : ARCHITETTURA DI X-MACHINE E VISTA DEI COMPONENTI
CHE GESTISCONO I DOCUMENTI XML E NON-XML.
Tornando alle funzionalità di X-Machine, quella principale è l’elaborazione di
documenti XML, che passano attraverso diversi passi e componenti.
Gli oggetti XML che devono essere memorizzati da X-Machine sono descritti dal
relativo schema (il DTD) inserito nel Data Map di Tamino. Il componente Data
Map contiene tutte le informazioni per la memorizzazione, l’indicizzazione e
l’elaborazione di oggetti XML per un’efficiente gestione dei dati. Tra le sue
funzionalità la costruzione e configurazione di parametri di indicizzazione
standard e testuali, l’integrazione con applicazioni esterne, la memorizzazione di
strutture dati in tabelle SQL e file Adabas.
Il primo passo è l’elaborazione da parte del parser interno ad X-Machine, che
controlla la correttezza sintattica degli schemi e si assicura che gli oggetti XML in
ingresso siano ben formati. Successivamente gli oggetti XML vengono passati all’
Object Processor per la memorizzazione. Gli schemi contenuti nel Data Map
consentono all’Object Processor di ottenere le informazioni necessarie a
memorizzare dati nell’ XML Store, e/o in tabelle SQL o file Adabas esterni.
Queste sorgenti dati esterne sono integrate attraverso il componente X-Node di
Tamino.
Utilizzando le regole di memorizzazione e richiesta definite nel Data Map, Object
Composer costruisce gli oggetti informativi e li restituisce come documenti XML,
anche se si tratta di dati non memorizzati all’interno ma provenienti da altre
sorgenti dati. Nel caso più semplice, quello previsto da questa prima
implementazione, gli oggetti richiesti tramite un’interrogazione sono memorizzati
internamente come oggetti XML. Nei casi più complessi viene richiesta la
comunicazione con il componente X-Node per costruire un documento di risultato
pag.131
in XML da dati non-XML (ad esempio per l’estrazione-caricamento di dati in altri
DBMS non XML nativi).
Le interrogazioni sui dati vengono processate dal Query Interpreter prima di agire
sull’Object Composer. Il Query Interpreter infatti riceve le richieste X-Query e
interagisce con l’Object Composer per richiedere oggetti XML in accordo a
quanto specificato dalla struttura degli schemi dei DocType memorizzati nel Data
Map.
5.2.4 L’AMMINISTRATORE DEL SERVER
Il componente Tamino Manager è una applicazione client/server che consente
l’amministrazione del server Tamino (e di altri server Tamino eventuali). Il
componente client è l’interfaccia web dell’utente chiamata System Management
Hub. Con l’installazione del server XML e del System Management Hub si
configurano sulla postazione server anche degli agenti software chiamati Tamino
Agents, come l’Administration Agent che, da componente attivo, effettua
operazioni di controllo come: creazione e cancellazione di Database, avvio e stop
di processi software sul server, gestione operazioni di backup e restore, controllo
dei parametri. Nella figura seguente viene mostrato lo schema di comunicazione
dell’interfaccia del Tamino Manager:
Figura 45 :
INTERFACCIA DI TAMINO MANAGER E COMUNICAZIONE CON
L’ADMINISTRATION AGENT E IL SERVER XML.
5.2.5 PROCEDURA DI CREAZIONE DEL DB PROTOTIPO
Il procedimento di creazione del database, come ogni altra operazione di
amministrazione, avviene attraverso il System Management Hub connesso al
Tamino Manager, un software applicativo accessibile tramite un comune browser
web (può gestire diversi nodi server Tamino dislocati in rete locale o su internet).
Per la creazione del database, dopo aver installato i componenti del server
Tamino, è possibile utilizzare il Tamino Manager: l’operazione di “Create
pag.132
Database” configura il kernel del server e alloca e inizializza gli spazi di
memorizzazione fisica del database. Per distinguere le diverse istanze di Database
Tamino ad ognuno viene assegnato un nome unico (nel caso del prototipo
“tecafast”). Tamino utilizza il concetto di locazione (location) che identifica i
contenitori (spazi fisici) allocati. E’ possibile settare anche diversi parametri
riguardanti le risorse del server (dimensioni della cache, accessi, etc.) e le
dimensioni del database (dimensione degli spazi di memoria allocati su disco),
oltre a parametri di ottimizzazione. In seguito alla procedura di creazione del
database, il nuovo nome del Tamino DB Server diviene visibile nel sottoalbero
dei Database del Tamino Manager.
Figura 46 : IMMAGINE DEL SYSTEM MANAGEMENT HUB E DELLA LISTA
DEI DATABASE CREATI E ATTIVI NEL SERVER DB.Il
database Tamino
risulta in grado di memorizzare documenti XML anche se non viene definita una
struttura nella mappa dati (Data Map). Il server XML Tamino utilizza le
definizioni di struttura di documenti xml (chiamati DocType) nella Data Map
oltre che per controllare la correttezza dei documenti inseriti, anche per migliorare
le prestazioni di ricerca. La definizione della DocType all’interno del Data Map
consente infatti l’indicizzazione dei dati contenuti nei documenti XML, abilitando
anche il controllo sui tipi di dato, sulla mappatura nella struttura di dati contenuti
in DB esterni (SQL, Adabas, etc.).
L’interfaccia che viene fornita per accedere alla definizione dei DocType e degli
elementi della struttura è il Tamino Schema Editor. Essa consente di caricare le
Document Type Definition dei documenti xml, di definire tali DTD come
DocType nella Data Map, definendo anche le collection che raggruppano le
DocType all’interno di ogni DB.
Per quanto riguarda la struttura dati del prototipo di documento di metadati Mpeg7, esso è stato costruito facendo riferimento alle specifiche di MDS Schema,
utilizzato per validare i documenti costruiti per il test del DB (la descrizione dei
tre telegiornali trasmessi sulle reti nazionali della RAI).
E' stata quindi impiegata il codice della DTD della struttura del documento di
descrizione Mpeg-7, non ricavabile automaticamente da un processo di
conversione da XML a DTD (implementato ad esempio nel software XML Spy).
Manualmente sono stati ricostruiti nella sintassi DTD i vincoli e le regole sui tipi
pag.133
e le strutture di dato previsti dall’MDS Schema, con i limiti di descrizione di
struttura analizzati nel capitolo III. I documenti di descrizione dei quattro
programmi TV di test sono stati dunque validati nuovamente per verificare la
correttezza della DTD che definisce l’albero della struttura dati.
La definizione della DocType o Schema del documento di descrizione metadati
nel DB avviene utilizzando l’applicazione Schema Editor di Tamino. Questa
applicazione consente non solo di definire le gerarchie di Collection (che
raggruppano gli schemi-DocType di documento) e la DocType stessa, ma anche
di navigare nella struttura dati con un’interfaccia grafica che mostra l’intero
albero e consente di controllare i parametri per ogni elemento e attributo della
schema, compresi aspetti di mappatura dei dati con DB e applicazioni esterne.
Figura 47 :
INTERFACCIA GRAFICA DELL’APPLICAZIONE TAMINO
SCHEMA EDITOR.
Una Collection raggruppa logicamente i Doctypes (schemi di documento) che
consentono di raggruppare i dati riguardanti diverse aree di applicazione (ad
esempio i documenti di descrizione separatamente dalle immagini o dai fogli di
stile). I doctype possono avere gli stessi nomi in diverse Collection. Per questo ad
ogni accesso alle risorse del Server DB deve essere indicato il nome della
Collection oltre che del Doctype. Tutti i documenti per i quali non viene definito
uno schema nella Data Map vengono memorizzati in una Collection speciale
chiamata ino:etc. Un documento viene riconosciuto come appartenente ad un dato
Doctype confrontando il nome di quest’ultimo con il nome dell’elemento radice.
Per creare lo schema di documento e definire il Doctype in Tamino, utilizzando lo
Schema Editor, è stato processato il file della DTD realizzato in precedenza con la
definizione della struttura. Alle informazioni contenute nella DTD lo Schema
Editor aggiunge alcune opzioni specifiche.
pag.134
Figura 48 : PROCEDURA DI DEFINIZIONE DELLO SCHEMA/DOCTYPE A
PARTIRE DALLA DTD, UTILIZZANDO LO SCHEMA EDITOR O
L’INTERFACCIA WEB.
Nel prototipo all’interno del database chiamato “tecafast” è stata definita la
Collection “teca2002collection” come predefinita. In questa Collection è stato
definito lo schema/Doctype principale “Mpeg7” e uno secondario “immagini” per
effettuare dei test sulla gestione di documenti non-XML (nello specifico file di
immagini) all’interno del DB. Un ulteriore Doctype può contenere documenti del
tipo fogli di stile, e nella figura seguente si vede un esempio di raggruppamento
degli schemi di definizione struttura all’interno della collection definita (nel Data
Map del server).
5.3 DESCRIZIONE DELLA RISORSA AUDIOVISIVA
Il primo passo per la realizzazione del progetto, come abbiamo accennato nel
capitolo 4, è stato la descrizione del contenuto audiovisivo .L’uso del software
sperimentale fornito dalla Ricoh denominato Movie Tool è stato fondamentale per
la creazione della struttura dati. Esso ha permesso una descrizione real-time dei
file Mpeg1 rappresentanti delle trasmissione televisive prese dalle reti televisive
RAI .
Per costruire una credibile descrizione di tali risorse audiovisive, che rientrano tra
i programmi già codificati e archiviati nella Teca Fast Rai, si è fatto riferimento
alle informazioni di palinsesto (per gli orari di trasmissione), a quelle di
documentazione del Catalogo Multimediale e ai dati di gestione dei file codificati
con relativi parametri del sistema di gestione (SQL Server) di Teca Fast Rai.
Questa integrazione di dati mette in luce la diversità dell’approccio di un sistema
di gestione metadati basato su strutture Mpeg-7: non solo la gestione di metadati
descrittivi di alto livello (titolo, autori, location, argomenti, etc. come avviene nel
Catalogo Multimediale) ma anche di parametri di più basso livello (tipo di
codifica, formato audio e video, campionamento, fattore di forma del frame,
pag.135
dimensioni in byte del programma archiviato in formato digitale, time code di
inizio e fine assoluti, etc. gestiti dal sistema di Teca Fast), il prototipo intende
evidenziare la capacità di gestire in maniera integrata entrambe gli aspetti,
utilizzando standard portabili e dettagliati come Mpeg-7. La fase di raccolta dati e
realizzazione dei documenti descrittivi dei tre telegiornali impiegati per il primo
sviluppo è avvenuta utilizzando gli strumenti di ricerca sulla intranet aziendale.
Con l'utilizzo di procedure specifiche illustrate nel capitolo 4 l'operazione di
indicizzazione è stata resa facilitata rispetto ai metodi di descrizione tradizionali,
diminuendo sia il tempo e sia il numero di risorse umane che servono per
effettuare una completa analisi del contenuto. Con l'uso di metadati e tecnologie
standard si rende l’applicazione distaccata dalla piattaforma e dall’ambiente di
sviluppo.
La procedura di descrizione è mostrata in figura, in cui si possono apprezzare tutti
i vantaggi .
Figura 49 : PROCEDURA DI DESCRIZIONE
5.4 GESTIONE DEL DATABASE
Per accesso alla applicazione web e l’interazione con il prototipo è stato realizzato
un sito web, denominato “TV News Archive”. La home page del sito
(http://62.110.204.10/tvnew.htm) è visibile nella seguente immagine:
pag.136
Figura 50 :
HOME PAGE DELL’INTERFACCIA INTERATTIVA PER
L'ACCESSO ALLE FUNZIONALITÀ DI RICERCA E GESTIONE DEL DB.
Attraverso collegamenti ipertestuali si accede alle Web Interactive Interface
sviluppate per il prototipo. Il sistema ha tutte le funzionalità necessarie per una
completa gestione del DB: inserimento, cancellazione e ricerca dei dati. Si è
introdotta.
Lo scopo del sistema è mostrare le proprie potenzialità e la facilità di accesso alle
risorse attraverso l’impiego di un web browser di ultima generazione (si richiede
almeno la versione 5 di Microsoft internet Explorer, abilitato alla visualizzazione
di documenti XML).
5.4.1 INTERFACCIA INTERATTIVA DI GESTIONE DOCUMENTI
Le funzioni necessarie per la gestione del DB che sono state implementate
prevedono l’inserimento e l’eliminazione di un documento Mpeg7, come la
possibilità di definire e cancellare una Doctype. L’interfaccia di gestione è
costituita da codice Javascript, in grado di eseguire le funzioni capaci di interagire
con il DB, e da 5 form fondamentali per inviare i comandi e i dati al Server XML.
L’invio della richiesta di operazione avviene attraverso il protocollo standard http.
Analizziamo prima di tutto le fasi di inserimento ed eliminazione di un
documento.
Nella pagina Web viene utilizzata una funzione Javascript e una form per
consentire all’utente di impostare l’indirizzo del DB Server con il quale si vuole
pag.137
interagire (funzione utile in fase di sviluppo). E’ necessaria per consentire
all’utente di impostare l’indirizzo del DB, il suo nome e la collection in cui
inserire o eliminare un documento.
Per l’inserimento di documenti di descrizione nel DB vengono utilizzate una
funzione Javascript e una form per consentire all’utente di scegliere un file
contenente il codice XML con la descrizione del programma TV Telegiornale
basata sulla struttura di metadati Mpeg-7 implementata. L’invio della richiesta
avviene attraverso il metodo POST del protocollo standard HTTP, invocando il
comando “_PROCESS” delle Application Program Interface di Tamino, con il
passaggio dell’indirizzo del server, del DB e della collection su cui memorizzare
il file inviato.
Il risultato dell’operazione ( che viene visualizzato nel Frame sottostante nella
finestra browser) consente all’utente di verificare la bontà della sua operazione. Il
server XML invierà, se l’operazione è andata a buon fine, il numero dell’
“ino:id”che identifica il documento (ogni documento inserito in una Doctype
viene associato con un identificatore, chiamato ino:id, unico all’interno del DB.
“ino” è il namespace di default per gli elementi xml definiti da Tamino); se si
sono verificati degli errori nell’invio della richiesta, verranno visualizzati i relativi
messaggi di errori per permettere eventualmente all’utente di correggere alcuni
parametri.
L’eliminazione di documenti dal Database sul server XML richiede l’invio di una
query in sintassi X-Query/Xpath per l’individuazione del documento da eliminare.
Viene impiegata nuovamente una richiesta http di tipo POST che invia il comando
“_DELETE” al server passando la query come parametro. Il messaggio della
risuscita dell’eliminazione del documento verrà visualizzato nel Frame
sottostante.
Le altre due funzioni importanti per una completa gestione del DB sono la
possibilità di definire o eliminare una DTD(è la struttura dei documenti che
vogliamo inserire nel DB) di documento in remoto.
Per definire e cancellare una Doctype, è necessario impostare l’indirizzo del DB e
il suo nome utilizzando sempre la form vista in precedenza, naturalmente non è
necessario identificare la collezione perché essa verrà inserita con l’opportuna
operazione.
Per poter effettuare questa operazione utilizzando il browser web senza installare
l’applicativo Tamino Schema Editor, si impiegano funzioni Javascript e form
HTML che consentono all’utente l’invio di file (già pronti nel formato Tamino
Schema) al server XML, tramite una POST HTTP che invoca il comando
“_DEFINE” oppure “_UNDEFINE” passando il file selezionato con un form.
pag.138
5.5 INTERFACCE DI QUERY
Per poter effettuare il recupero delle informazioni contenute nel DB sono state
realizzate due interfacce web per la richiesta dei documenti di test attualmente
caricati nel server DB. Alla richiesta il server risponde con un documento XML
(la struttura generica di un documento di risposta del server viene illustrata
successivamente contestualmente all’analisi delle interfacce di interrogazione) a
cui viene associato un foglio di stile XSL per trasformare il risultato in una pagina
HTML facilmente consultabile.
5.5.1 OPERAZIONI DI QUERY IN RETE ATTRAVERSO UN DBMS
NATIVO XML
Il server XML nella versione attuale (quella configurata è la v.2.2.9) utilizza per
le interrogazioni il Query Language XML di Tamino, che segue buona parte delle
specifiche dello standard Xpath del W3C, analizzato nel capitolo III. In più esso
presenta delle estensioni per la ricerca di testo, l’ordinamento e altre operazioni.
Le interrogazioni vengono eseguite dal server XML utilizzando il comando
“_XQL”, e si richiede di indicare sempre il nome della Collection in cui deve
essere effettuata la ricerca, che può essere indicata in due modi diversi:
Nella URL: ad esempio
http://localhost/tamino/tecafast/teca2002collection?_xql=/Mpeg7
Oppure come parametro addizionale del comando:
http://localhost/tamino/tecafast?_xql=/Mpeg7&_collection=teca2002collection
L’elaborazione della richiesta di interrogazione avviene da parte del Request
Interpreter secondo i seguenti passi mostrati anche nella figura successiva:
•
Request Parser: controlla sintatticamente l’interrogazione XML che
arriva al server.
•
Optimizer: controlla se nel Data Map esiste uno schema di documento
per il tipo di documento cui si riferisce l’interrogazione, ed effettua il
parsing dello schema per tutte le informazioni di indicizzazione presenti.
•
Object composer: se le informazioni richieste sono indicizzate, segue
l’elaborazione standard da parte del componente X-Machine. Questo
significa che l’Object Composer si occupa di costruire il documento di
risposta XML in accordo con le informazioni fornite dallo schema di
documento nel Data Map.
•
Postprocessor: si occupa di elaborare la richiesta per i nodi per i quali
non ci sono informazioni di indicizzazione. Esso localizza le
informazioni rilevanti, costruisce un albero in DOM (Document Object
Model) che poi l’Object Composer utilizza per costruire il documento
XML di risposta.
pag.139
Figura 51 : PASSI DI ELABORAZIONE DELLE RICHIESTE DI
INTERROGAZIONE AL SERVER XML
La tipica espressione di una query ha la forma:
_xql=/NodoDiPartenza[NodoDaControllare=‘Valore’]/NodoDaRestituire
dove all’interno delle parentesi quadre sono inserite le condizioni di filtraggio sui
dati. Rispetto a quanto visto per la sintassi di Xpath standard ci sono alcune
variazioni, come la presenza dell’operatore di confronto di stringhe di testo “~=”
che combinato con il wildcard “*” consente di cerca sottostringhe all’interno di
informazioni testuali. Nelle figura seguenti viene mostrata la struttura del
documento XML di risposta alle query da parte del server, in cui risalta
l'aasegnazione da parte di Tamino di un unico "id" per ciascun documento.
pag.140
Figura 52 : OGNI DOCUMENTO MEMORIZZATO NEL DB XML VIENE
IDENTIFICATO DA UN IDENTIFICATORE UNIVOCO “INO:ID”
Figura 53 :
STRUTTURA GENERALE DI OGNI DOCUMENTO XML DI
RISPOSTA COSTRUITO ALL’ATTO DELL’ELABORAZIONE DEI RISULTATI DI
UNA QUERY SUL SERVER XML
5.5.2 IMPLEMENTAZIONE DI XML NEL WEB
In termini di implementazione c’è una grande differenza se si usa un linguaggio
come Xpath per il processamento di documenti (come nel caso di XSL) o se si usa
per la ricerca di documenti da una sorgente di dati XML. Innanzitutto, la ricerca
di documenti è una tecnologia server, quindi un client web come ad esempio un
browser invia una query XML. Il server allora retituisce il risultato della query ad
esempio sotto forma di una pagina XML generata dinamicamente. Il client può
quindi applicare una qualche formattazione al risultato ricevuto utilizzando un
foglio di stile XSL.
pag.141
Figura 54 : CASO IN CUI SI DISPONE DI UN BROWSER IN GRADO DI
LEGGERE DOCUMENTI XML/XSL.
Questa configurazione richiederebbe l’uso di un browser abilitato alla
visualizzazione di documenti XML/XSL. In un ambiente aperto non si può fare
un assunto del genere. Invece in un ambiente l’XSL basato sul server può essere
usato insieme alle query XML. La figura di seguito mostra questo aspetto.
Figura 55 : CASO DI UTILIZZO DI UN COMUNE BROWSER HTML CON
SUPPORTO CSS (CASCADING STYLE SHEET)
pag.142
Nella figura precedente il processore XSL server based (servlet) converte le
pagine XML e i fogli di stile XSL in formato HTML (possibilmente con
formattazione CSS), che può essere visualizzato da gran parte dei web browser.
Un possibile compromesso è quello di supportare i vecchi client e i client
compatibili con XSL separatamente fornendo i fogli di stile in due versioni
diverse. Esistono attualmente alcune implementazioni sperimentali di servlet
XSLT, realizzate da Lotus, James Clark (che ha lavorato alla realizzazione del
W3C XSL Working Draft), e altri.
In ambiente intranet tuttavia le cose cambiano. Qui il supporto lato client all’XSL
può essere introdotto in tempi relativamente brevi e può essere utilizzata una
formattazione completamente XSL.
Figura 56 :
DOCUMENTI XML INSTRADATI FINO AL CLIENT PER BROWSER
ABILITATO ALL'XSL
L’uso di XSL lato server può ridurre il tempo di trasmissione solo se una piccola
parte di informazione deve essere estratta da un documento XML, mentre può
aumentare il tempo di trasmissione se viene richiesta l’aggiunta di molti elementi
decorativi.
Si può sempre far riferimento al contenuto non formattato della sorgente dei dati.
I risultati restituiti come risposta ad una query sono delle pagine XML generate
dinamicamente. Queste possono anche subire una formattazione, con XSL.
Tornando ad Xpath, una seconda modalità di implementazione (vedi Figura
sopra) prevede che il meccanismo di accesso fisico per reperire e richiedere un
pag.143
documento in una sorgente dati sia completamente differente dal meccanismo
utilizzato per selezionare gli elementi da un singolo documento. In particolare in
un ambiente aziendale, un archivio XML può ospitare un enorme numero di
pagine XML, possibilmente milioni. In tali condizioni si richiede l’uso di
tecnologie di database sofisticate per gestire efficientemente le query.
L’ottimizzazione delle query, il caching, e le tecniche di indicizzazione sono
alcune delle parole chiave conosciute nel mondo delle tecnologie relazionali e che
sono importanti anche per i server XML.
L’indicizzazione in particolare, una tecnologia chiave in tutti i sistemi di database,
pone alcune problematiche di interesse. Innanzitutto vanno identificati gli
elementi adatti a fare da chiavi. Il DBMS a questo punto costruisce tabelle indici
o alberi indici che consentono di trovare rapidamente un oggetto secondo una
certa chiave. Utilizzando gli indici il carico elaborativo e il tempo richiesti per il
reperimento di un oggetto vengono ridotti da n a log(n). L’indicizzazione è la
principale ragione per cui i DBMS (inclusi i server XML) sono molto più
performanti dei file system cosidetti “flat”.
Un repository XML d’altra parte lavora in un ambiente aperto. I client possono
inviare query di ogni tipo, cosi che tipicamente non è prevedibile determinare i
migliori tag da prendere in considerazione per l’indicizzazione. Si potrebbe
pensare di indicizzare tutti i tag ed attributi. Ma in questo modo si comporterebbe
un grande overhead, rendendo lente le operazioni di aggiornamento. Inoltre i
processori XML devono essere in grado di processare qualsiasi documento XML
ben-formato, anche se la definizione dello schema (ad es. la DTD) non si conosce
o viene perduta. Poiché sia la struttura dei documenti che la natura delle query
non sono prevedibili per l’archivio XML, è davvero difficile pianificare in
anticipo una struttura di indicizzazione.
Alcuni XML information server sono a volte in grado di utilizzare un misto di
tecniche di indicizzazione adattative. Queste tecniche includono la tradizionale
indicizzazione controllata dall’amministratore in combinazione con tecniche di
indicizzazione avanzate derivate dai sistemi di ricerca nei testi ad alta capacità che
hanno dovuto affrontare da più tempo un problema simile.
5.5.3 COSTRUZIONE DELLE INTERFACCE
Le interfacce web realizzate per l’invio di interrogazioni in sintassi XPath al DB
del prototipo utilizzano programmazione Javascript e delle form in cui inserire i
parametri della query. I parametri chiave utilizzati per la ricerca possono essere
dei menu a discesa o campi a testo liberi in cui inserire stringhe di testo . La
ricerca è effettuata in elementi specifici della struttura di descrizione basata su
metadati Mpeg-7. In questo caso viene mascherata la sintassi Xpath per avere una
applicazione trasparente all’utente.
pag.144
Nel caso del menu a discesa i valori della query sono già inseriti dentro la pagina
Web. Inoltre queste interfacce mostrano la possibilità di effettuare la ricerca
specifica di una stringa di caratteri o una parola all’interno dei alcuni campi come
il “Titolo” (elemento Title nella struttura di descrizione Mpeg-7 implementata), o
“Nome e cognome del giornalista” (elementi GivenName in Creation nella
struttura dati), o nel campo di descrizione a testo libero (elementi
freeTextAnnotation nella struttura dati).
La possibilità offerta di combinare criteri di ricerca molto articolati rende
l’applicazione di facile integrazione nel mondo Web. Utilizzando condizioni
multiple sul nome degli autori, sul titolo, sulla data e orario e su altre
caratteristiche di un dato TG è possibile avere una elevata puntualità nelle
ricerche. Grazie alla struttura del DocType definita nel Data Map, le ricerche di
questo tipo risultano comunque gestite efficientemente da Tamino, mostrando un
altro dei vantaggi di un sistema di gestione dati strutturati completamente basato
su XML nativo.
Per i documenti risultanti dalla query si utilizza una trasformazione basata su un
foglio di stile XSL. Non viene impiegata l’elaborazione lato client, ma viene
utilizzato un Java Servlet per il processamento lato server del documento xml per
la trasformazione dei risultati della query restituita dal DB del prototipo. Ciò
permette di non caricare con inutili operazioni il client. L’URL stessa non si
riferisce direttamente al DB Tamino ma alla Servlet configurata (in questo caso il
path è preceduto dall’indicazione di “servlet” e dal nome del servlet specifico
chiamato “tecafaststyle” per il processamento del foglio di stile XSL).
Inoltre l’utilizzo di un parser SAX (affrontato nel capitolo III) completamente
standard implementato nella servlet consente di implementare tutte le potenti
funzioni dello standard XSL di trasformazione (il linguaggio XSL supportato dal
DOM Microsoft ha ancora delle limitazioni rispetto allo standard, ad esempio
non è in grado di gestire xsl:variable).
L’impiego di un’interfaccia “leggera” come quella illustrata di seguito consente
alcuni vantaggi rispetto all’impiego dell’interfaccia Javascript-DOM di
processamento lato client, uno dei principali è la compatibilità: il servlet elabora
lato server il codice xml con la XSL, restituendo al client web una pagina HTML
standard, consentendo così l’impiego di un browser standard HTML (o altro
browser, ad esempio wap, se il foglio di stile viene programmato
opportunamente).
5.5.4 INTERFACCIA DI INTERROGAZIONE SULL’INTERO TG
Viene mostrata in figura la prima interfaccia web realizzata per fornire
funzionalità di ricerca su risorse di telegiornale. Si utilizza una funzione Java
Script per costruire e inviare la query e una form per l’inserimento i parametri
dell’interrogazione. Come si vede dalla figura, il sistema nasconde all’utente le
tecnologie XML implementate, essendo semplice da usare come un interfaccia
Web.
pag.145
Figura 57 :
INTERFACCIA DI RICERCA AVANZATA SULL'INTERO TG
La scelta dei parametri della Query impiegati per il recupero delle informazioni è
secondo le specifiche esigenze di progetto, prendendo spunto dagli strumenti di
ricerca sulla intranet aziendale, così da rendere l’applicazione il più possibile da
subito attuabile.
In questa prima interfaccia si possono effettuare ricerche con parametri multipli
come la data, l’ora, l’emittente e lo speaker; i risultati sono dei documenti XML e
vengono visualizzati associandoli un foglio di stile XSL. Si utilizza per questa
operazione un Java Servlet che permette di costruire dinamicamente la pagina
Web dei risultati, processando i documenti XML con fogli di stile XSL, e
visualizza tutti i TG che rispondono ai parametri della Query.
Nella figura sotto è mostrata una pagina di risposta ad una query(trasformata in
HTML dal foglio di stile XSL A), dove si trova l’elenco dei TG che
corrispondono ai parametri dell’interrogazione.
pag.146
Figura 58 :
RISPOSTA DEL SERVER A CUI È STATO ASSOCIATO UN FOGLIO
DI STILE XSL A (VEDI APPENDICI)
Le informazioni di ogni TG recuperato sono il Titolo (es. TG1), l’emittente, lo
speaker, la data e la durata. Il Titolo e la scritta MEDIAPROFILE contengono due
link costruiti dinamicamente che puntano allo stesso documento XML; ad esso ,
però, gli viene ancora associato un altro foglio di stile necessario per estrarre altre
informazioni aggiuntive. Questi contengono il riferimento alla scheda di ogni TG
e alle informazioni di palinsesto e sul profilo del media (es. formato e dimensione
del file).
Analizziamo, adesso, la scheda del TG che contiene le informazioni generali sul
TG. Si costruisce dinamicamente (richiamando il documento XML di descrizione
e trasformandolo con il foglio di stile XSL descritto nell'appendice B), a seconda
del numero dei servizi, una tabella che visualizza le loro informazioni.
pag.147
Figura 59 : SCHEDA TG (FOGLIO DI STILE XSL B VEDI APPENDICI)
Le informazioni visualizzate sono l’ordine del servizio all’interno del TG, la
durata del servizio, il giornalista, il tipo di servizio un abstract e una preview.
Questa rappresenta un frame chiave del singolo servizio ed è stata estratta durante
la descrizione del servizio utilizzando Movie Tool.
Viene costruito un link che permette la visualizzazione del singolo servizio. Una
funzione Java Script che crea dinamicamente il link prendendo le informazioni
necessarie direttamente dal documento XML. Le informazioni estratte sono la
locazione della risorsa che si trova in MediaUri, l’inizio e la durata del singolo
servizio necessarie per comunicare al server di streaming l’intervallo temporale
del file AV. Il formato del tempo espresso nella descrizione Mpeg-7 deve essere
adattato al formato di Real Server, per questo motivo è stato necessario inserire il
javascript nel foglio di stile per operare questa trasformazione.
Real Server permette la gestione dei file audiovisivi in modo semplice e flessibile,
le informazioni inviate al server sono i parametri di tempo necessari per poter
visualizzare solo una parte del video.
pag.148
Figura 60 : VISUALIZZAZIONE DEL SINGOLO SERVIZIO CON REALPLAYER
Con il link MediaProfile visualizziamo (con il foglio di stile XSL C) informazioni
di palinsesto e sul profilo del media. Inoltre si mostrerranno quelle generali sul
TG, sulla produzione e la regia (sono state inserite prendole da Catalogo
Multimediale), sui diritti televisivi della risorsa audiovisiva ( questo è un esempio
di come Mpeg-7 può affrontare questo problema) e sul file fisiche (che vengono
inserite automaticamente da Movie Tool).
5.5.5 INTERFACCIA DI INTERROGAZIONE SUI SINGOLI SERVIZI
Viene mostrata in figura la seconda interfaccia web realizzata per fornire
funzionalità di ricerca sul singolo servizio. Si utilizza una funzione Java Script per
costruire e inviare la query e delle form per l’inserimento i parametri
dell’interrogazione. Come si vede dalla figura, il sistema permette una completa
trasparenza dell’utente dalle tecnologie XML implementate.
La scelta dei parametri della Query impiegati per il recupero delle informazioni è
avvenuta in collaborazione con i responsabili di Teca Fast Rai, prendendo spunto
dagli strumenti di ricerca della intranet aziendale.
Nella pagina si possono effettuare ricerche multiple per aumentare la puntualità
sul tipo di servizio, sull’emittente, su parole chiave e sul giornalista; il risultato
contiene le parti dei documenti Mpeg-7(le singole sequenze) che soddisfano i
parametri della query. La pagina di risosta è costruita associando al documento
XML il foglio di stile XSL descritto nell'appendice D. Si utilizza per questa
operazione un Java Servlet che permette di costruire dinamicamente una tabella
in cui verranno visualizzati tutti i servizi risultanti dalla Query.
pag.149
Figura 61 :
INTERFACCIA DI RICERCA AVANZATA SUL SINGOLO SERVIZIO
Figura 62 :
RISPOSTA, RESTITUITA DEL SERVER, SOTTO FORMA DI
DOCUMENTO XML CON ASSOCIATO UN FOGLIO DI STILE XSL D
La query, quindi, è costruita in modo tale che come risultato visualizza una tabella
con le informazioni sui servizi giornalistici estratti dalle descrizione dei singoli
TG. Le informazioni di ogni servizio recuperato sono l’ordine del servizio rispetto
al suo intero TG, l’emittente, il giornalista, l’abstract, il tipo di servizio, la data e
la durata. Inoltre vengono costruiti due link uno che contiene il riferimento alla
scheda di ogni TG e l'altro invece permette di vedere il servizio.
pag.150
La scritta “Scheda TG” è documento XML di descrizione del programma da cui
deriva il singolo servizio( esso viene ancora associato ad un altro foglio di stile
necessario per visualizzare le informazioni aggiuntive) e l’ altra “Video” permette
di connettersi al server di Streaming per visualizzare il singolo servizio. La scheda
del TG è la stessa che si è incontrato nella prima interfaccia di query.
pag.151
CAPITOLO 6
CONCLUSIONI E SVILUPPI DEL PROGETTO
Lo scopo del progetto Internet TV fase 2 è la realizzazione di un sistema
informativo per la gestione di metadati audiovisivi, basato sulle tecnologie più
innovative, che si stanno imponendo in questo settore, e finalizzato alla diffusione
di risorse audiovisive in rete geografica.
Partendo dai risultati ottenuti dalla prima edizione, si sono ripercorsi tutti i passi
fondamentali del lavoro precedente, quali conoscere la struttura di Teca Fast e
acquisire competenze sulle tecnologie XML, a cui fa riferimento Mpeg-7, e sulle
infrastrutture Web, quali ad esempio DBMS nativo XML. In particolare le
tecnologie XML propongono una serie di strumenti molto potenti per la creazione
di basi di dati più accessibili, portabili e flessibili delle tradizionali tecnologie.
Le finalità del progetto Internet TV si possono sintetivamente riassumere in
quattro punti:
1) Ricerca puntuale e interoperabilità con i sistemi preesistenti
2) Accesso attraverso interfacce Web
3) Gestione dei Metadati
4) Collegamento alla risorsa fisica (video streaming su richiesta)
La prima differenza sostanziale rispetto al progetto precedente è stata migliorare
la ricerca puntuale, introducendo query con condizioni multiple, così da puntare
alla singola audiovisiva. Giovandosi dello stesso Server XML che permette di
interfacciarsi con numerosi database tradizionali tra cui SQL Server,
l'interoperabilità con i sistemi preesistenti è ancora presente nell'applicazione.
Oltre alla gestione dei metadati, è stata introdotta una procedura per la loro
estrazione adoperando lo strumento Movie Tool fornito dalla società giapponese
Ricoh. La descrizione della risorsa audiovisiva risulta facilitata rispetto alla prima
sperimentazione, inoltre sono state introdotte informazioni di più basso livello per
aumentare il dettaglio nel metadato.
Nel primo progetto il modello della struttura dati (descrizioni Mpeg-7) prevedeva
la descrizione del contenuto audiovisivo al livello di “programma” inteso come
puntata di programma televisivo trasmesso. La nuova struttura dati implementata
prevede inoltre la descrizione delle singole sequenze e l'inserimento delle
informazioni necessarie per la loro visualizzazione.
I passi successi sono stati la definizione della architettura dell'applicazione Mpeg7 e l'integrazione di funzionalità di pubblicazione in video streaming su richiesta.
Il prodotto finale è un sistema completo per l'estrazione e la gestione di un
archivio televisivo digitale dal punto di vista dei metadati.
Per il prosieguo del lavoro nell'ambito delle attività formative "Vivai d'Impresa",
si sono individuati alcuni sviluppi che si possono riassumere in tre punti
fondamentali. In primo luogo si studierà come potenziare la funzionalità per
pag.152
l’estrazione automatica di Metadati. In secondo luogo si potranno implementare
tecnologie per la gestione dei diritti d'autore integrando funzionalità per la
gestione degli accessi e per la protezione della connessione e la sicurezza dei dati
contenuti. Infine si propone di ricercare soluzioni adatte a portare il sistema verso
architetture "open source".
pag.153
BIBLIOGRAFIA, RISORSE IN RETE
•
"Speciale broadband: la rivoluzione della larga banda" di Andrea Petrucci disponibile all'indirizzo web: http://www.goa.it/speciali/largabanda.htm
•
"La televisione che non c'è e quella che ci sarà" di M.S. - disponibile
all'indirizzo web: http://www.goa.it/speciali/webtv/
•
“Il Multimedia nelle organizzazioni: Nuovi modelli di conoscenza e
comunicazione - DOSSIER DI INGENIUM” di:Beppe Croce – Rivista
Ingenium Anno XII n. 25
•
Rapporto Settore 1 - INFORMATICA E TELECOMUNICAZIONI MEMBRI
DEL GRUPPO DI LAVORO
http://web.tiscalinet.it/GianlucaRipa/personal/ecom/convergenza.htm.
•
Sito web della SIAE:
http://www.siae.it/Site2/SiaeMainSite.nsf/html/It_MMLicenza.html
•
“Archivi digitali” di Tommaso Russo – da “Archivi e Database”- Servizio del
programma
Mediamente
–
disponibile
all’indirizzo
internet
http://www.mediamente.rai.it/home/tv2rete/mm9899/98122801/s981228.htm
•
“Sistema Teche – Patrimonio Rai – Catalogo Multimediale” - testo
divulgativo rieditato da Barbara Scaramucci (Direttore Teche Rai), da un testo
di Roberto del Pero, Giorgio Dimino e Mario Stroppiana del Centro Ricerche
Rai.
•
“<indecs> Metadata Framework: Principles, model and dictionary”, ID
WP1a-006-2.0, Godfrey Rust, MUZE inc; Mark Bide, EDItEUR.
•
“Metadata Watch Report #3”, Makx Dekkers, PrincewaterhouseCoopers, 20
Novembre 2000, SCHEMAS-PwC-WP2-D24-Final-20001120
•
C. Oppenheim. “Legal issues associated with Electronic Copyright
Management Systems”.
•
A. Ramsden. “Copyright Management Technologies”.
•
B. Tuck. “Electronic Copyright Management Systems”.
•
“Unique identifiers : a brief introduction” / by G. Greene and Mark Bide.
•
Sito web del W3C Consortium http://www.w3.org/
o Metadati: http://www.w3.org/metadata
•
Nell’ambito dell’UKOLN http://ukoln.ac.uk/
o Interoperabilità: http://ukoln.ac.uk/interop-focus
pag.154
o Metadati: http://ukoln.ac.uk/metadata
o E-lib Standards Guidelines
http://www.ukoln.ac.uk/services/elib/papers/other/standards/versio
n2/intro.html
•
IFLA - Digital Libraries http://ifla.inist.fr/II/index.htm
•
Dublin Core, siti ufficiali: http://purl.org/dc/ , http://dublincore.org
•
“XML and Related Technologies” distribuito da Software Ag sul sito
www.softwareag.com/xml.
•
“Microsoft XML Document Object Model” di Gianluca Musella – articolo
pubblicato sullo Speciale XML della rivista “Computer Programming” n.90 di
Aprile 2000.
•
Document Object Model Level 1 Specification Version 1.0, reperibile
all’indirizzo http://www.w3.org/TR/REC-DOM-Level-1/
•
" XML passo passo"
•
" XML SPY" documetazione del software diponibile all''indirizzo
http://www.xmlspy.com
•
“Architetture software per oggetti formativi definiti con XML” Tesi di Laurea
di Paolo Diomede Tesi, sviluppata presso la Scuola Superiore G. Reiss
Romoli (Telecom Italia, L'Aquila)
•
S.Land, XML: The ASCII of the future, MSDN News n.3, Maggio/Giugno
1999.
•
S.Mohr, Designing Distribuited Applications with XML, Wrox Press, 1999.
•
Per XQL: http://www.w3.org/TandS/QL/QL98/pp/ibmpos.html).
•
“MPEG: Il presente ed il futuro del multimediale”A cura di Gianfranco
Giannini
–
Pixel
Magazine,
indirizzo
web
http://www.pixelmagazine.com/pag32.htm.
•
“Una rete d’ingegno” di Leonardo Chiariglione – Focus “Libri e copyright: la
sfida
digitale”
dal
sito
web
de
“IlSole24Ore”
indirizzo
http://sole.ilsole24ore.com/cultura/domenica/focus7_05/06.htm
•
Hunter J., Iannella R., "The Application of Metadata Standards to Video
Indexing", Second European Conference on Research and Advanced
Technology for Digital Libraries, Crete, Greece, September, 1998.
•
Movie Tool: manuale e documentazione elettronica fornita con il prodotto.
•
Overview of the MPEG-7 Standard, Version 5.0, Marzo 2001, ISO/IEC
JTC1/SC29/WG11 N4031
pag.155
•
Documento Mpeg-7 ISO/IEC 15938-5 Multimedia Description Schemes
Versione FCD N3966, 12 Marzo 2001, Singapore, ISO/IEC JTC 1/SC 29/WG
11/N3966.
•
"Mpeg-7
project"
diponibile
http://ipsi.fhd.de/delite/Projects/MPEG7/
•
J. Hunter, L. Armstrong, "A Comparison of Schemas for Video Metadata
Representation", WWW8, Toronto, May 10-14, 1999 - link :
http://archive.dstc.edu.au/RDU/staff/jane-hunter/www8/paper.html
•
“Accesso a database via Web” di Luca Mari, edizioni Apogeo, 2002.
•
Tamino DB Server Developer edition v.2.2.9 manuale e documentazione
elettronica fornita con il prodotto.
all'indirizzo
web
:
pag.156
APPENDICE A:
LISTATO DEL DOCUMENTO DESCRITTIVO
REALIZZATO SECONDO MPEG-7 MDS
Descrizione di un programma Tv archiviato in Teca (caso studio del
telegiornale “TG1”) basata su metadati e su strutture di descrizione
Mpeg-7 MDS Multimedia Description Schemes.
<?xml version="1.0" encoding="Shift_JIS"?>
<!-- edited with XML Spy v3.5 NT (http://www.xmlspy.com) by () -->
<Mpeg7 type="complete" xmlns="http://www.mpeg7.org/2001/MPEG-7_Schema"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance">
<DescriptionMetadata id="descriptionMetadata-36">
<Comment>
<FreeTextAnnotation>Descrizione delle informazioni descrittive del contenuto audiovisivo di un telegiornale
della RAI</FreeTextAnnotation>
</Comment>
<Creator>
<Agent xsi:type="PersonType" id="agent-37">
<Name>
<GivenName>Donato Biscaglia e Gianluca Cicero</GivenName>
</Name>
</Agent>
<Instrument>
<Tool id="tool-38" href="urn:ricoh:mmVISION:DescriptionToolCS:2">
<Name>MovieTool</Name>
</Tool>
</Instrument>
</Creator>
<CreationTime>2002-06-14T15:13:00:000:00</CreationTime>
</DescriptionMetadata>
<ContentDescription xsi:type="ContentEntityType">
<MultimediaContent xsi:type="AudioVisualType" id="multimediaContent-1">
<AudioVisual id="logical-2">
<MediaLocator type="TemporalSegmentLocatorType">
<MediaTime>
<MediaTimePoint> 2002-06-04 T20:00:00:000:00</MediaTimePoint>
<MediaDuration>P0DT0H4M29S13N25F</MediaDuration>
</MediaTime>
</MediaLocator>
<StructuralUnit id="structuralUnit-3" href="urn:ricoh:mmVISION:SegmentTypeCS:1">
<Name xml:lang="en">logical</Name>
</StructuralUnit>
<CreationInformation id="creationInformation-39">
<Creation id="creation-40">
<Title>TG1</Title>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>RAI_UNO</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Speaker</Name>
</Role>
<Agent type="PersonType" id="agent-88">
pag.157
<Name>
<GivenName>Filippo Gaudenzi</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role href="TecaFastXmCreatorCS">
<Name>Regia</Name>
</Role>
<Agent xsi:type="PersonType">
<Name>
<GivenName>Simone Morrettii</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role href="TecaFastXmCreatorCS">
<Name>Direttore di produzione</Name>
</Role>
<Agent xsi:type="PersonType">
<Name>
<GivenName>Franco Campanna</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role href="TecaFastXmCreatorCS">
<Name>Direttore fotografia</Name>
</Role>
<Agent xsi:type="PersonType">
<Name>
<GivenName>Mauro Durante</GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationLocation id="creationLocation-43">
<Name xsi:type="TextualType">Roma, Lazio</Name>
<Role id="role-44">
<Name>Studi di produzione</Name>
</Role>
<Country>it</Country>
<AdministrativeUnit>Studi Rai Saxa Rubra-3</AdministrativeUnit>
</CreationLocation>
<CreationDate>
<TimePoint>2002-06-15T20:00:00:000:00</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-45">
<Form type="GenreType" id="form-46" href="urn:mpeg:TVAnytime_v0.1FormatCS:1.3">
<Name>Magazine</Name>
</Form>
<Genre id="genre-47" href="TecaFastXmGenreCS">
<Name>Cultura , Attualita&apos;</Name>
</Genre>
<Target>
<Age min=">10"/>
</Target>
</Classification>
</CreationInformation>
<UsageInformation id="usageInformation-48">
<Rights>
<RightsId>
<IDOrganization>
<Name>Rai Produzione Radio Televisiva(esempio)</Name>
</IDOrganization>
<IDName>
pag.158
<Name>Rai TV Rights(esempio)</Name>
</IDName>
<UniqueID>RAICANALE3-TV001-ITALY-3758696(esempio)</UniqueID>
</RightsId>
</Rights>
</UsageInformation>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">
P0DT0H0M0S0N25F</MediaRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">6738</MediaIncrDuration>
</MediaTime>
<MediaSourceDecomposition id="mediaSourceDecomposition-4" criteria="physical" overlap="true"
gap="true">
<AudioVisualSegment id="physical-5">
<StructuralUnit id="structuralUnit-6" href="urn:ricoh:mmVISION:SegmentTypeCS:2">
<Name xml:lang="en">physical</Name>
</StructuralUnit>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">
P0DT0H0M0S0N25F</MediaRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">6738</MediaIncrDuration>
</MediaTime>
<MediaSourceDecomposition id="mediaSourceDecomposition-7" criteria="description"
overlap="true" gap="true">
<AudioVisualSegment id="description-8">
<MediaInformation id="mediaInformation-9">
<MediaProfile id="mediaProfile-10">
<MediaFormat>
<Content>audiovisual</Content>
<Medium id="medium-11" href="urn:mpeg:MPEG7MediumCS:2.1.1">
<Name xml:lang="en">HardDisk</Name>
</Medium>
<FileFormat id="fileFormat-12"
href="urn:mpeg:MPEG7FileFormatCS:3">
<Name xml:lang="en">mpeg</Name>
</FileFormat>
<FileSize>37687948</FileSize>
<System id="system-13" href="urn:mpeg:MPEG7SystemCS:1">
<Name xml:lang="en">PAL</Name>
</System>
<BitRate>178400</BitRate>
<VisualCoding>
<Format id="format-14"
href="urn:mpeg:MPEG7VisualCodingFormatCS:2">
<Name xml:lang="en">MPEG-1</Name>
</Format>
<Frame height="288" width="352" aspectRatio="1.22222222222222"
rate="25"/>
</VisualCoding>
</MediaFormat>
<MediaInstance id="mediaInstance-15">
<InstanceIdentifier type="mmVISION/PhysicalFileID"
organization="src.ricoh.co.jp">Undefined</InstanceIdentifier>
<MediaLocator xsi:type="TemporalSegmentLocatorType">
<MediaUri>
file://alfa/d.biscaglia/desktop/ProveVideo/tglaziompg.mpg</MediaUri>
<MediaTime>
<MediaRelTimePoint timeBase="../../MediaUri">
P0DT0H0M0S0N25F</MediaRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">
5302</MediaIncrDuration>
</MediaTime>
</MediaLocator>
</MediaInstance>
</MediaProfile>
</MediaInformation>
pag.159
<StructuralUnit id="structuralUnit-16"
href="urn:ricoh:mmVISION:SegmentTypeCS:2.2">
<Name xml:lang="en">description</Name>
</StructuralUnit>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">
P0DT0H0M0S0N25F</MediaRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">6738
</MediaIncrDuration>
</MediaTime>
</AudioVisualSegment>
</MediaSourceDecomposition>
</AudioVisualSegment>
</MediaSourceDecomposition>
<TemporalDecomposition id="temporalDecomposition-20" criteria="structure" overlap="true" gap="true">
<AudioVisualSegment id="structure-21">
<StructuralUnit id="structuralUnit-22" href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en">structure</Name>
</StructuralUnit>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">
P0DT0H0M0S0N25F</MediaRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">6738</MediaIncrDuration>
</MediaTime>
<TemporalDecomposition id="temporalDecomposition-23" criteria="structure" overlap="true"
gap="true">
<AudioVisualSegment id="structure-24">
<MediaLocator type="TemporalSegmentLocatorType">
<Image>http://62.110.204.10/tecaprova/Frame/tg1/tg1introd.jpg</Image>
<MediaUri>rtsp://62.110.204.10:554/tg1.rm</MediaUri>
</MediaLocator>
<StructuralUnit id="structuralUnit-25"
href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en">structure</Name>
</StructuralUnit>
<CreationInformation id="creationInformation-49">
<Creation id="creation-50">
<Title>Servizio1:Introduzione</Title>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Giornalista</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>Filippo Gaudenzi</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>RAI_UNO </GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationDate>
<TimePoint>2002-06-04T14:10:00:000:00</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-53">
<Genre id="genre-56" href="TecaFastXmGenreCS">
pag.160
<Name>Politica Estera</Name>
</Genre>
</Classification>
</CreationInformation>
<TextAnnotation>
<FreeTextAnnotation/>
</TextAnnotation>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">P0DT0H0M0S0N25F</MediaR
elTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">520</MediaIncrDuration>
</MediaTime>
</AudioVisualSegment>
<AudioVisualSegment id="structure-26">
<MediaLocator type="TemporalSegmentLocatorType">
<Image>http://62.110.204.10/tecaprova/Frame/tg1/tg1serv1.jpg</Image>
<MediaUri>rtsp://62.110.204.10:554/tg1.rm</MediaUri>
</MediaLocator>
<StructuralUnit id="structuralUnit-27"
href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en">structure</Name>
</StructuralUnit>
<CreationInformation id="creationInformation-57">
<Creation id="creation-58">
<Title>Servizio 1</Title>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Giornalista</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>Dino Corgona&apos;</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>RAI_UNO </GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationDate>
<TimePoint>2002-06-04T14:10:00:000:00</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-61">
<Genre id="genre-62" href="TecaFastXmGenreCS">
<Name>Politica Estera</Name>
</Genre>
</Classification>
</CreationInformation>
<TextAnnotation>
<FreeTextAnnotation>A Kanasky in Canada vertice del G8</FreeTextAnnotation>
</TextAnnotation>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">P0DT0H0M20S20N25F</Medi
aRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">1596</MediaIncrDuration>
</MediaTime>
</AudioVisualSegment>
pag.161
<AudioVisualSegment id="structure-28">
<MediaLocator type="TemporalSegmentLocatorType">
<Image>http://62.110.204.10/tecaprova/Frame/tg1/tg1introd.jpg</Image>
<MediaUri>rtsp://62.110.204.10:554/tg1.rm</MediaUri>
</MediaLocator>
<StructuralUnit id="structuralUnit-29"
href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en">structure</Name>
</StructuralUnit>
<CreationInformation id="creationInformation-63">
<Creation id="creation-64">
<Title>Servizio2:Introduzione</Title>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Giornalista</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>Filippo Gaudenzi</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>RAI_UNO </GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationDate>
<TimePoint>2002-06-04T14:10:00:000:00</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-67">
<Genre id="genre-68" href="TecaFastXmGenreCS">
<Name>Economia</Name>
</Genre>
</Classification>
</CreationInformation>
<TextAnnotation>
<FreeTextAnnotation/>
</TextAnnotation>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">P0DT0H1M24S16N25F</Medi
aRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">274</MediaIncrDuration>
</MediaTime>
</AudioVisualSegment>
<AudioVisualSegment id="structure-30">
<MediaLocator type="TemporalSegmentLocatorType">
<Image>http://62.110.204.10/tecaprova/Frame/tg1/tg1serv3.jpg</Image>
<MediaUri>rtsp://62.110.204.10:554/tg1.rm</MediaUri>
</MediaLocator>
<StructuralUnit id="structuralUnit-31"
href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en">structure</Name>
</StructuralUnit>
<CreationInformation id="creationInformation-69">
<Creation id="creation-70">
<Title>Servizio 2</Title>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
pag.162
<Name>Giornalista</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>Marzio Quaglino</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>RAI_UNO </GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationDate>
<TimePoint>2002-06-04T14:10:00:000:00</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-73">
<Genre id="genre-74" href="TecaFastXmGenreCS">
<Name>Economia</Name>
</Genre>
</Classification>
</CreationInformation>
<TextAnnotation>
<FreeTextAnnotation>Borsa: attenuati i ribassi dovuti agli scandali finanziari
americani. Nuovo record dell&apos; Euro sul Dollaro </FreeTextAnnotation>
</TextAnnotation>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">P0DT0H1M35S15N25F</Medi
aRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">1725</MediaIncrDuration>
</MediaTime>
</AudioVisualSegment>
<AudioVisualSegment id="structure-32">
<MediaLocator type="TemporalSegmentLocatorType">
<Image>http://62.110.204.10/tecaprova/Frame/tg1/tg1introd.jpg</Image>
<MediaUri>rtsp://62.110.204.10:554/tg1.rm</MediaUri>
</MediaLocator>
<StructuralUnit id="structuralUnit-33"
href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en">structure</Name>
</StructuralUnit>
<CreationInformation id="creationInformation-75">
<Creation id="creation-76">
<Title>Servizio3:Introduzione</Title>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Giornalista</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>Filippo Gaudenzi</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
pag.163
<Name>
<GivenName>RAI_UNO </GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationDate>
<TimePoint>2002-06-04T14:10:00:000:00</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-79">
<Genre id="genre-80" href="TecaFastXmGenreCS">
<Name>Sport</Name>
</Genre>
</Classification>
</CreationInformation>
<TextAnnotation>
<FreeTextAnnotation/>
</TextAnnotation>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">P0DT0H2M44S15N25F</Medi
aRelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">425</MediaIncrDuration>
</MediaTime>
</AudioVisualSegment>
<AudioVisualSegment id="structure-34">
<MediaLocator type="TemporalSegmentLocatorType">
<Image>http://62.110.204.10/tecaprova/Frame/tg1/tg1serv2.jpg</Image>
<MediaUri>rtsp://62.110.204.10:554/tg1.rm</MediaUri>
</MediaLocator>
<StructuralUnit id="structuralUnit-35"
href="urn:ricoh:mmVISION:SegmentTypeCS:4">
<Name xml:lang="en">structure</Name>
</StructuralUnit>
<CreationInformation id="creationInformation-81">
<Creation id="creation-82">
<Title>Servizio 3</Title>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Giornalista</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>Maurizio Colantoni</GivenName>
</Name>
</Agent>
</Creator>
<Creator>
<Role type="GenreType" id="role-87" href="TecaFastXmCreatorCS">
<Name>Emittente</Name>
</Role>
<Agent type="PersonType" id="agent-88">
<Name>
<GivenName>RAI_UNO </GivenName>
</Name>
</Agent>
</Creator>
<CreationCoordinates>
<CreationDate>
<TimePoint>2002-06-04T14:10:00:000:00</TimePoint>
</CreationDate>
</CreationCoordinates>
</Creation>
<Classification id="classification-85">
<Genre id="genre-86" href="TecaFastXmGenreCS">
<Name>Sport</Name>
pag.164
</Genre>
</Classification>
</CreationInformation>
<TextAnnotation>
<FreeTextAnnotation>Mondiali 2002: la finale sar_ Germania - Brasile . Vittoria
del Brasile nelle semifinali contro la Turchia grazie ad un gol di Ronaldo</FreeTextAnnotation>
</TextAnnotation>
<MediaTime>
<MediaRelTimePoint
timeBase="/Mpeg7/ContentDescription/MultimediaContent[1]/AudioVisual[1]/MediaTime">P0DT0H3M1S15N25F</Media
RelTimePoint>
<MediaIncrDuration timeUnit="P0DT0H0M0S1N25F">2198</MediaIncrDuration>
</MediaTime>
</AudioVisualSegment>
</TemporalDecomposition>
</AudioVisualSegment>
</TemporalDecomposition>
</AudioVisual>
</MultimediaContent>
</ContentDescription>
</Mpeg7>
pag.165
APPENDICE B
LISTATI DEL CODICE DELLE INTERFACCE
WEB
Codice dell’interfaccia di gestione del DB.
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<TITLE>Tamino TECA FAST Interface (Input Part)</TITLE>
<script Language="JavaScript">
var defaultDB="/tecafast/teca2002collection";
var defaultPath="/tamino";
var suggestedDatabaseURL=null;
var mylocation=null;
var host="62.110.204.10";
var protocol="http:";
var server="";
var port=80;
suggestedDatabaseURL="http://62.110.204.10"+defaultPath+defaultDB;
if
(window)
{
mylocation=window.location;
if
(mylocation.protocol.match(/^http/)!=null)
{
protocol=mylocation.protocol;
host=mylocation.host;
port=mylocation.port;
}
}
server=protocol+"//"+host;
suggestedDatabaseURL=server+defaultPath+defaultDB;
function setup()
{
if
(suggestedDatabaseURL)
document.forms[0].xxxdbname.value=suggestedDatabaseURL;
}
function setAction(){
var xxaction= document.forms[0].xxxdbname.value;
//alert("Database name will be changed " + xxaction );
document.forms[1].action = xxaction;
defaultStatus = "Database URL set to " + xxaction;
}
</script>
<style type="text/css">
<!-.unnamed1 { font-family: Arial, Helvetica, sans-serif; font-size: xx-small; font-style: normal; line-height: normal; fontweight: normal; text-transform: capitalize; color: #000066; background-color: #99CCFF; text-align: center; verticalalign: middle; word-spacing: normal; white-space: normal; border-style: groove}
-->
</style>
</head>
<BODY BGCOLOR="#99CCFF" LINK="#0000ff" VLINK="#800080" onload="setup()">
<table width="96%" cellpadding="0" cellspacing="0" bgcolor="#FFFFCC" bordercolor="#FF9900" align="center">
<tr>
<td width="7%" height="34"><img src="http://images.elis.org/vivai/vivai120x40.gif" width="120"
height="40"></td>
<td width="83%" height="34">
<div align="center">
<p> <font color="#000066"><i><b><font size="4">TV NEWS ARCHIVE&nbsp;</font>
pag.166
Gestione DB</b></i></font></p>
</div>
</td>
<td align="right" width="10%" height="34"><img src="http://images.elis.org/logo/rai-83x49.gif">
</td>
</tr>
</table>
<table cellspacing="10" align="center" width="882" bordercolor="#FFCC66" bgcolor="#FFFFCC" height="300">
<tr>
<td bgcolor="#99CCFF" height="231" width="858">
<form>
<b> <font face="Arial, Helvetica, sans-serif" size="2" color="#000066">URL
del DataBase XML</font><font face="Arial, Helvetica, sans-serif" size="2"></font><i><font face="Arial,
Helvetica, sans-serif" size="2">
</font></i></b><font face="Arial, Helvetica, sans-serif" size="2"><font size="1" color="#FF0000">(selezionare
il DB e la collezione: impostare prima di eseguire):</font></font><b><br>
</b>
<input type=text size=52 name=xxxdbname value="http://62.110.204.10/tamino/tecafast/teca2002collection">
<input type="button" value="Imposta DB" onclick="setAction()">
<br>
</form>
<form action="http://localhost/tamino/my-database" method=POST enctype="multipart/form-data"
target=xqlout.htm>
<input type="hidden" name="_encoding" value="utf-8">
<table width="519">
<tr>
<td width="279">
<tr>
<td bgcolor="#FFFFCC" width="279">
<div align="center"><font size="1" face="Arial, Helvetica, sans-serif" color="#330033"><b>Processa
File:</b></font></div>
<td width="169">&nbsp;
<input type=file size=30 name=_Process>
<td width="51">
<tr>
<td bgcolor="#FFFFCC" width="279">
<div align="center"><font size="1" face="Arial, Helvetica, sans-serif"
color="#330033"><b>Cancella:</b></font></div>
<div align="center"><font size="1" face="Arial, Helvetica, sans-serif"
color="#330033"><b>(//Mpeg7[@ino:id=])</b></font></div>
<td width="169">&nbsp;
<input type=text size=30 name=_Delete>
<td width="51">
<tr>
<td bgcolor="#FFFFCC" width="279">
<div align="center"><font face="Arial, Helvetica, sans-serif" size="1" color="#000066"><b>Definisci
Schema:</b></font></div>
<td width="169">&nbsp;
<input type=file size=30 name=_Define>
<td width="51">
</tr>
<tr>
<td bgcolor="#FFFFCC" width="279">
<div align="center"><font face="Arial, Helvetica, sans-serif" size="1" color="#000066"><b>Elimina
Schema:</b></font></div>
<td width="169">&nbsp;
<input type=text size=30 name=_Undefine>
<td width="51">
</tr>
<tr>
<td bgcolor="#FFFFCC" width="279">
&nbsp;
<td width="169">
<td width="51">
</tr>
<tr>
<td width="279">&nbsp;
<input type=submit value=Esegui name="submit">
pag.167
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <input type=reset value=Cancella name="reset">
&nbsp;&nbsp;
<td width="169">
<td width="51">
</tr>
</table>
</form>
</table>
</body>
</html>
<!-- ..... -->
<form name="form_parametri">
<!-- ..... -->
<input name="campoutente1" type="text"/>
<!-- ..... -->
<select name="select_criterioutente" size="1">
<option value="//AudioVisual//Title" selected>su
Titolo</option>
<option value="//AudioVisual//Creator//GivenName">su
Autori</option>
<option value="//AudioVisual//FreeTextAnnotation">su
Descrizioni</option>
</select>
<!-- ..... -->
<input type="button" value="invia" onClick="sendQueryServlet()" name="button"/>
<input type="reset" value="azzera" name="reset"/>
</form>
<!-- ..... -->
</BODY>
</HTML>
pag.168
Codice dell’interfaccia di ricerca sull'intero TG.
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<TITLE>Tamino TECA FAST Interface (Input Part)</TITLE>
<script language="JavaScript">
function sendQuery() {
var temp=document.form_parametri;
var flag;
var query="http://62.110.204.10/servlets/tecafast2style/tamino/tecafast/teca2002collection/Mpeg7?_xql=";
var xsltransf="&_xslsrc=http://62.110.204.10/tecaprova/xsl/TGdisplay.xsl";
var criteriostart="Mpeg7[//Creator[Role/Name='Emittente']//GivenName";
var criteriostart2="//Creator[Role/Name='Speaker']//GivenName";
var criteriostart1="//MediaTimePoint";
var criteriovalorestart="'*";
var criteriovaloreend="*'";
var criterioconfronto="~=";
flag=0;
if (temp.emittente.value!="" || temp.speaker.value!="" || temp.anno.value!="" ||
temp.mese.value!="" || temp.giorno.value!="" || temp.ora.value!="") {
flag++;
query= query + criteriostart + criterioconfronto + criteriovalorestart +
temp.emittente.value + criteriovaloreend + "and" + criteriostart2 + criterioconfronto + criteriovalorestart +
temp.speaker.value + criteriovaloreend + "and" + criteriostart1+ criterioconfronto + criteriovalorestart +
temp.anno.value +temp.mese.value+temp.giorno.value+ temp.ora.value+ criteriovaloreend + "]"+ xsltransf ;
}
switch (flag) {
case 0:{ alert("Inserisci almeno un valore!"); break; }
case 1:{
<!-- alert("Sto inviano la query: " + query); -->
window.open(query);
break;
}
default: alert("Hai inserito pi?i un valore!");
}
}
</script>
</head>
<BODY BGCOLOR="#99CCFF" LINK="#0000ff" VLINK="#800080" >
<table width="96%" cellpadding="0" cellspacing="0" bgcolor="#FFFFCC" bordercolor="#FF9900" align="center">
<tr>
<td width="7%" height="34"><img src="http://62.110.204.10/tecaprova/immagini/tr_vivai168x70.gif" width="120"
height="40"></td>
<td width="83%" height="34">
<div align="center">
<p> <font color="#000066"><i><b><font size="4">TV NEWS ARCHIVE&nbsp;</font>
&nbsp;</b></i></font></p>
</div>
</td>
<td align="right" width="10%" height="34"><img src="http://62.110.204.10/tecaprova/immagini/rai-83x49.gif">
</td>
</tr>
</table>
<form name="form_parametri" >
<table cellspacing="10" align="center" width="882" bordercolor="#FFCC66" bgcolor="#FFFFCC" height="300">
<tr>
<td bgcolor="#99CCFF" height="231" width="858">
<div style="position: absolute; top: 75; left: 54; width: 764; height: 316">
<table width="764" height="185">
<tr>
<td width="1650" height="71"><i><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EMITTENTE</b></i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;
pag.169
<select name="emittente" size="1">
<option value=""></option>
<option value="RAI_UNO">RAI UNO</option>
<option value="RAI_DUE">RAI DUE</option>
<option value="RAI_TRE">RAI TRE</option>
</select>
</tr>
<tr>
<td width="983" height="67"><i><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DATA</b></i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<select name="anno" size="1">
<option value=""></option>
<option value="2001">2001</option>
<option value="2002">2002</option>
</select>&nbsp;&nbsp; <select name="mese" size="1">
<option value=""></option>
<option value="-01-">GENNAIO</option>
<option value="-02-">FEBBRAIO</option>
<option value="-03-">MARZO</option>
<option value="-04-">APRILE</option>
<option value="-05-">MAGGIO</option>
<option value="-06-">GIUGNO</option>
<option value="-07-">LUGLIO</option>
<option value="-08-">AGOSTO</option>
<option value="-09-">SETTEMBRE</option>
<option value="-10-">OTTOBRE</option>
<option value="-11-">NOVEMBRE</option>
<option value="-12-">DICEMBRE</option>
</select>&nbsp;&nbsp; <select name="giorno" size="1">
<option value=""></option>
<option value="01">1</option>
<option value="02">2</option>
<option value="03">3</option>
<option value="04">4</option>
<option value="05">5</option>
<option value="06">6</option>
<option value="07">7</option>
<option value="08">8</option>
<option value="09">9</option>
<option value="10">10</option>
<option value="11">11</option>
<option value="12">12</option>
<option value="13">13</option>
<option value="14">14</option>
<option value="15">15</option>
<option value="16">16</option>
<option value="17">17</option>
<option value="18">18</option>
<option value="19">19</option>
<option value="20">20</option>
<option value="21">21</option>
<option value="22">22</option>
<option value="23">23</option>
<option value="24">24</option>
<option value="25">25</option>
<option value="26">26</option>
<option value="27">27</option>
<option value="28">28</option>
<option value="29">29</option>
<option value="30">30</option>
<option value="31">31</option>
</select>
</tr>
<tr>
<td width="478" height="54"><i><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ORA</b></i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
pag.170
<select name="ora" size="1">
<option value=""></option>
<option value="08">8:00</option>
<option value="14">14:00</option>
<option value="20">20:00</option>
</select>
&nbsp;&nbsp;
</tr>
<tr>
<td width="478" height="53"><p><i><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SPEAKER</b></i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input name="speaker" type="text" size="35"/>
</p>
</tr>
<tr>
<td width="849" height="27">
<p>
&nbsp;
<p>
&nbsp;
<p>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type=submit value=invia onClick="sendQuery()" name="button" >
<input type=reset value=azzera name="reset" >
</tr>
</table>
</div>
</form>
</table>
</body>
</html>
pag.171
Codice dell’interfaccia di ricerca sul singolo servizio giornalistico
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<TITLE>Tamino TECA FAST Interface </TITLE>
<script language="JavaScript">
function sendQuery() {
var temp=document.form_parametri;
var flag;
var
query="http://62.110.204.10/servlets/tecafast2style/tamino/tecafast/teca2002collection/Mpeg7?_xql=";
var xsltransf="&_xslsrc=http://62.110.204.10/tecaprova/xsl/TGservizi.xsl";
var
criteriostart="Mpeg7//AudioVisual/TemporalDecomposition/AudioVisualSegment/TemporalDecomposition/AudioVisua
lSegment[//GivenName";
var criteriostart1="//Name";
criteriostart2="//GivenName";
var criteriostart3="//FreeTextAnnotation";
var criteriovalorestart="'*";
var criteriovaloreend="*'";
var criterioconfronto="~=";
flag=0;
if (temp.emittente.value!="" || temp.servizio.value!="" || temp.descrizione.value!="" ||
temp.giornalista.value!="") {
flag++;
query= query + criteriostart + criterioconfronto + criteriovalorestart +
temp.emittente.value + criteriovaloreend + "and" + criteriostart1+ criterioconfronto + criteriovalorestart +
temp.servizio.value + criteriovaloreend +"and"+ criteriostart2 + criterioconfronto +criteriovalorestart+
temp.giornalista.value+ criteriovaloreend + "and"+criteriostart3+criterioconfronto+
criteriovalorestart+temp.descrizione.value + criteriovaloreend + "]"+ xsltransf ;
}
switch (flag) {
case 0:{ alert("Inserisci almeno un valore!"); break; }
case 1:{
<!-- alert("Sto inviano la query: " + query); -->
window.open(query);
break;
}
default: alert("Hai inserito pi?i un valore!");
}
}
</script>
</head>
<BODY BGCOLOR="#99CCFF" LINK="#0000ff" VLINK="#800080" >
<table width="96%" cellpadding="0" cellspacing="0" bgcolor="#FFFFCC" bordercolor="#FF9900" align="center">
<tr>
<td width="7%" height="34"><img src="http://images.elis.org/vivai/vivai120x40.gif" width="120"
height="40"></td>
<td width="83%" height="34">
<div align="center">
<p> <font color="#000066"><i><b><font size="4">TV NEWS ARCHIVE&nbsp;</font>
eX</b></i></font><font color="#000066"><i><b>perimental
Metadata Engine</b></i></font></p>
</div>
</td>
<td align="right" width="10%" height="34"><img src="http://images.elis.org/logo/rai-83x49.gif">
</td>
</tr>
</table>
<form name="form_parametri" >
pag.172
<table cellspacing="10" align="center" width="882" bordercolor="#FFCC66" bgcolor="#FFFFCC" height="300">
<tr>
<td bgcolor="#99CCFF" height="231" width="858">
<table width="576" height="1">
<tr>
<td width="279" height="65"><b><i>EMITTENTE&nbsp;</i></b>
<td width="226" height="65">
<select name="emittente" size="1">
<option value=""></option>
<option value="RAI_UNO">RAI UNO</option>
<option value="RAI_DUE">RAI DUE</option>
<option value="RAI_TRE">RAI TRE</option>
</select>
</tr>
<tr>
<td width="279" height="77">
<p><b><i>TIPO DI SERVIZIO</i></b></p>
<td width="226" height="77">
<p>
<select name="servizio" size="1">
<option value=""></option>
<option value="attualit">ATTUALITA'</option>
<option value="cronaca">CRONACA</option>
<option value="economia">ECONOMIA</option>
<option value=" politica">POLITICA</option>
<option value="sport">SPORT</option>
<option value="storia">STORIA</option>
</select>&nbsp;
</p>
</tr>
<tr>
<td width="279" height="1"><b><i>DESCRIZIONE dei SERVIZI</i></b>
<p><font size="1">(INSERISCI UNA PAROLA O UNA STRINGA) </font>
<p>&nbsp;
<td width="226" height="1">
<input name="descrizione" type="text" / size="44">
</tr>
<tr>
<td width="279" height="8"><b><i>GIORNALISTA</i></b>
<p><font size="1">(INSERISCI IL NOME) </font>
</p>
<p>&nbsp;
<td width="226" height="8">
<input name="giornalista" type="text" / size="44">
</tr>
</table>
</form>
</table>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type=submit value=invia onClick="sendQuery()" name="button" >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<input type=reset value=azzera name="reset" > </p>
</body>
</html>
pag.173
APPENDICE C
LISTATI DEL CODICE DEI FOGLI DI STILE XSL
Codice del foglio di stile XSL A
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
xmlns:xql="http://metalab.unc.edu/xql/"
xmlns:mpeg="http://www.mpeg7.org/2001/MPEG-7_Schema"
exclude-result-prefixes="xql ino mpeg"
version="1.0">
<xsl:template match="/">
<!-- si definiscono i parametri di formattazione al livello radice -->
<html>
<body alink="#ff3300" link="#ffcc00" text="#ffffff" vlink="#ff9900"
background="/SITOTECA/foglie.jpg">
<div align="center">
<table cellpadding="5" cellspacing="0" border="0" width="100%" height="104" vspace="0" hspace="0">
<tbody>
<tr>
<td width="15" height="100%" align="right" valign="top"><img src="/leftline01.jpg" width="15"
height="100%"/></td>
<td valign="top"><img src="/SITOTECA/rai-83x49.gif" width="83" height="49" />
<br /><br /><img src="/SITOTECA/elisicon.gif" width="67" height="56" />
<br /><br /><img src="/SITOTECA/tr_vivai168x70.gif" width="137" height="49" />
<br />
<font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC66"><b><font
color="#000066"><font color="#990000"></font><font color="#990000"></font>
<br /><font color="#990000" size="5">TV </font><font color="#990000" size="5"> NEWS</font>
<br /><font color="#990000" size="5">
ARCHIVE</font></font></b></font>
<br />
<br />
<br />
<br />
<br />
<font color="#000000">Internet TV Project
<br />Vivai d'Impresa
<br />Elis - RAI
</font>
</td>
<td width="100%">
<div align="center"> <table width="500">
<tr>
<td align="left"><font face="Verdana, Arial, Helvetica, sans-serif" size="4" color="#330033">Risultati
trovati:</font></td>
</tr>
</table>
<br />
<xsl:for-each select="//mpeg:Mpeg7">
<table bgcolor="#330033" bordercolor="#000000" cellpadding="5" cellspacing="0" border="0" width="500">
<xsl:variable name="number"> <xsl:value-of select="./@ino:id"/>
</xsl:variable>
<xsl:variable
name="query">http://62.110.204.10/servlets/tecafast2style/tamino/tecafast/teca2002collection?_xql=Mpeg7[
@ino:id=</xsl:variable>
<xsl:variable name="style">&amp;_xslsrc=http://62.110.204.10/tecaprova/xsl/tglazioProva.xsl</xsl:variable>
<xsl:variable name="style1">&amp;_xslsrc=http://62.110.204.10/tecaprova/xsl/TGmediaprof.xsl</xsl:variable>
<tr>
<td valign="top" bgcolor="#330033"> <font color="#ffcc00" size="2"><xsl:value-of select="position()"/>
)</font></td>
<td bgcolor="#330033" valign="top" width="80%"> <font color="#ffcc00" face="Verdana, Arial, Helvetica,
sans-serif" size="2">
pag.174
<b> <font color="#999999"> Titolo: </font></b>
<a target="_blank">
<xsl:attribute name="href"> <xsl:value-of select="concat($query,$number,']',$style)"/>
</xsl:attribute> <xsl:value-of select="mpeg:ContentDescription//mpeg:Title"/>
</a> </font>
<br/>
<font color="#ffcc00" face="Verdana, Arial, Helvetica, sans-serif" size="2">
<b><font color="#999999" size="2"> Emittente: </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:Creator[mpeg:Role/mpeg:Name='Emittente']/mpeg:Agent/mpeg:Nam
e/mpeg:GivenName"/></b> <br />
<b><font color="#999999" size="2"> Speaker </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:Creator[mpeg:Role/mpeg:Name='Speaker']/mpeg:Agent/mpeg:Name
/mpeg:GivenName"/></b>
<b><font color="#999999" size="2"> <br />
Data e ora di trasmissione: </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:MediaTime/mpeg:MediaTimePoint"/>
</b> <b><font color="#999999" size="2"> <br />
Durata: </font> <script language="JavaScript">
var temp = "<xsl:value-of select="mpeg:ContentDescription//mpeg:MediaTime/mpeg:MediaDuration"/>";
var minuti;
var secondi;
if(temp.substr(7,1) == "M" ){minuti = temp.substr(6,1);
if(temp.substr(9,1) == "S"){secondi = temp.substr(8,1)}
else{secondi = temp.substr(8,2)}
}
else
{minuti = temp.substr(6,2);
if(temp.substr(10,1) == "S"){secondi = temp.substr(9,1)}
else{secondi = temp.substr(9,2)}}
TIME=minuti + ":" + secondi
document.write(TIME)
</script>
</b> </font> <br />
<a target="_blank">
<xsl:attribute name="href"> <xsl:value-of select="concat($query,$number,']',$style1)"/>
</xsl:attribute> MEDIA PROFILE
</a>
</td>
</tr>
</table>
<br />
</xsl:for-each> </div>
</td>
<td width="15" align="right" valign="top"><img src="/leftline01.jpg" width="15" height="550"/></td>
</tr>
</tbody>
</table>
<br />
<br />
<br /></div>
</body>
</html>
</xsl:template>
<xsl:template match="/ino:response/ino:message"/>
<xsl:template match="/ino:response/xql:query"/>
</xsl:stylesheet>
pag.175
Codice del foglio di stile XSL B
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
xmlns:xql="http://metalab.unc.edu/xql/"
xmlns:mpeg="http://www.mpeg7.org/2001/MPEG-7_Schema"
exclude-result-prefixes="xql ino mpeg"
version="1.0">
<xsl:template match="/">
<xsl:variable name="query" select="mpeg:MediaLocator/mpeg:MediaUri"></xsl:variable>
<html>
<head>
<title>Nuova pagina 1</title>
</head>
<body background="http:\\62.110.204.10\tecaprova\immagini\foglie.jpg">
<xsl:for-each select="//mpeg:Mpeg7">
<table border="1" bordercolor="#00003299" width="75%" height="40" bgcolor="#99CCFF" align="center"
cellpadding="1">
<tr>
<td width="100%" bgcolor="#00003299"><strong><font color="yellow"><xsl:value-of
select="mpeg:ContentDescription/mpeg:MultimediaContent/mpeg:AudioVisual/mpeg:CreationInformation/mpe
g:Creation/mpeg:Title"/></font></strong> </td>
</tr>
<tr>
<td width="100%" bgcolor="#99CCFF"><strong>Emittente:</strong><xsl:value-of
select="mpeg:ContentDescription//mpeg:Creator/mpeg:Agent/mpeg:Name/mpeg:GivenName"/><br></br>
<strong> Speaker:</strong><xsl:value-of
select="mpeg:ContentDescription//mpeg:Creator[mpeg:Role/mpeg:Name='Speaker']/mpeg:Agent/mpeg:Name
/mpeg:GivenName"/><br></br><strong>
Data e ora:</strong><xsl:value-of
select="mpeg:ContentDescription//mpeg:MediaTime/mpeg:MediaTimePoint"/><br></br>
<strong>Durata: </strong> <script language="JavaScript">
var nframeE = "<xsl:value-of
select="mpeg:ContentDescription//mpeg:MediaTime/mpeg:MediaIncrDuration"/>";
var tempE;
var secondiE;
var minutiE;
var TIME;
var frameE;
tempE = Math.floor(nframeE/25)
frameE= nframeE - tempE*25
if (tempE &gt; 60 ) { minutiE= Math.floor(tempE/60);
secondiE=tempE - minutiE*60;}
else{ secondiE = tempE;
minutiE=0;}
TIME=minutiE + ":" + secondiE
document.write(TIME)
</script>
</td>
</tr>
</table>
<br></br>
<br></br>
<table border="1" bordercolor="#00003299" width="75%" height="40" bgcolor="#99CCFF" align="center"
cellpadding="1">
<tr bgcolor="#00003299">
<td width="25%" height="17" align="center"><strong><font
color="yellow">Servizio n</font></strong></td>
<td width="30%" height="17" align="center"><strong><font
color="yellow">Descrizione</font></strong></td>
<td width="30%" height="17"><strong><font
color="yellow">Giornalista</font></strong></td>
<td width="25%" height="17"><strong><font
color="yellow">Durata</font></strong></td>
pag.176
<td width="25%" height="17"><strong><font
color="yellow">Genere</font></strong></td>
<td width="70%" height="70" align="center"><strong><font
color="yellow">Filmato</font></strong></td>
</tr>
<xsl:for-each
select="mpeg:ContentDescription/mpeg:MultimediaContent/mpeg:AudioVisual/mpeg:TemporalDecomposition
/mpeg:AudioVisualSegment/mpeg:TemporalDecomposition/mpeg:AudioVisualSegment">
<tr>
<td width="35%" height="17"><xsl:value-of
select="mpeg:CreationInformation/mpeg:Creation/mpeg:Title"/></td>
<td width="50%" height="17"><br></br>
<xsl:value-of select="mpeg:TextAnnotation/mpeg:FreeTextAnnotation"/></td>
<td width="70%" height="17"><br></br>
<xsl:value-of
select="mpeg:CreationInformation//mpeg:Creator/mpeg:Agent/mpeg:Name/mpeg:GivenName"/></td>
<td width="70%" height="17" align="center"><br></br>
<script language="JavaScript">
var nframeE = "<xsl:value-of select="mpeg:MediaTime/mpeg:MediaIncrDuration"/>";
tempE = Math.floor(nframeE/25)
frameE= nframeE - tempE*25
if (tempE &gt; 60 ) { minutiE= Math.floor(tempE/60);
secondiE=tempE - minutiE*60;
}
else{ secondiE = tempE;
minutiE=0;
}
TIME=minutiE + ":" + secondiE
document.write(TIME)
</script>
</td>
<td width="70%" height="17"><br></br>
<xsl:value-of select="mpeg:CreationInformation/mpeg:Classification/mpeg:Genre/mpeg:Name"/></td>
<td width="70%" height="17">
<script language="JavaScript">
var tempS = "<xsl:value-of select="mpeg:MediaTime/mpeg:MediaRelTimePoint"/>";
var minutS=0;
var secondiS=0;
var minut=0;
var secondi=0
var video = "Video";
var secondiE;
var tempE ;
var minutiE;
nframeE= <xsl:value-of select="mpeg:MediaTime/mpeg:MediaIncrDuration"/>
var collegamento = "<xsl:value-of select="mpeg:MediaLocator/mpeg:MediaUri"/>";
if(tempS.substr(7,1) == "M" ){minutiS = tempS.substr(6,1);
if(tempS.substr(9,1) == "S"){secondiS = tempS.substr(8,1)}
else{secondiS = tempS.substr(8,2)}
}
else
{minutiS = tempS.substr(6,2);
if(tempS.substr(10,1) == "S"){secondiS = tempS.substr(9,1)}
else{secondiS = tempS.substr(9,2)}
}
tempE = Math.floor(nframeE/25)
frameE= nframeE - tempE*25
if (tempE &gt; 60 ) { minutiE= Math.floor(tempE/60);
secondiE=tempE - minutiE*60;}
else{ secondiE = tempE;
minutiE=0;}
minuti=Math.floor(minutiS);
secondi= Math.floor(secondiS);
if (secondi &gt; 60 ) { minuti++;
secondi=secondi-60;}
minutiE= minutiE + minuti
secondiE= secondiE + secondi
if (secondiE &gt; 60 ) { minutiE++;
secondiE=secondiE-60;}
pag.177
TIME= collegamento+ "?start="+ minutiS + ":" + secondiS +"&amp;end=" + minutiE +":" + secondiE+ "," +
frameE
document.write(video.link(TIME))
</script>
<br></br>
<img border="0" width="100" height="70"> <xsl:attribute name="src"> <xsl:value-of
select="mpeg:MediaLocator/mpeg:Image"/></xsl:attribute> </img></td>
</tr>
</xsl:for-each>
</table>
</xsl:for-each>
</body>
</html>
</xsl:template>
<xsl:template match="/ino:response/ino:message"/>
<xsl:template match="/ino:response/xql:query"/>
</xsl:stylesheet>
<td valign="top"><img src="/SITOTECA/rai-83x49.gif" width="83" height="49" />
<br /><br /><img src="/SITOTECA/elisicon.gif" width="67" height="56" />
<br /><br /><img src="/SITOTECA/tr_vivai168x70.gif" width="137" height="49" />
se/xql:query"/>
</xsl:stylesheet>
pag.178
Codice del foglio di stile XSL C
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xql="http://metalab.unc.edu/xql"
xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
xmlns:mpeg="http://www.mpeg7.org/2001/MPEG-7_Schema"
exclude-result-prefixes="xql ino mpeg">
<xsl:template match="/">
<!-- si definiscono i parametri di formattazione al livello radice -->
<html>
<head>
<title>Scheda Programma</title>
</head>
<body alink="#ff3300" link="#ffcc33" text="#ffffff" vlink="#ff9900" background="/SITOTECA/foglie.jpg">
<div align="center">
<table cellpadding="5" cellspacing="0" border="0" width="100%" height="104" vspace="0" hspace="0">
<tbody>
<tr>
<td width="15" height="100%" align="right" valign="top"><img src="/leftline01.jpg" width="15"
height="100%"/></td>
<td valign="top"><img src="/SITOTECA/rai-83x49.gif" width="83" height="49" />
<br /><br /><img src="/SITOTECA/elisicon.gif" width="67" height="56" />
<br /><br /><img src="/SITOTECA/tr_vivai168x70.gif" width="137" height="49" />
<br />
<br />
<br />
<br />
<font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC66"><b><font
color="#000066">&lt;<font color="#990000">M</font>peg-<font color="#990000">7</font>/&gt;
<br /><font color="#990000">M</font>etadata e<font color="#990000">X</font>perimental
<br /><font color="#990000">R</font>epository </font></b></font>
<br />
<br />
<br />
<font color="#000000">Internet TV Project
<br />Vivai d'Impresa
<br />Elis - RAI
</font>
</td>
<td width="100%">
<div align="center">
<xsl:for-each select="//mpeg:Mpeg7">
<table bgcolor="#330033" bordercolor="#000000" cellpadding="5" cellspacing="1" border="0" width="500">
<tbody>
<tr bgcolor="#330033">
<td align="left" colspan="2" width="574"> <font face="Verdana, Arial, Helvetica, sans-serif" size="2">
<b> <font color="#ffcc00"> DESCRIZIONE: </font> </b> </font> <br />
</td>
</tr>
<tr bgcolor="#000066">
<td bgcolor="#330033"> <font color="#999999" size="2"> </font> </td>
<td valign="top" width="80%" bgcolor="#330033"> <font color="#ffcc00" face="Verdana, Arial, Helvetica,
sans-serif" size="2">
<b> <font color="#999999"> Titolo: </font> <xsl:value-of select="mpeg:ContentDescription//mpeg:Title"/>
</b> </font> <br />
<font color="#ffcc00" face="Verdana, Arial, Helvetica, sans-serif" size="2">
</font>
<font color="#ffcc00" face="Verdana, Arial, Helvetica, sans-serif" size="2">
<b><font color="#999999" size="2"> Emittente: </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:Creator[mpeg:Role/mpeg:Name='Emittente']/mpeg:Agent/mpeg:Nam
e"/></b>
<b><font color="#999999" size="2"> <br />
pag.179
Data e ora di trasmissione: </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:MediaTime/mpeg:MediaTimePoint"/>
</b> <b>
</b> </font> </td>
</tr>
</tbody>
</table>
<br />
<hr width="500" color="black" size="1"/>
<br />
<table border="0" cellpadding="5" width="500">
<tr bgcolor="#000066">
<td align="center" valign="top" width="20%" colspan="2"> <b> <font color="#00ccff" face="Verdana, Arial,
Helvetica, sans-serif" size="2">
CREATION INFORMATION </font> </b> </td>
</tr>
<xsl:for-each
select="//mpeg:ContentDescription//mpeg:AudioVisual/mpeg:CreationInformation/mpeg:Creation/mpeg:Creat
or">
<tr>
<td valign="top" width="20%" bgcolor="#000066"> <b> <font color="#00ccff" face="Verdana, Arial,
Helvetica, sans-serif" size="2">
<xsl:value-of select="mpeg:Role/mpeg:Name"/> </font> </b> </td>
<td width="80%" bgcolor="#330033"><font color="#00ccff" face="Verdana, Arial, Helvetica, sans-serif"
size="2">
<xsl:value-of select="mpeg:Agent/mpeg:Name"/></font> </td>
</tr>
</xsl:for-each>
</table>
<br />
<table border="0" cellpadding="5" width="500">
<tr bgcolor="#000066">
<td colspan="2" align="center" valign="top" width="20%"> <b> <font color="#00ccff" face="Verdana, Arial,
Helvetica, sans-serif" size="2">
MEDIA INFORMATION </font> </b> </td>
</tr>
<tr>
<td valign="top" width="20%" bgcolor="#000066"> <b> <font color="#00ccff" face="Verdana, Arial,
Helvetica, sans-serif" size="2">
Media Format: </font> </b> </td>
<td width="80%" bgcolor="#330033"> <font face="Verdana, Arial, Helvetica, sans-serif" size="2">
<font color="#808080">[Content]] </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:MediaFormat/mpeg:Content"/>
<br />
<font color="#808080">[File Format] </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:MediaFormat/mpeg:FileFormat"/>
<br />
<font color="#808080">[System] </font>
<xsl:value-of select="mpeg:ContentDescription//mpeg:MediaFormat/mpeg:System"/>
<br />
<font color="#808080">[Medium] </font> <xsl:value-of
select="mpeg:ContentDescription//mpeg:MediaFormat/mpeg:Medium"/>
<br />
<font color="#808080">[FileSize] </font>
<xsl:value-of select="mpeg:ContentDescription//mpeg:MediaFormat/mpeg:FileSize"/> bit
<br /><font color="#808080">[BitRate] </font>
<xsl:value-of select="mpeg:ContentDescription//mpeg:MediaFormat/mpeg:BitRate"/>
<br />
[VisualCoding] :
<br /><font color="#808080">[Format] </font>
<xsl:value-of select="mpeg:ContentDescription//mpeg:VisualCoding/mpeg:Format"/>
<br /><font color="#808080">[FrameWidth] </font>
<xsl:value-of select="mpeg:ContentDescription//mpeg:VisualCoding//@width"/>
<br /><font color="#808080">[FrameHeight]</font>
<xsl:value-of select="mpeg:ContentDescription//mpeg:VisualCoding//@height"/>
<br /><font color="#808080">[AspectRatio] Width:</font>
<xsl:value-of select="mpeg:ContentDescription//mpeg:VisualCoding//@aspectRatio"/>
<br /><font color="#808080">[FrameRate] </font>
pag.180
<xsl:value-of select="mpeg:ContentDescription//mpeg:VisualCoding//@rate"/>
<br />
</font>
</td>
</tr>
</table>
<br />
<table border="0" cellpadding="2" width="500">
<tr bgcolor="#000066">
<td colspan="2" align="center" valign="top" width="20%"> <b> <font color="#00ccff" face="Verdana, Arial,
Helvetica, sans-serif" size="2">
USAGE INFORMATION </font> </b> </td>
</tr>
<tr>
<td valign="top" width="20%" bgcolor="#000066"> <b> <font color="#00ccff" face="Verdana, Arial,
Helvetica, sans-serif" size="2">
Rights: </font> </b> </td>
<td width="80%" bgcolor="#330033"> <font face="Verdana, Arial, Helvetica, sans-serif" size="2">
<font color="#808080">[IDOrganization] </font> <xsl:value-of
select="//mpeg:ContentDescription//mpeg:UsageInformation/mpeg:Rights/mpeg:RightsId/mpeg:IDOrganizatio
n/mpeg:Name"/>
<br />
<font color="#808080">[IDName] </font>
<xsl:value-of
select="//mpeg:ContentDescription//mpeg:UsageInformation/mpeg:Rights/mpeg:RightsId/mpeg:IDName/mpe
g:Name"/>
<br /><font color="#808080">[UniqueID] </font>
<xsl:value-of
select="//mpeg:ContentDescription//mpeg:UsageInformation/mpeg:Rights/mpeg:RightsId/mpeg:UniqueID"/>
<br /><br />
</font> </td>
</tr>
</table>
<br /><br />
</xsl:for-each>
</div>
</td>
<td width="15" align="right" valign="top"><img src="/leftline01.jpg" width="15" height="550"/></td>
</tr>
</tbody>
</table>
<br />
<br />
<br />
</div>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
pag.181
Codice del foglio di stile XSL D
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
xmlns:xql="http://metalab.unc.edu/xql/"
xmlns:mpeg="http://www.mpeg7.org/2001/MPEG-7_Schema"
exclude-result-prefixes="xql ino mpeg"
version="1.0">
<xsl:template match="/" >
<html>
<head>
<title>Nuova pagina 1</title>
</head>
<body background="/SITOTECA/foglie.jpg">
<div align="center">
<table cellpadding="5" cellspacing="0" border="0" width="100%" height="104" vspace="0" hspace="0">
<tbody background="/SITOTECA/foglie.jpg">
<tr>
<td width="15" height="100%" align="right" valign="top"><img src="/leftline01.jpg" width="15"
height="100%"/></td>
<td valign="top"><img src="/SITOTECA/rai-83x49.gif" width="83" height="49" />
<br /><br /><img src="/SITOTECA/elisicon.gif" width="67" height="56" />
<br /><br /><img src="/SITOTECA/tr_vivai168x70.gif" width="137" height="49" />
<br />
<font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC66"><b><font
color="#000066"><font color="#990000"></font><font color="#990000"></font>
<br /><font color="#990000" size="5">TV </font><font color="#990000" size="5"> NEWS</font>
<br /><font color="#990000" size="5">
ARCHIVE</font></font></b></font>
<br />
<br />
<br />
<br />
<br />
<font color="#000000">Internet TV Project
<br />Vivai d'Impresa
<br />Elis - RAI
</font>
</td>
<td width="100%">
<div align="center"> <table width="500">
<tr>
<td align="left"><font face="Verdana, Arial, Helvetica, sans-serif" size="4" color="#330033">Risultati
trovati:</font></td>
</tr>
</table>
<br />
<table border="1" bordercolor="#00003299" width="100%" height="40" bgcolor="#99CCFF" align="center"
cellpadding="1">
<tr bgcolor="#00003299">
<td width="25%" height="17" align="center"><strong><font
color="yellow">Servizio n°</font></strong></td>
<td width="30%" height="17" align="center"><strong><font
color="yellow">Descrizione</font></strong></td>
<td width="25%" height="17" align="center"><strong><font
color="yellow">Scheda TG</font></strong></td>
<td width="30%" height="17"><strong><font
color="yellow">Giornalista</font></strong></td>
<td width="25%" height="17"><strong><font
color="yellow">Durata</font></strong></td>
<td width="25%" height="17"><strong><font
color="yellow">Genere</font></strong></td>
<td width="70%" height="70" align="center"><strong><font
color="yellow">Filmato</font></strong></td>
pag.182
</tr>
<xsl:for-each select="//AudioVisualSegment">
<tr>
<td width="25%" height="17"><xsl:value-of select="CreationInformation/Creation/Title"/></td>
<td width="30%" height="17"><br></br>
<xsl:value-of select="TextAnnotation/FreeTextAnnotation"/></td>
<td width="25%" height="17"><a target="_blank">
<xsl:variable name="valore"> <xsl:value-of select="./@ino:id"/>
</xsl:variable>
<xsl:variable
name="query">http://62.110.204.10/servlets/tecafast2style/tamino/tecafast/teca2002collection?_xql=Mpeg7[
@ino:id=</xsl:variable>
<xsl:variable name="style">]&amp;_xslsrc=http://62.110.204.10/tecaprova/xsl/tglazioProva.xsl</xsl:variable>
<xsl:attribute name="href"> <xsl:value-of select="concat($query,$valore,$style)"/>
</xsl:attribute>
scheda TG </a></td>
<td width="30%" height="17"><br></br>
<xsl:value-of select="CreationInformation//Creator/Agent/Name/GivenName"/></td>
<td width="25%" height="17"><br></br>
<script language="JavaScript">
var nframeE = "<xsl:value-of select="MediaTime/MediaIncrDuration"/>";
tempE = Math.floor(nframeE/25)
frameE= nframeE - tempE*25
if (tempE &gt; 60 ) { minutiE= Math.floor(tempE/60);
secondiE=tempE - minutiE*60;
}
else{ secondiE = tempE;
minutiE=0;
}
TIME=minutiE + ":" + secondiE
document.write(TIME)
</script>
</td>
<td width="25%" height="17"><br></br>
<xsl:value-of select="CreationInformation/Classification/Genre/Name"/></td>
<td width="70%" height="17">
<script language="JavaScript">
var tempS = "<xsl:value-of select="MediaTime/MediaRelTimePoint"/>";
var minutiS;
var secondiS;
var minuti=0;
var secondi=0;
var video = "Video";
var secondiE;
var tempE ;
var minutiE;
nframeE= "<xsl:value-of select="MediaTime/MediaIncrDuration"/>"
var collegamento = "<xsl:value-of select="MediaLocator/MediaUri"/>";
if(tempS.substr(7,1) == "M" ){minutiS = tempS.substr(6,1);
if(tempS.substr(9,1) == "S"){secondiS = tempS.substr(8,1)}
else{secondiS = tempS.substr(8,2)}
}
else
{minutiS = tempS.substr(6,2);
if(tempS.substr(10,1) == "S"){secondiS = tempS.substr(9,1)}
else{secondiS = tempS.substr(9,2)}
}
tempE = Math.floor(nframeE/25)
frameE= nframeE - tempE*25
if (tempE &gt; 60 ) { minutiE= Math.floor(tempE/60);
secondiE=tempE - minutiE*60;
}
else{ secondiE = tempE;
minutiE=0;
}
minuti=Math.floor(minutiS);
secondi= Math.floor(secondiS);
if (secondi &gt; 60 ) { minuti++;
secondi=secondi-60;}
minutiE= minutiE + minuti
pag.183
secondiE= secondiE + secondi
if (secondiE &gt; 60 ) { minutiE++;
secondiE=secondiE-60;}
TIME= collegamento+ "?start="+ minutiS + ":" + secondiS +"&amp;end=" + minutiE +":" + secondiE+ "," +
frameE
document.write(video.link(TIME))
</script>
<br></br>
<img border="0" width="100" height="70"> <xsl:attribute name="src"> <xsl:value-of
select="MediaLocator/Image"/></xsl:attribute> </img></td></tr></xsl:for-each>
</table></div>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>
</xsl:template>
<xsl:template match="/ino:response/ino:message"/>
<xsl:template match="/ino:response/xql:query"/>
</xsl:stylesheet>
pag.184
Codice del foglio di stile XSL D
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
xmlns:xql="http://metalab.unc.edu/xql/"
xmlns:mpeg="http://www.mpeg7.org/2001/MPEG-7_Schema"
exclude-result-prefixes="xql ino mpeg"
version="1.0">
<xsl:template match="/" >
<html>
<head>
<title>Nuova pagina 1</title>
</head>
<body background="/SITOTECA/foglie.jpg">
<div align="center">
<table cellpadding="5" cellspacing="0" border="0" width="100%" height="104" vspace="0" hspace="0">
<tbody background="/SITOTECA/foglie.jpg">
<tr>
<td width="15" height="100%" align="right" valign="top"><img src="/leftline01.jpg" width="15"
height="100%"/></td>
<td valign="top"><img src="/SITOTECA/rai-83x49.gif" width="83" height="49" />
<br /><br /><img src="/SITOTECA/elisicon.gif" width="67" height="56" />
<br /><br /><img src="/SITOTECA/tr_vivai168x70.gif" width="137" height="49" />
<br />
<font face="Verdana, Arial, Helvetica, sans-serif" size="2" color="#FFCC66"><b><font
color="#000066"><font color="#990000"></font><font color="#990000"></font>
<br /><font color="#990000" size="5">TV </font><font color="#990000" size="5"> NEWS</font>
<br /><font color="#990000" size="5">
ARCHIVE</font></font></b></font>
<br />
<br />
<br />
<br />
<br />
<font color="#000000">Internet TV Project
<br />Vivai d'Impresa
<br />Elis - RAI
</font>
</td>
<td width="100%">
<div align="center"> <table width="500">
<tr>
<td align="left"><font face="Verdana, Arial, Helvetica, sans-serif" size="4" color="#330033">Risultati
trovati:</font></td>
</tr>
</table>
<br />
<table border="1" bordercolor="#00003299" width="100%" height="40" bgcolor="#99CCFF" align="center"
cellpadding="1">
<tr bgcolor="#00003299">
<td width="25%" height="17" align="center"><strong><font
color="yellow">Servizio n°</font></strong></td>
<td width="30%" height="17" align="center"><strong><font
color="yellow">Descrizione</font></strong></td>
<td width="25%" height="17" align="center"><strong><font
color="yellow">Scheda TG</font></strong></td>
<td width="30%" height="17"><strong><font
color="yellow">Giornalista</font></strong></td>
<td width="25%" height="17"><strong><font
color="yellow">Durata</font></strong></td>
<td width="25%" height="17"><strong><font
color="yellow">Genere</font></strong></td>
<td width="70%" height="70" align="center"><strong><font
color="yellow">Filmato</font></strong></td>
pag.185
</tr>
<xsl:for-each select="//AudioVisualSegment">
<tr>
<td width="25%" height="17"><xsl:value-of select="CreationInformation/Creation/Title"/></td>
<td width="30%" height="17"><br></br>
<xsl:value-of select="TextAnnotation/FreeTextAnnotation"/></td>
<td width="25%" height="17"><a target="_blank">
<xsl:variable name="valore"> <xsl:value-of select="./@ino:id"/>
</xsl:variable>
<xsl:variable
name="query">http://62.110.204.10/servlets/tecafast2style/tamino/tecafast/teca2002collection?_xql=Mpeg7[
@ino:id=</xsl:variable>
<xsl:variable name="style">]&amp;_xslsrc=http://62.110.204.10/tecaprova/xsl/tglazioProva.xsl</xsl:variable>
<xsl:attribute name="href"> <xsl:value-of select="concat($query,$valore,$style)"/>
</xsl:attribute>
scheda TG </a></td>
<td width="30%" height="17"><br></br>
<xsl:value-of select="CreationInformation//Creator/Agent/Name/GivenName"/></td>
<td width="25%" height="17"><br></br>
<script language="JavaScript">
var nframeE = "<xsl:value-of select="MediaTime/MediaIncrDuration"/>";
tempE = Math.floor(nframeE/25)
frameE= nframeE - tempE*25
if (tempE &gt; 60 ) { minutiE= Math.floor(tempE/60);
secondiE=tempE - minutiE*60;
}
else{ secondiE = tempE;
minutiE=0;
}
TIME=minutiE + ":" + secondiE
document.write(TIME)
</script>
</td>
<td width="25%" height="17"><br></br>
<xsl:value-of select="CreationInformation/Classification/Genre/Name"/></td>
<td width="70%" height="17">
<script language="JavaScript">
var tempS = "<xsl:value-of select="MediaTime/MediaRelTimePoint"/>";
var minutiS;
var secondiS;
var minuti=0;
var secondi=0;
var video = "Video";
var secondiE;
var tempE ;
var minutiE;
nframeE= "<xsl:value-of select="MediaTime/MediaIncrDuration"/>"
var collegamento = "<xsl:value-of select="MediaLocator/MediaUri"/>";
if(tempS.substr(7,1) == "M" ){minutiS = tempS.substr(6,1);
if(tempS.substr(9,1) == "S"){secondiS = tempS.substr(8,1)}
else{secondiS = tempS.substr(8,2)}
}
else
{minutiS = tempS.substr(6,2);
if(tempS.substr(10,1) == "S"){secondiS = tempS.substr(9,1)}
else{secondiS = tempS.substr(9,2)}
}
tempE = Math.floor(nframeE/25)
frameE= nframeE - tempE*25
if (tempE &gt; 60 ) { minutiE= Math.floor(tempE/60);
secondiE=tempE - minutiE*60;
}
else{ secondiE = tempE;
minutiE=0;
}
minuti=Math.floor(minutiS);
secondi= Math.floor(secondiS);
if (secondi &gt; 60 ) { minuti++;
secondi=secondi-60;}
minutiE= minutiE + minuti
pag.186
secondiE= secondiE + secondi
if (secondiE &gt; 60 ) { minutiE++;
secondiE=secondiE-60;}
TIME= collegamento+ "?start="+ minutiS + ":" + secondiS +"&amp;end=" + minutiE +":" + secondiE+ "," +
frameE
document.write(video.link(TIME))
</script>
<br></br>
<img border="0" width="100" height="70"> <xsl:attribute name="src"> <xsl:value-of
select="MediaLocator/Image"/></xsl:attribute> </img></td></tr></xsl:for-each>
</table></div>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>
</xsl:template>
<xsl:template match="/ino:response/ino:message"/>
<xsl:template match="/ino:response/xql:query"/>
</xsl:stylesheet>
pag.187
APPENDICE D
TERMINI E DEFINIZIONI:
AV: AudioVisual
CIF: Common Intermediate Format
CS: Classification Scheme
D: Descriptor
Ds: Descriptors
DDL: Description Definition Language
DS: Description Scheme
DSs: Description Schemes
IANA: Internet Assigned Numbers Authority
IPMP: Intellectual Property Management Protocol
JPEG: Joint Photographic Experts Group
MDS: Multimedia Description Scheme
MPEG: Moving Picture Experts Group
MPEG-7: standard ISO/IEC 15938
QCIF: Quarter Common Intermediate Format
SMPTE: Society of Motion Picture and Television Engineers
TZ: Time Zone
TZD: Time Zone Difference
URI: Uniform Resource Identifier (IETF Standard is RFC 2396)
URL: Uniform Resource Locator (IETF Standard is RFC 2396)
XM: eXperimentation Model
XML: eXtensible Markup Language
pag.188
Ringraziamenti
ƒ
Si ringraziano per la collaborazione alla tesi il Prof. Alessandro Neri e il
Prof. Claudio Palma dell’Università degli Studi Roma Tre.
ƒ
Si ringrazia per la collaborazione nella realizzazione del progetto e della
tesi, l’Ing. Francesco Romano (DNT Dipartimento Nuove Tecnologie
ELIS ).
ƒ
Si ringrazia la struttura ELIS per le infrastrutture e le risorse messe a
disposizione nell’ambito del progetto Vivai D’Impresa.
ƒ
Si ringrazia la società giapponese Ricoh per averci permesso di
partecipare alla sperimentazione del suo prodotto.
ƒ
Un ringraziamento va anche tutte le persone in ELIS che in questi mesi
sono stati disponibili a soddisfare le necessità non solo di progetto.
ƒ
Un particolare ringraziamento va a Gianluca Cicero e Arianna D.
ƒ
Ringrazio di cuore la mia famiglia che mi sono stati vicini con sincerità
in questi anni.
pag.189