Organisatienaam is een redundant gegeven #112
Comments
|
WaterML gebruikt hier het standaard OGC type CI_ResponsibleParty daarin is volgens mij verplciht dat je minimaal een van de drie attributen gebruikt: individualName, organisationName of positionName zie ook bijv http://wiki.esipfed.org/index.php/CI_ResponsibleParty |
|
Dat kan kloppen.. Maar dat kan nooit een reden zijn om architectuurprincipes te schenden. We hebben te maken met een uitwisselformaat. Om een voorbeeld te noemen: individualName zit kennelijk ook in dit uitwisselformaat, maar NL wetgeving stelt ook dat je uit privacy overweging heel voorzichtig moet zijn met namen. Een uitwisselformaat kan niet leidend zijn voor je architectuur. |
|
We hebben ervoor gekozen een profiel te maken op WaterML en dan was de consequentie de organisatienaam op te nemen. Ik snap je bezwaren, kan me daar alles bij voorstellen. |
|
Het hoeft niet verkeerd te zijn de organisatienaam op te nemen, we moeten
hem alleen niet laten aanleveren door de bronhouder maar zelf op basis van
KvK nummer ophalen bij het HR. Dit zou dus geen authentiek BRO gegeven
moeten zijn maar een verwijzing naar het HR.
…On Thu, Jun 11, 2020 at 12:02 PM AnnitaVijverberg ***@***.***> wrote:
We hebben ervoor gekozen een profiel te maken op WaterML en dan was de
consequentie de organisatienaam op te nemen. Ik snap je bezwaren, kan me
daar alles bij voorstellen.
Het is denk ik niet aan mij om te beslissen over het wel/niet afwijken van
de gekozen standaard. Lijkt me het beste als je dit met Frank bespreekt.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACYIP55NNMDE65IAY3SOPKLRWCTUTANCNFSM4N2SV3WA>
.
|
|
De organisatie naam is ook (terecht) niet als authentiek aangemerkt in de catalogus. In de LV is functionaliteit voorzien (voorheen organisatie en volmachten register) om namen en organisaties aan elkaar te koppelen. Op den duur zou dit gelinked kunnen worden aan het HR of de europese counterpart. Voor zou ik willen voorstellen de naam voorlopig weg te laten dit is volgens het originele md schema mogelijk: Voor de duidelijkheid: het huidige bro profiel <complexType name="CI_ResponsibleParty_PropertyType">
<!-- BRO changed sequence minOccurs from 0 to 1 -->
<sequence minOccurs="1">
<element ref="gmd:CI_ResponsibleParty"/>
</sequence>
<!-- BRO commented out:
<attributeGroup ref="gco:ObjectReference"/>
-->
<attribute ref="gco:nilReason"/>
</complexType>Waarschijnlijk ik er overheen, maar ik vind in "OGC 10-126r4" (water ML 2.0) ook geen aanleiding om dit te doen. |
|
Dit is wat je meestal terug vindt in documentatie:
Maar dat terzijde, voor nu kan ik wel akkoord gaan met het voorstel van Sjaak. |
|
Ah.. Ik denk dat de LV terughoudend moet zijn om namen aan (kvk / ecrn) nummers te koppelen. Dat is niet de taak van de LV maar o.a. van het HRN. Ik ben bang dat we een hele can-of-worms opentrekken als wij die koppeling ook gaan leggen. Overigens, bij andere objecten zijn we ook terughoudend met het verstrekken van kvk's aan de uitgifte kant. Alleen aanleverende partijen en bronhouders hebben inzage. Er is wel een onderscheid of deze partij een bedrijf is of bevoegd gezag. Misschien dat de keten architect hier ook eens naar moet kijken. |
Akkoord. We hebben een aantal keuzes hierin:
Mijn voorkeur gaat uit naar 2. |
|
De software van dataleveranciers en gebruikers die gebaseerd op WaterML zal een organisatienaam aanleveren respectivelijk verwachten die uitgeleverd te krijgen. Han had ook nog wat gevonden en ik weet niet of jij, Sjaak, dit ook hebt gezien:
Ik kan niet helemaal overzien wat dit betekent voor dataleveranciers die, op basis van hun WaterML software, wel een organisatienaam aanleveren. |
|
Sjaak, betekent afwijzen in jou voorstel dat de dataleverancier een meding krijgt dat zijn aanlevering niet verwerkt kan worden? Dat hij het opnieuw moet leveren? |
Dat is inderdaad het idee en het meest duidelijke. Negeren is een 2e optie, maar dan kan er een andere organisatie naam uit de uitgifte komen dan aangeleverd. Is dat wenselijk? Overigens vind ik het zeer vreemd dat een waterML standaard dit dicteert en dat wij als BRO hier geen verdere afweging inmaken. Ik weet ook niet of er in ons huidige werkveld maar één leverancier is die waterML (direct en op deze manier gebruikt en dan ook nog eens GLD implementeert). Ik denk dat daar echt een foute aanname achter zit wat client software ontwikkeling is en betekent. De BRO gaat nooit plug-and-play zijn voor aansluitende partijen omdat je in het koppelvlak waterML gebruikt. Er zullen altijd aanpassingen moeten gebeuren. Ik denk dat voor de meeste partijen momenteel dit zelfs het ontwikkelen van dergelijke software is. |
|
Voor nu wat mij betreft akkoord, dan moeten we adv ervaringen bij een volgende versie bekijken wat we hier uiteindelijk mee doen. |
|
WaterML is tot stand gekomen in een internationale context (OGC leden); veel landen hebben geen "Stelsel van Basisregistraties", dat is waarom "organisatienaam" in die context is het wellicht logisch dit attribuut op te nemen in de WaterML standaard. In Nederland hebben we echter wél een Stelsel van Basisregistraties, en ik denk dat voor de Nederlandse situatie het Stelsel van Basisregistraties leidend zou moeten zijn boven WaterML. In het stelsel geldt de "data bij de bron" gedachte, oftewel GEEN duplicatie van objecten en attributen en VERWIJZINGEN naar de bron op basis van unieke IDs (voor bedrijven verwijzingen vanuit registraties naar het NHR en mbv OID/KvK nummers). Dat "data bij de bron" architectuurprincipe is vrij essentieel, we moeten geen data dupliceren in de BRO die ook al in een bron register is opgenomen. Ergo, in alle registraties behalve NHR worden in principe alléén KVK nummers opgenomen, geen overige attributen! Bedrijfsnaam wordt bijgehouden in het NHR, en kan bij het NHR worden opgevraagd op basis van het KvK nummer. Dus ik zit op jouw lijn Sjaak, dat we dit gegeven moeten negeren, alleen het KVK opnemen in de BRO. Voor WaterML is dit attribuut echter toch aanwezig..., dus we kunnen of niets of iets invullen: Ad (1) Bij uitlevering kan evt (als we het veld bij inname leeg laten) vanuit de uitlever service on the fly een call worden gedaan naar het NHR om de bedrijfsnaam op te halen en deze dan on the fly te includen in het veld. Dat creëert echter wel een sterke afhankelijkheid van het NHR, en is een beetje een ongebruikelijke manier van doen... We kunnen die taak ook gewoon bij de afnemer leggen natuurlijk, maar dan zadel je die op met werk (men levert een bedrijfsnaam aan, die wordt er door de BRO afgesloopt, en bij afname moet je em er dan zelf weer aanplakken...) Mijn eigen gevoel zegt nu het veld leeg te laten. Het veld bij uitgifte invullen obv een call naar het NHR, zou kunnen... wel zo prettig voor afnemers. In geval van invullen van een KVK nummer bij bedrijfsnaam:
Op deze manier zit in de BRO bij bedrijfsnaam een KVK nummer. Staat ie er dus 2x in... niet optimaal (onnodige duplicatie) Ik denk dus dat leeglaten de betere optie is, of het attribuut bedrijfsnaam verwijderen uit WaterML... maar dan ben je niet meer compliant met deze standaard verwacht ik... Is "Bedrijfsnaam" in WaterML trouwens een verplicht veld? |
|
Hoi Erik, Sjaak,
Wat Erik voorstelt het wel aanleveren van het veld organisatienaam maar
alleen een lege string aanleveren is ook wat Han eerder via de mail heeft
voorgesteld. Een lege string is iets anders dan geen waarde natuurlijk maar
op basis van de huidige catalogus uitvoerbaar. Je slaat het gegeven dan
niet op maar houdt je wel aan de uitwisselstandaard. Dat lijkt mij ook de
beste oplossing. We zullen hier wel een duidelijke werkafspraak over moeten
maken.
Voor uitgifte vindt ik de eerste oplossinghet mooiste: de BRO vult hem
doormiddel van een call naar de KvK. Ik snap echter ook de praktische
implementatie bezwaren hiervan. Misschien kunnen we de URI naar de
bedrijfsnaam resource in de KVK API erin zetten? dat gaat iets verder dan
twee keer een KvK leveren en maakt het ophalen door de afnemer wel
eenvoudiger.
groeten
Frank
…On Thu, Jun 25, 2020 at 3:04 PM erikvanderzee ***@***.***> wrote:
WaterML is tot stand gekomen in een internationale context (OGC leden);
veel landen hebben geen "Stelsel van Basisregistraties", dat is waarom
"organisatienaam" in die context is het wellicht logisch dit attribuut op
te nemen in de WaterML standaard.
In Nederland hebben we echter wél een Stelsel van Basisregistraties, en ik
denk dat voor de Nederlandse situatie het Stelsel van Basisregistraties
leidend zou moeten zijn boven WaterML. In het stelsel geldt de "data bij de
bron" gedachte, oftewel GEEN duplicatie van objecten en attributen en
VERWIJZINGEN naar de bron op basis van unieke IDs (voor bedrijven
verwijzingen vanuit registraties naar het NHR en mbv OID/KvK nummers). Dat
"data bij de bron" architectuurprincipe is vrij essentieel, we moeten geen
data dupliceren in de BRO die ook al in een bron register is opgenomen.
Ergo, in alle registraties behalve NHR worden in principe alléén KVK
nummers opgenomen, geen overige attributen! Bedrijfsnaam wordt bijgehouden
in het NHR, en kan bij het NHR worden opgevraagd op basis van het KvK
nummer.
Dus ik zit op jouw lijn Sjaak, dat we dit gegeven moeten negeren, alleen
het KVK opnemen in de BRO. Voor WaterML is dit attribuut echter toch
aanwezig..., dus we kunnen of niets of iets invullen:
(1) leeg laten (dat zou dan in de BRO standaard opgenomen moeten worden,
want we willen voor dit attribuut geen waarde (bedrijfsnaam) in de BRO
hebben) of
(2) bij het veld bedrijfsnaam óók een KVK nummer invullen (dat zou dan in
de BRO standaard opgenomen moeten worden); beetje gek maar houdt het
stelsel wel consistent.
Ad (1) Bij uitlevering kan evt (als we het veld bij inname leeg laten)
vanuit de uitlever service on the fly een call worden gedaan naar het NHR
om de bedrijfsnaam op te halen en deze dan on the fly te includen in het
veld. Dat creëert echter wel een sterke afhankelijkheid van het NHR, en is
een beetje een ongebruikelijke manier van doen... We kunnen die taak ook
gewoon bij de afnemer leggen natuurlijk, maar dan zadel je die op met werk
(men levert een bedrijfsnaam aan, die wordt er door de BRO afgesloopt, en
bij afname moet je em er dan zelf weer aanplakken...)
Ad (2) Het staat een afnemer NA afname uit de BRO vrij om een bedrijfsnaam
uit het NHR te halen en daarmee de KVK waarde van het attribuut
Bedrijfsnaam te overschrijven... maar het lijkt me een wat vreemde situatie
maar het kan wel.
Mijn eigen gevoel zegt nu het veld leeg te laten. Het veld bij uitgifte
invullen obv een call naar het NHR, zou kunnen... wel zo prettig voor
afnemers.
In geval van invullen van een KVK nummer bij bedrijfsnaam:
- Voorafgaand aan levering aan de BRO kan de bedrijfsnaam ("fugro")
door aanleverende "grondwatersoftware" van een dataleverancier worden
vervangen door een KVK nummer [via aanroep NHR]
- Na afname kan een KVK nummer bedrijfsnaam door afnemende
"grondwatersoftware" van een dataleverancier weer worden vervangen door een
bedrijfsnaam ("fugro") [via aanroep NHR]
Op deze manier zit in de BRO bij bedrijfsnaam een KVK nummer. Staat ie er
dus 2x in... niet optimaal (onnodige duplicatie)
bedrijfsID = KVKnummer
bedrijfsnaam = KVKnummer
Ik denk dus dat leeglaten de betere optie is, of het attribuut
bedrijfsnaam verwijderen uit WaterML... maar dan ben je niet meer compliant
met deze standaard verwacht ik... Is "Bedrijfsnaam" in WaterML trouwens een
verplicht veld?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACYIP5YAJB675LLCR6CMBWLRYNDMNANCNFSM4N2SV3WA>
.
|
Dan maak je afhankelijk van de API die, mogelijkerwijs veranderlijk is in de toekomst. Voor ECRN's heb je nog steeds geen oplossing. Een lege string aanleveren kan, zoals eerder besproken, maar de vraag is wat doe je als er geen lege
Dus..
Met betrekking to het punt van Erik:
Ik stel mezelf voor dat het ophalen van een naam een typische functionaliteit is van de client software. We moeten vermijden dat we de rol in nemen die ook door de software leveranciers als 'feature' of extra kan worden ingevuld. |
|
Ik moet nu een keuze maken in de afronding van GLD. De keuze is als volgt:
|
|
Dat lijkt me inderdaad de meest zuivere oplossing Sjaak; document niet
innemen en foutmelding teruggeven als het veld niet leeg is. Aan
uitgiftekant, wellicht kan worden gewerkt met een parameter
CompanyName=TRUE|FALSE in de API request. Bij TRUE vult de BRO de
bedrijfsnaam in obv een call naar het NHR, bij FALSE blijft het veld gewoon
leeg.
Maar zoals gezegd, het creëert een afhankelijkheid van/met het NHR;
wellicht beter om de MVP aanpak hier te hanteren en in eerste instantie
gewoon ook leeg uit te leveren, dit zou mijn voorkeur hebben. En dan kijken
we wel even wat de reactie vanuit gebruik is.
Groeten, Erik
…On Wed, Jul 1, 2020 at 3:16 PM Sjaak Derksen ***@***.***> wrote:
Ik moet nu een keuze maken in de afronding van GLD.
De keuze is als volgt:
- Bij het aanleveren van een niet lege organisatienaam volgt er een
brondocument fout met een beschrijving:
*Uitvoerder.organisatienaam (Operator.name) waarde is niet correct:
moet gelijk zijn aan leeg.*
- Aan jullie om hier een werk-afspraak op te definiëren.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMDDLBURAM2CYL6FNXQISE3RZMZLJANCNFSM4N2SV3WA>
.
|
|
Wat mij betreft akkoord Sjaak |
|
Ook akkoord van mij, ik zal de werkafspraak in gang gaan zetten.
groeten
Frank
…On Thu, Jul 2, 2020 at 4:10 PM AnnitaVijverberg ***@***.***> wrote:
Wat mij betreft akkoord Sjaak
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#112 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACYIP525JBJS5BXKB4TZ2WLRZSINLANCNFSM4N2SV3WA>
.
|
Type issue
Implementatie
Waar
5.3.7.2 organisatienaam
Samenvatting
Het expliciet opgeven van een organisatie naam leid tot inconsistente data in de toekomst en is in strijd met de huidige architectuur.
Oplossingsrichting
Werkafspraak: maak de organisatie naam optioneel en verwijder uit de volgende versie. Een identificerend gegeven is voldoende. Een 2e zorgt voor redundantie en foutgevoeligheid.
The text was updated successfully, but these errors were encountered: