INDIGO Meeting 2021-10-05¶

Updated information in the course of the meeting is in color.

Participants¶

OpenAtlas: Stefan Eichert, Nina Brundke, Alexander Watzinger, Bernhard Koschiček-Krombholz, Christoph Hoffmann, Jan Belik
Spraycity: Stefan Wogrin
LBI ArchPro: Geert Verhoeven, Jona Schlegel
TU Wien: Johannes Otepka
ACDH-CH: Peter Andorfer

General¶

Introduction of members of different teams and opening words, introduction to Redmine, our ticket system
Public protocol ok? public protocol is fine for everyone involved
Short introduction and demonstration of how to enter dates into OpenAtlas as well as the manual
Show how users are created and how to add INDIGO team members, short introduction of different groups of users (editor, manager, etc.)
Short introduction to different types (value types, custom types, etc.) including how to set up new types as well as parent-child relations for types

Functionality¶

Discussing issues on the roadmap and what information will be available before OpenAtlas (e.g. time, geolocation of images) and how to import them.

#1500: Creation of artifacts¶

This will have to be implemented, maybe similar to Move events.

Short presentation of the CIDOC CRM by Stefan and its use within the INDIGO project; discussion of the OpenAtlas shortcuts within CIDOC CRM
INDIGO specific: Connecting actor(s) to artifacts as necessary changes in the data model is already mapped in the model but still has to be implemented in the UI
Presentation on how to enter time spans - question: states "date" when the graffiti was created OR how long it was visible? -> Event = creation of graffiti; how long it was visible can be connected to the graffiti itself as an artefact; Idea: Connected events and artefacts to track (partial) changes over time (agency of artifacts) - best discussed when some data has been entered to see what is needed or if methods already implemented are sufficient (no problem to map it within the model though)

#1576: Controlled vocabularies¶

When considering to also use Vocabs it seems to be easiest to:

First implement, manage and use vocabularies in OpenAtlas best via types as they are easy to edit during the project
At project's end, import them to Vocabs
Add Vocabs URIs to type entries in OpenAtlas
Other controlled vocabularies can already be used during data entry

Maybe most users should just have the contributor role to prevent changing of vocabularies.

#1575: External image processing¶

Where would images be saved and what information will be already included.

In general small-sized photos can be uploaded connected to each entry to prevent any confusion
Metadata connected with camera, as well as additional data (IPTC standard - included in the (raw) photo as well as in a .XMP or other text formats) Will be provided; to decide: which information will be used (see ARCHE as well), including copyright information such as CC BY licenses and how can this information be imported into OpenAtlas
Some metadata has to be provided to ARCHE, eg. right holder, name, photographer, etc - see ARCHE information on metadata
In any case, keep raw data to keep working with as well as derivates for long term archiving as best practice

#1573: 3d geometries¶

3d geometries for graffiti could be added to OpenAtlas. They could be displayed as lines on the map but it wouldn't be possible to edit them within the application. So the main question would be how to import them.

Question: where will 3D geometries be available and which information is provided with them? -> if a polygon is provided, a line can show where the graffiti is/was as additional information (during data entry not for presenting data); 3D data can be stored in OpenAtlas but not edited; will be discussed when more data is available/workflows were developed (e.g. is a 3D database in addition needed, can it be resolved within OpenAtlas, how can data be stored in OpenAtlas, etc.)

#1574: Dates with hours and minutes¶

The tracking of hours and minutes for events could be added to OpenAtlas but we should discuss where they are needed to decide if we want to add this functionality in general.

Seconds are not needed within the project
Information delivered with photo on time can be used to track date, here it can be done with more precise time span
But for artifact and event (an addition) option to track time more precisely (am/pm, hour, or else) is desirable; maybe as an option that can be found and activated in the setting section
Hour and minute is useful, seconds not necessary

Concluding¶

When will data entry begin, it may begin partially e.g. to build vocabularies
- Actual data entry can start after implementation of #1500
Further steps
- Once #1500 is implemented we will meet again for a more detailed user interface introduction