A possible solution to Org IDs

[Owen Scott]

Hi All,

First off, apologies that I’m not very connected to the org ID discussion, so not sure what is already proposed under 2.01. That said, heard a very good suggestion from the team at Open Spending, via the team at Open Contracting. The basic idea would be an organization element with the following form:

participating-org/@ref
participating-org/@type
participating-org/@role
participating-org/@vocabulary-uri

In the above structure, the @vocabulary-uri attribute would be a link to a machine-readable code list (in any format). The idea here would be a hierarchical approach whereby:

• any organization with an official IATI/CRS code should be referenced to that code
• any organization with a code on another blessed list (e.g. tax registration) should be referenced to that code (with a uri link pointing to the lookup facility)
• any other organization (e.g. govt ministries/departments) can be referenced from any code list

Any publisher would be able to create their own code list, and the approach would rely more on convention than codification. For instance, if I’m really knowledgeable about the structure of a certain country’s ministries, I could publish/maintain a codelist myself (which others could discover and use), but if that government were to publish an official codelist, that would become preferable. The community would be responsible for maintaining lists, discovery mechanisms, crosswalks, and eventually maybe centralized APIs pulling together commonly-used lists.

I realize it’s not perfect, but could be a step in the right direction (that doesn't the IATI Secretariate becoming a registrar). Any thoughts on this? Also note the potential interest from other open data players.

Best,

Owen

​

[Tim Davies]

Hey Owen,

So - I think this idea basically comes from the draft IATI Organisation ID Standard in the first place (see http://iatistandard.org/organisation-identifiers/ which outlines the idea of preferred and alternative identifiers), with the difference that IATI compounds together the @vocabulary element into the ID (e.g. GB-COH is a vocabulary).

The big challenge so far has been getting anyone to take a lead on maintaining the registry of vocabularies, and developing tools to help users map between them. It would be great to get a community effort going on this though...

(Tangentially - I wrote down some thoughts about whether or not WikiData might be able to help with some of the mapping jigsaw over the weekend: http://www.timdavies.org.uk/2014/08/09/exploring-wikidata/ which might feed into any community effort)

All the best

Tim

--
You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

w: http://www.timdavies.org.uk | m: 07834 856 303 | twitter: timdavies

Co-director of Practical Participation: http://www.practicalparticipation.co.uk
--------------------------
Practical Participation Ltd is a registered company in England and Wales - #5381958.

[Bill Anderson]

Thanks for coming in on this Owen. Some thoughts:

 

1.       I think it is critical, as you suggest, that IATI, Open Contracting and other existing and emerging standards adopt a common approach.

2.       As Tim comments, your proposal is in fact a differently formatted  version, of the existing proposal

3.       Maintaining accessible codelists, as opposed to a consistent methodology, is challenging. Most useful authority lists do not currently have machine-readable lists.

 

My personal view is that IATI, Open Contracting, Open Spending, HXL and any other interested parties should form an informal consortium that maintains a shared list of recognised registration agencies / vocabularies AND develops a common methodology for identifying public entities. IATI is willing to seed and host this but is not, in my view, an appropriate home in the longer term.

 

Time I'm just back from hols and have not absorbed your wikidata stuff yet ...

 

Best

 

Bill

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Mark Brough]

Hi Bill, all

 

Agree very much with establishing a working group to sort this out properly.

 

Without wanting to pre-empt discussions that will flow from that, my strong suspicion is that authority lists won’t be sufficient and that some system of self-registration (or organic/demand-driven creation) of organisation identifiers will be necessary to fill the gap.

 

I also think some centralised API is going to be necessary to make these organisation IDs discoverable and encourage some consistency in usage. That could, for instance, also solve the problem of multiple / duplicate identifiers and encourage convergence towards a “preferred” identifier over time.

 

Mark

[Herman van Loon]

Hi Mark, all
I share the same suspiction. Maybe it is possible to combine both approaches.

Good to have a working group for this subject.


Best Herman

[Bill Anderson]

·         We need a consortium to work through the complexities of implementing a common approach, NOT to agree a common approach.

·         There is only one basic methodology [registration agency / vocabulary / authority - plus id] on the table and if we don't adopt it now the 'pragmatic' objections will have multiplied exponentially by the time the next integer upgrade comes around.

·         Why authority lists are important, and why organisation identifiers need to be meaningful is that someone needs to decide which organisation one is trying to reference. I refer you to Chris Taggart's work in the private sector which has explored this issue in some depth (eg http://blog.opencorporates.com/2013/04/18/what-makes-a-good-company-register-part-1-the-public-purpose/)

·         Creating a registration agency that allows for self-registration is a feasible option within this framework.

·         This is not a new issue. IATI has done a lot of work on this over the past few years. I accept that this may not always have been best communicated, but we have been round the block a couple of times...

 

 

From: iati-te...@googlegroups.com [mailto:iati-te...@googlegroups.com] On Behalf Of Herman van Loon
Sent: 13 August 2014 11:30
To: iati-te...@googlegroups.com
Subject: Re: [IATI Tech] A possible solution to Org IDs

 

Hi Mark, all

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Cristián Mansilla]

I think a good start could be define what does it mean "organization", since we are having some problems in that sense. For example, we have as participating organization WHO-Essential Medicines and Health Products (EMP). However, we are reporting this as just WHO. Same issue with STOP TB partnership. Then, changing the perspective, how could it be managed the change?, For example and especially for pharmaceutical companies, merges are a problem. 

Considering this, I would suggest that this consortium should definitely have some legal staff involved.

On Wednesday, August 13, 2014 2:29:58 PM UTC+2, Bill Anderson wrote:

·         We need a consortium to work through the complexities of implementing a common approach, NOT to agree a common approach.

·         There is only one basic methodology [registration agency / vocabulary / authority - plus id] on the table and if we don't adopt it now the 'pragmatic' objections will have multiplied exponentially by the time the next integer upgrade comes around.

·         Why authority lists are important, and why organisation identifiers need to be meaningful is that someone needs to decide which organisation one is trying to reference. I refer you to Chris Taggart's work in the private sector which has explored this issue in some depth (eg http://blog.opencorporates.com/2013/04/18/what-makes-a-good-company-register-part-1-the-public-purpose/)

·         Creating a registration agency that allows for self-registration is a feasible option within this framework.

·         This is not a new issue. IATI has done a lot of work on this over the past few years. I accept that this may not always have been best communicated, but we have been round the block a couple of times...

 

 

From: iati-te...@googlegroups.com [mailto:iati-te...@googlegroups.com] On Behalf Of Herman van Loon
Sent: 13 August 2014 11:30
To: iati-te...@googlegroups.com
Subject: Re: [IATI Tech] A possible solution to Org IDs

 

Hi Mark, all
I share the same suspiction. Maybe it is possible to combine both approaches.

Good to have a working group for this subject.


Best Herman

--
You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 

To post to this group, send email to iati-t...@googlegroups.com

 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Herman van Loon]

