activity identifier can be equal to the organisation identifier

[andylolz]

I don’t think this rule is correct:

https://github.com/data4development/IATI-Rulesets/blob/fb7c7c6067e1b3f25af383ba54593e2742fcc1e8/rules/iati/identifiers.xslt#L18-L22

What’s the basis for it?

[PetyaKangalova]

Hi @andylolz

The validator runs two test:

One gives you an error and checks that the IATI org id and activity id are not the same. I agree that the language is a bit confusing at the moment. @rolfkleef , we suggest to change it to.

The iati-identifier must begin with either the current or previous IATI organisation identifier, followed by a unique reference for the activity.

There is also an additional warning added to the validator that checks that the iati-identifier follows this structure: IATI org id + dash + activity identifier.

[andylolz]

Hi @PetyaKangalova,

Thanks for getting back to me on this.

The validator runs two test:

One gives you an error and checks that the IATI org id and activity id are not the same

Yes, that’s the one. I don’t think the problem here is the language – the language accurately represents what the test is doing. The problem is the test itself.

I don’t think there’s any requirement that the IATI org id and activity id can’t be the same. It’s not stated in the standard, so adding a rule to that effect is potentially confusing.

Consider the following (contrived) example:

<iati-activity>
    <iati-identifier>XM-DAC-7-1</iati-identifier>
    <reporting-org ref="XM-DAC-7-1" type="10">
        <narrative>Org name</narrative>
    </reporting-org>
    <title>
        <narrative>Title</narrative>
    </title>
    <description>
        <narrative>Description</narrative>
    </description>
    <participating-org ref="XM-DAC-7-1" role="1" type="10">
        <narrative>Org name</narrative>
    </participating-org>
    <other-identifier ref="XM-DAC-7" type="B1" />
    <activity-status code="1"/>
    <activity-date iso-date="2020-04-01" type="1"/>
</iati-activity>

This XML is valid (according to the standard) but would fail this test. The iati-identifier and reporting-org/@ref are identical, because the org’s identifier has changed (note the other-identifier.)

Again, I realise this is a contrived example. I’m just using it to demonstrate that this rule is not only confusing, but is also technically incorrect.

There is also an additional warning added to the validator that checks that the iati-identifier follows this structure: IATI org id + dash + activity identifier.

Yes, that’s right. This (recently added) test is a much better one, because it’s consistent with the standard and will catch far more bad examples.

Hope that helps. If I can help clarify further, please just let me know.

[rolfkleef]

The current sequence of tests:

1) If the activity identifier does not start with an organisation identifier in reporting-org or in other-identifier[B1], we return 1.1.1: The activity identifier should begin with the organisation identifier of the reporting organisation (or a previous version included in the other-identifier element).

2) Else, if the activity identifier is the same as the reporting-org, we return 1.1.3: The activity identifier must not be the same as the organisation identifier of the reporting organisation.

3) Else, if the activity identiier is not an organisation identifier followed by a dash and some extra info, we return 1.1.21: The activity identifier's prefix and suffix should be separated by a hyphen e.g. XM-DAC-2222

4) Else, if the activity identifier does not start with a known organisation id in the Registry, we return 1.3.11: The activity identifier should begin with an organisation identifier approved by the IATI registry.

I think the confusion is that we had step 2 in our data quality feedback rules, and step 3 has been added as part of the IATI rulesets. Step 3 basically says that an activity identifier cannot be the same as the organisation identifier, but as a warning.

Two options:

1) Keep 1.1.3 but as a warning, to be able to describe the situation to the user in different wording. 2) Remove 1.1.3 and produce warning 1.1.21.

[andylolz]

1, 3 and 4 sound great.

2 is almost entirely subsumed by 3, so I think it should be removed. The only bit that isn’t subsumed is the case described in the comment above, when 2 returns a false positive.

4. Else, if the activity identifier does not start with a known organisation id in the Registry

To use it for this purpose, I think known-publishers.xml needs to also include historical organisation ids. It currently doesn’t (e.g. GB-1 is missing).

---

Is it preferable for me to wait for some public consultation on these new rules? What’s the best way to provide feedback? I can see that these rules are still in flux, so maybe it’s better for me to wait?

[amy-silcock]

None of these rules are new - rather we're working out the best way to write tests for them. There's public testing but no consultation or sign off.

I agree with @andylolz that there should be no pure test to see if the IATI Identifier is the same as the reporting org (as per Andy's example above and the rules in the Standard): This MUST be prefixed with EITHER the current IATI organisation identifier for the reporting organisation (reporting-org/@ref) OR a previous identifier reported in other-identifier

This would mean removing 1.1.3.

If we were to check against the Registry IATI Org IDs, surely this should be done in the reporting-org element and not the iati-identifier?

How about:

1)
If the activity identifier does not start with an organisation identifier in reporting-org or in other-identifier[B1], we return 1.1.1: The activity identifier must begin with the organisation identifier of the reporting organisation (or a previous version included in the other-identifier element).

2)
Else, if the activity identifier is the same as the other-identifier[B1], and is not prefixed by the reporting-org, we return 1.1.1: The activity identifier must begin with the organisation identifier of the reporting organisation (or a previous version included in the other-identifier element).

3)
Else, if the activity identifier is the same as the reporting org, and is not prefixed by the other-identifier[B1], we return 1.1.1: The activity identifier must begin with the organisation identifier of the reporting organisation (or a previous version included in the other-identifier element).

4)
Else, if the activity identifier is not an organisation identifier followed by a dash and some extra info, we return 1.1.21: The activity identifier's prefix and suffix should be separated by a hyphen e.g. XM-DAC-2222-12

[andylolz]

There's public testing but no consultation or sign off.

Okay great - are there dates for this? I'll wait until then to provide comments.