Closed Cskyleryoung closed 8 months ago
thanks for bringing this up skyler. i'm not sure i understand the meaning
of extant
in this context. my impression of the word is that it refers to
the continued existence of something old from the past.
I think the term should be "extent". This refers to the polygon defining the area. See rows 190 and 191 of Por20349 - HSDS - US and UK.
However, the proposal (in row 188) is to rename "service_area.service_areas to service_area.name.
Closing this since as of 3.0, neither language
nor service_area
have fields with the same name as their object/table
There are two fields names in HSDS that are the same as their table names:
service_area
language
This is heuristically sloppy, and actually creates a really problem in some database/analytics systems like BigQuery, where referencing the field actually references the whole table (when the names are the same) and nests it in the resulting selected data. Because you can actually nest tables in BigQuery (and perhaps other emerging database technology).
I strongly recommend we update these field names so they aren't the same as their table names.
What should we call them?
We already have some common and more generic heuristics in the spec that we can draw on, the two most notable being
name
anddescription
.service_area.description
works great. I believe @mikethacker has already suggestedservice_area.extant
, which also works well.Likewise,
language.name
is more readable thanlanguage.language
.My official proposal.
service_area.service_area
toservice_area.extant
.language.language
tolanguage.name
.Taking it one step further?
Some of the small tables almost have the same issue of duplicate names:
required_document.document
payment_accepted.payment
accessibility_for_disabilities.accessibility
Would these be more readable and consistent as follows?
required_document.name
payment_accepted.method
accessibility_for_disabilities.description
Renaming these fields if definitely not something I'm going to die on the sword over. Whereas the first two (
service_area
andlanguage
) are actually rather critical, these last three are maybe nice to haves. I felt I had to mention them for consistency's sake, since they so nearly fall into the same category.