search

belgif / thematic

ICEG: Thematic Working Groups
11 stars 5 forks source link

Update REFNIS SKOS thesaurus / municipalities being merged #167

Open barthanssens opened 3 months ago

barthanssens commented 3 months ago

(actually a ticket for vocab-belgif, but mentioning it here for gathering additional comments)

There is a linked open data SKOS thesaurus of Statbel's REFNIS municipality codes. Given that a few municipalities will merge end of 2024 / start of 2025 (https://statbel.fgov.be/nl/over-statbel/methodologie/classificaties/geografie), an update is needed.

Two options:

barthanssens commented 3 months ago

(I'd go for the second option, since there are no "hierarchical" changes like in 2019)

As Statbel pointed out, there is 1 special case: Antwerp, which will not have a new REFNIS code (since it is being merged with a much smaller municipality), meaning that there could be some ambiguity in "new" Antwerp vs "old" Antwerp if option B is selected (since the URI will be re-used). An owl:version + skos:note could be added to document this change.

bdevloed commented 3 months ago

Thanks for opening this ticket.

I also feel reluctant to keep minting new URI's for the same unchanged NIS code for every NIS release. Wouldn't it be better to keep the year of the release out of the uri? And reflect updates as described in option 2?

Releasing 2025 NIS updates in a 2019 namespace seems a bit counter intuitive.

barthanssens commented 3 months ago

It's a bit of a tradeoff: the reason why there are currently two year-coded version of REFNIS, is mainly because of changes in "hierarchy" (i.e. municipalities were "moved" to another arrondissement = changes in skos:broader). Which AFAIK is non-trivial to keep track of in plain SKOS, if you want to be able to have both old and new situation in one version...

(one could probably use named graphs to group these statements, but not sure if that would make it more clear to other users / would be supported in tools)

barthanssens commented 2 months ago

As an example on how the new relations could be documented

Easiest way (downside, no URI to uniquely identify Antwerp before/after merger, then again, that's also not the case for the '11002' code in non-linked data applications. It is easy to indicate start/end date of a concept, but not the start/end date of a relation without resorting to quads / RDF-star)

<http://vocab.belgif.be/auth/refnis2019/11002> a skos:Concept ;
    skos:prefLabel "Antwerpen"@nl ;
    schema:startDate "1831-01-01" ;
    skos:changeNote "Includes Borsbeek as of 1/2025";
    skos:narrower  <http://vocab.belgif.be/auth/refnis2019/11007> .

<http://vocab.belgif.be/auth/refnis2019/11007> a skos:Concept ;
    skos:prefLabel "Borsbeek"@nl ;
    schema:startDate "1831-01-01" ;
    skos:changeNote "Part of Antwerpen as of 1/2025 " ;
    skos:broader <http://vocab.belgif.be/auth/refnis2019/11002> .

<http://vocab.belgif.be/auth/refnis2019/46029> a skos:Concept ;
   schema:endDate "2024-12-31" ;
   skos:prefLabel "Lokeren"@nl ;
   skos:narrower <http://vocab.belgif.be/auth/refnis2019/46014> ; 
   skos:narrower <http://vocab.belgif.be/auth/refnis2019/44045> .

<http://vocab.belgif.be/auth/refnis2019/46014> a skos:Concept ;
   schema:endDate "2024-12-31" ;
   skos:prefLabel "Lokeren"@nl ;
   skos:broader <http://vocab.belgif.be/auth/refnis2019/46029> .

<http://vocab.belgif.be/auth/refnis2019/44045> a skos:Concept ;
   schema:endDate "2024-12-31" ;
   skos:prefLabel "Moerbeke"@nl ;
   skos:broader <http://vocab.belgif.be/auth/refnis2019/46029> .

Another option would be to introduce a '2025' within the refnis2019 uri just for Antwerp, which could lead to some confusion (and still uses a somewhat indirect way to indicate start/end of relation, using once again start/end on the concept/labe)

<http://vocab.belgif.be/auth/refnis2025/11002> a skos:Concept ;
    skos:prefLabel "Antwerpen"@nl ;
    schema:startDate "2025-01-01" ;
    skos:narrower  <http://vocab.belgif.be/auth/refnis2019/11007> .

<http://vocab.belgif.be/auth/refnis2019/11002> a skos:Concept ;
    skos:prefLabel "Antwerpen"@nl ;
    schema:startDate "1831-01-01" ;
    schema:endDate "2024-12-31" .
    skos:broader <http://vocab.belgif.be/auth/refnis2025/11002> .

<http://vocab.belgif.be/auth/refnis2019/11007> a skos:Concept ;

    skos:prefLabel "Borsbeek"@nl ;
    schema:startDate "1831-01-01" ;
    skos:broader <http://vocab.belgif.be/auth/refnis2025/11002> .
pieterfa commented 1 week ago

Hi, thanks for opening this ticket.

For the second option (update current version and add some extra versionning data) I would use a dedicated property such as dcterms:replacedBy (and not the skos broader relation) to link the deprecated concepts to their new 'replacing' ones. This is more common practice. It is also more clear and unambigous. A concept can be deprecated and a dedicated property tells you which one(s) to use instead. Using skos broader or narrower relations to model merge, split or even mixed cases introduces some noice in the hierarchy and might cause ambiguities in the meaning of the hierarchical relationships. Using a dedicated property such as dcterms:replacedBy is unambiguous and it also allows:

pieterfa commented 1 week ago

Concerning Antwerp, normally, the meaning of a concept in a codelist should never change because it is referenced by existing resources. So the general rule is, if the meaning, i.e. the scope or the range, of a concept changes a new concept should be created. But, in this case, the concept just takes on a slightly broader meaning. Existing references to this concept will still be valid. This is the reason why the code '11002' is not changed, I guess. So I think both options are ok.

pieterfa commented 1 week ago

When choosing the first option, creating a new concept for Antwerp, we have two concepts with the same skos:notation value which should be unique within a conceptscheme. This can be solved by introducing different skos:notation systems (i.e datatypes). One for each new niscode version. Each concept gets a skos notation for each version where it did exist and was not deprecated.

Example: <http://vocab.belgif.be/auth/refnis2025/11002> skos:notation "11002"^^refnis:2025code, "11002" . <http://vocab.belgif.be/auth/refnis2019/11002> owl:deprecated true ; skos:notation "11002"^^refnis:2019code . <http://vocab.belgif.be/auth/refnis2019/11007> owl:deprecated true ; skos:notation "11007"^^refnis:2019code . <http://vocab.belgif.be/auth/refnis2019/46029> skos:notation "46029"^^refnis:2025code, "46029" . <http://vocab.belgif.be/auth/refnis2019/46014> owl:deprecated true ; skos:notation "46014"^^refnis:2019code . <http://vocab.belgif.be/auth/refnis2019/44045> owl:deprecated true ; skos:notation "44045"^^refnis:2019code . <http://vocab.belgif.be/auth/refnis2019/24001> skos:notation "24001"^^refnis:2019code, "24001"^^refnis:2025code, "24001" .

pieterfa commented 1 week ago

What will happen with the mapping relations to the 1995 version if we choose to update current (2019) version?