• Example for thumbnail: https://arche-thumbnails.acdh.oeaw.ac.at/?id=https%3A%2F%2Farche.acdh.oeaw.ac.at%2Fapi%2F4812&width=500&height=500
• https://app.swaggerhub.com/apis/zozlak/arche/3.5#/default/get__resourceId__metadata
• GET {resourceId}/metadata/ and format application/ld+json will output and json ld

Just a few notes for our OpenAtlas/ARCHE meeting tomorrow, implementation would be:

• Fetching ARCHE ids, compare with already imported and only get the new ones
• Fetch the thumbnail and a metadata file
• Create new entries with metadata and thumbnail in OpenAtlas
• Pushing a new, different metadata file back to ARCHE after the INDIGO team finished working on it OpenAtlas

Alexander Watzinger wrote:

Fixed size of way too large images in description

Thanks Alex! I wanted to ask how to do this..

Just for development reasons, add this to production.py

ARCHE_ID = 1390136
ARCHE_COLLECTION_IDS = [1390141]
ARCHE_BASE_URL = 'https://arche-curation.acdh-dev.oeaw.ac.at/'

I just tested it and it worked great. Thank you Bernhard and Massimiliano, this was a very important first step.
Next step would be to add a thumbnail image as a file entity in OpenAtlas (if it isn't already in the system) and add information provided.
I'm kind of busy at the moment with other stuff so feel free Bernhard to continue if you like, or just assign it to me and I will take care of it later.

Thank you, Alex, I will continue and assign the ticket to you, when I'm away.

One question is, how we keep track, if the images exist or not. Should we use origin_id from import to add the original ARCHE image ID?

In the feature_arche_import branch a rudimentary import is available.
If you go to Admin→Data→ARCHE, there is a crude overview from the ARCHE IDs. If you click on Fetch data, a list of all data in the collection is presented. At the tab import data, you can import the data. If the filenames are existing, it will through a warning and a list of which entities are already in the database. We definitively have to refine the duplicate method and think about how/where to store the original ARCHE IDs.

When data is imported, a new file entity will be created with the complete filename (e.g. INDIGO_2022-07-22_Z7II-A_1021.jpg) and the related file (max width=1200) will be stored in upload and renamed, so it will be displayed in OpenAtlas. Additionally, an artefact entity is created, named without the file extension (e.g. INDIGO_2022-07-22_Z7II-A_1021), with the geographic locations, creation date and also linked to the file entity.

One issue I noticed is the image rotation. Some images are upside down and some on the side.

Thanks Bernhard for the good progress. Next step would be to connect the artifact entities to an external reference system. One way to do it would be to look for one that it is called ARCHE and give a notice if none called like this exists before allowing to use these functions. Once this is done we can use the ARCHE identifiers to check for comparing what is already imported to avoid duplicates.

Once this is done, we can look what else information we can extract and map in OpenAtlas.

About the image rotation issues, in a similar project I'm using the code below which fixes rotation issues of photographs (exiftran package needed for that), not sure if this is helpful for these issues too but worth a try:

from subprocess import call

if f'.{ext}' in app.config['IMAGE_EXTENSIONS']:
  call(f'exiftran -ai {path}', shell=True)  # Fix rotation

But depending on the specifics, maybe this should be done already in ARCHE before? But it can't hurt to have these correction functions in OpenAtlas as well.

Anyway, thanks again for the good progress and as said before, you can assign this issue to me before leaving us for your true calling :)

• as persons (E21) - if no person with the provided name exists it will be created
• with a type (E55), so we need a type for persons to differentiate between graffito artists and photographers, maybe something like "project reference"
• as creator at a production event (E12) of the image (with the photo timestamp as begin, same location as graffito), we should also add a type for the production event, e.g. "photograph"

As soon as this is implemented we deploy it on the INDIGO instance so it can be demonstrated/tested.

Added license type and creator type to files

Alexander Watzinger wrote:

• as persons (E21) - if no person with the provided name exists it will be created

What if two or more persons with the same name exists? Should we just take the first occurrence?

I was thinking of that too, in that case I would say it's ok to just take the first one.
Persons can only exist if they either were created automatically (because not existing when importing data) or created manually. I think it unlikely that a person name duplicate is created manually but the responsibility not to create duplicates lies with the data entry persons.

Even if this happens, there is not much we can do about it within the automated script. In case we later notice that this happened we can try to merge these persons (manually) and updating links from one to another is relatively trivial.

Ok, it is done. Let's have a look over it together.