{{toc}}

h1. Developers Meeting 2019-11-27, 15:00

Participants: Stefan Eichert, Nina Brundke, Alexander Watzinger, Bernhard Koschicek, Christoph Hoffmann

Location: ACDH meeting room, Vienna

h2. Trivia

* Schedule (2 hours with break after one)
--> accepted
* https://github.com/topics/cidoc-crm
* License sentence on top of files e.g. "file":https://github.com/craws/OpenAtlas/blob/master/openatlas/views/actor.py
--> accepted
* THANADOS presentation: Wednesday, 4.12. 18:00 Redemptoristenkolleg Maria am Gestade, Klemenssaal (Salvatorgasse 12, 1010 Wien)
* Next meeting December or January?
--> second half of January 2020

h2. version:4.0.0 Version

* Possible release date: 2020-01-01
--> accepted
* Refactor OpenAtlas views for entities -> /entity/id
--> accepted
* #1079: Static type checking with Mypy

h2. #1048 Bootstrap 

* Update and presentation 
--> looks cool, will make the 4.0.0 release (but won't be Bootstrap 'pure', e.g. forms will be reworked later)

h2. #1050 API 

"Notes":https://redmine.openatlas.eu/projects/uni/wiki/Api

* For places we use the type "FeatureCollection", how should we name the other entities?
--> We will use other type names. Bernhard will research for existing possibilities 
* Should we also use "feature": [] for other entities also? The thing is, that every information is in feature, but an actor doesn't have a "feature". Or do we say, it is ok "feature":[] includes any entity
* Should we differentiate between E18 and E53? Alex and Bernhard would say no
--> for the default output we will not differentiate between them, in a CIDOC related output we will
* Should we use commet at "when": {"timespans":[]}? Is is technically no problem and an additional information some could need
--> comments will be used
* How long we want to maintain old API versions and how we implement a version system
--> API URL we be like /api/entity/107 because the API won't have compatibility changes often, in case it does we'll do something like /api2/entity/107
* What should happen, if a Type/Node is requested from the API? Should we show the parent and all sub types or only show parent?
--> Only one level up and down (parent and subs). Maybe research how other peoples map categories in json-ld. One possibility is that we include the path as string.
* What should happen with empty tags? 
--> ignore empty tags (don't write anything)

--> We will ask Rainer Simon about possibility to add other entities like actors or sources to the linked places format

h2. New Tickets

* #1100 Save geometry not working --> will be fixed soon
* #1086 Value types duplicates --> will be reported if it happens again
* #1089 Body Parts User Interface --> good idea, accepted and on wishlist
* #1090 Radiocarbon Dating --> good idea, accepted and on wishlist
* #1101 Main image for reference --> default image will be removed for reference