Skip to content

Commit

Permalink
Amend Profiles documentation responding to DS comments
Browse files Browse the repository at this point in the history
  • Loading branch information
Matt Marshall committed Aug 21, 2023
1 parent d17cd35 commit 126c864
Showing 1 changed file with 12 additions and 6 deletions.
18 changes: 12 additions & 6 deletions docs/hsds/variations_interoperability.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,21 @@ To this end, HSDS makes several provisions to ensure that the standard can be ef

The HSDS Profiles mechanism provides a method of building upon and tailoring the core HSDS Schema in order to adapt it for specific contexts which may require different or additional validation rules.

Profiles may declare new optional or mandatory fields, make existing optional fields mandatory, introduce new validation rules or new structures, or declare new API endpoints in addition to those on the [HSDS API Reference](api_reference).
Profiles may do the following:

Conversely, Profiles may also remove or override some parts of the HSDS Schema which are not relevant to them. (This will not prevent a publisher from publishing such excluded data, but it may not be validated by tooling used by that Profile, as it is technically additional data from the Profile's perspective.)

Profiles may also recommend the use of particular value sets (taxonomies, enumerations, etc) to ensure semantic interoperability among datasets that use the Profile.
* declare new optional or mandatory fields.
* make existing optional fields mandatory.
* introduce new validation rules.
* introduce new structures.
* declare new API endpoints in addition to those documented on the [HSDS API Reference](api_reference).
* remove or override some parts of the HSDS Schema which are not relevant to them. (Note: This will not prevent a publisher from publishing such excluded data, but it may not be validated by tooling used by that Profile, as it is technically additional data from the Profile's perspective.)
* recommend the use of particular value sets (taxonomies, enumerations, etc) to ensure semantic interoperability among datasets that use the Profile.

Profiles are generally developed and maintained by third parties to satisfy particular requirements for their context. These could arise from a community need, legal structures, taxonomy requirements, or other affordances of service provision specific to that context. In general, Profiles should provide robust documentation allowing a publisher or data user to understand its rules and structures both independantly and in comparison to the core HSDS schema.

NB: while Profiles may be used to extend the functionality of HSDS, they should not be used to create modular or re-usable "Extensions". The Profiles mechanism differs from that of an Extensions mechanism in other standards; as such, a given dataset may only implement a *single* Profile.
```{admonition} Profiles are not Extensions
While Profiles may be used to extend the functionality of HSDS, they should not be used to create modular or re-usable "Extensions". The Profiles mechanism differs from that of an Extensions mechanism in other standards; as such, a given dataset may only implement a single Profile.
```

### Publish data using an existing HSDS Profile

Expand All @@ -39,7 +45,7 @@ If the core HSDS standard or an existing Profile does not adequately meet the ne

Creating a new HSDS Profile is an involved but straightforward process:

1. **Engage and Discuss** with the community about which problems you're trying to solve and how best to address them. This may include people in the [wider Open Referral community](https://forum.openreferral.org/) and other implementors in your context who may want to contribute directly to your profile. Speaking to people who have implemented other HSDS Profiles may help you with thinking through some aspects of Profiles.
1. **Engage and Discuss** with the community about which problems you're trying to solve and how best to address them. This may include people in the [wider Open Referral community](https://forum.openreferral.org/) and other implementors in your context who may want to contribute directly to your profile. Speaking to people who have implemented other HSDS Profiles may help you with thinking through common challenges when developing a new Profile.
2. **Develop and Document** the Profile. All new Profiles should use the [Example Profile repository](https://github.com/openreferral/hsds_example_profile) as a starting point because it contains all of the tools required to generate your final Profile schemas as well as a basic documentation site. The Example Profile contains technical guidance and examples on creating a profile inside its README file. You may want to expand upon the basic documentation generated by the tools in the repository.
3. **Share and Support** your new Profile! Make an announcement on the [HSDS forums](https://forum.openreferral.org/) and start producing data conforming to your Profile. If others are using your Profile, you may want to collaborate with them to plan changes to the Profile or answer questions by expanding your documentation.

Expand Down

0 comments on commit 126c864

Please sign in to comment.