HannahSonntag
commented
3 years ago From our call with Robin/Orlin/Thomas/Steve/Hannah on 2nd Dec 2020 This is the suggested new database structure:
In brief here are bulletpoints of the discussion we had:
- Overall the structure should be kept as simple possible and as complex as necessary. - Organizations (as in Affiliation); i) Organizations would be user managed. Autosuggest could help avoiding the creation of duplicates. It could also be worthwhile to check out existing databases with lists of organizations that allow download or API-query (ror.org for example) ii) Do we need organization type? No iii) Organisation units; For sdash it would be sufficient to just have organization unit as field in the organizations table. But we should keep the organization unit table for the future since there is no harm in it
- Shall we include Middlenames? Yes, lets include Firstname, Middlenames, Lastname
- Where do we keep email addresses – It is a bit tricky because these are used for authentication. And are also important for the external author identification and therefore part of the affiliation? Also institutional email address could change. This is still not quite clear to me which table will get which email address for what reason.
- There was the question if we should keep linked in and twitter information separate in the table? - What Orlin suggested (sorry I cannot reproduce this. We went with Orlins suggestion)
Will probably start on this after 'public page light' is implemented since we dont want to delay that any further.
We want to separate the user profile from affiliations. Currently its all in one table.
Similar ‘ideas’ can be found in switch EDU-ID and ‘PURE’ from Elsevier- we can use as orientation.
More details on this will follow once we hammered out the details. This is the token issue for now.