Unfortunately there are not only ‘pragmatic’ objections against the current 2.01 proposal for organisation id’s (it’s disruptive nature). The 2.01 proposal has a fundamental problem which should in my opinion be addressed before a decision is taken on its implementation. The core of the problem is that in the current proposal, the organisation id is a MEANINGFULL id instead of a MEANINGLESS id. I will try 1) to explain this with an example and 2) sketch a modification of the current proposal using the ideas presented by several other people on this and other forums.

1) the problem of using a meaningfull id

When elements of the proposed org id  [registration agency / vocabulary / authority] change, ALL IATI publishers of the affected org id’s will need to change their publications. Let’s say by example that in order to combat tax evasion and fraud, the EU member states decide that in 10 years time there will be an European registration authority for all European private sector organisations, replacing all the current registration authorities within the EU. The consequences for IATI publishers would horrendous, because of the pervasive use of meaningfull org id’s of European private organisations throughout thousands of IATI files. The usability of IATI data would be severely degraded for many years. This problem is inherent to any identification system using meaningfull identifiers (including the current 1.x system).

2) what is the alternative ?

So the current methodology (both 1.x and 2.01) is flawed. An modification of the current proposal could strengthen it considerable though, avoiding the problems mentioned above and providing some substantial additional benefits. The modification is to have a unique MEANINGLESS IATI organisation id AND use the identifications provided by registration authorities (if available) as additional ATTRUBUTES. The IATI organisations id’s and their attributes are maintained in a CENTRAL REGISTRY. All organisations enter themselves in this central register:

-       The self-registering service provides the assignment of an unique meaningless IATI organisation id.

-       The organisation can enter the official identification(s) provided by registration authorities. If possible the registration service populates the fields automatically using the machine readable data of the registration authority.

-       The self-registering service enforces the uniqueness of the use of id’s of registration authorities.

-       It is possible to enter the identifiers of multiple registration authorities for one organisation (so organisations can be referred to even if they are registered by several registration authorities).

-       It is possible to enter data (name, organisation type, legal type, etc.) even if there is no  registration authority for an organisation (solving e.g. the problem of government entities and local NGO’s)

-       IATI publishers and users can access (search , retrieve, etc.) this central register through an API in the same way access to the IATI code list is being supported right now.

-       The currently used organisation identifier could be added as the attribute ‘IATI-organisation-legacy-identifier’, facilitating the migration to the new identification schema.

Using this approach, changes in registration authorities will only have an impact on ONE PLACE: the central register, and not on the whole IATI community. The advantages of the current 2.01 proposal will be fully maintained, because all IATI organisations can be referred to by making use of the official registration authority identifiers. This modified approach also solves the problem when an organisation has no id from an official registration authority.

[Bill Anderson]

A few questions, Herman

 

1.       What should other standards do? eg. OpenContracting. Also create their own registry on which you would have to self-register?

2.       How do you reference an organisation that has not self-registered?

3.       Who maintains the integrity of this new Central Registry. For instance what stops me from self-registering as someone else?

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 

To post to this group, send email to iati-te...@googlegroups.com

 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Tim Davies]

Hello Herman, Bill

I think it is worth separating two uses of Organisation Identifiers in IATI here:

(1) The use of the Organisation IDs to construct Activity IDs (i.e. the {Publishers Organisation ID}-{Publishers Activity ID} pattern)

(2) The use of Organisation IDs to simply identify organisations

I do think there is a very legitimate concern raised by (1) that, if the current Organisational ID proposals of updating to better schemes should they come along is applied, that we get a substantial 'shuffle' of activity identifiers, which is very problematic for tracability, and for any systems trying to aggregate together files which are using matching on activity ID to recognise unique activities.

However, this is also a much more tractable small set of organisations for self-registration, and in practice IATI (and Open Contracting etc.) may already have a self-registration for such organisations in terms of their ID on the IATI Registry.

For (2), I had always envisaged that some degree of shuffle was inevitable, but through (a) encouraging publishers to provide alternative IDs for organisations; and (b) encouraging development of community maintained mappings, it should be possible to develop tools which mitigate the impacts of any large shuffles (in any case, for analysis of data that seeks to match organisations, unless you introduce a centralised system which is very difficult for some of the reasons Bill sets out above, you would need tools that can do mapping to cope with the different quality of identifiers that different publishers were able to use given the data in their current systems).

Hope this helps support discussions in some way...

All the best

Tim

[Dan Mihaila]

Hello,
I think you all had good questions and raised concerns, but we should look to the positive side and try to start something that the involved actors could use and/or give feedback.

