_Neo4jDate field doesn't allow partial dates (year or year-month)

[alastair]

From trompamusic/trompace-client#21 (comment)

mutation {
  CreatePerson (
    title: "name"
    contributor:"alastair"
    format: "text/html"
    source:"foo"
    creator:"alastiar"
    name: "aname"
    date: {year: 2000}
  ){
    identifier
  }
}

query {
  Person(identifier: "b16777d3-e9f3-49be-8fc8-098ad30f66dc") {
    date {
      formatted
    }
  }

gives a result of

{
  "data": {
    "Person": [
      {
        "date": {
          "formatted": "2000-01-01"
        }
      }
    ]
  }
}

Intuitively, this feels wrong, as in many cases we may only have partial date information. Two use-cases which we need to support immediately:

• Muziekweb store birthdates and deathdates of people as only the year. It's incorrect and confusing to store this is the CE as yyyy-01-01
• MusicBrainz also supports partial dates, if all values are not known, e.g. only store yyyy or yyyy-mm.

While we may loose semantic information by not using a specific Date object, I think that it makes sense to consider changing the type of these Date fields that could be partial. Two options come to mind:

• change date to a string, and allow dates in the iso8601-2 format. A downside here is that we will have no validation of these fields
• split dates into 3 fields - dateYear, dateMonth, dateDay, and allow them to be optional. This could still cause a problem with validation, as (I think) we would want to prevent having a year, no month, and a day set.

[ChristiaanScheermeijer]

Another downside of updating the fields to type string is that it isn't possible anymore to search nodes in the CE API within a date range.

For example:

query {
  Person(
    filter: {
      birthDate_gte: {
        year: 1800
      },
      AND: [{
        birthDate_lte: {
          year: 1899
        }
      }]
    }
  ) {
    identifier
    name
  }
}

[ChristiaanScheermeijer]

I've been researching this topic some more and would like to discuss two possible solutions.

If we follow the date definition, the birthDate property, for example, should be an ISO-8601 string. Because we are using Neo4j Graphql, it has been decided to use the _Neo4jDate and _Neo4jDateTime temporal types for date objects. Because of this, it is not possible to enter uncertain dates.

I was thinking to make all the schema.org Date and DateTime fields scalar types. For each corresponding field, there will be a "parsed" field in order to filter based on these dates.

For example:

type Person {
  birthDate: string
  birthDateParsed: _Neo4jDate
}

We could either;

1. Autogenerate the parsed field automatically and populate this field with a parsed value of the scalar field and make the parsed field read-only.
2. Add both fields to the schema and add the need to let users fill in both fields.

The downside of the first option is that we need to implement an ISO-8601-2 parser which allows dates like 1800?. As for the second option, the downside is that we can't guarantee that the parsed field will be set. This will make the search with dates unreliable.

What do you think @alastair @musicog ?

[baukef]

As discussed with @alastair this is not required for the Trompa project and the issue can be closed.