Different kinds of tender notice

[birdsarah]

What types of notice should we capture. From the canadian dataset (expired notices):

• Advance Contract Award Notice (ACAN)
• Invitation to Tender (ITT)
• Letter of Interest (LOI)
• Notice of Proposed Procurement (NPP)
• Price and Availability (P&A)
• Request for Information (RFI)
• Request for Proposal (RFP)
• Request for Quotation (RFQ)
• Request for Standing Offer (RFSO)
• Request for Supply Arrangement (RFSA)

[practicalparticipation]

How would notices be rendered in the standard? Would there be a particular release type for each of these - or would be they be classifications applied to a release?

[birdsarah]

At the moment, we've got the following releaseTags in releaseMeta: planning, tenderNotice, awardNotice, contractSignature, contractAmendment, report, spending, terminationNotice

This list is an interesting mix of different kinds of tenderNotice and different kinds of contracting e.g. Standing Offer vs RFP....or maybe you could read it as entirely different kinds of contracting process. I'm not 100% sure.

We also don't have a place that describes that - which I'm thinking we should add, but maybe it should be freetext as I'm not sure people are going to agree on a shortlist of terms and I'm not sure its necessary to have it as standardized info.

[birdsarah]

Doing this would also allow to mark something as a framework agreement / consolidated purchase / standing offer etc.

[practicalparticipation]

Would it be useful to space for arbitrary classifications within the standard? I can envisage two kinds: structured taxonomies, and boolean flags (e.g. I think UK Contracts Finder data has lots of flags for whether tender was targetted at SMEs etc... or at least version of the data I saw had at one point).

This could work such that under most of our top-level sections allowing the use of a classification property, which would refer to a block of the form:

{
"classificationScheme": {
      "description": "A URI for this classification scheme, providing at least a human readable description of the classifications used.",
      "type": "uri"
    },
    "classificationID": {
      "description": "The classification ID from the Scheme used",
      "type": "string"
    },
    "classificationDescription": {
      "description": "A description of the classification.",
      "type": "string"
    }
}

And similarly at particular points we could allow a block of 'flags' of which we might allow

{
"flagScheme": {
      "description": "A URI for this scheme, providing at least a human readable description of the flags used.",
      "type": "uri"
    },
    "flag": {
      "description": "The name of the flag being applied",
      "type": "string"
    },
    "value": {
      "description": "A boolean value for whether this flag is true or false.",
      "type": "boolean"
    }
}

We could then maintain a core list of Open Contracting classification and flag schemes, and/or map from widely used schemes to a common one, allowing users to reconcile different datasets - whilst also leaving things flexible enough for different existing contracting information to be expressed.

(As an aside, we might want to apply the idea of a classification scheme being identified by URI rather than string also to the classification of items, with OCDS providing approved URIs for these schemes).

[birdsarah]

Yes, we can always use custom scheme's mappings (I remember us agreeing this already). I would recommend re-using our identifier definition in that case:

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string"
    },
    "scheme": {
      "description": "The scheme that holds the unique identifiers used to identify the item being identified.",
      "type": "string",
      "format": "uri"
    },
    "uid": {
      "description": "The unique ID for this entity under the given ID scheme.",
      "type": "string"
    },
    "uri": {
      "type": "string",
      "format": "uri"
    }
  },
  "required": [
    "name"
  ]
}

This issue is more about whether to have a noticeType field, does it add value, especially given that everyone has their own naming scheme. Would it be better for OCDS just to bring out a keyCases e.g. isFrameworkContract

[practicalparticipation]

Perhaps:

• Where lots of people have a particular kind of classification, but different codelists, we might include a specific classification property, rather than simply making this an entry in a classifications object, but use the identifier definition (so they would need to specify the scheme in use). This would be a political choice to say (a) this kind of classification is important and valued; (b) might allow us to move towards a preferred scheme over time.
• Where there are strong use cases to know things like 'isFrameworkContract', and publishers either have, or could have, data which would let them set this flag, then we bring these things out.

We might have to come up with a long-list of those possible key case flags, and then work out a priority set?

[timgdavies]

We've not found further demand for structured data to distinguish different process types.

The original proposal in this issue of using free text in the titles/descriptions appears to work.

Closing - but can re-open if future demand.