I agree that we will need a common service that will help with the registry and will have to be accepted. I see this similar with the SSL for web applications (http://en.wikipedia.org/wiki/Secure_Sockets_Layer) where you need a signed certificate to obtain the √ ok

How this URI (Unique Resource Identifier) is built or generated could be more a technical decision and could have a human readable solution or a long meaningless string (like a hash). I think it is more important to have a service that can provide accurate and live information about the identifiers and organization information.

I remember that at TAG meeting we also discuss about how to structure organizations (HQ, country offices, etc) and if each entity will have a different code or not.

All the best,

Dan

Dan Mihaila, IT Consultant
(M) +40 722 502 304 • (GTalk) dan.m...@gmail.com • (Skype) carcotelul
• (Yahoo) carcotelul
 

[Herman van Loon]

Hi Bill,

I will try to answer your questions below:

1.       What should other standards do? eg. OpenContracting. Also create their own registry on which you would have to self-register?

Trying to get the organisation-identification problem straightened out just for IATI is already very hard. I would be very reluctant to broaden the scope to other standards and increase complexity. There are profound differences between business, legal and financial entities. These are quite different domains, with different information requirements including the object of identification. It draws IATI into the complex arena of legal identification. Isn’t the goal of IATI to support of aid management and not legal or financial accounting?

So when referring to legal or financial entities, these other standard should definitely maintain their own registry. In the future we could, if necessary, link up these registries with IATI by describing the relations between them, in order to answer the ‘cross domain’ questions.

The broadening of the scope of the organisation-identification by including other standards has far reaching consequences. Therefore I suggest this should not implicitly be decided as a part of the introduction of the 2.01 version of the IATI.

2.       How do you reference an organisation that has not self-registered?

You ask this organisation to register themselves in order to receive funds. The registration process itself should be a onetime very simple activity. Or you accept that there is no registration because of privacy concerns or if the amount of funds involved is relatively small. In the current situation we have no insight whatsoever in the aid chain. When we have the registration of all the major players (including public organisations) AND use this registration in our publications, we will already have gained an enormous amount of information.  

3.       Who maintains the integrity of this new Central Registry. For instance what stops me from self-registering as someone else?

The central registry is maintained by the organisations who register themselves. Safeguards are built in to enforce the uniqueness of names and official registration codes used in the attributes.

Concerning the question what stops someone from misrepresenting themselves: what will stop me from using an official id belonging to somebody else in the current proposal? Having a central registry is in this regard not better or worse. In my opinion IATI should be built on trust. When it is built on mistrust, a whole different range of requirements will need to be implemented and will add enormously to the complexity without real added value. Going down this road, will alienate current and future IATI publishers because of the difficulties to implement the ‘abuse prevention’ requirements.

To post to this group, send email to iati-t...@googlegroups.com

 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[David Megginson]

I understand Herman's concerns about the implementation details, but I think we should focus on the most-important part of Owen's suggestion (and the draft IATI Organisation ID Standard) first: that we need to distribute the management of org ids, rather than trying to manage them all centrally. We already do that with the @vocabulary attribute sector codes (and similar), so it's not a huge change.

The problem

Before CIDA disappeared into DFAIT-D, the Canadian federal government had 14 different organisations reporting ODA: http://www.oag-bvg.gc.ca/internet/English/parl_oag_201304_04_e_38189.html#hd5a ; even more seriously, the Canada Revenue Agency (CRA) has registered over 80,000 charities, some unknown number of which are involved in ODA. Multiply these numbers by the number of donor countries, then add in national NGOs and community orgs in partner countries, and we have a big problem.  

Possible solutions

There are three possible approaches to managing an identifier space like this:

1. The IATI Secretariat tries to manage millions of identifiers itself (tens or hundreds of thousands of which change every year).
2. The IATI Secretariat asks local registrars to manage identifiers in an IATI-controlled database.
3. IATI develops a mechanism for pointing to different collections of identifiers already being managed externally.

I'd suggest that (1) is impractical, and (2) is unrealistic.  We have nowhere near the resources to keep track of org identifiers once we move beyond the (small number of) big national donors, and while we could ask national and local registration authorities like CRA to double-enter their charity-registration information into an IATI-controlled database, it isn't going to happen.

So that leaves us with what Owen and the draft OrgID standard are suggesting, (3), where we have in essence a namespace arrangement that lets us say "this org's identifier is XXYYZ according to the Canada Revenue Agency."  Now the problem is reduced to our maintaining identifiers for a few hundred registrars, rather than a few million organisations. It's still a non-trivial problem, but I think it's one we can manage.

Does everyone agree this far, before diving back into the details?

Cheers, David

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 

To post to this group, send email to iati-te...@googlegroups.com

[Bill Anderson]

Thanks David for presenting this with more clarity than I have managed.

I agree

Sent from my iPhone

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[David Megginson]

Thanks, Bill. So if everyone else also agrees on (3) — distributed management of identifiers — then our= implementation decision is between separate components and a single prefixed string.

Owen's suggestion is to add a separate @vocabulary-uri attribute to point to the registrar, so we'd have something that looks like this (please correct me if necessary, Owen):

<participating-org 

  vocabulary-uri="http://www.cra-arc.gc.ca/chrts-gvng/lstngs/" 

  ref="118838333RR0001">CARE Canada</participating-org>

The OrgID draft's suggestion is to maintain a registry of registrars, so to speak, and then include a short registrar code as a prefix to the org code, so we'd have something that looks like this (assuming that IATI decides to use the namespace code "CRA" for the Canada Revenue Agency):

<participating-org ref="CRA-118838333RR0001">CARE Canada</participating-org>

The benefits of Owen's approach are that it's open-ended — you can point to the URI of a new org registrar without waiting for the IATI secretariat to add it to the list of approved registrars — and that the URI could, in principle, be an actual pointer to a downloadable list, providing a RESTful end-to-end system (though in practice, most registrars don't provide anything like that right now).

The benefits of the OrgID draft's approach are that the markup is much simpler and shorter, and that IATI can perform some quality control by accepting only certain registrars (rather than allowing a reporter to plunk in any convenient URI). The syntax may have issues, especially if both the namespace/registrar id and the local org id have hyphens in them, but that's a detail we can work out.

So the big considerations are (1) open-ended or closed, controlled system? and (2) how important is it to minimize the amount of markup?

Cheers, David

[Bill Anderson]

David we need to get the opinions of Herman van Loon, John Adams and Mark Brough on this. I'm not sure we have consensus. If either the UK or Netherlands are unhappy with this to the extent that they may veto it at the Steering Committee then we will have to drop it.

John, Herman, Mark, could you comment?

Thanks

Bill

Away from my desk. Sent from my iPad

[Herman van Loon]

Hi Bill, David, Owen and others

I do not agree with the proposed way of implementation because the registrar identifiers will be directly used as identifiers of IATI organisations. The suggested implementation proposals will be very disruptive for all IATI publishers when there is any change in registrars. The proposals also do not cover government organisations and organisations for which there is no registrar.

The disruptive nature of changes in registrars can be avoided by introducing a meaningless IATI identifier (e.g. a sequence number) and optionally couple this identifier in a central repository to one or more registrar identifiers. So I have no objections against the use of registrar identifiers as an additional means of referring to IATI organisations, but I have objections against using them directly as the IATI identifier.

[Bill Anderson]

Hi Herman,

 

I fully accept that the distinction you make (raised also by Tim Davies) between organisation and activity identifiers is valid.

 

I remember, David, that one of the original principles adopted for activity identifiers is that they should be persistent.

 

To be clear, the issue is NOT that the immediate impact of normalising identifiers in the 2.01 upgrade is disruptive, but rather that the existing activity identifier rule is flawed and disruptive: namely that the activity identifier MUST be prefixed with the reporting organisation identifier (and therefore will not be persistent if the reporting organisation changes).

 

There are a number of reasons why organisation identifiers may legitimately change as the result of mergers, acquisitions, reorganisations, etc. But as an activity-based standard it is disruptive for the key unique identifier to change.

 

For IATI to maintain a registry (including an historical audit) of all identifiers reported through the standard is far less problematic than any attempt for it to maintain an authoritative registry of organisations.

 

A possible solution for  activity identifiers is therefore:

·         New activities are named according to the existing methodology (with the reporting organisation prefix)

·         Once reported an activity should never change its identifier. It will always contain the prefix of the organisation which first reported it.

·         IATI maintains a utility that maps all activity-identifiers against current reporting organisation identifiers

·         In version 2.01 the proposal that activity identifiers MUST be prefixed by the reporting organisation identifier is  scrapped.

 

Do we have a possible breakthrough?

 

Bill

 

 

From: iati-te...@googlegroups.com [mailto:iati-te...@googlegroups.com] On Behalf Of Herman van Loon
Sent: 25 August 2014 11:31
To: iati-te...@googlegroups.com
Subject: [IATI Tech] Re: A possible solution to Org IDs

 

Hi Bill, David, Owen and others

I do not agree with the proposed way of implementation because the registrar identifiers will be directly used as identifiers of IATI organisations. The suggested implementation proposals will be very disruptive for all IATI publishers when there is any change in registrars. The proposals also do not cover government organisations and organisations for which there is no registrar.

The disruptive nature of changes in registrars can be avoided by introducing a meaningless IATI identifier (e.g. a sequence number) and optionally couple this identifier in a central repository to one or more registrar identifiers. So I have no objections against the use of registrar identifiers as an additional means of referring to IATI organisations, but I have objections against using them directly as the IATI identifier.

 

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Mark Brough]

Hi David, all

Yes, in general I think your (3) - distributed management of organisation IDs - makes sense. I think the methodology currently in place for private sector organisations is probably the only sensible way to do this. (I'm not sure problems with referencing authority lists have been sufficiently explored though)

However, for public sector bodies there is currently no good methodology because for many organisations there are no authority lists to speak of.

I think there are two issues with the current proposal:
1) It doesn't solve the problem;
2) It creates additional disruption, particularly for potential users of the data.

