Necessity for Address and AddressRepresentation?

[DieterDePaepe]

A topic I had wondered about a bit already, and was briefly touched in another discussion:

Is there a need for both Address and AddressRepresentation in the RDF model? Can they not be merged?

By using only a (subclass of) locn:Address, that contains both the simply locn properties and the specialised INSPIRE attributes, users unfamiliar with INSPIRE would not be confused as to why the structured data of an address is stored in a different class.

[jechterhoff]

Good point. It looks like a pattern is emerging: A <<dataType>> of the INSPIRE conceptual schemas, which is primarily used as a facade for / simplified view on an INSPIRE <<featureType>>, could, in the RDF encoding, either be replaced by or merged with that feature type.

[jechterhoff]

In the revision of the draft vocabularies and guidelines:

• Type 'AddressRepresentation' is mapped to the RDF implementation of type 'Address'.
• Type 'Address' is aligned with locn:Address.
• A permission has been added to the guidelines, which states that "a \<> of the INSPIRE conceptual schemas, which is primarily used as a simplified view on an INSPIRE spatial object type, may, in the RDF encoding, either be mapped to or merged with that spatial object type." The following explanation was also added: "When working with linked data, you should be able to directly link to a spatial object, rather than introducing an indirection by linking to a resource which merely provides a simplified view on the spatial object."