techniques: Expressing existence of an object when their is no other data than its mere existence

[ColinMaudry]

Example : electronic auctions.

One may want to express in OCDS that a procedure will use electronic auctions, but has no more data than just "there will be electronic auctions". No details, no URL of the auctions, no dates, no specific type of electronic auctions...

The issues that it causes is that, with a simple object structure as the following, the data producer ends up with an empty object ("electronicAuction": {}), which doesn't have semantics in OCDS practice, and it could consequently puzzle data reusers or mess up with the merge to OCDS records:

"tender": {
    "electronicAuction": {
        "url": "",
        "details": ""
    }
}

In order to have a model that is both expressive for producers and clear for reusers, I suggest the following pattern (you can replace electronicAuction with frameworkAgreement or dps):

"tender": {
    "electronicAuction": {
        "url": "",
        "details": ""
    },
    "hasElectronicAuction": true
}

Using this model, if any property such as tender.electronicAuction.url or tender.electronicAuction.details would make tender.HasElectronicAuction = true optional.

[ColinMaudry]

@jpmckinney @duncandewhurst Feedback welcome :)

[PaulBoroday]

@ColinMaudry this issue (expression of using eAuction) is already solved here

[ColinMaudry]

@PaulBoroday Thanks! I hadn't spotted the procurementMethodModalities extension (fixed link), and I didn't suspect its existence since it's not mapped for TED F01 (section IV.1.6).

[jpmckinney]

That extension was drafted based on the much more general requirements of GPA, without the benefit of having analyzed TED or eForms. GPA adds no details for electronic auction, so at the time, putting it in a list of codes seemed okay.

Having worked more on TED/eForms now, some of that extension's codes can be better represented in other ways. For example, joint procurement is true anytime there is more than one party with the role of 'buyer'.

The hasSomeProperty and someProperty pattern might also be better than an open codelist, as it is more constrained, and therefore easier for users to interpret. One issue with that extension is that some publishers consider putting a wide variety of codes into it, instead of exploring other models.

That extension is not yet in the extension registry or Extension Explorer, so it is still subject to major change. As such, we can update that other extension if we develop more specific alternatives like this one.

[ColinMaudry]

That extension is not yet in the extension registry or Extension Explorer, so it is still subject to major change. As such, we can update that other extension if we develop more specific alternatives like this one.

I guess it means this extension (procurementMethodModalities) is not vastly used in production. In any case, we can tag the current version to make rollbacks easy.

I guess it also means I should remove electronicAuction from procurement_technique_extension.

@jpmckinney General remark: you prefer these discussions to take place in https://github.com/open-contracting-extensions/european-union, right?

[jpmckinney]

I guess it also means I should remove electronicAuction from procurement_technique_extension.

I'm not sure which is better: hasElectronicAuction or a code in a codelist. What do you think?

I think it's okay to have discussions on the extension itself during its development. Once we're satisfied with a draft, we can move any remaining issues over.

[ColinMaudry]

We should go with hasElectronicAuction, and an electronicAuction object. That would be both clear and easy to implement.

The codelist approach should only be for "leaf" concepts, concepts that don't have properties of their own.