Stel men in staat om informatieobjecten via MDTO te defineeren

[rien333]

Tijdens een discussie met de werkgroep kwam de behoefte naar voren om informatieobjecten niet via het ORI-model, maar via verwijzingen naar MDTO-native informatieobjecten op te nemen.

Opties

Een goed voorstel, wat mij betreft, maar dan moeten we wel een keuze maken tussen twee opties:

1. Enforce dat iedereen informatieobjecten altijd mbv MDTO definieert
2. Sta zowel ORI-native als MDTO-native informatieobjecten toe

Mijn voorkeur gaat uit naar optie nr. 1 - om the zen of python te citeren:

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

Ik denk ook dat in optie nr. 1 mogelijk een oplossing voor issue #19 in schuil gaat, in de zin dat het ons in staat stelt informatieobjecten uit de ORI XSD te slopen.

Mochten we voor optie nr. 1 gaan dan is het MDTO's <classificatie> element een goede kandidaat om op te slaan om wat voor soort informatieobject (voorstel, amendement, etc.) het gaat. (met oog op de test sets ben ik echter bang dat deze info zelden wordt meegeleverd EDIT: deze data is er soms wel)

Implementatie

In beide gevallen hebben we een robust verwijzing mechanisme nodig voor het verwijzen naar externe MDTO (.xml) bestanden. Als we voor optie nr. 2 gaan is het tijdens het maken van verwijzingen naar informatieobjecten bijvoorbeeld van belang gebruikers te forceren om aan te geven of het om een ORI of extern gedefinieerd informatieobject gaat.

[rien333]

Als we dit doen, kunnen sommige objecten die alleen maar bestaan om MDTO-achtige functies te uit te voeren (zoals <indiener>, wat in MDTO eigenlijk <betrokkene> is) ook weg. Dit maakt de XSD stukken simpeler.

EDIT:

Oke dit valt toch wel mee; natuurlijkPersoon blijft twee pijltjes hebben (namelijk ook heeftBehandelendAmbtenaar)

[rien333]

Oke dit valt toch wel mee; natuurlijkPersoon blijft twee pijltjes hebben (namelijk ook heeftBehandelendAmbtenaar)

Dit is mogelijk een probleem, aangezien een terugkerend feedback punt is dat men natuurlijkPersoon onder aanwezigeDeelnemer wil zien.

Er zijn twee manieren om hier mee te dealen:

1. Een extra criteria toevoegen over wanneer iets wel/niet genest wordt. Dit zou bijvoorbeeld kunnen zijn: "nest wanneer er een verplichte 1:1 relatie is tussen objecttypes".

• En dan nog een keer goed in de (UML) documentatie uitlichten wanneer iets genest moet worden. (bijv. door in het UML model bepaalde pijltjes dik te drukken/een andere kleur te geven)

2. De status quo behouden, en aanwezige deelnemers en natuurlijk personen aan elkaar koppelen via verwijzingen.

Ik neig naar optie 2. De enige reden waarom mensen willen nesten heeft iets te maken met vermeende weergave problematiek. Echter, weergave van ORI xml moet IMO in het edepot worden opgelost (iets wat ook altijd kan). Geen enkel mens wil namelijk XML zien/lezen, of het nou veel nested of niet. Sterker nog: je wilt nooit rauwe data in een eDepot dumpen, qua gebruiksvriendelijkheid. Elke eDepot leverancier maakt daarom een vertaalslag, om bijv. een jpeg/png/wacz/MDTO bestand mooi te presenteren.

En optie 1 doorvoeren kost iets meer "maintance" werk op de lange termijn (want het creëert extra uitleg)

[lmasrarsaml]

Om te komen tot een goede splitsing tussen ORI en MDTO wat betreft informatieobjecten, zal de huidige relatie tussen objecttypen die gaan over informatieobjecten (doelbestemming: MDTO) en objecttypen die gaan over raadsinformatieobjecten (doelbestemming: ORI) nader bekeken moeten worden, zodat een knip kan worden gemaakt die zo min mogelijk informatieverlies tot gevolg heeft.

Vanuit verschillende ORI-elementen wordt er verwezen naar een informatieobject of een type informatieobject:

• stemming --> heeftBetrekkingOp --> besluitvormingsstuk
• agendapunt --> heeftAlsBijlage --> informatieobject
• vergadering --> heeftAlsBijlage --> informatieobject
• vergadering --> isGenotuleerdIn --> informatieobject
• indiener --> heeftIngediend --> informatieobject
• mediabron --> isVastgelegdIn --> informatieobject (nu niet aanwezig maar nuttig om toe te voegen)

Binnen ORI is er één ouder-objecttype informatieobject aanwezig, met drie lagen aan gespecialiseerde typen informatieobject:
Laag 1: enkelvoudig informatieobject, wat een generalisatie is van laag 2.
Laag 2: ingekomen stuk, toezegging, mededeling, vraag, antwoord en besluitvormingsstuk (de laatste is een generalisatie van laag 3).
Laag 3: voorstel, amendement en motie.

