IIIF konsorcium si od zavedení IIIF Change Discovery Service slibuje lepší rozšíření IIIF tím, že usnadní využívání obsahu IIIF repositářů v reálném provozu tak, že pomocí tohoto nového API umožní repositářům sdělovat světu nejen, jaký obsah mohou těžit, ale i k jakým změnám v systému docházelo a kdy.
IIIF Presentation API totiž slouží k procházení aktuálního obsahu uživatelem v reálném čase, ale neumožňuje nikomu (ani uživateli, ani portálům či agregátorům) zjistit, zda je od minule něco nového. Pokud chceme zjistit, zda je v repositáři něco nového, pak bez Change Discovery Service je nutné projít/přetěžit kompletní repositář bez ohledu na to, zda k nějakým změnám vůbec došlo.
Principy fungování Change Discovery Service jsou vcelku prosté. Služba ve své nejjednodušší podobě (Level 0) předává seznam odkazů na obsah, který poskytuje, přičemž záměrně abstrahuje od předávání metadat či dat (data streamů) samotných Resources. Pokročilejší implementace pak sdělují, kdy byly uvedené Resources naposledy aktualizovány.
Odkaz ze seznamu typicky vede na jednotlivé manifesty, případně i kolekce - Change Discovery Service tedy umožní primárně sledovat změny v obsahu dostupném přes Presentation API. Současně je možné stejným způsobem zaznamenat změny v obrazovém obsahu (IIIF Image API), ale teoreticky i změny, které s obsahem poskytovaným přes IIIF nesouvisí vůbec, takže tento komunikační kanál je velmi univerzální.
V API však není implementován žádný mechanismus aktivního pushování změn ke klientům. Služba tedy pracuje velmi podobně jako OAI-PMH (parsují se harvestované informace dle vlastního uvážení).
Informace o zdrojích v systému sděluje služba jako Activity Streams (https://www.w3.org/TR/activitystreams-core/). Název aktivity pak uvádí, co se se zdrojem událo, volitelná property summary může danou aktivitu popsat podrobněji a časové razítko sděluje, kdy byla daná aktivita provedena.
Specifikace popisuje tři úrovně přístupu: Level 0, Level 1 a Level 2, kdy vyšší úrovně rozšiřují nižší (poskytují doplňující informace).
https://iiif.io/api/discovery/1.0/#level-0-basic-resource-list
Level 0 seznam aktivit představuje defacto netříděný seznam objektů a nepřináší v podstatě nic nového oproti tradičním postupům, jako je OAI-PMH bez podpory mazaných záznamů.
Příliš se neliší ani od IIIF Presentation API kolekcí - s výjimkou doporučení (SHOULD NOT) nezobrazovat na seznamu duplicitní odkazy (IIIF kolekce naopak mohou mít společné průniky).
https://iiif.io/api/discovery/1.0/#level-1-basic-change-list
Level 1 seznam aktivit přidává časové razítko ukončení aktivity a seznam aktivit je řazený od nejstarších událostí po nejnovější, což podle autorů do určité míry usnadňuje zpracování (aktivity na seznamu po určitém datu mohou být při zpracování ignorovány).
Implementační poznámka: Kdyby měly být seznamy obsažnější, pak to není příliš praktické. Musím načíst 10 000 událostí, abych zpracoval jen 10 nejnovějších na konci. Ve verzi API 1.0 není možno aktivně žádat o aktivity z konkrétního časového období, takže by i relativně malé repositáře měly raději pracovat s OrderedCollectionPages (vizte níže).
https://iiif.io/api/discovery/1.0/#level-2-complete-change-list
Level 2 přidává informaci o typu aktivity. Manuscriptorium jako agregátor by do vlastní implementace API pro diseminaci využilo aktivity Add, Remove, Move (jsme agregátor, nikoliv původce - o Create a Delete nic nevíme). Při ingestu bychom využili i Create a Delete, jak indikuje níže uvedená tabulka v souladu s https://iiif.io/api/discovery/1.0/#activities.
Protože Manuscriptorium čas od času (obvykle 1x ročně) preventivně přetěží a znovuzpracuje veškerý agregovaný obsah (především kvůli dosud stále velkému podílu repositářů bez podpory deleted records) – má smysl uvažovat i o implementaci aktivity Refresh.
Implementace aktivit v Manuscriptoriu:
Aktivita |
Ingest |
Diseminace |
Create |
ano |
ne |
Update |
ano |
ano |
Delete |
ano |
ne |
Move |
ano |
ano |
Add |
ano |
ano |
Remove |
ano |
ano |
Refresh |
ano |
ano |
Poznámka k implementaci aktivit souvisejících s daty distribuovanými přes IIIF Image API: protože Change Discovery API vrací seznam všech Activities v systému, nedovedeme si v praxi představit sdělování informací o tom, že se změnila data (obrazy stran) konkrétního Resource (k čemuž ale dokumentace API vybízí) – tady by bylo jistě efektivnější informovat o poslední změně spíše uvnitř manifestu, ale pro to mechanismus neexistuje. Pokud bychom tedy například převzorkovávali kompletní obsah profilu AIPDIG (a jiných), pak by na seznamu streamu aktivity byly desítky milionů Aktivit. To je vhodné uvážit před implementací.
https://iiif.io/api/discovery/1.0/#pages-of-changes
Implementace stránkování v předepsané formě není v zásadě problém, jen bude nutno generovat stránky nadřazených a sousedních kolekcí.
Implementovat stránkování pro Level 0 implementaci nemá smysl – pokud potřebuji stránkování, budu patrně pracovat s dynamickým obsahem a pak nemá cenu se omezovat na Level 0 a je lepší rovnou pracovat i s časovými razítky. Pro Level 1 a 2 bude nutné implementovat nadřazené kolekce stránek, jak předepisuje dokumentace. To je pouze technická formalita. Pokud generuji z dynamického obsahu, mohu generovat obsah aktuální stránky, indikovat předchozí i následující stránky, jakož i souhrnnou celkovou kolekci, ve které vygeneruji seznam stránek (OrderedCollectionPages).
Implementační poznámka: První záznam první stránky je nejstarší aktivita. Viz https://iiif.io/api/discovery/1.0/#orderedcollection. To je ale úplně málo praktické, protože i poskytovatel/klient musí poskytnout/načíst celý seznam, aby bylo možné zpracovat časové období, které klienta zajímá. Proto je nutné implementovat stránkování po co nejmenších stránkách a při zpracování je nutno vždy postupovat od last OrderedCollectionPage směrem dopředu (zpátky).
Implementační poznámka: Velikost stránky není pevně dána a pro různé stránky může být různá. Klient nemůže ovlivnit velikost stránky (https://iiif.io/api/discovery/1.0/#ordered-collection-page).
Summary (https://iiif.io/api/discovery/1.0/#summary) a Actor (https://iiif.io/api/discovery/1.0/#actor) : pokud by měly být využity, pak je nutno tuto informaci udržovat ve správním záznamu daného agregovaného záznamu/dokumentu.
Dokumentace přímo popisuje algoritmus zpracování obsahu poskytovaného prostřednictvím Change Discovery API (https://iiif.io/api/discovery/1.0/#activity-streams-processing-algorithm).
Je ke zvážení, zda je přidaná hodnota uvedení podobné služby dostatečná ve srovnání například s profilem EDM v OAI-PMH Manuscriptoria – z velké části jde o změnu spíš formální, pokud bychom se omezili na avizování aktivit souvisejících s obsahem poskytovaným přes IIIF Presentation API a zůstali na implementaci level 0, pak je přidaná hodnota nulová.
To samé platí pro implementaci Level 1 – máme k dispozici informaci o poslední aktualizaci a stále nemáme podporu mazaných záznamů.
V případě Level 2 jde ve srovnání s OAI-PMH a EDM o alternativní způsob poskytování téhož - získám změny za určité období, máme podporu mazaných záznamů, chybí popisná metadata, která je nutno načíst zvlášť.
Level 2 umožňuje navíc poskytnout historii záznamu (různé aktivity v různých časech pro stejný objekt/Resource). Navíc s pomocí aktivity Move lze udržovat persistenci identifikátorů.
Doporučujeme v Manuscriptoriu pro potřeby diseminace uvažovat jedině o implementaci Level 2.
Pro Manuscriptorium, jakožto agregátora, je implementace IIIF Change Discovery API do procesů Ingestu nutností. Bez něj budeme muset donekonečna zpracovávat kompletní obsah všech repositářů bez ohledu na to, zda se v nich udály některé změny.
Kromě toho budeme schopni využít obsah https://registry.iiif.io/ , kde IIIF konsorcium hodlá streamovat aktivity všech známých IIIF repositářů (a sem budeme též moci přispět).
Vytvořit autoamtický težební skript, který připraví vstup pro jednotlivé konektory správního systému.
Doporučujeme nejprve implementovat API do procesů diseminace, abychom podpořili komunitu v jejím úsilí a teprve později, až dané API bude podporovat více námi agregovaných repositářů, přistupme k implementaci API do procesů ingestu.