Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. z heterogenních dat

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace Z´ısk´ an´ı a uchov´ an´ı metadat z heterogenn´ıch dat

Plzeˇ n 2015

Martin Kryl

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 11. kvˇetna 2015 Martin Kryl

Abstrakt Práce ˇreˇs´ı problém ˇcten´ı metadat z obrazov´ ych soubor˚ u a jejich zápis do RDF modelu. Zamˇeˇril jsem se na soubory typu JPEG, PNG a TIFF. Ke ˇcten´ı metadat je vyuˇzita knihovna Metadata Extractor. Mapován´ı je definováno v ontologii. Je snaha o vyuˇzit´ı pojm˚ u z existuj´ıc´ıch RDF slovn´ık˚ u. Pro pˇr´ıpady, kdy nen´ı ˇza´dn´ y vhodn´ y pojem k dispozici, vytváˇr´ım vlastn´ı slovn´ık RDF vlastnost´ı. V´ ysledná ontologie mapuje 107 Exif makernote tag˚ u a 207 tag˚ u ostatn´ıch metadatov´ ych formát˚ u na vlastnosti existuj´ıc´ıch ontologi´ı. Implementace má formu pluginu pro program MetaMed. Kl´ıˇcová slova: RDF, metadata, obrazové soubory, ontologie, RDF slovn´ık, JPEG, PNG, TIFF, Exif, XMP.

Abstract This work tackles an issue of reading metadata from image files and adding them to RDF model. Image file types in the scope of the work are JPEG, PNG and TIFF. Metadata Extractor library is used for reading metadata from image files. Mapping definition is written in ontology file. Using existing vocabulary terms is preferred. In case no viable vocabulary term exists, a new property is defined in newly created ontology. Created mapping ontology has 107 defined mappings of Exif Makernote tags on existing terms and 207 mappings of other metadata tags. Extraction procedure is implemented as a plugin for MetaMed application. Keywords: RDF, metadata, image files, ontology, RDF vocabulary, JPEG, PNG, TIFF, Exif, XMP.

Obsah ´ Uvod

1

1 RDF a ontologie 1.1 Resource Description Framework 1.1.1 RDF trojice . . . . . . . . 1.1.2 Linked data . . . . . . . . 1.2 Ontologie a slovn´ıky . . . . . . . 1.2.1 RDF schéma . . . . . . . 1.2.2 Web Ontology Language .

. . . . . .

2 2 2 4 5 6 8

. . . . . . . . . . . . . .

11 12 12 13 13 14 15 15 16 17 17 18 19 19 20

. . . . . . . . . . .

21 21 21 22 22 23 23 24 25 25 26 27

. . . . . .

. . . . . .

. . . . . .

. . . . . .

2 Obrazov´ e soubory a metadata 2.1 JPEG . . . . . . . . . . . . . . . . . . . 2.1.1 JPEG Interchange Format . . . . 2.1.2 JPEG File Interchange Format . 2.1.3 Exchangeable Image File Format 2.1.4 Extensible Metadata Platform . . 2.1.5 Information Interchange Model . 2.1.6 Photoshop Image Resources . . . 2.1.7 ICC profil . . . . . . . . . . . . . 2.2 PNG . . . . . . . . . . . . . . . . . . . . 2.2.1 Struktura souboru . . . . . . . . 2.2.2 Dalˇs´ı metadata . . . . . . . . . . 2.3 TIFF . . . . . . . . . . . . . . . . . . . . 2.3.1 Struktura souboru . . . . . . . . 2.3.2 Dalˇs´ı metadata . . . . . . . . . . 3 Existuj´ıc´ı n´ astroje 3.1 Nástroje pro extrakci metadat . . . . . . 3.1.1 Exiv2 . . . . . . . . . . . . . . . 3.1.2 ExifTool . . . . . . . . . . . . . . 3.1.3 Metadata Extractor . . . . . . . . 3.1.4 Aperture . . . . . . . . . . . . . . 3.1.5 Porovnán´ı nástroj˚ u . . . . . . . . 3.2 Bˇeˇzné slovn´ıky a ontologie . . . . . . . . 3.2.1 Dublin Core . . . . . . . . . . . . 3.2.2 Friend of a Friend . . . . . . . . . 3.2.3 Kanzaki Exif . . . . . . . . . . . 3.2.4 NEPOMUK Information Element

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . .

3.2.5 3.2.6

Geo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Adobe slovn´ıky . . . . . . . . . . . . . . . . . . . . . . 28

4 N´ avrh ˇ reˇ sen´ı 4.1 Poˇzadavky na ˇreˇsen´ı . . . . . . . . . 4.2 Test existuj´ıc´ıch extrakˇcn´ıch nástroj˚ u 4.3 Volba nástroje . . . . . . . . . . . . . 4.4 V´ ybˇer ontologi´ı a slovn´ık˚ u . . . . . . 4.5 Implementované rozhran´ı . . . . . . . 4.6 Struktura Metadata Extractoru . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Implementace 5.1 Bal´ık extractor . . . . . . . . . . . . . . . . 5.1.1 Algoritmus extrakce . . . . . . . . . 5.2 Bal´ık commons . . . . . . . . . . . . . . . . 5.2.1 Tˇr´ıda pro práci s konfigurac´ı . . . . . 5.2.2 Tˇr´ıda ke zpracován´ı a zápisu metadat 5.3 Datová tˇr´ıda IndividualData . . . . . . . . . 5.4 Bal´ık util . . . . . . . . . . . . . . . . . . . 5.4.1 Formátován´ı logu . . . . . . . . . . . 5.4.2 Práce s daty a ˇcasem . . . . . . . . . 5.4.3 Transformace extrahovan´ ych hodnot 5.4.4 Tˇr´ıda ExtractorUtil . . . . . . . . . . 5.5 Vytvoˇrené ontologie . . . . . . . . . . . . . . 5.5.1 Mapovac´ı ontologie . . . . . . . . . . 5.5.2 Pojmová ontologie . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . .

29 29 29 32 33 34 35

. . . . . . . . . . . . . .

36 36 38 40 41 42 46 47 47 47 48 51 53 53 54

6 Diskuze v´ ysledku 56 6.1 V´ ykonnostn´ı metriky . . . . . . . . . . . . . . . . . . . . . . . 56 6.2 Srovnán´ı s ˇreˇsen´ım jin´ ych autor˚ u . . . . . . . . . . . . . . . . 58 6.3 Problémy ˇreˇsen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Z´ avˇ er

60

Pouˇ zit´ e zkratky

61

Literatura

62

´ Uvod V souˇcasné dobˇe existuje velké mnoˇzstv´ı formát˚ u soubor˚ u, do kter´ ych lze zapisovat data. Datov´ y soubor m˚ uˇze kromˇe samotn´ ych dat obsahovat i popis dat, tzn. metadata. Pˇreˇcten´ım a pochopen´ım metadat lze z´ıskat informace uˇziteˇcné pro dalˇs´ı zpracován´ı soubor˚ u, jejich anal´ yzu nebo vyhledáván´ı. Struktura metadat je vˇetˇsinou definovaná pouze pro konkrétn´ı formát souboru nebo malou mnoˇzinu formát˚ u. Jeden formát souboru m˚ uˇze nav´ıc obsahovat nˇekolik typ˚ u metadatov´ ych struktur. Metadata nacházej´ıc´ı se v r˚ uzn´ ych strukturách se mohou v´ yznamovˇe pˇrekr´ yvat. C´ılem této práce je vytvoˇrit plugin pro program MetaMed, kter´ y je vyv´ıjen na Katedˇre informatiky a v´ ypoˇcetn´ı techniky v rámci v´ yzkumné skupiny Medic´ınské informaˇcn´ı systémy. Plugin umoˇzn´ı ˇc´ıst metadata z obrazov´ ych soubor˚ u JPEG, TIFF a PNG. Extrahovaná metadata budou zapsána do RDF modelu. V souvislosti s t´ım navrhnu mapován´ı obrazov´ ych metadat na RDF vlastnosti existuj´ıc´ıch ontologi´ı. Pro metadata, která nebude moˇzné vhodnˇe pˇriˇradit k existuj´ıc´ım vlastnostem, vytvoˇr´ım vlastn´ı RDF slovn´ık.

1

1 RDF a ontologie 1.1

Resource Description Framework

Resource Description Framework, dále jen RDF, je v u ´vodu [1] pˇredstaven jako framework pro popis vlastnost´ı urˇcitého zdroje (resource). Zdrojem m˚ uˇze b´ yt cokoliv – dokumenty, osoby, fyzické objekty pˇr´ıpadnˇe i abstraktn´ı koncepty. RDF je uˇziteˇcné v situac´ıch, kdy je potˇreba, aby informace uloˇzené na webu nam´ısto ˇclovˇeka zpracoval stroj a porozumˇel jim. Framework dále umoˇzn ˇuje v´ ymˇenu dat mezi aplikacemi. RDF specifikace spravuje World Wide Web Consortium (W3C). W3C je mezinárodn´ı organizace pro v´ yvoj a správu webov´ ych standard˚ u, která byla zaloˇzena v ˇr´ıjnu 1994. Organizace na sv´ ych webov´ ych stránkách [2] uvád´ı jako svoji misi vytváˇren´ı protokol˚ u a doporuˇcen´ı, které zajist´ı dlouho trvaj´ıc´ı r˚ ust webu a umoˇzn´ı vyuˇz´ıt cel´ y jeho potenciál.

1.1.1

RDF trojice

Základn´ı strukturou RDF je RDF statement (v ˇceˇstinˇe se lze setkat s pˇreklady RDF tvrzen´ı nebo prohláˇsen´ı). Ten má formu trojice subjekt, predikát, objekt. Subjektem je popisovan´ y zdroj. Predikátem se rozum´ı vlastnost, kterou subjekt má. Objekt vyjadˇruje hodnotu vlastnosti. K trojici se m˚ uˇze pˇridat název grafu, v nˇemˇz je obsaˇzena, pak je tedy RDF statement tvoˇren ˇctveˇric´ı hodnot (v angliˇctinˇe RDF quad). "Hamlet" "Hamlet" "Hamlet" "Hamlet"

-

"je" "byl "byl "je"

- "trag´ edie". naps´ an" - "William Shakespearem". publikov´ an" - "1603". - "princ".

V´ ypis 1.1: Trojice popisuj´ıc´ı d´ılo a postavu Hamlet v pˇrirozeném jazyce. V´ ypis 1.1 ukazuje, jak by bylo moˇzné základn´ı informace o d´ıle Hamlet zapsat v pˇrirozeném jazyce. Takov´ y zápis je pro ˇclovˇeka ˇciteln´ y, nicménˇe pro stroj je tˇeˇzko uchopiteln´ y. Hlavn´ım problémem je rozliˇsen´ı, kdy se Hamletem

2

RDF a ontologie


rozum´ı název d´ıla a kdy jde o postavu ve hˇre. RDF toto ˇreˇs´ı pouˇzit´ım Internationalized Resource Identifier (IRI) definovan´ ych v [3], coˇz je urˇcitá nadmnoˇzina Uniform Resource Identifier (URI) pouˇz´ıvan´ ych k jednoznaˇcnému oznaˇcen´ı zdroj˚ u na webu. Na subjekt je odkazováno jednoznaˇcnˇe a je strojovˇe rozliˇsitelné, ˇze se jedná o r˚ uzné entity, i kdyˇz jejich popisn´ y název m˚ uˇze b´ yt stejn´ y. Na hru Hamlet m˚ uˇze odkazovat napˇr´ıklad http://lit.org/play/hamlet a na postavu http://lit.org/characters/hamlet. Pojem je v predikátu m˚ uˇze nab´ yvat v´ıce v´ yznam˚ u, vlastnost popisuj´ıc´ı ˇzánr d´ıla resp. roli osoby ve spoleˇcnosti. Pro poˇzadovanou vlastnost v predikátu se proto pouˇzije také IRI. V pˇr´ıpadˇe objektu je moˇzné odkázat na zdroj pomoc´ı IRI, nebo pouˇz´ıt literál. Kaˇzd´ y ze zp˚ usob˚ u je vhodn´ y pro jinou situaci. V tomto pˇr´ıpadˇe rok 1603 jiˇz pravdˇepodobnˇe nebude vystupovat v jiné trojici jako subjekt a je tedy vhodné zapsat ho jako literál. Naopak na objekt William Shakespeare je lepˇs´ı odkázat pomoc´ı IRI jak z d˚ uvodu rozliˇsen´ı mezi osobami stejného jména, tak umoˇznˇen´ı dalˇs´ıho popisu osoby. Sada RDF trojic tvoˇr´ı strukturu orientovaného grafu, kdy subjekt a objekt jsou vrcholy grafu a predikát je orientovaná hrana ze subjektu do objektu. Uzly mohou m´ıt formu literálu nebo IRI, jak jiˇz bylo zm´ınˇeno. Kromˇe toho je moˇzné jako uzel pouˇz´ıt tak zvan´ y prázdn´ y uzel (blank node) také obˇcas naz´ yvan´ y anonymn´ı zdroj (anonymous resource), jak uvád´ı [4] v kapitole 3.1. Jedná se o uzel, kter´ y nemá pˇriˇrazen´ y ˇzádn´ y globáln´ı identifikátor a v závislosti na zvoleném zp˚ usobu serializace je mu pˇriˇrazen m´ıstn´ı identifikátor na u ´rovni grafu. Lei Chen [5] vymezuje jejich uˇzit´ı do následuj´ıc´ıch pˇr´ıpad˚ u: • Vyjmenován´ı mnoˇziny prvk˚ u, jako napˇr´ıklad skupinu spoluautor˚ u knihy. • Zapsán´ı komplexn´ı datové struktury jako napˇr´ıklad adresu bydliˇstˇe, která se skládá z názvu ulice, mˇesta a ˇc´ısla domu. Prázdn´ y uzel zde bude vystupovat jako objekt pro predikát adresa a zároveˇ n bude subjektem pro predikáty ulice, mˇesto a popisné ˇc´ıslo. • K zapsán´ı kontextové informace pro RDF tvrzen´ı jako den vytvoˇren´ı nebo jméno autora. • M˚ uˇze pomoci k popisu zdroje, jehoˇz identifikátor je shodn´ y, jako nˇekterá z jeho vlastnost´ı. Napˇr´ıklad u osoby jej´ıˇz IRI odpov´ıdá IRI jej´ı emailové adresy. Zápis stejn´ ych dat jako v pˇredeˇslém pˇr´ıkladu do RDF je uveden ve v´ ypisu 1.2. Pˇri pˇreveden´ı t´ımto zp˚ usobem se ale ztratila ˇca´st informace o názvu 3

RDF a ontologie


d´ıla a postavy. Nen´ı totiˇz obecnˇe zaruˇceno, ˇze IRI subjektu bude obsahovat to, co bychom chápali jako název popisovaného zdroje. Název je tak nutné zadefinovat dalˇs´ı trojic´ı. . . "1603" . "princ" . V´ ypis 1.2: RDF trojice popisuj´ıc´ı d´ılo a postavu Hamlet. V ukázce 1.2 byl pouˇzit formát N-Triples. Tento formát má sice jednoduchou syntaxi, ale na zapsán´ı informace je potˇreba relativnˇe velké mnoˇzstv´ı znak˚ u. Nav´ıc informace takto zapsaná nen´ı pˇr´ıliˇs dobˇre ˇcitelná pro ˇclovˇeka. Existuj´ı i dalˇs´ı formáty, které se liˇs´ı ˇcitelnost´ı nebo potˇrebn´ ym m´ıstem k zapsán´ı dat. Dle mého názoru je jedn´ım z nejˇcitelnˇejˇs´ıch a zároveˇ nu ´sporn´ ych formát˚ u Turtle, kter´ y budu pouˇz´ıvat dále v dokumentu. Formát umoˇzn ˇuje definovat na zaˇca´tku souboru pˇredpony (prefixy), kter´ ymi se budou substituovat ˇca´sti IRI se jmenn´ ym prostorem. Zápis ekvivalentn´ı k 1.2 je uveden ve v´ ypisu 1.3. @prefix @prefix @prefix @prefix @prefix

play: . terms: . char: . people: . dc: .

play:hamlet dc:type terms:tragedy . play:hamlet dc:creator people:wiliam-shakespeare. play:hamlet dc:issued "1603". char:hamlet terms:role "princ". V´ ypis 1.3: Trojice popisuj´ıc´ı d´ılo a postavu Hamlet v Turtle syntaxi.

1.1.2

Linked data

V souvislosti s RDF modelem se ˇcasto hovoˇr´ı o konceptu linked data. Koncept prvnˇe uvedl Tim Berners-Lee [6]. Koncept popisuje pˇr´ıstup, jak´ y je tˇreba 4

RDF a ontologie

Ontologie a slovn´ıky

zvolit k publikován´ı strukturovan´ ych dat tak, aby byly lépe prozkoumatelné a vyuˇzitelné. D˚ usledkem by mˇelo b´ yt, ˇze data budou provázána a na základˇe znám´ ych dat bude moˇzné naj´ıt jiná relevantn´ı data. V dokumentu [6] BernersLee vymezuje ˇctyˇri podm´ınky k fungován´ı a r˚ ustu sémantického webu: 1. Pouˇz´ıván´ı URI k pojmenován´ı zdroj˚ u. 2. Pouˇz´ıván´ı HTTP URI, aby ˇslo dohledat dané zdroje. 3. Kdyˇz nˇekdo vyhledá dané URI, poskytnout uˇziteˇcné informace o zdroji za pouˇzit´ı standardn´ıch technologi´ı (RDF, SPARQL). 4. V odpovˇedi uvést i odkazy na jiné relevantn´ı URI, aby bylo moˇzné objevit dalˇs´ı informace. Vztah k RDF je patrn´ y z prvn´ıho a tˇret´ıho bodu. Prvn´ı bod odpov´ıdá zp˚ usobu, jak´ ym jsou identifikovány zdroje v RDF. Vyj´ımkou jsou prázdné uzly, které je moˇzné pˇrevést na IRI jak uvád´ı specifikace [4] v kapitole 3.5. Tˇret´ım bodem je pˇr´ımo jmenováno RDF jako preferovan´ y zp˚ usob podán´ı informace a SPARQL jako jazyk pro dotazován´ı se nad RDF modelem. ˇ Ctvrt´ y bod a jeho aplikace je v dalˇs´ı ˇca´sti dokumentu [6] bl´ıˇze rozebrán. V d˚ usledku jde opˇet o koncept, kter´ y jsem popsal v pˇredeˇslé sekci, kdy v objektu RDF trojice je moˇzné, ˇcasto i chtˇené, odkázat pomoc´ı IRI na jin´ y zdroj, sp´ıˇse neˇz pouˇz´ıt literál.

1.2


Sémantick´ y v´ yznam RDF trojice vycház´ı z predikátu, kter´ y vyjadˇruje vlastnost, jenˇz propojuje subjekt a objekt. V kapitole 1.1.1 popisuji, ˇze na pozici predikátu mus´ı b´ yt IRI. To samo o sobˇe k zajiˇstˇen´ı sémantické informace nestaˇc´ı. Uvaˇzujme vyjmenován´ı hlavn´ıch postav d´ıla Romeo a Julie trojicemi ve v´ ypisu 1.4. V ukázce pouˇz´ıvám anglické term´ıny hero a heroine pro hlavn´ı muˇzskou, resp. ˇzenskou postavu. Bez dalˇs´ı definice z tˇechto trojic nedokáˇze stroj pochopit ˇza´dn´ y hlubˇs´ı v´ yznam. Z jeho pohledu jde o neurˇcité vlastnosti hero a heroine, které propojuj´ı neurˇcit´ y zdroj romeo-and-juliet se zdroji romeo a juliet. Aby stroj pochopil, ˇze obˇe vlastnosti jsou si bl´ızké a liˇs´ı se pouze v pohlav´ı osoby, které je vlastnost´ı implikována, je nutné vlastnost bl´ıˇze definovat pomoc´ı ontologie ˇci slovn´ıku. Ontologie je definována jako sada formáln´ıch jednoznaˇcn´ ych tvrzen´ı popisuj´ıc´ı urˇcitou ˇca´st svˇeta [7]. 5

RDF a ontologie


@prefix play: . @prefix terms: . @prefix char: . play:romeo-and-juliet terms:hero char:romeo . play:romeo-and-juliet terms:heroine char:juliet . V´ ypis 1.4: Trojice popisuj´ıc´ı hlavn´ı postavy hry Romeo a Julie. Dalˇs´ı sémantick´ y problém m˚ uˇze vyvstat, pokud by jiná organizace chtˇela popisovat pomoc´ı RDF divadeln´ı hry a pro své potˇreby si nadefinovala svoji vlastnost http://lit.cz/rdf/hlavniPostava, která by byla pro postavy obou pohlav´ı. V rámci konceptu linked data by bylo ˇza´dané modely obou organizac´ı propojit. Nicménˇe pˇri snaze o propojován´ı vlastnost´ı hero, heroine a hlavniˇ sen´ım by mohla Postava by doˇslo ke konfliktu ontologické definice pojm˚ u. Reˇ b´ yt ontologie definuj´ıc´ı vztah tˇechto pojm˚ u. Pokud by stejn´ y postup mˇel b´ yt provádˇen pro kaˇzdou dalˇs´ı podobnou organizaci, stane se takové ˇreˇsen´ı ˇcasovˇe i finanˇcnˇe ne´ unosné. Z tohoto d˚ uvodu je vhodné pouˇz´ıt v ˇreˇsen´ı jiˇz existuj´ıc´ı definované pojmy a vlastnosti, pokud se svoj´ı definic´ı shoduj´ı s poˇzadavky ˇreˇsen´ı. Pojem RDF slovn´ıky (vocabularies) oznaˇcuje sady pojm˚ u, které jsou urˇceny k dalˇs´ımu pouˇzit´ı v ciz´ıch ontologi´ıch nebo aplikac´ıch.

1.2.1

RDF sch´ ema

RDF Schema (RDFS) [8], spravované W3C, je základn´ı slovn´ık k vytváˇren´ı datov´ ych model˚ u a ontologi´ı. Definované pojmy slovn´ıku jsou um´ıstˇené na jmenn´ ych prostorech http://www.w3.org/2000/01/rdf-schema# standardnˇe substituovan´ ym jako rdfs: a http://www.w3.org/1999/02/22-rdf-syntax-ns# nahrazovan´ ym prefixem rdf:. Pojmy se dˇel´ı na tˇr´ıdy a vlastnosti. V´ yznamné tˇr´ıdy definované v RDFS jsou: • rdfs:Resource kaˇzd´ y zdroj vystupuj´ıc´ı v RDF tvrzen´ı je instanc´ı této tˇr´ıdy. • rdfs:Class kaˇzd´ y zdroj, kter´ y je tˇr´ıdou, je instanc´ı této tˇr´ıdy. Tˇr´ıdy rdfs:Class a rdfs:Resource jsou instancemi rdfs:Class. • rdfs:Literal tˇr´ıda pro literály. Je podtˇr´ıdou rdfs:Resource. • rdfs:Datatype tˇr´ıda pro datové typy literál˚ u. Kaˇzdá instance tˇr´ıdy je podtˇr´ıdou rdfs:Literal. 6

RDF a ontologie


• rdf:Property tˇr´ıda pro RDF vlastnosti. RDF vlastnosti jsou dle specifikace [4] relace mezi zdrojem v subjektu a zdrojem v objektu. Vˇsechny vlastnosti jsou instanc´ı rdf:Property. V´ yznamné definované vlastnosti v RDFS jsou: • rdfs:range slouˇz´ı k definici tˇr´ıdy nebo mnoˇziny tˇr´ıd, jej´ıˇz instanc´ı je zdroj o v trojici (s, p, o), kdyˇz p je vlastnost, kterou pomoc´ı rdfs:range upravujeme. • rdfs:domain je pouˇz´ıvána obdobnˇe jako rdfs:range a definuje tˇr´ıdu nebo mnoˇzinu tˇr´ıd, jej´ıˇz instanc´ı je zdroj s na pozici subjektu. • rdf:type k vyjádˇren´ı, ˇze popisovan´ y zdroj je instanc´ı urˇcité tˇr´ıdy. • rdfs:subClassOf k vyjádˇren´ı, ˇze daná tˇr´ıda je podtˇr´ıdou jiné. Vˇsechny instance podtˇr´ıdy jsou zároveˇ n instancemi nadtˇr´ıdy. • rdfs:subPropertyOf k vyjádˇren´ı, ˇze daná vlastnost p je podˇrazená jiné vlastnosti P. Zdroje, které jsou v relaci p, jsou zároveˇ n v relaci P. • rdfs:label, rdfs:comment k vloˇzen´ı ˇclovˇekem ˇcitelného názvu zdroje, resp. jeho popisu. RDF umoˇzn ˇuje k textov´ ym hodnotám pˇriˇradit jazyk, kter´ ym jsou zapsané. D´ıky tomu je moˇzné udˇelat v´ıcejazyˇcné popisky a dokumentaci. Kromˇe tˇechto základn´ıch pojm˚ u jsou definované i dalˇs´ı, které maj´ı specifické pouˇzit´ı. Definované jsou tˇr´ıdy popisuj´ıc´ı mnoˇzinu prvk˚ u rdf:Bag, rdf:Seq a rdf:Alt. Jejich zam´ yˇslené uˇzit´ı je pro neseˇrazené mnoˇziny, mnoˇziny seˇrazené dle urˇcité vlastnosti, resp. mnoˇziny z nichˇz má b´ yt vybrána a pouˇzita jedna alternativa. Dále jsou definovány vlastnosti rdf:Statement, rdf:subject, rdf:predicate a rdf:object. Ty slouˇz´ı k popisu vlastnost´ı RDF trojice. To lze vyuˇz´ıt, jak bylo jiˇz uvedeno v souvislosti s blank node v kapitole 1.1.1, napˇr´ıklad k zapsán´ı ˇcasu, kdy byla trojice vytvoˇrena nebo kdo je jej´ım autorem. RDF schema definuje také nˇekolik vlastnost´ı k podpoˇre konceptu linked data. Vlastnost rdfs:seeAlso slouˇz´ı k odkazu na zdroj, kter´ y m˚ uˇze poskytnou dalˇs´ı souvisej´ıc´ı informace. Vlastnost´ı rdfs:isDefinedBy lze odkázat na definici zdroje, napˇr´ıklad RDF slovn´ık. 7

RDF a ontologie

1.2.2


Web Ontology Language

Web Ontology Language (OWL), tedy jazyk pro tvorbu webov´ ych ontologi´ı, rozˇsiˇruje moˇznosti jak zapisovat znalosti o vztaz´ıch mezi zdroji. OWL um´ı popisovat tˇr´ıdy, vlastnosti a jedince (individual), coˇz jsou instance tˇr´ıdy definované na u ´rovni ontologie. Základn´ı syntax´ı pro OWL ontologii je RDF/XML. Ontologii vycház´ı z RDF konceptu a lze zobrazit jako graf. Jazyk je v souˇcasnosti ve verzi 2 (z 11. prosince 2012). Jednotlivé moˇznosti, které OWL nab´ız´ı, jsou popsané ve W3C specifikaci [7]. Pro ukázku uvedu pouˇzit´ı ontologie pro ˇreˇsen´ı problému s harmonizac´ı RDF model˚ u z kapitoly 1.2. ˇ ast ontologie definuj´ıc´ı obor hodnot vlastnost´ı popisuj´ıc´ı Ontologie 1.5: C´ hlavn´ı postavy. Uvaˇzujme definici tˇr´ıd jako v ontologii 1.5. Ta ˇr´ıká pomoc´ı vlastnosti rdfs:range, ˇze objektem v trojici s predikáty hero, heroine a hlavniPostava jsou instance tˇr´ıdy Hero, Heroine, resp. HlavniPostava. Syntaxe umoˇzn ˇuje zkrátit IRI zdroj˚ u pouˇzit´ım prefixu, kter´ y je v RDF/XML uvozeny znakem & a ukonˇceny stˇredn´ıkem. Nyn´ı deklarujme, ˇze tˇr´ıda HlavniPostava je ekvivalentn´ı se sjednocen´ım mnoˇzin tˇr´ıd Hero a Heroine. Zápis této deklarace je v ontologii 1.6. 8

