You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ArjenSantema commented on Aug 24, 2022
Er zijn inmiddels verschillende digitale stelsels met ieder een stelselcatalogus. Iedere stelsel kent verschillenden domeinen, bijvoorbeeld de domeinen van de basisregistraties met ieder hun eigen onderliggende wetgeving. Punt is hoe je de begrippen in deze domeinen verbindt: door 1 overkoepelend begrippenkader te defiëren voor alle domeinen samen of door begrippen uit verschillende domeinen te verbinden via externe matching (exactMatch, relatedMatch, etc.).
Het eerste doen we bij Zorgeloos Vastgoed, waar we voor ieder begrip het eigenaarschap hebben neergelegd bij 1 partij. Ondanks de verschillende publieke én private partijen die hierbij betrokken zijn is vastgoed wel 1 sector, c.q. soort domein en wil je bij samenwerking in de sector als eerste dezelfde betekenis aan dezelfde begrippen geven.
In de stelselcatalogus gaat het om verschillende domeinen en hebben bijvoorbeeld de BRT en de BAG ieder hun eigen onderliggende wetgeving. Met als gevolg dat een begrip als 'gebouw' in beide registraties wordt gedefinieerd, terwijl het intuïtief over hetzelfde gaat en het stelsel van basisregistraties toch ook als samenhangend stelsel is bedoeld. Dit is een issue wat we ook bij het Kadaster hebben, als we dit niet oplossen kunnen we niet 1 Kadaster begrippenkader maken omdat wij al dit soort registraties beheren. Je kunt 'gebouw (BAG)' en 'gebouw (BRT)' als synoniemen beschouwen, maar binnen 1 taxonomie is het een dan een alternatieve term voor het ander en is het 1 begrip.
Hoe mooi zou het zijn als we de stelselcatalogus kunnen vullen met een statement als brt:Gebouw skos:inScheme stelsel:Catalogus of zoiets.
@architolk
Collaborator
architolk commented on Aug 25, 2022
Begrippen ontstaan vanuit gebruik in een specifiek domein, hetzij formeel vastgesteld in regelgeving en afspraakdocumenten, hetzij "zoals gebruikelijk" in een bepaald domein. Domeinoverstijgende begrippen ontstaan voor mijn gevoel dan ook vanuit domeinoverstijgend gebruik. Zoals bij Zorgeloosvastgoed daadwerkelijk een samenwerking is ontstaan, met haar eigen begrippen (die dan dus ook verbonden zijn met de begrippen uit andere domeinen). Waar er geen domeinoverstijgende samenwerking is, lijkt me dus ook geen domeinoverstijgende begrippen te kunnen ontstaan, hooguit een verbinding vanuit het ene domein naar het andere domein. Hetzij expliciet (omdat in de regelgeving/afspraken daadwerkelijk is gezegd dat een begrip hetzelfde is als in een ander domein, hetzij doordat uit analyse blijkt dat het zo in elkaar zit - of net iets anders...)
@ArjenSantema
Collaborator
Author ArjenSantema commented on Aug 26, 2022
Samenvatting discussie 25/8/2022:
Er is niets op tegen een begrip met een uri uit een andere registratie te importeren. Een punt van aandacht is dan wel hoe je bewaakt dat je actueel blijft als er een nieuwe versie door de bronhouder van het begrip wordt gepubliceerd. De stelselcatalogus van de basisregistraties kun je zien als 1 catalogus waarin alle begrippen uit de basisregistraties worden geïmporteerd. Als begrippen in meerdere registraties worden gedefinieerd, bijvoorbeeld het begrip 'gebouw' in zowel de BGT als in de BAG (met ieder hun eigen wetgeving) zijn het 2 begrippen. Deze worden in de stelselcatalgus verbonden met een 'clusterbegrip', dat een generalisatie is van deze begrippen. Zo ontstaat toch 1 taxonomie. Dit is één good practice, maar niet de enige en ook niet altijd de beste. Soms is het te omslachtig of is de beheerder van een catalogus niet bevoegd om zo'n clusterbegrip te definiëren. Dan blijven de externe matching mechanismes over (exactMatch, closeMatch, broadMatch, narrowMatch, relatedMatch) over. Daarmee verbindt je de verschillende taxonomieën, maar ontbreekt de stap naar 1 geïntegreerde taxonomie. Dit onderwerp verdient nog nadere uitwerking, die pas relevant wordt als de basis op orde is.
pldn/nederlands-profiel-voor-stelselcatalogi#39
ArjenSantema commented on Aug 24, 2022
Er zijn inmiddels verschillende digitale stelsels met ieder een stelselcatalogus. Iedere stelsel kent verschillenden domeinen, bijvoorbeeld de domeinen van de basisregistraties met ieder hun eigen onderliggende wetgeving. Punt is hoe je de begrippen in deze domeinen verbindt: door 1 overkoepelend begrippenkader te defiëren voor alle domeinen samen of door begrippen uit verschillende domeinen te verbinden via externe matching (exactMatch, relatedMatch, etc.).
Het eerste doen we bij Zorgeloos Vastgoed, waar we voor ieder begrip het eigenaarschap hebben neergelegd bij 1 partij. Ondanks de verschillende publieke én private partijen die hierbij betrokken zijn is vastgoed wel 1 sector, c.q. soort domein en wil je bij samenwerking in de sector als eerste dezelfde betekenis aan dezelfde begrippen geven.
In de stelselcatalogus gaat het om verschillende domeinen en hebben bijvoorbeeld de BRT en de BAG ieder hun eigen onderliggende wetgeving. Met als gevolg dat een begrip als 'gebouw' in beide registraties wordt gedefinieerd, terwijl het intuïtief over hetzelfde gaat en het stelsel van basisregistraties toch ook als samenhangend stelsel is bedoeld. Dit is een issue wat we ook bij het Kadaster hebben, als we dit niet oplossen kunnen we niet 1 Kadaster begrippenkader maken omdat wij al dit soort registraties beheren. Je kunt 'gebouw (BAG)' en 'gebouw (BRT)' als synoniemen beschouwen, maar binnen 1 taxonomie is het een dan een alternatieve term voor het ander en is het 1 begrip.
Hoe mooi zou het zijn als we de stelselcatalogus kunnen vullen met een statement als brt:Gebouw skos:inScheme stelsel:Catalogus of zoiets.
@architolk
Collaborator
architolk commented on Aug 25, 2022
Begrippen ontstaan vanuit gebruik in een specifiek domein, hetzij formeel vastgesteld in regelgeving en afspraakdocumenten, hetzij "zoals gebruikelijk" in een bepaald domein. Domeinoverstijgende begrippen ontstaan voor mijn gevoel dan ook vanuit domeinoverstijgend gebruik. Zoals bij Zorgeloosvastgoed daadwerkelijk een samenwerking is ontstaan, met haar eigen begrippen (die dan dus ook verbonden zijn met de begrippen uit andere domeinen). Waar er geen domeinoverstijgende samenwerking is, lijkt me dus ook geen domeinoverstijgende begrippen te kunnen ontstaan, hooguit een verbinding vanuit het ene domein naar het andere domein. Hetzij expliciet (omdat in de regelgeving/afspraken daadwerkelijk is gezegd dat een begrip hetzelfde is als in een ander domein, hetzij doordat uit analyse blijkt dat het zo in elkaar zit - of net iets anders...)
@ArjenSantema
Collaborator
Author
ArjenSantema commented on Aug 26, 2022
Samenvatting discussie 25/8/2022:
Er is niets op tegen een begrip met een uri uit een andere registratie te importeren. Een punt van aandacht is dan wel hoe je bewaakt dat je actueel blijft als er een nieuwe versie door de bronhouder van het begrip wordt gepubliceerd. De stelselcatalogus van de basisregistraties kun je zien als 1 catalogus waarin alle begrippen uit de basisregistraties worden geïmporteerd. Als begrippen in meerdere registraties worden gedefinieerd, bijvoorbeeld het begrip 'gebouw' in zowel de BGT als in de BAG (met ieder hun eigen wetgeving) zijn het 2 begrippen. Deze worden in de stelselcatalgus verbonden met een 'clusterbegrip', dat een generalisatie is van deze begrippen. Zo ontstaat toch 1 taxonomie. Dit is één good practice, maar niet de enige en ook niet altijd de beste. Soms is het te omslachtig of is de beheerder van een catalogus niet bevoegd om zo'n clusterbegrip te definiëren. Dan blijven de externe matching mechanismes over (exactMatch, closeMatch, broadMatch, narrowMatch, relatedMatch) over. Daarmee verbindt je de verschillende taxonomieën, maar ontbreekt de stap naar 1 geïntegreerde taxonomie. Dit onderwerp verdient nog nadere uitwerking, die pas relevant wordt als de basis op orde is.
@ArjenSantema ArjenSantema added the enhancement label on Aug 26, 2022
@RiX012
RiX012 commented on Jan 27, 2023
Inderdaad voor een volgende versie
The text was updated successfully, but these errors were encountered: