Service categories vs 'target populations' vs eligibility – how to distinguish and apply

Data Management
1

So I’m seeing this issue floating around and I want to create a space to discuss it (in part inspired by this thread on the AIRS networker, which won’t be accessible to non-members).

In Open Referral’s data model, we can now have attributes to describe various entities. the big one is service of course: a service taxonomy classifies the various types of services. But in addition to service types, there are also types of people. In the 211LA taxonomy, there’s a separate branch for target population and I think people manage these concepts in different ways.

This article seems to be cited as a still relevant bit of guidance for the I&R call center sector. It outlines different methods – linking a service term to a target population term creates a compound term, whereas floating terms are just multiple terms assigned to a single record. The article lays out some examples of advantages and disadvantages of each.

The article also acknowledges that some terms for service type can explicitly name the type of person served (i.e. Domestic violence support groups) – in which case the function of a target term would seem to already have been met. But if search results are being performed explicitly on target terms, to identify services associated with say Survivors of domestic violence, this kind of service might be missed by the filter if it’s not specially tagged by the target term.

The reason I wanted to start this here is that I noticed that target terms are often used to function as a kind of Eligibility category. I think this is what is implied (perhaps unintentionally) by the Open Eligibility taxonomy structure, which has the dual branches of types of services and types of situations which consist of tags that, if applied together, seem to suggest that a given type of person is eligible for a given type of service. But I don’t think that’s quite right; a service might be relevant to various types of people yet have eligibility rules that aren’t necessarily types of people at all (like income, housing status, enrollment in other programs, etc).

So I want to see how people think about these related, but distinct concepts – especially the difference between target population and eligibility rules. And I want to acknowledge that I think the right answer to some extent is “it depends,” primarily on what a particular set of users need and the best way to meet those needs given available resources. But recognizing that variable contingency, I still want to ask: how ought resource data be structured across these attributes in order to serve as infrastructure for many different use cases that might entail different decisions about search and delivery and etc.

1 Like
2

Sorry to come to this late, but I think the HSDS version 3.0 attribute table link_type field addresses this.

Terms from a taxonomy such as Open Eligibility Human Situation or the LGA’s Personal Circumstance list can be used with a link type (taken from an enumeration) indicating that it represents either eligibility or intended audience.

The UK’s Use of Taxonomies page has some useful information. It will ultimately need to be updated for version 3.0.

3

Just to be clear here: the attribute table is where all taxonomy_terms are linked to services, correct?

Also, I’ve been digging into the spec and see taxonomy_detail is a field (Schema Reference — Open Referral Data Specifications 3.0.1 documentation) but I can’t understand why. It wasn’t in our original specification (Por20349 - HSDS - US and UK - Google Sheets) and there are three fields related to taxonomy (taxonomy, taxonomy_details, taxonomy_id) so wondering if it’s an error or I’m just forgetting?

4

Yes this is correct. Here is an example attribute object.

{
    "id": "ae58cc39-8b70-4ab1-8aea-786882e5ac8e",
    "link_type": "link_type",
    "link_entity": "link_entity",
    "value": "value",
    "taxonomy_term": ▾{
        "id": "3f7b145d-84af-42d7-8fae-eaca714b02b2",
        "code": "code",
        "name": "name",
        "description": "description",
        "parent_id": "0bc248fa-dc27-4650-9ba4-8f1a24ef16a2",
        "taxonomy": "taxonomy",
        "taxonomy_detail": ▾{
            "id": "5c4d79d7-cc55-470e-9f1f-8cad074e4892",
            "name": "name",
            "description": "description",
            "uri": "http://example.com",
            "version": "version"
        },
        "language": "eng",
        "term_uri": "http://example.com"
    }
}

From the above example, you can see the taxonomy_detail contains the actual taxonomy object.

The taxonomy field is just a string which is kept for backwards compatibility reasons, whilst the taxonomy_detail contains the whole object from the taxonomy entity/table.

In all other cases where we converted the datapackage to jsonschema we just used the name of the table as the key name. In this case, it should have been called just taxonomy, HOWEVER, we already had a text field called taxonomy so had to make a different name, so we used taxonomy_detail. I thought this was discussed somewhere, but it was discovered after the creation of the linked mapping doc, which was why it was not in there.

Also, taxonomy_id is only there for use with the datapackage as the foreign key, and not needed for the JSON version. Conversely, taxonomy_detail being an object is not in the tabular version.

Possibly the other solution would have been to call the nested object “taxonomy” for consistancy and the string version something like “taxonomy_name”, however that would be a backwards incompatible change, and as the “taxonomy” entity/table is new in this version it seemed less harm to make up a new key name for the object.

Hope that makes sense!

1 Like
5

Yes it does. Thanks for explaining.