Update sources details to provide the version

[ericgodwin]

Background

The current sources field of the schema contains an array of sourcePropertyItems. Each item contains the following elements

- property: which property of the feature the source is associated with
- dataset: the dataset identifier, the name of the source
- license: the license that the data falls under
- record_id: the feature source identifier (how you identify the input feature in the dataset)
- update_time: inconsistently applied, but the time that the source data was last updated
- confidence: even more inconsistently applied, but how confident we are in the quality of the data or its existence

The goal here is to provide provenance for our data allowing users to track back and see what Overture data was constructed from. In other words the user can look at the specific record_id within the identified dataset and see where the data really comes from. The problem with this is that our dataset identifier is not unique; we are missing version information. As such I would suggest that we update our sourcePropertyItem definition to include the following:

- property: unchanged
- dataset: unchanged, but will be put on a deprecation path
- license: unchanged
- record_id: unchanged
- update_time: unchanged
- confidence: unchanged
- provider: The name of the entity that produced the data: meta, esri, microsoft, osm, etc.
- resource: The subject or type of data given by the provider: division-names, buildings, planet, etc.
- version: The sortable identifier such as a date or number: 2026-02-13, 5.3, A5692

Basically the dataset is being broken up into the provider + resource. This is being done because a number of our providers give us multiple resources and we want to make it easy for users to filter either a single resource or all. When combined, the provider + resource + version uniquely identify a specific input data snapshot and the record_id can be used to find the specific entity.

[ericgodwin]

We had a more detailed discussion about this and as such I wanted to add a few clarifications:

• The three fields should be added directly to the sourcePropertyItem next to where the current dataset lives. In other words we are not going to add a snapshot structure which encapsulates the provider, resource, and version.
• We are going to have a multi-phase roll out plan.

    Step 1 (covered by this issue): add the three new fields allowing them to be optional and nullable.
    Step 2 (after the pipeline is populating these fields): come back and mark dataset as deprecated and make these fields required and non-nullable.
    Step 3 (after 6m to 12m): remove the dataset field.

• All 3 fields should be strings of at least length 1, optional, and nullable.
• Basic tests and anti-pattern examples should be added to the code base as part of the work.