Example: Identifying divisions of an organisation

[timgdavies]

From @myroslav:

In our Moldova implementation we have need for extra details of organization identification. It is not just different way of identification (like different registry or different jurisdiction, that would natively map to additionalIdentifications) but a way to detail the already present primary one.

In Moldova there is inter-ministry registry that we use MD-IDNO schema for. For taxation, banking and accounting purposes big organizations that have divisions have additional so called divisionCode, that is normally sequential number from 1 to number of divisions organization has. For bank kind of organization every branch would have such number, for big national corporation, regional representative offices would have similar sequential numbers.

These divisionCode is normally used in accounting, in bank transactions when specifying receiver altogether with MD-IDNO, and mandatory for taxation, since tax office is handling taxation of branches independently of primary organization. At least we were told so. Additional information we have us that tax office is maintaining the registry, but that registry of Organization Divisions is not public.

Please help us define rules of how to express that additional divisionCode in OCDS, or its extension.

• The first proposal was to add extra divisionCode/divisionName attributes to Identification.

• The other was to introduce something like MD-TAXDC (Moldova Taxation Division Code) schema and add it as additionalIdentification for organizations having more then only primary division. But this approach is still not elegant enough.

Are there other options to the challenge we have?

[timgdavies]

Initial response - as a starting point:

• organization/identifier blocks are intended to capture the specific legal entity playing a role in the contracting process;
• If the divisions have a separate legal identity (for example, contracts are with that specific division, such that if it closed down, its contracts would not automatically transfer to the parent organisation) then the identifier could be used to distinguish them (admittedly, there can be lots of grey areas here);
• If the divisions are separate entities, then both identifier, and additionalIdentifiers should point to the same legal entity (not using one to point to the parent department, and the other to the division)

Assuming though that the divisions are just administrative units of the legal entity, then it would be better to capture the divisions using some additional properties (and this would discount the MD-TAXDC idea, as this is mixing levels of legal entity identification up).

