Sei sulla pagina 1di 5

Problema id avere risorse e ricercarle quando il crawler elegge una pagina per indicizzarla estrae anche dei metadati

(non necessariamente) i metadati servono per ritrovare e iriconoscere le risorse in rete, come scambiare i metadati c'e un livello di sintassi (come li esprimo i metadati?) un secondo livello dei contenuti (chi arriva e capisce la sintassi se non conosce poi il significato delle cose non capisce i metadati) rispeto ai dati bibliografici che dovevano descrivere solo un libro, con i metadati descrivo oggetti pi complicati se l;oggetto un programma (linguaggio, processore, etc...) il linguaggio (sintassi) per scambiare l;insieme di metadati XML (std di fatto per scambiarsi info sul web) il modello soap ne fa uso per richiesta e risposta REST usa XML in maniera pi elastica esistono pi formati per la descrizione delle risorse, uno dei primi marcxml (marc diffuso cos si riporta in XML) mods una versione di marc tendente a dc (sottoinsieme di marcxml) mads trasforma i documenti "umani" in machine readable (descrivere authority files) ead (linguaggio per gli archivi di documenti) ??? premis (metadati per la conservazione di risorse digitali o meno) (la conservazione necessita di un numero enorme di informazioni a seconda delle modalit e dei tempi scelti di durata della risorsa) (tre livelli della conoscenza dati info conoscenza (e la saggezza)) il problema di scambiarsi i dati nasce con i calcolatori nel momento in cui partecipavano a reti (sistemi distribuiti 1970) std per scambiare dati > ndr java classes, csv, xml, json, Distributed objects (corba, rmi, scambio di dati dipendente da ambiente), ndr (indipendente dalla rappresentazione del dato, nasce insieme a rpc) le precedenti rappresentazioni creano documenti "di testo" (usano caratteri) reutilizzo i meccanismi di posta elettronica e di parsing preesistenti (la raprresentazione di caratteri gi di fatto serializzata, non necessaria l'azione di marshalling) json costituito da due strutture dati: object (coppie {stringa:valore,stringa:valore}) array ([valore, valore]) mentre i valori possono essere stringhe numeri oggetti arraau booleani null json nasce da js per serializzare informazioni (oggetti in particolare) mantenendo la struttura lineare delle informazioni (json dovrebbe essere pi "leggero" di xml, ma meccanismi di compressione di quest'ultimo (es: tag di chiusura uguali apertura) lo possono rendere leggero) i parser json sono per pi leggeri in esecuzione (memoria e cpu)

rappresentazione e compressione delle immagini met anni 80 (contributi dall'industria televisiva, interessi commerciali)

l'immagine una matrice di pixel (densit dots per inch, range 600-6400) come rappresento i pixel? b/n (fax) 1bit per pixel gray scale (new fax) 8-12 bit per pixel full color 12-48 bit per pixel maggiore il numero di bit per pixel, maggiora la "fedelt" dell'immagine una pagina a colori scansionata a 600dpi contenuta in un file di 100MB sintesi additiva RGB (bianco somma dell'intensit massima dell'rgb) (three dots del tubo catodico) sintesi sottrattiva CMYK(ey) (nero somma dell'intensit massima di CMYx) (stampanti) formati di file immagini RASTER (sequenza di pixel) lossless compression (GIF, PNG) (G3, G4, JBIG) lossy (JPEG) image container (TIFF) raw (BMP, RAW sensore, DNG negativi digitali canon) VECTOR (descrizione geometrica) PDF, SVG, SWF, PostScript, ExtendedPS Postscript (descrive alla stampante come muovere la testina di stampa per disegnare sul foglio) (dipende dalla stampante?) -compressioni senza perdita ccitt standard, la necessit dal mondo del fax (anni 80) limitazioni delle linee telefoniche dell'epoca risoluzioni standard 200x100dpi o 200x200dpi high resolution tipicamente bianco e nero (due livelli) ogni riga fatta da pixel bianchi e pixel neri (codificare le run length) codificare la quantit di pixel consecutivi bianchi e di pixel consecutivi neri (le quantit di questi pixel fanno parte di un alfabeto "sono le lettere di questo alfabeto" Huffman code) esiste una tabella di codici (pi lunghi e pi corti) per la codifica dei run length g3, g4, jbig sono usati per la compressione di documenti d'ufficio (documenti da fax) le loro compressioni dipendono molto dall'alfabeto e quindi risultano non convenienti (se non controproducenti) per le immagini per le immagini a colori gif. costruisco una tabella di colori (tipicamente 256) e li rappresento a 24 bit, quindi metto come valore del colore l'indice nella tabella del colore corrispondente (se la tabella std posso non trasmetterla) la lista dei bit a quel punto essa stessa compressa con lzw (zip)

c' per perdita di informazioni nella scelta della tabella dei colori (approssimo i color reali ai 256 colori) usato anche per le immagini animate, perch il formato gif permette la ripetizione delle immagini intestazione + descrittore (esempio il periodo dell'animazione, lo spostamento delle immagini) + color table (opzionale) + sequenza di immagini (eventualmente con la loro color table) + trailer (poco usato) png, usa gzip invece di lzw e aumenta il numero dei colori (usato nella grafica web) -con perdita jpeg, se applico gif a immagini enormi perdo i vantaggi (e perdo sempre i colori!) nasce per le fotografie l'occhio umano percepisce un'approssimazione (interpolazione) della distribuzione dei pixel vicini (tessitura dei pixel adiacenti) si applica a ogni canale di colore (rgb, in compressione separata per colore) le immagini sono spezzettate in blocchi 8x8 pixel per essere elaborate singolarmente applico il coseno discreto (mi sposto in nuovo spazio, dall'intensit del canale "rosso" alle frequenze) butto le frequenze pi alte a seconda del livello di compressione (quantizzazione con matrici a seconda del livello di compressione Q10, Q20... Q99) selezioni i membri della tabella con ordine a zigzag per mettere gli elementi nulli alla fine applico l'Hoffman coder e ottengo l'immagine compressa devo poi fare le operazioni inverse (con approssimazioni che sono un'altra perdita) jpeg2000 usa una funzione di trasformazione differente (wavelets) con jpeg parto da 48bit per pixel, arrivo a 1,5 - 2 bit per pixel per le immagini migliori, 0,25-0,5 per le bozze tiff, contenitore di immagini. non un formato effettivo ma aggiunge informazioni descrittive (metadata) che includono tipi di immagini (b/w grayscale, palette, fullcolor) immagini spazi di colore - compressioni utilizzato soprattutto per archiviare le immagini rappresentazione dei video sequenza dei frame (frame per secondo) NTSC 30/s PAL 25/s HDTV 60/s risoluzione dei frame (pixel per lato) 720x480 - 768x576 - 1920x1080 un video non compresso occupa 1,5Gb/sec NTSC HD l'idea comprimere lavorando sulla ridondanza spaziale (per ogni frame / tipo jpeg) e la ridondanza temporale (l'immagine n+1 differisce solitamente di poco dall'immagine n) per la ridondanza spaziale si usa sempre la discrete cosine trasformation nel mondo della televisione prevale YUV luminanza e crominanza(a 2 componenti) (l'occhio pi sensibile alla luminanza che alla crominanza

cos non comprimo la prima) per la ridondanza temporale uso i motion vectors (spostamento dei blocchi 16x16 pixel) MPEG (motion picture experts group) industria cinematografica e videoludica (fine anni 80) mpeg-1 ha come obiettivo 1,5Mb/s con audio 64-192kb/s mpeg1 usa tre tipi di frame I frame (intra-frame coding) compressi (con dct) e indipendenti dagli altri frame P frame (predictive-coded) devo conoscere uno o pi precedenti I o P frame B frame (bi-directionally predictive coded) codificato secondo precedenti e futuri I e P frame (aumenta il livello di compressione) (introducono latenza nello streaming live) se la sequenza di questi frame 12 frame I B B P B B P B B P B B li memorizzo come 1 4 2 3 7 5 6 10 8 9 (ossia I P B B P B B ...) per l'audio un discorso di campionatura (almeno 8bit per campione) con una certa frequenza di campionatura esiste il teorema di shannon: per non perdere troppe informazioni devo campionare alla frequenza almeno doppia della frequenza pi alta che voglio mantenere (la trasformata di fourier ha un certo numero di componenti, decido quanti mantenere) l'orecchio umano percepisce dai 15Hz ai 20KHz, frequenze fuori da questo range sono scartabili (per questo 40KHz!!) l'algoritmo pi usato MPEG-1 layer 3 (MP3) stessa idea del jpeg applicato in maniera pi sofisticata al segnale acustico (onda) si pu partire da da 16bit a 48KHz (768Kb/s) fino a 32-256Kb/s mpeg2 (fino a 10Mb/s 720x486 DVD, supporta l'HD) (estensione di mpeg1) mpeg3 viene sviluppato come mpeg2 mpeg4 (migliori compressioni, bitrate scalabile, supporta i DRM, va oltre audio e video (testo, cgg, immagini ferme, menu) mpeg5 - mpeg6 assalto dei cybersquatter per ottenere i nomi a dominio collegati! mpeg7 va oltre le compressioni ???? mpeg21 un framework che intende digitalizzare tutto il multimedia lifecycle risorse (video, audio, immagini, testi...) modelli concettuali e di semantica continua nella slide mpeg 1-2-4 comprimere i bit mpeg 7-21 informazioni aggiuntive retrieval delle immagini prima generazione: inserimento di metadati manualmente (questo un tramonto) seconda generazione: content based image retrieval - le descrizioni sono minimali (o non esistono) quindi la ricerca funziona male

intorno alla met degli anni novanta nasce CBIR (ricerca sul contenuto, non sulla descrizione) visual content (colore, forma, ragionamento per vettori) informazioni sull'utente e dall'utente che l'ha creato in generale devo descrivere matematicamente l'immagine e devo accedere in maniera similare a immagini simili sulla base della loro rappresentazione matematica (vicinanza di immagini)