Closed dirk-qualisys closed 5 months ago
First of all, UN GHS sees new revisions every two years, and different regional/national implementations at any point in time are based on different GHS revisions. So we will have one type per UN GHS revision, and then define national GHS varieties as a restriction from the according UN GHS type. This reflects the building block approach.
Acute Toxicity is implemented in HazardClassCategoryEnum only once, although there are three routes of exposure which are classified separately. This is because the classification in SDScom up to 4.4.0 allows for multiple instances of HazardClassCategoryEnum which are combined with an optional HazardStatement or two. This works only where H phrase codes are used in classification, i.e. not on UN level or in the U.S., and it opens the door for inconsistent data like "Acute Tox. 1" + H229. So I will represent classes and categories in a comprehensive way in one enumeration type.
Defining classes and categories:
The first option was to define one type for the original GHS classes and categories, similar to HazardClassCategoryEnum, then restrict and enhance this type for the next revision, which in turn is the base class for the next revision etc. After seven revisions, the outcome is scattered so that it is hard to derive which values would be allowed. And at that point this we would need to derive the national GHS implementations...
The second option was to copy&paste classes and categories from one revision to the next, so that each GHS type is comprehensive and independent from other types. This makes it easy to read, but lengthy: The original GHS plus seven revisions ended up in 970 lines of code, making it hard to understand where the differences are and when they were introduced. Bearing in mind that SDScom should be also instructive, not the best choice either.
So I implemented each class separately, and created an additional type whenever this class was revised. The GHS revisions are then defined as a union of all applicable classes, i.e. classes which are valid for the repsective revision of UN GHS. The result is 570 lines of code and a better understanding of the development of GHS.
The third approach has the additional advantage that splitting classes into types does not need to reflect the sections of GHS exactly, but can be done to create enumerations of which exactly zero or one must be chosen, so that these enumeration types may be useful in other settings (or are at least instructional for implementing data models and user interfaces in IT systems).
For that reason, Pyr. Gas and Chem. Unst. Gas are implemented separately from Flam. Gas up to GHS revision 6, but integrated in Flam. Gas in revision 7. Also, STOT SE 3 is implemented separately from STOT SE 1/2.
Some comments on my commit:
Labelling is still missing, just the classification follows the new structure for now.
With the two possible ways of classifying in the EU during the transition period from GHS rev. 5 to GHS rev. 7, and the types being bound to either of them, I had to introduce two elements for classification which differentiate the GHS revision in their name. I.e., depending on the GHS revision you chose to classify, you need to populate different elements. Any better ideas? If not, do we still need ClpAtp?
Sometimes, GHS allows for subcategories within hazard categories, e.g. Eye Irrit. 2A and 2B are both labelled in the same way. For consistency, I have now added those subcategories where they were missing in 4.4.0.
Would be happy for any comments before I proceed with US and Canadian classification, and labelling.
Continued on that route and implemented precautionary statements. As with the hazard statements, there is one enum type per class for precautionary statements. This means that one can see in the implementation if the list of P phrases changed, but not if just one P phrase was dropped in a certain category while still used in another category of the same class. As a consequence, the SDScom implementation does not function as a comprehensive summary of labelling changes, or provide types that IT systems could use for their internal implementation to choose appropriate P phrases (where this is permitted). It would be easy to implement one Hazard or Precaution type per category (instead of class), but this increases the length of GHS type definitions significantly. Since IT systems will most likely use their own structures to facilitate choosing P phrases, I think the advanced complexity would not pay off.
I also added GHS revision 8, published mid of 2019 and certainly not yet used in any part of the world. They really liked to change precautionary statements there - have a look at the GHS types!
Will the enumeration cover H320 in future? This is a phrase covered by UN but not by CLP.
H320 is now included in v5.6:
`
As mentioned in issue #98, this is to collect reasoning and implementation aspects for classification and labelling types.