Flexible Classification Standards for Product Data Exchange applications like spent analysis instead of product refinement. This has been pointed out by Hepp, 2006 who revealed that a number of mappings of eCl@ss and UNSPSC to OWL are semantically incorrect: They represent the class hierarchy with an rdfs: subclassOf construct which leads to the wrong semantics regarding the subclass as a specialized concept of its superclass. This would, for instance, lead to the wrong implication that a screw assortment box (eCl@ss code 23-11-92- 04) is a specialization of a Screw / Nut (eCl@ss code 23-11-00-00). Thus, the eCl@ss classes must not be related by the is-a relationship. PLIB provides the con- struct of categorization classes which have been specifically introduced to model classes of eCl@ ss and UNSPSC, and they are not related by the is-a, but by the case-of relationship. Categoriza- tion classes do not possess any properties, thus the properties cannot be linked as before to the classes and the capabilities of the underlying data model, these classes cannot be automatically related and thus analyzed for common properties, etc. Nor- mally, the top level branches of many industry spanning classification standards (like eCl@ss and UNSPSC) represent different industrial sec- tors, thus the working groups are responsible for separated branches of the class hierarchy. And the simple data models used for these classifications does not support a harmonized organization of identical properties. With the old data model, eCl@ss has only one mechanism for modelling (at least) two different situations: On the one hand, eCl@ss provides a categorization hierarchy which models markets of products. Therefore, the class hierarchy is organised according to product domains which represent specific industrial branches. The goal is to give companies a clear part of the hierarchy where they can find the relevant products of