Kijken we naar de attributen die bij deze getrapte objecttypen horen, dan zijn er enkele categorieën zichtbaar (binnen deze objecttypen):

• een <omschrijving>, <inhoud> of <toelichting>-attribuut (enkelvoudig informatieobject, toezegging, mededeling, vraag, antwoord> en besluitvormingsstuk);
• een <relatie>-attribuut (antwoord bij vraag; amendement bij amendement; amendement bij voorstel);
• een <type>-attribuut (motie en vraag);
• een <actor>-attribuut (voorstel, besluitvormingsstuk);
• een <event>-attribuut (besluitvormingsstuk);
• een <taal>-attribuut (enkelvoudig informatieobject).

We willen deze veelvoud aan objecttypen en bijbehorende attributen die gaan over informatieobjecten feitelijk platslaan tot één referentiemechanisme, waarbij de informatie uit het model zoveel mogelijk overeind blijft. Een stapsgewijs voorstel:

• het in elkaar schuiven van informatieobject en enkelvoudig informatieobject. De attributen die in die twee objecttypen staan vermeld, vinden inhoudelijk allemaal een plek binnen MDTO (Voorstel is om een kleine mapping op te stellen voor in de gebruikshandleiding waarin ORI-attributen naar MDTO-attributen worden omgezet);
• het behandelen van voorstel, amendement en motie als <choice>-attributen binnen besluitvormingsstuk, vanuit de gedachte dat een besluitvormingsstuk altijd een voorstel, amendement of motie is en niet alleen een besluitvormingsstuk kan zijn;
• het toevoegen van de getrapte objecttypen als <choice>-attributen aan het referentiemechanisme, waarbij besluitvormingsstuk dus feitelijk een nested <choice> wordt.

De meest robuuste manier om naar MDTO-bestanden te verwijzen lijkt me om identificatie te gebruiken, een verplicht kenmerk binnen MDTO. Deze bestaat uit identificatiekenmerk (verplicht) en identificatiebron (verplicht indien bekend). Om daarnaast ook het soort informatieobject (objecttype) op te nemen kan het element <choice> worden gebruikt. Dat levert bijvoorbeeld het volgende verwijzingsmechanisme op:

<xsd:complexType name= "gerelateerdInformatieobject">
   <sequence>
      <identificatie>
         <identificatieKenmerk>
         <identificatieBron>
      </identificatie>
      <informatieobjectType>
         <choice>
            <xsd:element name="motie" type="motie"/>
            <xsd:element name="amendement" type="amendement"/>
            <xsd:element name="voorstel" type="voorstel"/>
            <xsd:element name="ingekomenStuk" type="ingekomenStuk"/>
            <xsd:element name="vraag" type="vraag"/>
            <xsd:element name="antwoord" type="antwoord"/>
            <xsd:element name="toezegging" type="toezegging"/>
            <xsd:element name="mededeling" type="mededeling"/>
         </choice>
      </informatieobjectType>
   </sequence>
</complexType>

Hoor graag waar dit mechanisme nog tekort schiet. De geneste <choice> binnen besluitvormingsstuk moet nog worden gebouwd, en in dit mechanisme zijn de attributen van de objecttypen niet geüniformeerd maar blijven ze zoals ze in het informatiemodel zijn. Eventueel moet dan nog ergens de naam van het objecttype worden toegevoegd als attribuut, zodat duidelijk is wat het type is (en niet alleen de attributen onder het type worden opgenomen).

Overigens: het zou voor de toepassing van ORI niet moeten uitmaken of een partij informatieobjectgegevens in TMLO/ToPX of in MDTO wil uitdrukken.

[rien333]

In grote lijnen akkoord!

Ik twijfel ten eerste nog wat de beste naam is voor de nieuwe complexType die je voorstelt — gerelateerdInformatieobject klinkt prima, maar we kunnen ook kiezen voor informatieobjectGegevens, omdat het eigenlijk over een verzameling beschrijvende gegevens gaat (mdto hanteert een zelfde 'naming convention', btw).

het behandelen van voorstel, amendement en motie als -attributen binnen besluitvormingsstuk, vanuit de gedachte dat een besluitvormingsstuk altijd een voorstel, amendement of motie is en niet alleen een besluitvormingsstuk kan zijn;

Volgens mij klopt dit niet, omdat een stemming over een besluitvormingsstuk kan gaan:

Om dingen vervolgens niet al te complex te maken kunnen we er ook voor kiezen om helemaal geen genestede choice te maken:

