juanpane
commented
9 years ago hi:
the proposal of concatenating IDs is technically possible, which would lead to a representation of something like this:
When we have multiple awards and a contract per award, the id of the award is the concatenation of the award id and the contract id. In this case, the list of suppliers of a award is a single element array. The problem with this solution is that the data doesn't reflect the reality, because in Paraguay, a tender can have multiple awards, but only one active at any moment, with this schema we will have multiple active awards and a subset of the awards can be active. For example, what can happen, and does happen, is that there is an award, and later this award is cancelled because of some problem in the process, later, another award is made, which is the valid one. In this case, it looks like we are trying to fit the reality to the model, rather than modelling the reality.
Another option, proposed by the Government (DNCP), is to add a supplier (id or the organization class) in the contract. This would extend the standard which is possible, and would model the real process in Paraguay, providing a simple solution to the problem. The data in open contracting would look something like this
As can be noted, the image above is more similar to the initial image of this ticket, and does not break the standard either.
Out of these 2 alternatives, the DNCP is more comfortable with the second, since it model the Paraguayan contracting reality. Even more considering that there is few publishers of open contracting, perhaps this addition of supplier in the contract can be included in the second version of the standard.
Furthermore, considering the fact that one award has an array of suppliers and the amount per contract is in the contract, there is no way to have a ranking of suppliers by the sum of their amount of all its contracts, unless there is a one to one correspondence between one award and one contract (information that seems to be lacking in the documentation). However, if this is the requirement (1to1), then the supplier property in the award does not need to be an array, but a single object. All of this seems to raise a flag that further revision is needed in this part of the standard.
timgdavies
From conversations with @juanpane:
This can be seen visually in this example (below)
However, in OCDS, we name the supplier at the award level, not the contract level, so this single award in the Paraguay case would need to be modelled as a collection of entries in the award array, each award including a single supplier and the relevant items or lots.
Discussion
Implementation issues
This raises one practical implementation issue around assigning an award id as the Paraguay data has a single award ID here.
This could be resolved by concatenating the award id and supplier id, or award and a hash of relevant values from the award.
@juanpane to check if this is an acceptable and practical way to model the data.
Documentation issues
Modelling the data in this way for OCDS does mean that the OCDS concept of 'award' is not directly identical to the Paraguay concept of an 'award'.
This kind of information could be added to the page referenced from the
publicationPolicylink of a release package, for example, to state something along the lines of:"In Paraguay, each tender results in a single award, which contains information on the items and lots awarded to each supplier. In the OCDS standard, this is represented as an array of separate award objects. All award objects with the same OCID should be considered as part of the same award."