search

LIBCAS / ARCLib

ARCLib – komplexní řešení pro dlouhodobou archivaci digitálních (knihovních) sbírek
GNU General Public License v3.0
4 stars 1 forks source link

Revize agregovaných elementu ARCLib XML. #97

Closed yantom closed 3 years ago

yantom commented 4 years ago

Všiml jsem si že některé agregace v rámci SIP profilu neprobíhají korektně. Příklad - SIP s n AMDSEC soubory. V některém (jednom) AMD XML změnit scannerModelSerialNo. Tato změna je korektně agregovaná v elementech ARCLib:ImageCaptureInformation, kde je scannerModelSerialNo součástí klíče pro seskupení, ale např. v elementu ARCLib:eventAgents se již projeví chyba - v agregujícím záznamu do kterého by nové scannerModelSerialNo spadlo je buď stále původní hodnota, nebo je zde naopak nová hodnota (nejspíš se bere hodnota z 1. AMD souboru v pořadí), v obou případěch je ale počet událostí n, což je nekorektní, protože n-1 událostí bylo skenováno skenerem s jiným sériovým číslem.

Klíčem je myšlena množina atributů jejichž každá unikátní kombinace znamená jeden agregující záznam. Momentálně je v sekci ARCLib:eventAgents klíčem množina {premis:linkingAgentIdentifierValue, premis:eventType, premisEventDatetime (přesnost pouze na den)}, tedy pro každou unikátní kombinaci agenta, typu události a dne je vygenerován agregovaný element .

Je otázka jak toto řešit, napadá nás a) mít neklíčový cílový element v agregačním záznamu opakovatelný b) zvážit zda jsou dané neklíčové elementy v daném agregačním záznamu třeba a pokud ano, udělat je klíčové, pokud ne - odebrat c) změnit strukturu

Tento issue řeší neklíčové atributy v agregovaných elementech, podobný problém je otevřen v #90 , ten ale řeší něco jiného - možnosti opakování klíčového atributu.

godnat commented 4 years ago

Asi možnost b, jestli to chápu správně. Problém na který se výše naráží (Arclib:eventAgents) je asi ten, že jsme se tam nyní pokusili dát víc klíčových elementů, klíčová je událost i agent. Pomohlo by tedy, kdyby se oddělili, tj. kdyby se každý seskupoval ve své vlastní sekci, tj. třeba události do Arclib:eventsAgent a agenti do ARCLIB_002?

Pro vyhledávání je důležité dokázat najít soubory, které provedl určitý v agent v určitém časovém rozmezí, zdrojové SIP balíčky tyto informace obsahují ale asi ne tak šikovně pro tu agregaci. Ve zdrojový balíčcích je událost a k ní je uveden čas události a odkaz na agenta. V sekci pro agenty je uveden název agenta ale nikoliv čas kdy událost provedl. Tj. je otázka zda nějak komplikovaně do agregovaných záznamů spojovat agenta a čas nebo spíš jen, dle mého názoru jednodušeji vzít udaje z událost a vzít udaje z agenta, včetně vzájemných odkazů, takže i v ArclibXML budou propojení přes odkazy.

Tj. mohla by se část údajů přesunout do ARCLIB_002, tj informace o agentovi. Aktuálně je tam ID agenta z PREMISu a počet souborů, ted by se k tomu přidalo z balíčků SIP: premis:agentName a premis:agentIdentifier (agentIdentifierValue už tam je, tak jen by se přidalo agentIdentifierType).

Pak v sekci s událostmi seskupit dle typu události a času na den a v sekci s agenty seskupit dle agentů (agentName)

godnat commented 4 years ago

V případě extrakce technických metadat se většina částí tvoří dobře, zaznamenají se všechny udaje v metadatech, i když je třeba část obrazů vytvořená jinak.

Jediný problém se zdá být s částí ARCLIB_003, jak je uvedeno výše a důvod je zřejmě také zmíněn výše, tj. že máme zájem zachytit události i agenty v jednom, což asi ne dobře funguje. Snaha byla zachovat v Arclib XML nějaké propojení, které je v původních metadatových souborech, ale toto propojení není v ARClib XML zřejmě třeba. Arclib XML-extrahovaná metadata mají sloužit hlavně pro vyhledávání, pro vztahy mezi událostmi, objekty, agenty by se uživatel měl pak už podívat do balíčku. Stačí že například balíček vyhledá dle uvedeného skeneru, softwaru apod.

Závěr pro issue za mě:

