• Table of contents
• Developers Meeting 2019-11-27, 15:00
  • Trivia
  • 4.0.0 Version
  • #1048 Bootstrap
  • #1050 API
  • New Tickets

Developers Meeting 2019-11-27, 15:00¶

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

Location: ACDH meeting room, Vienna

Trivia¶

• Schedule (2 hours with break after one)
  --> accepted
• https://github.com/topics/cidoc-crm
• License sentence on top of files e.g. file
  --> 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

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

#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)

#1050 API¶

Notes

• 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

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