Enumerations in the specification

[MikeThacker1]

The Open referral tabular data package includes five enumerations as field constraints. We have found that two of them are inadequate for implementation of the standard in England:

• eligibility.eligibility
• accessibility_for_disabilities.accessibility

In both cases we would like to reference an external vocabulary/taxonomy rather than be limited to a single text field with or without enumeration constraints.

I understand that the enumerations were intended as examples, but they are defined as formal constraints.

[greggish]

As I understand it, the issue is that the tabular datapackage (which is our 'single source of truth' for the HSDS schema) has a couple of instances in which code lists (in this case, for eligibility criteria, and for types of accessibility) are specified. I believe they were just specified as examples, but that's not clear.

I may have to dig into this a bit to get the context, but AFAIK we did not intend to specify those values as standardized vocabularies. Assuming my memory is correct, then we either should either remove these code lists or more clearly indicate that they are examples and not intended to be formal constraints.

(That said, @MikeThacker1 while I agree that we should do better than a single text field, I am skeptical of the prospect of referencing of a single authoritative taxonomy on any of these. Would be glad to learn more, but i suspect we need a solution that can work with/among any number of specialized taxonomies.)

[MikeThacker1]

Thanks. I do think more clarity would help, but we'll amend our work to still consider as valid values not in the OpenReferral example enumerations.

Yes @greggish I agree there won't be a single authoritative taxonomy on accessibility (or anything else). In common with service taxonomy terms, I'm proposing that service accessibility should be definable from any specified taxonomy (aka vocabulary) and term within that vocabulary.

[robredpath]

Tagging with both MAJOR and MINOR:

• Just removing the constraint would be a MINOR update (at least for publishers; there's a risk that data consumers might rely on the enum containing the only possible values)
• Adding links to another (new) table would be a MAJOR upgrade.

[NeilMcKLogic]

Hello all, in conversations with potential data partners in the last few years, one of them pointed out to me that there are 3,500+ unique variations for eligibility requirements. That suggests we should not have an enum constraining the values that are possible in that field.

Relatedly, I don't have data on accessibility but I would think it would similarly be poorly suited to an enum due to the probability there are an equally high number of possible variations/answers.