Vyhledávání v xml Milan Plachý

Obsah Strukturovaná data NEXI Indexace Vektorový model Výpočty relevance INEX Text centrické vs. Data centrické dokumenty

Relační databáze vs XML Relační databáze jsou schopny zvládat poměrně složité dotazy SELECT jméno FROM lidé WHERE zaměstnání LIKE ‘zahr%’ Strukturované dokumenty mají odlišnou strukturu a proto je nutné dotazovat se jinak Vyhledávání ve strukturovaném textu se nazývá structured retrieval

Vyhledávání ve strukturovaných textech (structured retrieval) Data jsou strukturována a korektně označkována Základní dvě kritéria na vyhledávání Textová Strukturální Příklad klasických dotazů Chci získat jména všech patentů, které přihlásil kdokoliv s příjmením Kukačka

Vyhledávání v XML (structured/semistructured retrieval) Pohled na XML jako na strom, kde vrcholy odpovídají elementům Každý element může obsahovat jeden a více atributů Listy obsahují text elementu, který je jejich otcem Vnitřní vrcholy kódují strukturu nebo jsou funkcemi metadat Standard pro přístup a zpracování dokumentů – XML DOM (Document object model) – reprezentace XML stromu Při vyhledávání se začíná od kořene a postupuje se logicky dále

Příklad XML a jeho reprezentace <hra> <autor>Shakespeare</autor> <jméno>Macbeth</jmeno> <akt číslo=“I“> <scéna číslo=“vii“> <název>Macbethův hrad</název> <verš>Budu vínem připíjeti</verš> </scéna> </akt> </hra>

Příklad XML a jeho reprezentace Kořenový element hra Element akt Element název Element autor Text Macbeth Element Shakespeare Atribut číslo = “I“ Element scéna Element název Element verš Atribut číslo = “vii“ Text Macbethův hrad Text Budu vínem ...

XPath Standard pro výpočet cest stromem Silný, pro potřeby vyhledávání potřebná pouze část Opakování Zadání výrazu vyhledá všechny vrcholy se zadaným jménem / odděluje následující vrcholy // libovolný počet vrcholů mezi oddělenými # oddělovač od listu (název#Macbeth)

Schémata Popis struktury strukturovaného dokumentu Pravidla a omezení Základní dvojice XML DTD XML Schema Pro zadávání dotazů je nutná znalost dokumentů popisujících schéma dokumentu, ve kterém vyhledáváme

NEXI (Narrowed extended XPath I) Běžný formát pro XML dotazy //článek [.//rok = 2001 or .//rok = 2002] //sekce [about(.,letní prázdniny)] Příklad Pro přehlednost rozdělen na řádky článek sekce letní prázdniny

NEXI // mají stejný význam jako v XPath Hledáme sekce knih (libovolný počet elementů mezi knihou a sekcí) . se odkazuje na klauzuli, kterou modifikuje Atribut rok je vztahový atribut Vyhledává se pouze v článcích z roků 2001 nebo 2002 Klauzule about je hodnotící, hodnotí se, jak je část relevantní vůči slovům letní prázdniny

NEXI Vztahový atribut jednoduše vyřadí všechny neodpovídající možnosti Prefiltering Postfiltering Odstraněním vztahových atributů získáme strom s jednotnou strukturou Odpadnou atributové vrcholy stromu Na stejném principu se dají stavět dotazy

Problémy Vyhledáváme ve strukturovaném textu za použití strukturovaného/nestrukturovaného dotazu Jak rozpoznat, zda uživatel chce pouze konkrétní část textu nebo text celý Dotazem na scénu v Macbethově hradu bude chtít uživatel pravděpodobně pouze tuto scénu Kdyby chtěl například hry, kde se vyskytuje Macbeth, pravděpodobně chce celou hru Kritérium výběru nejvhodnější části – PRINCIP ZÍSKÁVÁNÍ STRUKTUROVANÉHO DOKUMENTU

Princip získání strukturovaného dokumentu Systém by měl vždy vracet nejvíce specifickou část dokumentu Nejmenší odpovídající část Problém, co když vyhledáváme pouze název#Macbeth Nalezeno v názvu knihy Nalezeno v názvu scény Rozhodování, který vrchol je v pořádku je problematické (především algoritmicky)

Indexování Paralelní problém vůči výběru správné části Jakou část dokumentu indexovat? U nestrukturovaných dokumentů je jednoduché rozpoznat o co se jedná, u strukturovaných problém Možný přístup – seskupení vrcholů do nepřekrývajících se pseudodokumentů Může být nevýhodné pro uživatele, protože v pseudoelementu jsou spojeny zdánlivě nesmyslné množiny elementů

Pseudodokumenty - příklad Typ = “Dobrodružný“ Kniha Autor Název Kapitola Kapitola Brown D. Ztracený symbol

