Following are a couple thoughts on potential updates for
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
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
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.
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.