Artist duos' metadata displaying on APP with truncated dates

[madeleineb]

On the artist profile page, artist duos with two dates entered in the birthday field are displaying with only the first of those two dates under their name, and without the deathday field.

For example,

Versus the full metadata as displayed on the Artwork page under Biography (the copy for which is displaying in an unclear way, but that's another story):

This issue is universal for the artist profile pages of artist duos with dates structured in this way.

This was reported when a partner, Blain|Southern, inquired over intercom about their new (highly publicized) representees, Jake & Dinos Chapman.

[1aurabrown]

this is actually a problem with the way we have completely unstructured data for birthdates and dates of death. this has caused annoying problems in the past and the true solution is to have structured data that represents (a) when more than one unique artist are involved in a collaboration, (b) numerical birth and death years for each individual artist.

The data for this artist id (because according to the database they are treated as one Artist) is:

{
  "data": {
    "artist": {
      "birthday": "1931–2007, 1934–2015",
      "deathday": ""
    }
  }
}

so in the "b. 1931", this is a client-side attempt to normalize the birthday string, which sometimes is "b 1931", "born 1931", "1931-2000" etc. it takes the first instance of a number in an attempt to extract the birth year and prefixes it with 'b.'. The text in the bio is simply the entire birthday string, untampered, which in this case happens to be a string representation of two birthdays and death days (which is not how this field should be used, however there isn't a good alternative built into our schema for artist duos). I don't know a good solution for this other than fixing our schema and treating these years as numbers with some validation that they contain exactly four digits, and establish some relation between artists that represents a 'collaboration'

[alloy]

@briansw Can you decide what this should look like? And are there cases with even more artists that we need to worry about?

[alloy]

For reference, this is the formatting we do of this unstructured data for both Force and Eigen: https://github.com/artsy/metaphysics/blob/1a198118e7b7b0ec7d504adc1fedaf76bb669676/schema/artist/index.js#L170-L187

[alloy]

Discussed this with @briansw, we should probably just use whatever unstructured data exists in the DB when an entity represents a group. Does the model have a flag for that?