RDF a ontologie


ˇ ast ontologie definuj´ıc´ı ekvivalentn´ı vztah mezi tˇr´ıdou HlavOntologie 1.6: C´ niPostava a slouˇcen´ım tˇr´ıd Hero a Heroine. D˚ usledkem zapsán´ı takové znalosti do ontologie je, ˇze stroj s patˇriˇcnou softwarovou v´ ybavou dokáˇze pochopit spojitost mezi dan´ ymi pojmy a na jej´ım základˇe je schopen vyvodit znalosti, které nejsou explicitnˇe v RDF modelu uvedené. Ukázkou takové znalosti je fakt, ˇze zdroj romeo, kter´ y vystupuje jako objekt vlastnosti hero, je instanc´ı tˇr´ıd Hero a HlavniPostava. Tato informace vˇsak v trojic´ıch ve v´ ypisu 1.4 nen´ı zm´ınˇena, nebot’ nen´ı potˇreba z d˚ uvodu uˇzit´ı ontologie. Software, kter´ y umoˇzn ˇuje sémantiku informac´ı ˇc´ıst a vyvozovat znalosti, se oznaˇcuje pojmem sémantick´ y reasoner, nebo pouze reasoner. Jeho uˇziteˇcnost stoupá s komplexitou popisovan´ ych skuteˇcnost´ı. Kromˇe hledán´ı implicitn´ıch znalost´ı je moˇzné pouˇz´ıt reasoner k ovˇeˇren´ı konzistence dat. Reasoner je nicménˇe limitován t´ım, ˇze OWL funguje na pˇredpokladu otevˇreného svˇeta (open world assumption). Ten ˇr´ıká, ˇze tvrzen´ı je nepravdivé, jen pokud je ˇreˇceno, ˇze je nepravdivé. Naopak v pˇr´ıpadˇe uzavˇreného svˇeta je nepravdivé kaˇzdé tvrzen´ı, které nen´ı ˇreˇcené jako pravdivé [9]. Definujme, ˇze vlastnost hero má kardinalitu jedna, tzn. ˇze kaˇzd´ y zdroj m˚ uˇze b´ yt spojen danou vlastnost´ı pouze s jedn´ım objektem. Pak na v´ ypisu 1.7 neshledá reasoner nic ˇspatného, protoˇze ji interpretuje následuj´ıc´ı logikou. Romeo je hlavn´ı postavou hry. Julie je hlavn´ı postava stejné hry. Hra m˚ uˇze m´ıt nejv´ yˇse jednu hlavn´ı postavu. Julie je tedy stejn´ y objekt jako Romeo, pouze s jin´ ym IRI. Aby reasoner shledal v tomto pˇr´ıpadˇe data nekonzistentn´ı musela by v modelu b´ yt explicitnˇe formulována nˇejaká negativn´ı tvrzen´ı, nejjednoduˇseji napˇr´ıklad taková, kter´ ymi budou objekty juliet a romeo prohláˇseny za odliˇsné. V realitˇe je vˇsak takov´ y pˇr´ıstup nepouˇziteln´ y, protoˇze by bylo potˇreba k u ´plné definici formulovat tvrzen´ı pro kaˇzdou dvojici r˚ uzn´ ych ´ objekt˚ u. Uspornˇ ejˇs´ı by bylo definovat negativn´ı vztahy na u ´rovni ontologické definice tˇr´ıd a v datech pouze explicitnˇe pˇriˇradit objekt urˇcitému typu. V tomto pˇr´ıpadˇe tedy formulovat, ˇze romeo je instance tˇr´ıdy Hero, juliet je instance Heroine a v ontologii definovat, ˇze tˇr´ıda Hero nemá pr˚ unik s tˇr´ıdou Heroine.

9

RDF a ontologie


@prefix play: . @prefix terms: . @prefix char: . play:romeo-and-juliet terms:hero char:romeo . play:romeo-and-juliet terms:hero char:juliet . V´ ypis 1.7: Trojice popisuj´ıc´ı hlavn´ı postavy hry Romeo a Julie. Julie je deklarovaná vlastnost´ı hero nam´ısto heroine. V praxi je uˇziteˇcné v ontologi´ıch konstatovat vedle pozitivn´ı vlastnosti i negativn´ı, je-li to moˇzné. Pokud je u vlastnost´ı ve slovn´ıku definován jejich obor hodnot, m˚ uˇze reasoner odhalit nesoulad typ˚ u literál˚ u v datech a definice.

10

2 Obrazové soubory a metadata Obrazové (grafické) soubory mohou b´ yt velmi bohaté na metadata. Soubory, které byly vytvoˇrené v grafickém programu, maj´ı omezenou mnoˇzinu metadat popisuj´ıc´ı základn´ı vlastnosti jako ˇs´ıˇrku a v´ yˇsku obrazu nebo barevnou hloubku, pˇr´ıpadnˇe popisuj´ıc´ı program, kter´ ym byly vytvoˇreny. Na druhou stranu fotografie poˇr´ızené digitáln´ım fotoaparátem obsahuj´ı nav´ıc ˇradu u ´daj˚ u o okoln´ıch podm´ınkách pˇri focen´ı a nastaven´ı fotoaparátu. Existuje ˇrada r˚ uzn´ ych grafick´ ych formát˚ u. Základn´ı dˇelen´ı je na formáty rastrové a vektorové. Vektorové formáty ukládaj´ı matematick´ ym zápisem pozici a tvar jednotliv´ ych ˇcar, které jsou pouˇzity k vykreslen´ı komplexn´ıch tvar˚ u. Rastrové maj´ı strukturu mˇr´ıˇzky pixel˚ u. Pro kaˇzd´ y pixel je uloˇzena hodnota barevn´ ych sloˇzek, z kter´ ych je tvoˇrena barva konkrétn´ıho pixelu. Vektorové je moˇzné d´ıky zp˚ usobu jejich serializace snadno ˇskálovat do potˇrebné velikosti bez ztráty kvality. U rastrov´ ych obraz˚ u docház´ı k redukci informace pˇri zmenˇsen´ı velikosti nebo k pˇridáván´ı nov´ ych dat pˇri zvˇetˇsován´ı. V závislosti na pouˇzité interpolaˇcn´ı metodˇe, obsahu sn´ımku ˇci pomˇeru zmˇeny velikosti dojde k r˚ uzn´ ym kvalitativn´ım zmˇenám. Zmˇenˇen´ y obraz se m˚ uˇze jevit rozmazanˇe, objekty mohou b´ yt nevyhlazené nebo se objev´ı ˇsum u hran pˇrechod˚ u mezi barvami. [10, 11] Metoda ukládán´ı barevné konfigurace kaˇzdého pixelu je velmi nároˇcná na u ´loˇzn´ y prostor. Uvaˇzujeme-li barevn´ y prostor RGB, tedy tˇri sloˇzky s hodnotami 0 aˇz 255, pak zápis jednoho pixelu vyˇzaduje 3 byty. Jeden sn´ımek z fotoaparátu s rozliˇsen´ım 10 Mpx by tak mˇel velikost pˇribliˇznˇe 30 MB. Z tohoto d˚ uvodu se pˇristupuje u vˇetˇsiny formát˚ u k nˇejakému druhu komprese. Kompresn´ı metoda m˚ uˇze b´ yt ztrátová (lossy) nebo bezztrátová (lossless). Bezztrátovou kompres´ı se nepˇricház´ı o ˇzádnou obrazovou informaci. Hledá se nejefektivnˇejˇs´ı zp˚ usob, jak uchovat kvalitu a zmenˇsit velikost. Toho m˚ uˇze b´ yt doc´ıleno napˇr´ıklad identifikován´ım opakuj´ıc´ıho se vzoru v datech a jeho substituován´ı zkratkou o menˇs´ı velikosti. Naopak ztrátová komprese pˇripouˇst´ı degradaci kvality dat. Taková komprese m˚ uˇze ukládat obrazovou informaci s menˇs´ım rozliˇsen´ım a pro vykreslen´ı p˚ uvodn´ıho obrazu pouˇz´ıvat statistické odhady hodnot.[12] V práci se dále zab´ yvám pouze rastrov´ ymi formáty, které obsahuj´ı oproti vektorov´ ym vˇetˇs´ı mnoˇzstv´ı metadat ke zpracován´ı. Konkrétnˇe uvaˇzuji formáty JPEG, PNG a TIFF. 11

Obrazové soubory a metadata

2.1

JPEG

JPEG

JPEG je p˚ uvodem mezinárodn´ı standard ISO/IEC 10918 [13] komprese dat v statick´ ych obrazech. Název vycház´ı ze zkratky skupiny Joint Photographic Experts Group, jenˇz ho vytvoˇrila. V standardu byly definovány dvˇe metody komprese – ztrátová, zaloˇzená na diskrétn´ı kosinové transformaci, a bezztrátová vyuˇz´ıvaj´ıc´ı predikˇcn´ı pˇr´ıstup. [14] Skupina vytvoˇrila ˇradu dalˇs´ıch standard˚ u pro specifické zp˚ usoby uˇzit´ı, jejichˇz dokumentaci je moˇzné naj´ıt na webov´ ych stránkách skupiny1 . Dále budu uvaˇzovat pouze v´ yˇse zm´ınˇen´ y standard. Zkratka JPEG se v souˇcasnosti ˇcasto pouˇz´ıvá i jako oznaˇcen´ı datového formátu, kter´ y vyuˇz´ıvá tyto kompresn´ı metody. Základn´ım formátem je JPEG Interchange Format (JIF) definovan´ y ve standardu [15] v pˇr´ıloze B. Dalˇs´ı ˇ formáty vˇzdy JIF rozˇsiˇruj´ı a jsou s n´ım zpˇetnˇe kompatibiln´ı. Casto pouˇz´ıvané formáty jsou JPEG/JFIF pro obrazová data na webu a JPEG/Exif pro fotografie z digitáln´ıch fotoaparát˚ u [16].

2.1.1

JPEG Interchange Format

JIF se skládá z nˇekolika segment˚ u zaˇc´ınaj´ıc´ıch dvou bytovou kódovou znaˇckou definovanou ve standardu [15], pˇr´ıloze B.1. Segmenty maj´ı definované pevné poˇrad´ı. Názvy znaˇcek dle specifikace uvád´ım v závorce. Struktura souboru je dle pˇr´ılohy B.2.1 [15] následuj´ıc´ı: zaˇca´tek obrazu (SOI), definice Huffmanov´ ych tabulek (DHT), definice kvantizaˇcn´ıch tabulek (DQT), definice restart intervalu (DRI), hlaviˇcka rámce, segmenty s komprimovan´ ymi daty, konec obrazu (EOI). V hlaviˇcce rámce je pouˇzita jedna z ˇsestnácti znaˇcek pro zaˇca´tek rámce (SOFx). Dle zvolené znaˇcky je definována pouˇzitá metoda komprese. Jednotlivé segmenty s daty se skládaj´ı ze zaˇcátku scanu (SOS) a dat následovan´ ymi restart kódem (RST). Specifikace dále vyhrazuje ˇsestnáct znaˇcek pro oznaˇcen´ı segment˚ u pro data jin´ ych aplikac´ı (APPx). Segmenty se zpravidla vyskytuj´ı hned za SOI segmentem a je moˇzné vloˇzit v´ıce r˚ uzn´ ych APP segment˚ u. V tˇechto segmentech se ukládaj´ı metadata jednotliv´ ych formát˚ u rozˇsiˇruj´ıc´ıch JIF. 1

http://www.jpeg.org/index.html

12


2.1.2

JPEG

JPEG File Interchange Format

Tento formát, pouˇz´ıvaj´ıc´ı zkratku JPEG/JFIF nebo pouze JFIF, zvolil v roce 1996 Internet Engineering Task Force ve své publikaci jako kódován´ı JPEG soubor˚ u pro internetovou datovou komunikaci. V dokumentu byl dále zaveden pojem Multipurpose Internet Mail Extension (MIME), coˇz je rozˇs´ıˇren´ı p˚ uvodn´ıho emailového protokolu k umoˇznˇen´ı zas´ılán´ı jin´ ych typ˚ u dat neˇz ASCII text. MIME typ je textov´ y hierarchick´ y identifikátor typu obsahu s dvˇema stupni hierarchie. Koncept MIME typ˚ u se pozdˇeji rozˇs´ıˇril a pracuj´ı s n´ım i dalˇs´ı aplikace. Formátu JFIF byl pˇriˇrazen MIME typ image/jpeg. [17] JFIF pouˇz´ıvá APP0 segment, kter´ y mus´ı b´ yt hned za segmentem zaˇcátku obrazu. Specifikace silnˇe doporuˇcuje pouˇz´ıvat JPEG baseline jako zp˚ usob komprese obrazov´ ych dat, kv˚ uli zachován´ı maximáln´ı kompatibility se vˇsemi aplikacemi pouˇz´ıvaj´ıc´ı JPEG. Na rozd´ıl od JIF je definován barevn´ y prostor obrazu. M˚ uˇze b´ yt ve stupn´ıch ˇsedi (Y) nebo s tˇremi barevn´ ymi sloˇzkami (Y, Cb, Cr). Formát dále uchovává informaci o rozliˇsen´ı a umoˇzn ˇuje uloˇzit v segmentu APP0 zmenˇseninu p˚ uvodn´ıho obrazu jako náhled. [18]

2.1.3

Exchangeable Image File Format

Exif je metadatov´ y formát, prvnˇe publikovan´ y v roce 1998, momentálnˇe ve verzi 2.3. Je definován pro obrazová data v JPEG a TIFF Baseline formátu. Exif m˚ uˇze b´ yt pouˇzit i k popisu zvukov´ ych soubor˚ u formátu RIFF WAVE Form. V pˇr´ıpadˇe JPEG formátu vyuˇz´ıvá k zápisu sv´ ych dat segmenty APP1 a APP2. Segment APP1 mus´ı b´ yt hned za SOI. [19] T´ımto poˇzadavkem se Exif stává nekompatibiln´ı s JFIF, protoˇze oba vyˇzaduj´ı um´ıstit sv˚ uj blok na zaˇcátek. V nˇekter´ ych souborech se i pˇresto nacház´ı oba segmenty a je na aplikaci, zda-li a jak si s danou situac´ı porad´ı. Metadata jsou roztˇr´ıdˇena do nˇekolika adresáˇr˚ u (image file directories, IFD). Jednotlivé vlastnosti v adresáˇr´ıch se oznaˇcuj´ı jako tagy. Exif IFD obsahuje u ´daje o dobˇe poˇr´ızen´ı sn´ımku, pouˇzitém objektivu, vlastnostech dat jako pouˇzit´ y barevn´ y prostor a gamma. Dále jsou zde informace o nastaven´ı fotoaparátu bˇehem poˇrizován´ı sn´ımku. Je zde také prostor k zapsán´ı Makernote. Makernote, v ˇceˇstinˇe tedy nˇeco jako poznámka od v´ yrobce, je tag urˇcen´ y pro v´ yrobce zaˇr´ızen´ı k zapsán´ı libovolné informace. Obsah je plnˇe na uvá13


JPEG

ˇzen´ı v´ yrobce. [19] V´ yrobci vˇetˇsinou pouˇz´ıvaj´ı vlastn´ı proprietárn´ı formát ke kterému nezveˇrejˇ nuj´ı technickou dokumentaci. Nˇekteré formáty se podaˇrilo ˇcásteˇcnˇe popsat pomoc´ı reverzn´ıho inˇzen´ yrstv´ı. [20] Dalˇs´ım adresáˇrem je GPS IFD, kter´ y obsahuje data o m´ıstˇe, kde byl sn´ımek poˇr´ızen. P˚ uvodnˇe bylo zam´ yˇsleno data z´ıskávat v´ yhradnˇe z GPS pˇrij´ımaˇce zabudovaném v zaˇr´ızen´ı, nicménˇe verze 2.3 specifikace jiˇz pˇripouˇst´ı i z´ıskán´ı lokaˇcn´ı informace z mobiln´ıch telefon˚ u nebo pomoc´ı u ´daj˚ u z bl´ızké bezdrátové lokáln´ı s´ıtˇe (WLAN).[19] Jelikoˇz je na trhu ˇrada v´ yrobc˚ u digitáln´ıch fotoaparát˚ u, je snaha zajistit interoperabilitu mezi zaˇr´ızen´ımi r˚ uzn´ ych v´ yrobc˚ u. Soubor poˇr´ızen´ y na libovolném zaˇr´ızen´ı by mˇel b´ yt zobraziteln´ y i na zaˇr´ızen´ıch jin´ ych v´ yrobc˚ u. Vzniklo nˇekolik doporuˇcen´ı, jejichˇz dodrˇzen´ım by mˇela b´ yt interoperabilita zaruˇcena. Adresáˇr Interoperability IFD slouˇz´ı k urˇcen´ı, jaké sadˇe doporuˇcen´ı obrazov´ y soubor vyhovuje.

2.1.4

Extensible Metadata Platform

Extensible metadata platform (XMP) je standardem ISO 16684-1:2012 pro vytváˇren´ı, zpracován´ı a pˇredáván´ı metadat u digitáln´ıch dokument˚ u. XMP byla vytvoˇreno spoleˇcnost´ı Adobe Systems Inc. U JPEG formátu jsou data uloˇzena v APP1 segmentu, stejnˇe jako data Exifu, ale segment m˚ uˇze b´ yt um´ıstˇen na libovolném m´ıstˇe pˇred SOF. [21] Segmenty jsou od sebe rozliˇsitelné podle své signatury, která následuje za kódem APP1. XMP je tedy kompatibiln´ı s Exif i JFIF. Ve specifikaci [22] je popsán datov´ y model, kter´ y se shoduje s RDF modelem. Dokumenty [22, 23] definuj´ı RDF slovn´ıky t´ ykaj´ıc´ı se multimediáln´ıch ˇ adná zdroj˚ u. Ve slovn´ıku jsou definovány pouze poˇzadované datové typy. Z´ ontologie nad slovn´ıkem nen´ı zveˇrejnˇena. Ze své podstaty m˚ uˇze b´ yt mnoˇzina metadat zapisovateln´ ych do XMP neomezenˇe rozˇsiˇrována definován´ım a pouˇzit´ım dalˇs´ıch RDF slovn´ık˚ u. V praxi je ale uˇzivatel limitován aplikac´ı, jenˇz je pouˇzita ke ˇcten´ı a zápisu informace, která nemus´ı extern´ı slovn´ıky podporovat. Pro zachován´ı maximáln´ı interoperability je proto vhodné vyuˇz´ıvat slovn´ık definovan´ y v XMP specifikaci.

14


2.1.5

JPEG

Information Interchange Model

International Press Telecommunications Council (IPTC)2 je organizace zaloˇzená v Lond´ ynˇe roku 1965, která sdruˇzuje svˇetové zpravodajské organizace. Byla vytvoˇrena za u ´ˇcelem zjednoduˇsen´ı pˇredáván´ı informac´ı a ustanoven´ı technick´ ych standard˚ u zefektivˇ nuj´ıc´ım v´ ymˇenu informace. V jednom ze standard˚ u se zab´ yvá i metadaty v obrazov´ ych souborech. Jde o standard Information Interchange Model (IIM), momentálnˇe ve verzi 4.2 [24]. Ve standardu jsou definována metadata popisuj´ıc´ı obrazov´ y soubor ve smyslu jeho zapouzdˇren´ı pˇri pos´ılán´ı, do kter´ ych se zapisuje napˇr´ıklad datum zaslán´ı souboru, pouˇzité kódován´ı, adresát nebo formát souboru. V druhé ˇcásti jsou definována metadata popisuj´ıc´ı obsah daného souboru. Zde jsou informace o datu a ˇcasu poˇr´ızen´ı, autorsk´ ych právech, název, popisek obrazu a dalˇs´ı. Je zde i prostor pro zapsán´ı textové informace o státu, mˇestu a objektu, kter´ y je na fotografii zobrazen. Poloˇzky kategorizuj´ıc´ı kontext obrazové informace jsou vymezeny kontrolovan´ ym slovn´ıkem. To znamená, ˇze do daného pole se nevypisuje hodnota textovˇe (napˇr. Politika“), ale kódem ” ˇ ıseln´ z pevnˇe definovaného ˇc´ıseln´ıku hodnot (11000000). C´ ıky jsou definované v pˇr´ıloze specifikace. Metadata jsou v JPEG souboru um´ıstˇena do segmentu APP13. Segment m˚ uˇze b´ yt um´ıstˇen na libovolném m´ıstˇe pˇred SOF dle kapitoly 1.1.3 dokumentu [21]. Nen´ı známo, ˇze by IIM byl nekompatibiln´ı s jin´ ymi metadatov´ ymi formáty vkládan´ ymi do JPEG souboru. V d˚ usledku rozˇs´ıˇren´ı XMP byl vydán organizac´ı IPTC nov´ y standard, kter´ y popisuje zp˚ usob zápisu IIM metadat do XMP bloku. [25] V souˇcasné dobˇe je standard aktuáln´ı pro verzi 4.1 IIM, nikoliv tedy pro nejnovˇejˇs´ı 4.2. Standard popisuje mapován´ı nˇekter´ ych metadatov´ ych vlastnost´ı na jiˇz existuj´ıc´ı vlastnosti v XMP slovn´ıku. Pro zbylé pojmy je vytvoˇren nov´ y slovn´ık. Ve slovn´ıc´ıch je definován datov´ y typ hodnot vlastnost´ı a kardinalita vlastnost´ı.

2.1.6

Photoshop Image Resources

Adobe Photoshop, program k u ´pravˇe a vytváˇren´ı grafiky od spoleˇcnosti Adobe Systems Inc., vyuˇz´ıvá ˇradu funkc´ı, jejichˇz parametry nelze zapsat do 2

Domovsk´ a str´ anka IPTC: https://iptc.org

15


JPEG

bˇeˇzn´ ych rastrov´ ych obrazov´ ych soubor˚ u jako JPEG, PNG nebo TIFF. Jde napˇr´ıklad o moˇznost rozloˇzit obraz do nˇekolika vrstev, které se navzájem pˇrekr´ yvaj´ı, a v´ ysledn´ y obraz je funkc´ı jejich sjednocen´ı. Pˇri uloˇzen´ı do bˇeˇzného souboru by se uloˇzil pouze v´ ysledn´ y obraz a s jednotliv´ ymi vrstvami by nebylo moˇzné jiˇz pracovat. Proto spoleˇcnost vytvoˇrila vlastn´ı formát Photoshop Document, do kterého je program schopen zapsat vˇse potˇrebné. Metadata v tomto formátu jsou uchovávána jako Photoshop Image Resources (PSIR). PSIR je moˇzné pouˇz´ıt i v jin´ ych souborech. V JPEG souboru se nalézá v segmentu APP13 a slouˇz´ı jako kontejner obsahuj´ıc´ı i jiná metadata jako napˇr´ıklad v´ yˇse zm´ınˇen´ y IIM [26]. Specifikace PSIR [27] uvád´ı seznam definovan´ ych tag˚ u.

2.1.7

ICC profil

V roce 1993 bylo zaloˇzeno International Color Consortium (ICC)3 , které mˇelo vytvoˇrit otevˇren´ y a multiplatformn´ı systém pro správu barevné konfigurace nezávisl´ y na v´ yrobci zaˇr´ızen´ı. V´ ysledkem byla specifikace ICC profilu [28]. Specifikace se stala mezinárodn´ım standardem ISO 15076-1:2010. ICC profil se pouˇz´ıvá k transformaci obrazu poˇr´ızeného na zaˇr´ızen´ı s urˇcitou barevnou konfigurac´ı pro zaˇr´ızen´ı pouˇz´ıvaj´ıc´ı jinou konfiguraci tak, aby pozorované barvy na sn´ımku z˚ ustaly zachovány. Profil b´ yvá vkládan´ y do obrazov´ ych soubor˚ u. V pˇr´ıpadˇe JPEG se vkládá do segmentu APP2. Specifikace JPEG ˇr´ıká, ˇze kaˇzd´ y segment mus´ı m´ıt vyjádˇrenou bytovou délku pomoc´ı 16 bitového integeru. Do délky se zapoˇc´ıtává i samotné vyjádˇren´ı délky. Z toho plyne, ˇze velikost dat segmentu m˚ uˇze b´ yt nejv´ yˇse 65 533 byt˚ u. Jelikoˇz data profilu mohou b´ yt vˇetˇs´ı, byl zaveden zp˚ usob jak data rozdˇelit na nˇekolik ˇcást´ı. Kaˇzdá ˇcást bude m´ıt indikaci poˇrad´ı a celkového poˇctu ˇca´st´ı a kaˇzdá bude zapsána do jiného APP2 segmentu. Z definice plyne maximáln´ı velikost zapisovaného ICC profilu jako 16 707 345 byt˚ u. [28] 3

Domovsk´ a str´ anka ICC: http://www.color.org

16


2.2

PNG

PNG

Portable Network Graphics (PNG)4 je grafick´ y formát pouˇz´ıvaj´ıc´ı bezztrátovou kompresi. Formát umoˇzn ˇuje zapsat data obraz˚ u v odst´ınech ˇsedi, indexov´ ych barvách nebo True Color (24 bitová barevná hloubka s ˇcerven´ ym, zelen´ ym a modr´ ym kanálem). U kaˇzdé varianty je moˇznost nastaven´ı pr˚ uhlednosti. PNG byl vytvoˇren jako náhrada za formát GIF, u kterého doˇslo k patentovému sporu u kompresn´ı metody. Jedná se o mezinárodn´ı standard ISO/IEC 15948:2003. MIME typ souboru je image/png. [29] Dokument specifikace [29] v u ´vodu vyjmenovává nˇekolik bod˚ u jako hlavn´ı c´ıle pˇri vytváˇren´ı standardu. Poˇzadavek byl kladen na nezávislost procesu kódován´ı, dekódován´ı a pˇrenosu na platformˇe nebo stroji. Cel´ y formát mˇel b´ yt jednoduch´ y, aby v´ yvojáˇri nemˇeli problém standard implementovat, a dostateˇcnˇe flexibiln´ı, aby pˇr´ıpadné zmˇeny a rozˇs´ıˇren´ı byly kompatibiln´ı s dekodéry p˚ uvodn´ı verze. Byla preferována rychlost vykonán´ı proces˚ u pˇri dekódován´ı a prezentaci na u ´kor rychlosti zakódován´ı dat. D˚ uleˇzitou podm´ınkou bylo pouˇz´ıván´ı pouze volnˇe dostupn´ ych algoritm˚ u, aby nedoˇslo k dalˇs´ımu patentovému sporu. V´ yvojové c´ıle byly naplnˇeny a libovoln´ y PNG dekodér vyhovuj´ıc´ı standardu je schopen dekódovat libovoln´ y PNG soubor. Soubor je moˇzné kódovat a dekódovat sériovˇe, tedy bez znalosti kompletn´ıch dat, aby obrazová data z datového toku bylo moˇzno pr˚ ubˇeˇznˇe zobrazovat. Prezentace obrazu je progresivn´ı. To znamená, ˇze se pˇri zpracován´ı nejprve zobraz´ı hrubá aproximace obrazu a s dalˇs´ımi pˇricházej´ıc´ımi daty se obraz zkvalitˇ nuje. Pˇri pˇrenosu jsou chyby detekovatelné pomoc´ı kontroln´ıho souˇctu na konci kaˇzdé ˇca´sti.

2.2.1

Struktura souboru

