memberOf: OrganizationReference's that don't resolve

[jpmckinney]

The readme has (emphasis added):

The parties.memberOf property can be used to indicate the relationship between a party and some other party, association or grouping.

Is not require that the party identified by memberOf.id exists in the parties array, but implementations could choose to include it, so that it is possible to represent a tree-structure of multi-level hierarchy. A memberOf object should not be an object in the parties array unless it is semantically a party i.e. "involved in the contracting process". If the party is only referred to by memberOf, that's an indication that it's probably not involved in the contracting process.

We strongly recommend against populating memberOf unless a use case supports it.

An important structural check (I forget if this is implemented in CoVE) is to check whether all OrganizationReference's resolve to an object in the parties array. The guidance here would contradict that check.

I understand the reason to not put all values of memberOf into the parties array. I think the resolution might be to use a different class than OrganizationReference. We can either use Organization itself (encouraging publishers to limit it to id and name if the organization is already described in the parties array), or perhaps some new class.

Eager to hear other's thoughts.

[yolile]

I like the idea of a new class more. Maybe one with only name, id and url/uri to point to a page with more info in case the Organization doesn't exist in the parties array?

[jpmckinney]

Sounds good to me. What do you suggest as the new class name?

[yolile]

Maybe ExternalOrganizationReference, but if it exists in the parties array then that doesnt make much sense. So maybe ParentOrganizationReference ?

[jpmckinney]

I think maybe ParentOrganization, as it's not guaranteed to be a reference to a party.

[duncandewhurst]

I need some input on modelling for this.

The simplest version would look the same as the example in the extension documentation, with the addition of an optional url field for external references:

{
  "parties": [
  {
    "id": "12-001",
    "name": "Presidencia de Paraguay",
    "identifier": {
      "scheme": "PY-PGN",
      "id": "12-001",
      "legalName": "Presidencia de la República del Paraguay"
    }
  },
  {
    "id": "12-001-52",
    "name": "SENATICS",
    "identifier": {
      "scheme": "PY-PGN",
      "id": "12-001-52",
      "legalName": "Secretaría Nacional de Tecnología y Comunicación"
    },
    "memberOf": [
      {
        "id": "12-001",
        "name": "Presidencia del Paraguay"
      },
      {
        "id": "PG",
        "name": "Government of Paraguay",
        "url": "http://www.gov.py"
       }
    ]
  }
]
}

The downsides of this approach are:

• User or tools would need to handle two cases for the id and name fields depending on whether there is an entry in parties or not.
• It won't be possible to check whether references to parties are resolving correctly.
• References which aren't in the parties array would lack any context on where .id could be looked up and wouldn't be following the practice used elsewhere of having .scheme and .id for external identifiers.

To address those issues, another option could be to separate out the 'internal' reference (to the parties array) and the external reference, by having a nested organizationReference for the internal reference and a nested identifier for the external reference. This would also mean adding an id field at the top level of new class, since memberOf is an array.

So where the parentOrganization exists in the parties it would look like:

{
  "memberOf": [
    {
      "id": "12-001",
      "reference": {
        "id": "12-001",
        "name": "Presidencia del Paraguay"
      }
    }
  ]
}

And where the parentOrganization doesn't exist in the parties array:

{
  "memberOf": [
    {
      "id": "PY-PGN-PG",
      "identifier": {
        "id": "PG",
        "scheme": "PY-PGN",
        "legalName": "Government of Paraguay"
      },
      "url": "http://www.gov.py"
    }
  ]
}

The downsides of this approach are:

• Users and tools have two possible places to look for the name of the parent organization (.reference.name and .identifier.legalName).
• .identifier.legalName might not be known
• The description of .identifier.uri makes reference to the organization's .contactPoint which would not exist in the new class.

Two of those issues could be resolved by having a .name property on the top level of parentOrganization, but then we'd end up with .id and .name at the top level and as properties of .reference, which seems overly duplicative.

@jpmckinney @yolile do you have any views on the preferred approach?

[jpmckinney]

I'm not sure that it's necessary to reconcile the ParentOrganization with any potential matches in the parties array (especially considering some, by design, will not reconcile). I think it's fine to just disclose the information that we think is relevant to track about the parent organization.

If we want to support reconciliation, then we can recommend following a particular approach to the use of the id field.

I'm also fine with putting scheme at a top-level field in the ParentOrganization class, if we need an in-data means of indicating how to look up the id, instead of relying on the publication policy (which is another alternative).

[jpmckinney]

From discussion at OCDS retreat, we are considering a new memberships extension, which would be similar to other standards' ways of expressing organizational membership with looser semantics – in particular in the case of consortia. One important advantage is being able to describe the membership itself, like the type of membership. As part of this, we should check whether the shareholders extension can be merged into a common approach.

[jpmckinney]

Noting that if we pursue this extension (rather than a new memberships extension), then we can add this to the extension registry once this issue is closed.