Open dylanmccall opened 6 years ago
In the HSDA specification, for "GET /services/", the response ID includes a single "location_id" field, which strongly implies that a service record should have a single location: http://openreferral.readthedocs.io/en/latest/hsda/hsda/#get--services-.
In the HSDS specification, there is a separate table called "service_at_location". The text doesn't say anything about service and location being unique together, so I am left to assume this table creates a many-to-many relationship: http://openreferral.readthedocs.io/en/latest/hsds/reference/#service_at_location.
So, these two seem to be at odds with each other. I would really appreciate some clarity on how this should look, and it would also help if the specifications were a bit clearer about it.
The location_id on services was legacy artifact, that should be deprecated--didn't get caught in last release.
Labelling api - this issue is still current
In the HSDA specification, for "GET /services/", the response ID includes a single "location_id" field, which strongly implies that a service record should have a single location: http://openreferral.readthedocs.io/en/latest/hsda/hsda/#get--services-.
In the HSDS specification, there is a separate table called "service_at_location". The text doesn't say anything about service and location being unique together, so I am left to assume this table creates a many-to-many relationship: http://openreferral.readthedocs.io/en/latest/hsds/reference/#service_at_location.
So, these two seem to be at odds with each other. I would really appreciate some clarity on how this should look, and it would also help if the specifications were a bit clearer about it.