Soubor se dle specifikace [29] skládá ze signatury a posloupnosti nˇekolika chunk˚ u. Chunk je ˇca´st informace o obrazu, kter´ y má definovanou svoji délku, typ, m˚ uˇze obsahovat datovou ˇca´st a jej´ı kontroln´ı souˇcet. Datová ˇcást je nepovinná, protoˇze nˇekteré chunky mohou svoji funkci plnit bez ni. Napˇr´ıklad jde o IEND uˇz´ıvan´ y k oznaˇcen´ı konce souboru. Velikost datové ˇca´sti m˚ uˇze b´ yt nejv´ yˇse 231 − 1 byt˚ u. 4

Domovsk´ a str´ anka PNG: http://www.libpng.org/pub/png/

17


PNG

Název chunku se skládá ze ˇctyˇr p´ısmen, jejichˇz velikost urˇcuje vlastnosti daného chunku. Velikost prvn´ıho p´ısmena udává, jestli se jedná o chunk kritick´ y, nebo pomocn´ y (ancillary). Kritické chunky maj´ı velké p´ısmeno a mus´ı je rozeznat a správnˇe interpretovat kaˇzd´ y dekodér. Pomocné dekodér nemus´ı dekódovat. Velikost druhého p´ısmena udává, ˇze se jedná o standardizovan´ y chunk, pokud je velké, nebo soukrom´ y chunk, pokud je malé. Tˇret´ı p´ısmeno ˇ je vˇzdy velké. Ctvrt´ e malé p´ısmeno znaˇc´ı, ˇze editor m˚ uˇze bezpeˇcnˇe chunk zkop´ırovat, i kdyˇz ho nedokázal rozpoznat. [29] ˇ ri z nich jsou oznaˇcené Standard [29] definuje ˇsestnáct typ˚ u chunk˚ u. Ctyˇ jako kritické. Jedná se o IHDR obsahuj´ıc´ı hlaviˇcku souboru, PLTE s definic´ı palety pro indexové barvy, IDAT obsahuj´ıc´ı data obrazu a IEND. Zbyl´ ych ˇctrnáct chunk˚ u je pomocn´ ych. Obsahuj´ı informaci o pr˚ uhlednosti, nastaven´ı barevného prostoru, ˇcasu poˇr´ızen´ı, barvˇe pozad´ı a rozliˇsen´ı obrazu. V pomocn´ ych chunc´ıch je také nˇekolik textov´ ych, do kter´ ych lze zapisovat dvojice kl´ıˇc-hodnota.

2.2.2

Dalˇ s´ı metadata

Do chunk˚ u lze vloˇzit i metadata nˇekter´ ych dˇr´ıve zm´ınˇen´ ych formát˚ u. Specifikace XMP [21] pˇripouˇst´ı zápis do PNG chunku iTXt. Tento chunk se ˇrad´ı mezi textové a je pro nˇej definováno kódován´ı UTF-8. Specifikace umoˇzn ˇuje existenci pouze jednoho chunku s XMP informac´ı v souboru a doporuˇcuje ho umist’ovat na zaˇca´tek. Podobnˇe lze zapsat i IIM metadata, pokud jsou pˇrevedeny do XMP modelu [25]. IIM jako takové vˇsak nen´ı ve formátu PNG podporováno a nelze jej jinak neˇz pˇrevodem zapsat. ICC profil lze v PNG zapsat do iCCP chunku. V pˇr´ıpadˇe, ˇze enkodér zapisuje profil do souboru, doporuˇcuje se zapsat do chunk˚ u gAMA a cHRM data z´ıskaná aproximac´ı patˇriˇcn´ ych dat ICC profilu. T´ım se zajist´ı kompatibilita s aplikacemi, které iCCP pomocn´ y chunk nedokáˇz´ı interpretovat. Z tohoto plyne doporuˇcen´ı pro v´ yvojáˇre dekodér˚ u, aby v pˇr´ıpadˇe nalezen´ı a zpracován´ı chunku iCCP ignorovali chunky gAMA a cHRM. [29] V rámci projektu [30] byla snaha konvertovat Exif metadata do PNG. Bylo navrˇzeno mapován´ı nˇekter´ ych Exif tag˚ u na existuj´ıc´ı tagy v PNG a pro zbylé byl navrˇzen nov´ y chunk. Projekt ale z˚ ustal ve stádiu návrhu. Pro Photoshop Image Resource metadata jsem nenalezl ˇza´dn´ y zp˚ usob vloˇzen´ı do PNG souboru. 18


2.3

TIFF

TIFF

Tagged Image File Format je souborov´ y formát k uchován´ı rastrové grafiky. Ukládat lze nekomprimovaná i komprimovaná data, ztrátovˇe i bezztrátovˇe. P˚ uvodn´ı verze byla vytvoˇrena v roce 1986 spoleˇcnost´ı Aldus. Souˇcasná verze 6.0 vyˇsla v roce 1992. Spoleˇcnost se pozdˇeji slouˇcila s Adobe Systems Inc., která ted’ formát vlastn´ı. Specifikace stanovuje základn´ı verzi, TIFF Baseline, kterou mus´ı vˇsechny dekodéry umˇet zpracovat. [31] Tato verze má MIME typ image/tiff. Baseline TIFF umoˇzn ˇuje m´ıt v souboru v´ıce obraz˚ u, kaˇzd´ y ve vlastn´ım adresáˇri (IFD). Dekodéry nicménˇe nejsou povinny zpracovávat jiné obrazy neˇz obraz z prvn´ıho adresáˇre. Obraz je dˇelen´ y na pruhy (strips). V hlaviˇcce je kromˇe v´ yˇsky souboru definován i poˇcet ˇra´dek v jednom pruhu. Pruhy jsou komprimovány jednotlivˇe, pokud je potˇreba data komprimovat. Baseline nab´ız´ı dvˇe varianty bezztrátové komprese, pˇr´ıpadnˇe moˇznost ukládat nekomprimovan´ y obraz. Barevn´ y prostor Baseline TIFF m˚ uˇze b´ yt dvojbarevn´ y, v odst´ınech ˇsedi, indexov´ ych barvách a True Color. [31] Specifikace [31] definuje dále rozˇs´ıˇrenou verzi formátu, kterou schválilo TIFF Advisory Committee. V´ yrobce dekodér˚ u nemá povinnost brát na rozˇs´ıˇren´ı ohled a nen´ı tedy zaruˇceno, ˇze budou podporována na vˇsech zaˇr´ızen´ıch. Autor˚ um rozˇs´ıˇren´ı je doporuˇcováno, aby u ´zce spolupracovali s v´ yrobci dekodér˚ u a zajistili tak interoperabilitu. Rozˇs´ıˇren´ı mimo jiné zavád´ı moˇznost komprimace pomoc´ı JPEG nebo LZW, kter´ y byl pouˇzit ve formátu GIF a stal se pˇredmˇetem patentového sporu. Je definována moˇznost rozdˇelit obraz na nˇekolik stejnˇe velk´ ych ˇcást´ı a kaˇzdou z nich komprimovat samostatnˇe. Je uvedeno, ˇze komprese b´ yvá u ´ˇcinnˇejˇs´ı nad ˇca´stmi s podobnou v´ yˇskou a délkou sp´ıˇse neˇz nad dlouh´ ymi obdéln´ıky, které vznikaj´ı u obraz˚ u s vysok´ ym rozliˇsen´ım pˇri rozdˇelován´ı na pruhy. [31] D´ıky rozˇs´ıˇren´ı je moˇzné ukládat obrazy s CMYK a YCbCr barevn´ ymi prostory.

2.3.1

Struktura souboru

Struktura TIFF souboru je popsána v kapitole 2 dokumentace [31]. V hlaviˇcce souboru je ofsetov´ y odkaz na nult´ y adresáˇr. Na zaˇca´tku kaˇzdého adresáˇre je poˇcet poloˇzek adresáˇre. Za n´ım následuje dan´ y poˇcet poloˇzek, kaˇzdá 19


TIFF

o velikosti 12 byt˚ u. Kaˇzdá poloˇzka se skládá z tagu identifikuj´ıc´ıho v´ yznam poloˇzky, tagu datového typu hodnoty, poˇctu hodnot a ofsetového odkazu na hodnotu. Pokud se hodnota vejde do 4 byt˚ u, je moˇzné m´ısto offsetu vloˇzit do poloˇzky pˇr´ımo hodnotu. Kaˇzd´ y soubor mus´ı m´ıt alespoˇ n jeden adresáˇr. Na konci kaˇzdého adresáˇre mus´ı b´ yt odkaz na dalˇs´ı adresáˇr. Posledn´ı adresáˇr v ˇretˇezci mus´ı m´ıt v odkazu na dalˇs´ı adresáˇr nulu.

2.3.2

Dalˇ s´ı metadata

Jak bylo zm´ınˇeno v kapitole 2.1.3, Exif je pro nekomprimované grafické soubory definovan´ y nad TIFF Baseline. Struktura souboru s Exif metadaty je popsána v kapitole 4.5.2 dokumentu [19]. Metadata jsou um´ıstˇena jako prvn´ı adresáˇr. TIFF má definováno nˇekolik tag˚ u pro odkazován´ı na bloky metadat jin´ ych formát˚ u. Pro XMP je vyuˇz´ıván tag 700, pro IIM 33723 a pro PSIR 34377, dle [21], kapitola 2.1.6. Tato metadata mohou b´ yt snadno vloˇzena do TIFF. ICC profil je moˇzné vloˇzit pomoc´ı tagu 34675. Tag by mˇel b´ yt v adresáˇri, ve kterém je i odkaz na obrazová data, na které má b´ yt profil aplikován. Jelikoˇz m˚ uˇze b´ yt v TIFF v´ıce obraz˚ u, je moˇzné definovat i v´ıce profil˚ u v souboru. V adresáˇri ale nesm´ı b´ yt v´ıce neˇz jeden odkaz na ICC profil. [28]

20

3 Existuj´ıc´ı nástroje V této kapitole popisuji nástroje, které se sv´ ym charakterem t´ ykaj´ı moj´ı práce a které bych mohl vyuˇz´ıt k dosaˇzen´ı c´ıle. Jde v prvé ˇradˇe o aplikace a knihovny pracuj´ıc´ı s obrazov´ ymi soubory, které um´ı ˇc´ıst jejich metadata. Dále jde o RDF slovn´ıky, které by mohly poskytovat nˇekteré pojmy uˇziteˇcné k uchován´ı informace z obrazov´ ych soubor˚ u.

3.1

N´ astroje pro extrakci metadat

´ celem této práce je naj´ıt metadata v obrazov´ Uˇ ych souborech a extrahovat je. Moˇznost zmˇeny a zápisu metadatové informace v souboru, pˇr´ıpadnˇe vykreslen´ı obrazu, je mimo rámec práce. Z toho d˚ uvodu se v této sekci zamˇeˇr´ım pˇredevˇs´ım na moˇznosti nástroje pˇri extrahován´ı metadat.

3.1.1

Exiv2

Exiv2 [32] je knihovna v jazyce C++ a konzolová aplikace pro ˇcten´ı a editaci metadat obrazov´ ych soubor˚ u. Knihovna je licencována jako GNU General 1 Public License 2.0 . Autor nab´ız´ı moˇznost po domluvˇe poskytnout knihovnu s jinou licenc´ı tak, aby ji ˇsla pouˇz´ıt v closed-source projektech. Posledn´ı stabiln´ı vydaná verze je Exiv2 v0.24 z 2. prosince 2013. Knihovna je aktivnˇe udrˇzována a v projektu2 je kaˇzd´ y den provedeno nˇekolik reviz´ı. Knihovna podporuje metadata formát˚ u Exif, IIM a XMP. V pˇr´ıpadˇe Exif a XMP metadat um´ı z´ıskané hodnoty pˇrevést na hodnoty pro ˇclovˇeka srozumitelné. Jde pˇredevˇs´ım o pˇrevod ˇc´ıseln´ıkov´ ych hodnot na jejich textové popisy, nebo pˇridán´ı informace o mˇern´ ych jednotkách, jak plynou z definice tagu. Na webov´ ych stránkách knihovny lze vidˇet seznam detekovan´ ych meta3 datov´ ych tag˚ u . Rozpoznané jsou i Exif Makernote 10 v´ yrobc˚ u fotoaparát˚ u. Knihovna pracuje s 26 XMP slovn´ıky. 1

http://www.gnu.org/licenses/old-licenses/gpl-2.0.html http://dev.exiv2.org/projects/exiv2/activity 3 http://www.exiv2.org/metadata.html 2

21

Existuj´ıc´ı nástroje

Nástroje pro extrakci metadat

Knihovna se nezab´ yvá metadaty JIF, JFIF, PNG a Photoshop Image Resource. Hodnoty ICC profilu lze z´ıskat pouze jako posloupnost byt˚ u dále nezpracovanou a nepopsanou.

3.1.2

ExifTool

ExifTool [33] je platformˇe nezávislá knihovna a konzolová aplikace pro ˇcten´ı a manipulaci s obrazov´ ymi metadaty. Podporuje ˇradu typ˚ u soubor˚ u vˇcetnˇe JPEG, PNG a TIFF. Knihovna je licencována jako GNU General Public License4 nebo Artistic License5 . Posledn´ı stabiln´ı verze knihovny je 9.90 z 14. bˇrezna 2015. Knihovna je aktivnˇe udrˇzována a kaˇzd´ y mˇes´ıc vycház´ı pr˚ umˇernˇe dvˇe nové v´ yvojové verze. Stabiln´ı verze vycházej´ı pr˚ umˇernˇe ˇctyˇri roˇcnˇe. Knihovna um´ı ˇc´ıst kromˇe JIF vˇsechny v této práci diskutované metadatové formáty. Pro formát XMP rozpozná 55 r˚ uzn´ ych slovn´ık˚ u. Exif Makernote jsou ˇctena pro 22 v´ yrobc˚ u zaˇr´ızen´ı.

3.1.3

Metadata Extractor

Metadata Extractor [34] je knihovna napsaná v jazyce Java slouˇz´ıc´ı ke ˇcten´ı metadat z obrazov´ ych soubor˚ u. Mezi podporovan´ ymi formáty jsou JPEG, PNG i TIFF. Produkt je licencovan´ y jako Apache License 2.06 . Verze 2.8.1 vydaná 20. dubna 2015 je posledn´ı stabiln´ı verz´ı. Projekt je aktivn´ı. Knihovna ˇcte vˇsechny metadatové formáty diskutované v kapitole 2. V pˇr´ıpadˇe XMP dokáˇze pˇreˇc´ıst hodnoty jen ze 4 slovn´ık˚ u. Dokáˇze dekódovat Exif Makernote od 15 v´ yrobc˚ u zaˇr´ızen´ı. Hodnoty tag˚ u lze pˇrevést do tvaru pochopitelného pro ˇclovˇeka s vyj´ımkou Makernote, kde pro pˇribliˇznˇe 20 % tag˚ u pˇrevod chyb´ı. 4

http://dev.perl.org/licenses/gpl1.html http://dev.perl.org/licenses/artistic.html 6 http://www.apache.org/licenses/LICENSE-2.0 5

22


3.1.4

Nástroje pro extrakci metadat

Aperture

Aperture [35] je Java framework pro extrahován´ı metadat z r˚ uzn´ ych zdroj˚ ua jejich zapisován´ı do RDF modelu. Jako ukázka moˇzn´ ych zdroj˚ u jsou uvádˇeny emailové schránky, webové stránky a souborové systémy. Kromˇe metadat je moˇzné extrahovat i text obsaˇzen´ y v datech, napˇr´ıklad obsah emailu nebo textového souboru. Framework je vydáván pod BSD licenc´ı, která umoˇzn ˇuje pouˇz´ıt pro aplikace uˇz´ıvaj´ıc´ı Aperture API libovolnou licenci. Posledn´ı verze projektu je 1.6.0 z 30. prosince 2011. Na domovsk´ ych strán7 kách frameworku se nicménˇe jako posledn´ı uvád´ı 1.5.0 z 1. ˇcervence 2010. Jeden z v´ yvojáˇr˚ u, Antoni Mylka, komentoval stav projektu v tiketu v repositáˇri [36]. Dle jeho slov je projekt mrtv´ y, a zlom nastal v roce 2011, kdy se hlavn´ı v´ yvojáˇr rozhodl, ˇze nechce pouˇz´ıvat RDF k uchováváni dat a pˇreˇsel na jin´ y projekt. Nen´ı pr´ y ˇza´dn´ y aktivn´ı projekt, kter´ y by na Aperture navazoval ve smyslu extraktoru metadat a jejich uchován´ı v RDF. Zpˇetnˇe jako nejvˇetˇs´ı problém projektu uvád´ı fakt, ˇze velká ˇca´st lid´ı odm´ıtala RDF, a ti, kteˇr´ı ho podporovali, se nedokázali shodnout na centráln´ı ontologii a m´ısto toho se snaˇzili prosadit svoji vlastn´ı. Aperture dokáˇze z´ıskat metadata z JPEG souboru. Formáty PNG a TIFF nejsou podporovány. V JPEG souboru ˇcte pouze Exif metadata. Exif Makernote nedokáˇze zpracovat. Metadata jsou mapována na vlastnosti NEPOMUK ontologie.

3.1.5

Porovn´ an´ı n´ astroj˚ u

V tabulce 3.1 uvád´ım srovnán´ı jmenovan´ ych nástroj˚ u na základˇe mnoˇzstv´ı jimi rozpoznateln´ ych metadatov´ ych tag˚ u. Pro Exif Makernote uvád´ım pouze poˇcet r˚ uzn´ ych v´ yrobc˚ u, jejichˇz metadata jsou alespoˇ n ˇcásteˇcnˇe ˇctena. Dle mého názoru má tento ukazatel vˇetˇs´ı vypov´ıdaj´ıc´ı hodnotu, protoˇze jednotlivé ˇreˇsen´ı pˇristupuj´ı odliˇsnˇe k metadat˚ um r˚ uzn´ ych model˚ u stejného v´ yrobce. ExifTool pro kaˇzd´ y z 26 model˚ u v´ yrobce Canon pouˇz´ıvá zvláˇstn´ı sadu tag˚ u, které se v´ yznamem pˇrekr´ yvaj´ı. Metadata Extractor pouˇz´ıvá pro tyto tagy pouze jednu sadu tag˚ u. ExifTool by tak mˇel mnohonásobnˇe v´ıce definovan´ ych tag˚ u v pˇr´ıpadˇe, ˇze by oba nástroje rozpoznávaly stejnou mnoˇzinu metadat. 7

http://aperture.sourceforge.net/

23


Bˇeˇzné slovn´ıky a ontologie

Vˇsechny nástroje pracuj´ıc´ı s XMP metadaty pracuj´ı na principu hledán´ı nadefinovan´ ych znám´ ych ˇretˇezc˚ u v serializaci RDF modelu vloˇzené do obrazového souboru. Nejsou tedy schopny zobrazit libovolné RDF vlastnosti a jejich hodnoty. Domn´ıvám se, ˇze toto ˇreˇsen´ı vycház´ı ze snahy v´ yvojáˇr˚ u z´ıskaná metadata pˇrevést do ˇclovˇekem srozumitelného tvaru. V souhrnné tabulce 3.1 uvád´ım poˇcty slovn´ık˚ u, s kter´ ymi nástroj pracuje a ˇcte nˇejaké vlastnosti v nich definované.

Exif JIF JFIF ICC profil IPTC PSIR PNG Exif Makernote XMP

Metadata Extractor

Exiv2

169 9 4 65 77 43 24

290 0 0 0 71 0 0

ExifTool Aperture 282 0 4 104 84 97 43

23 0 0 0 0 0 0

15 v´ yrobc˚ u 10 v´ yrobc˚ u 22 v´ yrobc˚ u 4 slovn´ıky 26 slovn´ık˚ u 55 slovn´ık˚ u

0 0

Tabulka 3.1: Poˇcet tag˚ u v metadatov´ ych formátech, které jednotlivé nástroje dokáˇz´ı rozpoznat. U makernote je uveden poˇcet v´ yrobc˚ u zaˇr´ızen´ı, jejichˇz metadata jsou alespoˇ n ˇca´steˇcnˇe ˇctena. U XMP je uveden poˇcet pouˇz´ıvan´ ych slovn´ık˚ u. Poˇcty tag˚ u u Metadata Extraktoru ˇcerpám ze zdrojov´ ych kód˚ u knihovny verze 2.7.2. U Exiv2 vycház´ım z webové dokumentace8 ke dni 20. 4. 2015. U ExifTool ˇcerpám ze seznam˚ u tag˚ u ke dni 20. 4. 2015, na které je odkazováno z domovské stránky projektu9 . V pˇr´ıpadˇe Aperture jsou poˇcty z´ıskány ze zdrojového kódu frameworku verze 1.6.0.

3.2

Bˇ eˇ zn´ e slovn´ıky a ontologie

V kapitole 1.2 jsem zm´ınil d˚ uleˇzitost vyuˇz´ıván´ı pojm˚ u z jiˇz existuj´ıc´ıch a pouˇz´ıvan´ ych slovn´ık˚ u pˇri návrhu RDF ˇreˇsen´ı. Prozkoumal jsem známé slovn´ıky a snaˇzil se naj´ıt takové, jejichˇz vlastnosti by byly pouˇzitelné pro uchován´ı obrazov´ ych metadat. V praxi neexistuje ˇzádn´ y centráln´ı registr slovn´ık˚ u a 8 9

http://www.exiv2.org/metadata.html a pˇr´ısluˇsné podstránky. http://www.sno.phy.queensu.ca/˜phil/exiftool/

24



je tedy moˇzné, ˇze existuj´ı dalˇs´ı relevantn´ı slovn´ıky, které jsou málo známé a propagované.

3.2.1

Dublin Core

Dublin Core slovn´ık obsahuje sadu obecn´ ych RDF vlastnost´ı, které najdou uplatnˇen´ı v ˇradˇe situac´ı. P˚ uvodn´ı verze obsahuj´ıc´ı 15 pojm˚ u, popisuj´ıc´ı napˇr. název, autora, popis, typ, formát nebo zdroj objektu, byla vydána jako IETF RFC 5013, ANSI/NISO Standard Z39.85-2007 a mezinárodn´ı standard ISO 15836-2009. Tato verze pouze vyjmenovává dané pojmy a neklade ˇza´dné sémantické poˇzadavky na jejich doménu nebo obor hodnot. Souˇcasná verze z roku 2012 [37] byla oproti standardu rozˇs´ıˇrena na 55 vlastnost´ı. Kromˇe toho definuje nˇekolik tˇr´ıd, které vyuˇz´ıvá k definici domény a oboru hodnot u vˇsech vlastnost´ı. Pro pojmy je definovan´ y jmenn´ y prostor http://purl.org/dc/terms/. K zachován´ı kompatibility se standardem z˚ ustávaj´ı na jmenném prostoru http://purl.org/dc/elements/1.1/ definované p˚ uvodn´ı pojmy bez sémantiky. Je tedy v tomto pˇr´ıpadˇe moˇzné si podle potˇreby vybrat, zda-li je vhodnˇejˇs´ı pouˇz´ıt vlastnost s definovanou sémantikou ˇci nikoliv. V kontextu mé práce jsou uˇziteˇcné pˇredevˇs´ım vlastnosti p˚ uvodn´ıho slovn´ıku popisuj´ıc´ı jméno autora (creator ), datum poˇr´ızen´ı sn´ımku (date), popis obrazu (description) ˇci autorská práva (rights). K definován´ı mé ontologie budou uˇziteˇcné vlastnosti pro název a popis.

3.2.2

Friend of a Friend

Slovn´ık Friend of a Friend (FOAF) vznikl v roce 2000. Jeho c´ılem bylo umoˇznit popsán´ı jednotliv´ ych osob a jejich vztah˚ u s jin´ ymi osobami a informacemi na webu. Sv´ ym zp˚ usobem se jednalo o jednu z prvn´ıch aplikaci konceptu linked data. Specifikace [38] dˇel´ı pojmy do tˇr´ı kategori´ı. Do hlavn´ıch (core) pojm˚ u patˇr´ı takové tˇr´ıdy a vlastnosti, které popisuj´ı charakteristiky lid´ı nezávisle na technologii sociáln´ıch s´ıt´ı. Kromˇe tˇr´ıdy pro ˇclovˇeka je zde i definice tˇr´ıd pro organizaci, projekt a skupinu. V druhé skupinˇe jsou term´ıny popisuj´ıc´ı internetové u ´ˇcty osob nebo stránky projekt˚ u. Posledn´ı skupinou jsou pomocné term´ıny pro linked data, které autoˇri povaˇzovali za uˇziteˇcné.

25



Slovn´ıkové pojmy maj´ı k sobˇe definovanou i sémantiku. Tˇr´ıdy maj´ı hierarchickou strukturu. U nˇekter´ ych tˇr´ıd je vymezeno pomoc´ı owl:disjointWith, ˇze nemaj´ı pr˚ unik s jin´ ymi tˇr´ıdami. Napˇr´ıklad tˇr´ıda Project nemá pr˚ unik s tˇr´ıdami Document a Person, tzn. nic identifikovaného jako projekt nem˚ uˇze b´ yt zároveˇ n identifikováno jako osoba. Vlastnosti maj´ı definovanou doménu a obor hodnot. U vlastnost´ı navzájem inverzn´ıch je inverze definována. Zaj´ımav´ ym pojmem ve vztahu k mé práci je thumbnail, jakoˇzto vlastnost propojuj´ıc´ı obraz se sv´ ym náhledem. Dále jsou zde vlastnosti pouˇzitelné pro podrobnˇejˇs´ı popis autora sn´ımku. Vlastnost depicts m˚ uˇze propojit obraz a objekt, ˇci osobu na nˇem zachycenou. Teoreticky by se dalo uvaˇzovat i o vlastnosti based near, která propojuje dva objekty, které jsou si bl´ızké ve smyslu geografické pozice.

3.2.3

Kanzaki Exif

Masahide Kanzaki vydal v roce 2003 ontologii [39], která umoˇzn ˇuje zapsat Exif metadata definovaná ve specifikaci verze 2.2. Konkrétnˇe jde o metadata v Exif, GPS a Interoperability IFD. Makernote nejsou podporována. Definované tˇr´ıdy maj´ı hierarchickou strukturu. Pro tagy obsahuj´ıc´ı ˇc´ıseln´ıkov´ y kód jsou definovány zvláˇstn´ı tˇr´ıdy, jejichˇz instance odpov´ıdaj´ı jednotliv´ ym hodnotám ˇc´ıseln´ıkov´ ych kód˚ u. Napˇr´ıklad pro tag flash obsahuj´ıc´ı kód se stavem blesku pˇri poˇr´ızen´ı sn´ımku je v ontologii vytvoˇrena tˇr´ıda Dataflash, jej´ımiˇz instancemi jsou Fired, NotFired, Fired-auto a dalˇs´ı. Tyto objekty maj´ı definované pouze popisné vlastnosti rdfs:label obsahuj´ıc´ı název instance a rdfs:comment obsahuj´ıc´ı textové vysvˇetlen´ı v´ yznamu vˇcetnˇe ˇc´ıselˇ n´ıkové kódu. C´ıseln´ıkov´ y kód jako takov´ y nen´ı ˇzádnou vlastnost´ı samostatnˇe popsán a musel by v pˇr´ıpadˇe potˇreby b´ yt ˇcten´ y z komentáˇre. RDF vlastnosti jsou v ontologii hierarchicky ˇclenˇené a maj´ı definovanou doménu a obor hodnot. U literál˚ u je oborem hodnot datov´ y typ z XML schématu. Nˇekteré vlastnosti maj´ı anotac´ı nastavenou v´ ychoz´ı hodnotu. Kaˇzdá vlastnost odpov´ıdaj´ıc´ı nˇekterému z Exif tag˚ u má anotac´ı pˇriˇrazené ˇc´ıslo daného tagu.

