search

IATI / IATI-Schemas

Schema development for the International Aid Transparency Initiative.
Other
15 stars 9 forks source link

Add new @crs-channel-code attribute for the participating-org element #338

Closed dalepotter closed 6 years ago

dalepotter commented 7 years ago

Add a new attribute at iati-activities/iati-activity/participating-org/@crs-channel-code, type xsd:string with the following definition:

Under CRS++ Reporting Directives this code identifies the implementing agency. Codes ending in ‘00’ are generic and are similar to the OrganisationType code.

The attribute will have type xsd:string with occurrence rule 0..1.

Tasks:

hayfield commented 6 years ago

The CRS Channel Code is an element elsewhere in the Standard https://github.com/IATI/pyIATI/pull/229 - adding it like this would lead to multiple ways that literally the same sort of information is presented!

The original discussion fails to notice this.

andylolz commented 6 years ago

The CRS Channel Code is an element elsewhere in the Standard IATI/pyIATI#229 - adding it like this would lead to multiple ways that literally the same sort of information is presented!

There’s another element that uses the codelist, but I think it’s unrelated. What makes you think it’s related?

hayfield commented 6 years ago

There’s another element that uses the codelist, but I think it’s unrelated. What makes you think it’s related?

Related in the sense that they are both ways to present the same information (a value from a Codelist). The context is unimportant for this aspect of the technical implementation.

hayfield commented 6 years ago

This change leads to multiple ways to define the same sort of information (a value ideally from the Codelist). This is bad. As such, the following changes should additionally be made at the same time:

As noted elsewhere, it is possible this change could additionally be backported as a bug-fix to 2.02. At a minimum the changes should be made for 2.03.

This proposal for modification falls within the The Community inspects and comments on the 2.03 changes on GitHub as they are being developed. step of the Upgrade Timetable.

andylolz commented 6 years ago

You’re saying it’s a problem that in one instance CRSChannelCode is used in an attribute, and in another instance it’s used in a text node?

This is bad.

