PROARC NDK fixity check

[yantom]

V rámci PROARC NDK formátu je potřeba rozhodnout se jakým směrem se vydat při konfiguraci tasku pro kontrolu fixity.

Momentálně máme v systému zadefinované chování fixity checkeru pro balíčky dle standardů METS a BAGIT. Konfigurace je fixity checkeru je tedy triviální - nastavneí hodnoty METS/BAGIT.

Možná řešení pro PROARC_NDK:

1) Naprogramovat specifické řešení pro PROARC_NDK. Tedy možnosti checkeru: METS/BAGIT/PROARC_NDK. Nevýhoda je že toto nepokrývá další formáty balíčků jiné než METS/BAGIT. U těch by se situace opakovala, bylo by opět nutné buď 1) doprogramovat specifické řešení, 2) použít BAGIT, 3) programovat obecné řešení.

2) Použít BAGIT. Tento přístup je nejjednoduším na implementaci v ARCLibu ale vyžaduje předzpracování dodavatelem.

3) Programovat obecné řešení. Konfigurace by se z původního enumu METS/BAGIT změnila na JSON.

Příklad konfigurace pro PROARC_NDK:

{
  "checksumFiles": [
    {
      "fileType:": "METS",
      "filePath": "mets.xml"
    },
    {
      "fileType:": "METS",
      "filePath": "NDK/.+/mets_.+\\.xml"
    },
    {
      "fileType:": "TEXT",
      "filePath": "Original.+",
      "checksumType": "MD5",
      "checksumFirst": true,
      "rowFormat": "(\\w{32}) \\*(.+)"
    }
  ],
  "continueOnMissingFiles": false
}

Příklad konfigurace pro NDK:

{
  "checksumFiles": [
    {
      "fileType:": "METS",
      "filePath": "mets_.+\\.xml"
    }
  ],
  "continueOnMissingFiles": false
}

nebo lépe (metadata z md5 souboru který je také přítomný a popisuje i samotný mets.xml):

{
  "checksumFiles": [
    {
      "fileType:": "TEXT",
      "filePath": "md5_.+",
      "checksumType": "MD5",
      "checksumFirst": true,
      "rowFormat": "(\\w{32}) (.+)"
    }
  ],
  "continueOnMissingFiles": false
}

[kerschfilip]

Díky za poskytnuté možnosti. Rozhodli jsme se nakonec, že archivační balíčky z ProArcu budeme před vstupem do ARCLibu upravovat do podoby BAGIT.

Rád bych se tedy jen zeptal: pochopil jsem správně, že vkládání BAGIT je v ARCLibu v současnosti již implementováno? - znamená to, že můžeme zkusit nahrávat naše balíčky? A jaké změny v nastavení SIP profilu (XSL transformace) jsou pro "náš" BAGIT nutné, budeme-li pro generování ARCLib AIP XML používat mets stejný jako je v NDK? Díky

[yantom]

BAGIT balíček na vstupu by v zásadě měl fungovat. V současnosti by mělo stačit v SIP profilu změnit typ SIP balíku a upravit GLOB výrazy - přidat složku data do cest k souborům, např. pro tento profil: http://inqooltest-arclib.libj.cas.cz/sip-profiles/688e2510-490d-11ea-87a9-c5406a24266f změnit výrazy na:

data/info.xml data/['mets', 'METS'].xml

[kerschfilip]

Bohužel se mi nedaří BAGIT vložit. Použil jsem doporučené nastavení, ale ingest (například ingest-workflows/ARCLIB_000000832) skončí okamžitě chybou

File with metadata for ingest workflow with external id ARCLIB_000000832 does not exist at path given by glob pattern: data/['mets', 'METS']*.xml

Když jsem zkusil upravit glob výrazy, takto: Path to XML: mets.xml Path to main metadata file: mets.xml a Typ SIP: BAGIT tak ingest započne (takže ARCLib asi ví, že data má v případě BAGIT hledat ve složce data?), ale selže až po procesu extrakce metadat s chybou:

No value present java.util.NoSuchElementException: No value present ...

jde například o ingest-workflows/ARCLIB_000000836

[yantom]

Pro BAGIT byl založen samostatný issue, tento navrhujeme uzavřít.