Data/label version tag

[nrweir]

As we were working on the label extension at Sprint 4, we discussed the idea of creating a "label:version" tag to identify label files where multiple versions existed. In our minds we saw two scenarios where this could happen:

1. A set of labels are iteratively updated based on the same source image, for example after validation or due to incomplete labeling during a first pass (a common phenomenon for OSM)
2. Multiple labelers may independently create complete label sets based on the same source data, which are then aggregated somehow into a single validated version.

In both cases, it would be great to have a means to identify different versions of an asset or item which has some intrinsic relationship to other versions of the same object. This was discussed a bit in #362 and it was determined it shouldn't be restricted to the label extension, as it may be appropriate for other item/asset types.

A few questions related to this:

1. Is including something like this a good idea in general?
2. Should it be at the Asset or Item level? I think the main reason to have it at the asset level would be if a single item could potentially include different versions of the same label - should that type of structure be supported?
3. What should it be called? "version" could get confusing with "stac_version".

[m-mohr]

Adding a version number to the Item seems reasonable. We have it similarly in the collections. There, they are called version and stac_version and live alongside each other quite well. Currently, there's no stac_version in Items anyway.

[matthewhanson]

Versioning is something that is definitely reasonable, but it's different than other properties so I don't think it's as simple as just adding a version field. In fact, I think the collection version field suffers from the same issue.

A version is not a separate record. It is a different version of the same record.

As a user I typically want the latest version of any specific Item (or Collection).
However, for data provenance I also want to be able to link to any previous version of an Item or Collection.
But when I search I do not want every version, I only want the latest.

So the issue here is that if you want them to be separate records then the version has to appear in the ID, but then that means they are separate records that will all get returned in a search.

So I think version is quite distinct than other metadata fields and deserves special consideration.

[nrweir]

One other potentially relevant use case for labels, though this may be less relevant for non-label formats, would be "parallel" versions. For example, a common part of crowdsourced labeling pipelines is to have multiple people generate "preliminary" labels for a given piece of imagery, which are then merged by an expert validator to generate the final version. These preliminary versions would likely be numbered in some fashion, though the sequence doesn't have any intrinsic meaning in that case. There, you wouldn't necessarily just want the most recent one. I recognize this is probably something of an edge case, though, and not necessarily something we need to structure version tagging around.

[m-mohr]

So I think version is quite distinct than other metadata fields and deserves special consideration.

Agreed, for example I would see it as a top-level field like in collections and not as part of properties.

[m-mohr]

So I think version is quite distinct than other metadata fields and deserves special consideration.

Agreed, for example I would see it as a top-level field like in collections and not as part of properties. Reason is that otherwise it would also be handled by Commons and Summaries, which doesn't make any sense.

[m-mohr]

Related to #635

[m-mohr]

Closed as duplicate of #557