1) Adding the prefix "XM-DAC" to existing DAC donor / agency or channel of delivery codes does not solve the problem of the funders (e.g. UNOPS, several EC agencies) and implementers (e.g. Ministries in partner countries) that do not have an organisation ID provided by the DAC. Indeed, the draft paper that Bill previously referred to on this stated that reliance on DAC codes was "not viable". [1] This is the real problem that we need to solve with organisation identifiers.

2) The proposal also creates disruption for those lucky enough to be on the list. Even replacing GB-1 directly with XM-DAC-12-1 would take time to propagate so in reality we're actually creating a duplicate identifier for some period of time. Then factor in the likelihood of getting it wrong [2] and this would likely be quite heavily disruptive. That disruption would be justifiable if we were really solving the problem, but we're not.

We need a solid proposal that deals with these issues while building broad consensus. Asking the Steering Committee to establish a working group and give it a mandate might be useful. (I'd be very happy to join such a group, as I've said before.) I'd suggest that in the meantime, the methodology should remain as at present:

1) Is the identifier on the IATI organisation identifiers codelist?
2) If not, does it conform to a standard pattern?

Mark

[1] https://docs.google.com/document/d/1FAMcPHB25TC9xUKcC-WdwYquiiH1Vqcq0dN0kCSOKg4/edit#heading=h.qm6uq51idybp
[2] http://aiddata.org/blog/the-maturing-of-the-iati-data-standard-ensuring-quality-in-a-highly-networked-environment

[Mark Brough]

By the way, I should also say that the IATI/DI GEI paper I linked to below is quite useful in starting to think through the various options - would be a very good starting point for further discussions.

[Bill Anderson]

The EU now has an authority list on its corporate bodies (including historical audits). http://open-data.europa.eu/en/data/dataset/corporate-body

 

 

From: iati-te...@googlegroups.com [mailto:iati-te...@googlegroups.com] On Behalf Of Herman van Loon
Sent: 25 August 2014 11:31
To: iati-te...@googlegroups.com
Subject: [IATI Tech] Re: A possible solution to Org IDs

 

Hi Bill, David, Owen and others

I do not agree with the proposed way of implementation because the registrar identifiers will be directly used as identifiers of IATI organisations. The suggested implementation proposals will be very disruptive for all IATI publishers when there is any change in registrars. The proposals also do not cover government organisations and organisations for which there is no registrar.

The disruptive nature of changes in registrars can be avoided by introducing a meaningless IATI identifier (e.g. a sequence number) and optionally couple this identifier in a central repository to one or more registrar identifiers. So I have no objections against the use of registrar identifiers as an additional means of referring to IATI organisations, but I have objections against using them directly as the IATI identifier.

 

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Herman van Loon]

Bill,