Within the parties/organisation block, the name field can be used for the division / department name (or a composite of organisation name and division - e.g. "Moldova National Bank > Chișinău branch", whilst identifier/legalName for the formal name of the parent organisation ("Moldova National Bank").

For the identifier for the division, I've had a look at existing schema for similar concepts.

• Schema.org has 'department' which it uses to relate to organisations together in a hierarchy;
• The W3C Organization Ontology has 'hasSubOrganization' and 'hasUnit' for "e.g. a Department within a larger Organization."
• The Core Public Organisation Vocabulary of the EU follows the W3C model;

To my mind, 'unit' might be the most generalisable term to cover divisions, departments, branches etc.

My proposal would then be to add unitCode as an extension to the identifiers block with the following definition.

To identify a particular sub-unit (department, division, branch) of this legal entity, use a recognised reference code for the specific sub-unit in this field. If using unit codes, then when constructing the object identifier for a party, and entering the cross-reference to a party elsewhere in your data, you should include the unit code within the identifier.

So - assuming, (in my fictional example), that 'Moldova National Bank' has an identifier of MD-IDNO-123456789, and the Chișinău branch has the unit code '14', this would give us a parties block looking as follows:

{
   "id":"MD-IDNO-123456789-14",
   "name":"Moldova National Bank - Chișinău branch",
   "identifier":{
       "legalName":"Moldova National Bank",
       "scheme":"MD-IDNO",
       "id":"123456789",
       "unitCode":"14"
     }
}

Does this look sensible to you?

[timgdavies]

Reply from @myroslav:

I'm not sure that Organization.name is adequate replacement for additional departmentName, since Organization.name was normally utilized as shortName or organization. Unfortunately we'll have little control over composition with parent org name, thus no way to rely on that. I.e. whilst Organization.identifier.name will be "Moldova National Bank", for Organization.name following cases are possible:

• sometimes it'll be be just "Chișinău branch" , and
• sometimes it'll be be "Chișinău branch of MNB"
• usually it'll be "Chișinău branch of Moldova National Bank"
• and almost never Organization.name will be "Moldova National Bank - Chișinău branch"

Suggestion of in-content extension for Identifier.id, like "123456789/14", similar to what is sometimes (unofficially) is happening with UA-EDR identifiers in Ukraine, was blocked immediately with arguments that such behavior should never happen in Moldova (and I do support it due to need of proper org linking).

Our internal OCDS identifiers can be MD-IDNO-123456789-14 since it does not influence any government level processes, but I'm afraid it'll break some of the already available tools for OCDS, and will prevent from attribution of awarded contracts to "parent" org, since OCDS org IDs were never meant to follow "hyphen-as-org-hiererchy-separator" schema, and normal "equal" criteria will not match "startsWith" that would work in the case. Or do we consider Organization.id to have some meaning only within release, and not support any external linking (with Identifier.schema-Identifier.id to be Primary Key instead)?

[timgdavies]

In OCDS 1.1 - organisation.id is only used to cross-reference between an in-line reference to an organisation (e.g. buyer, supplier etc.) and the entry in the parties array with the same id.

Local implementations can chose to use some value for that id which supports some degree of external linkage (and should document this in their publication policy, so users can understand this).

The organization.identifier.id does have an external cross-reference. The value of this field should always match something that can be found in the external corporation registry/identifier list referenced by scheme.

On the name fields - introducing a departmentName field alongside name could work - although note that applications not aware of this extension would potentially display less comprehensive information. You may wish to internally store separate 'organisation' and 'department' names - but to express these in OCDS data as a single composite string in name.

[juanpane]

I'll try to explain the case of Paraguay. We have entities, and these entities have administrative divisions. Both of them have their codes coming from the National Budget Law. Some examples:

• 12-001 Presidencia
  • 12-001-52 National ICT Secretary
  • 12-001-38 National Science Secretary
• 12-006 Ministerio de Hacienda
  • 12-006-03 Sub secretaria de estado de tributación
  • 12-006-04 Sub secretaría de estado de administración financiera

In many contexts, it is very import to separate the two secretaries from the presidency, as it is important to separate the different divisions from the Ministerio de Hacienda (Ministry of Finance). In general, each ministry would have a division that requires something to be procured, and then another division that in general is in charge of the procurement process (unidad operativa de contratacion o UOC). Normally, each institution has a UOC.

The problem of putting only the division name, is that many divisions having the same name will have parties entries with different identifiers, but with the same name. In this case, we need to be able to differentiate them. This same issue is the problem that currently the bulk download data from Mexico has, where if we do an analysis of the procurement processes by parties.name, we get a lot of Secretaria de Finanzas, but where they belong to different "delegaciones" (sort of municipalities).

The approach stated by Tim (use name:"the name of the institution - name of division") was the same I proposed to Eduardo Borregon from Poder (@emartinborregon) to potentially address this issue, but he energetically opposed to that, since as a journalist, he would not want to artificially override the legal name of the division.

The issue I see with having a list of divisions in the same parties entry, is that then if the division requiring the good is different from the division managing the procurement process, then the buyer and procuringEntities attributes would point to the same entry in the parties array, but we would not be able to easily know which division, if any, is acting as the buyer or the procuring entity.

One thought that comes to my mind is to be able to treat each entry that we want to use in the attributes (buyer, procuringEntity, payer) as different entries in the parties array, and then all of them having an extra "parent" attribute of type "OrganizationReference" that would point to the parent entry.

For example

"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"
        },
        "parent":{
            "id":"12-001",
            "name":"Presidencia del Paraguay"
        },
        ...
    },
    {
        "id": "12-001-38",
        "name": "CONACYT",
        "identifier": {
            "scheme": "PY-PGN",
            "id": "12-001-38",
            "legalName": "Comisión Nacional de Ciencia y Tecnología"
        },
        "parent":{
            "id":"12-001",
            "name":"Presidencia del Paraguay"
        },
        ...
    }
]

Whit this approach there would be no problem in having different divisions in the different attributes (buyer, payee, procuringEntity) and furthermore, it can allow the user to create any arbitrary organizational structure of any depth (as long as it is a tree and not a graph).

In the case in Paraguay, we are thinking seriously to use this approach, since we don't want to loose this important division information, as it would normally carry the information of the contact point and the responsible for the division, which in some cases, are very important divisions (see the example above).

Considering the legal entities comment by @timgdavies, in the case of Paraguay, all of them are define in the National Budget Law, so these divisions (called unidad administrativa) are legally defined (not sure though is this can then be called a legal entity?).

