Datatypes of SEMIC-Address:Address.adminUnit and INSPIRE-Address:AddressRepresentation.adminUnit differ

[GeertThijs]

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?

[EmidioStani]

This issue groups a different issues:

1) The original request from Germany to represent a code and level was brought to the working group where the creation of AdminUnit class was approved; in this way the AdminUnitL1 and AdminUnitL2 properties in the Address class stayed a free text while in the AdminUnit class there is opportunity to Member States to adopt a classification system, thus it keeps compatibility with INSPIRE and still we need to consider that all of them are optional properties and relations while for INSPIRE some properties are mandatory. Now, looking at the UML diagram at page 27 of https://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AD_v3.0.pdf section 5.2.12, there is a class AdminUnitName with properties "name" and "level'; looking at the URIs of Germany used (see issue #12) for code and level, each of them have a "label" that could be skos:prefLabel of the respective code and level URIs

2) your question about to create a reference for postName/postCode could come from PostalDescriptor (depicted in the UML diagram above) and it could solve the partially the issue brought by Norway in CPSV-AP: https://github.com/SEMICeu/CPSV-AP/issues/107

So within this issue I would focus on point 2) if there is interest.

[GeertThijs]

That is not my point, my point is that SEMIC:Address is mapped on INSPIRE:AddressRepresentation and not on INSPIRE:Address as can be deduced from the definition and usageNote https://semiceu.github.io/Core-Location-Vocabulary/releases/2.00/#Address. If we follow along with this then:

• INSPIRE:AddressRepresentation is a more readable, less structured version of INSPIRE:Address. Very usefull to convey an Address in one language for example or to represent it as a label to put on a letter or a map. On the other hand INSPIRE:Address is the official multiligual and structured reference version of the Address from which several AddressRepresentations can be derived.

• It can be a bit confusing that SEMIC uses Address as a name for something that is actually only an AddressRepresentation, but let's say that this is done so for convenience.

• Another difference is that INSPIRE models AddressRepresentation as a datatype, it has no identity unlike an INSPIRE:Address which is a class. This causes possible confusion for the users of SEMIC:Address as SEMIC:Address.addressid is NOT the id of the AddressRepresentation but that of the Address from which it was derived (see further).

• If we compare INSPIRE:Addressrepresentation with the SEMIC-version of it than we get this:

• We see that SEMIC added some usefull fields like fullAddress and poBox, no problem with that.

• Also adminUnitL1 and adminUnitL2 are usefull, the first to denote the country, the latter a state or region in that counntry. Usefull to denote foreign addresses.

• INSPIRE:Addressrepresentation.addresFeature was renamed to SEMIC:Address.addressid. However, this is not the id of the INSPIRE:AddressRepresentation but that of the INSPIRE:Address. This should be made more clear in the definition and usageNote.

• An important difference is that INSPIRE:AddressRepresentation.adminunit is an attribute (with datatype LanguageString) while SEMIC:Address.adminUnit is an association with an instance of the class AdminUnit. In my opinion this is one step too far. It furthers the confusion between SEMIC:Address being a structured Address like INSPIRE:Address or being an INSPIRE:Addressrepresentation.

• Worse is that SEMIC:Address can no longer be used in an informal way as an Addressrepresentation, one can no longer say "MercatorStreet 12, 1070 Brussels" but has to say "MercatorStreet 12, 1070 (reference to AdminUnit Brussels)". So you need some uri to denote the AdminUnit in stead of simply providing its name.

• And to add further to this problem: in the class AdminUnit there is only two fields: code and level. No name attribute or anything.

To conclude: I could live with the fact that by recuperating INSPIRE:AddressRepresentation as SEMIC:Address

1. the name of the element is changed from AddressRepresentation to Address,
2. its metaclass is changed from Datatype to Class,
3. the attribute addressFeature is renamed to addressId (if the definition and usageNotes make more cleat that this is a reference to the structured Address)

but not with

4. that adminunit is no longer an attribute of type Langstring but an association with a class AdminUnit.

If we start with associations like with Adminunit (or even with AdminUnitName which is actually an INSPIRE:Address Addresscomponent) SEMIC:Address is no longer an AddressRepresentation anymore but a structured Address, more (but still a lot less) like INSPIRE:Address. If that is the goal however, a lot more changes should be made to SEMIC:Address as the model of INSPIRE:Address is rather complicated.

Having a Core Vocabulary with a half-structured Address which neither fully maps to INSPIRE:AddressRepresentation, and neither fully to INSPIRE:Address is not advisable.

[EmidioStani]

Hello @GeertThijs ,

today we are proposing a different thing, putting the adminunit attribute inside the AdminUnit class but since your point is to avoid to use URI so one can do "MercatorStreet 12, 1070 Brussels" " in the Address we can propose this alternative.

[EmidioStani]

During the webinar on the review of Core Vocabularies on the 27th of October, it was agreed to put on hold this issue and look at INSPIRE RDF guidelines.