Adoption of local and national taxonomies - particularly in England

One English council has raised concern that there is little correlation between the taxonomies used by its filters and the English Local Government taxonomies maintained by the Local Government Association (LGA). (The LGA maintains taxonomies of Service Types, Circumstances and Needs). A similar point was raised at a recent meeting of councils who aim to adopt the ORUK compliant “Outpost” product, so here’s my answer:

The ORUK standard, built on the Human Services data Specification, is taxonomy neutral so you can use any taxonomies that suit your purposes. Ideally taxonomies should be public like the LGA’s which follow open data standards, but that is not essential.

You can use multiple different taxonomies for different purposes.

It’s probably best to start tagging services according to your local taxonomy agreed internally and with partners sharing the data (ideally following user research).

Where data is combined across multiple data feeds, align taxonomies with those used by the other feeds. This could mean adding extra terms that are not used internally.

The English Department for Education (DfE) aims to combine feeds describing family services so I expect them to formalise their taxonomy which should be used for relevant services that will be surfaced through their GOV.UK presence. I hope the DfE taxonomy will align with the LGA’s service types taxonomy but we will have to assess how feasible that is.

There is scope to influence the content of both the LGA’s taxonomies and the forthcoming DfE taxonomy.

Ah yes, the Taxonomy Dilemma rears its head in the UK!

This is a common, critical, unsolved challenge, and I want to believe we can build tools to better cope with it. But so far, any tool builders we’ve come across who tried to tackle it tried to do so entirely with machines – hoping that NLP and LLMs could algorithm their way out of the problem – and none of that has worked. I think algorithms could be a helpful accelerator as a secondary tactic, but ultimately we need interfaces for humans to manage associations. So far I see even experts either doing this stuff in spreadsheets, or getting lost in complex ontology tooling. There must be some kind of middle path that’s more sophisticated than simple spreadsheet, but less cumbersome than full-blown ontology management.

Taxonomy is one of the 5 most important elements of a Place-based Directory of Service (PBDoS). It underpins the data collection and assurance and provides for the management information.

However, there is little point in sorting out just the taxonomy as the benefits of a place-based approach still won’t be realised.

PBDoS Top 5

  • Collection from multiple sources (aggregation)
  • Data accuracy
  • Data richness
  • Presentation of data to multiple applications
  • Management Information (Taxonomy)

We are currently working across the Lancashire and South Cumbria ICB.

We think the taxonomies built into HSDS 3.0 are sensible and useful.

We also think the original thinking from the LGA and iStandUK on taxonomies remains useful.

I understand why it was decided not to include those in HSDS 3.0 to provide choice for the different users of the standard.

I embrace the introduction of the application profile and hope that the UK eventually agrees to all use the same one.

We recognise that the LGA taxonomy terms needed some refinement but we achieved that relatively easily and would recommend that people do similar as there are many benefits to be able to work across geographical and admin boundaries.

We decided that the best way to implement taxonomies was to give local control and so we do as has been said and map local terms to the national ones.

We also provide each team with their choice of wording and the ability to create a subset of taxonomy terms which are relevant to their particular context. This makes it far easier for people to tag and to find services.

We recognise that there needs to be a manual assurance team to ensure the correct taxonomies are applied to services even if they are supported by AI suggestions. This team is effectively a subset of the current effort that ‘places’ are putting into checking/assuring data in many different teams/applications/spreadsheets across the place but is more efficient and effective.

We encourage a plethora of front end applications to consume the data and they can use whatever wording they want in their UI so that their particular context audience understands.

We are developing a Place-based Directory of Service which provides for the 5 important elements. This is currently in use in Lancashire and a trial in Dorset and conversations in Bolton but it is our intention to launch this in the Autumn. We have included the ability to transform source data into HSDS 3.0 from spreadsheets, endpoints, a user interface as well as accepting uploads of flier to the assurance team and reports of errors/omissions from frontline workers.

We have also found that most of the potential applications at the front end struggle to use the API and so have created a links generator which makes it easy to add to a website or simply message direct to a client or colleague.

1 Like

Thanks Ian, using a subset of terms from a formal shared taxonomy is a great approach if that taxonomy includes everything a dataset of services needs

I’d love to know more - perhaps in a separate thread when you are able to share.