Op dit moment bevat de XSD een complexType genaamd informatieobjectGegevens. De enige functie van deze gegevens is om aan te geven naar wat voor soort informatieobject gerefereerd wordt:

<xs:simpleType>
    <xs:restriction base="xs:string">
        <xs:enumeration value="Voorstel"/>
        <xs:enumeration value="Motie"/>
        <xs:enumeration value="Amendement"/>
        <xs:enumeration value="Besluitsvormingsstuk"/>
        <xs:enumeration value="Toezegging"/>
        <xs:enumeration value="Mededeling"/>
        <xs:enumeration value="Vraag"/>
        <xs:enumeration value="Antwoord"/>
        <xs:enumeration value="Ingekomen stuk"/>
    </xs:restriction>
</xs:simpleType>

Dit zijn niet eens alle soorten informatieobjecten die VNG's ORI erkent. Zo bestaan er ook nog verschillende types moties, zoals een motie van wantrouwen, treurnis, etc. (zie ook issue #44).

Problemen van deze aanpak

Onze huidige aanpak heeft een aantal mankementen.

Inflexibel: In de praktijk is het aantal (sub)soorten informatieobjecten wat binnen een vergadering functioneert veel groter dan nu in de XSD erkent wordt. Met onze huidige aanpak — een vaste waardelijst — halen we dus een hoop werk op onze schouders (bijv. wanneer we een verzoek ontvangen deze lijst uit te breiden). De enige manier om iets aan deze lijst toe te voegen is namelijk om een nieuwe versie van de XSD uit te brengen, met als bijkomend nadeel dat er dan snel meerdere ORI XSDs in omloop zullen zijn. (NB: Notubiz heeft ons eerder op dit probleem gewezen)
Relevantie: Je zou kunnen stellen dat wat voor soort informatieobject tijdens een agendapunt behandeld werd, een domein specifiek gegeven is, en daarom in ORI XML thuishoort. Anderzijds zou je kunnen stellen dat dit informatie over een informatieobject betreft, en daarom binnen MDTO's <classificatie> thuishoort. Immers, de naam van een informatieobject slaan we ook niet in ORI XML op, precies omdat het informatieobject metadata is.

Mijn inziens dealen we hier dus met een grijs gebied — bovenstaande informatie lijkt op twee plekken te passen. Natuurlijk begrijp ik dat men bij het raadplegen van een videotuul wilt zien om wat voor vergaderstuk het gaat, maar de vraag wat voor informatie je wil zien is een andere vraag dan waar welke informatie thuishoort.

Toegevoegde complexiteit: De XSD en bijhorende documentatie worden iets complexer door een specifiek verwijsmechanisme voor informatieobjecten te creëren. Dit is niet het meest zwaarwegende nadeel, maar het mag gezegd worden dat de XSD naar een UML-achtig plaatje omzetten een onnavolgbare wirwar van pijltjes gaat opleveren:

(link naar de complete afbeelding)

En dit zijn nog lang niet alle pijltjes die van ORI naar MDTO lopen. Punt is dat dit plaatje — en tot op een zekere hoogte, de XSD — een stuk overzichtelijker wordt als we informatieobject classificering over de schutting gooien.

Voorstel: een open waardelijst

Ik denk dat we alle bovengenoemde problemen kunnen oplossen door met een externe, open waardelijst te gaan werken, en dan bij voorkeur een bestaande. Dat wil zeggen: in plaats van een waardelijst voor te kauwen binnen onze XSD, moet men gaan refereren naar een waardelijst buiten ons project. Het resultaat hiervan is dat de bovengenoemde enumeratie uit de XSD gesloopt wordt. MDTO doet iets vergelijkbaars: in plaats van alle mogelijke waardes van te voor uit te schrijven (vaak een onmogelijke of onwenselijke taak), verwacht MDTO dat er naar informatie op andere plekken verwezen wordt.

Het heeft mijn voorkeur de referentie naar deze waardelijst op te namen via MDTO's <classificatie>. Zodoende wordt de classificatie van een informatieobject een taak voor MDTO, waar, zoals eerder genoemd, best wat voor te zeggen is.

Er bestaat al een uitstekende kandidaat voor zo'n waardelijst, namelijk de PLOOI documentsoorten lijst, een onderdeel van een serie standaarden voor overheidsinformatie:

PLOOI documentsoort | vergaderstuk | agenda
PLOOI documentsoort | vergaderstuk | besluitenlijst
PLOOI documentsoort | vergaderstuk | ingekomen stuk
PLOOI documentsoort | vergaderstuk | vergaderverslag

Het enige probleem is dat deze waardelijst nog een beetje karig is. Op dit moment missen moties en motie-subtypes bijvoorbeeld nog. Ik ben meer dan bereid hier over in conclaaf te gaan met de beheerders, tho. Uiteindelijk is dit voordelig voor zowel ons project als het TOOI project.

TOOI heeft bovendien het probleem van subtypes al opgelost (zie #44). Voor motie subtypes stel ik me bijvoorbeeld iets als dit voor:

PLOOI documentsoort | vergaderstuk | besluitvormingsstuk | motie | wantrouwen
PLOOI documentsoort | vergaderstuk | besluitvormingsstuk | motie | voorsel
PLOOI documentsoort | vergaderstuk | besluitvormingsstuk | motie | afkeuring
PLOOI documentsoort | vergaderstuk | besluitvormingsstuk | amendement
PLOOI documentsoort | vergaderstuk | vraag | schriftelijk
PLOOI documentsoort | vergaderstuk | vraag | mondeling
...

In XML vorm is het eind resultaat van het voorstel iets als dit:

<ORI>
    <stemming>
        ...
        <heeftBetrekkingOpBesluitvormingsstuk>
            <!-- dit besluitvormingsstuk  wordt in MDTO verder beschreven-->
            <verwijzingID>abcd-1234</verwijzingID>
        </heeftBetrekkingOpBesluitvormingsstuk>
    </stemming>
</ORI>

<MDTO>
    <informatieobject>
        <identificatie>
            <identificatieKenmerk>abcd-1234</identificatiekenmerk>
            ...
        </identificatie>
        <classificatie>
            <begripLabel>Motie van treurnis</begripLabel>
        <begripCode>c_bf0f9c95</begripCode>
        <begripBegrippenlijst>
                <verwijzingNaam>PLOOI documentsoorten</verwijzingNaam>
         </begripBegrippenlijst>
        </classificatie>
     <informatieobject>
</MDTO>

Natuurlijk wel goed om dan te documenteren dat dit de verwachte aanpak is, en eventueel hoe nieuwe waardes aan bovengenoemde PLOOI begrippenlijst kunnen worden toegevoegd.

Nadelen van dit voorstel

Ik kan me goed voorstellen dat wanneer je een videotuul/raadsinformatie wilt raadplegen, je wilt zien om wat voor soort vergaderstuk het gaat. Dit voorstel maakt dat niet onmogelijk, maar wel omslachtiger, omdat een computerprogramma dan zowel ORI als MDTO xml moet doorzoeken.

Dit "nadeel" bestaat echter al binnen de huidige vorm van de XSD. Je wilt immers ook kunnen zien wat de (bestands)naam van een relevant informatieobject is, en deze informatie slaan we nu ook alleen maar in MDTO op.

Regionaal-Archief-Rivierenland / ORI-XSD

Verplaats informatieobject classificering naar TOOI waardelijst #49

Problemen van deze aanpak

Voorstel: een open waardelijst

Nadelen van dit voorstel