Add contact person to address details

[practicalparticipation]

From Mexico field work, there is demand for the named procurement officer for a project. This could be handled by adding a name property to the address block, and noting in documentation that this should be the person responsible for this procurement.

Similar named contacts may be useful on the supplier side too.

[jpmckinney]

It's not the same contact person for all contracts with an organization, so that property should be at the same level as any organization properties - not a property of the organization or its address.

[practicalparticipation]

Good point & agreed.

[LindseyAM]

Here is an example of a tender notice from nepal that also names the person and their contact info: http://eproc.dor.gov.np/tender_details.php?tid=51282 (Curious to know from @birdsarah how often a named person with contact info showed up in the datasets of the supply side analysis)

[practicalparticipation]

A further contribution related to this thread from Mihaly Fazekas:

address: is it the address of the headquarters or the organisational unit submitting/receiving the tender. In CEE countries it is typically the local unit's address which creates all sorts of confusions about identifying organisations.

In order to (a) avoid a proliferation of fields; (b) assuming that organizational IDs can be cross-referenced to the legal address of an organisation using third-party datasets, I'm leaning towards the suggestion that:

• We replace 'Organization' with 'Entity' to recognise that sometimes address and contact details will belong to a sub-unit of an organisation, rather than to the organization per-se;
• Rename the id field under buyer, supplier etc. to become 'organizationId', an document that this should be the identifier of the legal entity that is party to the contract.
• Adding additional vCard properties to the address block, including contact person, e-mail, phone etc. (as no good reason not to allow these to be specified where they are known).

This would mean:

• The standard does not guarantee nor imply that it will contain the legally registered address of an organisation;
• But address details should be usable as correspondence details;

[jpmckinney]

The address block should be renamed in that case, if it no longer contains just an address. Maybe contactPoint as in http://schema.org/contactPoint

[practicalparticipation]

+1 to using contactPoint

[jpmckinney]

FYI, CoST recommends fields for electronic addresses.

[birdsarah]

See buyer fields:
http://ocds.open-contracting.org/opendatacomparison/datamap/field/37/

and supplier fields:
http://ocds.open-contracting.org/opendatacomparison/datamap/field/45/

Contact information appeared for buyer / procuring entity, but not for suppliers really.

[practicalparticipation]

I had a slightly different interpretation of how we should make this change, which was to:

• Replace address with contact point
• Have all address details in here

On the basis that:

• The organisational identifier can be used to look up the official registered address of a company
• The address held in contracting systems is generally a contact point for the organisation, rather than the registered legal office.

[myroslav]

It look like keeping contact outside of organization is good thing. The reason is that in different tenders of same organization there will be different contact persons responsible for tenders. I.e. the contact is not a property of organization, but property of tender, but keeping it within procuringEntity would be reasonable.

If we were voting, I'd vote for keeping the approach implemented in 9bcd186

[practicalparticipation]

But does a contact point need an address as well in these cases? Right now our contact point block only contains electronic contact details? It sits parallel to an address block attached to the organisation.

And what is the meaning of address attached directly to an organisation? Would this be registered office address? Or just any contact address?

[myroslav]

In our case the Organization is the legal identification of procuringEntity (identifier), i.e. the way to uniquely identify the party and set of necessary prerequisites (address) to sign a contract.

The contactPoint is physical person to be contacted about particular tender (i.e. the one responsible). The set of options does contain e-mail, phone and fax - this is normally enough to contact the person, and no address is required.

[birdsarah]

My understanding of all the data I've seen. Is there's often an address associated with a supplier, and sometimes a buyer. (What specifically that address represents is unclear).

Seperate from that, many places list a contact point for the buyer - someone to contact about the tender.

And, finally, some people list a contact point for the supplier.

Based on this and the above discussion I made the addition of contact point in the way I did.

To see the fields from supply side:
buyer: http://ocds.open-contracting.org/opendatacomparison/datamap/field/37/
supplier: http://ocds.open-contracting.org/opendatacomparison/datamap/field/45/

[LindseyAM]

Address of procuring entity important if that is where bids are to be mailed or dropped off (in non-ebidding scenario).

Sent from my iPhone

On Nov 6, 2014, at 6:10 PM, Sarah Bird notifications@github.com wrote:

My understanding of all the data I've seen. Is there's often an address associated with a supplier, and sometimes a buyer. (What specifically that address represents is unclear).

Seperate from that, many places list a contact point for the buyer - someone to contact about the tender.

And, finally, some people list a contact point for the supplier.

Based on this and the above discussion I made the addition of contact point in the way I did.

To see the fields from supply side:
buyer: http://ocds.open-contracting.org/opendatacomparison/datamap/field/37/
supplier: http://ocds.open-contracting.org/opendatacomparison/datamap/field/45/

—
Reply to this email directly or view it on GitHub.

[birdsarah]

it would be very easy to add an address to contactPoint, so there was one for the org and one for the contact point. or do we not want one for the org at all?

[practicalparticipation]

Discussed and agreed that this can be handled when data of this sort arises.

If data requires, then adding address to a contactPoint, following the standard address approach, should be straighforward.