I like the idea in principle, because it provides far more stability when there are changes in the reporting organisation. But how would, without mandatory organisation prefix , the uniqueness of the identifier being guaranteed? And from the practical point of view: is this feasible to implement within a reasonable amount ot time? 2.01 is quite a drastic change already?

On the organisation identifier itself still remains the question if this is a meaningfull or meaningless  identifier. These identifiers are not only used as a part of the activity identifier, but also in several other places in the standard, so the question is not solved by changing the activity identifier.

An IATI organisation is not by definition the same as an legal entity, and does not need to have a KvK like number. Also organisations with different names (as frequently is the case) can share the same KvK like number (because they belong to the same legal entity).

So the key question is: what should the IATI organisation identifier identify?

In my opinion the IATI organisation identifier should represent a business entity determined by the publishing organisation itself. Some organisations might prefer to have a 1 to 1 match between the business and legal entity. Others might prefer to represent themselves as one IATI organisation, encompassing multiple legal entities.  It is not up to IATI to make this decision. IATI might consider to facilitate the registration of the relation between the IATI organisation identifier and the corresponding legal or other identifiers(s).

[Chad McEvoy]

Hi Everyone,

Sorry to interject out of the blue but I wanted to remind you all about the BRIDGE project and start a conversation about how it might be a tool that could potentially address some of these issues for you.   BRIDGE is an effort to create a unique ID system for the whole of the global social sector.  It is being funded by the Gates Foundation, the Hewlett Foundation and Google.org.  We are now in the process of wrapping up major initial technical development work and have loaded the system with approximately 3,000,000 uniquely identified organization records from the databases of the Foundation Center, GuideStar, GlobalGiving and TechSoup Global.  We are going through a process of internal integration, testing and data clean up at the moment—but when this becomes available publicly it will provide both a UI and API interface for retrieving BRIDGE ID numbers based on all sorts of data normalizations and matching/deduplication algorithms that have been extensively tuned to work especially well with global nonprofit organizational datasets.  It is likely that this system could be an extremely useful tool for the IATI community.

We are proving it works now.  Foundation Center, GuideStar, GlobalGiving and TechSoup Global are making sure we can ping the system, insert records and verify matching routines, and when it looks good, we will be rolling it out.  In addition to the current testing and integration work underway we are in the process of researching and evaluating long term sustainable business model options for the system as well as collecting use cases and feature requests for future implementation.  I would be very interested in starting a dialogue (here or elsewhere) with anyone from the IATI community who would be interested in learning more about BRIDGE and contributing thinking to its ongoing development.

Regards,

Chad McEvoy

BRIDGE Project Manager

[Herman van Loon]

Hi Chad,
Interesting to hear that the BRIDGE project seems to tackle the same problem we try to address. From your description I understand that:
1 - a bridge id is a meaningless number for which an non-profit organisation should register themselves;
2 - that it's current scope is the worldwide NGO community;
3 - that it does not include government bodies and private sector organisations.

Is this correct?

I am curious what a bridge-id actually identifies. Is this a legal entity, a financial entity, or something else, or is it up to the organisation which applies for the number? Is a bridge registration moderated? Are there any fees for organisations who register?

Kind regards
Herman

[Din esh]

More about BRIDGE in the link. 

http://www.marketsforgood.org/bridge-to-somewhere-a-conversation-with-global-giving-guidestar-the-foundation-center-and-techsoup-global/

I was part of it when it got initiated, while at TechSoup. Speak to Paul van Haver at TechSoup, he should be able to help you. 

Paul: https://www.linkedin.com/in/paulvh. Think Tim Davies knows him

Cheers,

Dinesh

--

[Chad McEvoy]

Hi Herman, 

1) Yes, but currently the system is comprised of the de-duplicated combination of the databases from the four core partner orgs.  So that is 3 million orgs that already have BRIDGE IDs associated with them.  The process for self registration once the system goes public has not been totally decided upon, but there will be one.

2) Correct

3) No, just organizations at this time.  We may add additional entity types in the future (ie programs) but I don't see us adding private sector entities.  Here are the definitions from the BRIDGE project charter that we are trying to stick to:

 

1.      Only organizations will be imported into BRIDGE in the first system iteration.

1.1.   BRIDGE definition of an organization:

1.1.1.An organization is not “ad hoc”, meaning it has some distinct legal personality.

1.1.2.An organization is able to send or receive philanthropic resources.

1.1.3.An organization is not a natural person.

1.1.4.An organization is not a program (as defined below). 

1.2.   BRIDGE definition of a program:

1.2.1.A program is an entity which does not have a distinct legal personality.

1.2.2.A program is dependent on one or more encompassing organizations (as defined above).

1.2.3.A program has a charitable purpose.

We will not charge any sort of fee to receive a BRIDGE ID.  Most of the org data that will be loaded into the system will be moderated in the sense that it will come out of datasets that are already fairly well polished and curated.  Individual registered orgs will be moderated at least enough to make sure we are not including garbage/nonsense data. 

Let me know if that answers your questions.  I'm happy to field more!  

- Chad 

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---

You received this message because you are subscribed to a topic in the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/iati-technical/pjXkBP5Mef4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to iati-technica...@googlegroups.com.

[Bill Anderson]

For the record, I sit on the BRIDGE advisory board on behalf of IATI.

 

IATI's interest in BRIDGE in the first instance has been that it will allow for self-registration of NGOs that do not have access to any other recognised Registration Agency (or where existing agencies are used for repressive control). In the longer term, as a global rather that US-philanthropy-led initiative, BRIDGE could potentially play a useful role cross-mapping identifiers between agencies, leading to unique identification of NGOs around the world.

 

We still need to deal with public entities ...

 

Bill

 

From: iati-te...@googlegroups.com [mailto:iati-te...@googlegroups.com] On Behalf Of Chad McEvoy

Sent: 29 August 2014 01:30
To: iati-te...@googlegroups.com

You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Sarah Johns]

Hello, I work with NGOs in the UK and Southern countries, and have been following this conversation with interest. Chad - I have a couple of questions about the Bridge Project:

