The following schemas declare new properties with the same name as their containing schema, and duplicate the semantics of an existing field:
- accessibility.json
- service_area.json
- taxonomy_term.json
Using accessibilty.json as an example, the patch for this schema declares a new accessibilty property; creating accessibilty.accessibilty. This property is a free-text string with the following description and example:
Description: "Description of assistance or infrastructure that facilitate access to clients with disabilities."
Example: "The building is equipped with induction loops for hearing aids. Wheelchair access is possible on all levels."
The upstream HSDS accessibilty.json schema has an existing property, accessibilty.description which is also a string containing the following description and example:
Description: "A free text description of the assistance or infrastructure that facilitates access to clients with disabilities."
Example: "The building is equipped with induction loops for hearing aids. Wheelchair access is possible on all levels."
In these cases, ORUK Profile patch may have been intending to rename upstream properties/fields or provide different descriptions more suited for the UK; however the patch omits removing the original fields. What we're left with is several schemas with two properties having similar or identical semantics, identical structure/validation rules, and with one of those properties being named directly for the containing schema. In the case of taxonomy_term.json, the new property is actually named term… however the issue is the same as across the other two schemas.
We should decide what our intentions are with these cases and whether the upstream HSDS fields are sufficient. If we believe they would benefit from some localisation or tweaks, we should implement the schema patch correctly to remove the upstream field and re-add a new one.
The following schemas declare new properties with the same name as their containing schema, and duplicate the semantics of an existing field:
Using
accessibilty.jsonas an example, the patch for this schema declares a newaccessibiltyproperty; creatingaccessibilty.accessibilty. This property is a free-text string with the following description and example:The upstream HSDS
accessibilty.jsonschema has an existing property,accessibilty.descriptionwhich is also a string containing the following description and example:In these cases, ORUK Profile patch may have been intending to rename upstream properties/fields or provide different descriptions more suited for the UK; however the patch omits removing the original fields. What we're left with is several schemas with two properties having similar or identical semantics, identical structure/validation rules, and with one of those properties being named directly for the containing schema. In the case of
taxonomy_term.json, the new property is actually namedterm… however the issue is the same as across the other two schemas.We should decide what our intentions are with these cases and whether the upstream HSDS fields are sufficient. If we believe they would benefit from some localisation or tweaks, we should implement the schema patch correctly to remove the upstream field and re-add a new one.