-
Notifications
You must be signed in to change notification settings - Fork 5
Description
If SEMIC-Address:Address maps to INSPIRE-Address:AddressRepresentation, why then Address.adminUnit and Addressrepresentation.adminUnit have different datatypes? The first actually points to an AdministrativeUnit, while the latter is a GeographicalName (which more or less corresponds to a geographical LanguageString), meant to represent the name of the AdminstrativeUnit. AddressRepresentations are meant to be much more flexible than a structured Address, allowing to just put down the name of a municipality or other locality rather than having to reference an AdminstrativeUnit object. To make things even more difficult, this object only has a code and a level attribute. Even in the INSPIRE structured Address the Address does not connect directly to the AdminstrativeUnit, it is associated with an address component of type MunicipalityName (which in stead is supposed to connect with AdministrativeUnit). The SEMIC Address in its curent version goes one step too far in structuring something that is no more than an AddressRepresentation, a human-readable representation of an Address for use as a label on a letter or on a map. Plus that it no longer maps 1:1 to the INSPIRE AddressRepresentation. And if adminUnit is now a reference rather that a name, why not do the same for postName or postcode or even thoroughfare?