Any thoughts @jpmckinney @emartinborregon @timgdavies ?

[jpmckinney]

Isn't one solution to run an analysis based on the identifier, not the name?

We don't want every contracting process to include a partial hierarchy of a government. Governmental hierarchies exist outside of and are independent of contracting processes. Ideally, a second dataset would use the same identifiers and describe the hierarchy (maybe using the W3C Organization Ontology). If you absolutely need a solution within OCDS, one option is to add a field for the parent organization name ('parentName') under the 'details' object within the Organization object. But in general, it is not in scope for OCDS to model organizational hierarchies (certainly not complete organizational hierarchies).

[akuckartz]

Please use the Organization Ontology (as suggested by @jpmckinney) and also have a look at the Registered Organization Vocabulary published by the W3C.

[timgdavies]

I think we have two issues in play here:

(1) Identifiers for sub-divisions - and how to represent them;

(2) Understanding the organisational hierarchy using OCDS data;

I think the proposal above does cover (1) - with the important note that the identifier block is to identify the legal entity not the department (so this indicates immediate parent legal entity of a department).

I would quite strongly stick to the principle that in OCDS name can (and should) be used to present composite names of departments. Local implementation may opt for a particular separator that makes parsing out parent and child names easier.

For structured data on (2), our approach has generally been that this should be handled by separate datasets that focus on organisational identification and structures. OCDS is not authoritative on organisational hierarchy, nor is organisational hierarchy generally 'declared' as part of a contracting process (this contrasts with the shareholder section in OCDS for PPPs profile where shareholder information is being gathered/snapshot as part of the contracting process).

[timgdavies]

We discussed this earlier today with @emartinborregon who described the following user story for maintaining structured information on hierarchy:

As a journalist I want to be able to query an API for all the contracts from a particularly government agency so that I don't need to look up every single department identifier individually.

We discussed how this could be addressed by a reasonably intelligent API that:

• Maintains a separate record of organisational hierarchy;
• Rewrites API queries so that in a single request, users can supply the top of a hierarchical tree, and the query will be executed on all children also;

However, this raises temporal issues. For example, in 2016 Agency X might belong to 'Department A', but in 2017 it might have been moved for 'Department B' due to a restructure.

Querying using a separate hierarchy list (assuming it is not versioned, and queries are not overly complex) would only be able, in 2017, be able to return the structure as it is then - rather than as it was when the tenders/contracts were issued.

This led us to explore how a data system could explicitly include some level of hierarchical information to support querying, and make sure users downloading data have access to this information.

Drawing on @akuckartz's signposting, and existing use of Popolo in @emartinborregon's system (which draws on it) we looked at the Organization Ontology and looked at using memberOf property. This proposal is outlined below

Proposal: community extension to add memberOf to party

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

The target of memberOf should be an array of organizationReference blocks as below:

{
  "parties": [
    {
      "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"
      }]
    }
  ]
}

We would 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. E.g:

{
  "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"
       },
      {
       "id":"PG-RBC01",
       "name":"Regional buying consortium"
      }]
    }
  ]
}

The example above also shows how memberOf can be used to represent arbitrary memberships - and does not have to only relate parties, but can relate a party to an association. memberOf is also not restricted to declaring direct parents, but might also be used to declare the top parent of an organisation.

We would be looking to re-use the definition of memberOf from the Organization Ontology which is:

Indicates that an agent (person or other organization) is a member of the Organization with no indication of the nature of that membership or the role played. Note that the choice of property name is not meant to limit the property to only formal membership arrangements, it is also intended to cover related concepts such as affiliation or other involvement in the organization.

We could add to this a clarification that **This relationship should be true as of the release.date in which it is contained.

Notes

The parties section can be used to describe individuals, departments and organizations. The party.name should be a display name for the party. The party.identifier block should identify the legal entity the party represents.

Discussion

The memberOf approach does not preclude an API or analysis using externally defined hierarchies but does offer a way for APIs to more simply query all the parties which are member of some parent entity.

Questions

• Do you support the development of this as a community extension?

• Does the re-use of the definition of memberOf from the Organization ontology fit OCDS usage?

• Do you support the proposal that "We would not require that the party identified by memberOf.id exists in the parties array, but implementations could choose to include it."? Would you propose an alternative rule here?

