Closed technickle closed 7 years ago
This seems like a reasonable request. Perhaps it makes sense to rename the status
field in the bulk spec to status_description
so it does not get confused. However, I'm not comfortable requiring the rule-based status
field at this point without data providers weighing in on whether they can support it in their extract-transform-load process while publishing the data.
Renaming the bulk field to status_description sounds great. closed_date in the bulk export model already provides the same information as status does in GeoReport v2 -- if closed_date is null or empty, the GeoReport v2 status is "open", otherwise the GeoReport v2 status is "closed". And closed_date is better than GeoReport status since it conveys more info.
good thinking!
We're publishing on Socrata using 'status' and 'status_notes' as described in the GeoReport V2 specification. If a case is open, there may be in progress information. Closed cases should have the resolution. It is true that a case with no closed date is open. Having the status field available makes it easier to filter only open or closed records:
https://data.sfgov.org/City-Infrastructure/Case-Data-from-San-Francisco-311-SF311-/vw6y-z8j6
via @peterwtux: I think the "status" field should only allow values "open" or "closed" from the GeoReport v2 spec so that consumers of the bulk data can make sense of the status information without any per-jurisdiction customization (and ongoing maintenance when the jurisdiction adds or changes wording of its possible textual status expressions).
More fine-grained status expressions like "Processing" or "Hold" should either go in status_notes, or possibly be stored in another, optional, field. I suggest the name "status_description" for putting such expressions in another field; this suggests the relationship to "status" and that it is textual (i.e., likely to contain words in the primary language of the relevant jurisdiction or customer who created the request).