specification
specification copied to clipboard
openreferral
Vocabularies/taxonomies for things other than services
Our work in England has identified the need to use taxonomy terms from external vocabularies for these entities as well as services:
- accessibility (see Issue 207)
- cost_option
- eligibility
- organization
- service_area
The current specification only permits the use of taxonomy terms for services - in service_taxonomy.taxonopmy_id.
Hence our analyst added an extra link_taxonomy table with a "link_type" of each of the above entities as shown in our ERD (currently missing the accessibility link).
This is a rather messy implementation just to keep strict compliance with the existing standard before extending it.
We would like to propose adding the field link_type to service_taxonomy populated with any of these values:
- service = the default if no value is specified
- accessibility
- cost_option
- eligibility
- organization
- service_area
This approach does make referential integrity checking more difficult in a traditional relational database, but the only alternative would be to add a separate table for each taxonomy relationship.
Sounds like an interesting proposal. Could you define the use case from a user perspective?
My intuition would be you are trying to find organisations or services at a location that have services with a specific taxonomy?
Could this not be achieved by calling the /services/ endpoint with a query on its taxonomies?
The idea there would be that organisations that have services with taxonomy X,Y,Z would therefore also be organisations with the same taxonomy by association
My best use case is a frontline worker wanting to find services of a particular type for with a particular eligibility criterion.
From our illustrative API, this query returns services with both:
- a service taxonomy term of "excercise" from the "Bucks:keyword" vocabulary
- an eligibility term of "hearing impairment" from the OpenEligibility vocabulary
I don't have live examples for the other types of taxonomy link, but they might facilitate for example:
- finding organizations with particular characteristics
- finding locations with particular accessibility, eg wheelchair access, hearing loop, ...
To recap here, it seems like we should consider adding an optional taxonomy_type to the taxonomy table, and enable the table to link to organizations – as well as, perhaps, fields like funding, accessibility, etc. Essentially a taxonomy of taxonomies.
Seems plausible to me. I'd like to hear from AIRS and people who work with the 2-1-1 taxonomy about it, as I think they also have the makings of multiple different types of taxonomies ('target population,' etc) baked in.
I'd like to add two things to this conversation.
1: We've encountered situations where services have two types of taxonomies. In this situation, one is a common language taxonomy and the other is a professional taxonomy (AIRS). We use the vocabulary field to distinguish between the two. By also adding a taxonomy_type field to the table, we could greatly increase the amount of flexibility in the taxonomy data model. Additionally, we've had clients request mapping between taxonomies. For example, they want numerous AIRS/professional taxonomy terms to appear to the user as a single common language term. This could be achieved by adding a field for mapping one taxonomy to another.
2: We've encountered many situations where clients want specific information attached to organizations, services and (to a lesser extent) locations. By having an auxiliary table connected to these three entities offering a simple custom data/key-value pair, we could meet a wide range of use cases while still following the specification.
Yes @greggish adding taxonomy_type to service_taxonomy would be the simplest approach (although the name service_taxonomy would then imply a smaller scope for taxonomies than is supported).
Regarding @devinbalkind's point on mappings between taxonomies, I think such mapping are best kept separately this diagram shows the mappings between our taxonomies. We do have potential cases where we want to do a lookup on services whose service types might come from more than one taxonomy (eg esd service types and OpenActive Activity list. So this is effectively a union between taxonomies, which again we are planning to handle outside the standard.
Of the 5 client projects I've worked on involving Open Referral, all involve client-created taxonomies to classify services. Only 2 of the 5 have used a standardized taxonomy and when they did that taxonomy was used as a secondary mechanism for classification.
@devinbalkind we have these use-cases for applying standardised taxonomies:
- aggregating data from several sources into one consistent directory of services
- maintaining extra information pertaining to taxonomy terms centrally rather than in each location (eg the service types most suitable for people of a particular type of circumstance) and using central taxonomist expertise in defining terms
- allowing software (eg a service finder using an API feed of services) to be configured such that it will work with different API endpoints from different directories
Of course, a lot of this has still to be put to the test :-)
Closing because as of 3.0, each object has an attributes array which can be used to include taxonomy_terms.