• Any other feedback on this proposal?

[emartinborregon]

I like the membership solution and it's wider enought to be used in other cases like the parent company of a supplier. Let's implement it!

[pepegarcia]

Hi! In Mexico, our Access to Information National Law requires that every "Sujeto obligado", which is the procuringEntity, publishes their contracts specifying at least three different units that are memberOf the procuringEntity, and that are directly involved in the procurement process:

1) "Unidad administrativa solicitante". The unit that requires the good or service and initiates the procurement process and that commonly has the budget. This area, and @emartinborregon, would agree, it is very important to understand the rationale of the whole procurement process and to relate spending with results. Each area has objectives and goals, and only relating the procuring process to the "substantive" area or unit -and its objectives and goals, we can evaluate the adequacy and relevance of the procurement process.

2) "Unidad administrativa contratante". The unit who buys. Regularly, many institutions have special units to purchase and write contracts (e.g. Dirección de Contratación de Servicios)

3) "Unidad administrativa responsable de la ejecución". The unit in charge of managing the goods or services, especially if it is public infrastructure (works).

That is why at INAI we are using procuringEntity as the legal entity responsible for the contracts (the Sujeto Obligado), and buyer, as the unit that requires the good or service (The Mexican Federal Government is not publishing the same way).

At any case, we can use the memberOf extension to relate different organizations (as @timgdavies explained), but, maybe we will need and propose another extension to specify the units inside an organization participating in a procurement process, and their roles.

[antonioherrera]

Hello everyone!

As Pepe wrote last week, we need to define how to capture these three units that are involved in a particular contracting process. In the meeting that we held with Secretaría de la Función Pública (SFP) today, we agreed this data is crucial in Mexico. And we noticed that buyer and procuringEntity would be regularly the same institution (when talking about entities) at the federal level.

This let me think that we can take advantage of those references (that are part of the core schema) when referencing these units, because two of them have the same definition (at a department/unit level).

Consider that the definition of buyer is "The buyer is the entity whose budget will be used to purchase the goods. This may be different from the procuring entity who may be specified in the tender data." And the proposed definition of requestingUnit is "The unit that requires the good or service and initiates the procurement process and that commonly has the budget."

In the same way, the definition of procuringEntity is "The entity managing the procurement. This may be different from the buyer who pays for, or uses, the items being procured." and the proposed definition of contractingUnit is "The unit managing the procurement. Regularly, many institutions have special units to purchase and write contracts".

We would consider to develop an extension that allow us to capture these units into the institution that many times will be both the buyer and the procuringEntity.

However, we also need to include the resposibleUnit that is the one who monitores the contact implementation, and is in charge of managing the goods or services, especially if it is public infrastructure (works). We could do it by adding an organizationReference in the Implementation object, but we are open for other proposals.

[jpmckinney]

I generally agree with all the questions. However:

• The objects inside memberOf should have fairly limited fields to begin with; id and name seem sufficient to cover the use cases discussed.
• We should strongly recommend against populating memberOf unless a use case supports it, because we don't want to promote the communication of organizational hierarchy data through OCDS.
• 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.

For the more recent examples by @pepegarcia and @antonioherrera of sub-organizations with clear roles, I think those are better solved by appropriate use of buyer and procuringEntity and by adding remaining organizations as parties with an appropriate role (and optionally by adding an OrganizationReference field in an appropriate location to refer to those same parties).

---

Querying using a separate hierarchy list (assuming it is not versioned, and queries are not overly complex) would only be able, in 2017, be able to return the structure as it is then - rather than as it was when the tenders/contracts were issued.

Presumably a correct implementation would store historical organizational hierarchy data, and not only the latest version. Most implementations of Popolo do this, as many use cases are interested in history.

[pepegarcia]

Dear @jpmckinney, to answer your comment: "For the more recent examples by @pepegarcia and @antonioherrera of sub-organizations with clear roles, I think those are better solved by appropriate use of buyer and procuringEntity", we were precisely using those two in an incorrect way to fill the gap. To use properly those variables, we definitely will need to propose, create and use an extension in Mexico to map sub-organizations and their particular roles (with their specific IDs). That's a nationwide legal requirement, and we will definitely propose it and use it, but we need to know the best way to do it. So what do you think @timgdavies @juanpane @emartinborregon?