Zdá se úprava by mohla být následující:

  1. Část ARCLIB__002 působí nadbytečně (zde byla též snaha zřejmě prolinkovat udaje v ArclibXML, ale nenašla jsem zdroj této informace), nahradí se např. informacemi o agentech. Informace sem se budou extrahovat způsobem, jako je to v ARCLIB_001, ARCLIB_004, tj. že se zaznamená z původního balíčku úplně vše a seskupí dle jména a času.

  2. ArcLIB_003 zde zůstane jen informace o událostech. Tj. skoro jako doposud (vypadá že funguje podobně jako extrahování a seskupování v ARCLIB_001 a ARCLIB_004).

(Ohledně událostí se v ARCLIB_003 ukazuje jedna nepříjemnost, že se spojí události, které mají stejný čas i název, i když se nejdna o stejnou událost uplne—jednou je to vznik obrazů podruhé vznik výstupů z OCR, což znamená že se nezaznamená aplikace použitá při OCR, vyřeší se rozdělením agentů a událostí do různých sekcí. Otázka pro řešitelský tým je, jestli je nutné extrahovat ze SIP události do Arclib XML, jestli se podle nich bude vyhledávat, jestli nestačí jen použití agenti)

  1. Do Arclib XML namapovat i údaje z mix:ScannerModel a mix:ScanningSystemSoftware to zřejmě mezi agenty (do ARCLIB_002), protože to je agent a měl by správně být jako agent popsán ale nebývá. Viz issue https://github.com/LIBCAS/ARCLib/issues/89 myslím, že jsme to na minulé schůzce odsouhlasili
ZdenekVasek commented 3 years ago

K otázce extrakce událsotí a agentů - u popsané situace se domnívám, že extrakce jen agentů by měla být dostačující.

yantom commented 3 years ago

To co popisujete: "Ohledně událostí se v ARCLIB_003 ukazuje jedna nepříjemnost, že se spojí události, které mají stejný čas i název, i když se nejdna o stejnou událost uplne—jednou je to vznik obrazů podruhé vznik výstupů z OCR" lze pěkně použít na ilustraci problému grupování. Kdyby pro nás byla informace o tom zda se jedná o VZNIK nebo OCR podstatná a existovala v nějakém elementu, např. poznámce, a chtěli bychom ji přidat do eventAgent, musela by být buď součástí klíče (což by znamenalo že by byl pro OCR i pro VZNIK samostatný eventAgent záznam) nebo by musel v eventAgent existovat vícenásobný element pro poznámky, např. <ARCLib:eventsNotes><ARCLib:eventNote>vznik</ARCLib:eventNote><ARCLib:eventNote>ocr</ARCLib:eventNote></ARCLib:eventsNotes>, nebo by muselo dojít k jiné změně struktury. Nicméně z otázky kterou pokládáte, z komentáře pana Vaška a z toho co jsem pochopil na minulé schůzi chceme jít cestou eventAgents úplně smazat a mít pouze sekci agents, která nahradí současné ARCLIB_002 u kterých budeme evidovat počet souborů a datum kdy byl daný agent řekněme aktivní - zapojen v některé události.

Dle návrhu by zde měli být zapsáni agenti z premis:agent + další agenti kteří v přemis:agent nejsou a to z mix:ScannerModel a mix:ScanningSystemSoftware. Ve vzorovém balíčku na kterém probíhá vývoj data z mix:ScanningSystemSoftware v premis:agent skutečně nejsou, avšak data z mix:ScannerModel zde jsou. Opravdu máme brát v potaz i mix:ScannerModel?

Ve vzorovém balíčku máme tedy na jeden konkrétní objekt navázány tyto vstupy:

<premis:agent> 
    <premis:agentIdentifier> 
      <premis:agentIdentifierType>NK_AgentID</premis:agentIdentifierType>  
      <premis:agentIdentifierValue>DL 3003-flatData</premis:agentIdentifierValue> 
    </premis:agentIdentifier>  
    <premis:agentName>DL 3003-DL 3003</premis:agentName>  
    <premis:agentType>software</premis:agentType>  
</premis:agent> 
navázano s objektem v premis:event
<premis:event> 
<premis:eventIdentifier> 
  <premis:eventIdentifierType>NK_eventID</premis:eventIdentifierType>  
  <premis:eventIdentifierValue>flatData_001</premis:eventIdentifierValue> 
</premis:eventIdentifier>  
<premis:eventType>capture</premis:eventType>  
<premis:eventDateTime>2014-06-26T21:50:34</premis:eventDateTime>  
<premis:eventDetail>capture/digitization</premis:eventDetail>  
<premis:eventOutcomeInformation> 
  <premis:eventOutcome>OK</premis:eventOutcome> 
</premis:eventOutcomeInformation>  
<premis:linkingAgentIdentifier> 
  <premis:linkingAgentIdentifierType>NK_AgentID</premis:linkingAgentIdentifierType>  
  <premis:linkingAgentIdentifierValue>DL 3003-flatData</premis:linkingAgentIdentifierValue>  
  <premis:linkingAgentRole>machine</premis:linkingAgentRole> 
