If there are multiple versions of the same dataset with separate indexed metadata records, ideally a search client should be able to filter search results to show the most recent version, and ideally indicate there are multiple versions with links to older version metadata. This issue has come up with the EarthCube GeoCodes Registry, see https://github.com/earthcube/facetsearch/issues/74.
To start discussion, I'd suggest that the schema:identifier always identify the root dataset, with the schema:version property used to identify versions of that datasets. Schema.org rangeIncludes for schema:version is number or text. If numbers are used, the version number with the greatest value should always be the most recent version. If the schema:version value is a string, then the last value in an (English language) alphanumeric sort should be the most recent version. Note that if a standard major.minor.patch approach is used for the version string, all values would need to be included, e.g. version 1.0.0, not version 1 or 1.0 (those look like numbers), and if more than 10 values might occur, the values need to be 0-padded so they sort properly, e.g. 01.05.00 (if there is a 01.10.00 minor release).
If there are multiple versions of the same dataset with separate indexed metadata records, ideally a search client should be able to filter search results to show the most recent version, and ideally indicate there are multiple versions with links to older version metadata. This issue has come up with the EarthCube GeoCodes Registry, see https://github.com/earthcube/facetsearch/issues/74.
To start discussion, I'd suggest that the schema:identifier always identify the root dataset, with the schema:version property used to identify versions of that datasets. Schema.org rangeIncludes for schema:version is number or text. If numbers are used, the version number with the greatest value should always be the most recent version. If the schema:version value is a string, then the last value in an (English language) alphanumeric sort should be the most recent version. Note that if a standard major.minor.patch approach is used for the version string, all values would need to be included, e.g. version 1.0.0, not version 1 or 1.0 (those look like numbers), and if more than 10 values might occur, the values need to be 0-padded so they sort properly, e.g. 01.05.00 (if there is a 01.10.00 minor release).