Archipelago handles files, keeps them around, classifies them, basically does the whole DAMS thing and depends (for IIIF sakes) on having access to technical metadata to build proper IIIF manifest via Twig templates.
If you are using Archipelago as an aggregator of remote files you can really ingest URLs into some JSON keys and adapt your twig templates to handle remote files for almost ANY (almost, i would say 60%) of the needs. BUT, some things of the things, a 40% require to have access to a locally managed by archipelago (e.g S3) file so we can create File Entities and also, most importantly extract techmd and also do post processing (OCR, etc).
If a JSON key that is mapped to ap:entitymapping is marked as e.g entity:file and instead of containing IDs (File IDs) contains URLs to remote resources we could:
Fetch the Remote URL and get a temp file, analize, extract all the data we need and generate an e.g as:image
entry BUT not generate a File entity and even more delete the tmp file at all (so a one time operation as long as as:image is not deleted?)
These as:image, as:document etc will have a slightly different “CONTRACT” less internal keys
Not all Viewers will be able to deal with this remote sources (because on actual daily operations we will be getting the REMOTE file always, there won’t be anything in archipelago at all to backup our as:image other than techmd and urls
The idea situation here is to store everything related to the remote source in an Entity as closed as a File Entity so we can keep track/usage but also make sure the existing Entity based workflow does not need recoding. This will also allow us to convert a remote entity into a real one on request and if that is the case, probably having a Remote Stream Wrapper (there used to be one but its buggy) would be the best situation so we can keep the existing File Entity around without basically No other change than an initial download to make TECHMD possible
What?
Archipelago handles files, keeps them around, classifies them, basically does the whole DAMS thing and depends (for IIIF sakes) on having access to technical metadata to build proper IIIF manifest via Twig templates.
If you are using Archipelago as an aggregator of remote files you can really ingest URLs into some JSON keys and adapt your twig templates to handle remote files for almost ANY (almost, i would say 60%) of the needs. BUT, some things of the things, a 40% require to have access to a locally managed by archipelago (e.g S3) file so we can create File Entities and also, most importantly extract techmd and also do post processing (OCR, etc).
If a JSON key that is mapped to ap:entitymapping is marked as e.g entity:file and instead of containing IDs (File IDs) contains URLs to remote resources we could:
The idea situation here is to store everything related to the remote source in an Entity as closed as a File Entity so we can keep track/usage but also make sure the existing Entity based workflow does not need recoding. This will also allow us to convert a remote entity into a real one on request and if that is the case, probably having a Remote Stream Wrapper (there used to be one but its buggy) would be the best situation so we can keep the existing File Entity around without basically No other change than an initial download to make TECHMD possible