26


3.2.4


NEPOMUK Information Element

NEPOMUK, zkratka pro Networked Environment for Personal, Ontologybased Management of Unified Knowledge, je projekt snaˇz´ıc´ı se o vytvoˇren´ı open-source softwarov´ ych nástroj˚ u, které by umoˇznily pracovat s informacemi v poˇc´ıtaˇci sémanticky. Jde primárnˇe o otázku pˇreveden´ı strukturovan´ ych dat z libovolného datového souboru do sémantického modelu, v pˇr´ıpadˇe tohoto projektu do RDF. Za t´ımto u ´ˇcelem vznikla ˇrada ontologi´ı a slovn´ık˚ u. Jejich podmnoˇzinu tvoˇr´ı sada ontologi´ı oznaˇcovaná jako NEPOMUK Information Element (NIE) [40]. Specifikace NIE klade na ontologie nˇekolik poˇzadavk˚ u. Mimo jiné by nemˇely uˇz´ıvat jazykové konstrukce, které nejsou v RDF schématu, nebo v NEPOMUK Representation Language, coˇz je nadstavba nad RDFS pro projekt NEPOMUK. Je nutné specifikovat doménu a obor hodnot u vlastnost´ı v ontologii. U tˇr´ıd by mˇela b´ yt vytvoˇrena hierarchie, pokud je to moˇzné. Prvn´ı ontologi´ı v sadˇe je NIE [40], dle které se jmenuje celá sada. V n´ı je definována tˇr´ıda Informaˇcn´ıho elementu, coˇz je abstraktn´ı tˇr´ıda pro informace uloˇzené v souboru. V ontologii se nacház´ı vlastnosti, které se hod´ı k zapsán´ı IPTC metadat. Jsou to copyright, contentCreated popisuj´ıc´ı dobu vytvoˇren´ı obsahu, keyword s kl´ıˇcov´ ymi slovy a title pro název sn´ımku. NEPOMUK File Ontology [41] nab´ız´ı moˇznosti jak zapsat informace o datovém souboru na disku. Jsou zde vlastnosti k zapsán´ı jména souboru, hash otisku, dobu vytvoˇren´ı a modifikace. Pro obrazové soubory jsou zaj´ımavé vlastnosti urˇcuj´ıc´ı, z kolika prvk˚ u je sloˇzena barevná paleta, zda-li docház´ı k prokládán´ı obrazu (interlace) nebo jak´ ym zp˚ usobem je komprimován. Posledn´ı zaj´ımavou ontologi´ı je NEPOMUK EXIF ontologie (NEXIF) [42]. Tato ontologie mˇela vzniknout jako rozˇs´ıˇren´ı Kanzakiho ontologie, která v té dobˇe postrádala definici domény a oboru hodnot vlastnost´ı a nevyhovovala tak nastaven´ ym poˇzadavk˚ um projektu na ontologie. K d˚ uleˇzité zmˇenˇe doˇslo u vlastnost´ı, pro které Kanzaki definoval ˇc´ıseln´ıkové tˇr´ıdy. V specifikaci NEXIF maj´ı tyto vlastnosti obor hodnot integer nebo string. Ontologie tak ztrác´ı funkci kontrolovaného slovn´ıku. Na druhou stranu je moˇzné do tˇechto vlastnost´ı pˇriˇradit hodnotu, která ve specifikaci Exif nen´ı definovaná, ale je zavedená v´ yrobcem v Makernote.

27


3.2.5


Geo

Exif metadata obsahuj´ı i u ´daj o geografické poloze, kde byl sn´ımek poˇr´ızen. K zápisu této informace lze vyuˇz´ıt slovn´ık vytvoˇren´ y W3C [43]. Slovn´ık definuje tˇr´ıdu geografického bodu a jej´ı vlastnosti zemˇepisná délka, ˇs´ıˇrka a v´ yˇska. Obor hodnot vlastnost´ı nen´ı definovan´ y, je doporuˇcováno pouˇz´ıvat textov´ y ˇretˇezec.

3.2.6

Adobe slovn´ıky

Spoleˇcnost Adobe Systems vyuˇz´ıvá metadatov´ y formát XMP, kter´ y je zaloˇzen na RDF. Aby bylo moˇzné uchovávat data, vytvoˇrila nˇekolik slovn´ık˚ u obsahuj´ıc´ıch pojmy k popisu obrazov´ ych dat. Slovn´ıky jsou do urˇcité m´ıry popsány ve specifikac´ıch XMP [21, 22, 23] a dokumentu mapován´ı IIM na XMP[25]. Dle dokument˚ u se zdá, ˇze slovn´ıky pokr´ yvaj´ı velkou mnoˇzinu obrazov´ ych metadat. V dokumentech jsou vˇsak pouze informace o jmenném prostoru, názvu vlastnosti a datovém typu. Nen´ı známo, zda-li mezi pojmy existuj´ı dalˇs´ı ontologické vztahy. Spoleˇcnost nikde nezveˇrejnila serializaci definice slovn´ık˚ u do nˇekterého z RDF formát˚ u. Slovn´ıky tak bohuˇzel nelze vyuˇz´ıt v sémantick´ ych aplikac´ıch pracuj´ıc´ıch s ontologiemi.

28

4 Návrh ˇreˇsen´ı 4.1

Poˇ zadavky na ˇ reˇ sen´ı

V zadán´ı je vymezeno, ˇze ˇreˇsen´ı by mˇelo vycházet z potˇreb projektu Medical Research & Education (MRE) na Katedˇre informatiky a v´ ypoˇcetn´ı techniky Západoˇceské univerzity v Plzni1 . V tomto projektu je vyv´ıjen nástroj MetaMed, kter´ y je pouˇz´ıván k extrakci metadat z pˇr´ıchoz´ıch lékaˇrsk´ ych dat v r˚ uzn´ ych formátech. Metadata obrazov´ ych soubor˚ u ale nejsou zat´ım programem ˇrádnˇe extrahována. Program pouze zap´ıˇse jejich obecná metadata jako název souboru, datum vytvoˇren´ı souboru nebo hash otisk. Informace obsaˇzené v obrazov´ ych metadatech by byly uˇziteˇcné pro dalˇs´ı práci se soubory a poˇzadavek na jejich extrakci mˇel vysokou prioritu. Proto v práci ˇreˇs´ım právˇe obrazové soubory. Po konzultaci s vedouc´ım diplomové práce byly na základˇe ˇcetnosti uˇzit´ı vybrány grafické soubory MIME typ˚ u image/jpeg, image/png a image/tiff jako vhodné k ˇreˇsen´ı. ˇ sen´ı bude m´ıt formu pluginu pro aplikaci MetaMed v jazyce Java. MeReˇ taMed je licencovan´ y pod GNU General Public Licence verze 32 . Je nutné brát ohled na kompatibilitu licenc´ı extern´ıch knihoven s touto licenc´ı. MetaMed nen´ı vázán na konkrétn´ı operaˇcn´ı systém ˇci platformu, plugin by tedy mˇel b´ yt také multiplatformn´ı. Aplikace poskytuje rozhran´ı pro pˇripojen´ı pluginu. Posledn´ım poˇzadavkem je uloˇzen´ı z´ıskan´ ych metadat do RDF modelu, s kter´ ym MetaMed pracuje.

4.2

Test existuj´ıc´ıch extrakˇ cn´ıch n´ astroj˚ u

Proces ˇcten´ı metadat z obrazov´ ych soubor˚ u nen´ı triviáln´ı, d˚ ukazem tomu budiˇz fakt, ˇze existuj´ıc´ı nástroje se liˇs´ı v mnoˇzstv´ı z´ıskateln´ ych metadat, viz tabulka 3.1. Nav´ıc v pˇr´ıpadˇe Exif Makernote nen´ı k dispozici dokumentace popisuj´ıc´ı jejich v´ yznam a zp˚ usob zápisu. Pro tuto ˇcinnost by zˇrejmˇe bylo vhodné prozkoumat moˇznost vyuˇzit´ı jiˇz existuj´ıc´ıho a ovˇeˇreného ˇreˇsen´ı jin´ ych 1 2

Domovsk´ a str´ anka Medical Research & Education: http://medical.kiv.zcu.cz/ http://www.gnu.org/licenses/gpl-3.0.en.html

29

Návrh ˇreˇsen´ı

Test existuj´ıc´ıch extrakˇcn´ıch nástroj˚ u

autor˚ u. V kapitole 3.1 jsem popsal nˇekolik nástroj˚ u pracuj´ıc´ıch s metadaty, které se sv´ ym rámcem bl´ıˇz´ı náplni této práce. Pro porovnán´ı nástroj˚ u a pˇrehlednou prezentaci jejich schopnosti extrahovat metadata jsem vybral ˇctyˇri testovac´ı obrazové soubory, které sv´ ymi obsaˇzen´ ymi metadaty dostateˇcnˇe ilustruj´ı pr˚ umˇern´ y stav z dostupn´ ych soubor˚ u. Jedná se o jeden soubor PNG formátu, jeden TIFF soubor a dva JPEG soubory. Soubory JPEG a TIFF jsou poˇr´ızeny fotoaparáty r˚ uzn´ ych v´ yrobc˚ u, konkrétnˇe spoleˇcnostmi Canon, Olympus a Nikon. Pouˇzité verze nástroj˚ u pˇri testován´ı jsou Metadata Extractor 2.7.2, Exiv2 0.24, Exiftool 9.94, Aperture 1.6.0. Nalezen´ı vhodn´ ych soubor˚ u, ve kter´ ych by bylo zastoupeno co nejv´ıce r˚ uzn´ ych metadatov´ ych formát˚ u a tag˚ u, bylo obt´ıˇzné. U soubor˚ u ˇcasto chybˇela informace o tom, zda-li je moˇzné je volnˇe uˇz´ıt v mé práci. Nakonec jsem zvolil soubory, které jsou sb´ırány autorem Metadata Extraktoru a následnˇe poskytovány volnˇe k libovolnému uˇzit´ı. Archiv3 v souˇcasné dobˇe obsahuje 385 grafick´ ych soubor˚ u 22 r˚ uzn´ ych formát˚ u. Poˇcty nalezen´ ych tag˚ u uvád´ım v souhrnné tabulce 4.1, detailn´ı tabulka vˇcetnˇe seznamu nalezen´ ych metadat je na pˇriloˇzeném DVD. Z podstaty vˇeci nelze urˇcit celkov´ y poˇcet metadat v souborech a vyjádˇrit pod´ılem nalezené mnoˇzstv´ı z celku. V tabulce pro pˇrehlednost uvád´ım hodnotu pouze v pˇr´ıpadˇe, ˇze v daném souboru nˇekter´ y z extraktor˚ u nalezl alespoˇ n jeden tag pˇr´ısluˇsného metadatového formátu. Pokud byla metadata ve v´ıce souborech, jsou poˇcty v´ yskyt˚ u pro jednotlivé soubory oddˇeleny ˇcárkou. V takovém pˇr´ıpadˇe je poˇrad´ı hodnot v´ yznamné a je stejné pro vˇsechny pole dané ˇra´dky. Nástroje se neshoduj´ı na názvech metadatov´ ych formát˚ u. Uvád´ım oznaˇcen´ı zavedené v této práci. V jednom ze soubor˚ u byla nalezena metadata formátu Adobe JPEG, kter´ y v této práci nen´ı popsan´ y. Nástroje ExifTool a Aperture metadata Exif dále neˇclen´ı. Oproti tomu Metadata Extractor a Exiv2 je tˇr´ıd´ı dle IFD, ve kterém jsou obsaˇzeny. Abych mohl smysluplnˇe porovnávat v´ ysledky, uvád´ım v ˇra´dku Exif souˇcet nalezen´ ych metadat ze vˇsech Exif IFD kromˇe Exif Makernote. Ta jsou uvedena samostatnˇe. V tabulce 4.1 jsou tuˇcnˇe zv´ yraznˇeny maxima pro dan´ y metadatov´ y formát a soubor. Z tohoto testu nevzeˇsel dominantn´ı nástroj, tedy takov´ y, kter´ y by v kaˇzdém souboru nalezl nejv´ıce metadat ve vˇsech metadatov´ ych formátech. 3

https://github.com/drewnoakes/metadata-extractor-images

30


Test existuj´ıc´ıch extrakˇcn´ıch nástroj˚ u

Metadata Extractor Exif Exif Makernote JIF Adobe JPEG ICC profil IPTC PSIR XMP PNG

Exiv2

ExifTool Aperture

42, 44, 72 45, 46, 73 36, 38, 57 132, 49 105, 116 144, 160 8, 8 0, 0 0, 0 4 0 4 30, 0 0, 0 39, 25 3 3 3 2 0 2 13 127 84 14 0 14

13, 13, 0 0, 0 0, 0 0 0, 0 0 0 0 0

Tabulka 4.1: Poˇcet nalezen´ ych metadat u testovan´ ych soubor˚ u. V pˇr´ıpadˇe v´ yskytu metadatového formátu ve v´ıce souborech jsou hodnoty pro jednotlivé soubory oddˇeleny ˇca´rkou. Tuˇcnˇe jsou zv´ yraznˇeny maxima pro konkrétn´ı soubor a metadatov´ y formát. Jako nevyhovuj´ıc´ı se jev´ı Aperture, kter´ y, jak jiˇz bylo popsáno v kapitole 3.1.4 a ukázáno v tabulce 3.1, um´ı pracovat pouze s Exif daty JPEG souboru. Ani zde ale nedosahuje u ´rovnˇe ostatn´ıch nástroj˚ u. Vhodn´ y nen´ı ani Exiv2, kter´ y nedokáˇze pracovat s PNG soubory a metadatov´ ymi formáty jin´ ymi neˇz Exif, IPTC a XMP. Pro ˇrádné otestován´ı schopnosti práce s IPTC bylo v testované sadˇe málo metadat tohoto typu. Nástroj nalezl 3 metadata stejnˇe jako Metadata Extractor a ExifTool. V pˇr´ıpadˇe Exif metadat identifikoval Exiv2 nejv´ıce metadat ze vˇsech nástroj˚ u. Po hlubˇs´ım srovnán´ı nalezen´ ych tag˚ u se ukázalo, ˇze na rozd´ıl od ostatn´ıch vypisuje i odkazy na IFD formou bytového offsetu v souboru. Bez tˇechto odkaz˚ u odpov´ıdaj´ı mnoˇziny nalezen´ ych tag˚ u tˇem, které z´ıskal Metadata Extractor. Exif Makernote zpracoval Exiv2 v obou pˇr´ıpadech. V XMP záznamu dokázal Exiv2 pˇreˇc´ıst nejv´ıce vlastnost´ı i pˇresto, ˇze má definováno ménˇe slovn´ık˚ u neˇz ExifTool, viz tabulka 3.1. Metadata Extractor dokázal z´ıskat ve vˇsech pˇr´ıpadech v´ıce Exif metadat neˇz ExifTool. Jako jedin´ y rozpoznal JIF metadata obsaˇzená v JPEG souborech. U metadatov´ ych formát˚ u Adobe JPEG, IPTC, PSIR a PNG rozpoznal ˇ stejná metadata jako ExifTool. Spatn´ y v´ ysledek mˇel Metadata Extractor u XMP, kde dokázal pˇreˇc´ıst pouze 13 tag˚ u oproti 84 tag˚ u ˇcten´ ych ExifToolem. Tento v´ ysledek pramen´ı z toho, ˇze Metadata Extractor pouˇz´ıvá pouze 4 slovn´ıky. Metadata Extractor nedokázal extrahovat ICC profil z testovaného souboru TIFF. Z JPEG souboru profil pˇreˇcetl, ale z´ıskal ménˇe metadat neˇz 31


Volba nástroje

ExifTool. U v´ ysledku ˇcten´ı Makernote tag˚ u je d˚ uleˇzité poznamenat, ˇze zde Metadata Extractor vypisuje i tagy, u kter´ ych nezná v´ yznam. Jde o 50, resp. 3 tagy. Po jejich odeˇcten´ı je na tom kvantitativnˇe h˚ uˇre neˇz Exiv2 a ExifTool. U ExifTool je problém s nemoˇznost´ı zpracovávat JIF metadata. Exif metadata nepˇreˇcetl v takové m´ıˇre jako Metadata Extractor a Exiv2. XMP metadat zpracoval ménˇe neˇz Exiv2. U ostatn´ıch metadatov´ ych formát˚ u mˇel nejlepˇs´ı v´ ysledek.

4.3

Volba n´ astroje

Z hlediska mnoˇzstv´ı rozpoznan´ ych tag˚ u v pˇredchoz´ım testu nebyl ˇza´dn´ y nástroj perfektn´ı. Kaˇzd´ y z trojice Metadata Extractor, Exiv2 a ExifTool mˇel oblast, ve které vynikal. Variantou by tedy bylo vyuˇz´ıt v mém pluginu vˇsechny nástroje podle jejich siln´ ych stránek. Jelikoˇz je kaˇzd´ y psán v jiném jazyce, bylo by v rámci jejich integrace nutné hledat zp˚ usob jak efektivnˇe volat procedury jiného jazyka. Problém by bylo moˇzné obej´ıt pouˇz´ıván´ım konzolov´ ych aplikac´ı m´ısto knihoven a ˇcten´ım extrahovan´ ych metadat z v´ ystupu aplikac´ı. Tento pˇr´ıstup vˇsak otev´ırá nové problémy s identifikac´ı tag˚ u a jejich hodnoty. ExifTool uvád´ı pouze názvy vlastnost´ı a metadatov´ y formát. XMP metadata se stejn´ ym názvem, ale jin´ ym adresáˇrem, nelze proto rozliˇsit. Takto pˇredávaná metadata by nav´ıc jiˇz byla interpretována, coˇz by vadilo pˇri procesu mapován´ı do RDF na existuj´ıc´ı slovn´ıky, ve kter´ ych m˚ uˇze b´ yt poˇzadována ˇc´ıseln´ıková hodnota. Dalˇs´ım problémem by byla otázka rozdˇelen´ı ˇreˇseného problému mezi nástroje. ExifTool má v´ıce jak dvojnásobn´ y poˇcet slovn´ık˚ u pro XMP neˇz Exiv2, ale extrahoval v testu ménˇe metadat. Kter´ y z nich má b´ yt v takovém pˇr´ıpadˇe urˇcen ke zpracován´ı daného formátu? I kdyby se problém rozdˇeloval aˇz na u ´rovni slovn´ık˚ u a v´ yrobc˚ u Makernote, byla by potˇreba vypracovat podrobná anal´ yza rozpoznateln´ ych metadat a m´ıry jejich uˇziteˇcnosti, aby ˇslo exaktnˇe rozhodnout o nástroji, kter´ y bude slovn´ık ˇci daného v´ yrobce ˇreˇsit. Toto ˇreˇsen´ı se mi zdálo nepraktické a proto jsem se rozhodl zvolit pouze jednu knihovnu, s kterou budu pracovat. V této fázi jsem jiˇz uvaˇzoval pouze nástroje Metadata Extractor a ExifTool, které podporuj´ı vˇsechny poˇzadované souborové formáty. Metadata Extractor je psán v jazyku Java, ExifTool je v jazyku Perl. Jelikoˇz plugin má b´ yt v jazyku Java a já nemám ˇza´dné zkuˇse-

32


Výbˇer ontologi´ı a slovn´ık˚ u

nosti s volán´ım procedur jazyka Perl Java aplikac´ı a ani s jazykem Perl jako takov´ ym, rozhodl jsem se pro Metadata Extractor.

4.4

V´ ybˇ er ontologi´ı a slovn´ık˚ u

Extrahovaná metadata z obrazov´ ych soubor˚ u maj´ı b´ yt uloˇzena do RDF. V kapitole 3.2 jsem pˇredstavil slovn´ıky, které jsou pouˇz´ıvané a definuj´ı pojmy t´ ykaj´ıc´ı se této práce. Neexistuje ˇzádn´ y slovn´ık, kter´ y by sv´ ym rozsahem pokryl cel´ y ˇreˇsen´ y problém. V práci tedy kombinuji pojmy z r˚ uzn´ ych slovn´ık˚ u, pokud to jejich sémantika definovaná v ontologii umoˇzn ˇuje. Kanzakiho Exif slovn´ık a NEXIF, kter´ y je souˇcást´ı NEPOMUK projektu, definuj´ı pojmy pro Exif metadata obrazov´ ych soubor˚ u. Kaˇzd´ y ale nab´ız´ı jiné ontologické ˇreˇsen´ı. Kanzaki vyuˇz´ıvá konceptu kontrolovan´ ych slovn´ık˚ u pro Exif tagy, které maj´ı charakter ˇc´ıseln´ıku. Oproti tomu NEXIF u vˇetˇsiny tˇechto tag˚ u poˇzaduje textovou hodnotu, které odpov´ıdá ˇc´ıseln´ıkov´ y kód. V´ yjimkou jsou v souˇcasné specifikaci pojmy pro orientaci sn´ımku a zápis tag˚ u GPS IFD Exifu. NEXIF nab´ız´ı v´ıce pojm˚ u neˇz Kanzakiho slovn´ık (156 oproti 142). Z tˇechto dvou slovn´ık˚ u jsem se rozhodl pro vyuˇzit´ı NEXIF na základˇe toho, ˇze byl vytvoˇren jako rozˇs´ıˇren´ı Kanzakiho slovn´ıku, je propojen´ y s dalˇs´ımi slovn´ıky NEPOMUK projektu a obsahuje v´ıce pojm˚ u. Tato volba je dále v´ yhodná pˇri vytváˇren´ı mapován´ı Makernote metadat, které ˇzádn´ y slovn´ık explicitnˇe neˇreˇs´ı. Makernote metadata obsahuj´ı nˇekteré tagy v´ yznamem odpov´ıdaj´ıc´ı tag˚ um specifikovan´ ym v Exif formátu, ale pro ˇc´ıseln´ıkové tagy mohou zapisovat i dalˇs´ı kódy. Jelikoˇz NEXIF nemá kontrolovan´ y slovn´ık pro taková metadata a vyuˇz´ıvá textové hodnoty, nen´ı problém namapovat Makernote tag i pˇresto, ˇze se neshoduje strukturou ˇc´ıseln´ıku. Aby bylo moˇzné se zapsan´ ymi informacemi do RDF dále pracovat je potˇreba m´ıt dostupnou ontologii pro pouˇz´ıvané slovn´ıky. V tomto ohledu nevyhovuj´ı Adobe slovn´ıky, pro které nen´ı soubor s ontologi´ı uvolnˇen. Sémantiku lze ˇcásteˇcnˇe dohledat v dokumentech specifikuj´ıc´ıch XMP, ale takov´ y formát je v tomto pˇr´ıpadˇe nepouˇziteln´ y. Adobe slovn´ıky, na kter´ ych je vybudován XMP formát, proto nemohu pouˇz´ıt.

33


4.5

Implementované rozhran´ı

Implementovan´ e rozhran´ı

Plugin obsahuje tˇri tˇr´ıdy extraktor˚ u, jednu pro kaˇzd´ y typ obrazov´ ych soubor˚ u. Tyto tˇr´ıdy implementuj´ı rozhran´ı Extractor poskytované knihovnou LibMed aplikace MetaMed. Tˇr´ıdy dˇed´ı z abstraktn´ı tˇr´ıdy AbstractExtractor, která je také deklarována v knihovnˇe. Tento vztah je zachycen v diagramu tˇr´ıd na obrázku 4.1. Diagram obsahuje i signatury procedur.

Obrázek 4.1: Diagram tˇr´ıd zachycuj´ıc´ı implementované rozhran´ı a dˇediˇcnost extraktor˚ u. Rozhran´ı pˇredepisuje sedm metod, které je potˇreba implementovat. Metodou extract(File) je v parametru pˇredáván odkaz na soubor, z kterého maj´ı b´ yt z´ıskána metadata. Metadata se uloˇz´ı do RDF modelu, na kter´ y je pro4 cedurou vrácen odkaz. MetaMed pouˇz´ıvá framework Jena k práci s RDF modely a vracen´ y model je instanc´ı tˇr´ıdy implementuj´ıc´ı rozhran´ı Model 5 z tohoto frameworku. Metoda hasSupport(File) slouˇz´ı k urˇcen´ı, zda-li extraktor dokáˇze pracovat s formátem souboru, kter´ y je pˇredávan´ y v parametru. Metodou setModel(Model) se extraktoru pˇredá odkaz na RDF model, do kterého má b´ yt zapisováno. Metodami getModel(), getExtractorName() a getFileType() se z´ıská z extraktoru odkaz na pouˇz´ıvan´ y RDF model, ˇretˇezec s názvem extraktoru, respektive ˇretˇezec s datov´ ym typem, kter´ y je extraktorem zpracováván. Volán´ım metody initialize() by se mˇela instance extraktoru pˇripravit k pouˇzit´ı. Abstraktn´ı tˇr´ıda AbstractExtractor implementuje kromˇe metod extract(File) a initialize() vˇsechny pˇredepsané metody. 4 5

Domovsk´ a str´ anka frameworku: https://jena.apache.org/ com.hp.hpl.jena.rdf.model.Model

34


4.6

Struktura Metadata Extractoru

Struktura Metadata Extractoru

Metadata Extraktor ˇclen´ı známé metadatové tagy do adresáˇr˚ u. Pro kaˇzd´ y adresáˇr existuj´ı tˇr´ıdy s názvem kodDirectory.java a kodDescriptor.java, kde kod je zkratka názvu adresáˇre. V prvn´ım ze soubor˚ u jsou definované ˇc´ıselné kódy znám´ ych metadatov´ ych tag˚ u, názvy tag˚ u a procedury pro jejich z´ıskán´ı ze souboru. Do procedur b´ yvá zakomponována i kontrola správnosti dat. V druhém souboru jsou definované procedury k pˇrevodu extrahované hodnoty do formátu pro ˇclovˇeka srozumitelného. Extrakce obrazov´ ych metadat ze souboru prob´ıhá pomoc´ı funkce readMetadata(File), kterou poskytuj´ı tˇr´ıdy JpegMetadataReader, PngMetadataReader a TiffMetadataReader. Funkce vrac´ı objekt tˇr´ıdy Metadata se z´ıskan´ ymi metadaty. Tento objekt v sobˇe obsahuje nˇekolik objekt˚ u tˇr´ıdy Directory, a kaˇzd´ y z nich obsahuje nˇekolik objekt˚ u tˇr´ıdy Tag. Pokud soubor neobsahuje metadata, nebo je nebylo moˇzné pˇreˇc´ıst, nebude v Metadata instanci ˇzádn´ y Directory objekt. Z objektu Directory lze zjistit poˇcet znám´ ych tag˚ u pro dan´ y adresáˇr nebo poˇcet nalezen´ ych tag˚ u, tedy objekt˚ u tˇr´ıdy Tag v instanci Directory. Objekt uchovává v hashovac´ıch mapách z´ıskané hodnoty, z´ıskané hodnoty pˇrevedené do pˇrijatelnˇejˇs´ıho tvaru pro ˇclovˇeka a názvy metadat. Hashovac´ı mapy maj´ı jako kl´ıˇc ˇc´ıseln´ y kód tagu. Objekt um´ı vrátit iterátor pˇres nalezené tagy. U objekt˚ u tˇr´ıdy Tag lze z´ıskat pˇreloˇzenou extrahovanou hodnotu, ˇc´ıseln´ y kód tagu decimálnˇe nebo hexadecimálnˇe, ˇci název tagu. Extrahovanou hodnotu nepˇreloˇzenou nelze z objektu z´ıskat. Je potˇreba pouˇz´ıt adresáˇrov´ y objekt. Extrahované hodnoty jsou textové ˇretˇezce bez ohledu na jejich v´ yznam.

35

