datapackage.json - eligibility - eligibility or description column has gone?

[odscjames]

http://docs.openreferral.org/en/1.1.1/hsds/reference/#eligibility has a "eligibility" column. (v1.1.1)

http://docs.openreferral.org/en/latest/hsds/reference/#eligibility does not. (all v2's and latest)

[odscjames]

https://github.com/openreferral/specification/commit/b02e50d05dff13103388c0e3b0eda1be669accd7#diff-85b9548466eda4168e93923c9559cce6492b416971e27ed0f0b07e102bb11419 This commit removes it

[robredpath]

@greggish @odscjames eligibility is now handled by the other_attribute mechanism, with link_type = eligibility.

I can see how that's not clear from the docs, so that's something we should improve in the future.

[odscjames]

Ah I see, so we are moving from Eligibility being a free text field to Eligibility being described as a term from the Taxonomy?

So if a service had Eligibility requirements you wanted to describe, you'd:

• create a row in Eligibility with
  • a new id
  • the service_id of the service you wanted to document
• create a row in other_attribute with
  • a new id
  • link_id being the id of the row you just created above
  • link_type = eligibility
  • taxonomy_term_id being the taxonomy id you want to attach

?

[greggish]

I do wonder if this poses an accessibility challenge for data providers whose records only have unstructured eligibility information – which is most of them. What if the most practical thing is to still use a free text field?

[odscjames]

(BTW fixing https://github.com/openreferral/specification/issues/270 may help make this clearer)

[MikeThacker1]

I think I was expecting the free text (lesser) alternative to taxonomy terms to still exist for legacy daat and people who haven't (yet) implemented taxonomies.

Mike

*Mike Thacker Porism Tel / Signal / WhatsApp: +44 7976 295 784 Bon Marché Centre, 241–251 Ferndale Road, London, SW9 8BJ, England @. | porism.com http://twitter.com/MikeThacker http://plus.google.com/+MikeThacker

On Fri, 29 Oct 2021 at 14:21, Greg Bloom @.***> wrote:

I do wonder if this poses an accessibility challenge for data providers whose records only have unstructured eligibility information – which is most of them. What if the most practical thing is to still use a free text field?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/267#issuecomment-954739538, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSVFHIDJ2U3DTMFVKDHB6DUJKNUDANCNFSM5G2UEXJQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Porism supports the Open Referral UK https://openreferraluk.org/ standard for the UK public sector

[robredpath]

@MikeThacker1 @greggish HSDS 2.0 supports use of informal tagging or free text, because it doesn't specify what a taxonomy_term should be - you can just have a row in taxonomy_term for each tag or instance of free text, and link to that with a row in other_attribute, as @odscjames describes.

[robredpath]

(I clearly need to update http://docs.openreferral.org/en/latest/hsds/classifications/ with an example!)

[MikeThacker1]

Actually the text on Applying a taxonomy term to an object helps a lot. (Although it raises more questions on taxonomies for me.)

[Cskyleryoung]

I agree with @MikeThacker1, this makes sense, but also raises some questions about the nature of taxonomies. Coming from the 211 space, I naturally want to reserve taxonomy_term for taxonomies with official specifications, like AIRS or even Open Eligibility. However, I'm going to also end up putting every defined list of enums from my client's data management system, plus a few pools of thousands of random text strings, in there because I have nowhere else to put them.

[mrshll1001]

I think this can be closed, as HSDS 3.0 is out now. datapackage.json has a field called "eligibility_description". The attribute schema does not though, and other_attribute seems to have been removed.