ThreeSixtyGiving / standard

The 360Giving data standard for UK philanthropic giving
http://www.threesixtygiving.org
Other
10 stars 15 forks source link

OrganisationType field: remove partial codelist #255

Closed morchickit closed 5 years ago

morchickit commented 6 years ago

I got a feedback from the Challenge Fund that publishers dont use the Recipient Org:Organisation Type field and tried to understany why the Big Lottery created the field BIGField_Organisation_Type.

I asked Katherine about it, and she said it is a codelist. Digging into the documentation, you can see that the spreadsheet format doumentations says:

Recipient Org:Organisation Type | A description of this organisation | string | False

The JSON documentation however says the following: organisationType | enum | string,null | Registered Charity Registered Company Community Group List to be updated

What does this means for version 1? Should we keep it as string, change to classification or expand this codelist?

stevieflow commented 6 years ago

Yes, understood

Agreed - it is a codelist - and very partial

I quickly added this to the example data, and got an invalid response with a value Registered Bod:

ExampleTrust-grants-fixed (2).xlsx

https://dataquality.threesixtygiving.org/data/d5b1e129-38f6-44a6-ad27-559f42e686c4

(NB - this was via uploading a spreadsheet, so think this is consistent between roll-up and JSON)

@timgdavies can recall the original design decision on this?

I guess the options are

@KDuerden - I dont think anyone has used this field?

timgdavies commented 6 years ago

I believe there was early on a desire for this information in cases where no organisation identifiers were supplied. But where we have good use of organisation identifiers, then some of this can be inferred.

I don't have a strong opinion on whether to extend or remove the codelist. However, the field description probably needs to be updated, as this is not just a 'description of the organisation', but should be 'a description of the type of the organisation'.

stevieflow commented 6 years ago

Thanks @timgdavies

@morchickit @KDuerden - what do you think?

morchickit commented 6 years ago

I think if we can make it a free text filed that would be the best option, since we see that other organisations do want this field and use alternative one (like the Big Lottery).

On Mon, Aug 13, 2018 at 7:55 PM Steven Flower notifications@github.com wrote:

Thanks @timgdavies https://github.com/timgdavies

@morchickit https://github.com/morchickit @KDuerden https://github.com/KDuerden - what do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ThreeSixtyGiving/standard/issues/255#issuecomment-412625907, or mute the thread https://github.com/notifications/unsubscribe-auth/ADHzu5NwgIhPKqeuDwiAXFfuy-yPwysmks5uQcuWgaJpZM4V1jIg .

KDuerden commented 6 years ago

+1 for free text.

@stevieflow no one has used this field (or the Funding Org Type equivalent) because the couple of times it came up it rendered the data invalid because the values they wanted to use weren't on the list. In at least one case we just moved the text to the org description field because it is free-text. In the other that I remember we just used their own title. So this field has been basically useless!

stevieflow commented 6 years ago

OK thanks. @morchickit I've create a new project for proposals for v1.1 - and added this to it

morchickit commented 6 years ago

We should then put it forward this issue forum as well for acknowledgement. I'll do it today.

On Tue, 14 Aug 2018, 08:17 Steven Flower, notifications@github.com wrote:

OK thanks. @morchickit https://github.com/morchickit I've create a new project for proposals for v1.1 - and added this to it

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ThreeSixtyGiving/standard/issues/255#issuecomment-412777818, or mute the thread https://github.com/notifications/unsubscribe-auth/ADHzu5iCXV7Jl7U6J9l9mxf14h3SYabKks5uQnl9gaJpZM4V1jIg .

drkane commented 6 years ago

I've put down some thoughts in the forum - free text makes sense to me.

https://forum.threesixtygiving.org/t/recipient-organisation-type-field/255/2

morchickit commented 6 years ago

@stevieflow - we have not this discussed it in the committee this week, but I suggest we should move on it and make it free text in the JSON Schema.

KDuerden commented 6 years ago

@morchickit yes please - conversation last week with publisher I had to suggest an alternative field for data they have about type of org - because this is a codelist.

stevieflow commented 5 years ago

Have created a branch for this https://github.com/ThreeSixtyGiving/standard/tree/255-OrganisationTypeList

KDuerden commented 5 years ago

What's the eta on this branch being pushed to live? There is a publisher we want to move onto using this field rather than their own field title.

robredpath commented 5 years ago

@KDuerden this has now been merged to live

morchickit commented 5 years ago

Can we close this?

robredpath commented 5 years ago

@morchickit yup!

KDuerden commented 5 years ago

@robredpath I understood this change was live but CoVE is giving error messages for data using the field, sans codelist: https://dataquality.threesixtygiving.org/data/8399663a-a215-43df-a2bd-981e96754b92 This file hasn't been failing the daily data test, and has loaded into GN ok.

stevieflow commented 5 years ago

This error https://dataquality.threesixtygiving.org/data/8399663a-a215-43df-a2bd-981e96754b92 looks like a codelist is still being checked for / exists....

robredpath commented 5 years ago

I've got a PR open for this now - we accidentally pulled in a link to an old version of the schema when doing the metadata work

robredpath commented 5 years ago

https://github.com/OpenDataServices/cove/pull/1236

KDuerden commented 5 years ago

thanks @robredpath - thought it might be something like that!

robredpath commented 5 years ago

@stevieflow @KDuerden fixed now - you'll need to resubmit the data as validation results are cached, but that data now passes