Indexování Další možností je použít velký element jako indexovací jednotku Např. Kniha v kolekci knih Poté pro každou knihu budeme hledat podelement s nejlepší shodou Často neužitečné, relevance knihy nedává dobrý popis relevance jejich částí Tomuto přístupu se říká odshora dolů (top down)

Další přístupy Odsdola nahoru (bottom up) Kompletní indexace Od listů nahoru Opačný problém než u top down Relevance listů nemusí být dobrý prediktor pro relevanci nadřazených elementů Kompletní indexace Indexování všech elementů Vysoký stupeň redundance

Kompletní indexace Nutnost vybrat užitečné elementy a ty oindexovat, ostatní ne Různé techniky Vyhození všech malých elementů Vyhození všech elementů, na které se uživatel neptá (nutnost logování a upravení po určité době) Vyhození všech elementů, které nejsou relevantní podle nějakého pravidla (pokud máme pravidla) Ponechání pouze typů elementů, které byly vybrány správcem (knihovník, ...)

Kompletní indexace I s použitím pravidel dochází často k velké redundanci Problém s hnízděnými elementy Uživatel nezná strukturu dokumentu Možnost zpracování postprocessingem Složení několika hnízděných elementů a jejich označení (highlighting) Zaměření pozornosti uživatele na označenou část Daná část je prezentována i s jejím kontextem

Rozlišování kontextů Potřeba rozlišit různé kontexty termu Např. z důvodu statistiky nebo výpočtu relevance Výpočet idf Pokud by se autor knihy jmenoval Zelí, pak nemá toto slovo vztah k výrazům v samotné knize Možné řešení počítání idf pro každý pár kontext/term Autor#“Zelí“ Text#“Zelí“ Velká část dvojic bude mít malou hodnotu df

Rozlišování kontextů Další řešení je brát v potaz pouze otce termu a ne jeho další předky Stále problémy, nejsou rozlišeny například jména firem a jména zaměstnanců, protože rodičovský element je jméno

Rozdílnost schémat Schema heterogeneity/schema diversity Více schémat se vyskytuje v kolekci Shodné elementy mají různá pojmenování (autor/tvůrce) Různá struktura celku Možnost použití automatického/poloautomatického porovnávání

UI a rozšiřování dotazu Řešení problému neznalosti názvů elementů Ideálně: zobrazená struktura dokumentu pomocí stromu Výběr konkrétních elementů uživatelem skrze interface Zobrazení vazeb rodič-potomek Rozšíření pro libovolný počet vrcholů mezi elementem a předkem

Rozšiřování dotazu Viz příklad s letními prázdninami Není nutné definovat přesnou cestu v dotazu Nezájem/neznalost Je velký rozdíl Kapitola Kapitola Název Název FFT FFT

Vektorový model pro vyhledávání v XML V následujícím případě budeme chtít, aby kniha se jménem Ceasar měla větší váhu než kniha, jíž je autorem V nestrukturovaném textu – 1-dimensionální vektorový prostor Kniha Kniha Název Název Autor Ceasar Galské Ceasar

Vektorový model Možnost kódovat slovo společně s pozicí v XML stromě Každý list je rozdělen na jednotlivá slova – nové listy Vytvoření všech podstromů zakončených termem Slovníkové podstromy Poté možnost klasického vyhledávání ve vektorovém prostoru

Vytvoření slovníkových podstromů Microsoft Bill Kniha Název Autor Název Autor Microsoft Bill Microsoft Bill Gates Kniha Kniha Název Autor Microsoft Bill Gates

Dimensionalita Dimense vyvažuje na druhé straně přesnost a množství nalezených dokumentů Pokud nepovolíme dimenze – klasické vyhledávání – velký počet nalezených dokumentů s malou přesností Gates nebyl myšlen jako autor článku atd. Na druhou stranu při vytvoření všech podstromů jako dimenzí – zabrání velkého prostoru Řešení – indexace všech cest, které končí v jednoduchém termu – Strukturovaný term

Strukturované termy Značení : <c,t> (<kontext,term>) V příkladě s Gatesem chybí např: /Book/Author#“Bill“ Podstrom s listy Bill a Gates není strukturovaný term Používá se pseudo-XPath notace

Výpočet podobnosti Protože uživatel nezná strukturu textu, je nutné spočítat podobnosti různých cest CR...podobnost kontextu (context resemblance) cq...dotaz, cd...dokument,|cq|/|cd|...počet vrcholů dotazu/dokumentu CR(cq,cd)= 1+|cq| 1+|cd|

