Here at the City of Asheville, we're using this as a starting point for building not just the open dataset for permits, but our internal "canonical representation" as well. One consequence is that we want to encode the relationships between different datasets (e.g., addresses, contractors, owners). Thus, while we may well include ContractorCompanyName in the main permits dataset, we would add something like the contractor id rather than including the rest of the contractor information. And we might also just include an array of contractor IDs rather than (or in addition to) the optional contractor dataset.
Obviously nothing in the standard prevents this, but it would be nice to clearly indicate the relationships as part of the dataset. It might be worth integrating this somehow into the optional dataset information (https://github.com/open-data-standards/permitdata.org/wiki/Optional-Dataset-Information-Requirements). I'd be interested in discussing/collaborating on how best to do this for a REST API version of the data.
Incidentally, the other way we'll be publishing this is through a GraphQL endpoint. The advantage there is that we can actually encode all the dataset relationships directly into the schema so that we don't have to have a separate metadata source to encode. it.
Here at the City of Asheville, we're using this as a starting point for building not just the open dataset for permits, but our internal "canonical representation" as well. One consequence is that we want to encode the relationships between different datasets (e.g., addresses, contractors, owners). Thus, while we may well include ContractorCompanyName in the main permits dataset, we would add something like the contractor id rather than including the rest of the contractor information. And we might also just include an array of contractor IDs rather than (or in addition to) the optional contractor dataset.
Obviously nothing in the standard prevents this, but it would be nice to clearly indicate the relationships as part of the dataset. It might be worth integrating this somehow into the optional dataset information (https://github.com/open-data-standards/permitdata.org/wiki/Optional-Dataset-Information-Requirements). I'd be interested in discussing/collaborating on how best to do this for a REST API version of the data.
Incidentally, the other way we'll be publishing this is through a GraphQL endpoint. The advantage there is that we can actually encode all the dataset relationships directly into the schema so that we don't have to have a separate metadata source to encode. it.