|
| 1 | +--- |
| 2 | +title: Manage a custom terms type |
| 3 | +weight: 6 |
| 4 | +--- |
| 5 | + |
| 6 | +# How to manage a custom terms type |
| 7 | + |
| 8 | +When tracking terms and conditions across different services, you might encounter situations where a service uses terms types that aren't yet supported by Open Terms Archive. |
| 9 | +This guide will help you handle these custom terms types effectively, whether you're working on a new collection or expanding an existing one. |
| 10 | + |
| 11 | +## Understanding the validation |
| 12 | + |
| 13 | +Open Terms Archive validates terms types to ensure consistency and quality across collections. When you encounter a validation error like: |
| 14 | + |
| 15 | +```shell |
| 16 | + 1) Service declarations validation |
| 17 | + <service_name> |
| 18 | + valid declaration schema: |
| 19 | + Error: |
| 20 | + |
| 21 | + data/terms must be equal to one of the allowed values (in entire file) |
| 22 | +``` |
| 23 | + |
| 24 | +This means the terms type you're trying to use isn't in the official list of supported types. |
| 25 | + |
| 26 | +## Before going further |
| 27 | + |
| 28 | +Before proceeding with using a custom terms type, please double-check that the type you're considering doesn't already exist in the supported terms types list. Different services often use different names for the same type of terms. For instance, "Terms and Conditions" might be called "Terms of Use" or "Terms of Service" by different services. |
| 29 | + |
| 30 | +Review the [supported types list](https://github.com/OpenTermsArchive/terms-types/blob/main/termsTypes.json) carefully to ensure the terms type you want to track is not already supported under a different name. If it does, use the associated type in your declaration. If you are sure it's not supported, you can proceed with the following steps. If you're unsure, you can ask for help in the [Open Terms Archive community]({{< relref "community/how-to/join" >}}). |
| 31 | + |
| 32 | +## Long-term solution |
| 33 | + |
| 34 | +The recommended approach is to contribute your new terms type to the official list. This helps maintain consistency across collections and enables better comparison of terms across different services. |
| 35 | + |
| 36 | +You can propose your new terms type for inclusion in the official list of supported types via the [dedicated repository](https://github.com/OpenTermsArchive/terms-types), following the [contribution process](https://github.com/OpenTermsArchive/terms-types/blob/main/CONTRIBUTING.md#add-new-terms-types). |
| 37 | + |
| 38 | +This process has the following benefits: |
| 39 | + |
| 40 | +- Your terms type becomes available to all collections |
| 41 | +- You don't need to maintain a custom fork |
| 42 | +- It helps build a more comprehensive and useful shared list |
| 43 | +- Enables better comparison of terms across different services |
| 44 | + |
| 45 | +This solution can take some time to have your terms type to be approved, so if you need a faster solution, you can proceed with the following temporary solutions. |
| 46 | + |
| 47 | +## Temporary solutions |
| 48 | + |
| 49 | +### For proof of concept or development |
| 50 | + |
| 51 | +As the validation is primarily intended for production environments to maintain consistency, if you're working on a proof of concept or development environment that won't be deployed to production, you can safely ignore these validation errors, the whole tracking process will still work. |
| 52 | + |
| 53 | +### Using a forked version |
| 54 | + |
| 55 | +If you need a faster solution for production use, you can fork the terms-types repository and add your custom type: |
| 56 | + |
| 57 | +1. Fork the [terms-types repository](https://github.com/OpenTermsArchive/terms-types) |
| 58 | +2. Add your custom terms type to the `termsTypes.json` database file |
| 59 | +3. Update your collection's `package.json` to use your fork: |
| 60 | + |
| 61 | +```json |
| 62 | +{ |
| 63 | + "dependencies": { |
| 64 | + "@opentermsarchive/engine": "5.0.3", |
| 65 | + "@opentermsarchive/terms-types": "<your-organization-or-username>/terms-types#main" |
| 66 | + } |
| 67 | +} |
| 68 | +``` |
| 69 | + |
| 70 | +This solution is only recommended as a temporary solution, it is strongly recommended that you also submit the new terms type through the process describe in previous section. This way, you'll contribute to the community by helping maintain consistency across collections and enables better comparison of terms across different services, and also eventually stop maintaining a custom fork. |
0 commit comments