Discussion: Tender location directly tied to tender

[tdavis9]

Makueni County, Kenya has tenders that are directly related to locations, regardless of the items within the tender. We are aware of the OCDS Location Extension but this assumes that items are linked to locations, which is not what we encountered. We have created an OCDS extension that depends and extends upon the OCDS Tender Location extension, but re-uses this entity directly at the tender level

https://github.com/devgateway/forms-makueni/tree/master/persistence-mongodb/src/main/resources/extensions/tender_location

[jpmckinney]

Thanks, @tdavis9. Can you share some sample location descriptors? Does Makueni County have item-level information?

If there is item-level information, the location data can be repeated across all items. To avoid this repetition, there is issue open-contracting/standard#893 about moving some reused content to the top-level. In that case, each item would just refer to the same location.

[jpmckinney]

@yolile @duncandewhurst This use case sounds familiar – not sure if it's come up in other implementations.

[jpmckinney]

@yolile I found one case: in open-contracting/standard#888, all items in a given lot had the same location. That case might also be addressed by open-contracting/standard#893 (without adding a location field to the lot).

[yolile]

@jpmckinney yes, that was the case in Paraguay. I recently have seen that in Peru the same happens with the contracts from a framework agreement, where the location is at contract level, example: https://apps1.perucompras.gob.pe//OrdenCompra/obtenerPdfOrdenPublico?ID_OrdenCompra=1109816&ImprimirCompleto=1

page 2

[mpostelnicu]

Thanks, @tdavis9. Can you share some sample location descriptors? Does Makueni County have item-level information?

If there is item-level information, the location data can be repeated across all items. To avoid this repetition, there is issue open-contracting/standard#893 about moving some reused content to the top-level. In that case, each item would just refer to the same location.

@jpmckinney yes we do have items but since in some cases there can be a lot of them, we wanted to avoid repetition to keep the OCDS json smaller. open-contracting/standard#893 sounds like a great idea.

[duncandewhurst]

I found several examples of systems with location at the tender level.

• In NSW Australia's eTendering system, a tender's location can be a list of NSW regions and/or Australian states and territories (example).
• In Australia's AusTender system, a tender's location can be a list of Australian states and territories and/or state capitals (example).
• In New Zealand's GETS system, a tender's location can be a list of New Zealand regions (example)
• In the UK's Contracts Finder system, a tender's location can be a lat/long, a postcode or a region (mapping)

Similar to the relationship between the tender classification extension and the item classifications, I think this points to a need for a tender location in addition to item locations.

[jpmckinney]

What is the meaning of those locations? Delivery locations like in the location extension?

On that understanding, I'll move this issue to ocds-extensions, as it relates to the Location extension.

[duncandewhurst]

For the UK and Australia NSW, the semantics aren't clear from the definitions, which are 'the location of the Contract' and 'the geographic location(s) of the RFTs or Contract Notices' respectively. For AusTender and GETS, we don't know the definitions.

In GETS, I think it's safe to assume they are delivery locations rather than the location of the procuring entity, since I found examples where buyers based in one region issued tenders/contracts covering other regions, e.g. Northland Regional Council issued a tender with both Northland and Auckland listed as locations. Although many notices just have 'New Zealand' in the location field.

In NSW eTendering, AusTender and Contracts Finder, use of the field seems inconsistent. Some notices seem to use it for the delivery location (examples: 1, 2, 3) whilst others list many locations even when the tender clearly relates to a single delivery location (examples 1, 2, 3).

My sense is that procuring entities are probably entering location information into a field that is simply labelled 'location' and are variously interpreting it as:

• Delivery location
• The location(s) in which I think interested suppliers might be based
• The geographic scope of my organization

So I don't think the semantics are any more precise then 'what the procuring entity thinks of as the location of this tender'.

In the UK and NSW at least, procuring entities enter data using third party systems, so how the location is presented/described in those systems might vary and some systems might just select all locations by default.

On the one hand, this seems like a bad candidate for standardisation, on the other hand, a tender-level location field is clearly a common feature of procurement systems. It's possible analysts might want to do something with the data, even if it is loosely defined.

[jpmckinney]

If the data is more or less "semantic-free" ("here is some location data, but we can't tell you what it means") then that's a good candidate for a local extension.

I think tender/lot-level delivery location is fine, and can use the same names as the fields that appear under items.

It's not clear to me what use cases the other two support. They seem to be equally supported by the location/address information of the buyer or procuring entity.

[duncandewhurst]

Ok great. I think it makes sense to add those fields at the same time as merging the extension into the OCDS schema. Sound good?

[jpmckinney]

As noted in open-contracting/standard#1179, let's make a PR against the Location extension first.