</premis:linkingAgentIdentifier>  
<premis:linkingObjectIdentifier> 
  <premis:linkingObjectIdentifierType>file</premis:linkingObjectIdentifierType>  
  <premis:linkingObjectIdentifierValue>PS_1_0003_R</premis:linkingObjectIdentifierValue> 
</premis:linkingObjectIdentifier> 
</premis:event> 
<mix:ScannerModel> 
  <mix:scannerModelName>DL 3003</mix:scannerModelName>  
  <mix:scannerModelNumber>DL 3003</mix:scannerModelNumber>  
  <mix:scannerModelSerialNo>2012.04.04</mix:scannerModelSerialNo> 
</mix:ScannerModel>  
<mix:ScanningSystemSoftware> 
  <mix:scanningSoftwareName>Copinet</mix:scanningSoftwareName>  
  <mix:scanningSoftwareVersionNo>2.0.4451.21664</mix:scanningSoftwareVersionNo> 
</mix:ScanningSystemSoftware> 
navázáno s objektem v mix:GeneralCaptureInformation
 <mix:GeneralCaptureInformation> 
    <mix:dateTimeCreated>2014-06-26T11:50:39</mix:dateTimeCreated>  
    <mix:imageProducer>The National Library of the Czech Republic, A3993</mix:imageProducer>  
    <mix:captureDevice>digital still camera</mix:captureDevice> 
  </mix:GeneralCaptureInformation>

Požadovaný výstup má tedy vypadat nějak takto?:

<!--z premis:agent-->
<ARCLib:agent>
<ARCLib:agentName>DL 3003-DL 3003</ARCLib:agentName>
<ARCLib:agentNote/>
<ARCLib:eventDate>2014-06-26</ARCLib:eventDate>
<ARCLib:fileCount>10</ARCLib:fileCount>
</ARCLib:agent>
<!--z ScannerModel-->
<ARCLib:agent>
<ARCLib:agentName>DL 3003</ARCLib:agentName>
<ARCLib:agentNote>2012.04.04</ARCLib:agentNote>
<ARCLib:eventDate>2014-06-26</ARCLib:eventDate>
<ARCLib:fileCount>10</ARCLib:fileCount>
</ARCLib:agent>
<!--z ScanningSystemSoftware-->
<ARCLib:agent>
<ARCLib:agentName>Copinet</ARCLib:agentName>
<ARCLib:agentNote>2.0.4451.21664</ARCLib:agentNote>
<ARCLib:eventDate>2014-06-26</ARCLib:eventDate>
<ARCLib:fileCount>10</ARCLib:fileCount>
</ARCLib:agent>

Připouštím že je možné, že si vůbec nerozumíme, proto mě prosím neváhejte vyvést z omylu.

Bohužel se mi při revizi úplně nezdá ani sekce ARCLIB_001. V první řadě, pokud souhlasíte, bych přidal preservationLevelValue do klíče pro group by (jinak bychom mohli snadno narazit na problém zmíněný v tomto issue, např. by ARCLib agregoval 5 JPEGů do jednoho elementu, s jedním preservationLevelValue, i když by na vstupu byly dva odlišné preservationLevelValue). Pokud přidám atribut do klíče, vznikly by v tomto případě dva elementy se stejným PUID ale jiným preservationLevelValue. Opět jsou zde i již zmíněné alternativní řešení, ale stávající stav je předpokládám nevyhovující. Stejná situace nastává u scannerModelSerialNo, buď bude třeba dle něj štěpit (přidat do group by), nebo ho zde vůbec neuvádět, nebo v agregovaném záznamu uvádět tolik různých skenerů, kolik bylo reálně použito k skenování agregovaného počtu formátů. V současnosti se systém víceméně spoléhá, že všechny soubory jednoho formátu a jednoho AIPu byly skenovány jedním skenerem a mají stejný preservationLevelValue. Pokud by to tak nebylo, uvede systém do agregovaného elementu klamlivou hodnotu - první skener/preservationLevelValue na který narazí.

Předpokládám že jakékoliv změny máme rovnou zanést i do schéma pro index a vyhledávacího formuláře v GUI.

godnat commented 3 years ago

Ad mix:ScannerModel Za mě ano, prosím i jeho extrakci do metadat, v některých balíčcích je informace o skeneru i v premis agent, ale neplatí to pro všechny balíčky a všechny producenty. A je to důležitý údaj, podle kterého může být potřeba vyhledávat- asi kombinace názvu skeneru a serioveho čísla. Ale kdyby měl někdo z týmu jiný nápad, jiný názor, tak je to k diskuzi.

