Permits vs Applications for Permits

[WilsonFarrellToC]

Hi all. We are implementing the BLDS spec to represent our permitting data in our open data portal. I have a question about the Core Permits Dataset. In our town, we take applications for permits that may result in a number of permits being issued. For instance, a hot water heater change out may result in both an electrical and a plumbing permit being issued. New home construction would result in several permits being issued. We have application types and permit types. An application is required for each building job, so a contractor cannot use a single application to build a row of homes; they have to apply for each home separately. I'm not sure what needs to be represented by a single row in the Core Permits Dataset. If I chose to have each row represent as a permit, I am no longer representing what the application was for (e.g., I don't know someone was changing out a hot water heater because I only know that they were issued an electrical and plumbing permit at the same time). If I choose to represent each row as an application, I loose the fidelity of the scope of work as indicated by the permits issued. My feeling is (because we have fairly granular application types) that I would have each row represent an application. If we need to provide permit level data we can do so using our own spec. What was the intent of BLDS spec with respect to the possible one to many relationship between applications and permits?

Thanks for any clarification you can provide.

[mheadd]

@WilsonFarrellToC I think the intent was to group together permits that were part of a larger project (perhaps analogous to an application in the description you provided) by using the project fields that are part of the optional BLDS fields:

Field	DataType	Description
ProjectName	TEXT	Name of the project related to the permit
ProjectID	TEXT	ID within the jurisdiction’s database of the project related to the permit

If you did represent each row as a permit, would it be possible to tie multiple permits to the same application using these fields?

[WilsonFarrellToC]

Thanks for the reply. I did see the ProjectName and ProjectID fields and considered using it that way, but the issue is that we lose all of the information at the application level, which we feel is where the value is for the customer. What work is being performed at a location? If I see electrical & plumbing permits, I lose the information that they are replacing a hot water heater. Further, we have applications that are never permitted because they are cancelled before they get that far. We want to show that data, too, as it better represents the amount of work we are performing. Finally many of the mapped field values that BLDS uses more closely align with our application statuses, types and classes. Unfortunately the spec really did not map to our internal business process very well and we have had to adjust accordingly through an ETL process.

[mheadd]

@WilsonFarrellToC: Understood. This seems like it might be the way to go then:

My feeling is (because we have fairly granular application types) that I would have each row represent an application. If we need to provide permit level data we can do so using our own spec.

Does this approach still required complex ETL?

[WilsonFarrellToC]

It requires complex ETL either way (permit applications as rows or permits as rows); however one way I have already built the complex ETL. Thanks again.