Lo standard MPEG-7 per la definizione di metadati di oggetti multimediali
-
Upload
delfinostefano -
Category
Technology
-
view
1.406 -
download
0
description
Transcript of Lo standard MPEG-7 per la definizione di metadati di oggetti multimediali
UNIVERSITÀ DEGLI STUDI DELL'AQUILA
Facoltà di Scienze MM.FF.NN.
Corso di Laurea di I livello in Informatica
TESI DI LAUREA
Lo standard MPEG-7 per la definizione
di metadati di oggetti multimediali
Laureando Relatore
Stefano Delfino Prof. Vincenzo Fazio
Correlatore
Dott. Gianluca D'Andrea
Anno Accademico 2010/2011
2
Sommario
Introduzione ............................................................................................................................ 3
1. Lo standard MPEG-7 ............................................................................................................. 5
1.1 I metadati ..................................................................................................................................... 5
1.2 MPEG-7 - Multimedia Content Description Interface .................................................................. 6
1.2.1 Componenti principali di MPEG-7 ................................................................................. 8
1.2.2 Parti di MPEG-7 ........................................................................................................... 10
2. Creazione di una Description .............................................................................................. 13
2.1 La nostra Description ................................................................................................................. 13
2.1.1 La libreria "libxml2" ..................................................................................................... 18
2.1.2 La libreria "libextractor" .............................................................................................. 19
3. XML e database .................................................................................................................. 21
3.1 Un database Open Source XML nativo ...................................................................................... 22
3.2 Scrivere applicazioni basate su XQuery ..................................................................................... 23
3.2.1 La libreria "libcURL" ...................................................................................................... 25
3.3 Ricerche con XQuery .................................................................................................................. 26
3.3.1 Full Text Index basato su Apache Lucene ..................................................................... 27
4. Un sistema DRM con MPEG-7 ............................................................................................. 30
4.1 Architettura del sistema esistente ............................................................................................. 30
4.2 Perché MPEG-7?......................................................................................................................... 32
4.3 DRM Server con eXist-db ........................................................................................................... 32
4.3.1 Configurazione di Lucene .............................................................................................. 35
4.3.2 Query utilizzate ............................................................................................................. 37
Conclusioni ............................................................................................................................ 39
Bibliografia ............................................................................................................................ 41
3
Introduzione
Oggi grazie alla crescente capacità di banda ed alla sempre maggiore copertura della rete
mondiale Internet, la diffusione di contenuti multimediali ha raggiunto un altissimo livello sia in
termini di quantità che di qualità. Spesso Internet viene denominata come l' "archivio eterno",
questo per la sua immensa capacità di contenere e rendere disponibili risorse di ogni tipo. In ogni
istante, ognuno di noi può essere sia produttore che consumatore di contenuti multimediali,
questo grazie alla tecnologia che ci circonda, dalle fotocamere alle videocamere digitali, dai
notebook agli smartphone, insomma tutti strumenti elettronici che ci permettono di creare e/o
consumare foto, video, immagini e tanto altro ancora. Inoltre è sempre più vasto il campo di
sistemi elettronici che utilizzano tali contenuti in modo automatico, non solo per lo scambio di
questi ma anche per operazioni decisamente più complesse come l'indicizzazione, il filtraggio, etc.
Tuttavia, il valore delle informazioni spesso dipende, non solo dalla loro qualità e quantità,
ma anche dalla facilità del loro reperimento, accesso e gestione. Infatti senza un adeguato
strumento di ricerca, tutto questo patrimonio umano rischia di rimanere poco utilizzato. Per
questo motivo è necessario un processo di standardizzazione che descriva in maniera oggettiva le
informazioni multimediali.
Per gestire questa grossa quantità di dati multimediali, sia da parte degli utenti, sia da parte
dei sistemi automatici, ci aiuta MPEG-7: formalmente chiamato "Multimedia Content Description
Interface", uno strumento nato per descrivere contenuti multimediali attraverso una
rappresentazione testuale (XML). La descrizione del contenuto multimediale attraverso un
linguaggio strutturato testuale è un fattore molto importante per la ricerca, infatti gli attuali
motori di ricerca basano la loro esplorazione esclusivamente sulla parte testuale di un
documento, tralasciando ogni contenuto multimediale presente.
Lo standard MPEG-7 contribuisce al miglioramento di altri servizi come la
videosorveglianza, la TV digitale, l'arricchimento delle informazioni associate ad un multimedia,
come ad esempio i sottotitoli di un film o la pubblicità contenuta in un video, e molti altri ancora.
Inoltre, video rubati, video scaricati senza permesso da Internet, video alterati e modificati ed
altro, tutto questo potrebbe diventare immediatamente tracciabile dalle compagnie di
produzione e distribuzione attraverso un riconoscimento effettuato a livello di frame nei video
descritti con lo standard MPEG-7.
4
Il compito principale della mia tesi è quello di integrare lo standard MPEG-7 in un sistema
basato su DRM (Digital Rights Management). Questo sistema, sviluppato grazie ad altre tesi
precedenti, permette lo scambio di contenuti multimediali tutelando il diritto digitale. L'attuale
versione del sistema DRM ha un'architettura composta da un client e due server:
• l'Account Server gestisce gli utenti del sistema (registrazione, cancellazione,
autenticazione); ha inoltre il compito di raccogliere le richieste del client facendo
intervenire, ove necessario, il DRM Server.
• il DRM Server si occupa di gestire i file multimediali e la loro distribuzione nel sistema.
Inoltre si occupa di codificare un nuovo file che si vuole introdurre nella rete.
Il mio intervento apporta modifiche proprio su quest'ultimo server prevedendo una struttura per
l'inserimento e la gestione di descrizioni MPEG-7 e per ottimizzare le operazioni di ricerca.
Nel prossimo capitolo vedremo le caratteristiche dello standard MPEG-7 partendo dalla
descrizione dei metadati. Nei Capitoli 2 e 3 vedremo prima la descrizione creata e le librerie
utilizzate per assistere tale processo di creazione e poi vedremo il database utilizzato per gestire
la collezione di descrizioni MPEG-7 in formato XML. Infine nell'ultimo capitolo si descrive il
prototipo realizzato, mostrando le modifiche e le scelte fatte per integrare lo standard MPEG-7
all'interno dell'applicazione esistente.
5
1. Lo standard MPEG-7
1.1 I metadati
La funzione principale di un sistema basato sui metadati è quella di consentire il
raggiungimento dei seguenti obiettivi:
• Ricerca: accertare l'esistenza di un documento;
• Localizzazione: rintracciare una particolare occorrenza di un documento;
• Selezione: analizzare, valutare e filtrare una serie di documenti;
• Interoperabilità semantica: permettere la ricerca in ambiti disciplinari diversi grazie a una
serie di equivalenze fra descrizioni;
• Gestione risorse: gestire le raccolte di documenti grazie all'intermediazione di banche
dati e cataloghi;
• Disponibilità: ottenere informazioni sull'effettiva disponibilità del documento.
Nel contesto dei documenti digitali, il termine metadato adotta il significato che gli è stato
affidato dall'informatica e dalla filosofia. Dall'informatica deriva la restrizione del concetto di
"dato", limitando il suo dominio semantico ai soli dati digitali e discreti che vengono gestiti da un
computer. Dalla filosofia, e più specificatamente dalla metafisica, deriva un utilizzo particolare del
termine "meta", designandolo come un prefisso che serve per denotare un genere alternativo o di
secondo ordine di relazioni fra due tipi di entità analoghe.
Nei progetti di digitalizzazione e nelle attività di gestione degli archivi di oggetti digitali, i
metadati rivestono un'importanza crescente, tanto da venire considerati parte costituente della
definizione di "oggetto digitale". I metadati sono dati riguardanti le risorse, in particolare sono le
descrizioni di alcune loro caratteristiche. Queste descrizioni sono in forma testuale e
comprensibile all'uomo, ma anche utile ai motori di ricerca, che oggi basano le proprie attività
soprattutto sulla parte testuale di una risorsa.
Esistono vari tipi di metadati che possiamo raggruppare in tre principali categorie:
6
• Metadati Descrittivi: vengono usati per descrivere le risorse sia multimediali che cartacee
al fine di agevolare operazioni come la ricerca, la gestione, pubblicazione delle risorse.
• Metadati Gestionali: vengono usati per il controllo d'accesso alle risorse, per
l'archiviazione, la manutenzione e la conservazione, per la certificazione di autenticità, per
l'identificazione univoca di risorse multimediali.
• Metadati Strutturali: servono per descrivere la struttura delle risorse e le relazioni tra di
esse o tra le loro parti. Questi metadati inoltre forniscono dati di identificazione e
localizzazione del documento, come il codice identificativo, l'indirizzo del file sul server,
l'archivio digitale di appartenenza e il suo indirizzo Internet.
Oltre ad una corretta associazione tra i metadati e le risorse vi deve essere anche una giusta
uniformità degli stessi in modo da rendere le risorse più fruibili ai motori di ricerca e di
conseguenza agli utenti.
"The association of standardized descriptive metadata with
networked objects has the potential for substantially
improving resource discovery capabilities by enabling field-based
(e.g., author, title) searches, permitting indexing of
non-textual objects, and allowing access to the surrogate
content that is distinct from access to the content of the
resource itself." (Weibel and Lagoze, 1997)
Vari progetti di ricerca hanno lavorato per rendere queste descrizioni il più uniformi possibili, per
facilitare quindi operazioni di ricerca e interoperabilità semantica. Tra i risultati più promettenti
troviamo "tecniche" di descrizione come il Dublin Core, EBU Core, MPEG-7, TV Any Time, etc.
Andremo a vedere, nel prossimo paragrafo, MPEG-7 standard oggetto di studio di questa tesi.
1.2 MPEG-7 - Multimedia Content Description Interface
Lo standard MPEG-7 [ISO/IEC 15983] è stato sviluppato ed ufficializzato nel 2001 da MPEG
(Moving Picture Experts Group), organizzazione che lavora con l'ISO (International Organization
for Standardization) e sviluppa le norme per la compressione audio e video digitale. A differenza
degli altri standard, quali MPEG-1 e MPEG-2 per lo sviluppo di algoritmi di compressione e MPEG-
4 per l'organizzazione all'interno di oggetti multimediali, MPEG-7 nasce per la sola descrizione
dell'informazione multimediale attraverso una rappresentazione testuale strutturata (XML).
Questa rappresentazione permette alle risorse di essere facilmente reperite per il loro contenuto
7
e non per la loro struttura fisica. Quindi l'arricchimento (Enrichment) dei contenuti audiovisivi,
con le loro rappresentazioni, permetterà di indicizzare e categorizzare il materiale al fine di
produrre una ricerca più raffinata e fornire le basi per la creazione di servizi innovativi quali ad
esempio la capitolazione automatica e la ricerca per similarità del contenuto (ricerca per
immagine o per suono).
Gli elementi che MPEG-7 standardizza forniscono un valido sostegno ad un ampio insieme
di applicazioni che utilizzano risorse multimediali. Visto che al giorno d'oggi è difficile trovare un
dominio applicativo che non faccia uso di risorse multimediali, MPEG-7 si inserisce bene in molti
settori come:
• Broadcast media selection (e.g. canali radio e televisione)
• Cultural services (e.g. musei e gallerie d'arte)
• Digital libraries (e.g. cataloghi di immagini, dizionari musicali, archivi di film e musica).
• E-Commerce (e.g. pubblicità personalizzata, cataloghi on-line)
• Education (e.g. corsi multimediali e ricerca di materiale multimediale di supporto)
• Home Entertainment (e.g. sistemi per la gestione di file multimediali personali,
includendo la manipolazione dei contenuti, per esempio audio e video editing, ricerca di
giochi e karaoke)
• Investigation services (e.g. riconoscimento delle caratteristiche umane)
• Journalism (e.g. ricerca di interventi fatti da un politico, digitando il suo nome, o
inserendo la sua voce o la foto del suo volto)
• Multimedia directory services (e.g. pagine gialle, informazioni turistiche, informazioni
geografiche)
• Multimedia editing (e.g. servizi di personalizzazione delle news)
• Remote sensing (e.g. cartografia, ecologia, gestione delle risorse naturali)
• Shopping (e.g. ricerca degli abiti che piacciono)
• Surveillance (e.g. controllo del traffico).
Lo standard non definisce come le descrizioni MPEG-7 saranno usate per rispondere alle domande
degli utenti. Il tipo di contenuto e la domanda non devono essere per forza dello stesso genere;
infatti un video può essere cercato usando una musica, un discorso, etc.
Alcuni scenari d'interrogazione possibili sono:
• Suona poche note e riceverai una lista di pezzi musicali simili alla richiesta, o un insieme di
immagini in qualche modo correlate ad esempio in termini di emozioni.
8
• Disegna poche linee sullo schermo e trovi un insieme di immagini, "loghi" o ideogrammi
simili.
• Definisci oggetti includendo il colore o texture per ricevere esempi tra i quali selezionare
quelli adatti al tuo design.
• Descrivere i movimenti desiderati tra gli oggetti per ricevere animazioni che soddisfino
quanto descritto temporalmente e spazialmente.
• Descrivi un'azione per trovare una lista di scenari che contengono tale azione.
• Usando un estratto di voce di Pavarotti, ottieni un insieme di registrazioni, video-clip dove
Pavarotti sta cantando, e materiale fotografico raffigurante Pavarotti.
1.2.1 Componenti principali di MPEG-7
Lo standard fornisce tre principali componenti: Description tools, Description Definition Language
(DDL), System Tools.
Figura 1 - Relazioni tra le componenti principali di MPEG-7
Description Tools
Description Tools è formato dai Descriptors (D) ed i Description Schemes (DS):
• I Descriptors definiscono caratteristiche sia di basso livello (colore, texture, movimento,
potenza sonora, etc.) sia di alto livello (un contenuto semantico, un concetto astratto).
Molte di queste caratteristiche potranno essere estratte in modo automatico, soprattutto
quelle di basso livello, mentre per quelle di alto livello spesso c'è bisogno dell'intervento
umano, soprattutto per quanto riguarda i concetti semantici che sono descrizioni ad alto
livello per eccellenza.
9
• I Description Schemes aumentano le funzionalità dei descrittori MPEG-7, combinando
singoli D e DS, in particolare stabilendo una relazione tra i D e DS di cui è costituito. I
Description Schemes possono riguardare il dominio audio e video in maniera specifica o
una descrizione multimediale generica. Tipicamente, infatti, un DS generico corrisponde a
metadati immutabili che riguardano la creazione, la produzione, l'uso e la manutenzione
di un contenuto multimediale. I Description Schemes multimediali (MDS) si riferiscono a
tutti i tipi di media contenenti audio, video o dati testuali, mentre i Descriptor specifici di
un dominio, come quelli per il colore, la texture, la melodia e così via, fanno riferimento
soprattutto al dominio audio o video. Così come per i D, anche per i DS alcuni possono
essere automaticamente generati ed altri richiedono l'intervento umano.
Description Definition Language
MPEG-7 DDL costituisce il fondamento dell'intero standard. In accordo con MPEG-7 Requirements
Document è: "...un linguaggio che permette la creazione di nuovi Description Schemes (DS) e,
possibilmente, i Descriptors(D). Esso inoltre permette l'estensione e la modifica di DS già
esistenti".
Si tratta di un linguaggio per definire la struttura ed il contenuto di documenti MPEG-7. Il
DDL non è un linguaggio di modellazione (come UML) ma uno schema language per
rappresentare il risultato della modellazione di dati audio-visuali attraverso una serie di vincoli
sintattico - strutturali e di costanti alle quali i D e DS MPEG-7 devono essere conformi.
Si tratta, in sostanza, di una estensione del linguaggio XML Schema orientata al multimedia.
Se il proposito di un XML Schema è quello di definire una classe di documenti XML, il proposito di
un MPEG-7 Schema è quello di definire una classe di documenti MPEG-7.
Le istanze MPEG-7 sono documenti XML, conformi a un particolare schema MPEG-7
espresso mediante DDL che descrivono il contenuto multimediale.
Con MPEG-7 DDL è possibile esprimere non solo una struttura, ma anche la gerarchia e la
relazione spazio-temporale e concettuale tra gli elementi di un DS e tra i DS stessi.
System Tools
System Tools fornisce i metodi per la rappresentazione dei contenuti in formato binario (per una
maggiore efficienza nella trasmissione e memorizzazione), i meccanismi per la trasmissione (sia a
livello testuale [TeX] che binario [BiM]), le tecniche per la sincronizzazione delle descrizioni
rispetto ai contenuti, ecc.
10
1.2.2 Parti di MPEG-7
Sebbene gli elementi sopra citati rappresentano il cuore dello standard, nella realtà, lo standard è
formato da diverse parti. Nella Figura 2 vengono mostrate le parti che saranno brevemente
descritte in seguito.
Figura 2 - Organizzazione generale di MPEG-7
• MPEG-7 System [ISO/IEC 15938-1]: strumenti di supporto alla codifica binaria BiM delle
descrizioni MPEG-7 ed al "Terminal Architetture", una sorta di applicazione contenente i
sistemi per l'encoding, il decoding, la memorizzazione, la trasmissione, etc.
dell'informazione MPEG-7.
• MPEG-7 Description Definition Language (DDL) [ISO/IEC 15938-2]: come già detto nel
precedente paragrafo, è un linguaggio che permette la creazione di nuovi Descriptors (D)
e Description Scheme (DS). Inoltre è composto da tre componenti logiche fondamentali:
− XML-Schema structural language components.
− XML-Schema datatype language components.
− MPEG-7 specific extensions (per esempio il supporto di particolari tipi di dato
come le matrici).
• MPEG-7 Visual [ISO/IEC 15938-3]: i D e i DS associati esclusivamente a descrizioni di tipo
Video.
• MPEG-7 Audio [ISO/IEC 15938-4]: i D e i DS associati esclusivamente a descrizioni di tipo
Audio. I tools audio forniti possono essere di due tipi: i Low-Level Description Tools (per la
descrizione di caratteristiche di basso livello come lo spettro, caratteristiche temporali,
etc.) e gli High-Level Description Tools (per la descrizione di caratteristiche di alto livello
come i timbri, le melodie, il parlato, etc.)
11
• MPEG-7 Multimedia Description Schemes (MDS) [ISO/IEC 15938-5]: fornisce un set di
strutture, Descriptors(D) e Description Schemes(DS) per la descrizione di entità generiche
e/o multimediali. I tools forniti possono essere raggruppati in cinque classi fondamentali:
− Content Description: rappresenta l'informazione percepibile (audio, video, etc.).
− Content Management: descrive informazioni sulla creazione, l'uso e le proprietà
dei media.
− Content Organization: permette di creare, modellare e classificare collezioni di
media e relative descrizioni.
− Navigation and Access: fornisce strumenti per facilitare la navigazione, l'accesso e
la ricerca di materiali multimediali.
− User Interaction Tools: permette di descrivere le preferenze degli utenti rispetto
alla ricerca ed alla navigazione all'interno delle descrizioni multimediali.
• MPEG-7 Reference Software [ISO/IEC 15938-6]: implementazione software delle parti più
rilevanti dello standard. Il software, chiamato XM (eXperimentation Model), permette di
utilizzare i Descriptors, i Description Schema ed il Description Definition Language (DDL)
oltre che ad altre funzioni non normative ma necessarie per il corretto utilizzo di MPEG-7.
L'architettura dell'applicazione è Client/Server: la parte server permette l'estrazione delle
informazioni, quella client la ricerca, il filtragio e/o il transcoding dei dati multimediali.
• MPEG-7 Conformance [ISO/IEC 15938-7]: linee guida e procedure per testare la
conformità allo standard delle varie implementazioni.
• MPEG-7 Extraction and use of Descriptions [ISO/IEC 15938-8]: materiale informativo
sull'uso di alcuni Description Tools e sulle tecniche di estrazione simbolica.
• MPEG-7 Profiles and levels [15938-9]: fornisce profili standard e orientamenti.
• MPEG-7 Schema definition [15938-10]: specifica lo schema usando il Description
Definition Language.
• MPEG-7 Profile Schemas [15938-11]: elenca gli schema dei profili usando il Description
Definition Language.
• MPEG-7 Query Format [15938-12]: il query format offre un'interfaccia standard per il
recupero delle informazioni multimediali dal sistema (per esempio MPEG-7 databases).
definisce tre aspetti fondamentali che sono input query format, output query format e
query management format:
− L'input query format specifica l'interfaccia attraverso la quale l'utente può
descrivere i suoi criteri di scelta attraverso un set di precisi parametri di input in
aggiunta si possono scegliere dei parametri di output per definire l'insieme dei
risultati ritornati.
12
− L'output query format specifica il formato dell'interfaccia per il result set.
− Il query management format offre i mezzi per selezionare i servizi (es. MPEG-7
database) o aggregare i servizi (es. un fornitore di servizi che gestisce una serie di
servizi diversi).
13
2. Creazione di una Description
Nel contesto applicativo di questa tesi, siamo interessati a creare una descrizione MPEG-7
per file multimediali. In particolare da un'analisi dei requisiti utente è emerso che la descrizione
da creare deve soddisfare principalmente la sola operazione di ricerca. Per questo deve contenere
le informazioni per poter cercare un file multimediale dati i seguenti valori:
• parole appartenenti all'anagrafica del file multimediale;
• parole appartenenti ad un testo che può essere in diversi contesti un abstract, un
testo associato, un testo trascritto tramite un motore Speech-to-Text.
Abbiamo inserito nella nostra descrizione una parte generica comune a tutte le descrizioni di file
multimediali che ci permette di descrivere sia la parte relativa ai dati anagrafici che la parte
relativa al testo associato al parlato in file video o audio.
2.1 La nostra Description
Una descrizione MPEG-7 è scritta in XML seguendo degli schemi ben precisi. Si possono
utilizzare schemi esistenti e definiti dal MPEG oppure estendere quelli esistenti e definirne di
nuovi. Nel nostro caso abbiamo utilizzato gli "schemi" definiti dal MPEG MDS Sub-group del 20011
i quali contengono Description Schemes (DSs) e Descriptors (Ds) che descrivono le strutture
standard che sono utilizzate per documentare i file multimediali. Grazie a questo schema abbiamo
la possibilità di definire descrizioni che rispettano la struttura definita da MPEG e quindi conformi
allo standard. A titolo di esempio, all'interno dello schema MDS troviamo la struttura che deve
avere una data all'interno di una descrizione:
<!-- ##################################### --> <!-- Definition of Time datatype (6.4.2) --> <!-- ##################################### --> <!-- Definition of Time datatype --> <complexType name=" TimeType">
<sequence> <choice> <element name=" TimePoint" type="mpeg7:timePointType"/>
1 (MDS) Multimedia Description Schemes dal sito del (NIST) National Institute of Standard and Technology
http://m7itb.nist.gov/mds-2001.xsd
14
<element name="RelTimePoint" type="mpeg7:RelT imePointType"/> <element name="RelIncrTimePoint" type="mpeg7: RelIncrTimePointType"/> </choice> <choice minOccurs="0"> <element name="Duration" type="mpeg7:durationType" /> <element name="IncrDuration" type="mpeg7:IncrDurat ionType"/> </choice> </sequence> </complexType> <!-- ########################################## --> <!-- Definition of timePoint datatype (6.4.3) --> <!-- ########################################## --> <!-- Definition of timePoint datatype --> <simpleType name="timePointType"> <restriction base="mpeg7:basicTimePointType"> <pattern value="(\-?\d+(\-\d{2}(\-\d{2})?)?)? (T\d{2}(:\d{2}(:\d{2}(:\d+)?)?)?)?(F\d+)?((\-|\+)\d{2}:\d{2})?"/>
</restriction> </simpleType>
Questo ci dà la possibilità di definire all'interno delle nostre descrizioni, dei metadati che fanno
riferimento a date quali ad esempio la data di creazione di un video o la data di aggiornamento di
una descrizione, come quella mostrata di seguito:
<Time> <TimePoint>2011-07-26T13:15:00</TimePoint> </Time>
Un altro aspetto considerato in questa fase di studio è stato quello di individuare quali metadati
introdurre nella nostra descrizione, considerato i requisiti utente e quanto definito da altri
standard per la descrizione di contenuti multimediali. In particolare è stato utile al nostro scopo
osservare il progetto Dublin Core [4].
Lo scopo del Dublin Core è quello di dare una rappresentazione formale alle risorse
accessibili in rete via web. Varie possono essere le risorse che si possono descrivere: testi,
immagini, suoni, video, fotografie, etc. Il Dublin Core è un modello descrittivo "piatto" che non
permette la descrizione di metadati strutturati. Esso stabilisce un insieme base di elementi
descrittivi, che permettono di descrivere la parte centrale e anagrafica di una risorsa
multimediale. Tra i 15 elementi definiti troviamo metadati come il Titolo, l'Autore, Editore,
Descrizione, etc.
Di seguito si mostrano gli strumenti messi a disposizione dallo standard MPEG-7 per
descrivere le risorse multimediali sotto molti aspetti.
15
Figura 3 - Anteprima dei "description tools" dello standard MPEG-7
In particolare tra questi, abbiamo utilizzato per la nostra descrizione i seguenti strumenti:
• content management: utilizzato per descrivere le informazioni generiche sulla creazione
del multimedia (<CreationInformation>) come la data di creazione, il luogo, il titolo,
l'autore, etc. e per le informazioni riguardanti il media (<MediaInformation>) come la sua
dimensione e il suo formato;
• content organization: utilizzato per descrivere l'organizzazione dei multimedia in
collezioni o album.
Di seguito si riportano due figure rappresentanti una vista ad livello delle descrizioni di file audio e
video (*.mp3, *.mp4, *.avi, etc.) utilizzate, mostrando i description tools utilizzati (Content
Management e Content Organization) e l'organizzazione data alle loro componenti.
16
Figura 4 - Anteprima astratta delle nostre descrizioni
Di seguito si riporta la descrizione MPEG-7 scelta relativa ad un multimedia di tipo video.
<?xml version="1.0" encoding="iso-8859-1"?> <Mpeg7 xmlns="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xsi:schemaLocation="urn:mpeg:mpeg7:schema:20 01 Mpeg7-2001.xsd"> <Description xsi:type="ContentEntityType">
<!-- Parte relativa alla descrizione del video --> <MultimediaContent xsi:type=" VideoType">
<Video> <MediaInformation>
<MediaProfile> <!-- Informazioni sul TIPO FORMATO --> <MediaFormat>
<Content href="MPEG7ContentCS" /> <FileFormat href="urn:mpeg:mpeg7:cs:FileFormatCS:20 01:3">
<Name>video/mp4</Name>
</FileFormat> <FileSize> 3938787</FileSize>
<VisualCoding> <Format href="urn:mpeg:mpeg7:cs:VisualCodingFormatC S:2001:1"
colorDomain="color" /> <Frame height=" 352" width=" 288" />
</VisualCoding> </MediaFormat> <MediaInstance>
<MediaLocator> <!-- Path del file -->
17
<MediaUri> /home/user/video.mp4
</MediaUri> </MediaLocator>
</MediaInstance> </MediaProfile>
</MediaInformation> <CreationInformation>
<Creation> <!-- TITOLO del video --> <Title> Il mondo che vorrei</Title>
<Abstract> <!-- COMMENTI astratti di DESCRIZIONE --> <FreeTextAnnotation> Video musicale della canzone di Vasco Rossi
</FreeTextAnnotation> </Abstract> <Creator>
<Role href="creatorCS"> <Name>Autore</Name>
</Role> <Agent xsi:type="PersonType">
<Name> <GivenName> VascoRossi
</GivenName> </Name>
</Agent> </Creator> <Creator>
<Role href="creatorCS"> <Name>Casa di Produzione</Name>
</Role> <Agent xsi:type="OrganizationType"> <Name>EMI</Name>
</Agent> </Creator> <CreationCoordinates> <!--LUOGO di produzione del contenuto --> <Location> <Name>Italia</Name>
</Location> <!-- DATA di produzione --> <Date>
<TimePoint> 2009</TimePoint>
</Date> </CreationCoordinates>
</Creation> </CreationInformation>
</Video> </MultimediaContent> <!-- Parte relativa alla descrizione del audio --> <MultimediaContent xsi:type=" AudioType">
<Audio> <TextAnnotation>
<FreeTextAnnotation> Testo del parlato
</FreeTextAnnotation> </TextAnnotation>
</Audio>
18
</MultimediaContent> <MultimediaContent xsi:type=" MultimediaCollectionType"> <Collection xsi:type="TextAnnotation" name=" Nome Album"/>
</MultimediaContent> </Description> </Mpeg7>
Il file XML mostrato è stato validato utilizzando il seguente validatore on-line:
− www.xmlvalidation.com
2.1.1 La libreria "libxml2"
Per manipolare un file testuale scritto in XML, abbiamo utilizzato la libreria libxml2 [5] del
progetto Gnome2. Questa libreria è scritta in C ed è estremamente portatile. Questi sono alcuni
punti chiave della libreria:
• libxml2 supporta completamente XPath, XPointer e XInclude;
• libxml2 può fare la convalida DTD in fase di analisi;
• supporto di base per i client HTTP e FTP consentendo il recupero di risorse remote;
• interfaccia SAX compatibile con Expath;
• rappresentazione interna del documento simile all'interfaccia DOM.
Essa consente di creare dinamicamente la struttura del file XML, aggiungendo nodi ed attributi
alla struttura partendo dalla radice. Sono molte le API fornite dalla libreria, ma basta dare uno
sguardo al codice d'esempio fornito, per rendersi subito conto della semplicità del suo utilizzo.
Nel nostro caso abbiamo usato solo un sottoinsieme di queste API con il quale prima
creiamo un file XML in memoria e poi interagendo con l'utente inseriamo sequenzialmente nodi e
attributi per i vari metadati. In particolare utilizziamo i seguenti comandi:
// creiamo un nuovo documento xmlDoc *doc = xmlNewDoc(BAD_CAST "1.0");
// creiamo e settiamo l'elemento radice root_node = xmlNewNode(NULL, BAD_CAST "Mpeg7"); xmlDocSetRootElement(doc, root_node);
// inseriamo gli attributi del nodo Mpeg7 xmlNewProp(root_node, BAD_CAST "xmlns",
BAD_CAST "urn:mpeg:mpeg7:schema:2001"); xmlNewProp(root_node, BAD_CAST "xmlns:xsi",
BAD_CAST "http://www.w3.org/2001/XMLSchema-instance "); xmlNewProp(root_node, BAD_CAST "xmlns:mpeg7",
BAD_CAST "urn:mpeg:mpeg7:schema:2001"); xmlNewProp(root_node, BAD_CAST "xsi:schemaLocation" ,
2 GNOME - GNU Object Model Environment
19
BAD_CAST "urn:mpeg:mpeg7:schema:2001 Mpeg7-2001.xsd ");
// facciamo il dumping del documento sullo stdio xmlSaveFormatFileEnc("-", doc, "UTF-8", 1);
Con le istruzioni sopra riportate creiamo il semplice file XML riportato di seguito, che viene
visualizzato nello standard input/output:
<?xml version="1.0" encoding="UTF-8"?> <Mpeg7 xmlns="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xsi:schemaLocation="urn:mpeg:mpeg7:schema:20 01 Mpeg7-2001.xsd"> </Mpeg7>
Quelli mostrati sono i principali comandi che abbiamo utilizzato per creare la nostra descrizione.
Oltre a questi abbiamo utilizzato anche la funzione xmlParseMemory() che effettua il parsing di
un documento XML in memoria, poi crea e restituisce il puntatore al documento XML
(xmlDocPtr ). Notiamo come la libreria permette sia di creare e modificare dinamicamente la
struttura di un file XML effettuandone contemporaneamente il parsing per accettarne la validità,
e sia di effettuare direttamente il parsing su un file esistente come nel caso di
xmlParseMemory() , che come vedremo più avanti, viene utilizzato per controllare il risultato di
una query effettuata col linguaggio XQuery.
In questa fase abbiamo utilizzato anche i metadati già presenti sulla risorsa. Per estrarli
abbiamo utilizzato la libreria libextractor [6].
2.1.2 La libreria "libextractor"
GNU libextractor è una libreria che si pone come obiettivo quello di fornire un'interfaccia comune
per l'estrazione di metadati dai file di qualsiasi tipo. I tipi di file supportati sono MP3, Ogg, Real
Media, MPEG, RIFF (avi), GIF, JPEG, PNG, TIFF, HTML, PDF, PostScript, Zip, OpenOffice.org,
StarOffice, Microsoft Office, tar, DVI, man, Deb, elf, RPM. Se si necessita di supportare un nuovo
formato di file è possibile farlo estendendo le funzionalità della libreria tramite appositi plugin che
forniscono il codice necessario per interpretare il nuovo formato.
La libreria libextractor viene rilasciata sotto licenza GNU General Public License ed è fornita
insieme al comando extract che ne rappresenta l'interfaccia da riga di comando. Tramite
quest'ultimo è possibile visualizzare i metadati contenuti in un file sul terminale. Basta dare il
comando seguito da un file, fornito come input, per vedere i metadati in esso contenuti.
$ extract /home/user/video.mp4 format - 352x288 duration - 39s mimetype - video/mp4
20
Libextractor utilizza il primo byte di un file per indovinare il suo mimetype. Una volta individuato il
tipo del file procede nell'estrarre gli altri metadati presenti, come il nome del software utilizzato
per creare il file, il nome dell'autore, il titolo dell'album, la dimensione di una immagine o la
durata di un video, naturalmente verranno estratti solo se presenti.
#include <extractor.h>
int main(int argc, char * argv[]) { EXTRACTOR_ExtractorList * plugins; EXTRACTOR_KeywordList * md_list; plugins = EXTRACTOR_loadDefaultLibraries();
md_list = EXTRACTOR_getKeywords(plugins, "/home/u ser/video.mp4"); EXTRACTOR_printKeywords(stdout, md_list);
EXTRACTOR_freeKeywords(md_list); EXTRACTOR_removeAll(plugins); /* unload plugins */
return 0; }
Il pezzo di codice mostra come visualizzare nel terminare l'elenco dei metadati presenti nel file,
utilizzando la libreria libextractor . Il risultato atteso è identico a quello mostrato in
precedenza con il comando extract .
Oltre a questi comandi abbiamo utilizzato il seguente comando per l'estrazione singola di
metadati come il mimetype (ad esempio video/mp4 ) o il format (352x288 ) di un video:
• EXTRACTOR_extractLast(EXTRACTOR_MIMETYPE, md_list)
• EXTRACTOR_extractLast(EXTRACTOR_FORMAT, md_list)
Grazie a queste due librerie è stato possibile costruire la nostra descrizione riutilizzando
informazioni già presenti e aggiungendone di nuove, assicurando che il file XML risultante sia
valido.
Una volta creato il nostro file descrittivo XML in memoria, bisogna memorizzarlo e quindi
predisporre di una struttura capace di gestire file XML. Per questo compito abbiamo utilizzato,
come vedremo nel prossimo capitolo, il database XML nativo eXist [7].
21
3. XML e database
I documenti XML sono per natura dei raccoglitori di informazioni, infatti al loro interno è
possibile "memorizzare" dati organizzati in forma gerarchica. Ma è possibile considerare un
documento XML come un database? [8] Un documento XML è simile ad un database, nel senso
che colleziona al suo interno dati organizzandoli secondo una struttura, ma questa caratteristica è
comune, in misura diversa, a tutti i tipi di file. XML e le tecnologie correlate ad esso, possono
costituire un database management system (DBMS)? XML fornisce molte funzionalità tipiche di
un DBMS come la memorizzazione, la possibilità di definire schemi (DTD, XML schema), la
possibilità di utilizzare linguaggi di query (XPath, XQuery, XQL), ed altro. Ma nonostante queste
caratteristiche che accomunano un documento XML ad un database, altre sono quelle che solo un
DBMS può offrire come l'indicizzazione, la sicurezza, efficienza nella memorizzazione, integrità dei
dati e delle transazioni, trigger ed altro ancora.
Figura 5 - Possibili scenari nel utilizzo di file XML
22
Come facciamo a scegliere se utilizzare un database o utilizzare la capacità di memorizzazione dei
documenti XML. Diversi sono gli aspetti da considerare in questa scelta; occorre un repository per
memorizzare la pagine di un sito come mostrato nella Figura 5-A o il database è utilizzato per
un'applicazione che utilizza XML come formato di trasporto di dati Figura 5-B.
Oltre a quanto già detto, un altro fattore importante nella scelta di un database è chiedersi
se verranno memorizzati dati o documenti, cioè se XML è utilizzato solo come mezzo di trasporto
dei dati tra applicazione e database e quindi si necessita di memorizzare questi ultimi, oppure il
suo uso è integrale come nel caso di documenti XHTML che si vogliono memorizzare. Questa
scelta influenza il modo nel quale poter memorizzare un file XML, data-centric o document-centric
e quindi il tipo di database.
Queste ed altre sono le motivazioni che devono guidare la scelta sull'utilizzo di un database.
Ad esempio, come nel nostro caso, se i documenti XML da gestire contengono anche informazioni
semantiche, si potrebbe voler memorizzare tali documenti mantenendo intatta la loro struttura
gerarchica. Se si hanno queste esigenze è consigliato l'utilizzo di un database XML nativo. Questa
scelta oltre a preservare la struttura dei documenti consente anche di realizzare transazioni a
livello di documento e eseguire query in un linguaggio di query XML.
Queste sono le considerazioni che hanno portato la nostra scelta verso il database XML
nativo eXist, in quanto è un database funzionalmente completo, che supporta la maggior parte
delle tecnologie che girano intorno a XML ed inoltre è Open Source.
3.1 Un database Open Source XML nativo
eXist-db è un database open source basato interamente sulla tecnologia XML e rilasciato al
pubblico sotto licenza GNU LGPL. Esso è compatibile con molti standard web che rendono eXist
un'eccellente piattaforma per lo sviluppo di applicazioni web. Tra le tecnologie fornite troviamo:
• XQuery 1.0 / XPath 2.0
• Interfacce HTTP: REST, WebDAV, SOAP, XMLRPC
La versione utilizzata è la 1.4 che aggiunge una gestione dell'indicizzazione full text basata su
Apache Lucene [9] che utilizzeremo per facilitare le ricerche full text.
eXist-db fornisce un potente ambiente per lo sviluppo di applicazioni web basate su XQuery
e standard relativi. Intere applicazioni web possono essere scritte in XQuery, utilizzando XSLT,
XHTML, CSS e JavaScript (per le funzionalità AJAX). Le pagine XQuery possono essere eseguite sia
se memorizzate sul file system che memorizzate sul database, ed è proprio quest'ultimo
approccio quello che utilizzeremo.
23
Figura 6 - eXist Architecture
Nella figura precedente viene mostrata l'architettura del database utilizzato, mettendo in
evidenza la struttura three-tier, che mostra le varie componenti che caratterizzano questo
database.
3.2 Scrivere applicazioni basate su XQuery
XQuery [10] non è solo un potente linguaggio di interrogazione, ma anche un linguaggio di
programmazione funzionale con forti caratteristiche di tipizzazione, che può inoltre essere
utilizzato per processare l'intera parte logica di un'applicazione web.
XQuery è una raccomandazione del W3C ed è compatibile con diversi standard come XML,
Namespaces, XSLT, XPath, e XML Schema.
eXist fornisce tre differenti modi per chiamare una XQuery sul web:
XQueryServlet XQueryServlet legge uno script XQuery dal file system, di solito nella
directory nella quale l'applicazione risiede, e la esegue utilizzando il
corrente contesto HTTP. Il risultato della query è restituito come il
contenuto della risposta HTTP.
XQueryGenerator XQueryGenerator integra le funzionalità di eXist durante l'esecuzione di
XQuery, con il framework Apache Cocoon. Come accade con
XQueryServlet, gli script XQuery sono letti dal file system, ma il risultato
invece di tornare direttamente alla richiesta HTTP, è passato ad una
24
pipeline in Cocoon.
REST Server REST server può essere usata per eseguire XQuery memorizzate sul
database. Questo è un concetto potentissimo che consente di
memorizzare l'intera applicazione nel database.
Per mantenere l'interfaccia REST semplice, le operazioni base di un database sono direttamente
mappate su messaggi HTTP. I seguenti metodi sono supportati:
GET Ricerca una rappresentazione della risorsa o della collezione nel database. Richieste
XQuery e XPath possono anche essere specificate usando parametri opzionali del
metodo GET.
PUT Upload una risorsa sul database. Se richiesto, le collezioni sono automaticamente
create e le risorse esistenti sono sovrascritte.
DELETE Rimuove una risorsa (documento o collezione) dal database.
POST Invia i dati sottoforma di un frammento XML nel contenuto della richiesta
specificando l'azione da eseguire. Richieste di questo tipo sono utilizzate per passare
complesse espressioni XQuery troppo grandi per essere codificate nel URL.
Per la nostra applicazione abbiamo utilizzato l'interfaccia REST Server utilizzando una libreria C
libcURL [11] per comunicare con essa.
L'interfaccia REST fornisce l'autenticazione HTTP, quindi solo gli utenti autorizzati possono
accedere al database. Se le credenziali d'accesso (username e password) non sono fornite, il
server assume l'utilizzo da parte di un utente "guest", il quale ha delle funzionalità ridotte. Se le
credenziali sono fornite e non sono corrette viene restituita alla richiesta una pagina di errore
(Status code 403 - Forbidden).
Come già anticipato l'interfaccia REST supporta gli script XQuery memorizzati sul server: se
la risorsa di destinazione di un GET o POST è una risorsa con mime/type application/xquery ,
il server REST controlla sintatticamente ed esegue la XQuery richiesta. La XQuery ha accesso a
tutto il contesto HTTP, includendo parametri e attributi di sessione.
Quando si esegue una richiesta usando GET o POST, il server può memorizzare i risultati in
una cache di sessione lato server. Il consumo di memoria di questa funzionalità è basso se si tratta
di memorizzare risultati che referenziano a nodi già presenti nel database, mentre è alto se si
tratta di memorizzare nodi generati dalla XQuery stessa.
25
3.2.1 La libreria "libcURL"
LibcURL è un libreria che permette il trasferimento di file interfacciandosi con il lato client dei più
comuni e protocolli, DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS,
POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET and TFTP. LibcURL supporta anche i
certificati SSL, HTTP POST, HTTP PUT, i proxy, i cookie, autenticazione con username e password, e
molto altro.
LibcURL è altamente portatile e lavora allo stesso modo su differenti piattaforme,
includendo Solaris, NetBSD, FreeBSD, OpenBSD, Darwin, HPUX, IRIX, AIX, Tru64, Linux, UnixWare,
HURD, Windows, Amiga, OS/2, BeOs, Mac OS X, Ultrix, QNX, OpenVMS, RISC OS, Novell NetWare,
DOS, etc.
LibcURL è stata rilasciata nel 2000 ed è la libreria C per il trasferimento file più utilizzata al
mondo. Molte sono le grandi agenzie che la utilizzano nelle loro applicazioni ad alto volume e
numerose le applicazioni open source che la utilizzano.
LibcURL è stata interamente realizzata thread-safety, è molto veloce ed è ampiamente
documentata. Non è molto complicata da utilizzare, basta creare un gestore della comunicazione,
impostare varie opzioni ed eseguire il gestore. Di seguito viene mostrata la sequenza di istruzioni
che si deve quasi sempre rispettare per lavorare con libcURL:
#include <curl/libcurl.h> ... CURL *curl; CURLcode res; curl = curl_easy_init(); ... curl_easy_setopt(curl, CURLOPT_URL, "http://example .com/file.ext"); ... res = curl_easy_perform(curl); curl_easy_cleanup(curl); ...
Possiamo osservare che il gestore viene inizializzato con curl_easy_init() che in
particolare crea un'interfaccia di tipo easy e tutte le operazioni che si possono effettuare su di
essa iniziano con curl_easy_* . Esistono tre tipi di interfacce che si possono creare: easy
interface, multi interface, share interface. Noi nel nostro codice utilizzeremo solo l'interfaccia easy
visto la sua estrema semplicità e completezza. L'unica opzione che viene settata è relativa all'URL
di riferimento per l'operazione da eseguire. In questo punto del programma si possono
aggiungere altre opzioni come ad esempio i parametri da passare con un messaggio POST, allora
l'istruzione sarebbe curl_easy_setopt(curl, CURLOPT_POSTFIELDS,
"user=username&id=51") . L'istruzione res = curl_easy_perform(curl) manda in
esecuzione il gestore configurato e il risultato viene mostrato sullo standard output. L'ultima
26
espressione mostrata al contrario di curl_easy_init() serve per chiudere qualsiasi
connessione con l'interfaccia creata.
Naturalmente se abbiamo a che fare con un URL e con una risorsa remota significa che
vogliamo in qualche modo gestire il risultato dell'operazione e non accontentarci di visualizzare il
risultato sullo stdout. Per realizzare ciò esiste l'opzione CURLOPT_WRITEFUNCTION che permette
di gestire i dati risultanti dall'esecuzione, ad esempio scrivendoli in un file. Parallelamente a
questa l'opzione CURLOPT_READFUNCTION ci permette di leggere da un file e passare il
contenuto al gestore della comunicazione.
Naturalmente quanto detto sopra non è che una piccolissima parte del potenziale di questa
libreria; bisogna considerare che molte sono le API messe a disposizione dalle tre interfacce e
molti i contesti applicativi nei quali poter sfruttare libcURL in tantissimi modi differenti.
Come già accennato in precedenza, utilizziamo questa libreria per interfacciarci con
l'interfaccia REST del database eXist. In particolare utilizzeremo messaggi di tipo HTTP POST, HTTP
PUT e autenticazione con username e password.
3.3 Ricerche con XQuery
Le informazioni contenute all'interno di una collezione di file XML possono essere
recuperate utilizzando un linguaggio di query. Esistono diversi linguaggi per interrogare XML e
diversi modi per farlo. Nel nostro caso abbiamo utilizzato XQuery sia per la sua semplicità ma
anche per l'estrema potenzialità e completezza. Come mostrato nella Figura 3 il database eXist
offre un buon supporto a questo linguaggio.
Come già accennato possiamo effettuare vari tipi di ricerca: possiamo mirare ad un
particolare nodo del file XML oppure cercare in tutto il file. Ad esempio, se consideriamo il
seguente file XML oggetto delle nostre interrogazioni:
<bookstore> <book category="COOKING"> <title lang="en">Everyday Italian</title> <author>Giada De Laurentiis</author> <year>2005</year> <price>30.00</price> </book> <book category="WEB"> <title lang="en">XQuery Kick Start</title> <author>James McGovern</author> <author>Per Bothner</author> <author>Kurt Cagle</author> <author>James Linn</author> <author>Vaidyanathan Nagarajan</author> <year>2003</year>
27
<price>49.99</price> </book> ... </bookstore>
Potremmo eseguire le seguenti interrogazioni:
• se cerchiamo l'elenco dei nomi di libri, potremmo effettuare una query del tipo
doc("books.xml")/bookstore/book/title aspettandoci di ottenere come
risultato un elenco di nodi <title> contenenti i nomi dei libri della biblioteca;
• se cerchiamo l'elenco dei nomi di libri aventi un prezzo inferiore a 30€, potremmo
effettuare una query del tipo doc("books.xml")/bookstore/book[price<30] ;
Inoltre è possibile effettuare anche una ricerca full text che cercherà una corrispondenza in tutto
il testo contenuto nel file XML. Per ottimizzare quest'ultima operazione, il database eXist offre la
possibilità di configurare un sistema di indicizzazione con lo scopo di rendere tali operazioni più
veloci.
3.3.1 Full Text Index basato su Apache Lucene
Dalla versione 1.4 di eXist è stato introdotto un nuovo modulo per l'indicizzazione full text che
sostituisce il vecchio build-in di eXist per l'indicizzazione full text. Il nuovo modulo è più veloce, più
configurabile e più ricco di funzionalità rispetto alla vecchia indicizzazione di eXist.
Basato su Apache Lucene, questo modulo è strettamente integrato con l'architettura
modulare di indicizzazione di eXist: l'indice si comporta come un plugin, il quale aggiunge se
stesso alle pipeline di indicizzazione del db. eXist infatti si può configurare con diversi tipi di indici:
Structural Indexes, Range Indexes, NGram Indexes, Spatial Indexes, Old Legacy Full Text Indexes,
New Full Text Indexes. Una volta configurato, l'indice sarà notificato di ogni evento significante,
come l'aggiunta o la rimozione di un documento, la rimozione di una collezione, o
l'aggiornamento di un singolo nodo. Non è necessaria nessuna re-indicizzazione manuale per
rendere l'indice aggiornato dopo ogni modifica al "contenuto" del db.
eXist associa un distinto node-id per ogni nodo in un documento XML. Questo node-id è
usato per identificare il documento corrispondente all'interno dei file indice di Lucene. Questo
significa che è possibile personalizzare in maniera molto sottile il peso dato ad ogni
corrispondenza. In questo modo la ricerca di una parola chiave avrà un'importanza differente in
base alla posizione della sua corrispondenza all'interno del documento XML. Per esempio, una
corrispondenza di una parola chiave all'interno di un titolo può avere un'importanza più alta
rispetto ad una corrispondenza all'interno del body del documento. Questo significa che i risultati
riguardanti le corrispondenze trovate all'interno del titolo di un documento, probabilmente
28
compariranno prima tra i risultati della ricerca. Le ricerche quindi avranno maggiore Precision e
Recall3 rispetto a sistemi che non conservano la struttura del documento.
Per vedere meglio il funzionamento dell'indice di Lucene, prendiamo in considerazione il
seguente file XML:
<test> <p n="1">this paragraph tests the things made u p by <name>ron</name>.</p> <p n="2">this paragraph tests the other issues made up by <name>edward</name>.</p> </test>
È possibile definire un indice Lucene su un singolo attributo o elemento (qname="…") o su
un path (match="…" ). Se definiamo un indice nel seguente modo <text qname="test"/> , un
indice viene creato solo su <test> . Così facendo a Lucene viene passata la stringa
rappresentativa di <test> , che include tutto il testo contenuto da <test> stesso e da tutti i suoi
discendenti; tale stringa nel nostro esempio è "this paragraph tests the things made
up by ron. this paragraph tests the other issues ma de up by edward. ".
Con un indice definito in questo modo "non è possibile" cercare solo nei nodi sotto al nodo
<test> , cioè nei nodi <p> e <name> poiché tali nodi sono stati collassati all'interno del nodo
padre. Se si vuole poter interrogare i nodi discendenti, si devono impostare indici addizionali su
questi, come <text qname="p"/> e <text qname="name"/> .
Per definire un indice su un path di un nodo si usa come detto <text
match="//test"/> . Questo tipo di indice mantiene la struttura dei nodi sotto il nodo <test> .
Questo consente quindi di interrogare direttamente i nodi sotto <test> ; in particolare questo
modo di indicizzare è visto come una scorciatoia per interrogare tutti i nodi sotto <test> .
Bisogna aggiungere anche, che il valore dell'attributo match "//test " non è una espressione
XPath ma un semplice path. Per il nostro lavoro si è utilizzato l'attributo "qname" visto che
l'utilizzo di "match " potrebbe essere soggetto a cambiamenti. Tra poco vedremo come abbiamo
settato l'indicizzazione che ci permette di effettuare interrogazioni full text sfruttando il nuovo
modulo Lucene.
Prima di poter effettuare delle interrogazioni full text bisogna impostare l'indicizzazione del
database. eXist fornisce un semplicissimo modo per fare questo. Se vogliamo interrogare una
nostra collezione memorizzata in db/prova , bisogna creare un file collection.xconf in
db/system/config/db/prova . Quindi la configurazione dell'indice è di solito memorizzata in
3 Precision and Recall: due parametri ampiamente utilizzati per valutare la correttezza di un algoritmo di Pattern
Recognition.
29
una directory dentro system/config/db isomorfa alla directory del db. Nel precedente caso il
file collection.xconf è il seguente:
<collection xmlns="http://exist-db.org/collection-c onfig/1.0"> <index> <!-- Enable the legacy full text index for compari son with Lucene --> <fulltext default="all" attributes="no"/> <!-- Lucene index is configured below --> <lucene> <analyzer class="org.apache.lucene.analysis.stan dard.StandardAnalyzer"/> <analyzer id="ws" class="org.apache.lucene.analy sis.WhitespaceAnalyzer"/> <text qname="test"/> <text qname="p"/> <text qname="name"/> </lucene> </index> </collection>
Nel file di configurazione si ha la possibilità di impostare anche l'esclusione dall'indice di alcuni
nodi. Se per esempio si vuole escludere dall'indice i nodi inline, che si trovano nel mezzo del testo,
come potrebbero essere i tag <note> basta aggiungere <ignore qname="note"/> al livello
principale nel file di configurazione sotto il nodo <lucene> oppure sotto il nodo il cui indice si
vuole "alleggerire". Questa esclusione viene solo applicata a nodi discendenti.
Quanto descritto sopra sono le funzionalità che sfrutteremo nel nostro lavoro. Il modulo
Lucene naturalmente offre ancora molte funzionalità tra le quali la possibilità di assegnare un
"Boosting Values" valore d'importanza ad ogni match trovato. Il valore viene impostato nel file di
configurazione mediante l'attributo "boost " <text qname="name" boost="2.0"/> .
Ora che abbiamo visto come impostare il file di configurazione possiamo introdurre
brevemente l'espressione XQuery che utilizzeremo per interrogare una collezione come quella
vista sopra. Cominciamo col fare riferimento alla collezione da interrogare, per la quale è stato
creato il file collection.xconf , e lo facciamo con l'espressione collection('/db/prova') .
Per effettuare una query full text bisogna fare riferimento ad uno degli indici creato sopra (test, p,
name) basta aggiungere l'elemento scelto, per esempio collection('/db/prova')/test o
collection('/db/prova')/test/p o collection('/db/prova')//name . Ora è possibile
effettuare la query: collection('/db/prova')//p[ft:query(.,'edward')] . Il risultato
della query precedente è il secondo paragrafo del file XML di prova. Più avanti vedremo questi
strumenti applicati ad una collezione di file XML secondo lo standard MPEG-7.
30
4. Un sistema DRM con MPEG-7
4.1 Architettura del sistema esistente
Come anticipato nell'introduzione, lo scopo della tesi è quello di inserire all'interno di un
sistema esistente lo standard MPEG-7. Il sistema esistente permette di condividere file
multimediali tutelando gli aspetti di sicurezza tipici di un'applicazione DRM.
Prima di mostrare l'architettura del sistema ed in parte il funzionamento, bisogna
specificare che il DRM Server più volte nominato, è composto da due parti principali: il DRM
Server cioè la parte on-line che risponde alle richieste degli utenti, e il DRM Encoder una parte
off-line che si occupa della codifica e memorizzazione dei multimedia.
Il DRM Encoder tramite un plugin di codifica di GStreamer codifica il file multimediale con
un'apposita chiave (MasterKey), lo memorizza sul file system, e tiene traccia della MasterKey
utilizzata e delle informazioni relative al file all'interno di un database MySQL che vedremo tra
breve.
Nella parte on-line, il DRM Server rimane in attesa di connessioni e per ognuna di queste
permette l'operazione di ricerca e download del file codificato. Il Client una volta ricevuto il file
codificato, necessita della MasterKey per decodificarlo e riprodurlo. Il Client la riceve dal DRM
Server ma prima dell'invio quest'ultimo codifica la MasterKey utilizzando un'altra chiave
(UserKey). Quest'ultima è necessaria per la riproduzione sul Client in particolare per decodificare
la MasterKey ricevuta dal DRM Server; quindi attraverso l'Account Server, il DRM Server manda al
Client la UserKey utilizzata per codificare la MasterKey. A questo punto il client riceve dal DRM
Server la MasterKey codificata e dall'Account server la UserKey, e può quindi decodificare il
multimedia ricevuto e riprodurlo.
La seguente figura mostra l'architettura alla base del sistema realizzato finora mettendo in
evidenza le tecnologie utilizzate.
31
Figura 7 - Architettura del sistema DRM
Come mostrato, tutta la comunicazione è basata su Open SSL, la gestione delle utenze
sull'Account Server sfrutta Open LDAP. Nel DRM Server, la parte di codifica (DRM Encoder) utilizza
GStreamer per codificare i file multimediali mentre nel Client viene utilizzato per decodificare il
file ricevuto. Il formato JSON4 viene utilizzato come formato di scambio dati tra i vari componenti
del sistema.
Come accennato, il DRM Encoder una volta effettuata la codifica dei file, memorizza
all'interno di un database MySQL il percorso dove ha codificato il file, le informazioni relative al
file e la MasterKey utilizzata.
Figura 8 - Tabella relazionale del database MySQL
La tabella mostra quali dati effettivamente vengono memorizzati sul database MySQL. In
particolare l'entry media contiene una stringa descrittiva che tiene traccia delle informazioni utili
per la ricerca. Questa stringa è formata dalla semplice concatenazione delle seguenti
4 JSON (JavaScript Object Notation) - http://www.json.org
32
informazioni: artista, canzone, album. Fino a questo punto, lo sviluppo dell'applicazione si è
concentrato sulla parte di comunicazione e protezione dei dati, mettendo assieme tecnologie
come Open SSL e Open LDAP come mostrato nella Figura 7, integrando un plugin di GStreamer
con il quale si codifica un file multimediale nel DRM Encoder e un altro plugin per la riproduzione
all'interno del Client, trascurando quindi tutta la parte di "gestione" dei file multimediali, dalle
descrizioni semantiche dei multimedia alla ricerca basata sui contenuti semantici. Infatti l'attuale
funzione di ricerca, cerca un possibile match con una sottostringa dell'entry media.
Questo metodo di ricerca non è completo in quanto permette di cercare i file solo in base ai
metadati elencati sopra, trascurando così molti altri aspetti semantici. Inoltre la concatenazione
dei metadati in una stringa non è un buon metodo per strutturare e memorizzare queste
informazioni, perché si perde la struttura che collega questi metadati e quindi la semantica
contenuta in essa.
4.2 Perché MPEG-7?
In un'applicazione distribuita per la condivisione di file multimediali, si potrebbe voler
cercare i multimedia in base all'anno di produzione o al luogo di creazione, o in base ad aspetti più
descrittivi e semantici, come potrebbero essere le parole appartenenti ad una descrizione astratta
del file, o appartenenti al testo corrispondente all'audio. Un altro possibile scenario potrebbe
essere la possibilità di cercare un video dando un'immagine o un audio dando la sua cover.
Questi aspetti semantici devono essere quindi descritti e memorizzati dall'applicazione e
quindi si necessita di una struttura che contenga tutti i metadati necessari salvaguardandone
anche la semantica che lega tra di loro i vari metadati. Per questo motivo, lo standard MPEG-7 è
l'ideale per memorizzare e strutturare le informazioni all'interno di file XML. Ecco da dove è nata
la necessità di sostituire il database MySQL e introdurre eXist-db dove vengono gestite le
collezioni di descrizioni XML. Di seguito mostreremo come abbiamo cambiato il sistema
portandolo così ad una versione che sfrutta lo standard MPEG-7.
4.3 DRM Server con eXist-db
Una delle modifiche apportate al sistema è stata quella di togliere il database relazionale
MySQL e sostituirlo col database XML nativo eXist, nel quale verranno memorizzate e gestite le
descrizioni semantiche, in XML conforme allo standard MPEG-7, dei file multimediali codificati. La
figura seguente mostra le caratteristiche principali introdotte sul DRM Server.
33
Figura 9 - Principali caratteristiche del nuovo server
All'interno del Server DRM abbiamo modificato la parte di codifica (la parte off-line),
intervenendo su un programma chiamato drmencoder che tramite una iterazione con l'utente
crea il file XML descrittivo e lo memorizza nel database, tenendo traccia così dei metadati che
descrivono il file, della Master Key e del path dove il file codificato viene memorizzato. I file XML
creati vengono poi memorizzati nel database eXist sfruttando la sua interfaccia REST e la libreria C
libcURL, in una collezione che ha una struttura completamente speculare a quella della cartella
nel file system, nella quale viene memorizzato il file codificato. Prendendo ad esempio un file
audio codificato e memorizzato nella seguente directory:
/DRM_SERVER_HOME/D/DANIELE_ROSSI/ALBUM_STORICO/yellow_song.mp3
il file XML descrittivo relativo ad esso, viene memorizzato nella seguente struttura all'interno del
database eXist:
/eXistHOME_APPLICATION /D/DANIELE_ROSSI/ALBUM_STORICO/yellow_song.xml
Come brevemente illustrato nel capitolo precedente, il database eXist una volta installato deve
essere configurato per le operazioni di ricerca full text che sfruttano Lucene. Inoltre abbiamo
utilizzato diversi file XML e XQuery di supporto alle varie funzionalità.
Cominciamo col mostrare il file XML che verrà memorizzato nella nostra collezione. Per
cercare di riutilizzare gran parte del vecchio sistema DRM con il database relazionale, abbiamo
esteso il file XML MPEG-7 mostrato nel Capitolo 2, in modo da tenere traccia anche dell'id della
risorsa e della master_key.
<media> <id> ID </id> <mediaKey> Master key </mediaKey>
<Mpeg7 xmlns="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xsi:schemaLocation="urn:mpeg:mpeg7:schema:20 01 Mpeg7-2001.xsd"> <Description xsi:type="ContentEntityType"> <!-- Parte relativa alla descrizione del vide o --> <MultimediaContent xsi:type=" VideoType">
<Video>
MPEG-7
Lucene Full-Text Index
XQuery
eXist-db
34
<MediaInformation> ... <MediaUri> /D/DANIELE_ROSSI/ALBUM_STORICO/yellow.mp4
</MediaUri> ... </MediaInformation> <CreationInformation> ... </CreationInformation> </Video> </MultimediaContent> <!-- Parte relativa alla descrizione del audi o --> <MultimediaContent xsi:type=" AudioType">
<Audio> ...
</Audio> </MultimediaContent> <MultimediaContent xsi:type=" MultimediaCollectionType"> <Collection xsi:type="TextAnnotation" name= " ALBUM_STORICO"/>
</MultimediaContent> </Description> </Mpeg7> </media>
Come possiamo notare, non vi è un vero parallelismo tra la tabella relazionale della Figura 8 e il
file XML mostrato sopra. L'entry real_path che sembra mancare, è invece già contenuta
all'interno della descrizione MPEG-7 nel tag <MediaUri> ; questo contiene la posizione del file
codificato.
Il valore ID nel database eXist, assume un significato differente rispetto al database
relazionale MySQL, infatti in eXist una risorsa XML è univocamente distinta dal suo path e quindi
questo valore è stato conservato solo per consentire una selezione rapida (numerica e non un
path testuale) dei risultati a seguito di una ricerca. Immaginate lo scenario di ricerca, nel quale un
utente deve selezionare il risultato desiderato, e per fare ciò deve digitare il suo real_path.
Questo approccio non è molto User Friendly, ecco perché si è deciso di lasciare la selezione del
risultato dandone il suo id.
Per tenere traccia del progressivo id si è utilizzato un file XML memorizzato nel database.
Quando si cerca di recuperarne il valore con una XQuery per inserire una nuova entry il valore
dell'id viene anche incrementato dalla query stessa. Di seguito mostriamo il file e la query.
<!-- next_id.xml --> <data> <next-id> 0</next-id>
</data>
(: get_next_id.xq :) xquery version "1.0"; let $id-file := '/db/drmp2p/next_id.xml' let $id := doc($id-file)/data/next-id/text()
let $action := update replace doc($id-file)/data/next-id with <next-id>{ $id + 1}</next-id>
35
let $res := $id - 1
return $res
La query prende il riferimento al file next_id.xml, ed al testo contenuto all'interno del nodo
<next-id> ; poi modifica questo valore incrementandolo di uno e ne restituisce il valore
decrementato di uno. Questo ci permette quindi di avere sempre un progressivo numerico da
memorizzare assieme al file XML.
4.3.1 Configurazione di Lucene
Come abbiamo accennato nel Paragrafo 3.3, le ricerche full text con XQuery sfruttano un modulo
di indicizzazione di Apache Lucene. Questo crea e modifica gli indici ad ogni evento significativo
fatto sui file XML memorizzati; quindi ad ogni inserimento, modifica e cancellazione dei file XML,
vengono parallelamente modificati anche gli indici relativi. Come già detto in precedenza, si deve
configurare l'indicizzazione tramite un file di configurazione del database eXist, con il quale si
definisce come devono essere creati e mantenuti gli indici.
<!-- //db/system/config/db/drmp2p/collection.xconf --> <collection xmlns="http://exist-db.org/collection-c onfig/1.0"> <index xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001"> <!-- Enable the legacy full text index for compar ison with Lucene --> <fulltext default="none" attributes="no"/> <!-- New full text index based on Lucene --> <lucene> <analyzer class="org.apache.lucene.analysis.stand ard.StandardAnalyzer"/> <analyzer id="ws" class="org.apache.lucene.analys is.WhitespaceAnalyzer"/> <text qname="media"> <ignore qname="mpeg7:LastUpdate"/> <ignore qname="mpeg7:MediaUri"/> <ignore qname="mpeg7:Role"/> <ignore qname="mpeg7:FileSize"/> <ignore qname="mpeg7:FileFormat"/> </text> <text qname="@name"/> </lucene> </index> </collection>
Grazie a questo file di configurazione sarà possibile effettuare query full text sfruttando
l'indicizzazione del modulo Lucene. In particolare notiamo la definizione di due indici <text
qname="media"> e <text qname="@name"/> :
36
• Media indicizza tutto il testo contenuto nel file XML tranne quello contenuto nei tag
definiti dall'attributo qname del tag ignore, come ad esempio <ignore
qname="mpeg7:MediaUri"/> .
• Name indicizza il testo appartenente all'attributo name del tag Collection che descrive
l'album di appartenenza del media.
La XQuery memorizzata e richiamata per la ricerca è la seguente.
(: fulltext_query.xq :) xquery version "1.0"; declare namespace mp7='urn:mpeg:mpeg7:schema:2001'; declare option exist:serialize "method=xml media-ty pe=text/xml indent=yes"; <list> { let $parameter := request:get-parameter('paramete rs', ' ') let $query := <query> <wildcard>*{$parameter}*</wildca rd> </query> let $my_collection := collection('/db/drmp2p/coll ection') let $testo := $my_collection//media[ft:query(., $ query)] let $attributo := $my_collection//*[ft:query(@name, $query)]/ance stor::media for $result in $testo | $attributo let $id := $result//id/text() let $path := $result//mp7:MediaUri/text() return <item> <id>{$id}</id> <path>{$path}</path> </item> } </list>
Vediamo brevemente come funziona:
• per cominciare si recupera il parametro passato per la ricerca;
• viene creata una "query" con elementi <wildcard> che danno la possibilità di cercare
nelle sottostringhe tramite il simbolo *;
• vengono poi creati due insiemi di nodi <media> : uno contenente i match con il testo
dell'intero file e l'altro contenente i match con l'attributo name di Collection ;
• i due insiemi vengono poi uniti e per ogni elemento <media> contenuto nell'insieme
risultante, viene creato un elemento <item> che ne conterrà <id> e il <path> .
37
Il risultato atteso dalla precedente query sarà qualcosa del genere:
<list> <id> 10 </id> <path>/D/DANIELE_ROSSI/ALBUM_STORICO/yellow_song. mp3</path> <id> 23 </id> <path>/E/EMANUELE_BIANCHI/COLLEZIONE_JAZZ/the_bes t_jazz.mp3</path> </list>
Quanto visto fin-ora riguarda principalmente la parte relativa ad eXist e alla ricerca full text
utilizzando Lucene. Nel prossimo paragrafo mostriamo altre query utilizzate nelle varie
funzionalità soprattutto nella parte di ricerca dei file e di recupero di informazioni relative ad un
file selezionato.
4.3.2 Query utilizzate
In uno scenario di ricerca quando l'utente inserisce le parole chiave da cercare, la query
restituisce un file XML che verrà serializzato nel formato JSON nel seguente modo:
[{ "id" : 10, "mediapath" : "/D/DANIELE_ROSSI/ALBUM_STORICO/yel low_song.mp3", },{ "id" : 23, "mediapath" : "/E/EMANUELE_BIANCHI/COLLEZIONE_JAZ Z/the_best_jazz.mp3", }]
Questi dati serializzati, arrivano sul client e l'utente seleziona l'id desiderato. A questo punto
bisogna recuperare sul DRM Server due informazioni relative al file selezionato:
• il Media Path del file all'interno del DRM Server;
• la Master Key che è servita al DRM Encoder per codificare il file.
Ricordiamo che questi valori sono contenuti nella collezione di descrizioni XML all'interno del
database eXist, in particolare all'interno dei tag <mediaKey> e <MediaUri> . Per recuperarli
partendo dall'id selezionato utilizziamo le seguenti XQuery:
(: get_mediapath_from_id.xq :) xquery version "1.0"; declare namespace mp7='urn:mpeg:mpeg7:schema:2001'; declare option exist:serialize "method=xml media-ty pe=text/xml indent=yes"; for $media in collection('/db/drmp2p/collection') let $id := request:get-parameter('parameters', ' ') where $media//id/text() = $id return <mediapath>{$media//mp7:MediaUri/text()}</mediapath>
38
(Get_mediapath_from_id.xq) una volta individuato il media avente l'id dato come parametro, si
restituisce il testo contenuto in <MediaUri> all'interno di un tag risultato <mediapath> .
(Get_masterkey_from_id.xq) si restituisce il testo contenuto in <masterKey> all'interno di un
tag <masterkey> .
DRM Server
(Logic-Layer)
eXist-db
(Data-Layer)
get_mediapath_from_id.xq
1- POST message by libcURL
2- XML with result
Figura 10 - Scenario d'interrogazione - Recupero Media Path
Lo scenario mostra la sequenza di passi all'interno del DRM Server, per il recupero del path del
media. All'interno del messaggio HTTP POST viene inserito il parametro id sfruttando la libreria
libcURL. Viene eseguito lo stesso processo anche per il recupero della Master Key. Una volta
recuperati questi dati il media può esse codificato e mandato sul Client.
(: get_masterkey_from_id.xq :) xquery version "1.0"; declare namespace mp7='urn:mpeg:mpeg7:schema:2001'; declare option exist:serialize "method=xml media-ty pe=text/xml indent=yes"; for $media in collection('/db/drmp2p/collection') let $id := request:get-parameter('parameters', ' ') where $media//id/text() = $id return <masterkey>{$media//mediaKey/text()}</masterkey>
39
Conclusioni
MPEG-7 è uno standard che fornisce un valido supporto alla gestione della semantica in
campo multimediale. Lo standard consente di arricchire un oggetto multimediale aggiungendo
metadati che consentono di aumentare la sua semantica. Il processo di arricchimento
(enrichment) permette quindi di aggiungere informazioni al multimedia, come ad esempio i
sottotitoli o la pubblicità in un video. Questo processo ha come principale vantaggio quello di
rendere l'oggetto più gestibile in operazioni di archiviazione, di ricerca o di fruizione dei contenuti,
come la capitolazione automatica (chaptering).
Molti sono i settori nei quali lo standard MPEG-7 si inserisce e molte le possibili estensioni.
Nella nostra applicazione lo standard offre dei vantaggi nelle ricerche dando dei risultati più
precisi, e la possibilità di avere in futuro delle descrizioni semantiche più dettagliate estendendo
quella esistente. In particolare possiamo già prevedere la possibilità di estenderle collegando tra
loro multimedia che hanno in comune alcuni metadati quali Autore e/o Genere, fornendo
eventualmente tali multimedia alternativi tra i risultati di una ricerca. Inoltre potremmo voler
effettuare ricerche per similarità, dando l'immagine relativa o in qualche modo collegata ad un
video o un audio, ed avere come risultato della ricerca tutti quei multimedia che sono collegati
all'immagine data.
Nella tesi si è affrontato il tema dell’enrichment in maniera completa mentre a livello
implementativo si è utilizzato MPEG-7 solo per migliorare il modulo di ricerca nel sistema DRM
esistente. Il modello presentato è applicabile in diversi contesti ovviamente modificando i
metadati di arricchimento.
Molte le strade e gli sviluppi futuri, in particolare il prossimo step sarà quello di introdurre
lo standard MPEG-21. Questo standard molto recente considera tutte le problematiche inerenti la
distribuzione dei contenuti in funzione dei diritti digitali, mentre gli standard come MPEG-1,
MPEG-2, MPEG-4 trattano i file dal punto di vista fisico e come abbiamo visto MPEG-7 tratta la
parte semantica dei multimedia. Lo scopo è quello di realizzare un framework multimediale che
fornisca all'utente un supporto per lo scambio, l'accesso, ed altre operazioni effettuate sul
multimedia, controllando che l'utente abbia i diritti per effettuare tale operazione. Vista la
possibilità di estendere l'architettura di questa applicazione al peer-to-peer, questa integrazione
va considerata per controllare il più possibile il percorso del multimedia dal produttore al
consumatore (value-chain).
40
Attualmente l'applicazione è sprovvista di interfaccia grafica (GUI - Graphical User
Interface). A tal proposito abbiamo studiato due possibili soluzioni da adottare: le librerie grafiche
Gtk+ e Qt4. Abbiamo realizzato per entrambe le soluzioni una piccola GUI per l'autenticazione e
confrontato le due soluzioni. Sebbene la libreria Qt4 manipolata in C++ è sembrata molto
immediata, la libreria Gtk+ gestita col linguaggio C si è rivelata la soluzione migliore, per la sua
versatilità, estrema semplicità e velocità.
L'attuale implementazione del sistema è un prototipo che mostra le funzionalità delle varie
componenti. Si dovrebbe effettuare al più presto un lavoro di ingegnerizzazione separando la
parte di logica dalla parte di presentazione, stratificando meglio l'architettura del sistema. Questa
operazione è necessaria per aumentare la leggibilità del progetto, il quale comincia ad avere
dimensioni discrete, non più gestibili senza una buona struttura.
Concludendo, questo lavoro illustra lo standard MPEG-7 applicato ad un contesto di
descrizione e ricerca di contenuti multimediali; inoltre descrive una serie di tecnologie che sono
state utilizzate nella realizzazione del prototipo. In particolare le librerie libxml2 e libextractor per
la creazione di descrizioni MPEG-7 in formato XML, il database eXist per la memorizzazione dei file
e per le query in XQuery, il motore Lucene per l’indicizzazione delle descrizioni e infine la libreria
libcURL per la comunicazione con l'interfaccia REST del database eXist.
41
Bibliografia
[1] Giancarlo Vercellesi, Tutorial su MPEG-7 [ISO/IEC 15938]. Giugno 2006.
[2] Leonardo Chiariglione, MPEG-7 Overview. Ottobre 2004.
[3] José M. Martínez, Rob Koenen, and Fernando Pereira, MPEG-7: the generic
Multimedia Content Description Standard. Giugno 2002.
[4] DCMI - Dublin Core Metadata Initiative, http://dublincore.org
[5] libxml2 - The XML C parser and toolkit of Gnome, http://xmlsoft.org
[6] GNU libextractor - A simple library for keyword extraction,
http://www.gnu.org/software/libextractor
[7] eXist-db - An Open Source Native XML Database, http://exist-db.org.
[8] Federico Tonioni, Gestione di risorse per teche digitali con tecnologie MPEG-7, XML e Java.
[9] Apache Lucene, http://lucene.apache.org
[10] XQuery, http://www.w3.org/XML/Query
[11] CURL - The multiprotocol file transfer library, http://curl.haxx.se/libcurl
[12] Paolo Tatone, GStreamer mediaplayer plugin per l’integrazione in un sistema di Digital
Rights Management. L'Aquila, Ottobre 2009.
[13] Lorenzo Sfarra, Progettazione e realizzazione di un sistema DRM utilizzando SSL e
GStreamer. L'Aquila, Marzo 2010.