Data Management and OS Data Hub

Who needs access?

There are a number of questions that need to be considered with access to the OS Data Hub:

What is the need?

• Create Data Packages?

• View and Download Data Packages?

What role?

• Administrator, allows you to create, edit and delete data packages.

• User, allows you to view and download existing data packages.

Do they need it all? Only give access to those who actually need it

Is there any risk? By giving someone permissions are you enabling them to do something they shouldn't, or you ​wouldn’t want them to?

Picking your Product

When picking your product there are a number of factors to think about: ​

Manage your data packages​ effectively

Name them sensibly:

e.g. <System> <Product> or <Contractor> <Product> or <Format> <Product> or any other useful combination.

Let OS do the hard work!​

• One size doesn’t have to fit all.​ It’s easy to create lots of data packages per product.​

• Not all systems require the same data holdings, so create different packages.​

• Not all systems consume the same data formats, so create different packages.

Delete them when no longer required.

Gives a clearer picture, reduces mail traffic.

Editing your Data Packages

Think very carefully about it – especially with addressing products.​

​What does this really mean?

Editing a data package enables you to change the area of coverage.​ This effectively is then a full resupply followed by future change only updates (if applicable).​ It is not a expanded change only update.

Am I better creating a new package?​

So the questions to ask here are 'Does the package number matter?'​ and 'Is there a cost associated to a full resupply?​'

and then…think very carefully about it again, as you can’t revert back.

Manage your API Projects​ effectively

Name them sensibly:

e.g. <System> <Environment> or <Process> <Environment> or <Contractor> <Product> or any other useful combination.

Let OS do the hard work!​

Different API endpoints can be contained in the same project e.g. Group API’s by target system together.​

Fair Usage Policy & Security​

Don’t use the same API key in every application.​

If you need to change one you don’t want to change them everywhere.​

Delete them when no longer required.

This makes it easier to manage and monitor usage across your estate.​

​Managing Contractors​

We understand that you have a requirement to provide contractor with OS data. There are several ways to achieve this, allowed under the contractor licence:

Direct Access ​

Create a user account for the contractor to download their own data and manage their own API keys.​

Positive: Reduce Administration. Can provide autonomy to contractors. ​

Negative: Full visibility of your Data Hub account. Potential Risk. ​

​Indirect Access​

Manage the data the contractor requires yourself and provide them with the downloaded data or the API keys. ​

Positive: Retain full control. Zero visibility of data hub account. No account management. Reduced Risk. Consistency with naming etc…​

Negative: Increased administration compared to Contractor Read-Write

This content has been developed from what was originally a Lightning Talk PowerPoint slide set. These slides are available to PSGA members to view and download from the PSGA members area of the OS website