5 Implementace Architektura ˇreˇsen´ı je zobrazena diagramem tˇr´ıd na obrázku 5.1. Tˇr´ıdy jsou rozdˇeleny do ˇctyˇr bal´ık˚ u. V bal´ıku extractor jsou tˇr´ıdy implementuj´ıc´ı rozhran´ı Extractor MetaMedu. V bal´ıku mapping je pouze jedna tˇr´ıda, IndividualData, kterou pouˇz´ıvám pro uchován´ı definice mapován´ı pro urˇcit´ y tag. Bal´ık util obsahuje tˇri tˇr´ıdy se statick´ ymi procedurami uˇziteˇcn´ ymi pˇri zpracován´ı metadat a tˇr´ıdu OneLinerLogFormat potˇrebnou pˇri inicializaci Java loggeru, aby byla zjednoduˇsena syntaxe zapisovan´ ych záznam˚ u do logu. Posledn´ı bal´ık, common, obsahuje tˇr´ıdu zpracovávaj´ıc´ı extrahovaná metadata nezávisle na typu souboru a tˇr´ıdu spravuj´ıc´ı konfiguraci pluginu. V diagramu pro pˇrehlednost vynechávám procedury, které slouˇz´ı k rozˇclenˇen´ı komplexn´ıch ˇcinnost´ı a uvád´ım pouze hlavn´ı proceduru. Napˇr´ıklad tˇr´ıda ValueTransformator má 15 neuveden´ ych privátn´ıch procedur na transformaci hodnot, které se volaj´ı v závislosti na vstupn´ım parametru funkce dataTransformation. Plné kˇrivky v diagramu znaˇc´ı asociaci, tzn. ˇze tˇr´ıda, z které kˇrivka vycház´ı, má ve svém atributu odkaz na instanci tˇr´ıdy, do které kˇrivka vede. Pˇreruˇsovaná kˇrivka znaˇc´ı závislost, tedy ˇze tˇr´ıda, z které kˇrivka vycház´ı, v nˇekteré ze sv´ ych procedur vyuˇz´ıvá proceduru ˇci atribut tˇr´ıdy, do které je kˇrivka vedena. Pro zmenˇsen´ı poˇctu lini´ı v diagramu vykresluji pouze jednu spojnici na okraj bal´ıku v pˇr´ıpadˇe, ˇze daná závislost ˇci asociace plat´ı pro kaˇzdou tˇr´ıdu bal´ıku.

5.1

Bal´ık extractor

Extraktory vyuˇz´ıvaj´ı anotaci @MetaDataExtractor definovanou knihovnou LibMed v projektu MetaMed. D´ıky této anotaci dokáˇze aplikace MetaMed naj´ıt vˇsechny tˇr´ıdy extraktor˚ u aniˇz by na nˇe bylo ve zdrojovém kódu pˇr´ımo odkazováno. Knihovna Metadata Extractor pracuje s obrazov´ ymi soubory JPEG, PNG a TIFF podobnˇe. Pˇri implementaci proto nebylo potˇreba navrhovat odliˇsné algoritmy a kódy v extraktorech jsou si podobné. Kaˇzd´ y extraktor si uchovává v privátn´ıch atributech odkaz na ontologick´ y model obsahuj´ıc´ı definici mapován´ı metadat na RDF vlastnosti, konfiguraci, nástroj k zapsán´ı RDF trojice do modelu a instanci ExtractorLogic, která obsahuje hlavn´ı logiku ex36

Implementace

Bal´ık extractor

Obrázek 5.1: Diagram tˇr´ıd v pluginu a jejich vzájemn´ ych závislost´ı. trakce a zpracován´ı metadat spoleˇcnou pro vˇsechny extraktory. Kromˇe toho má kaˇzd´ y definován v hashovac´ı mapˇe tˇr´ıdy metadatov´ ych adresáˇr˚ u z Metadata Extractoru, které jsou pro dan´ y typ souboru pˇr´ıpustné, a jejich kódovou zkratku. Volán´ım konstruktoru se pˇriˇrad´ı ˇretˇezec s MIME typem, kter´ y extractor ˇreˇs´ı, do zdˇedˇeného atributu fileType a nastav´ı se název extraktoru dle jména extraktorové tˇr´ıdy. Volán´ı konstruktoru s parametrem pouˇz´ıvaného RDF modelu pˇriˇrad´ı jeho odkaz do zdˇedˇené promˇenné model.

37

Implementace

Bal´ık extractor

Pro u ´plnou implementaci rozhran´ı mus´ı tˇr´ıdy poskytnout vlastn´ı implementaci dvou procedur. Proceduru initialize() volá MetaMed jednorázovˇe na zaˇcátku procesu extrakce metadat ze soubor˚ u. Procedura z´ıská odkazy na instance singleton˚ u ExtractorSettings a ExtractorLogic a z nich dále odkazy na instanci utility k zápisu do RDF modelu, RDFUtil projektu MetaMed, a ontologického modelu, ve kterém je naˇctena mapovac´ı ontologie. Druhá procedura, extract(File), je volána pro kaˇzd´ y zpracovávan´ y soubor a obsahuje algoritmus k pˇreˇcten´ı, zpracován´ı a zápisu metadatové informace.

5.1.1

Algoritmus extrakce

Algoritmus se skládá z následuj´ıc´ıch sériovˇe provádˇen´ ych ˇcinnost´ı: 1. Vytvoˇren´ı poˇcitadel uchovávaj´ıc´ıch statistiky. ˇ ı obecn´ 2. Cten´ ych souborov´ ych metadat, vytvoˇren´ı Resource objektu v modelu pro dan´ y soubor na základˇe jeho názvu a zapsán´ı ˇcten´ ych metadat. 3. Vytvoˇren´ı hashovac´ı mapy uchovávaj´ıc´ı názvy a odkazy na vˇsechny vytvoˇrené objekty typu Resource a vloˇzen´ı objektu zpracovávaného souboru. ˇ ı metadat pomoc´ı knihovny Metadata Extractor. 4. Cten´ 5. Z´ıskán´ı definice z mapovac´ı ontologie pro kaˇzd´ y tag z kaˇzdého adresáˇre a zapsán´ı ˇcten´ ych metadat do RDF modelu. 6. Zmˇenˇen´ı IRI vˇsech objekt˚ u Resource kromˇe objektu reprezentuj´ıc´ı zpracovávan´ y soubor. 7. Vypsán´ı statistik a pˇr´ıpadného varován´ı pˇri podezˇren´ı na ˇspatnou konfiguraci extraktoru. Poˇcitadla sleduj´ı ˇctyˇri celoˇc´ıselné u ´daje. Prvn´ım je poˇcet zapsan´ ych RDF trojic do modelu. Toto ˇc´ıslo nemus´ı odpov´ıdat poˇctu nalezen´ ych a zapsan´ ych tag˚ u z r˚ uzn´ ych d˚ uvod˚ u. Napˇr´ıklad u IPTC tagu obsahuj´ıc´ı kl´ıˇcová slova k popisu souboru je pro kaˇzdé slovo zapsána jedna trojice. Do zapsan´ ych trojic se nezapoˇc´ıtávaj´ı trojice vytvoˇrené ve druhém kroku, protoˇze jsou zapisovány na jiné u ´rovni neˇz obrazová metadata. Druh´ y sledovan´ yu ´daj je poˇcet tag˚ u, jejichˇz definice nebyla nalezena v mapovac´ı ontologii. Jde pˇreváˇznˇe o tagy, 38

Implementace

Bal´ık extractor

které extrahovac´ı knihovna nezná a extrahovaná hodnota nemus´ı b´ yt korektn´ı. Tyto tagy v mapovac´ı ontologii nejsou obsaˇzeny z d˚ uvodu nemoˇznosti vytvoˇren´ı jejich koneˇcného v´ yˇctu. Dalˇs´ı podrobnosti ke zp˚ usobu vytváˇren´ı mapovac´ı ontologie jsou v kapitole 5.5.1. Tˇret´ım u ´dajem je poˇcet tag˚ u definovan´ ych v ontologii, ale nemapovan´ ych na ˇzádnou RDF vlastnost. Takové tagy dokáˇze knihovna pojmenovat, ale hodnoty v nich obsaˇzené nejsou uˇziteˇcné pro dalˇs´ı práci na u ´rovni MetaMedu. Jde napˇr´ıklad o hodnoty Makernote obsahuj´ıc´ı data, jejichˇz interpretace je neznámá. Posledn´ım sledovan´ ym u ´dajem je poˇcet tag˚ u, jejichˇz z´ıskaná hodnota byla extrahovac´ı knihovnou oznaˇcena jako neznámá, byla prázdná, ˇci byla bˇehem transformace oznaˇcena jako neplatná. Knihovna jako neznámou oznaˇc´ı tˇreba hodnotu ˇc´ıseln´ıkového tagu, která nen´ı definovaná v ˇc´ıseln´ıku. Obecná metadata souboru jsou ˇctena zdˇedˇenou procedurou abstraktn´ı tˇr´ıdy. Bˇehem ˇcten´ı je mimo jiné z´ıskán název souboru, kter´ y je pouˇzit v parametru funkce mreResource(String) utility RDFUtil k vytvoˇren´ı zdroje daného souboru. IRI vytvoˇreného zdroje má tvaru http://mre.kiv.zcu.cz/id/HASH, kde HASH je 40 znak˚ u dlouh´ y ˇretˇezec, na kter´ y byl pˇreveden název souboru hashovac´ı funkc´ı SHA-1. Hashovac´ı mapa vytvoˇrená v bodˇe 3 slouˇz´ı k tomu, aby extraktor mohl vytváˇret komplexn´ı stromovou strukturu a mohl metadata ukládat do trojic s jin´ ym zdrojem na pozici subjektu neˇz je zdroj generovan´ y v pˇredchoz´ım kroku. Takto lze napˇr´ıklad informace o náhledu obrazu obsaˇzené v jednom z Exif IFD zapsat bez toho, aby kolidovala s informacemi o p˚ uvodn´ım obrazu. Ke ˇcten´ı obrazov´ ych metadat pouˇz´ıvám v´ yhradnˇe knihovnu Metadata Extractor a jej´ı funkce vracej´ıc´ı instanci tˇr´ıdy Metadata, viz kapitola 4.6. Pˇri procházen´ı vˇsech tag˚ u adresáˇre si program uchovává mnoˇzinu ˇc´ısel jiˇz zpracovan´ ych tag˚ u. Nˇekteré tagy mohou b´ yt zpracovány jeˇstˇe pˇred t´ım, neˇz se k nim iterátor dostane. To nastává v pˇr´ıpadˇe, kdy se zapisovaná hodnota skládá z hodnot nˇekolika tag˚ u. Napˇr´ıklad v IPTC jsou datum a ˇcas vytvoˇren´ı zapsány do dvou tag˚ u, ale pro zápis do RDF potˇrebuji jejich sloˇzenou hodnotu. Pokud se iterátor dostane k jiˇz zpracovanému tagu, pokraˇcuje hned následuj´ıc´ım tagem. Toto ˇreˇsen´ı nen´ı nezbytnˇe nutné, protoˇze zpracován´ı skládané hodnoty je definováno tak, aby nezáleˇzelo na poˇrad´ı nalezen´ı tag˚ u. Zapisovaná trojice by odpov´ıdala trojici jiˇz existuj´ıc´ı v grafu a nebyla by duplicitnˇe zapsána. Nicménˇe toto ˇreˇsen´ı ˇsetˇr´ı v´ ypoˇcetn´ı ˇcas v pˇr´ıpadˇe, kdy se v datech kombinované hodnoty vyskytuj´ı.

39

Implementace

Bal´ık commons

Pro kaˇzd´ y tag nalezen´ y Metadata Extractorem se vyhledá definice mapován´ı z mapovac´ı ontologie. Definic´ı se rozum´ı prvek na jmenném prostoru de´ kde ADRE´R ˇ KOD, finovaném v konfiguraˇcn´ım souboru s názvem ADRESA ´ ˇ SAR je zkrácen´ y název metadatového adresáˇre, ve kterém se tag vyskytuje, a ´ KOD je hexadecimáln´ı ˇc´ıslo tagu, jak ho poskytuje knihovna. Dalˇs´ı informace o mapovac´ı ontologii viz kapitola 5.5.1. Definice se zpracuje funkc´ı ExtractorUtil.getMappingDefinition(Individual) a je vrácen odkaz na instanci IndividualData umoˇzn ˇuj´ıc´ı pˇr´ıstup k jednotliv´ ym poloˇzkám definice. Samotné zpracován´ı hodnoty na základˇe definice a následn´ y zápis provád´ı funkce z tˇr´ıdy ExtractorLogic. Po dokonˇcen´ı iteraˇcn´ıho cyklu nad tagy z adresáˇre mohou b´ yt vypsány chyby, na které narazila knihovna pˇri jejich extrakci. Tyto hláˇsen´ı maj´ı pouze informaˇcn´ı charakter a nejsou známkou ˇspatnˇe vykonané extrakce. Vypisuji je proto na standardn´ı v´ ystup. V celé sekci vyuˇz´ıvaj´ıc´ı extern´ı knihovnu a pracuj´ıc´ı se souborem zachytávám v´ yjimky IOException a JpegProcessingException, resp. ekvivalentn´ı pro jiné typy obrazov´ ych soubor˚ u. Hláˇsen´ı o tˇechto chybách jsou pos´ılána na chybov´ y v´ ystup. Pˇred dokonˇcen´ım práce s metadaty daného souboru jsou pˇrejmenovány RDF zdroje vytvoˇrené bˇehem zpracován´ı. Pojmenován´ı je jednoznaˇcné na základˇe trojic modelu, ve kter´ ych se zdroj vyskytuje na pozici subjektu. V dobˇe vytvoˇren´ı tˇechto zdroj˚ u nen´ı kompletn´ı model znám a pˇrejmenován´ı mus´ı probˇehnout aˇz po zápisu vˇsech trojic. T´ımto zp˚ usobem je zajiˇstˇeno, ˇze zdroje budou m´ıt pˇri opˇetovném spuˇstˇen´ı stejn´ y název. Zároveˇ n je zajiˇstˇeno, ˇze zdroje popisuj´ıc´ı shodnou skuteˇcnost vytvoˇrené pˇri zpracován´ı r˚ uzn´ ych soubor˚ u maj´ı také stejn´ y název. V d˚ usledku je zdroj popisuj´ıc´ı fotoaparát, z kterého byla série fotografi´ı poˇr´ızena, zapsán v RDF modelu pouze jednou a vˇsechny fotografie na nˇej odkazuj´ı.

5.2

Bal´ık commons

Bal´ık commons obsahuje dvˇe tˇr´ıdy. Tˇr´ıda ExtractorSetting slouˇz´ı k naˇcten´ı a uchován´ı konfigurace pluginu. ExtractorLogic definuje procedury k zapsán´ı extrahovan´ ych metadat do RDF nezávisle na typu obrazového souboru. Obˇe tˇr´ıdy jsou navrˇzené dle designového vzoru singleton, coˇz znamená, ˇze v kaˇzdém okamˇziku je inicializována nejv´ yˇse jedna instance dané tˇr´ıdy.

40

Implementace

5.2.1

Bal´ık commons

Tˇ r´ıda pro pr´ aci s konfigurac´ı

Instance tˇr´ıdy ExtractorSetting obsahuje osm atribut˚ u popisuj´ıc´ı konfiguraci pluginu. Jsou jimi atributy mappingOwlFileName, mappingOwlFileURL a immNS t´ ykaj´ıc´ı se mapovac´ı ontologie. Prvn´ı z nich nese název souboru s ontologi´ı. Druh´ y je jmenn´ y prostor, kter´ y ontologie vyuˇz´ıvá, a tˇret´ı je URL adresa, z které má b´ yt soubor pˇr´ıpadnˇe staˇzen. Obdobnˇe popisuj´ı atributy imageOwlFileName, imageNS a imageOwlFileURL ontologii pouˇz´ıvanou k zapsán´ı metadat, pro které nejsou definované vhodné vlastnosti v jin´ ych ontologi´ıch. Zbylé atributy connectionTimeout a readTimeout slouˇz´ı k nastaven´ı doby, po které se má pˇreruˇsit pokus o pˇr´ıpojen´ı k serveru pˇri stahován´ı ontologie, resp. doby, po které se pˇreruˇs´ı stahován´ı, pokud nepˇricház´ı ˇza´dná data. Ke ˇcten´ı souboru konfigurace docház´ı pˇri inicializaci. Je pouˇzita funkce knihovny LibMed PropertiesUtil.readConfigs(String). Parametrem je relativn´ı cesta k souboru. Konstantou v tˇr´ıdˇe je stanovena cesta ke konfiguraˇcn´ımu souboru image/image.properties. Funkce jako v´ ychoz´ı sloˇzku povaˇzuje .mre/ v domovském adresáˇri uˇzivatele. Z této sloˇzky naˇc´ıtá MetaMed i dalˇs´ı konfiguraci a ukládá sem v´ ypis chybového v´ ystupu. V bloku kódu pracuj´ıc´ıho s naˇcten´ ymi daty jsou zachytávány chyby NullPointerException a NumberFormatException. Prvn´ı z nich je zapˇr´ıˇcinˇena nenalezen´ım souboru na oˇcekávaném m´ıstˇe. Druhá chyba nastává pˇri pokusu pˇrevést textovou hodnotu na celoˇc´ıselnou. Pˇri v´ yskytu libovolné chyby je cel´ y program ukonˇcen, jelikoˇz proces zpracován´ı metadat a jejich zápisu do RDF závis´ı na ontologi´ıch, jejichˇz naˇcten´ı je podm´ınˇeno korektn´ı konfigurac´ı. Chyba je vysvˇetlena v chybovém hláˇsen´ı zaslaném na chybov´ y v´ ystup pˇred ukonˇcen´ım bˇehu programu. Po zpracován´ı konfiguraˇcn´ıho souboru je volána funkce validateConfig() k ovˇeˇren´ı, ˇze vˇsechny atributy byly naplnˇeny a ˇze ˇc´ıselné hodnoty ˇcasov´ ych limit˚ u k ukonˇcen´ı spojen´ı jsou kladné. Pokud to pro nˇekter´ y atribut neplat´ı, vrac´ı funkce název problémového atributu. V takovém pˇr´ıpadˇe je na chybov´ y v´ ystup zasláno hláˇsen´ı o chybném prvku konfigurace a program je ukonˇcen.

41

Implementace

5.2.2

Bal´ık commons

Tˇ r´ıda ke zpracov´ an´ı a z´ apisu metadat

Inicializace Tˇr´ıda ExtractorLogic v konstruktoru ukládá odkaz na RDF model pˇredávan´ y parametrem konstruktoru do privátn´ıho atributu. Následnˇe vytváˇr´ı instanci utility RDFUtil nad dan´ ym modelem a instanci singletonu ExtractorSettings. Na základˇe hodnot v konfiguraci se naˇctou obˇe ontologie do in-memory modelu. Pˇri naˇc´ıtán´ı se nejprve zkouˇs´ı otevˇr´ıt soubor s ontologi´ı v pracovn´ım adresáˇri. Pokud soubor nen´ı nalezen, je zaslána zpráva s názvem hledaného souboru na standardn´ı v´ ystup a program se pokus´ı z´ıskat soubor s ontologi´ı z Internetu. Pokud je u ´spˇeˇsn´ y, zap´ıˇse soubor na disk na adresu, kde byl p˚ uvodnˇe hledán. V pˇr´ıpadˇe, ˇze se ani t´ımto zp˚ usobem nepodaˇrilo ontologii z´ıskat, je na chybov´ y v´ ystup zaslána o této situaci zpráva a program se ukonˇc´ı. Toto poˇrad´ı naˇc´ıtán´ı je nutné, aby uˇzivatel mohl provádˇet zmˇeny v definici mapován´ı v lokáln´ım souboru bez nutnosti aplikovat tyto zmˇeny i na vzdáleném centráln´ım u ´loˇziˇsti. V opaˇcném pˇr´ıpadˇe by samozˇrejmˇe ˇreˇsen´ım mohlo b´ yt pˇrepsán´ı URL adresy v konfiguraci, ˇci odpojen´ı stroje od Internetu, ale takové postupy rozhodnˇe nejsou uˇzivatelsky pˇr´ıvˇetivé. Pokud uˇzivatel chce vynutit staˇzen´ı aktuáln´ı verze ontologie z Internetu, je nutné lokáln´ı soubor s ontologi´ı smazat ˇci pˇrejmenovat. Pokud naˇcten´ı probˇehne v poˇra´dku, vytvoˇr´ı se logger pro zapisován´ı lad´ıc´ıch informac´ı. Logger bude zprávy ukládat na disk do souboru imageextractor-unknown-tags.log v podsloˇzce .mre/image/ domovského adresáˇre uˇzivatele. Adresa a název souboru jsou pevnˇe definovány konstantami tˇr´ıdy. Jelikoˇz jde o soubor primárnˇe urˇcen´ y k zapisován´ı kód˚ u neznám´ ych tag˚ u, pouˇz´ıvám v loggeru redukovanou informaci bez ˇcasové znaˇcky a p˚ uvodce zprávy. Odpov´ıdaj´ıc´ı formát je definovan´ y pomocnou tˇr´ıdou OneLinerLogFormat. V pˇr´ıpadˇe chyby pˇri vytváˇren´ı souboru program pokraˇcuje v normáln´ım bˇehu, protoˇze logger nen´ı nezbytnˇe nutn´ y ke správné funkci extraktoru. Zpráva o problému je zaslána na standardn´ı v´ ystup. Nakonec je v konstruktoru ˇcten soubor .mre/image/prefix.properties v domovském adresáˇri, kter´ y obsahuje definici prefix˚ u. Prefixy se pouˇz´ıvaj´ı pˇri serializaci RDF modelu k nahrazen´ı ˇca´sti IRI se jmenn´ ym prostorem. Jako takové nemaj´ı na funkci ˇzádn´ y vliv, slouˇz´ı pˇredevˇs´ım ke zlepˇsen´ı ˇcitelnosti a redukován´ı velikosti v´ ystupn´ıho RDF souboru. Pokud by prefixy nebyly definovány, vygeneruje Jena vlastn´ı. Z tohoto d˚ uvodu je chyba pˇri zpraco-

42

Implementace

Bal´ık commons

ván´ı souboru pouze zaznamenána na standardn´ı v´ ystup a program pokraˇcuje v bˇehu. Instanci tˇr´ıdy ExtractorLogic lze z´ıskat volán´ım funkce getInstance(Model). Z instance je volán´ım funkc´ı getRDFUtil(), getOntModel() a getLogger() z´ıskateln´ y odkazy na inicializovan´ y RDFUtil pro pouˇz´ıvan´ y model, model obsahuj´ıc´ı ontologie k mapován´ı, resp. logger k v´ ypisu lad´ıc´ıch informac´ı.

Zpracov´ an´ı metadat Tˇr´ıda definuje proceduru processTag(. . . ) s ˇsesti vstupn´ımi parametry, která obsahuje ˇcást logiky extraktoru shodnou pro vˇsechny souborové typy. Prvn´ım vstupn´ımi parametrem je objekt metadatového tagu nalezen´ y Metadata Extractorem. Druh´ ym je definice mapován´ı tagu z´ıskaná z mapovac´ı ontologie. Tˇret´ı je adresáˇr nalezen´ ych tag˚ u v souboru. Následuje odkaz na seznam ˇc´ısel tag˚ u, jenˇz jiˇz byly zpracovány, a hashovac´ı mapa názv˚ u vytvoˇren´ ych uzl˚ u na jejich odkazy. Posledn´ım parametrem je poˇcitadlo statistick´ ych u ´daj˚ u. Posloupnost ˇcinnost´ı vykonávan´ ych v proceduˇre je následuj´ıc´ı: 1. Nalezen´ı dalˇs´ıch definic mapován´ı a jejich rekurzivn´ı proveden´ı. 2. Z´ıskán´ı zapisované hodnoty ˇcten´ım z tagu nebo sloˇzen´ım z v´ıce tag˚ u. 3. Z´ıskán´ı odkazu na zdroj, kter´ y bude v subjektu zapisované trojice. 4. Zapsán´ı trojice. Pro kaˇzd´ y tag lze v mapovac´ı ontologii definovat v´ıce mapován´ı. Na dalˇs´ı mapován´ı je odkazováno objektovou vlastnost´ı duplicateTo. V prvn´ım kroku je zjiˇst’ováno zda-li v definici mapován´ı zpracovávaného tagu je tato vlastnost pouˇzita. V kladném pˇr´ıpadˇe je z´ıskána definice následuj´ıc´ıho mapován´ı a je rekurzivnˇe volána procedura se stejn´ ymi parametry kromˇe druhého. Jelikoˇz hroz´ı nebezpeˇc´ı nekoneˇcného rekurzivn´ıho volán´ı pˇri pouˇzit´ı nevhodné ontologie, je pˇred volán´ım ovˇeˇreno, ˇze v ˇretˇezci vlastnost´ı duplicateTo nen´ı cyklus. Pokud by cyklus byl nalezen, je o tom zaslána zpráva na standardn´ı v´ ystup a provede se mapován´ı pouze podle p˚ uvodn´ı definice. Dále se testuje, zda-li definice obsahuje název a jmenn´ y prostor RDF vlastnosti, na kterou má b´ yt mapováno. Pokud neobsahuje, zap´ıˇse se infor43

Implementace

Bal´ık commons

mace o prázdné definici do logu pro lad´ıc´ı v´ ypisy a bˇeh programu opust´ı proceduru. Tento test nem˚ uˇze b´ yt vykonán hned na zaˇca´tku, protoˇze i v tomto ohledu prázdná definice m˚ uˇze m´ıt definované dalˇs´ı mapován´ı, které nemus´ı b´ yt prázdné. Existence pouˇzité RDF vlastnosti nen´ı programem ovˇeˇrována. Druh´ ym krokem je z´ıskán´ı hodnoty, která bude do trojice zapsána na pozici objektu. Metadata Extractor poskytuje hodnotu pˇreloˇzenou, ˇci p˚ uvodn´ı. Rozd´ıl je patrn´ y pˇredevˇs´ım u ˇc´ıseln´ıkov´ ych tag˚ u, kdy p˚ uvodn´ı hodnota je napˇr´ıklad kód 3 u tagu mˇern´ ych jednotek a pˇreloˇzená hodnota je ˇretˇezec cm. Dalˇs´ı variantou z´ıskán´ı hodnoty je jej´ı sloˇzen´ı z nˇekolika tag˚ u stejného adresáˇre. K sloˇzen´ı hodnot slouˇz´ı privátn´ı funkce concatValue(IndividualData, Directory, Set). V´ ysledná hodnota je z´ıskána zˇretˇezen´ım hodnot tag˚ u v poˇrad´ı definovaném v ontologii. K urˇcen´ı poˇrad´ı jsou pouˇzity objektové vlastnosti concatAfter a concatBefore, které jsou vzájemnˇe inverzn´ı. Funkce concatValue nejprve zkontroluje, ˇze v ontologii nen´ı tˇemito vlastnostmi tvoˇren cyklus. Testuje se naˇc´ıtán´ım dalˇs´ıch prvk˚ u v obou smˇerech, dokud takové prvky existuj´ı, a uchováván´ım seznamu ˇcten´ ych objekt˚ u. Pokud byl objekt naˇcten v´ıckrát, je v definici cyklus, informuje se o tom zprávou na standardn´ı v´ ystup a vrac´ı se prázdn´ y ˇretˇezec. V opaˇcném pˇr´ıpadˇe zaˇcne b´ yt tvoˇren v´ ysledn´ y ˇretˇezec. Pro kaˇzd´ y tag m˚ uˇze b´ yt definováno, zda-li má b´ yt pouˇzita pˇreloˇzená hodnota a zda-li je potˇreba provést transformaci. Pˇred pˇridán´ım do ˇretˇezce je hodnota oˇciˇstˇena na okraj´ıch od b´ıl´ ych znak˚ u. Hodnoty jsou v budovaném ˇretˇezci oddˇeleny mezerou. Ve funkci je ˇreˇsena speciálnˇe situace, kdy docház´ı k pˇridán´ı ˇcasového u ´daje k datu. V takovém pˇr´ıpadˇe jsou hodnoty oddˇeleny stˇredn´ıkem a po spojen´ı do ˇretˇezce je zavolána transformaˇcn´ı metoda k pˇrevodu do správného tvaru. Ve tˇret´ım kroku je zjiˇst’ováno, zda-li subjektem v zapisované trojici bude instance Resource obrazového souboru, nebo nˇejak´ y jin´ y uzel. Pokud se jedná o jin´ y uzel, je zjiˇst’ováno, zda-li nen´ı v definici cyklus, podobnˇe jako v prvn´ım kroku. V pˇr´ıpadˇe nalezen´ı cyklu nebude trojice zapsána a na standardn´ı v´ ystup bude zasláno sdˇelen´ı o problému. Pokud je definice v poˇra´dku, volá se metoda getTypedNode(IndividualData, HashMap<String, Resource>, int[]) s parametry definice mapován´ı zpracovávaného tagu, hashovac´ı mapa s vytvoˇren´ ymi uzly a poˇcitadlo statistik. Volaná funkce najde nebo vytvoˇr´ı odpov´ıdaj´ıc´ı uzel a odkaz na nˇej vrac´ı. Pˇri vytváˇren´ı nového uzlu je ˇctena jeho definice z ontologie a je moˇzné volat funkci rekurzivnˇe k vytvoˇren´ı dalˇs´ıch uzl˚ u, s kter´ ymi je vytváˇren´ y uzel spojen. Pokud nen´ı vazba na jin´ y uzel de-

