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:

    <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>     <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">

 <MultimediaContent xsi:type=" VideoType">

<Video> <MediaInformation>

<MediaProfile>  <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>

17

<MediaUri> /home/user/video.mp4

</MediaUri> </MediaLocator>

</MediaInstance> </MediaProfile>

</MediaInformation> <CreationInformation>

<Creation>  <Title> Il mondo che vorrei</Title>

<Abstract>  <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>  <Location> <Name>Italia</Name>

</Location>  <Date>

<TimePoint> 2009</TimePoint>

</Date> </CreationCoordinates>

</Creation> </CreationInformation>

</Video> </MultimediaContent>  <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> this paragraph tests the things made u p by <name>ron</name>. this paragraph tests the other issues made up by <name>edward</name>. </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 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>  <fulltext default="all" attributes="no"/>  <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">  <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>  <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.

 <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.

 <collection xmlns="http://exist-db.org/collection-c onfig/1.0"> <index xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001">  <fulltext default="none" attributes="no"/>  <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.

Lo standard MPEG-7 per la definizione di metadati di oggetti multimediali

Technology

Transcript of Lo standard MPEG-7 per la definizione di metadati di oggetti multimediali