Make "start/begin area" a relationship to allow multiple entries?


Main reason for it to be a relationship is the usual reason for things to be relationships: some (lots of) artists have no founders, but more importantly some have more than one, which a static field doesn’t support well (unlike “born in”, which I’d expect is always one place! I hope…)

"Indefinite hiatus" vs. end of life-span
Add a founder relationship for groups and ensembles (STYLE-644)

Well, yes. But then, “start/begin area” is only “born/died in” for a person. A group could have dissolved and reformed multiple times.
What’s the percentage of artists that have start and/or end area set? If that’s relatively low, would it make sense to turn those into ARs in one of the next schema changes?


It would be really nice to be able to have multiple dates for that, especially four groups and also labels (both tend to be resurrected multiple times if they once were successful). The issues I see that need to be solved:

  1. We might have the date, but not the start / end area, and you cannot create a relationship without a proper endpoint. This alone maybe disqualifies it as a AR unless we have a good idea
  2. The naming has to be adopted, for sure only the first date can be considered “founding” a group, later dates are maybe “reformed at”. Could be solved by an attribute
  3. It’s a bit awkward to edit for born / died dates, which probably most people expect to be straight forward to enter and relationships makes it a bit harder.

But as this involves a schema change it could also maybe be not just a relationship but something more specialized (just allowing multiple start / end pairs to be edited).

I haven’t looked yet, but it would surprise me if there was not already a ticket about this in Jira :slight_smile:



It wouldn’t need a schema change to be put into effect. The current data can be migrated to relationships and the MB server code can get updated to use those relationships for WS output and whatever else it’s currently being used for. The entity db fields should get removed at the next schema change, but no schema changes are needed to go ahead with it, if it’s what we ultimately want to do.


The lack of an endpoint wouldn’t be a huge issue if there was an [unknown] special purpose area; but that always has the risk of being over/misused I suppose.


What’s being discussed seems to lend itself to creating a more versatile timeline in general (if we have multiple ‘start’ and ‘end’ why not a ‘moved’ or ‘changed name’ etc).
Not something that I think needs to be added, but might be worth keeping in mind.