Design Guidelines¶

These are guidelines for creating IDSs according to Tetra Data conventions. These guidelines go beyond the base level of platform requirements which every IDS must follow (such as having an @idsType defined).

The aim of these guidelines is to make IDSs consistent by using a common set of practices and reusable Components, which makes IDSs easier to create and maintain, and makes data easier to consume downstream by making IDS design predictable.

The detailed conventions are organized into the following pages:

General¶

#	Rule	Checked by IDS Validator (only for IDS designed by TS)
1	Most of the fields in schema.json should be nullable unless defined to be NOT NULL in Nullable values and required fields or confirmed with the vendor that cannot be null	No
2	If a field indicates that it’s a scientific measure, like “weight”, “mass”, “volume”, use the `RawValueUnit` component	No
3	All scientific units should be standardized where possible, see Units	No
4	All ID-like fields must be string type, user ID, instrument ID, sample ID, etc.	No
5	Combine fields that has the common key prefix into one single object by extracting the prefix as the parent key	Yes, warning if not followed
6	Any IDS field called `name` should follow this convention: If the value is derived from the raw file, use the raw file’s name. If the value does not come from the raw file, use all lower case and separate words with spaces	No
7	Make the field name singular if its value is not an array	No
8	Make the field name plural if its value is an array	No
9	For fields with a value that is a non-scientific number, you don’t need to define it as `RawValueUnit`. For example, index of something or count of something	No
10	Spell out acronyms and abbreviations as the full names if possible to avoid ambiguities	No
11	Annotate fields with `Required` to objects when the fields must be present in the IDS JSON	No