Update mappings for BT-01 (Procedure Legal Basis)

[duncandewhurst]

The following eForms fields are both mapped to tender.legalBasis.id:

id	name	mandatory	repeatable	description	documentation
BT-01-notice	Procedure Legal Basis	PIN PIN(CN) CN CAN(VEAT) CAN CAN(MOD) CEI T01 T02 X01 X02	false	The legal basis (e.g. a Union or national legal act) under which the procurement procedure takes place or, in case of prior information notices, under which the procurement procedure(s) will take place.	Procedure Legal Basis
BT-01(c)-Procedure	Procedure Legal Basis (ID)		false	The legal basis (e.g. a Union or national legal act) under which the procurement procedure takes place or, in case of prior information notices, under which the procurement procedure(s) will take place.	Other Legal Basis (BT-01)

Whilst both fields share the same description in guidance.yaml, the eForms documentation clarifies that:

• BT-01-notice should reference either the CELEX number of the EU regulatory domain that applies to the procurement (for above-threshold notices) or the code 'other' (for below-threshold notices).
• BT-01(c)-Procedure should reference the local legal basis for the procurement, e.g. by its European Legal Identifier (ELI).

The mapping is likely to cause a conflict in two scenarios:

1. Referencing both an EU directive and it's transposition into national law: Implementers might map both the CELEX number for an EU directive and the ELI for its transposition into national law to tender.legalBasis.id. For example, in the UK (pre-brexit) the Public Contracts Regulations 2015 (ELI: https://www.legislation.gov.uk/id/uksi/2015/102) was the act that implemented EU Directive 2014/24 (CELEX: 32014L0024).
2. Referencing an EU directive by both its CELEX number and its ELI: Implementers might map both references to tender.legalBasis.id because the eForms documentation gives the ELI for Directive 2014/24 as an example value for BT-01(c)-Procedure. I think that's a mistake (see https://github.com/OP-TED/eForms-SDK/discussions/1064)), but implementers might follow the example.

To resolve the first conflict, @jpmckinney suggested:

As for our mapping, I agree that the Directive and its transposition into local law are two different concepts. The legalBasis field, as defined, is appropriate to the transposition. Right now, our mapping puts the Directive in that field, as a shorthand for the local law; however, it would be better to use that field for the transposition only.

The Directive, itself, is more like a property of the transposition, e.g. "local-law prov:wasDerivedFrom 2014/24". We can perhaps change legalBasis from using the Classification definition, to re-using the necessary fields (maybe just scheme, id, url), plus a wasDerivedFrom object with scheme, id, url fields.

That sounds good to me. Here's what it looks like in JSON:

{
  "tender": {
    "legalBasis": {
      "id": "https://www.legislation.gov.uk/id/uksi/2015/102",
      "scheme": "ELI"
      "wasDerivedFrom": {
        "id": "32014L0024",
        "scheme": "CELEX",
        "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011R1007",        
      }
    }
  }
}

Since BT-01(c)-Procedure isn't mandatory in eForms, we might end up with data that looks like this:

{
  "tender": {
    "legalBasis": {
      "wasDerivedFrom": {
        "id": "32014L0024",
        "scheme": "CELEX",
        "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011R1007",        
      }
    }
  }
}

That's equivalent to saying that all we know about the legal basis for the procedure is that it was derived from Directive 2014/24. I think that's OK since EU member states must transpose EU directives into national law. I don't know if a procedure can take place on the legal basis of a directive before that directive is transposed into national law. That's the only scenario I can think of where the above modelling might be incorrect.

To resolve the second conflict @jpmckinney suggested:

If the ELI and CELEX refer to the same thing, our guidance can be to just refer to it via CELEX (unless there's some indication that ELI is preferred). There's no reason to have multiple identifiers for legislation.

I agree that there's no reason to have multiple identifiers. A challenge with the proposed approach is that it leaves it up to OCDS for eForms implementers to identify when an ELI and a CELEX refer to the same thing. We could provide a look-up table based on adding ELIs to the EU's legal basis codelist, but (subject to the outcome of https://github.com/OP-TED/eForms-SDK/discussions/1064) this situation would only occur when there is an error in an eForms implementation so I think providing guidance is sufficient.

---

We'll also need to update the mapping for BT-01-notice to handle the 'other' code and the mapping for BT-01(c)-Procedure to handle non-ELI identifiers.

[jpmckinney]

That's equivalent to saying that all we know about the legal basis for the procedure is that it was derived from Directive 2014/24. I think that's OK since EU member states must transpose EU directives into national law.

Indeed, I think it's an appropriate model for incomplete data.