44

Implementace

Bal´ık commons

finována, je zapsána trojice, kde subjektem je obrazov´ y soubor, predikát je ˇcten z definice a objektem je vytváˇren´ y uzel. Ve ˇctvrtém kroku probˇehne zápis extrahované hodnoty. K zápisu slouˇz´ı procedura addValueWithType(Resource, IndividualData, String, int[]). Parametry jsou zdroj pouˇzit´ y v subjektu nalezen´ y ve 3. kroku, definice mapován´ı tagu, zpracovaná hodnota ze 2. kroku a poˇcitadlo. Procedura na zaˇcátku nahrad´ı nepovolené znaky mezerou. Mezi nepovolené patˇr´ı ˇr´ıd´ıc´ı znaky 0x00 aˇz 0x1f, znak 0x7f a speciáln´ı znaky unicode 0xfff0 aˇz 0xffff. V´ yskyt tˇechto znak˚ u v extrahované hodnotˇe m˚ uˇze indikovat chybu pˇri extrakci, chybu v datech souboru, ˇci ˇspatnˇe vloˇzená metadata uˇzivatelem. Z testován´ı vyplynulo, ˇze se tyto znaky nacház´ı vˇetˇsinou v nˇekterém z komentáˇrov´ ych tag˚ u. Jelikoˇz m˚ uˇze j´ıt o chybu uˇzivatelskou, rozhodl jsem se hodnoty s nepovolen´ ymi znaky nezahazovat, ale pouze odstranit dané znaky. Zapisovac´ı procedura dále kontroluje, zda-li ˇretˇezec ukazuje na hodnotu null, je prázdn´ y nebo obsahuje pouze b´ılé znaky. V takovém pˇr´ıpadˇe nen´ı hodnota zapsána, protoˇze nemá smysl. Dále nejsou zapsány hodnoty zaˇc´ınaj´ıc´ı ˇretˇezcem unknown a undefined. Takové hodnoty poskytuje Metadata Extraktor v pˇr´ıpadˇe, ˇze nezná v´ yznam ˇc´ıseln´ıkového kódu. Pokud by bylo uˇzivatelem pˇresto chtˇeno zapsat hodnotu, m˚ uˇze v definici poˇzadovat zápis kódu m´ısto pˇrekladu, ˇci m˚ uˇze definovat vlastn´ı pˇreklad ˇc´ıseln´ıku. Po zkontrolován´ı zapisovan´ ych dat procedura zjiˇst’uje, zda-li je definován v ontologii oddˇelovaˇc, kter´ ym má b´ yt z´ıskaná hodnota rozdˇelena do nˇekolika ˇretˇezc˚ u. Kaˇzd´ y z ˇretˇezc˚ u je pak zapsán dle stejné definice. Oddˇelovaˇcem m˚ uˇze b´ yt regulárn´ı v´ yraz. Hodnoty jsou zapsané jako literál s definovan´ ym datov´ ym typem, nebo jako objekt kontrolovaného slovn´ıku. Pˇri zapisován´ı literálu datového typu XSDDateTime je volána pomocná funkce z tˇr´ıdy DateUtil, která se pokus´ı vstupn´ı textovou hodnotu pˇrevést do hodnoty formátu Date. Pokud se pˇrevod nepodaˇr´ı, nen´ı hodnota zapsána. Pojmy kontrolovan´ ych slovn´ık˚ u lze pouˇz´ıt pouze takové, které jsou definované v obrazové ontologii naˇctené pˇri inicializaci objektu tˇr´ıdy ExtractorLogic. IRI pojmu mus´ı m´ıt tvar VLASTy NOST HODNOTA, kde VLASTNOST je IRI vlastnosti definované pro dan´ tag a HODNOTA je extrahovan´ y ˇretˇezec upraven´ y pˇredeˇsl´ ymi kroky. Pokud prvek s dan´ ym IRI neexistuje, trojice nebude zapsána.

45

Implementace

5.3

Datová tˇr´ıda IndividualData

Datov´ a tˇ r´ıda IndividualData

Instance tˇr´ıdy IndividualData jsou pouˇz´ıvány k pˇr´ıstupu k definici mapován´ı tagu. Tˇr´ıda má 16 atribut˚ u plynouc´ıch ze struktury mapovac´ı ontologie. Pˇr´ıstup k atribut˚ um je pomoc´ı get a set metod. Atribut id uchovává název instance imageMetadata v mapovac´ı ontologii. Pokud má b´ yt stejn´ y tag ˇreˇsen i jin´ ym mapován´ım, je odkaz na takovou instanci v atributu duplicateTo. Integer tag je ˇc´ıslo, které má dan´ y tag v adresáˇri Metadata Extractoru. Toto ˇc´ıslo je potˇreba pokud je pˇristupováno k extrahovan´ ym hodnotám jin´ ych metadatov´ ych tag˚ u, napˇr´ıklad pˇri skládán´ı hodnoty z nˇekolika tag˚ u. Poˇrad´ı skládán´ı hodnot je dané ve vlastnostech follows a precedes, které obsahuj´ı odkaz na pˇredcházej´ıc´ı, resp. následuj´ıc´ı ˇca´st. Atributy namespace a attribute obsahuj´ı jmenn´ y prostor a název RDF vlastnosti, která bude pouˇzita jako predikát pˇri zapisován´ı z´ıskané hodnoty. Se zapisovanou hodnotou souvis´ı atributy description a writeAsNode obsahuj´ıc´ı pravdivostn´ı hodnotu, zda-li má b´ yt pouˇzita extrahovaná hodnota v ˇclovˇekem ˇcitelném tvaru, resp. zda-li má b´ yt v objektu pouˇzit pojem z kontrolovaného slovn´ıku. Atributy transformation a transformationParameter, popisuj´ı zp˚ usob, jak´ ym bude extrahovaná hodnota transformována a parametry transformace. V atributu datatype je datov´ y typ zapisovaného literálu. Pokud má b´ yt hodnota rozdˇelena na nˇekolik podˇretˇezc˚ u, je v atributu splitDelimiter uveden regulárn´ı v´ yraz pro nalezen´ı oddˇelovaˇc˚ u. Má-li b´ yt subjektem trojice jin´ y zdroj neˇz obrazov´ y soubor, je na definici takového zdroje odkázáno v atributu aggregatedIn. Typ zdroje m˚ uˇze b´ yt urˇcen atributy typeNamespace a typeClass, které obsahuj´ı jmenn´ y prostor a název tˇr´ıdy, jej´ıˇz instanc´ı je zdroj. Tˇr´ıda dále definuje tˇri funkce, které pracuj´ı s ˇcasto pouˇz´ıvan´ ymi kombinacemi atribut˚ u. Funkce isTyped() vrac´ı hodnotu true, pokud je v definici uzlu obsaˇzena informace o jeho typu. To znamená, ˇze atributy typeNamespace a typeClass nejsou null. Funkce isDefined() vrac´ı true, je-li znám´ y jmenn´ y prostor a název vlastnosti v predikátu, tedy atributy namespace a attribute nejsou null. Funkce needsConcat() vrac´ı true, pokud alespoˇ n jeden z atribut˚ u follows a precedes odkazuje na objekt a je nutné spojovat extrahované hodnoty. 46

Implementace

5.4 5.4.1

Bal´ık util

Bal´ık util Form´ atov´ an´ı logu

Tˇr´ıda OneLinerLogFormat je jednoduchá pomocná tˇr´ıda, která dˇed´ı z tˇr´ıdy Formatter, a slouˇz´ı k poskytnut´ı vhodnˇejˇs´ıho formátován´ı pro lad´ıc´ı log. Tˇr´ıda pˇrekr´ yvá metodu format(LogRecord) tak, aby byla do logu zapisována ˇ vzniku události, p˚ pouze informace o u ´rovni hláˇsen´ı a jeho text. Cas uvodce události ani ˇza´dné dalˇs´ı informace nejsou zapisovány. Záznam je zapsán do jednoho ˇra´dku logu. Tento formát je zam´ yˇslen k pouˇzit´ı pro logy, které nemaj´ı slouˇzit k zapisován´ı chyb pˇri bˇehu programu, ale sp´ıˇse k zaznamenáván´ı u ´daj˚ u pro dalˇs´ı zpracován´ı. Takov´ y log by mˇel b´ yt co nejstruˇcnˇejˇs´ı, aby jeho zpracován´ı bylo rychlé, a syntax´ı jednoduch´ y, aby bylo moˇzné z´ıskat potˇrebná data bez nutnosti tvorby sloˇzit´ ych regulárn´ıch v´ yraz˚ u.

5.4.2

Pr´ ace s daty a ˇ casem

Tˇr´ıda DateUtil poskytuje statickou funkci pro pˇreˇcten´ı data a ˇcasu z textového vstupu, u kterého nen´ı znám datov´ y formát. V privátn´ı konstantˇe je definována sada formát˚ u, které jsou postupnˇe aplikovány na vstupn´ı data. Poˇrad´ı, v jakém jsou aplikovány, je v´ yznamné. Hledá se prvn´ı formát, pˇri jehoˇz pouˇzit´ı v parsovac´ı funkci nen´ı vyhozena chyba ParseException. Datum a ˇcas z´ıskan´ y pouˇzit´ım takového formátu je povaˇzován za správn´ y, pokud je po 31. 12. 1969. Nen´ı-li podm´ınka splnˇena pokraˇcuje se v cyklu dalˇs´ım formátem. Podm´ınka ˇca´steˇcnˇe eliminuje problém, kdy ˇcas ve formátu HHmmssZ, napˇr´ıklad 181920-0000, byl bez vykázán´ı chyby interpretován jako formát yyyyMMdd. Hodnota vˇsak byla nesmyslná, v tomto pˇr´ıpadˇe Mon Jul 31 01:00:00 GMT+01:00 1820. Formát obsahuj´ıc´ı pouze ˇcasovou sloˇzku je siln´ y v tom ohledu, ˇze zpracuje bez chyby i vstupy obsahuj´ıc´ı pouze datum, leˇc samozˇrejmˇe nesprávnˇe. Zmˇena poˇrad´ı testován´ı by v tomto pˇr´ıpadˇe problém neˇreˇsila, naopak by zp˚ usobila dalˇs´ı problémy. P˚ uvodnˇe jsem chtˇel podm´ınku rozˇs´ıˇrit na testován´ı, ˇze z´ıskan´ y datum je pˇred souˇcasn´ ym systémov´ ym datem. Nicménˇe tato podm´ınka by ˇcinila funkci

47

Implementace

Bal´ık util

nekonzistentn´ı v tom ohledu, ˇze v závislosti na souˇcasném datu by vracela r˚ uzné v´ ystupy. Zároveˇ n by mohl nastat problém u jednoho z IPTC tag˚ u udávaj´ıc´ı datum platnosti obsahu. Tento datum z podstaty nemus´ı b´ yt pˇred souˇcasn´ ym datem. Pˇri práci s daty pouˇz´ıvám anglick´ y locale, jelikoˇz ˇretˇezce, které poskytuje Metadata Extractor, jsou zapsané v anglické notaci. Funkce by samozˇrejmˇe v pˇr´ıpadˇe potˇreby ˇsla upravit, nebo pˇret´ıˇzit, aby byl locale variabiln´ı podle prostˇred´ı uˇzivatele. ˇ sen´ı v této funkci nepracuje korektnˇe s ˇcasov´ Reˇ ymi zónami. Exif metadata s datov´ ymi a ˇcasov´ ymi hodnotami neobsahuj´ı u ´daj o ˇcasové zónˇe. Metadata Extractor sice zná tag 0x882A, kter´ y by informaci o zónˇe mˇel obsahovat, ale tag nen´ı ˇcten´ y u ˇza´dného z testovac´ıch soubor˚ u. U pˇr´ıpad˚ u, kdy nen´ı zóna uvedena, pˇredpokládá funkce pásmo UTC+0. Pro tˇr´ıdu je napsán unit test zkouˇsej´ıc´ı, ˇze jsou korektnˇe ˇcteny ˇretˇezce vˇsech definovan´ ych formát˚ u.

5.4.3

Transformace extrahovan´ ych hodnot

V tˇr´ıdˇe ValueTransformator je definována statická funkce pro transformaci extrahovan´ ych dat dataTransformation(String, IndividualData). Vstupem jsou ˇretˇezec k transformaci a mapovac´ı definice tagu. Funkce vrac´ı zmˇenˇen´ y ˇretˇezec pˇri standardn´ım bˇehu. Pokud je poˇzadována transformace, která nen´ı definována, nebo nen´ı pouˇzitelná pro daná data, je vrácen vstupn´ı ˇretˇezec. Pokud dojde k chybˇe pˇri zpracován´ı, nebo je vstupn´ı ˇretˇezec vadn´ y, vrac´ı se prázdn´ y ˇretˇezec. Ke transformaˇcn´ım funkc´ım je vytvoˇren unit test. Zp˚ usob transformace je pro tag definován odkazem na instanci transformace v mapovac´ı ontologii. Funkce nejprve iterátorem projde vlastnosti transformace a hledá jej´ı decimáln´ı kód. Pokud byl kód nalezen volá pomocnou funkci, které pˇredává kód transformace, parametry transformace a vstupn´ı ˇretˇezec. Je definováno 16 r˚ uzn´ ych transformac´ı. V mapovac´ı ontologii ´ maj´ı pˇr´ısluˇsné instance jména transformation KOD. Pˇred proveden´ım transformace jsou z ˇretˇezce odstranˇeny b´ılé znaky na zaˇcátku a konci. Transformace s kódem 1 slouˇz´ı pouze k nahrazen´ı znak˚ u mezera znakem teˇcka. Transformace je pouˇzitá u tagu GPS verze, jehoˇz v´ ystup je formátován jinak, neˇz poˇzaduje pouˇzitá ontologie. 48

Implementace

Bal´ık util

Transformace s kódem 2 slouˇz´ı k pˇrevodu velikosti u ´hlu z formátu u ´hly, minuty, vteˇriny na desetinné ˇc´ıslo. Ve vstupn´ım ˇretˇezci jsou oˇcekávány 3 zlomky. Funkce rozdˇel´ı vstup na nˇekolik podˇretˇezc˚ u za pouˇzit´ı oddˇelovac´ıho znaku mezera a lom´ıtko. Z nich jsou pak ˇcteny celoˇc´ıselné hodnoty a vypoˇctena v´ ysledná hodnota. Pokud nen´ı z´ıskáno 6 podˇretˇezc˚ u nebo pˇri ˇcten´ı cel´ ych ˇc´ısel dojde k chybˇe NumberFormatException, je vrácen prázdn´ y ˇretˇezec. Jelikoˇz Metadata Extractor vrac´ı ˇretˇezce, ve kter´ ych jsou desetinná ˇc´ısla zapsána s desetinnou teˇckou, pˇrevád´ım pˇr´ıpadné ˇceské desetinné ˇcárky na teˇcky pˇred vrácen´ım hodnoty. Tato transformace se pouˇz´ıvá u nˇekolika Exif GPS tag˚ u. Kód 3 pˇrevede sérii cel´ ych ˇc´ısel oddˇelen´ ych mezerou na textov´ y ˇretˇezec tak, ˇze kaˇzdé ˇc´ıslo bude nahrazeno znakem odpov´ıdaj´ıc´ı danému kódu ve v´ ychoz´ım kódován´ı. Mezery nejsou zachovány. Ve vˇetˇsinˇe pˇr´ıpad˚ u um´ı tuto transformaci vykonat jiˇz Metadata Extractor a poskytuje ji jako pˇreloˇzenou hodnotu tagu. Knihovna uvaˇzuje v´ıce kódován´ı a pˇr´ıpadnˇe speciáln´ı charakteristiky ˇretˇezce v závislosti na metadatovém adresáˇri. U GPS tag˚ u ale tuto moˇznost neposkytuje a pouˇz´ıvám zde proto tuto funkci. Transformace ˇc´ıslo 4 pˇrevede racionáln´ı ˇc´ıslo na desetinné. Ze vstupu jsou odstranˇeny vˇsechny p´ısmenné znaky. Návrh programové logiky neumoˇzn ˇuje provést v´ıce neˇz jednu transformaci extrahované hodnoty a v nˇekter´ ych pˇr´ıpadech bylo potˇreba kromˇe pˇrevodu i odstranit text. Naopak odstranˇen´ı znak˚ u v ˇza´dném z pˇr´ıpad˚ u nevad´ı. Proto bylo pˇristoupeno k této variantˇe. Funkce dokáˇze pˇrevést i v´ıce ˇc´ısel v jednom ˇretˇezci. Je ale potˇreba, aby pˇri rozdˇelen´ı na podˇretˇezce jako v tr. 2, byl sud´ y poˇcet prvk˚ u. Pˇri lichém poˇctu je vracen vstupn´ı ˇretˇezec bez p´ısmenn´ ych znak˚ u. Pˇri chybˇe NumberFormatException je vracen prázdn´ y ˇretˇezec. Parametrem transformace je poˇcet desetinn´ ych m´ıst, nejménˇe je vˇsak jedno. V´ ysledn´ y ˇretˇezec pouˇz´ıvá desetinnou teˇcku. Transformace s kódem 5 pˇrevede sérii ˇc´ısel oddˇelen´ ych mezerou na ˇc´ıslo verze takov´ ym zp˚ usobem, ˇze mezery budou odstranˇeny a na pozici oddˇeluj´ıc´ı verzi a podverzi bude vloˇzena teˇcka. Pozice, ve smyslu poˇctu prvk˚ u, po kter´ ych je teˇcka um´ıstˇena, je parametrem transformace. Pˇri chybˇe ˇcten´ı cel´ ych ˇc´ısel, stejnˇe jako pˇri neplatném parametru, je vrácen prázdn´ y ˇretˇezec. Transformace se uplatˇ nuje u Exif tagu s verz´ı interoperability. Transformace 6 je pouˇzita k pˇrevodu hodnoty poˇctu bit˚ u na kaˇzdou sloˇzku do tvaru poˇzadovaného v NEXIF ontologii. Knihovna napˇr´ıklad vrac´ı ˇretˇezec 8 8 8 pokud pro kaˇzdou z barevn´ ych sloˇzek je vymezeno 8 bit˚ u. NEXIF poˇzaduje pouze jedno ˇc´ıslo platné pro vˇsechny sloˇzky. Funkce vrac´ı podˇretˇezec

49

Implementace

Bal´ık util

od zaˇcátku vstupu k prvn´ımu znaku mezera. Tento postup by nebyl korektn´ı pro pˇr´ıpad, kdy kaˇzdá sloˇzka bude m´ıt jin´ y poˇcet bit˚ u. S t´ım jsem se nicménˇe nesetkal a tedy to nepˇredpokládám. Tag v JFIF adresáˇri pouˇz´ıvá jin´ y ˇc´ıseln´ık pro jednotky rozliˇsen´ı neˇz ostatn´ı adresáˇre. Pro pˇrevod na ˇc´ıslo odpov´ıdaj´ıc´ı ostatn´ım slouˇz´ı transformace 8. Jde pouze o inkrementaci ˇc´ısla na vstupu, nebot’ je cel´ y ˇc´ıseln´ık posunut´ y právˇe o jeden prvek. Transformace nekontroluje, zda-li je vstup z platného rozsahu. Kontrola tohoto typu je provádˇena pˇri zápisu hodnoty pomoc´ı kontrolovaného slovn´ıku. Transformaci je tedy moˇzné pouˇz´ıt i k jin´ ym u ´ˇcel˚ um. Transformace 9 pˇridá za kaˇzdé ˇc´ıslo na vstupu ˇretˇezec /100000. Touto formou je ˇreˇsen problém s PNG tagy barevnosti, které jsou uvádˇené jako celá ˇc´ısla po vynásoben´ı ˇc´ıslem 100 000. Je vracen prázdn´ y ˇretˇezec pˇri chybˇe ˇ ˇcten´ı cel´ ych ˇc´ısel. Reˇsen´ı je velmi specifické a tˇeˇzko pouˇzitelné u jiného tagu. Transformace 10 pˇrevád´ı ˇc´ıseln´ıkovou hodnotu PNG tagu s typem barev na hodnotu poˇctu barevn´ ych vzork˚ u v pixelu. PNG pˇripouˇst´ı varianty odst´ıny ˇsedi (0), RGB (2), paletové barvy (3), odst´ıny ˇsedi s pr˚ uhlednost´ı (4), a RGB s pr˚ uhlednost´ı (6). Jsou definovány následuj´ıc´ı pˇrevody: 0 na 1, 2 na 3, 3 na 1, 4 na 2, 6 na 4. Ostatn´ı vstupy jsou pˇrevedeny na prázdn´ y ˇretˇezec. V transformaci 11 je ˇctena celoˇc´ıselná hodnota. Pokud je vˇetˇs´ı neˇz 0, je vrácen ˇretˇezec true. V opaˇcném pˇr´ıpadˇe je vrácen ˇretˇezec false. Pˇri chybˇe ˇcten´ı ˇc´ısla je vrácen prázdn´ y ˇretˇezec. Transformace se pouˇz´ıvá u PNG tag˚ u pˇri urˇcen´ı, zda-li je obraz transparentn´ı a zda-li je pouˇzito prol´ınán´ı (interlace). Dále je pouˇzita u nˇekter´ ych makernote tag˚ u. Transformace ˇc´ıslo 12 slouˇz´ı ke spojen´ı dvou tag˚ u obsahuj´ıc´ıch datum a ˇcas do jedné hodnoty. Datum a ˇcas je rozdˇelen do r˚ uzn´ ych tag˚ u ve formátu IPTC a v Olympus makernote. Pˇri spojován´ı dojde k vloˇzen´ı znaku stˇredn´ık mezi hodnoty, jak bylo popsáno v kapitole 5.2.2. Tento znak je vyuˇzit jako oddˇelovaˇc a kaˇzd´ y podˇretˇezec je pˇreveden funkc´ı z DateUtil tˇr´ıdy na datum. Pokud se pˇrevod podaˇr´ı, jsou data seˇcteny. Souˇcet je pˇreveden na ˇretˇezec a vrácen. V pˇr´ıpadˇe chyby pˇri zpracován´ı je vrácena p˚ uvodn´ı hodnota. To je z d˚ uvodu, ˇze pˇri skládán´ı ˇretˇezce ze dvou tag˚ u, je transformace volána po naˇcten´ı kaˇzdého z tag˚ u a po dokonˇcen´ı spojen´ı. Pˇri vracen´ı prázdného ˇretˇezce jako v pˇredchoz´ıch transformac´ıch by se nikdy nevytvoˇril cel´ y ˇretˇezec. Kódem 13 je volána transformace odstraˇ nuj´ıc´ı p´ısmenné znaky ze vstupn´ıho ˇretˇezce. Pouˇz´ıvá se hlavnˇe u tag˚ u, které je potˇreba z´ıskat z Metadata 50

Implementace

Bal´ık util

Extractoru pˇreloˇzené, ale nen´ı chtˇené, aby ˇretˇezec obsahoval mˇerné jednotky, nebo jiné textové informace. Typické je uˇzit´ı u tag˚ u clonového ˇc´ısla, kde knihovna správnˇe interpretuje data, ale pˇridá pˇred ˇc´ıslo p´ısmeno F. Transformace 14 pˇrevede sérii cel´ ych ˇc´ısel oddˇelen´ ych mezerou na jejich hexadecimáln´ı reprezentaci. Mezery nejsou zachovány. Pˇrij´ımá pouze ˇc´ısla ˇ ısla jsou vˇzdy zapsána dvˇema znaky. Pokud dojde v rozmez´ı 0 aˇz 255. C´ k problému pˇri ˇcten´ı ˇc´ısel je vrácen prázdn´ y ˇretˇezec. Transformace je pouˇzita u Canon tagu obsahuj´ıc´ıho unikátn´ı identifikátor fotografie. Transformac´ı 15 lze pˇrevést textovou hodnotu z tag˚ u popisuj´ıc´ıch pouˇzité digitáln´ı pˇribl´ıˇzen´ı na ˇc´ıslo poˇzadované NEXIF specifikac´ı. Pokud vstup zaˇc´ıná podˇretˇezcem no, obsahuje not used nebo se rovná ˇretˇezci off, je vrácena hodnota 0. Pokud vstupn´ı ˇretˇezec obsahuje unknown, je vrácen prázdn´ y ˇretˇezec. V ostatn´ıch pˇr´ıpadech jsou odstranˇeny p´ısmenné znaky a vrácen zbyl´ y ˇretˇezec, protoˇze knihovna poskytuje hodnoty zvˇetˇsen´ı jako ˇc´ıslo následované p´ısmenem x. Transformace ˇc´ıslo 16 slouˇz´ı k vydˇelen´ı ˇc´ısla na vstupu ˇc´ıslem zadan´ ym v parametru transformace. Chyba pˇri dˇelen´ı, vˇcetnˇe dˇelen´ı nulou, vrac´ı prázdn´ y ˇretˇezec. Poˇcet desetinn´ ych m´ıst je urˇcen v závislosti na hodnotˇe v´ ysledku. Vrácená hodnota obsahuje desetinnou teˇcku. Transformace je pouˇzita u dvou tag˚ u Casio makernote, které pouˇz´ıvaj´ı ˇspatné mˇerné jednotky. Posledn´ı transformace, s kódem 17, poskytuje mechanismus k nadefinován´ı vlastn´ıch popisn´ ych hodnot pro ˇc´ıseln´ıkové kódy. Parametrem funkce je ˇretˇezec obsahuj´ıc´ı textové hodnoty oddˇelené stˇredn´ıkem. Funkce rozdˇel´ı tento ˇretˇezec na podˇretˇezce s t´ım, ˇze prvn´ı odpov´ıdá indexu 0. Je vrácen popisek na indexu, kter´ y je dán vstupn´ı hodnotou. Vrac´ı prázdn´ y ˇretˇezec, pokud vstup nen´ı celé ˇc´ıslo, nebo index neodpov´ıdá ˇza´dnému prvku.

5.4.4

Tˇ r´ıda ExtractorUtil