1. I'm not sure I understand the rationale of only applying it to NGOs. As you know the development community is made up of different entities, including foundations and private sector organisations, both of whom play a big role in providing what's termed as 'private development assistance' alongside NGOs. What registration system would they be expected to use and would that then produce more of a challenge? 

1. What is the sustainability plan (both financial and in terms of iteration) for Bridge beyond the support from the Gates Foundation? For example from the two illustrations given in the article, international book registration ISBNs are allocated via national registration agencies, and this is a service that book publishers pay for in most countries. And vehicle registration numbers have been updated a number of times since their inception to reflect changes in manufacturer practice and the increase in users by two agencies in the US. 

2. What interest have you had from NGOs themselves for this type of ID and how would you encourage them to use the IDs in their data? Do you have NGOs from outside the US on the Board?

3. What interest have you had from foundations etc outside the US in using the BRIDGE system? 

It'd be great to get more information, as I couldn't find much online.

Kind regards,

Sarah

[Bill Anderson]

I would like to see whether we now can reach a consensus to move forward - specifically for the 2.01 upgrade.

(Discussion on this thread has moved here from http://support.iatistandard.org/entries/77310197-Version-2-01-Iteration-2-5-A-consistent-approach-to-OECD-DAC-organisation-identifiers?page=1#post_22190619 - so I am going to post this in both places.)

The issue is not directly related to the changing of DAC 'codes', but specifically to how we validate organisation and activity identifiers.

• In Strengthening the Core of the Standard we have  proposed that all organisation identifiers MUST be prefixed with a code from the OrganisationRegistrationAgency code list.
• I think we now have consensus on this.
• There is an outstanding proposal that the prefix (vocabulary/uri) is stored in a separate attribute. This proposal still accepts the necessary association between an identifier and a registration agency.
• There is still a lot more work to be done on:
• public entity identifiers
• a self-registration registry
• a common approach by IATI, OpenContracting, HXL and others to solving gaps and problems
• but this outstanding work does not negate the establishment of the rule.
• The second proposal made in Strengthening the Core is that the activity-identifier MUST be prefixed with the reporting organisation's identifier
• Opposition to this is at the heart of Herman van Loon's dogged contributions to this discussion and we now fully understand and accept his argument.
• As an activity-based standard, persistent activity identifiers are necessary. There are reasons why organisation identifiers may need to change as a result of mergers, acquisitions or reorganisations. But to track activities over time, and the traceable flow of resources between activities - changing activity identifiers is unworkable. 
• We need to agree a new approach to guidance on activity-identifier. A possible solution is to maintain the current methodology (reporting-org/@ref prefix) when first reporting an activity PROVIDED that it is never changed in subsequent updates, even if the reporting-org/@ref changes. This has the added benefit of showing the origin of an activity where organisational changes have taken place.

 

So, the actual changes required to the 2.01 proposal are (in Strengthening the Core of the Standard) the removal of two lines (struck through), and the addition of one (underlined) - as below

Reporting organisation

• The reporting-org element is MANDATORY.
• ALL the following rules must apply to the organisation-identifier in reporting-org/@ref
• It is mandatory
• The agency prefix MUST be a valid code in the IATI code list
• The identifier MUST be the prefix to the iati-identifier
• The identifier MUST be the same as that recorded by the publisher on the IATI Registry
• The identifier MUST only contain alphanumeric characters and hyphen, underscore, colon or period

IATI activity identifier

• The iati-identifier is MANDATORY
• It MUST be globally unique among all activities published by a single reporting organisation
• Once an activity has been reported to IATI its identifier MUST NOT be changed in subsequent updates,
• It MUST be prefixed with the organisation-identifier found in reporting-org/@ref
• The identifier MUST only contain alphanumeric characters and hyphen, underscore, colon or period

[Herman van Loon]

In this modified proposal the first question which remains is how the uniqueness of the IATI activity identifier can be guaranteed. Unless I am mistaken, it can not when the organisation prefix is not required. In the original proposal the uniqueness is guaranteed because the IATI activity identifier is always preceded by the organisation id. So uniqueness of the IATI activity identifier in the old proposal is the responsibility and under control of the publisher. In the modified proposal this is no longer the case. This can be solved if the IATI activity identifier is still be prefixed by the organisation identifier of the organisation which published the activity the first time. This prefix should not change anymore thereafter. Under these conditions uniqueness can be guaranteed. Suggested rule: replace the strikethough
It MUST be prefixed with the organisation-identifier found in reporting-org/@ref with 'it must be prefixed with the organisation identifier the activity was orginally being published'

Because there are already 269 publishers, I would strongly suggest leaving the organisation identifiers currently in use, unchanged. This will avoid disruption when migrating to 2.01. To comply with the 2.01 standard, the URI to the existing IATI organisation codelist should be specified as @vocabulary-uri. Although these ‘legacy’ organisation identifiers will not be prefixed with their registration agency, it will be unambiguous from the URI that IATI is the registration agency.

The second question which remains is what to do with organisations for which there is no registration agency. In my opinion we should not postpone this discussion but agree on the principles how to solve this issue now. Otherwise the solution might impact the very rules and guidelines we are trying to establish right now and could therefore be quite disruptive. Implementation of the solution could be after the introduction of 2.01. A solution would be to have a self-registration service, for which IATI is an alternative registration agency (XM-IATI?). The actual identification would be XM-IATI-<meaningless number>.

[Bill Anderson]

Hi Herman

·         "Suggested rule: replace the strikethough It MUST be prefixed with the organisation-identifier found in reporting-org/@ref with 'it must be prefixed with the organisation identifier the activity was orginally being published'"

o   I agree. And no existing identifiers are changed.

·         A self-registration service, for which IATI is an alternative registration agency (XM-IATI?). The actual identification would be XM-IATI-<meaningless number>.

o   I agree. This would in the first instance be manually maintained. Netherlands MFA could retain its existing identifier and be XM-IATI-NL-1

o   Exploratory discussions are taking place with OpenContracting and UNOCHA on a joint approach to filling the gaps

·         To comply with the 2.01 standard, the URI to the existing IATI organisation codelist should be specified as @vocabulary-uri

o   I disagree.

o   Firstly , if the identifier is split into two parts (Agency in @vocabulary-uri and identifier in @ref) the identifier itself will no longer be unique.

o   Secondly, this is more disruptive than the original proposal (see below)

o   Thirdly, for ease of reference identifiers are better maintained as single objects.

·         Because there are already 269 publishers, I would strongly suggest leaving the organisation identifiers currently in use, unchanged.

o   I disagree. The least disruptive path would be for the 49 (not 269) publishers affected to add XM-IATI as a prefix onto their existing identifiers

·         Disruption

o   We currently have 275 publishers.

o   Asking all publishers to comply with an organisation identifier prefix requires 48 publishers to change. Most publishers already follow the methodology. NB this change is to organisation identifier only, (NOT activity identifier)

o   Adding a vocabulary-uri will require all 275 publishers to change

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[David Megginson]

On Tue, Sep 2, 2014 at 6:39 AM, Bill Anderson <Bill.A...@devinit.org> wrote:

Hi Herman

·         "Suggested rule: replace the strikethough It MUST be prefixed with the organisation-identifier found in reporting-org/@ref with 'it must be prefixed with the organisation identifier the activity was orginally being published'"

o   I agree. And no existing identifiers are changed.

Yes, I also think this is the right choice: it's better to preserve the information as it was, rather than trying to force forward-looking continuity on it. So perhaps we can check off at least one item.

Cheers, David

[Mark Brough]

There are definitely benefits to having persistent iati-identifiers. However, the core concerns remain – the proposal still doesn’t provide us with a methodology for identifying any more public bodies, and it still creates quite a lot of disruption.

 

An IATI codelist will remain necessary for some existing publishers not on the OECD-DAC list (UNOPS, EC Enlargement, World Bank – although IDA and IBRD have codes, WB as a whole does not). Given this, it's unclear why we can't just continue for now with a default that if no registration agency is declared, it's assumed to be on the IATI organisation identifiers codelist. So there's no disruption now and would allow time for a working group to put together a more complete proposal on organisation identifiers, including how to identify all public bodies.

 

I do think we should consider some system of self-registration. I think the flexible ID standard Herman suggests has some merits, although not sure all identifiers need to be meaningless – created/merged/abolished organisations could just forward onto the new organisation containing those identifiers. I think if we had a decent self-registration and reconciliation API in place along with a solid methodology then we could 1) fix the problem of creating organisation identifiers for public bodies, so the benefits would significantly increase and 2) either not need to change identifiers or the cost of doing so would be significantly reduced.

 

