Benchmarks and systems need versioning so you can use a specific version for an experiment and also have experiment results grouped by version. It will also allow to compare results from different versions of the same product.
We need to be able to define a latest version (or several, one of them should be marked as "default") which will be continuously updated
and several tagged versions which we don't intend to change.
It would also be good to support benchmarks and systems defined in the old way.
Solution
Benchmark and system resources will have per-version URI and basically would be "benchmark version" and "system version" resources.
There should be some kind of benchmark resource which will unite all versions of the same benchmark. The same for systems.
UI will need to let pick a benchmark first, then a benchmark version.
User story
Benchmarks and systems need versioning so you can use a specific version for an experiment and also have experiment results grouped by version. It will also allow to compare results from different versions of the same product.
We need to be able to define a latest version (or several, one of them should be marked as "default") which will be continuously updated and several tagged versions which we don't intend to change.
It would also be good to support benchmarks and systems defined in the old way.
Solution
Benchmark and system resources will have per-version URI and basically would be "benchmark version" and "system version" resources.
There should be some kind of benchmark resource which will unite all versions of the same benchmark. The same for systems.
UI will need to let pick a benchmark first, then a benchmark version.
Ontology changes
Examples
benchmark.ttl
system.ttl
Steps