V této úloze se pracuje s jistou množinou (množinami) emailových zpráv, které mohou být nějakým způsobem opatřeny meta-informací. Takové množině se často říká korpus. V našem případě budou moci být emaily navíc doplněny meta-informacemi o tom, zda jeden každý email skutečně je nebo není spamem, a o tom, zda si spam filtr myslí, že jeden každý email je spamem.
Máte k dispozici 2 sady dat pocházející ze stejného zdroje.
Domluvme se tedy následovně: emailový korpus pro nás bude představovat
!truth.txt
, který bude obsahovat na každém řádku jméno souboru a informaci o tom, zda email uložený v daném souboru je či není spam, a!prediction.txt
, který bude obsahovat na každém řádku jméno souboru a informaci o tom, zda email uložený v daném souboru je spam filtrem považován za spam nebo ne. (Tento soubor samozřejmě v datech, které od nás dostáváte, nenajdete - tento soubor bude vytvářet váš spam filtr.)Samozřejmě platí, že tyto dva soubory v adresáři být mohou, ale také nemusí:
!prediction.txt
, který bude obsahovat jeho odhady.
!truth.txt
. Jinak byste nevěděli, které emaily jsou spam.
!truth.txt
i !prediction.txt
. Porovnáním údajů v těchto dvou souborech zjistíme, jak moc se předpovědi filtru shodují se skutečností. (Vlastní emaily zde vlastně ani nebudeme potřebovat).
S obsahem souborů lze pracovat jako s prostým textem, aniž byste předpokládali, že soubory mají nějakou vnitřní strukturu.
Pokud ale chcete jejich strukturu využít (což samozřejmě můžete), vězte, že tyto soubory měly odpovídat normě RFC5322 (příp. RFC2822). V ní se v článku 3.6 píše:
The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional.
Nespoléhejte tedy na to, že všechny emaily budou mít subjekt, nebo další pole!!!
V tomtéž dokumentu se také dočtete:
It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, ...