As things currently stand (and while persistence in iati-identifiers is desirable), there could also be some big implications from this proposal that are worth thinking through. In addition to those points raised by Herman,

 

• All publishers will need to maintain lists of whether activities have previously been reported or not, given that iati-identifiers are at the moment structured as [organisation id]-[organisation's project ID]: so a DFID activity 001 published today would be GB-1-001, and another activity 002 published tomorrow would be XM-DAC-12-1-002
• Traceability will become more difficult as implementers / co-funders will need to know both the old and new organisation identifiers AND the project ID (or, contract documents could include the new organisation ID and the full IATI-identifier rather than just the project ID?)
• There will be duplicate organisation IDs for each organisation (because of `transaction/provider-org/@ref` and `participating-org[@role="Funding"]/@ref` in implementing organisations' activities), which have to also be reconciled. This will remain even if we have persistence in iati-identifiers.
• It will become more difficult to ask questions about relationships between participating-orgs (e.g. who else is X funding, who else is giving money to Y) if they change. Traceability is clearest at the transaction level, but it also occurs at the participating-org level in a simpler way
• Even with the latest suggested changes, it will become increasingly difficult to ensure that activities are globally unique. At the moment ensuring that an iati-identifier begins with the `reporting-org/@ref` is a straightforward way of ensuring that publishers are publishing iati-identifiers in a way that is pretty likely to be globally unique. If activities could start with something not stated elsewhere in the activity (i.e. a previous organisation identifier), then programmatic testing of this becomes difficult and compliance could fall.

 

These implications don’t mean that we should never change organisation IDs (either along the lines of the previous or current proposals), just that doing so is likely to be disruptive. So we should balance the costs and benefits and make sure we don’t have to do this more than once.

 

--
Mark Brough
Aid Information Advisor, Publish What You Fund
Skype: mark-brough - Twitter: @mark_brough

[Bill Anderson]

Thanks Mark

 

·         "the proposal still doesn’t provide us with a methodology for identifying any more public bodies"

 

But it does.  It might not provide us with identifiers, but it provides us with a methodology to reference all identifiers that do exist. The next challenge is for IATI, OpenContracting, HXL and others to work together to find solutions USING A METHODOLOGY THAT WE AGREE UPON.

 

·         "it still creates quite a lot of disruption"

 

There are two types of disruption. The primary one is the ongoing real-world  phenomenon of organisations changing - this is a disruptive process that affects the way an organisation runs its business, its relationships with other organisations and the way in which information systems (among them IATI) reflect these changes.

 

The secondary one is the one-off, short -term request to ask 48 publishers to change their organisation identifier (along with changing the coding of activity statuses, activity dates, transaction types, narrative fields, etc).

 

There are preparatory discussions taking place for the building of utilities/search engines that will track and cross-map organisation identifiers and activity identifiers. This is taking place independently of this discussion, but will obviously help here.

 

·         "An IATI codelist will remain necessary"

 

Agree 100%. The starting point would be to include all existing non-prefixed identifiers in an IATI authority list. All that publishers will need to do if they do not wish to change to an alternate authority list is to prefix their existing identifier with XM-IATI. This list can also be used as a source of last resort for the identifying of ANY organisation that either does not have access to a more recognised identifier or prefers not to use one.

 

·         "it's unclear why we can't just continue for now with a default that if no registration agency is declared, it's assumed to be on the IATI organisation identifiers codelist"

 

Because the long-term benefits of having a consistent standard used by thousands of publishers outweighs the short-term disruption to 48 publishers (who are being disrupted by integer upgrade change at the same time anyway)

 

·         "I do think we should consider some system of self-registration"

 

Agree 100%. One solution (for NGOs) is already being explored by the BRIDGE project. Any self-registration system  is acceptable if it has credibility and we can reference it using our agreed methodology. For IATI itself to embark on this course would, at the moment, require resources beyond its current capacity.

 

·         "All publishers will need to maintain lists of whether activities have previously been reported or not,"

 

I think it is for the publisher to decide whether they store lists, or a database field or a date-based algorithm, etc. I agree this is a disruption but hardly insurmountable.

 

·         "Traceability will become more difficult"

 

I agree that transaction/provider-org/@ref is a challenge. HOWEVER IATI guidance on traceability is that it should be established through provider-activity-id which we have now protected.

 

·         "It will become more difficult to ask questions about relationships between participating-orgs"

 

cf my first point on disruption above. This is a real-world problem when organisations change.

 

·         "it will become increasingly difficult to ensure that activities are globally unique"

 

Not convinced that this will be the case. Cross-mapping utilities; a formal record of organisation identifier changes (eg. in registry or org file or activity file), the efforts of a working group to look at solutions ...

 

·         make sure we don’t have to do this more than once

 

In my opinion the two things we have to nail properly NOW is a standard methodology for organisation identifiers; and the persistence of activity identifiers. The scale of disruption if we delay a decision for two years  will indeed  be unsustainable

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

--
You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Adams]

Bill

Thanks for all the hard work you've done in getting us to this point.  The 2.01 proposal is now clear and there are good reasons for the proposal. 

Reporting organisation

I welcome the separation of the reporting-org/ref from the iati-identifier. 

Does that mean if I generate a codelist for all the UK Government and Devolved Administrations, and host as machine readble on data.gov.uk, that we can stick to something similar to (or even the same as) GB-1, GB-3, GB-21 etc? Or will we need to change to GB-GOV-1 etc?

On an aside, I find the XM-DAC-12 type location rather unappealing aesthetically. Terrible reason, I know.

Should we introduce a vocabulary attribute to reference a URI for the actual codelist for the organisation. That might make it easier to reference non-IATI codelists and encourage more interchangeability between IATI, OpenCorporates and others? 

IATI activity identifier

I welcome the persistence of the iati-identifier. That is a key consideration for us as we are implementing traceability (it's hard enough without changing the identifiers mid-way through the process!).

I think our publication process could handle the change of organisation - for us it would simply be a recording of the original iati-identifier in a static table and matching against it. 

However I think the identifier must be prefixed with an organisation identifier, to maintain global uniqueness. Would it be possible to have an additional field in reporting-org to indicate "previously known as"? So for example, if DFID were merged with the FCO by a future government, the reporting-org would be:

<reporting-org ref="GB-3" previous-ref"GB-1">

Although maybe we'd need previous-ref to be a series of strings if there was significant history....Maybe that's too complex and trying to solve a problem that really isn't there.

I'm broadly content with the proposal. The clincher for me is the iati-identifier persistence.

John

[Bill Anderson]

Thanks John

 

·         "generate a codelist for all the UK Government and Devolved Administrations"

 

 

We have a formatting rule for Registration Agencies that expects CC-AAA where CC is the ISO Country code (XM = multilateral) and AAA is an agency identifier. So unfortunately you would have to change from GB-1 to GB-GOV-1. (Your other option, other than XM-DAC-12-1 would be XM-IATI-GB-1, but it would be great if you could get buy-in for a GB-GOV agency)

 

·         "Should we introduce a vocabulary attribute"

 

I am not in favour of placing the registration agency in a separate attribute, splitting it off from the identifier, as this means that the identifier itself is not unique and users will have to reconstruct it every time they search for or reference an organisation or activity. I am in favour of an identifier URL that points to the organisation's  record on its registration agency site - but most agencies do not currently provide this service. NB that the Registration Agency URL is already recorded in the OrganisationRegistrationAgency codelist.

 

·         "encourage more interchangeability between IATI, OpenCorporates and others"

 

I think we should be doing two things: sharing the OrganisationRegistrationAgency codelist; and creating a shared Agency that develops a methodology for public entities

 

·         "Would it be possible to have an additional field in reporting-org to indicate "previously known as"?"

 

Eureka! I think this very simple suggestion is the breakthrough we need.  Here are some ideas:

 

·         Add reporting-org/@previous-ref to contain the previous identifier. This is the simplest but only allows for one. This could be a problem.

·         Add reporting-org/@previous-ref as a flag and allow multiple occurrences of the reporting-org element. I think this is messy for an element containing a key piece of data.

·         Redefine the other-identifier element to allow it to reference either organisations OR activities, and add other-identifier/@identifier-type with a codelist which includes "Previous Reporting Organisation Identifier" (This attribute/codelist would be a useful improvement in making other identifiers more accessible - e.g. for DAC reporters who include their CRS Id here)

·         We would now be able to validate the activity-identifier by saying that it must be prefixed either by the current or previous reporting-org.

--

You received this message because you are subscribed to the
"IATI Technical" discussion list. Find out more at http://www.aidtransparency.net/governance/tag
 
To post to this group, send email to iati-te...@googlegroups.com
 
To unsubscribe from this group, send email to
iati-technica...@googlegroups.com
 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iati-technica...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[Bill Anderson]

Could everyone who has been following this thread please note that the third iteration of the 2.01 proposal was released yesterday. This issue is dealt with in the forum here - http://support.iatistandard.org/entries/52824355-Version-2-01-Iteration-3-9-Organisation-and-Activity-Identifiers

It contains a new suggestion - using the other-identifier element to store previous reporting organisation identifiers. 

I would appreciate feedback on this asap: Either on this thread or as a comment on the above topic

Thanks

Bill

To post to this group, send email to iati-technical@googlegroups.com

 
To unsubscribe from this group, send email to

iati-technical+unsubscribe@googlegroups.com

 
For more options, including the option to switch to a digest subscription, visit this group at http://groups.google.com/group/iati-technical
 
Tickets for the IATI technical secretariat can be posted to http://support.iatistandard.org
---
You received this message because you are subscribed to the Google Groups "IATI Technical Advisory Group (TAG) technical discussion list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to iati-technical+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________