With work progressing on version 3 that uses the concept of “profiles” to distinguish full, core, UK and potentially other representations of the standard, it’s essential that we remain clear on what service directories in the UK need to do to profess compliance with the standard.
The Government Data Standards Authority has endorsed Open Referral UK as an interchange standard and its prime purpose is to allow easy movement of open services data between different front and back-end systems without vendor tie-in or the need for bespoke connectors.
We see as “compliant” ( to varying degrees) those API feeds featured on Our dashboard which does pass/fail checks against Open Referral UK API Validation Rules.
Version 3 will make small changes to the web method responses for the UK profile and will define what web methods are considered core (see proposals in section 3 of Por11328 - Aligning Open Referral and Open Referral UK - The API - HSDA) and extended.
The Working Group (in which some suppliers have chosen to participate) will soon firm up what the version 3 API looks like so that Open Data Services Co-op (inc @robredpath and @davidraznick) can formalise definitions.
At all costs we need to avoid directories professing compliance without having open APIs that meet these standards.
I can arrange for validation of existing APIs so, where compliant, they can be added to the Dashboard.
@MikeThacker thanks for laying out what the Open Refferral UK complience rules are.
It has got me thinking that, when coming up with profiling mechanism, we look beyond just what the fields and enumerations are. We might also want to have a way to express:
- What taxonomies need to be used.
- What output representations and API endpoints are needed.
It would be great as part of defining a profile there was a specified way to express these further restrictions. So for open Referrall UK you could restrict the allowed minimum output represenations to just both /services with services/{id} endpoints.
The only slight issue I have with “section 3 of Por11328 - Aligning Open Referral and Open Referral UK - The API - HSDA” is defining /taxonomy_term, /taxonomy_term/{id}, taxonomies, taxonomies/{id} as core. This is because I think in Open Referral as a whole would have to agree that these are core but that is potentially too much of a restriction on everyone. My preference would be to have these as recommended. However, this is very much up for discussion.
Yes @davidraznick we should go on to look at things like taxonomies to be used. At first I just wanted to lay out the basics.
Regarding making /taxonomies part of the core, we found it useful for driving queries by taxonomy term as shown by the API Query tool.
Of course we should discuss with the group (and here). “recommended” may be best. And I’m not suggesting that all (sometimes non-open) taxonomy terms should be available, just those used to tag data.