Výpočet podobnosti Výpočet relevance dokumentu jako celku Cosinová míra pomocí fce SimNoMerge(SNM) V...slovník nestrukturovaných termů B...množina XML kontextů weight(q,t,c)...váha(hodnocení termu t v dotazu q a kontextu c SMN(q,d) = Σ Σ CR(ck,cl) Σ weight(q,t,ck) ckϵB cl ϵB t ϵV Weight(d,t,cl) Σ weight^2(d,t,c) c ϵB,t ϵV

Výpočet podobnosti Hodnoty weight se dá počítat klasicky jako IDF nebo DF SNM není klasická kosinová míra, hodnoty větší než 1 Možnost normalizace

SNM - příklad <c1,t>...strukturovaný term <c´,t>...získané strukturované termy se shodným termem dotaz <c1,t> <c1,t> <d1,0,50> <d4,0,10> <d9,0,20> CR(c1,c1) = 1 <c2,t> <d2,0,25> <d3,0,10> <d12,0,90> CR(c1,c2) = 0 <c3,t> <d3,0,70> <d6,0,80> <d9,0,60> CR(c1,c3) = 0,63

SNM - příklad Řádek odpovídající podobnosti c1,c2 bude ignorován Dokument s nejvyšší podobností bude d9 (1 * 0,2) + (0,63 * 0,6) = 0,578

/hra/jméno#’Macbeth’ SimMerge(SM) SNM dělá pro separované kontexty zvlášť výpočty SM počítá statistiky pro všechny spočtení weight(q,t,c) a weight(d,t,c) ze všech kontextů (kromě těch s nulovou podobností Modifikace rovnice, spojení termů se strukturou odpovídající dotazu Hra/jméno Hra/akt/scéna/jméno Často lepší než SNM /hra/jméno#’Macbeth’

INEX Vyhodnocení vyhledávání v XML Základní oblast vyhodnocování XML vyhledávání INitiative for the Evaluation of XML retrieval Odkazy na kolekce Množiny dotazů Posouzení relevance výsledků Relevance dokumentů je následně posuzovány lidmi

INEX historie 2002 2005 2006 Především prezentace výsledků dotazování Zhruba 12000 článků z IEEE žurnálů, 494 MB 1532 uzlů na dokument, průměrná hloubka uzlu - 7 2005 Rozšíření kolekcí 2006 Více článků než wikipedia(en)

Zjednodušené schéma INEX dokumentu článek základní údaje tělo název článku název žurnálu sekce název odstavec ... ... Úvod ... Tato práce...

INEX – typy informací 2 základní typy informací CO topics CAS topics CAS (Content And Structure) Obsahují klíčová slova a popis struktury Viz příklad s letními prázdninami Složitější výpočet relevance Na INEX 2002 byla přesnost struktury (správná hloubka) a přesnost tématu (konkrétní části) definována jako dvě ortogonální dimenze

CAS – přesnost struktury Vyhodnocení správnosti nalezené struktury Není příliš hloboko ve stromě nebo naopak příliš vysoko 4 případy Přesné pokrytí (E) – hledaná informace je v hlavní části komponenty a daná komponenta je smysluplná Příliš malé (S) – hledaná informace je v hlavní části komponenty, ale komponenta není smysluplná Příliš velké (L) – hledaná informace je v článku, ale není to hlavní část Žádné pokrytí (N) – hledaná informace není součástí komponenty

CAS – tématická přesnost Tématická dimenze má podobně jako strukturální 4 úrovně přesnosti (3) – velmi relevantní (2) – relevantní (1) – méně relevantní (0) – nerelevantní Teoreticky je možných 16 kombinací obou dimenzí Některé možnosti nemohou nastat (3N)

CAS – kombinace dimenzí Přiřazení konstant relevance konkrétním kombinacím z obou dimenzí Značení Q(rel,cov) 1,00 3E 0,75 2E,3L 0,50 1E,2L,2S 0,25 1S,1L 0,00 0N

CAS Σ c ϵB Q(rel(c), cov(c)) Výpočet relevantních komponent se dá spočítat například jako Nepočítá se s překrýváním Σ c ϵB Q(rel(c), cov(c))

Text centrické vs. Data centrické XML dotazování Předchozí text byl věnován text centrickému přístupu Porovnávání textu v dotazu s textem v dokumentu Důležitá struktura i text Větší sílu má text Adaptace metod z nestrukturovaných dokumentů Dlouhá textová pole Porovnávání na neúplnou shodu Hodnocení výsledků dle relevance S tím špatně pracuje relační db

Data centrické XML dokumenty Numerické nebo jinak definované netextové údaje Vyhledává se na přesnou shodu Př. Najdi zaměstnance, kteří mají tento měsíc stejné příjmy jako minulý Používá se pro kolekce dat s danou strukturou Lepší v případech kdy je potřeba join Lepší v případech kdy je potřeba přetřídit data Chceme získat text kapitoly, která následuje po...

Data centrické XML dokumenty Různé jazyky pro data centrické dokumenty Často inspirováno relačními db, nebo jsou přímo jejich rozšířením XQuery Velice silný, složitý a robustní Pokrývá všechny oblasti dotazování v XML Vytvoření dotazu může být často složité

Materiály Introduction to Information Retrieval Online edition (c)2009 Cambridge UP DRAFT! © April 1,2009 Cambridge University 10 XML retrieval Information retrieval systems are often http://nlp.stanford.edu/IR-book/pdf/10xml.pdf