[jpmckinney]

@pepegarcia Yes, that seems consistent with the rest of my sentence, "and by adding remaining organizations as parties with an appropriate role (and optionally by adding an OrganizationReference field in an appropriate location to refer to those same parties)."

[antonioherrera]

I think we didn't explain ourselves properly. In order to make an example how we are thinking about it, I'm using the data of our system and the proposal that @pepegarcia told me.

{
  "parties": [
    {
      "id": "INA1402082Z8",
      "name": "INAI",
      "identifier": {
        "scheme": "RFC",
        "id": "INA1402082Z8",
        "legalName": "Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales"
      }
      "unitIdentifiers":[
      {
        "scheme": "CUA"
        "id": "310"
        "name": "Dirección General de Políticas de Acceso"
        "roles": [requestingUnit]
      },
      { 
        "scheme": "CUA"
        "id": "210"
        "name": "Dirección General de Administración"
        "roles": [contractingUnit, resposibleUnit]
      }
      "address": {
        "streetAddress": "Av. Insurgentes Sur 3211"
        "locality": "Coyoacán"
        "region": "Ciudad de México"
        "postalCode": "04530"
        "countryName": "México"
      }
      "contactPoint": {
        "name": "Felipe Contreras Alvarado"
        "email": "felipe.contreras@inai.org.mx"
        "telephone": "+5255674352"
        "faxNumber": "+5255674353"
        "url": "http://inicio.inai.org.mx/"
      },
      "roles": [buyer, procuringEntity]
     }]
}

As you can see, INAI is both the buyer and the procuringEntity. The only information that we have to differenciate this parties (buyer and procuringEntity) is through its units. We take advantage of this example to match the transparency law that requires this data. In other hand, we have been told that we cannot capture a single unit as a party, but the organization that it belong.

[jpmckinney]

What was the reason a unit could not be a party in OCDS? (I'm assuming it's true, in the real world, to say that the unit is a party to the contracting process.)

[antonioherrera]

So, if we can capture thise units as parties, we can relate them with the organizations that they belong with memberOf right? In the case this units are part of different organizations.

[jpmckinney]

Yes, that would help to avoid ambiguity.

[juanpane]

I agree with the memberOf attribute.

As from @timgdavies questions:

• Do you support the development of this as a community extension?
  • Yes, how do you suggest to proceed? @pepegarcia @antonioherrera Have you done any work on the memberOf extension?
• Does the re-use of the definition of memberOf from the Organization ontology fit OCDS usage?
  • yes, this would make things interoperable if and when OCDS could be converted to JSON-LD and from there to, for example, RDF
• Do you support the proposal that "We would not require that the party identified by memberOf.id exists in the parties array, but implementations could choose to include it."? Would you propose an alternative rule here?
  • I think the "optional" inclusion is OK, but in my experience, from the users side, one would need to know where to go and resolve the identifier (and endpoint documented in the publisher puplicationPolicy, for instance) and this tend to be lacking. So from a user perspective my guess is that it should say, "if the identifier is not present in the parties array as the publisher chose to manage this information outside OCDS, the publisher should document where and how these missing identifiers could be resolved". What do you think @emartinborregon?
• Any other feedback on this proposal?
  • I think splitting @antonioherrera 's json example into multiples parties and using the memberOf reference to INAI would do the trick, then for each attribute (buyer, procuringEntity) the publisher will be able to reference the most specific unit it wants to refer, having the hierarchical information in the memberOf attribute. What do you think @pepegarcia @emartinborregon @antonioherrera

[viktor992]

Hi! Following the Paraguay example, which roles would have "Government of Paraguay" and "Presidencia del Paraguay" in the parties array? And, in general, all the organizations that are only in the memberOf field?

[yolile]

@jpmckinney @timgdavies created repo: https://github.com/open-contracting/ocds_memberOf_extension

[jpmckinney]

We can expand the current worked example.

We should also give an example for this sentence in the schema for the Organization.id field:

This field may be built with the following structure {identifier.scheme}-{identifier.id}(-{department-identifier}).

Or, we should re-consider that sentence. See CRM-5095 for a publisher's questions.