open-data-standards
Contractor data set fields
Why do all the fields have a number 2 attached in the contractor dataset schema? Does this make sense?
The Core Permits Dataset has the primary contractor fields, and those are from the Optional Contractor part of the spec.
In some cases, more than one contractor may be associated with a given permit. The contractor information included in the core dataset should be for the primary contractor. If additional contractors need to be associated, additional datasets for each contractor may be submitted and lined to the core dataset through the following information.
I would be interested in moving the documentation for these into the same page so you don't have to jump around and avoid confusion.
I do not think the documentation needs to move to the same page.
I perfectly understand that this is supposed to be a separate "Contractors" table right. As such why would you need a number 2 in the name for each field?
I agree that appending a "2" to field names is confusing as well as makes field discoverability difficult. I assume that if there are 2 optional contractors the second optional contractor would have a "3" appended. So to discover all the contractors, one would have to walk through all numbers (if the 2nd contractor is removed, would it automatically renumber?).
It seems like there should be a consistent contractor resource object that is stored in a collection list.
New to the group, so I apologize if this has been hashed out before. I did search the github conversations and did not see anything that was quite relevant to my comments. Also, feel free to take my observations with the appropriate grain of salt.
I agree that the 2 is not required. I would go onto say that the word contractor is not needed either as that is implied by the table name.
I would go even further to say that having the "required" contractor information in the permit structure makes this difficult to query as well. I would like to see all Contractors listed in the contractor structure and if we need to make one required, the spec should require a "1 or more" relationship to permits. A primary flag could be added to say which is primary. As a result the contractor fields in the permit could be removed. However, it could be in both locations, as far as the open data/public facing aspect goes, with the primary contractor listed in both the permit data and the contractor data. I would hope that the back-end data source would only have contractor information in one table (the back-end should really be a many-to-many mapping between a contractor table and a permit table). As it currently is, to get all the contractors for a permit, I have to perform two queries.
Thanks
@WilsonFarrellToC This is exactly what I was trying to get at. I totally agree with your comments.