OpenAtlas

{{toc}}

A collection of ideas that haven't made it into an own ticket yet.

h2. API

* 2023: SPARQL endpoint, e.g. with karma (suggestion from Christoph) https://github.com/usc-isi-i2/Web-Karma

* 2023: [[Version 1]]

* 2023: Spatial search through coordinates

h2. Frontend

h3. Quality

* 2023: make frontend code testable and write tests (e.g. to identify unused code)

h3. Entity view

* 2024: Make a link button available in artifact tabs. Challenge there would be that artifacts are linked very different depending on the corresponding entity.

* 2021: don't show link buttons in tabs if there are no entities to link

* 2020: Show membership at appears first if available

h3. Forms

* 2024: Form HTML validation errors because *label for* at *multi table fields* isn't valid for the *span button* so it should be transformed to an *input button* but the *layout* has to be adapted, see e.g. https://demo-dev.openatlas.eu/insert/creation

* 2024: Dynamic entity add: re-filling of tables after adding an entity doesn't work (anymore) but would be useful e.g. at actor when wanting to add a residence and the same place as birth/dead place

* 2023: Dynamic entity add: custom required types are ignored (e.g. case study at place or type). Could be problematic but not sure if it is worth the effort to add these into popup forms. Also we can't offer there e.g. an add type too.

* 2023: Dynamic entity add: it's only available for "table select" but not for "multi table select" (e.g. artifact at source). Of course it would be nice to have it there too but not sure how difficult to implement and if it there are unwanted side effects

* 2023: Filter functions in form fields ignore table name because it's present in a JavaScript call in table cells. Would be nice to fix but not sure how complicated this is.

* 2022: Member/membership: add + buttons for person/group in tab. But difficult how to differ from relation link because they too have an actor entity as origin

* 2022: Better validation for reference systems: names have to be unique and when adding one with an existing name a transaction error occurs which works but is ugly but when updating one to an existing name strange things happen.

* 2021: Update links instead recreate, test first in Journal application

h3. Maps

* 2020: Add an additional area where existing geometries are shown (don't use label "features")

* 2020: Search function for existing entities on map

h2. Settings

* 2020: Add a default value to settings and show if they are changed in views

h2. External Reference System (GeoNames, Wikidata)

* 2023: Retrieve and offer data from external reference systems (e.g. name, birthday, ... when creating a new person)

* 2020: Show additional information e.g. if Wikidata id is provided also show (their) GeoNames id, Pelagios, ...

* 2020: Advanced options for GeoNames search (e.g. select categories, fuzzy or not, ..)

h2. Integrity checks

* Events: check dates for super and proceeding events

* Events: check links between super and proceeding events, e.g. one event can't have the same other event as super and proceeding

h2. Import

* 2020: Implement B.C. dates

* 2020: Warn if inconsistent dates (e.g. begin for end)

* 2020: Warn if missing dates (e.g. begin_to without begin_from)

h2. Third party software

* 2023: with *gettext* 0.23 (currently 0.21 in Debian/bookworm) it should be possible to use translated strings in f-strings, e.g. @f'{_("welcome")} {username}'@

h2. Time intensive and requires substantial financing

*Functionality*

* 2023: Multi language support for data (#1925, on roadmap)

* 2023: Factoid model (linking data details to sources, make multiple and even conflicting data details possible), see https://www.kcl.ac.uk/factoid-prosopography/about

* 2023: Track data changes (e.g. description diffs) -> before that we would have to refactor to only save changes at update

*System*

* 2020: Multi instance capability #924

* 2020: Debian package