Six model versions ship side by side, but there is no way to move an instance or a collection from one to another. Loading a v3 document into v5 keeps what still exists and reports the rest as dropped (openMINDS:Deserializer:DroppedProperties), which is the right thing for a reader but leaves the user with no path forward: the dropped properties are lost, renamed properties are not carried over, and split or merged types are not handled.
openMINDS_Python has the same gap and is stricter about it: Collection.load requires a version and raises on any type it does not know, so a v3 file cannot even be read into v5.
Proposal: a migration step, version pair by version pair, that:
- reads with the source version's classes and writes with the target's, so both sets of validators run;
- applies a small table of known renames and type changes per version pair (the pipeline's
alias.json already records class renames; property renames would need the same);
- reports what it could not carry over, per node, in the same shape as the deserializer's dropped-properties report.
Because only one model version can be on the path at a time here, the migration will have to serialize with one version, switch, and deserialize with the other, which is also an argument for #169 on version switching. The migration tables themselves are language-neutral and would be worth sharing with the Python project.
🤖 Generated with Claude Code
Six model versions ship side by side, but there is no way to move an instance or a collection from one to another. Loading a v3 document into v5 keeps what still exists and reports the rest as dropped (
openMINDS:Deserializer:DroppedProperties), which is the right thing for a reader but leaves the user with no path forward: the dropped properties are lost, renamed properties are not carried over, and split or merged types are not handled.openMINDS_Python has the same gap and is stricter about it:
Collection.loadrequires a version and raises on any type it does not know, so a v3 file cannot even be read into v5.Proposal: a migration step, version pair by version pair, that:
alias.jsonalready records class renames; property renames would need the same);Because only one model version can be on the path at a time here, the migration will have to serialize with one version, switch, and deserialize with the other, which is also an argument for #169 on version switching. The migration tables themselves are language-neutral and would be worth sharing with the Python project.
🤖 Generated with Claude Code