Ad Arclib__001 ano, přidání preservationLevelValue do klíče by se asi mohlo hodit. Ještě se zamyslím. Původně se, pokud vím, preservationLevelValue neextrahovalo, ale přidalo se proto, že se extrahovali informace o Tiffu, který v balíčku fyzicky nebyl, tak aby to nemátlo a budoucí uživatelé si nemysleli, že v balíčku je taky TIFF (když není mezi identifikovaými soubory Droidem). Jinak to preservationLevelValue asi tak velký význam nemá, tak jestli ho možná nevyhodit.

Ad scannerModelSerialNo může se stát, že v jednom balíčku budou použity různá zařízení (typicky, když se něco doplní nebo nahradí). Takže určitě by to mělo evidovat různé skenery. A asi tedy i seriová čísla, asi se muze stat, že se nakombinují 2 skenery s různými seriovými čísly.

yantom commented 3 years ago

Upravili jsme XSLT, snad teď již více odpovídá požadavkům.

Přikládám zip obsahující nové XSLT, testovací balíček, výstup transformace na daném balíčku a popis změn.

newSipProfileDemo.zip

Prosím o reakci zda je nový profil a jeho výstup OK. Dále je otázkou zda provedené změny odzrcadlit i v definici ARCLib XML a možnostech vyhledávání - vzhledem k tomu že formát ARCLib XML je odvozen z potřeb NDK a v NDK profilu nyní zanikla sekce ARCLIB_002 a dva elementy z sekce eventAgents, asi by měly zaniknout i v ARCLib XSD a ve vyhledávacím formuláři.

godnat commented 3 years ago

V Arclibu na test nový profil ještě nasazen není, že?

S výše popsanými úpravami souhlasím, na xslt se ještě podívám. Výstup transformace vypadá dobře, v sekci ARCLIB_002 (eventAgents) je možné smazat element - byl to linkovací element, který vedl na původní ARCLIB_002, ale teď už není potřeba a z ARCLIB_001 by se mohlo jako klíčový element přesunout do ARCLIB_002, tam kde se to mapuje z mixu ze skeneru.

"Dále je otázkou zda provedené změny odzrcadlit i v definici ARCLib XML a možnostech vyhledávání - vzhledem k tomu že formát ARCLib XML je odvozen z potřeb NDK a v NDK profilu nyní zanikla sekce ARCLIB_002 a dva elementy z sekce eventAgents, asi by měly zaniknout i v ARCLib XSD a ve vyhledávacím formuláři."
Ano.

Děkuji.

yantom commented 3 years ago

Ad. smazat linkingDeviceID - obsahovalo hodnotu z agentIdentifier, bylo součástí klíče pro seskupení. Pokud zde ponecháme pouze agentName, chceme grupovat pouze dle agentName? Znamenalo by to že pokud by se někdy vyskytnou stejně pojmenovaní agenti s jiným ID, v XML budou spojeni do jednoho elementu. Nebo můžeme stále grupovat podle jména i ID ale ve výsledném XML uvádět jen jméno, to by zase znamenalo že ve výsledku může být 2x stejný eventagent lišící se snad jen v počtu napojených souborů, pokud by na vstupu byli dva agenti se stejným jménem ale jiným ID.

Nasazeno není, chcte nasadit (do kterého SIP profilu?) současnou verzi nebo až verzi upravenou dle Vaší reakce?

Ostatní je jasné. Úprava formátu ARCLib XML dle těchto změn v XSD, šabloně pro indexaci, formuláři na FE a v reporotovacích šablonách chvíli potrvá.

godnat commented 3 years ago

Stačí nasadit až další verzi, jen jsem nevěděla, jak to otestovat, a nešlo mi tam nakopírovat nový SIP profil.

Ad. smazat linkingDeviceID- dobře, zamyslím se nad tím. agentIdentifier nenese žádnou významovou informaci, tak mi přišlo, že kdyby tam nebyl, že by ten zapis vypadal jednodušší. Ale jak to popisujete, tak se zamyslím, jestli se nám to k něčemu nehodí- nemělo by, pokud by metadata byla přesná (stačí nám znát jen použitého agenta a kdy), ale protože nejsou, tak agentIdentifier by teoreticky mohl k nějakému rozlišení vést, jen mě to ted nenapadá.

Takže nenapadá mě přínos proč by tam ten element měl být, ale ani ničemu nevadí, že tam je.

yantom commented 3 years ago

Úpravy zapracovány, nový SIP profil nahrán na server: https://arclib-test.lib.cas.cz/sip-profiles/ed8e7270-647c-11eb-8e13-29510e40f403 a zde testovací ingest: https://arclib-test.lib.cas.cz/ingest-workflows/ARCLIB_000003333

godnat commented 3 years ago

Otestováno na datech a vypadá to dobře. Vypadá to, že se extrahuje vše, co se extrahovat má a co může být teoreticky potřeba pro vyhledávání. Myslím, že se může zavřít.