Can you elaborate? I know you have an issue with the inconsistency of putting codelist items in text nodes (as discussed here: IATI/pyIATI#229)… But here you seem to suggest it’s especially bad to use both a text node and an attribute for the same codelist. Can you explain why this is particularly abhorrent?

hayfield commented 6 years ago

You’re saying it’s a problem that in one instance CRSChannelCode is used in an attribute, and in another instance it’s used in a text node?

Correct.

But here you seem to suggest it’s especially bad to use both a text node and an attribute for the same codelist. Can you explain why this is particularly abhorrent?

It's not necessarily a huge amount worse in combination. It mostly highlights the sillyness of iati-activity/crs-add/channel-code.

In the general sense, you could kinda stretch an argument to say that a particular Codelist requires newlines in its codes (see: related explanation).

In the specific case, it may have previously been argued that CRSChannelCode definitely needed the ability to have newlines in codes (the one reason you might require an element over an attribute). With this proposal, however, it becomes clear that this cannot be the case since it forces the Codelist to be limited to values that are permitted within an attribute.

Sooooo, this proposal eliminates any argument for why iati-activity/crs-add/channel-code is at element rather than attribute level. Which, well, yeah.

allthatilk commented 6 years ago

@IATI/bas Can we get an update on what's happening with this one? We need actionable suggestions to move forward.

andylolz commented 6 years ago

I think @hayfield’s comment is about iati-activity/crs-add/channel-code, and not about this proposal. I don’t think anyone has a problem with this proposal as it stands. I.e.:

It's not necessarily a huge amount worse in combination.

I don’t see why this proposal can’t be progressed. What do you think, @hayfield?

hayfield commented 6 years ago

The two issues are related.

This is currently with @IATI/bas to make some sort of decision.

amy-silcock commented 6 years ago

Currently waiting to hear back on this one @stevieflow (you should have received an e-mail about this last week).

One organisation are using the current channel code element at v2.02. We're trying to get in contact to see why and whether or not this can be changed.

If they are happy to change their reporting then we can go ahead and make sure the standard is consistent.

andylolz commented 6 years ago

One organisation are using the current channel code element at v2.02.

The dashboard seems to suggest there are more, now [1]. (I think slovakaid publish this too, but a bug with their data means the dashboard isn’t including them [2].)

We're trying to get in contact to see why and whether or not this can be changed.

I don’t understand… What are you asking these publishers to change? It sounds like you’re talking about the text() vs @code issue… Is that right?

[1] http://dashboard.iatistandard.org/element/iati-activity_crs-add_channel-code.html [2] https://iatiregistry.org/dataset/slovakaid-69_1_ac

stevieflow commented 6 years ago

So - tell me this again.

With this proposal, I'll be able to describe one organisation with two references:

eg - for UNDP:

<participating-org ref="XM-DAC-41114" crs-channel-code="41114" role="1" type="40" />

Or - to quote @hayfield

This change leads to multiple ways to define the same sort of information (a value ideally from the Codelist). This is bad.

Are we sure about this?

I actually understood the original intention was to something about publishers being able to use the ''Channel Parent Category'' from OECD-DAC Channel codes - eg column A from cell 8 on "Channel codes" sheet from the latest OECD DAC code list:

40000 MULTILATERAL ORGANISATIONS 41000 United Nations agency, fund or commission (UN)

(btw - as an aside, why would anyone use 40000 value in their data ?)

BUT this then implies creation of a new non-embedded codelist, which then needs close maintenance and inspection routines we've had to cobble together (thanks to master cobbler @andylolz)

Can someone please remind me why this is useful? @bill-anderson ?

I thought we wanted to get away from generic codes (DFID did this recently - @jjohnadamsDFID ?).

And - didn't we move away from just declaring (for UNDP example) 41114 when we know it has to be XM-DAC-41114 to help data users?

What exactly does adding crs-channel-code to the participating-org element help do?

stevieflow commented 6 years ago

We're trying to get in contact to see why and whether or not this can be changed.

I don’t understand… What are you asking these publishers to change? It sounds like you’re talking about the text() vs @code issue… Is that right?

I don't quite understand either. FCO use the channel-code sub element in the crs-add - eg - in this file:

<crs-add>
<channel-code>52000</channel-code>
</crs-add>

That's permissible in the standard. What needs to change?

stevieflow commented 6 years ago

That's permissible in the standard. What needs to change?

Update: that's permissible in the available/live versions 2.0x of the standard. @hayfield am I right in understanding you want to change this - rendering a breaking change?

hayfield commented 6 years ago

Update: that's permissible in the available/live versions 2.0x of the standard. @hayfield am I right in understanding you want to change this - rendering a breaking change?

My proposal would be to:

This then ideally leaves nobody using the poorly designed deprecated thing, with everything consistent and nice for data users and anybody who may use the attribute in the future.

(NOTE: I don't know what the email you received said)

@stevieflow

stevieflow commented 6 years ago

Wait

The final 2.03 proposal doc says:

Publishers will now be able use CRS channel delivery codes to describe the types of organisations they are working with.

Keyword here (my emphasis): "types" of orgs.

As in:

40000 MULTILATERAL ORGANISATIONS 41000 United Nations agency, fund or commission (UN)

But I assume not

41304 UNESCO United Nations Educational, Scientific and Cultural Organisation UNESCO 41146 UNWOMEN United Nations Entity for Gender Equality and the Empowerment of Women ONU Femmes

The actual channel codes list from OECD tries to list the generic type along with several specific agencies.

By progressing down this route, we seem to be caught into two other proposals for 2.03

1 - modify the organisationType codelist to have more values (where's the GitHub issue for this?). Wouldn't this incorporate the generic / types from the channel codes already?

2 - Migrate the organisationRegistrationAgency list to org-id (where's the githib issue for this?). Wouldn't that guide people to output specific agencies on the channel code list with the XM-DAC prefix?

So - to repeat: what value do we get from this?
And I add: who is to benefit?

@timgdavies may have something to add

andylolz commented 6 years ago

Notify the one user of the shouldn't-ever-have-been-added-at-2.02 thing (FCO)

Mm.. I'm not really sure about this, for a couple of reasons:

  1. They’re not the one user; they’re the one publisher. There may be other users (of their data)
  2. They’re not the one publisher, either; there are others (according to the IATI dashboard). See my comment above.
hayfield commented 6 years ago

modify the organisationType codelist to have more values (where's the GitHub issue for this?)

https://github.com/IATI/IATI-Codelists-NonEmbedded/issues/182

Migrate the organisationRegistrationAgency list to org-id (where's the githib issue for this?)

https://github.com/IATI/IATI-Schemas/issues/339

@IATI/bas: Could you take a look at the questions?

bill-anderson commented 6 years ago

A summary of a Tech Team discussion today that relates to crs-add/channel-code ...

andylolz commented 6 years ago

That all sounds fine to me.

But I don’t think anything here addresses @stevieflow’s point above: https://github.com/IATI/IATI-Schemas/issues/338#issuecomment-347618462

bill-anderson commented 6 years ago

@stevieflow's point ...

By progressing down this route, we seem to be caught into two other proposals for 2.03 1 - modify the organisationType codelist to have more values (where's the GitHub issue for this?). Wouldn't this incorporate the generic / types from the channel codes already? 2 - Migrate the organisationRegistrationAgency list to org-id (where's the githib issue for this?). Wouldn't that guide people to output specific agencies on the channel code list with the XM-DAC prefix? So - to repeat: what value do we get from this? And I add: who is to benefit?

DAC reporters benefit. We cannot easily (i.e. disruptive change in major upgrade) reconcile the differences between the IATI OrganisationType codes and generic CRS delivery channel codes. We recognise this is a duplication but given that we need to remain compatible with the CRS and we want implementing agencies properly described as participating orgs we see no better option. NB that channel codes were not included in the original IATI standard for the very reason that the list tries to fulfill two very different functions: org types and identifiers.