EDITOR’S NOTE: Welcome Kathryn Irish, Senior Data Analyst of Open Data Services, to the Open Referral blog!
Also note: Open Referral’s new standing technical committee wants to hear from members of our community about your priorities and feedback for future versions of HSDS, and for other features of our emerging ecosystem. Please take a few minutes to complete this survey– your input can help us shape our roadmap for the year ahead!
Ok on with the announcement, take it away Kathryn:
We’re pleased to announce a minor upgrade of HSDS.
HSDS version 3.1 updates our schema in the following ways:
- to improve the modelling of URLs, allowing multiple URLs to be attached to organizations and services (so that social media sites, program pages, and other web locations can be structured in a standardized way).
- to allow modelling of service capacity, in addition to the modelling of service status – enabling services to convey a maximum capacity of `units` and given quantity of `units` that are currently available (such as beds, hours, or other types of capacities as needed).
- to support further serialization of information about services and locations, such as `location_type`, and `service_area` that vary across different locations.
Furthermore, we have updated HSDS’s API specifications to enable querying for some endpoints via HTTP POST, especially pertaining to taxonomy terms, so that such queries can benefit from HTTPS encryption. In this way, search parameters can remain unspecified in the URI of the API response – and thus not subject to monitoring of network traffic. This can address privacy concerns around sensitive searches (such as reproductive healthcare providers, support for survivors of domestic violence, etc).
Finally, we have also updated the API specs to enable querying via taxonomy for all suitable endpoints.
Here is the changelog that specifies each individual change.
As a minor upgrade, version 3.1 includes no changes that would render any compliant data to be incompatible with systems that use HSDS 3.0. Even with the addition of the new features described above, data in the 3.1 format will remain interoperable with any system that expects data in the 3.0 format – and vice versa.
Many thanks to the new Standing Technical Committee for their support and guidance through this process. (Read this post for more information about this new Committee.) To learn more about our newly established method for developing and approving proposals for new features, review this documentation.
We also are grateful to the wider community for their continued engagement via github issues, our forum and monthly technical meetups – all of which helped us understand their needs and work towards an upgrade that would address them. (And we are especially thankful to our team member Matt Marshall, for his extraordinary work in getting all of this done before his paternity leave.)
Last thing: the Standing Technical Committee has already begun considering prospects for the next upgrade. We want to receive input from our broader community on your questions and priorities – so we have developed this survey to gather your feedback. Please take a few moments to share with us your suggestions to help improve this process and advance the development of future versions of our specifications!
Leave a Reply