Whenever possible, we should use tested and already implemented ways of storing the data. An example of this is the “agency” object, which in a standardized form turns into ‘organization' (popoloproject.com). Here is a list of the objects that we have and potential sources for where we can find a way to standardize them (https://docs.google.com/document/d/1USFMTHfrmBzDvNW08b2f6osyl9I375d7h47uGcvxXjY/edit?usp=drive_web). So far, we have only standardized “'agency' -> ‘organization'" so there is a lot to grab. - Mikael
Separate current schema into a set of sub schemas, each based on a data standard, and then normalize based on that. (Let’s use open-contracting.org as the gold standard - if the field exist a certain way there, we can use that nomination for the other attributes as well.)
Procurement - open-contracting.org
Public Hearing - ?
Property Disposition - ?
Court Notices - ?
Rule Details - ?
Standardize remaining terms in the notice skeleton and notice attributes.
Create strategy for how to combine the different sub-schemas with the notice skeleton (both how we store the objects and how they appear in the API Schema).
Whenever possible, we should use tested and already implemented ways of storing the data. An example of this is the “agency” object, which in a standardized form turns into ‘organization' (popoloproject.com). Here is a list of the objects that we have and potential sources for where we can find a way to standardize them (https://docs.google.com/document/d/1USFMTHfrmBzDvNW08b2f6osyl9I375d7h47uGcvxXjY/edit?usp=drive_web). So far, we have only standardized “'agency' -> ‘organization'" so there is a lot to grab. - Mikael