Tato tˇr´ıda obsahuje ˇctyˇri statické funkce volané tˇr´ıdami extraktor˚ u nebo tˇr´ıdou ExtractorLogic. Pro vˇsechny funkce kromˇe pˇrejmenován´ı uzl˚ u je sestaven unit test. Funkce getMappingDefinition(Individual) slouˇz´ı k naˇcten´ı mapovac´ı definice do instance IndividualData, kterou pak vrac´ı. Funkce iteruje nad vˇsemi vlastnostmi uzlu pˇredaného jako vstupn´ı parametr. Jména vlastnost´ı porov51

Implementace

Bal´ık util

nává s názvy znám´ ych vlastnost´ı mapovac´ı definice. Pˇri shodˇe je objekt vlastnosti pˇreˇcten a zapsán do pˇr´ısluˇsného atributu mapovac´ı instance. Vlastnost popisuj´ıc´ı typ literálu je jedin´ y pˇr´ıpad, kdy je ˇcten´ y objekt nutné zpracovat pˇred zapsán´ım. K zpracován´ı je pouˇzita funkce getExpectedXSDDatatype(String), která pˇrevede textovou definici datového typu na pˇr´ısluˇsnou instanci XSDDatatype a tu pak vrac´ı. Pro lepˇs´ı uˇzivatelskou pˇr´ıvˇetivost a syntaktickou benevolenci netestuji ˇretˇezec na vstupu na rovnost, ale pouze na v´ yskyt specifického podˇretˇezce. V d˚ usledku nezáleˇz´ı na tom, jestli v mapovac´ı ontologii je definován poˇzadovan´ y datov´ y typ jako http://www.w3.org/2001/XMLSchema#string (IRI), xsd:string (prefixová cesta), XSDstring (instance Java tˇr´ıdy) nebo string (název primitivn´ıho datového typu). Funkce je definována pouze pro datové typy xsd:string, xsd:integer, xsd:float, xsd:dateTime a xsd:boolean. Pokud vstup neodpov´ıdá ˇza´dnému z nich, je vrácena hodnota null. Dalˇs´ı funkc´ı je isDefinitionGraphCycle(. . . ) hledaj´ıc´ı cyklus v definici objektov´ ych vlastnost´ı. Parametrem je naˇctená definice mapován´ı tagu a enumeraˇcn´ı hodnota popisuj´ıc´ı vlastnost k prozkoumán´ı. Funkce je definována pouze pro vlastnosti duplicateTo a isAggregatedIn. Testován´ı na v´ yskyt cyklu u definice návaznosti pˇri spojován´ı je provádˇena pˇr´ımo ve funkci concatValue. Jelikoˇz jsou obˇe podporované vlastnosti definované jako funkˇcn´ı, hledán´ı prob´ıhá lineárn´ım pr˚ uchodem grafu od uzlu ze vstupn´ıho parametru pˇres danou vlastnost. Pokud je navˇst´ıven uzel, kter´ y byl navˇst´ıven jiˇz dˇr´ıve, je definice vlastnosti zacyklená a je vrácena pravdivostn´ı hodnota true. Pokud pro procházen´ y uzel nen´ı vlastnost definována, je vrácena hodnota false. Posledn´ı funkce, renameNodes(HashMap<String, Resource>, RDFUtil), slouˇz´ı k pˇrejmenován´ı uzl˚ u na základˇe vlastnost´ı, které jsou pro nˇe definovány. Vstupn´ım parametrem je mapa názv˚ u vytvoˇren´ ych uzl˚ u na jejich instanci a instance RDFUtil pro zapisován´ı do RDF modelu. Funkce pro vˇsechny vytvoˇ ezec ˇrené uzly, kromˇe uzlu obrazového souboru, projde jejich vlastnosti. Retˇ vznikl´ y slouˇcen´ım IRI vlastnosti a textové serializace objektu vloˇz´ı do seznamu. Po pˇreˇcten´ı vˇsech vlastnost´ı je seznam abecednˇe seˇrazen. Uzel je pak pˇrejmenován na název odpov´ıdaj´ıc´ı v´ ystupu SHA-1 hashovac´ı funkce nad seznamem.

52

Implementace

5.5

Vytvoˇrené ontologie

Vytvoˇ ren´ e ontologie

V projektu vyuˇz´ıvám dvˇe vlastn´ı ontologie. Prvn´ı z nich obsahuje definici mapován´ı extrahovan´ ych tag˚ u. Druhou ontologi´ı vytváˇr´ım vlastnosti, které vypl´ yvaj´ı ze zpracovávan´ ych metadat a neexistuj´ı v jiném slovn´ıku ˇci ontologii. RDF/XML serializace obou ontologi´ı jsou na pˇriloˇzeném DVD.

5.5.1

Mapovac´ı ontologie

Definice mapován´ı by jistˇe mohla b´ yt zanesena do zdrojov´ ych kód˚ u programu. Takové ˇreˇsen´ı je ale nepraktické pˇri potˇrebˇe provést zmˇenu, protoˇze je nutné cel´ y projekt znovu zkompilovat. Rozhodl jsem se tedy pro vynesen´ı definice do extern´ıho souboru i za cenu jej´ıho sloˇzitˇejˇs´ıho ˇcten´ı. Ontologie obsahuje instanci tˇr´ıdy ImageMetadata pro vˇsechny metadatové tagy, které jsou definovány v Metadata Extractoru 2.7.2 u souborov´ ych typ˚ u JPEG, PNG a TIFF. Názvy prvk˚ u jsou sloˇzeny ze zkratky názvu adresáˇre, do kterého knihovna tag ˇrad´ı, a hexadecimáln´ıho ˇc´ısla identifikuj´ıc´ı tag. Napˇr´ıklad prvek vztahuj´ıc´ı se k Exif tagu s oznaˇcen´ım modelu zaˇr´ızen´ı má název exifIFD0 0x0110. Aby ˇslo lépe poznat, co prvek popisuje, uvád´ım u kaˇzdé vlastnosti anotac´ı rdfs:label textov´ ym popisek. Pˇredchoz´ı prvek má ych kód˚ u knihovny, popisek TAG MODEL. Popisky jsou z´ıskány ze zdrojov´ konkrétnˇe jde o název konstanty uchovávaj´ıc´ı ˇc´ıslo tagu. Takov´ y popisek mi pˇripadá jako dostateˇcn´ y pro potˇreby ontologie. Prvky mohou definovat mapován´ı pomoc´ı deseti datov´ ych a pˇeti objektov´ ych vlastnost´ı. Jejich uˇzit´ı bylo popsáno v kapitole 5.3. Vlastnosti maj´ı definovanou doménu i obor hodnot. Vˇsechny vlastnosti jsou funkˇcn´ı, tzn. prvek m˚ uˇze m´ıt kaˇzdou vlastnost definovanou maximálnˇe jednou. Pokud by napˇr´ıklad mˇel b´ yt tag zapsán pomoc´ı dvou dalˇs´ıch definic, bude ve vlastnosti prvku uveden odkaz pouze na jednu definici a v té bude odkaz na druhou definici. Kromˇe prvk˚ u odpov´ıdaj´ıc´ıch znám´ ym metadatov´ ym tag˚ um se v ontologii nacház´ı prvky, jejichˇz název zaˇc´ıná slovem duplicate. Jedná se o prvky obsahuj´ıc´ı dalˇs´ı definici mapován´ı k danému tagu. Ty vyuˇz´ıvám v pˇr´ıpadˇe, kdy vlastnost, na kterou je tag mapován, vyˇzaduje v objektu ˇc´ıseln´ıkov´ y kód. Pro takov´ y tag pouˇziji druhé mapován´ı na vlastnost v moj´ı ontologii, která vyuˇz´ıvá kontrolovan´ y slovn´ık. Dalˇs´ımi zvláˇstn´ımi prvky jsou ty, jenˇz obsahuj´ı 53

Implementace


v názvu agg. Jde o definici uzl˚ u, které jsou v nˇekterém z mapován´ı pouˇzity na pozici subjektu v RDF trojici. Napˇr´ıklad gps agg1 je definován jako uzel typu geo:Point, na kter´ y budou dle definic gps 0x0002, gps 0x0004 a gps 0x0006 pˇripojena extrahovaná metadata o zemˇepisné ˇs´ıˇrce, délce a nadmoˇrské v´ yˇsce. V ontologii je zavedena tˇr´ıda DataTransformation, která má definováno 16 instanc´ı. V definici transformace je vˇzdy odkazováno na jednu z instanc´ı. Instance maj´ı definovan´ y pouze ˇc´ıseln´ y kód transformace a nˇekolik anotaˇcn´ıch vlastnost´ı pro popis jejich funkce. Transformace jsou bl´ıˇze popsány v kapitole 5.4.3 zab´ yvaj´ıc´ı se jejich programovou implementac´ı. Pˇri tvorbˇe mapován´ı obrazov´ ych metadat na RDF vlastnosti byly nejprve nalezeny existuj´ıc´ı slovn´ıky ˇreˇs´ıc´ı podobn´ y problém, viz kapitola 3.2. Jako základ byla zvolena NEXIF ontologie, která poskytovala nejv´ıce relevantn´ıch pojm˚ u. U vˇetˇsiny pojm˚ u byl v popisu odkaz na Exif tag, kterému odpov´ıdaj´ı. Následnˇe byly na NEXIF ontologii namapovány i tagy se stejn´ ym v´ yznamem z metadatov´ ych adresáˇr˚ u jin´ ych neˇz Exif. Poté byly v ostatn´ıch ontologi´ıch hledány pojmy vyuˇzitelné pro dosud nenamapované tagy. Po prohledán´ı znám´ ych slovn´ık˚ u jsem pro kaˇzdou definici mapován´ı doplnil poˇzadovan´ y datov´ y typ. V dalˇs´ım kroku se porovnaly pˇreloˇzené a nepˇreloˇzené v´ ystupy Metadata Extraktoru u kaˇzdého tagu a rozhodl jsem o volbˇe v´ ystupu a transformaci. Nakonec se pˇridaly do definice odkazy na uzel, na kter´ y maj´ı b´ yt metadata navázána, pokud to nen´ı uzel obrazu. Ve druhé fázi byla vytvoˇrena ontologie pro tagy, které se nepodaˇrilo namapovat a probˇehlo mapován´ı na tyto tagy. Poté byly opˇet nadefinovány datové typy, typ ˇcteného v´ ystupu z knihovny a metoda transformace. Ve tˇret´ı fázi byly pro nˇekteré tagy mapované na existuj´ıc´ı ontologie vytvoˇreny vlastnosti i v mé ontologii vyuˇz´ıvaj´ıc´ı kontrolované slovn´ıky. Byla doplnˇena definice dan´ ych prvk˚ u, aby odkazovala na dalˇs´ı definici.

5.5.2

Pojmov´ a ontologie

Tato ontologie definuje tˇr´ıdy Image, ICC, Camera a Resolution slouˇz´ıc´ı k vymezen´ı domény definovan´ ych vlastnost´ı. Kromˇe tˇechto tˇr´ıd je definovaná tˇr´ıda CodeList a jej´ı podtˇr´ıdy, jejichˇz instance tvoˇr´ı kontrolované slovn´ıky vybran´ ych vlastnost´ı. Jde o vlastnosti, které v p˚ uvodn´ım navrˇzeném mapován´ı vyˇzaduj´ı ukládat ˇc´ıseln´ıkové kódy. Aby bylo moˇzné zapsat u ´daje i ve tvaru ˇcitelném pro ˇclovˇeka je vytvoˇreno dalˇs´ı mapován´ı na vlastnosti této ontologie. 54

Implementace


Ontologie obsahuje objektové vlastnosti createdWithCamera, hasIccProfile a hasResolution, kter´ ymi lze propojit instanci Image s instancemi ostatn´ıch tˇr´ıd zde definovan´ ych. Vlastnost hasResolution a vlastnosti s n´ı souvisej´ıc´ı jsou zde definovány i pˇresto, ˇze v NEXIF ontologii jsou dostupné. D˚ uvodem je potˇreba vytvoˇrit strukturu, do které p˚ ujde zapsat kombinace hodnot tag˚ u pro rozliˇsen´ı na ose x, y a mˇernou jednotku. V NEXIF jsou vˇsechny vlastnosti vázány pˇr´ımo na uzel obrazového souboru a m˚ uˇze doj´ıt ke konfliktu, pokud je napˇr´ıklad v Exif tagu definována sada hodnot 72, 72, DPI a v makernote bude sada hodnot 1, 1, proporcionálnˇe. Obˇe sady jsou sami o sobˇe správné, ale pˇri jejich mapován´ı na stejnou NEXIF vlastnost se stanou strojovˇe, a v nˇekter´ ych pˇr´ıpadech i pro ˇclovˇeka, nepouˇzitelné. Zaveden´ım tˇr´ıdy Resolution je moˇzné sady hodnot od sebe oddˇelit. Datové vlastnosti jsou rozdˇelené do dvou skupin na spoleˇcné pro v´ıce tag˚ u a odpov´ıdaj´ıc´ı pouze jednomu tagu. Ty, které odpov´ıdaj´ı pouze jednomu tagu, byly skriptem sesb´ırány ze zdrojov´ ych kód˚ u knihovny. Skript naˇcetl popisek odpov´ıdaj´ıc´ı názvu tagu v knihovnˇe a komentáˇr, pokud byl nˇejak´ y nad definic´ı tagu. U vlastnost´ı byla definována doména Image. Spoleˇcné tagy byly vybrány na základˇe anal´ yzy nenamapovan´ ych tag˚ u. Tyto vlastnosti byly vytváˇreny manuálnˇe a maj´ı definovan´ y i obor hodnot a detailnˇejˇs´ı popis v anotaci.

55

6 Diskuze výsledku 6.1

V´ ykonnostn´ı metriky

Plugin jsem otestoval s verz´ı MetaMed 2.0.0-r201504231326. Pouˇzil jsem obrazové soubory, které volnˇe poskytuje autor Metadata Extractoru. Testoval jsem na stroji Intel Core i3-2100 3,1 GHz s 8 GB pamˇet´ı RAM a operaˇcn´ım systému Windows 7, 64 bitová verze. Na stejném stroji jsem poté spustil virtuáln´ı stroj s operaˇcn´ım systémem Debian GNU/Linux 6 s pˇridˇelen´ ymi 4 GB RAM a otestoval plugin i zde. V tabulce 6.1 uvád´ım srovnán´ı namˇeˇren´ ych ˇcas˚ u pˇri zpracován´ı 277 obrazov´ ych soubor˚ u pomoc´ı MetaMedu na stroji s OS Windows a na virtuáln´ım stroji s OS Debian. Dále v posledn´ım sloupci uvád´ım dobu ˇcten´ı stejn´ ych soubor˚ u samotnou knihovnou na stejném stroji. V tabulce je ˇcas prvn´ıho bˇehu a pr˚ umˇern´ y ˇcas tˇr´ı následuj´ıc´ıch bˇeh˚ u. Na obou operaˇcn´ıch systémech dokázal MetaMed zpracovat soubory za pˇribliˇznˇe 16 vteˇrin, coˇz odpov´ıdá pr˚ umˇernˇe 58 ms na jeden soubor. Tato rychlost se jev´ı jako pˇrijatelná, V pˇr´ıpadˇe, kdy soubory jiˇz byly naˇcteny v pamˇeti z pˇredchoz´ıho bˇehu, se doba zpracován´ı na OS Windows zkrátila na polovinu. D˚ uvodem, proˇc tomu tak nebylo i na OS Debian, m˚ uˇze b´ yt omezen´ı dostupné pamˇeti na 4 GB nebo samotná virtualizace. Windows

Debian Metadata Extractor

ˇ prvn´ıho bˇehu Cas 16 376 ms 16 222 ms ˇ Cas ostatn´ıch bˇeh˚ u 8 423 ms 15 882 ms

10 747 ms 909 ms

Tabulka 6.1: Doba zpracován´ı testovac´ı sady programem MetaMed a samotnou extrahovac´ı knihovnou. Statistiky z´ıskané ze zpracován´ı celé obrazové sady jsou v tabulce 6.2. Sleduji poˇcet zapsan´ ych trojic, prázdn´ ych ˇci neznám´ ych hodnot, neexistuj´ıc´ıch definic a prázdn´ ych definic. Neexistuj´ıc´ı definice znamená, ˇze pro dan´ y tag nebyla v ontologii nalezena ˇzádná definice. Prázdná definice znamená, ˇze zámˇernˇe nen´ı definováno mapován´ı pro dan´ y tag a v ontologii je jen prázdná instance. Vysok´ y poˇcet neexistuj´ıc´ıch definic (11,2 %) by mohl indikovat ˇspatnˇe z´ıskanou sadu ˇcten´ ych tag˚ u pˇri tvorbˇe ontologie. Po prozkoumán´ı lad´ıc´ıho logu se ukázalo, ˇze 91 % nenalezen´ ych tag˚ u jsou makernote metadata, která 56

Diskuze výsledku

Výkonnostn´ı metriky

nejsou vyjmenována ve zdrojov´ ych kódech tˇr´ıd *MakernoteDirectory a nen´ı zaruˇceno jejich správné naˇcten´ı. Zbyl´ ych 9 % pˇr´ıpad˚ u jsou Exif tagy, které rovnˇeˇz nejsou k nalezen´ı v pˇr´ısluˇsn´ ych tˇr´ıdách. V tomto ohledu tedy funguje plugin správnˇe. Poˇcet Relativnˇe Zapsané trojice 21786 Prázdná ˇci neznámá hodnota 865 Neexistuj´ıc´ı definice 3013 Prázdná definice 1193

81,1 3,2 11,2 4,4

% % % %

Tabulka 6.2: Statistiky zpracovan´ ych metadat. V ideáln´ım pˇr´ıpadˇe by mˇela testovac´ı sada obsahovat kaˇzd´ y tag alespoˇ n jednou, aby bylo ovˇeˇreno, ˇze je hodnota z tagu správnˇe ˇctena. Naj´ıt sadu obrázk˚ u pokr´ yvaj´ıc´ı vˇsechny tagy je velmi tˇeˇzké. V tabulce 6.3 porovnávám kolik ze vˇsech znám´ ych tag˚ u Metadata Extractoru je obsaˇzeno v pouˇzité testovac´ı sadˇe obrázk˚ u. Ne´ uplné pokryt´ı mi dˇelalo problémy pˇri anal´ yze metadat a hledán´ı moˇznost´ı kam je namapovat. Takové tagy jsem vˇetˇsinou nechal namapované na vlastnost moj´ı ontologie, protoˇze jsem nedokázal odhadnout, v jakém tvaru je bude knihovna poskytovat. Znám´ ych tag˚ u Ovˇeˇren´ ych tag˚ u Pod´ıl ovˇeˇren´ ych Exif Thumbnail XMP JIF Adobe JPEG JFIF Png Exif IFD0 Makernote Exif Interoperability Exif GPS Exif SubIFD ICC Photoshop IPTC

20 15 9 4 4 24 22 722 5 31 111 65 43 77

20 15 9 4 4 23 21 600 4 24 69 36 21 26

100 100 100 100 100 95,8 95,5 83,1 80 77,4 62,2 55,4 48,8 33,8

% % % % % % % % % % % % % %

Tabulka 6.3: Srovnán´ı poˇctu znám´ ych tag˚ u a tag˚ u obsaˇzen´ ych v testovac´ı obrazové sadˇe. 57

Diskuze výsledku

6.2

Srovnán´ı s ˇreˇsen´ım jiných autor˚ u

Srovn´ an´ı s ˇ reˇ sen´ım jin´ ych autor˚ u

Jak jiˇz bylo zm´ınˇeno v kapitole 3.1.4, nen´ı ˇzádn´ y aktivn´ı projekt, kter´ y by se zab´ yval ˇcten´ım obrazov´ ych metadat a jejich zápisem do RDF. Jedin´ y v´ yznamn´ y projekt, Aperture framework, byl v roce 2011 zastaven z d˚ uvodu ztráty zájmu hlavn´ıho v´ yvojáˇre o RDF. Aperture u soubor˚ u JPEG rozpoznává 20 základn´ıch Exif tag˚ u a 3 GPS tagy. M˚ uj plugin definuje mapován´ı 314 tag˚ u na existuj´ıc´ı slovn´ıky, z toho je 107 tag˚ u z Exif Makernote adresáˇre. V tomto ohledu je plugin v´ yrazn´ ym pokrokem, protoˇze zpracovává i dalˇs´ı Exif IFD a metadatové formáty. Nav´ıc pracuje i se soubory TIFF a PNG. Aperture mapuje vˇsechny tagy na vlastnosti ontologie NEXIF. Já také vycház´ım z této ontologie. Spoleˇcnˇe s n´ı dále pouˇz´ıvám Dublin Core, Friend of a Friend, Geo a dalˇs´ı slovn´ıky projektu NEPOMUK. Také jsem vytvoˇril vlastn´ı slovn´ık pro tagy, které nelze pˇriˇradit ˇzádné jiné RDF vlastnosti. Slovn´ık kromˇe pojm˚ u pro jednotlivé tagy definuje i 51 spoleˇcn´ ych pojm˚ u. Jist´ ym zp˚ usobem by za podobn´ y projekt ˇsel oznaˇcit metadatov´ y formát XMP, kter´ y funguje na principu RDF. Dle jeho specifikac´ı a v´ ypisu znám´ ych XMP tag˚ u na stránkách ExifTool bych odhadoval, ˇze sv´ ym rozsahem pˇredˇc´ı moj´ı práci. Pˇrekáˇzkou v uˇz´ıván´ı je vˇsak nemoˇznost z´ıskat serializaci XMP slovn´ıku a ontologi´ı. Pˇri zamˇeˇren´ı se pouze na extrakci obrazov´ ych metadat, je v´ yznamn´ ym nástrojem ExifTool, jehoˇz autorem je Phil Harvey. Nástroj rozeznává v´ıce tag˚ u neˇz mnou pouˇz´ıvan´ y Metadata Extractor.

6.3

Probl´ emy ˇ reˇ sen´ı

Hlavn´ım problémem ˇreˇsen´ı bych oznaˇcil mal´ y poˇcet rozeznávan´ ych XMP tag˚ u. Pouˇzitá knihovna je v tomto ohledu slabá a v budoucnu by stálo za prozkoumán´ı, zda-li by nebylo moˇzné s XMP tagy pracovat jin´ ym zp˚ usobem. Ideáln´ı by bylo vyuˇz´ıt faktu, ˇze se jedná o RDF model a pracovat s n´ım pomoc´ı nástroj˚ u Jena frameworku. Nikde v procesu zpracován´ı z´ıskan´ ych metadat a jejich zapsán´ı do RDF ˇ sen´ı modelu nekontroluji, zda-li vlastnost pouˇzitá pˇri mapován´ı existuje. Reˇ funguje i v pˇr´ıpadˇe, ˇze vlastnost neexistuje v daném slovn´ıku. Uˇzivatel nemá 58

Diskuze výsledku

Problémy ˇreˇsen´ı

zpˇetnou vazbu o pˇr´ıpadné chybˇe vzniklé pˇri upravován´ı ontologické definice mapován´ı. Ovˇeˇrován´ı bˇehem extrakce by cel´ y proces v´ yraznˇe zpomalilo. Vhodnˇejˇs´ı ˇreˇsen´ım by bylo vytvoˇren´ı samostatného nástroje pro kontrolu definice ontologie. V ˇcasov´ ych u ´daj´ıch z Exif adresáˇre nen´ı korektnˇe ˇreˇsena ˇcasová zóna. ˇ sen´ı by U neznám´ ych ˇcasov´ ych pásem pˇredpokládá program GMT+0. Reˇ mohlo spoˇc´ıvat v odhadu ˇcasové zóny dle GPS lokace, nebo pˇreˇcten´ım nˇekterého tagu jiného adresáˇre obsahuj´ıc´ı ˇcasovou znaˇcku a zónu. Hodnoty nˇekter´ ych makernote tag˚ u by mohly b´ yt lépe mapované na existuj´ıc´ı vlastnosti. Bohuˇzel nemám dostatek testovac´ıch soubor˚ u k ovˇeˇren´ı platnosti takového mapován´ı.

59

Z´ avˇ er Téma práce vyvstalo z potˇreby v´ yzkumné skupiny Medic´ınské informaˇcn´ı systémy rozˇs´ıˇrit stávaj´ıc´ı aplikaci MetaMed o moˇznost extrahovat metadata z obrazov´ ych soubor˚ u a zapsat je do RDF modelu. Rozˇs´ıˇren´ı má formu pluginu k aplikaci MetaMed v jazyce Java. Celá definice zp˚ usobu zapsán´ı z´ıskan´ ych hodnot do RDF modelu je uchována v samostatné ontologii pro tento u ´ˇcel navrˇzené. Je vytvoˇrena i dalˇs´ı ontologie definuj´ıc´ı pojmy pro metadata, která neˇslo namapovat na stávaj´ıc´ı ontologie. Práce je ˇclenˇena do ˇsesti ˇca´st´ı. V prvn´ı ˇcásti se zab´ yvám problematikou RDF, ontologiemi a principy sémantického webu. Ve druhé ˇca´sti popisuji obrazové soubory typu JPEG, PNG, TIFF a metadata v nich obsaˇzená. Ve tˇret´ı kapitole jsou pˇredstavené vybrané existuj´ıc´ı nástroje pro práci s obrazov´ ymi metadaty a RDF slovn´ıky, které se tˇechto metadat t´ ykaj´ı. V dalˇs´ı ˇcásti zd˚ uvodˇ nuji v´ ybˇer knihovny vyuˇzité k extrahován´ı metadat ze soubor˚ u. V páté kapitole popisuji implementaci rozˇs´ıˇren´ı pro MetaMed. Na závˇer hodnot´ım v´ ysledné softwarové d´ılo a srovnávám ho s obdobn´ ymi projekty jin´ ych autor˚ u. Vˇsechny body zadán´ı byly v práci splnˇeny a softwarové ˇreˇsen´ı vyhovuje poˇzadavk˚ um kladen´ ym na projekt.

60

Pouˇ zit´ e zkratky EXIF FOAF ICC IFD IIM IPTC IRI JFIF JIF JPEG MIME NEPOMUK NEXIF NIE OWL PNG PSIR RDF RDFS TIFF W3C XMP

Exchangeable Image File Format Friend of a Friend International Color Consortium Image file directory Information Interchange Model International Press Telecommunications Council Internationalized Resource Identifier JPEG File Interchange Format JPEG Interchange Format Joint Photographic Experts Group Multipurpose Internet Mail Extension Networked Environment for Personal, Ontologybased Management of Unified Knowledge NEPOMUK EXIF ontologie NEPOMUK Information Element Web Ontology Language Portable Network Graphics Photoshop Image Resources Resource Description Framework RDF Schema Tagged Image File Format World Wide Web Consortium Extensible metadata platform

61

str. str. str. str. str. str. str. str. str. str. str. str.

13 25 16 13 15 15 3 13 12 12 13 27

str. str. str. str. str. str. str. str. str. str.

27 27 8 17 16 2 6 19 2 14

