IATI Consultations Archive

Live discussions and consultations can be found at discuss.iatistandard.org.

Add more granularity to activity contact details

Background
Activity contacts can provide the name of the individual to contact about an activity
They cannot provide the job title or the department they work in, which is arguably important for large organisations
Additionally a contact type option is not available

Problems
It’s sometimes important to know the job title or department of the responsible individual, and this may also help avoid some data protection concerns about providing individuals’ names

Proposal
Add <job-title> and <department> elements within the <person> element.

In addition:
There may be different contact requirements for an activity. For example, the address to send evaluation or feedback to, and the address to send error reports about the information in an activity record, may be different.

Additional proposal:
Create a <contact-type> field or attribute with a code-list of contact types which may include: donor-contact; project-contact; feedback-contact;
(This should be a minimal code-list, and we may wish to always require a ‘primary contact’ to be specified, either with a contact-type, or a @primary-contact=’true’ element)

 

Proposed by Mark Brough

Have more questions? Submit a request

19 Comments

  • 0
    Avatar
    Tim Davies

    We should consider including 'corruption report' on the code list. For example, the World Bank operate a corruption reporting hot line (http://web.worldbank.org/WBSITE/EXTERNAL/EXTABOUTUS/ORGANIZATION/ORGUNITS/EXTDOII/0,,contentMDK:20659616~menuPK:1702202~pagePK:64168445~piPK:64168309~theSitePK:588921,00.html) and providing a way for this information to be distributed within the IATI data would seem appropriate.

  • 0
    Avatar
    Bill Anderson

    There seems to be a move towards providing less personal data in IATI, so this proposal is not to be carried forward for our first decimal upgrade.

  • 0
    Avatar
    Tim Davies

    asd

  • 0
    Avatar
    Tim Davies

    I'm not sure I understand the justification here.

    Contact details are essential to the feedback loop built on top of IATI, and are not personal details. They are essential public contact information.

    Can this be put forward for wider discussion for the next decimal upgrade.

  • 0
    Avatar
    Mark Brough

    I agree with Tim, and I think this meets the definition of a decimal upgrade.

    Whether or not publishers choose to publish personal information (and the department and job title is surely less personal than someone's name, as is permitted in the Standard at the moment), is surely a choice for the publishers. Including it in the Standard would not force the release of anything, and would not enable the release of more personal information than is possible at the moment. It would give publishers a choice that is somewhere between an indiivdual's name and a generic contact point.

    I think it would be good for this proposal to go through and be discussed as part of the general consultation process, where these concerns could be raised and discussed.

  • 0
    Avatar
    David Carpenter

    Agree. There is no problem with adding this additional information and making it optional.

    We are concerned that there may need to be wider consultation on what elements are required, so would welcome some more concrete proposals. It may be that this should be tried as an additional namespace, but if we can get it right quickly it could be part of the 1.03 release.

  • 0
    Avatar
    David Carpenter

    I want to start drawing up schema code to represent this change in the next few days - is there agreement on this? Do we want more/less fields? Are we happy with backwards compatibility etc?

  • 0
    Avatar
    Yohanna Loucheur

    CIDA is fine with the proposal above as long as the fields are optional.

    We had also submitted a request to the TAG to allow the use of different languages for Activity Contact. The Canadian government is legally required to publish in 2 languages (French and English). Other publishers may be in a similar position. Currently, CIDA is concatenating the French and English acronyms for "organisation name" (ACDI-CIDA) and publishing the address in English, which is really not ideal. Having separate fields with the language clearly identified would allow users to chose the language that best suit their needs.

    To make it possible to publish in more than one language, we propose that the fields should have their own "language" tag (to identify the language of the field content) and a 0..n relation with the parent. 

    In the Canadian case this would be required at least for the "organisation name" field and the "mailing address" field (mailing addresses are expressed differently depending on the language). However, it may be prudent to apply to all fields to accomodate others' needs.  

  • 0
    Avatar
    David Carpenter

    There may be a problem with the contact-info fields at the moment as they are designated as 'plainText' type. We usually use 'textType' to enable an element to specified in more than one language.

    The current approach to language is to have duplicate elements with the xml:lang= "" attribute designating the language of the supplied text. I'm unclear as to whether or not that is sufficient for what is being asked here. Will try to clarify.

  • 0
    Avatar
    David Carpenter

    Hi Yohanna

    To be honest I'm not clear. 

    I think what is clear, is that where the standard deliberately made provision for alternative languages to be used, the method was to duplicate elements and to specify a default language on an activity and then an alternate language by using the xml:lang attribute. Those elements are designated as 'textType'

    So it seems to me that we would need to change the contact-info elements to be of type 'textType' to do things 'the standard way'

    I'm also seeking clarification about 'plainType', my reading is that the use of xml:lang is not forbidden (extended attributes may be used) but crucially people using the data will not expect to see it, and therefore will not expect to see those elements in different languages.

    So, if those elements were treated as 'textType's where we could use xml:lang - would that be a suitable solution for you? (I'm not sure whether or not this would count as a backwards compatible change tho.)

    Thanks for engaging in this.

  • 0
    Avatar
    David Megginson

    Allowing multilingual contact info would be a backwards-compatible change for information producers, but not for information consumers: since the additional attributes or elements would be optional, every IATI file that is valid before the change will be valid after; however, as David  Carpenter mentioned, as with any optional change, systems that process IATI data might be thrown off when the new elements appear.

    We have two choices.  The first is to repeat the entire contact-info container for each language:

    <contact-info xml:lang="en">
      <person-name>Yohanna Loucheur</person-name>
      <organisation>Canadian International Development Agency (CIDA)</organisation>
    </contact-info>

    <contact-info xml:lang="fr">
      <person-name>Yohanna Loucheur</person-name>
      <organisation>Agence canadienne de développement international</organisation>
    </contact-info>

    The other is to  repeat only the necessary fields for each language:

    <contact-info>
      <person-name>Yohanna Loucheur</person-name>
      <organisation xml:lang="en">Canadian International Development Agency (CIDA)</organisation>
      <organisation xml:lang="fr">Agence canadienne de développement international (ACDI)</organisation>
    </contact-info>

    The second option will result in shorter IATI reports.  It's not a difficult schema change, and I think it's a good idea, if the other stakeholders support it.
  • 0
    Avatar
    Yohanna Loucheur

    Thanks David for these suggestions.  We tend to prefer the second option to avoid repeating unecessary information.  Let's make sure we allow this change for all the elements of Contact-Info, as we don't know which elements some publishers may wish to publish in more that one language.

  • 0
    Avatar
    David Megginson

    I agree, Yohanna.  For example, many people from India and China use different names in English or French than they do in their own languages, so we can't even assume that person-name might not need to be translated.

  • 0
    Avatar
    Mark Brough

    We agree - it would be useful to allow all elements of the IATI Standard to be published in multiple languages. The second option seems preferable to avoid repeating unnecessary information, while at the same time allowing information to be published in a different language where appropriate.

  • 0
    Avatar
    David Carpenter

    Just to confirm that we believe we would need to change the contact-info elements (and sub-elements) to become 'textType' instead of 'plainType', as well as add the new sub-elements.

  • 0
    Avatar
    Bill Anderson

    We have added the following:

    • Contact Type (with an associated code list)
    • Job Title
    • Website

    The ability to report multiple languages has been added to:

    • Organisation Name
    • Person Name
    • Job Title
    • Mailing Address
    Some initial values have been added to the Contact Type codelist, but these require input and review.
    Please continue to comment in this topic.
  • 0
    Avatar
    David Carpenter

    Looking at the 1.03 dev schema it looks to me as though:

    1) Job title has been added, but Contact Type and Website have not

    Also it seems that the elements are all of 'plainType' I think they should have been changed to 'textType' to enable multiple languages to be used as discussed above.

  • 0
    Avatar
    David Carpenter

    This is all fixed up now. Website is a new element, type is an attribute, language options are allowed.

  • 0
    Avatar
    Wendy Rogers
    Re Added: We should consider including 'corruption report' on the code list. For example, the TAKUKURU operate a corruption reporting hot line (http://www.pccb.go.tz/) and providing a way for this information to be distributed within the ICT data would seem appropriate.
Please sign in to leave a comment.