Use simpler naming conventions for chicago.opengrid.io

[tomschenkjr]

Data was loaded into Plenario from the Chicago Open Data Portal are long names, such as Crimes_2001_to_present. This impacts the usability for the Quick Search (e.g., Crimes_2001_to_present 60602) and the display under "Add Datasets".

After UrbanCCD-UChicago/plenario#222, we simply used the default naming conventions from the portal. We should switch to shorter naming conventions.

@willengler - is there a way to do this easily or should we re-add data to the portal?

[WillEngler]

No way to do this easily now, and that's largely by design. From the admin panel, you can easily update other user-provided metadata, like the description. You can even change the human_name, but that won't trigger an update of the dataset_name. There are two reasons for this:

• Technical reason: We use dataset_name as a pointer to a table with the same name where we can go fetch data. We could enable editing to dataset_name as long as we emit an ALTER TABLE on edit. Or, as you suggested, we could circumvent that entirely by re-ingesting the datasets with new names and then deleting the old dataset.
• Stability reason: dataset_name is the id that client applications use. So if we changed crimes_2001_to_present to crimes, applications set up to fetch from crimes_2001_to_present would break. Using a name to identify datasets as opposed to, say, an integer is really helpful for making ad-hoc API calls readable for the human who is composing them.

The stability reason makes me really reluctant to allow changes to dataset_name, even if we could work around the technical barrier. Is it feasible to add a lookup table in OpenGrid that could map crimes to crimes_2001_to_present and then launch a query against Plenario? Hope that doesn't come off as me punting the problem off to you. I just want to really vet other options before considering making a breaking change.

[tomschenkjr]

@WillEngler - thank you. You bring up a good point with the human name as that's a potential leverage here.

@nfspeedypur & @uturndata - if I understand correctly, one way to make names more user-friendly in the application is reference the human_name since that can be edited. That is, the query is using the dataset_name, but the UI could display human_name.

I realize this would take some work, but just wanted to raise it.

[smarziano]

I just wanted to add to this thread based on our CUTGroup test experiences. In the quick search, we found that the "Help (?)" text was unclear for testers. One example is a tester read the information in this help box and read that “business_license 60601” was a possible search, so she tried “business license 60647." This did not work because her search term lacked the underscore.

A user should be able to see their options when searching "business" and should not need an underscore to match the dataset name.

Lastly, the promo video that is on the homepage provides example searches that are not possible without underscores.