Embedded values vs links to other datasets

[ejaxon]

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.

[mheadd]

@ejaxon Ah, I can see why the relationship issue would be important given that you are using GraphQL. Will be interesting to see that when it's ready. Can you share when it is publicly available?

[mheadd]

@ejaxon In the interim, I've labeled this for consideration as an enhancement so we can take it up in the next round of changes.

[ejaxon]

Yes, absolutely will share - it's all intended to be both internal and part of open data and SimpliCity. Some data challenges (surprise!) have slowed things, but definitely by January.