AddressRepresentation is a datatype and not a class:
AddressRepresentation comes from the INSPIRE-Address spec where it is clearly marked as a datatype, not as a class. It is distinct from the Address entity, which is marked as a class (or featuretype in INSPIRE terminology).
Datatypes are identified by the values of their attributes, eg the AddressRepresentation Mercatorstraat 12 is different from Rue Mercator 12. They both refer to the same Address however, which is identified by an uri.
There is some intrinsic value in using datatypes where needed, as it tells the user that there is no need to support an identifier for ephemere things like Identifier, Geometry, Name, Contactinfo, Price, Time etc etc
It is correct that RDF does not make any distinction between classes and datatypes. But UML does and as long as your specs support the distinction (as does OSLO, ISO, INSPIRE and others with schemas in UML or variants), the distinction remains useful.
The distinction is also clearly visible in de spec, as the ICEG toolchain is essentially the same as the OSLO toolchain where this distinction is not only made in the diagram but also in the textual rendering of it.
Thus it would be strange to change just one datatype like Addressrepresentation to a class, and leaving all the other datatypes (BuildingGeometry, Geometry, DirectPosition, DateOfEvent etc etc ) as is.
(As a matter of fact, there is one element in the diagram that is now a datatype and that should be a class and that is Document. A Document is clearly something that is identifiable and not identified by the text in it.)
Last thing: some semantic intiatives like SEMIC chose not to make any distinction between classes and datatypes which is there good right. But they are consequential in that, they did not turn some datatypes into classes, they did it for all datatypes.
AddressRepresentation is a datatype and not a class: