Some thoughts on simplifying HSDS locations for the future.
Following are a couple thoughts on potential updates for location, physical_address, and postal_address in HSDS. I’ve been transforming AUW211’s data into HSDS using DBT, and the aspect of having two address tables that are separate from the location table introduces complexity that I’m not sure is worth it. I’m usually in favor of normalization, but there’s a strong case for denormalizing these tables.
1) Consolidate to address.
physical_address, and postal_address are identical, distinguished only by type of address, a taxonomic difference that should be reflected in a column, not a table. These should be consolidated to address with an added column of type, and enumerations of physical and mail.
I foresee there may some confusion around the ambiguity of the name address, as the word alone can reflect a number of things in different parlances, such as a web address. However, I’m not going to make a big deal out of it personally. It’s easy to distinguish what’s going on by glancing at the column names, and other types of address in HSDS are clearly labeled as well (url instead of “web address” for example).
I think there is a very strong case that postal_address has to go.
2) Consolidate to location.
This second proposal is more contentious, but should be seriously considered as a logical extension of the first proposal.
If we are going to consolidate the first two tables around a new column of type, and if the primary reason for having address separate from location is that location might be of a third type='virtual', then why not consolidate all of the types up to location and denormalize the required fields there?
Aside from moving the address specific fields to location, there are only one or two additional updates required:
- Add a `url` field, which should really exist anyway if `virtual` is considered a legitimate `type`.
- I may be thinking too far ahead on this one, but I propose we add a `definition` column that is expected to be GeoJSON or TopoJSON, describing the geometry of a location.
what3words got me thinking about that second item: although it can be defined well enough as simple lat-long (which is already included in location), w3w is actually a one square meter shape.
As other new standards are introduced, especially in developing nations, the combination of `name`, `description`, and `definition` should allow for many new standards to get defined as needed in plain text and geometry.
Conclusion
These aren’t issues to die on, and I’m sure there are very good reasons why the address tables got normalized to the current extent. In practice, they have been a hassle for me, and I’ve heard reports that they are a hassle for others in the OR community as well.
This seemed like a bit much to leave in a GitHub issue, although perhaps I should move it there for further discussion. In any case, if you have thoughts and want to carry on the discussion, or just want to learn more about HSDS in general, checkout the GitHub space (https://github.com/openreferral/specification) or Slack space (https://openreferral.slack.com) to get involved.