Extend capture of schemaVersion beyond just schema.org version

[gtsueng]

Is your feature request related to a problem? Please describe.
The ability to capture schema versions is very important for data validation. Metadata json files or markup generated to be compliant with one version of a schema may not be compliant with a newer version of the same schema. A new schema (B) extended from a specific version of a different schema (A) may have irrelevant properties if those properties get deprecated in the next version of of the schema (A).

Describe the solution you'd like
Capture the version information from the extended schema if available. We currently use the field schema:schemaVersion at the class level to capture which version of the schema.org schema that a class was extended from a schema.org class.

Describe alternatives you've considered
Some options discussed at the weekly internal meeting on 2025.05.06:

• Have the DDE automatically set schemaVersion at the schema level using timestamps if schemaVersion at the schema level are not available. Then apply this information to the schemaVersion for any class extended from that schema.
  • Example: mytest:TestSubstance extended from bioschemas:ChemicalSubstance would have:
    • schema:schemaVersion set to ['https://schema.org....version, 'bioschemas schemaversion']
  • Pros: easier to handle from the DDE side
  • Cons: DDE only supports the latest version of a schema at a time. If the schema is from a single file that's constantly being overwritten, there's no way to know what the changes were unless they are logged in a separate file somewhere. Schema maintainers would need to maintain a separate change log for the schema files.
• Leverage the schema:schemaVersion at the class level if one is available. If a schema:schemaVerison is available at the class level, included it in the schema:schemaVersion for the extended class.
  • Example: mytest:TestSubstance extended from bioschemas:ChemicalSubstance would have:
    • schema:schemaVersion set to ['https://schema.org....version, 'bioschemas:ChemicalSubstance schemaversion']
  • Pros: The DDE editor only works at the class level, thus output files of the DDE are always at the class level. This means that DDE output files can (and often are) versioned and maintained separately at the class level, so even if a schema references an older version, it would still be possible to point to an actual file
  • Cons: More difficult to automate from the DDE side and requires more info from the schema creator side. Schema creators would need to version their class-level json files and store them, if not, there's no way to point to the schemaVersion at the class level.

Additional context

• The schema:schemaVersion in multiclass schemas have to be manually added at this point in time, else that information isn't really found anywhere except in the description.
• Resolving the issue with schema versioning is an important first step for resolving the issue of explaining changes between versions of a schema or class (see enable the capture of schema changes #209)