<xsd:complexType name="gerelateerdInformatieobject">
   <sequence>
      <identificatie>
         <identificatieKenmerk>
         <identificatieBron>
      </identificatie>
      <informatieobjectType>
         <choice>
            <xsd:element name="besluitvormingsstuk" type="besluitvormingsstuk"/> <!-- nieuwe toevoeging-->
            <xsd:element name="motie" type="motie"/>
            <xsd:element name="amendement" type="amendement"/>
            <xsd:element name="voorstel" type="voorstel"/>
            <xsd:element name="ingekomenStuk" type="ingekomenStuk"/>
            <xsd:element name="vraag" type="vraag"/>
            <xsd:element name="antwoord" type="antwoord"/>
            <xsd:element name="toezegging" type="toezegging"/>
            <xsd:element name="mededeling" type="mededeling"/>
         </choice>
      </informatieobjectType>
   </sequence>
</complexType>

Also, als we dit letterlijk zo implementeren slopen we uiteindelijk vrij weinig omtrent informatieobjecten uit ORI. Ik denk dat we 'm ook zo kunnen doen:

<informatieobjectType>
   <xsd:restriction base="xsd:string">
      <xsd:enumeration value="besluitvormingsstuk"/>
      <xsd:enumeration value="motie"/>
      <xsd:enumeration value="voorstel"/>
      <xsd:enumeration value="vraag"/>
      ...
   <xsd:restriction base="xsd:string">
</informatieobjectType>

Natuurlijk verlies je dan bijv. de motie-specifiecke gegevens die je nu in ORI kan opnemen, maar ik vermoed dat dat soort gegevens ook best makkelijk naar MDTO te mappen zijn.

Overigens: het zou voor de toepassing van ORI niet moeten uitmaken of een partij informatieobjectgegevens in TMLO/ToPX of in MDTO wil uitdrukken.

Hangt een beetje van de implementatie af, denk ik. In any case voel ik er wel wat voor moderniteit af te dwingen, en ons zelf niet met meer werk op te zadelen door ook met legacy formaten te willen dealen.

Stel bijvoorbeeld dat we <identificatie> uit MDTO stelen, zodat we zelf niet opnieuw het wiel hoeven uit te vinden. Dat kan via XML's namespaces functionaliteit. Dan krijg je iets als dit qua XML:

<ORI xmlns="https://vng.nl/projecten/open-raadsinformatie" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://vng.nl/projecten/open-raadsinformatie https://github.com/Regionaal-Archief-Rivierenland/ORI-XSD/releases/download/v0.0.5/ORI.xsd" xmlns:mdto="https://www.nationaalarchief.nl/mdto">

<vergadering>
    <ID>abcd-1234</ID>
    ...
    <isGenotuleerdIn>
        <mdto:identificatie>
            <mdto:identificatieKenmerk>xyz-5678</mdto:identificatieKenmerk>
            <mdto:identificatieBron>blah blah</mdto:identificatieBron>
        </mdto:identificatie>
        <!-- iets kan trouwens ook een generic "informatieobject" zijn -->
        <informatieobjectType>informatieobject</informatieobjectType>
    </isGenotuleerdIn>
</vergadering>

We hoeven natuurlijk niet MDTO's identificatieGegevens te stelen. Misschien is het zelfs beter om dat niet te doen, omdat ik het nut van <identificatieBron> in deze context niet helemaal snap.

En als we dat wel doen, wat is dan een goede waarde voor <identificatieBron>? MDTO stelt dat het om de "herkomst van het kenmerk" gaat. Is de herkomst hier het originele XML bestand, of de naam van het RIS systeem?

[lmasrarsaml]

Om antwoord te geven op je punten:

• informatieobjectGegevens kan ook goed als naam, ik had gerelateerdInformatieobject gekozen zodat in de naam ook de relatie duidelijk was. Maar als we het als complexType gaan hanteren, dan kan dat ook worden afgevangen door het attribuut dat de relatie legt <gerelateerdInformatieobject> te noemen, met als type informatieobjectGegevens.
• goed punt over de relatie stemming met besluitvormingsstuk, dan gaat die nested choice niet werken.
• ik voel er zelf wel wat voor om de gegevens die wat zeggen over de relatie van het informatieobject ten opzichte van het bestuurlijke besluitvormingsproces weergeven, op te nemen in ORI. Daar horen ze inhoudelijk gezien ook bij. Lijkt me een goede om in de werkgroep te bespreken.
• identificatieBron had ik toegevoegd om dezelfde identificatieregels te hebben als MDTO ze stelt. Strikt genomen hebben we bron niet nodig, behalve als er over meerdere bronnen heen dezelfde identificatiegegevens worden gehanteerd. Maar dan alsnog zal het waarschijnlijk binnen verschillende leveringen worden verwerkt en niet voor problemen zorgen. Anyway, we kunnen hem toevoegen en niet verplicht stellen, dan is dit potentiële probleem alvast opgelost. Ik ben geen voorstander van het opnemen van XML-elementen uit een andere XSD.