The use of the "Digital Nameplate" submodel is prevented by the fact that too many properties are mandatory, but are not required in some product groups.
One example of this is the BatteryPassport, where the Battery Regulation prescribes how the nameplate-based information must be presented. Using the current submodel “Digital Nameplate” means that additional (mandatory) properties are included that are not required by the regulation. See also the issue here: #170
The submodel “ContactInformation” can be considered as blueprint, as all of its properties are defined as optional and it is very well suited for reuse.
Those elements should be made optional:
- URIOfTheProduct
- ManufacturerName
- ManufacturerProductDesignation
- AddressInformation
- OrderCodeOfManufacturer
Making URIOfTheProduct optional is important to address legacy assets, which usually have not an URI. One could argue about whether ManufacturerName should be the only mandatory property. But it certainly does no harm to define as also optional.
@mv-sickde @SAidta
The use of the "Digital Nameplate" submodel is prevented by the fact that too many properties are mandatory, but are not required in some product groups.
One example of this is the BatteryPassport, where the Battery Regulation prescribes how the nameplate-based information must be presented. Using the current submodel “Digital Nameplate” means that additional (mandatory) properties are included that are not required by the regulation. See also the issue here: #170
The submodel “ContactInformation” can be considered as blueprint, as all of its properties are defined as optional and it is very well suited for reuse.
Those elements should be made optional:
Making URIOfTheProduct optional is important to address legacy assets, which usually have not an URI. One could argue about whether ManufacturerName should be the only mandatory property. But it certainly does no harm to define as also optional.
@mv-sickde @SAidta