politicalGeocodingURI needed not only adminUnitL2

[SebastianSK]

AdminUnitL2 is of data type text. The examples given use the nuts code.

In Germany we have several nuts-alike statistical geocoding keys that range from
a) the list of streets (Straßenschlüssel - Level 5)
b) the list of districts (Landkreisschlüssel - Level 4)
c) the list of municipalities (Allgemeiner Gemeindeschlüssel AGS- Level 4)
d) the list of regions (Regionalschlüssel - Level 3)
e) the list of states (States - Level 2)

After having streamlined thoughts with German KoSIT (#6) what Germany needs here is:

the possibility to express those geopolitical encoding in zero-to-many keys that are not called "secondLine" but have a rather level-agnostic name. Perhaps we should use something like "politicalGeocodingURI"

In DCAT-AP.de we extend the Core Location in the following manner to respond to German key-needs:

1. the level of the geopolitical key dcatde:politicalGeocodingLevelURI https://www.dcat-ap.de/def/politicalGeocoding/Level/
2. the key itself, dcatde:politicalGeocodingURI that then links to e.g. the municipalityKey https://www.dcat-ap.de/def/politicalGeocoding/municipalityKey/

[giorgialodi]

I see some possibilities here:

1. we could consider the INSPIRE address data model where there is a concept of AdminUnit with the name and the hierarchy level (instead of having data type properties - strings - whose name include the level too in some cases). In the Italian data model we follow the INSPIRE address model and we have the geographical hierarchy expressed as classes so that to use national controlled vocabularies for country, region, province, city.
2. keep the things here very core/simple leaving you as Germany to extend it as you have done in the case of DCAT-AP.DE. In CLV postname is the city and thoroughfare is the street name.
3. definitely fix the type for AdminLevel2: if it is recommended to use a controlled vocabulary it cannot be a Text (AdminUnit1 and AdminUnit2 #10)

[bertvannuffelen]

A generic comment on the cv:Address notion.

We should align on the purpose of the cv:Address notion: is it to cover in a structured way European addresses or is it to provide a common way to express addresses from all around the world?

Both objectives are valuable, but cannot be satisfied easily in one cv:Address because for almost every component in an address there is a structured coded version or a non-structured version.

INSPIRE (https://inspire.ec.europa.eu/data-model/approved/r4618-ir/html/index.htm?goto=2:1:1:1:7062) has this distinction. An inspire:Address is a structured notion capable to handle all European addresses. The inspire:AddressRepresentation is a flattened structure where all the composition of the values is reduced to a label.

It is on the inspire:AddressRepresentation that cv:Address has been build.

I think we have to consider here whether the cv:Address should capture the structural decomposition of addresses in a every MS. If that is needed the inspire:address model should be fitting already.

Maybe this is missing in the cv:Address a link to the inspire structured representation of the address. If I am not mistaken, according to INSPIRE every MS has to publish PURIs for their addresses pointing to the structured version of the addresses.
So linking a cv:Address with an INSPIRE PURI address would share the MS perfect structured view.

I understand that system designers would like to offer the same sorting and organisation of entities according to the system default address system, but I think this has limits. Given raise to these generic properties names like LocatorDesignator and AdminUnitLevel{1,2,3,...} which probably are not the daily terminology people use to write an address on an evelope.

So maybe we should look from a perspective what are the common information we would like to know from an address so that the most common operations can be achieved on a collection of addresses from within the EU, but also from outside them.

[dimi-schepers]

During the Core Vocs webinar dd. 2021-05-20, an agreement was reached to include a new generic field (expecting a geopolitical code) allowing countries to represent their own political and jurisdictional system in addition to the two levels of administrative units. The editorial team will propose something.

[EmidioStani]

During the webinar of 02/12/2021 it was agreed to add an additional class AdminUnit with properties:

• code, indicating the classification of the AdminUnit
• level, indicating the level of the AdminUnit

It was also agreed to create a relation between Address and AdminUnit called additionalAdminUnit

The properties AdminUnitL1 and AdminUnitL2 will stay to not break compatibility

[EmidioStani]

The AdminUnit class has been added in the consolidated diagram https://github.com/SEMICeu/Core-Location-Vocabulary/tree/master/releases/2.00