3.0 Schema review questions remaining

Here is a list of the schema review questions remaining from the schema spreadsheet.

Table - organization
Field - currently called uri

We need to decide name for this, as the comments say this should be named website but we already have field named website.
Shall we keep it as uri?

Table - organization
Fields - tax_status and tax_id

Are you sure we want to remove tax_status and tax_id? or shall we deprecate them?

Table - organization
Field - id (and oranization_id in other tables)

Currently this is set as an uuid in 2.0 shall we remove the uuid requirement to make it the same as all the other id fields?

Table - service
Fields - wait_time and fees

Are you sure we want to remove wait_time and fees? or shall we deprecate them?

Table - location
Field - location_type

I think this should be removed as we only need address.address_type?

Table - required_document

Shall we add a uri field to point to the doucment? What shall we call this field?

Great list! Thanks so much for this.

The following are simply my opinions. I hope others comment as well on this thread and we get these resolved.

organization.uri: yes I think it should be named uri
organization.tax_status and tax_id: yes I think deprecated
organization.id: yes I think it should be the same as the other fields
service.wait_time and fees: yes I think deprecated
location.location_type: I think location_type is there to signal whether the address is physical or virtual, and address_type is to define whether the address is a physical office people can visit or just a postal address – so I think we need both.
required_document: should have a uri that could be called “link” or “path”.


Thanks for the feedback. I will provisionally change the schemas to do what you suggest.

Also I forgot

Table - service
Field - licences

Shall we deprecate this and not remove?

provisionally I will just deprecate this field as well

1 Like

Devin’s points reflect my own assumptions and opinions as well. To emphasize a few key points:

  1. In general, I’m in favor of deprecation over deletion.
  2. I confirm that location_type exists primarily to delineate virtual locations.
  3. I think adding required_document.uri is a good idea. Heuristically, I’m in favor of simply calling it “uri” as that naming convention already exists. However, it’s not a major issue either way.
1 Like

Happy to hear this.

And yes I agree that we should default to deprecate and not remove and URI is fine with me for the document_required field name.

I think I’m following and agree with what has been suggested so far.

I think this is a great shout. We are currently using link_taxonomy tables to identify whether services have an address, are online , telephone services etc so have a location type would be a welcome addition @MikeThacker I think that we would be looking to ask for this from a DfE perspective

Thanks @rgparkins. I see that location.location_type is not in the current DRAFT UK profile - probably because it was proposed after the initial profile fields were drafted.

It would be good to run the UK profile by you (as well as others) before it is finalised. I was hoping that DfE requirements would be a subset of the UK profile rather than adding extra fields, but we need to see if that would work.

Thanks @MikeThacker let me know when is convenient, I can invite our other TA as well who has been more into the detail of our schema