Modelling Services

[pwalsh]

What we did have:

Until 0.0.15-alpha services were modeled in a parent-child hierarchy, the idea being that:

• This allows public users to assign requests at different levels of the hierarchy (don't make the public user think too much if they are reporting a 15L bin or a 30L bin, just let them report a rubbish issue)
• This allows us to model service types that are not strictly 311 related (have different branches for 311 and non-311 queries)

There were tests at the API endpoint and repository levels that showed serialization to/from open311 group to this parent-child data model was working (for some definition of working).

I came to this model from:

• my reading of the Open311 spec (which has no hierarchy but has a "group" as a container for services, but which can't be used as a service), and looking at example services from data we have we seems to me to have an implicit or explicit hierarchy
• the point that we want to accept requests that are not strictly 311 related, and having a branched and hierarchical service entity supports that

What we now have:

This was changed in 0.0.15-alpha back to a model that directly follows the Open311 approach of a "flat" container group. I don't really know why - perhaps there was an edge case, or some behavior in the existing client that was not identical to the test cases we had.

Whatever the case, I think this highlights that we need to discuss and design the Service entity a bit to ensure we model it in a way that supports Open311 but is not restricted by it.

** Some thoughts:**

• Open311 is a data interoperability format - we should be able to read and write Open311, but there is no reason that we need to restrict our data model to what open311 dictates (especially as the standard is over 10 years old and we want Gov Flow to be 311 + more). That means, we should be able to losslessly ingest open 311, and we should be able to export our data as 311, with an acceptable degree of loss (example: as we currently have, we support multiple images for service requests but open311 supports a single image for a service request)
• After thinking about it further since the change, I still think the parent-child data model, or a version of it, is on the way to the correct way to model Service data, primarily because of my first two points above, being (i) this allows public users to assign requests at different levels of the hierarchy, and (ii) this allows us to model service types that are not strictly 311 related (have different branches for 311 and non-311 queries, for example). it would be great to discuss different approaches.

@amirozer @idoivri be great to get your thoughts here, and/or discuss this further in person.