Literatura [1] SCHREIBER, G. – RAIMOND, Y. RDF 1.1 Primer [online]. 2014. [cit. 22.4.2015]. Dostupné z: http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140624/. [2] W3C Mission [online]. 2015. [cit. 22.4.2015]. Dostupné z: http://www.w3.org/Consortium/mission. [3] DUERST, M. – SUIGNARD, M. RFC 3987: Internationalized Resource Identifiers (IRIs). IETF (January 2005). Dostupné z: http://www.ietf.org/rfc/rfc3987.txt. [4] CYGANIAK, R. – WOOD, D. – LANTHALER, M. RDF 1.1 Concepts and Abstract Syntax [online]. 2014. [cit. 22.4.2015]. Dostupné z: http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/. [5] CHEN, L. et al. Blank Nodes in RDF. Journal of Software. 2012, 7, 9, s. 1993–1999. [6] BERNERS-LEE, T. Linked Data - Design Issue [online]. 2009. [cit. 22.4.2015]. Dostupné z: http://www.w3.org/DesignIssues/LinkedData.html. [7] HITZLER, P. et al. OWL 2 Web Ontology Language Primer (Second Edition) [online]. 2012. [cit. 22.4.2015]. Dostupné z: http://www.w3.org/TR/2012/REC-owl2-primer-20121211/. [8] BRICKLEY, D. – GUHA, R. RDF Schema 1.1 [online]. 2014. [cit. 22.4.2015]. Dostupné z: http://www.w3.org/TR/2014/REC-rdf-schema-20140225/. [9] MAZZOCCHI, S. Closed World vs. Open World: the First Semantic Web Battle [online]. 2005. [cit. 22.4.2015]. Dostupné z: http://www.betaversion.org/~stefano/linotype/news/91/. [10] Raster Graphic Definition [online]. 2015. [cit. 28.4.2015]. Dostupné z: http://techterms.com/definition/rastergraphic. [11] Vector Graphic Definition [online]. 2015. [cit. 28.4.2015]. Dostupné z: http://techterms.com/definition/vectorgraphic.

62

LITERATURA

LITERATURA

[12] MATTHEWS, R. Digital image file types [online]. [cit. 28.4.2015]. Dostupné z: http://users.wfu.edu/matthews/misc/graphics/ formats/formats.html. [13] ISO-IEC, I. 10918. Digital compression and coding of continuous–tone still images. 1992. [14] WALLACE, G. K. The JPEG still picture compression standard. Consumer Electronics, IEEE Transactions on. 1992, 38, 1, s. xviii–xxxiv. [15] ISO-IEC, I. 10918-1. Digital compression and coding of continuous–tone still images. 1992. [16] NHU, T. The Metadata in JPEG files - Exiv2 [online]. 2015. [cit. 28.4.2015]. Dostupné z: http://dev.exiv2.org/projects/ exiv2/wiki/The_Metadata_in_JPEG_files. [17] FREED, N. – BORENSTEIN, N. Multipurpose internet mail extensions (MIME) part two: Media types. Technical report, rfc 2046, November, 1996. [18] HAMILTON, E. JPEG file interchange format. C-Cube Microsystems. 1992. [19] Exchangeable image file format for digital still cameras: Exif Version 2.3 [online]. 2012. [cit. 28.4.2015]. Dostupné z: http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf. [20] HUGGEL, A. Exiv2 - Image metadata library and tools [online]. 2014. [cit. 28.4.2015]. Dostupné z: http://www.exiv2.org/makernote.html. [21] Adobe XMP Specification Part 3: Storage in Files [online]. 2014. [cit. 28.4.2015]. Dostupné z: http: //wwwimages.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/ XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart3.pdf. [22] Extensible Metadata Platform (XMP) Specification: Part 1, Data Model, Serialization, and Core Properties [online]. 2012. [cit. 28.4.2015]. Dostupné z: http: //wwwimages.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/ XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart1.pdf.

63

LITERATURA

LITERATURA

[23] Adobe XMP Specification Part 2: Additional Properties [online]. 2014. [cit. 28.4.2015]. Dostupné z: http: //wwwimages.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/ XMP%20SDK%20Release%20cc-2014-12/XMPSpecificationPart2.pdf. [24] Information Interchange Model Version 4 [online]. 2014. [cit. 28.4.2015]. Dostupné z: http://www.iptc.org/std/IIM/4.2/specification/IIMV4.2.pdf. [25] IIM Schema for XMP [online]. 2008. [cit. 28.4.2015]. Dostupné z: http://www.iptc.org/std/IIM/4.1/specification/ IPTC-IIM-Schema4XMP-1.0-spec_1.pdf. [26] Guidelines for Handling Image Metadata [online]. 2010. [cit. 28.4.2015]. Dostupné z: http://metadataworkinggroup.com/pdf/mwg_guidance.pdf. [27] Adobe Photoshop File Formats Specification [online]. 2013. [cit. 28.4.2015]. Dostupné z: http: //www.adobe.com/devnet-apps/photoshop/fileformatashtml/. [28] Image technology colour management — Architecture, profile format, and data structure [online]. 2010. [cit. 28.4.2015]. Dostupné z: http://www.color.org/specification/ICC1v43_2010-12.pdf. [29] Portable Network Graphics (PNG) Specification (Second Edition) [online]. 2003. [cit. 28.4.2015]. Dostupné z: http://www.w3.org/TR/2003/REC-PNG-20031110/. [30] RANDERS-PEHRSON, G. Converting TIFF/EP or Exif files to and from the PNG format (Draft 0.20, December 20, 2000) [online]. 2000. [cit. 28.4.2015]. Dostupné z: http://pmt.sourceforge.net/exif/drafts/history/d020.html. [31] TIFF Revision 6.0 [online]. 1992. [cit. 28.4.2015]. Dostupné z: http: //partners.adobe.com/public/developer/en/tiff/TIFF6.pdf. [32] HUGGEL, A. Exiv2 - Image metadata library and tools [online]. 2014. [cit. 30.4.2015]. Dostupné z: http://www.exiv2.org/. [33] HARVEY, P. ExifTool by Phil Harvey [online]. 2015. [cit. 30.4.2015]. Dostupné z: http://owl.phy.queensu.ca/~phil/exiftool/.

64

LITERATURA

LITERATURA

[34] NOAKES, D. drewnoakes/metadata-extractor · GitHub [online]. 2015. [cit. 30.4.2015]. Dostupné z: https://github.com/drewnoakes/metadata-extractor. [35] Aperture Framework [online]. 2015. [cit. 30.4.2015]. Dostupné z: http://aperture.sourceforge.net/. [36] MYLKA, A. Aperture / Feature Requests / #118 Advice please on extracting embedded files from RTF docs [online]. 2014. [cit. 30.4.2015]. Dostupné z: http: //sourceforge.net/p/aperture/feature-requests/118/#e875. [37] DCMI Metadata Terms [online]. 2012. [cit. 30.4.2015]. Dostupné z: http://dublincore.org/documents/2012/06/14/dcmi-terms/. [38] BRICKLEY, D. – MILLER, L. FOAF Vocabulary Specification 0.99 [online]. 2014. [cit. 30.4.2015]. Dostupné z: http://xmlns.com/foaf/spec/20140114.html. [39] KANZAKI, M. Exif data description vocabulary [online]. 2007. [cit. 30.4.2015]. Dostupné z: http://www.kanzaki.com/ns/exif. [40] MYLKA, A. et al. Nepomuk Information Element Ontology (NIE) [online]. 2012. [cit. 30.4.2015]. Dostupné z: http://www.semanticdesktop.org/ontologies/2007/01/19/nie/. [41] MYLKA, A. et al. Nepomuk File Ontology (NFO) [online]. 2013. [cit. 30.4.2015]. Dostupné z: http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/. [42] MYLKA, A. et al. Nepomuk EXIF Ontology (NEXIF) [online]. 2012. [cit. 30.4.2015]. Dostupné z: http: //www.semanticdesktop.org/ontologies/2007/05/10/nexif/. [43] BRICKLEY, D. W3C Semantic Web Interest Group: Basic Geo (WGS84 lat/long) Vocabulary [online]. 2006. [cit. 30.4.2015]. Dostupné z: http://www.w3.org/2003/01/geo/.

65

Pˇ r´ılohy Struktura pˇ riloˇ zen´ eho DVD Na pˇriloˇzen´ım DVD jsou následuj´ıc´ı sloˇzky a soubory: • latex obsahuj´ıc´ı zdrojové kódy dokumentace. • MetaMed obsahuj´ıc´ı aplikaci MetaMed s pluginem pro zpracován´ı metadat z obrazov´ ych soubor˚ u. Ve sloˇzce jsou tˇri .bat soubory slouˇz´ıc´ı k ukázce práce MetaMedu a extraktor˚ u. • metamed-extractor-image se zdrojov´ ymi kódy pluginu ke zpracován´ı metadat obrazov´ ych soubor˚ u. • srovnani obsahuj´ıc´ı obrazové soubory, kter´ ymi byla testována schopnost nástroj˚ u pracovat s obrazov´ ymi metadaty v kapitole 4.2. Pro kaˇzd´ y nástroj je vytvoˇrena sloˇzka se seznamy nalezen´ ych metadat v jednotliv´ ych souborech. V adresáˇri je tabulka se zaznamenan´ ymi poˇcty z´ıskan´ ych metadat. • dip.pdf s textem diplomové práce.

V´ ypis nalezen´ ych metadat v souboru Sanyo SR662.jpg knihovnou Metadata Extractor. [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif [ Exif

IFD0 IFD0 IFD0 IFD0 IFD0 IFD0 IFD0 IFD0 IFD0 IFD0 SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD SubIFD

0 x010e ] Image Description = SANYO DIGITAL CAMERA 0 x010f ] Make = SANYO Electric Co . , Ltd . 0 x0110 ] Model = SR662 0 x0112 ] Orientation = Top , left side ( Horizontal / normal ) 0 x011a ] X Resolution = 72 dots per inch 0 x011b ] Y Resolution = 72 dots per inch 0 x0128 ] Resolution Unit = Inch 0 x0131 ] Software = V662U -71 0 x0132 ] Date / Time = 2001 :09:15 18 :11:27 0 x0213 ] YCbCr Positioning = Datum point - 0 x829a ] Exposure Time = 0.25 sec - 0 x829d ] F - Number = F2 .8 - 0 x9000 ] Exif Version = 2.00 - 0 x9003 ] Date / Time Original = 2001 :09:15 18 :11:27 - 0 x9004 ] Date / Time Digitized = 2001 :09:15 18 :11:27 - 0 x9101 ] Components Configuration = YCbCr - 0 x9102 ] Compressed Bits Per Pixel = 3.5 bits / pixel - 0 x9204 ] Exposure Bias Value = 0 EV - 0 x9205 ] Max Aperture Value = F2 .8 - 0 x9207 ] Metering Mode = Multi - segment - 0 x9208 ] White Balance = Unknown - 0 x9209 ] Flash = Flash did not fire - 0 x920a ] Focal Length = 6.0 mm - 0 xa000 ] FlashPix Version = 1.00 - 0 xa001 ] Color Space = Undefined - 0 xa002 ] Exif Image Width = 1024 pixels - 0 xa003 ] Exif Image Height = 768 pixels - 0 xa004 ] Related Sound File = - 0 xa300 ] File Source = Digital Still Camera ( DSC )

[ Exif [ Exif [ Exif [ Exif [ Exif [ Exif

Thumbnail Thumbnail Thumbnail Thumbnail Thumbnail Thumbnail

-

0 x0103 ] 0 x011a ] 0 x011b ] 0 x0128 ] 0 x0201 ] 0 x0202 ]

Thumbnail Compression = JPEG ( old - style ) X Resolution = 72 dots per inch Y Resolution = 72 dots per inch Resolution Unit = Inch Thumbnail Offset = 878 bytes Thumbnail Length = 4562 bytes

[ File - 0 x0001 ] File Name = Sanyo SR662 . jpg [ File - 0 x0002 ] File Size = 18526 bytes [ File - 0 x0003 ] File Modified Date = Sun Jan 27 02 :31:16 GMT 2013 [ JFIF [ JFIF [ JFIF [ JFIF

-

0 x0005 ] 0 x0007 ] 0 x0008 ] 0 x000a ]

Version = 1.1 Resolution Units = inch X Resolution = 72 dots Y Resolution = 72 dots

[ JPEG [ JPEG [ JPEG [ JPEG [ JPEG [ JPEG [ JPEG [ JPEG

-

0 xfffffffd ] Compression Type = Baseline 0 x0000 ] Data Precision = 8 bits 0 x0001 ] Image Height = 225 pixels 0 x0003 ] Image Width = 300 pixels 0 x0005 ] Number of Components = 3 0 x0006 ] Component 1 = Y component: Quantization table 0 , Sampling factors 1 horiz /1 vert 0 x0007 ] Component 2 = Cb component: Quantization table 1 , Sampling factors 1 horiz /1 vert 0 x0008 ] Component 3 = Cr component: Quantization table 1 , Sampling factors 1 horiz /1 vert

[ Sanyo Makernote - 0 x0200 ] Special Mode = 33554691 1114897 3502768191 [ Sanyo Makernote - 0 x0201 ] Sanyo Quality = Normal / Medium High [ Sanyo Makernote - 0 x0f00 ] Data Dump = [20 longs ]

V´ ypis nalezen´ ych metadat v souboru Sanyo SR662.jpg knihovnou Exiv2. Exif . Image . Ima g eD e sc r ip t io n Exif . Image . Make Exif . Image . Model Exif . Image . Orientation Exif . Image . XResolution Exif . Image . YResolution Exif . Image . ResolutionUnit Exif . Image . Software Exif . Image . DateTime Exif . Image . YCb C rP o si t io n in g Exif . Image . ExifTag Exif . Photo . ExposureTime Exif . Photo . FNumber Exif . Photo . ExifVersion Exif . Photo . Dat e Ti m eO r ig i na l Exif . Photo . Da t e T i m e D i g i t i z e d Exif . Photo . C o m p o n e n t s C o n f i g u r a t i o n Exif . Photo . C o m p r e s s e d B i t s P e r P i x e l Exif . Photo . Ex p o s u r e B i a s V a l u e Exif . Photo . Max A pe r tu r eV a lu e Exif . Photo . MeteringMode Exif . Photo . LightSource Exif . Photo . Flash Exif . Photo . FocalLength Exif . Photo . MakerNote Exif . Photo . Flas hpix Ver sion Exif . Photo . ColorSpace Exif . Photo . Pixe lXDi men sion Exif . Photo . Pixe lYDi men sion Exif . Photo . Rel a te d So u nd F il e Exif . Photo . FileSource Exif . Thumbnail . Compression Exif . Thumbnail . XResolution Exif . Thumbnail . YResolution Exif . Thumbnail . ResolutionUnit Exif . Thumbnail . J P E G I n t e r c h a n g e F o r m a t Exif . Thumbnail . J P E G I n t e r c h a n g e F o r m a t L e n g t h

Ascii 21 Ascii 24 Ascii 6 Short 1 Rational 1 Rational 1 Short 1 Ascii 9 Ascii 20 Short 1 Long 1 Rational 1 Rational 1 Undefined 4 Ascii 20 Ascii 20 Undefined 4 Rational 1 SRational 1 Rational 1 Short 1 Short 1 Short 1 Rational 1 Undefined 142 Undefined 4 Short 1 Long 1 Long 1 Ascii 13 Undefined 1 Short 1 Rational 1 Rational 1 Short 1 Long 1 Long 1

SANYO DIGITAL CAMERA SANYO Electric Co . , Ltd . SR662 top , left 72 72 inch V662U -71 2001 :09:15 18 :11:27 Co - sited 294 1/4 s F2 .8 2.00 2001 :09:15 18 :11:27 2001 :09:15 18 :11:27 YCbCr 3.5 0 EV F2 .8 Multi - segment Unknown No flash 6.0 mm ( Binary value suppressed ) 1.00 Uncalibrated 1024 768 Digital still camera JPEG ( old - style ) 72 72 inch 878 4562

V´ ypis nalezen´ ych metadat v souboru Sanyo SR662.jpg knihovnou Exiftool. ExifTool Version Number File Name Directory File Size File Modification Date / Time File Access Date / Time File Creation Date / Time File Permissions File Type File Type Extension MIME Type JFIF Version Exif Byte Order Image Description

: : : : : : : : : : : : : :

9.93 Sanyo SR662 . jpg . 18 kB 2015 :02:15 14 :26:23 +01 :00 2015 :05:13 01 :06:26 +01 :00 2015 :05:13 01 :06:26 +01 :00 rw - rw - rw JPEG jpg image / jpeg 1.01 Little - endian ( Intel , II ) SANYO DIGITAL CAMERA

Make Camera Model Name Orientation X Resolution Y Resolution Resolution Unit Software Modify Date Y Cb Cr Positioning Exposure Time F Number Exif Version Date / Time Original Create Date Components Configuration Compressed Bits Per Pixel Exposure Compensation Max Aperture Value Metering Mode Light Source Flash Focal Length Special Mode Sanyo Quality Data Dump Flashpix Version Color Space Exif Image Width Exif Image Height Related Sound File File Source Compression Thumbnail Offset Thumbnail Length Image Width Image Height Encoding Process Bits Per Sample Color Components Y Cb Cr Sub Sampling Aperture Image Size Megapixels Shutter Speed Thumbnail Image Focal Length

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

SANYO Electric Co . , Ltd . SR662 Horizontal ( normal ) 72 72 inches V662U -71 2001 :09:15 18 :11:27 Co - sited 1/4 2.8 0200 2001 :09:15 18 :11:27 2001 :09:15 18 :11:27 Y , Cb , Cr , 3.5 0 2.8 Multi - segment Unknown No Flash 6.0 mm 0 0 0 Normal / Medium High ( Binary data 152 bytes , use -b option to extract ) 0100 Uncalibrated 1024 768 Digital Camera JPEG ( old - style ) 908 4562 300 225 Baseline DCT , Huffman coding 8 3 YCbCr4:4:4 (1 1) 2.8 300 x225 0.068 1/4 ( Binary data 4562 bytes , use -b option to extract ) 6.0 mm

V´ ypis nalezen´ ych metadat v souboru Sanyo SR662.jpg frameworkem Aperture. < file: / C: / Users / Keiras / Desktop / New %20 folder %20(6) / Sanyo %20 SR662 . jpg > < http: // www . se man ticd eskt op . org / ontologies /2007/05/10/ nexif # height > " 768 " ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # width > " 1024 " ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # e x p o s u r e B i a s V a l u e > " 0 " ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # exposureTime > " 0.25 " ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # flash > " 0 " ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # fl ashp ixVe rsio n > " 48 49 48 48 " ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # make > " SANYO Electric Co . , Ltd ." ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # dateTime > " 2001 -09 -15 T18:11:27 .000+01 :00 " ^^ < http: // www . w3 . org /2001/ XMLSchema # dateTime > ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # d a t e T i m e D i g i t i z e d > " 2001 -09 -15 T18:11:27 .000+01 :00 " ^^ < http: // www . w3 . org /2001/ XMLSchema # dateTime > ; < http: // www . sema ntic des ktop . org / ontologies /2007/05/10/ nexif # d a te T im e Or i gi n al > " 2001 -09 -15 T18:11:27 .000+01 :00 " ^^ < http: // www . w3 . org /2001/ XMLSchema # dateTime > ; a < http: // www . s eman tic desk top . org / ontologies /2007/05/10/ nexif # Photo > .

Zápis nalezen´ ych metadat v souboru Sanyo SR662.jpg do RDF modelu pomoc´ı MetaMed aplikace obsahuj´ıc´ı m˚ uj plugin. @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix @prefix

mre: nihss: mreid: rdfs: dscl: fslmre: rdf: mreb: ds: dc: geo: foaf: nfo: acl: nie: dc10: image: dcm: fsl: xsd: owl: skos: icd10: nexif:

< http: // mre . kiv . zcu . cz / ontology / mre . owl # > . < http: // mre . kiv . zcu . cz / ontology / nihss . owl # > . < http: // mre . kiv . zcu . cz / id / > . < http: // www . w3 . org /2000/01/ rdf - schema # > . < http: // mre . kiv . zcu . cz / ontology / dscl . owl # > . < http: // mre . kiv . zcu . cz / id / fresnel # > . < http: // www . w3 . org /1999/02/22 - rdf - syntax - ns # > . < http: // mre . kiv . zcu . cz / > . < http: // mre . kiv . zcu . cz / ontology / dasta . owl # > . < http: // purl . org / dc / elements /1.1/ > . < http: // www . w3 . org /2003/01/ geo / wgs84_pos # > . < http: // xmlns . com / foaf /0.1/ > . < http: // www . sema ntic des ktop . org / ontologies /2007/03/22/ nfo # > . < http: // www . w3 . org / ns / auth / acl > . < http: // www . sema ntic des ktop . org / ontologies /2007/01/19/ nie # > . < http: // purl . org / dc / elements /1.0/ > . < http: // mre . kiv . zcu . cz / ontology / image . owl # > . < http: // mre . kiv . zcu . cz / ontology / dicom . owl # > . < http: // www . w3 . org /2004/09/ fresnel # > . < http: // www . w3 . org /2001/ XMLSchema # > . < http: // www . w3 . org /2002/07/ owl # > . < http: // www . w3 . org /2004/02/ skos / core # > . < http: // purl . bioontology . org / ontology / ICD10 / > . < http: // www . se mant icde skto p . org / ontologies /2007/05/10/ nexif # > .

< http: // mre . kiv . zcu . cz / id / JPEG /39 c 0 2 b d 1 7 3 5 f b 8 a a d f a 1 7 8 e f 6 4 7 8 c 7 6 8 1 4 6 d 9 5 a 4 > i ma g e: f il e So u rc e i m a g e : f i l e S o u r c e _ 3 ; i m a g e : h a s R e s o l u t i o n < http: // mre . kiv . zcu . cz / id /870769 a 0 d d 5 5 0 8 5 9 6 f f c f 1 8 9 7 8 5 e 7 0 3 f 4 5 1 9 7 7 a 1 > ; i m a g e : i m a g e Q u a l i t y " Normal / Medium High " ^^ xsd:string ; i m a g e :j f i f _ 0 x 0 0 0 5 " 1.1 " ^^ xsd:float ; i m a g e :j p e g _ 0 x 0 0 0 6 " Y component: Quantization table 0 , Sampling factors 1 horiz /1 vert " ^^ xsd:string ;

i m a g e :j p e g _ 0 x 0 0 0 7 " Cb component: Quantization table 1 , Sampling factors 1 horiz /1 vert " ^^ xsd:string ; i m a g e :j p e g _ 0 x 0 0 0 8 " Cr component: Quantization table 1 , Sampling factors 1 horiz /1 vert " ^^ xsd:string ; i m a g e : j p e g _ 0 x f f f f f f f d " Baseline " ^^ xsd:string ; i m a g e :o r i e n t a t i o n i m a g e : o r i e n t a t i o n _ 1 ; image:yCbCrPositioning image:yCbCrPositioning_2 ; mre:filePath " single - image \\ Sanyo SR662 . jpg " ; n f o : f i l e L a s t M o d i f i e d " 2015 -02 -15 T14:26:23 " ^^ xsd:dateTime ; nfo:fileName " Sanyo SR662 . jpg " ; nfo:fileSize " 18526 " ; nfo:hasHash < http: // mre . kiv . zcu . cz / id /597 f 8 3 0 a 9 6 9 4 5 d b 9 5 e c 5 3 2 f 8 5 c 2 6 b f f 0 d d 5 e e e a 6 > ; nexif:bitsPerSample 8 ; n e x i f : c o m p o n e n t s C o n f i g u r a t i o n " YCbCr " ^^ xsd:string ; n e x i f : c o m p r e s s e d B i t s P e r P i x e l " 3.5 " ^^ xsd:float ; nexif:dateTime " 2001 -09 -15 T18:11:27 " ^^ xsd:dateTime ; n e x i f : d a t e T i m e D i g i t i z e d " 2001 -09 -15 T18:11:27 " ^^ xsd:dateTime ; n e x i f : d a t e T i m e O r i g i n a l " 2001 -09 -15 T18:11:27 " ^^ xsd:dateTime ; n e x i f :e x i f V e r s i o n " 2.0 " ^^ xsd:float ; nexif:exposureBiasValue 0 ; n e x i f : e x p o s u r e T i m e " 0.25 " ^^ xsd:float ; nexif:fNumber " 2.8 " ^^ xsd:float ; n ex i f: f il e So u rc e 3 ; nexif:flash " Flash did not fire " ^^ xsd:string ; n e x i f : f l a s h p i x V e r s i o n " 1.0 " ^^ xsd:float ; n e x i f :f o c a l L e n g t h 6 ; n e x i f : i m a g e D e s c r i p t i o n " SANYO DIGITAL CAMERA " ^^ xsd:string ; n e x i f :i m a g e L e n g t h 300 ; n ex i f: i ma g eW i dt h 225 ; nexif:make " SANYO Electric Co . , Ltd . " ^^ xsd:string ; nexif:maxApertureValue 3 ; n e x i f : m e t e r i n g M o d e " Multi - segment " ^^ xsd:string ; nexif:model " SR662 " ^^ xsd:string ; n e x i f :o r i e n t a t i o n 1 ; n e x i f : p i x e l X D i m e n s i o n 1024 ; n e x i f : p i x e l Y D i m e n s i o n 768 ; nexif:resolutionUnit 2 ; nexif:samplesPerPixel 3 ; nexif:software " V662U -71 " ^^ xsd:string ; n e x i f :x R e s o l u t i o n 72 ; nexif:yCbCrPositioning 2 ; n e x i f :y R e s o l u t i o n 72 ; foaf:thumbnail < http: // mre . kiv . zcu . cz / id /4311 d 6 a 4 6 d c 1 d f 9 4 6 e e 9 1 5 9 d 9 5 1 8 f 8 a e 5 7 e a 3 a 3 7 > . < http: // mre . kiv . zcu . cz / id /4311 d 6 a 4 6 d c 1 d f 9 4 6 e e 9 1 5 9 d 9 5 1 8 f 8 a e 5 7 e a 3 a 3 7 > a foaf:Image ; i m a g e :c o m p r e s s i o n i m a g e : c o m p r e s s i o n _ 6 ; image:resolutionUnit image:resolutionUnit_2 ; n e x i f :c o m p r e s s i o n 6 ; n e x i f : j p e g I n t e r c h a n g e F o r m a t 878 ; n e x i f : j p e g I n t e r c h a n g e F o r m a t L e n g t h 4562 ; nexif:resolutionUnit 2 ; n e x i f : x R e s o l u t i o n 72 ; n e x i f : y R e s o l u t i o n 72 . < http: // mre . kiv . zcu . cz / id /597 f 8 3 0 a 9 6 9 4 5 d b 9 5 e c 5 3 2 f 8 5 c 2 6 b f f 0 d d 5 e e e a 6 > a nfo:FileHash ; n f o : h a s h A l g o r i t h m " SHA1 " ; nfo:hashValue " c 8 b e 1 a 9 2 d c e 8 3 4 7 e 0 5 4 7 f 0 a 1 3 f 5 4 2 a 8 6 d 6 b 8 3 4 0 9 " . mreid:e6180e894cda9a9f377fbe63ae2858030c449cfa a mre:Dataset ;

mre:hasData < http: // mre . kiv . zcu . cz / id / JPEG /39 c 0 2 b d 1 7 3 5 f b 8 a a d f a 1 7 8 e f 6 4 7 8 c 7 6 8 1 4 6 d 9 5 a 4 > ; m r e : h as D a t a S o u r c e < http: // mre . kiv . zcu . cz / id /50 d 8 b 4 a 9 4 1 c 2 6 b 8 9 4 8 2 c 9 4 a b 3 2 4 b 5 a 2 7 4 f 9 c e d 6 6 > ; dc:title " unknown 2015 -02 -15 " . < http: // mre . kiv . zcu . cz / id /50 d 8 b 4 a 9 4 1 c 2 6 b 8 9 4 8 2 c 9 4 a b 3 2 4 b 5 a 2 7 4 f 9 c e d 6 6 > a mre:DataSource ; dc:title " unknown " . < http: // mre . kiv . zcu . cz / id /870769 a 0 d d 5 5 0 8 5 9 6 f f c f 1 8 9 7 8 5 e 7 0 3 f 4 5 1 9 7 7 a 1 > a i ma g e: R es o lu t io n ; image:resolutionUnit image:resolutionUnit_2 ; i m a g e :x R e s o l u t i o n 72 ; i m a g e :y R e s o l u t i o n 72 .

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. z heterogenních dat

Recommend Documents