Some so called transformative agreements are built on different subsets. E.g. The Royal Society <London> offer such a contract that is listed in ESAC as
However, subscribers are offered three flavours (A, B and S). It seems that ESAC is not granular enough to model the subsets, while to transfer cost data it seems necessary to assign the proper subset.
A practical issue arises as in UIs to enter cost data one has to select the proper contract and ideally a central system will be able to deliver the contract contents (read journals covered). This seems not easily possible with an id that is not granular enough.
Some so called transformative agreements are built on different subsets. E.g.
The Royal Society <London>offer such a contract that is listed in ESAC astrs2023tib
However, subscribers are offered three flavours (A, B and S). It seems that ESAC is not granular enough to model the subsets, while to transfer cost data it seems necessary to assign the proper subset.
A practical issue arises as in UIs to enter cost data one has to select the proper contract and ideally a central system will be able to deliver the contract contents (read journals covered). This seems not easily possible with an id that is not granular enough.
Additionally, there are some workflow issues also mentioned in https://github.com/opencost-de/opencost/issues/15#issuecomment-1431437194 and https://github.com/opencost-de/opencost/issues/15#issuecomment-1450243156 that are also apparent in the above example: the ESAC entry (at time of this writing) refers to 2023, while the contract is actually renewed for 2024. For cost transport it would not be correct to assign papers from a different period to the same id, if said id does not refer to the time span. (openCost addresses multiple years in the contract schema.)
As the issue mainly results from workflow aspects, transform2open might be helpful here.
isRelatedTo: #15