Voorstel om informatieobjecten te kunnen relateren #2240
Replies: 12 comments 2 replies
-
|
Dit lijkt me qua structuur een goed en werkbaar voorstel. Het lijkt me wel verstandig om in de tabel met mogelijke waarden ook een generieke waarde op te nemen Van de voorgestelde waarde |
Beta Was this translation helpful? Give feedback.
-
|
Dit voorstel is kort besproken in een meeting op 17-10-2023. Uitkomst daarvan is o.a. dat we duidelijk onderscheid moeten maken in de definities van de concepten "versie" en "variant". Zoals afgesproken doe ik een voorstel voor deze definities binnen de DRC. DefinitiesVersie Variant Impact op dit voortelHet concept Bij het stempelen van documenten is de consensus dat dit valt onder de definitie van versies en niet van varianten (zie ook de opmerking van 31 mei) en daarmee al gedekt is door de bestaande werking van de DRC, mede door wijziging #2241 die beschikbaar is gekomen in DRC 1.4.0. Daarom komt de behoefte aan het relatietype Het is daarmee niet gezegd dat aan elkaar gerelateerde informatieobjecten in alle gevallen varianten van elkaar zijn, er zijn ook andere relaties denkbaar (bijvoorbeeld "is_vervangen_door" of "is_beantwoord_met"), maar het zijn in elk geval nooit versies van elkaar in de terminologie van de DRC. |
Beta Was this translation helpful? Give feedback.
-
|
Na een beperkte zoekactie kan ik niet vaststellen dat gebruik van het begrip 'variant' in relatie tot documenten gebruikelijk is. De noodzaak voor onderscheid tussen versies en varianten ontstaat echter vooral door de smalle definitie in het RGBZ ("aanduiding van de bewerkingsfase van het informatieobject"). Een alternatief is voor het introduceren van het begrip 'variant', is het uitgaan van de bredere definitie van 'versie' zoals gehanteerd binnen Dublin Core en door overerving ook MDTO ("informatieobject dat een versie of aanpassing is van een ander (informatie)object"). Dit betekent wel dat voor de attribuutsoort 'versie' in de Documenten API expliciet moet worden gemaakt dat die betrekking heeft op de 'bewerkingstijdslijn'. Hernoeming hiervan ligt daarbij voor de hand. Toegevoegde rationale: voordeel van dit alternatief kan zijn dat we geen inspanning hoeven doen om een conceptueel juiste, maar 'synthetische' scheidslijn tussen twee concepten aan te brengen die de buitenwereld als één ziet: het zijn 'gewoon' allemaal versies, waarbij de relatie duidelijk maakt hoe het karakter van een specifieke versie ten opzichte van hetgeen waarvan die is afgeleid begrepen moet worden. |
Beta Was this translation helpful? Give feedback.
-
|
Ondanks dat ik snap dat de term Zou |
Beta Was this translation helpful? Give feedback.
-
Als je de bredere definitie kiest en de bestaande vergeet is er nog maar één betekenis van het woord versie en zijn we 'in sync' met andere standaarden ;)
Dat is een synoniem van representatie. De tekst die ik hier schrijf kan ik ook representeren in een Pdf- of Wordbestand, maar omdat het woord representatie in zich houdt dat de inhoud van de representatie ten opzichte van hetgeen wordt gerepresenteerd niet verandert, geldt dat niet voor bijvoorbeeld een versie van deze tekst waar ik alle leestekens en lidwoorden uit heb geschrapt. Een geanonimiseerde versie zou ik dientengevolge niet beschouwen als verschijningsvorm of representatie van het origineel, waarmee dat begrip volgens mij niet het (hele) voorgestelde gebruik van variant afdekt. |
Beta Was this translation helpful? Give feedback.
-
Consequentie is dan, lijkt me, dat in het voorstel voor statussen #2242 er meerdere versies van hetzelfde informatieobject geldig kunnen zijn (overeenkomend met de 'oorspronkelijke' variant en de 'afgeleide' varianten). Doorzien we dit en kunnen we dit tacklen? |
Beta Was this translation helpful? Give feedback.
-
|
Naar aanleiding van gesprekken die gevoerd zijn in Nieuwegein en voortschrijdend inzicht heb ik het API-ontwerp voor het relateren van informatieobjecten aangepast, zie redoc. De naamgeving in deze nieuwe versie is consistent gemaakt met de naamgeving van het RGBZ waarin zaken aan elkaar gerelateerd kunnen worden met de relatie "heeft relevante andere".
Op dezelfde manier modelleren we de relatie "heeft relevante andere" tussen informatieobjecten:
In het volgende voorbeeld leggen we een relatie tussen twee documenten waarbij
{
"informatieobject": "<doc1>",
"relevantAnderInformatieobject": "<doc2>",
"aardRelatie": "publiceerbare_variant"
}Deze relatie wordt als conveniance ook zichtbaar gemaakt in de resource
Het attribuut "richtingRelatie" wordt gebruikt om de waarde van het attribuut "aardRelatie" in de goede richting te lezen. In de aanvullende specificatie van de standaard leggen we vast dat het attribuut
In de toekomst kan deze tabel eventueel worden uitgebreid met nieuwe waarden als daar behoefte aan is. |
Beta Was this translation helpful? Give feedback.
-
|
Naar aanleiding van gesprekken met VNG-collega's heb ik het voorstel weer wat bijgeslepen. Ten eerste is de naamgeving van de modellering aangepast:
De relatieklasse In de aanvullende specificatie van de standaard leggen we vast dat het attribuut "relatie" de volgende waarden mag hebben.
In de toekomst kan deze tabel eventueel worden uitgebreid met nieuwe waarden als daar behoefte aan is. In het volgende voorbeeld leggen we vast dat
De notatie Deze relatie wordt als conveniance ook zichtbaar gemaakt in de resource
De notatie
|
Beta Was this translation helpful? Give feedback.
-
|
Samenvattend zijn dit de verschillen:
|
Beta Was this translation helpful? Give feedback.
-
|
Inmiddels is het nieuwe voorstel uitgewerkt in de OAS, zie redoc. Graag jullie feedback of goedkeuring! Als dat binnen is, zal ik ook het expand-mechanisme toevoegen. |
Beta Was this translation helpful? Give feedback.
-
|
De relatie 'is_een_geanonimiseerde_variant_van' vind ik niet helemaal gelukkig. Anonimiseren is maar één van de gronden waarop (delen van) documenten worden gelakt. Op deze manier zou je voor elke uitzonderingsgrond een aparte relatie moeten kunnen leggen. En een document kan meer dan één uitzonderingsgrond bevatten. Nu zijn persoonsgegevens in de praktijk de meest voorkomende grond, maar dat wil niet zeggen dat we daar het model op moeten baseren. De publiceerbare_variant relatie was beter. Maar ook dit past niet helemaal, omdat sommige documenten ongelakt gepubliceerd kunnen worden. Dan zou ik 'is_een_gelakte_variant_van' als relatienaam willen voorstellen. De discussie of een informatieobject een enkelvoudiginformatieobject moet zijn, hoort hier ook bij. Want een document waarvan een gelakte variant bestaat, zou volgens mij in MDTO niet enkelvoudig zijn. Het informatieobject zelf bevat één of meer bestanden. Waarbij de gelakte versie een (hiërarchische) relatie heeft met het 'formele' informatieobject. Het hernoemen in het informatiemodel lijkt me onjuist. In RGBZ-termen zou ik eerder verwachten dat een document met een gelakte versie een samengesteld document is. Of zie ik dat verkeerd? Tot slot zou het een mooie uitbreiding zijn om naast het vastleggen van gelakte documenten ook bij het informatieobject de uitzonderingsgronden voor publicatie te kunnen maken. Dan is ook in de keten de reden duidelijk dat een informatieobject niet (volledig) kan worden vrijgegeven. |
Beta Was this translation helpful? Give feedback.
-
Intern hebben we hierover ook discussie gehad. Inderdaad drukt de relatieaanduiding Het alternatief Als we de 'geanonimiseerde' optie omdat die niet aansluit bij het bedoelde gebruik even vergeten, hebben we nu kandidaten voor de relatienaam die een maatregel uitdrukken ('het lakken') en het resultaat van die maatregel ('het is publiceerbaar'). Wat we eigenlijk willen uitdrukken is de áfwezigheid van elementen in de inhoud van het openbaar te maken informatieobject die (volledige) openbaarmaking van het origineel in de weg staan. Probleem daarbij is dat er diverse grondslagen kunnen zijn voor die niet-(volledige)openbaarmaking. Bijvoorbeeld de in Wet open overheid genoemde uitzonderingsgronden, maar ook, voor zover die van invloed zijn op openbaarmaking, auteursrechtelijke of contractueel overeengekomen gebruiksbeperkingen. Volgens mij kunnen we deze samenvatten als 'beperkingen aan de openbaarheid'. Als we bovendien duidelijk willen maken dat het bestaan van beperkingen in 'het origineel' een voorwaarde is voor het bestaan van een zonder beperkingen openbaar te maken variant, komen we uit bij iets als het volgende, helaas niet heel compacte, voorstel voor een relatiebeschrijving:
Dit vind ik een lastige vraag. MDTO stelt dat een 'bestand' zich verhoudt tot een 'informatieobject' doordat het (geparafraseerd) "een representatie van een (deel van een) informatieobject is". Persoonlijk kan ik me voorstellen dat varianten met en zonder openbaarheidsbeperkingen gezien worden als twee bestanden die één informatieobject representeren, maar ik weet niet of daarover consensus bestaat. Het RGBZ kent het concept 'bestand' niet. Dit betekent dat we varianten met en zonder openbaarheidsbeperkingen sowieso als twee 'enkelvoudige informatieobjecten' moeten zien. Op basis van de definitie voor samengesteld informatieobject zou ik het niet gek vinden om de varianten middels dat concept samen te binden, ware het niet dat we in de Documenten API geen samengestelde informatieobjecten kennen.
Dit zou te realiseren zijn door de bedoeling en beschrijving van 'Gebruiksrechten informatieobject', waarin voorwaarden voor raadplegen buiten beschouwing worden gelaten, uit te breiden richting 'beperkingGebruik' in MDTO waaronder wel expliciet openbaarheidsbeperkingen worden begrepen. |
Beta Was this translation helpful? Give feedback.
-
De relatiebeschrijving lijkt me zo inderdaad veel beter recht te doen aan wat de relatie tussen twee documenten is. De naam is misschien wat cryptisch voor iemand die zicht het model eigen wil maken, maar past wel bij beter dan gelakte variant inderdaad. Dit lijkt mij een prima voorstel!
Dit lijkt mij een zuivere weergave. Om het pragmatisch te houden, hoeven we dit ook niet hier op te lossen. Maar wellicht wel goed om dit mee te nemen bij een standaardmapping RGBZ <-> MDTO.
Dit lijkt me een elegente oplossing. Ik zou er wel voor willen pleiten om (in ieder geval voor de uitzonderingsgronden van de WOO) een enum te maken. Dat maakt rapportage (in de geest van de IHH-dashboards) op te publiceren documenten ook een stuk eenvoudiger. |
Beta Was this translation helpful? Give feedback.
-
Mooi!
|
Beta Was this translation helpful? Give feedback.
-
Voorstel om informatieobjecten onderling te kunnen relateren
Dit is een voorstel om issues #2078 en #2079 te tackelen.
De volgende referentietabel wordt opgenomen in de aanvullende specificatie van de Documenten API. In deze eerste versie bevat de tabel twee relaties waarmee documenten aan elkaar gelinkt kunnen worden.
De kolom Relatie geeft de relatie weer tussen twee informatieobjecten, zeg
informatieobject1eninformatieobject2. Kolommen Rol1 en Rol2 geven de rollen weer die respectievelijkinformatieobject1eninformatieobject2spelen in deze relatie.POST
In de volgende POST-operatie wordt de relatie vastgelegd dat document
<doc1>is vervangen door de gestempelde versie<doc2>. De notatie<doc>staat voor de url link naar documentdoc.POST /relaties{ "informatieobject1": "<doc1>", "informatieobject2": "<doc2>", "relatie": "is_vervangen_door_gestempelde_versie" }Respons:
{ "url": "<rel1>", "uuid": "<<rel1>>", "informatieobject1": "<doc1>", "informatieobject2": "<doc2>", "relatie": "is_vervangen_door_gestempelde_versie", }Aan de objecten in het responsbericht zijn zowel een url naar het object zelf en een uuid ter identificatie van object toegevoegd. De notatie
<<rel>>staat voor de uuid van relatierel.In de volgende POST-opdracht wordt vastgelegd dat
<doc2>een publiceerbare versie<doc3>heeft.POST /relaties{ "informatieobject1": "<doc2>", "informatieobject2": "<doc3>", "relatie": "heeft_publiceerbare_versie" }Respons:
{ "url": "<rel2>", "uuid": "<<rel2>>", "informatieobject1": "<doc2>", "informatieobject2": "<doc3>", "relatie": "heeft_publiceerbare_versie", }GET
Alle attributen van de resource
/relatiesmogen gebruikt worden als query parameter voor filtering:urluuidinformatieobject1informatieobject2relatieEr is één extra query parameter toevoegd zodat het opgegeven infomatieobject zowel kan matchen op
ìnformatieobject1als opinformatieobject2:informatieobjectBijvoorbeeld, onderstaande query geeft alle relaties terug waarin
doc2voorkomt.GET /relaties?informatieobject=<doc2>Respons:
[ { "url": "<rel1>", "uuid": "<<rel1>>", "informatieobject1": "<doc1>", "informatieobject2": "<doc2>", "relatie": "is_vervangen_door_gestempelde_versie", }, { "url": "<rel2>", "uuid": "<<rel2>>", "informatieobject1": "<doc2>", "informatieobject2": "<doc3>", "relatie": "heeft_publiceerbare_versie", } ]DELETE
De volgende DELETE-operatie verwijderd relatie
rel2.DELETE /relaties/<<rel2>>PUT/PATCH
Er worden geen PUT/PATCH-operaties ondersteund. Updates kunnen alleen worden uitgevoerd door middel van DELETE en POST. Dus om een bestaande relatie tussen documenten aan te passen wordt eerst de relatie verwijderd met een DELETE en vervolgens wordt de aanpassing als een nieuwe relatie opgevoerd met een POST.
Convenience
Voor het gemak is de
/enkelvoudiginformatieobjectenresource uitgebreid met het attribuut"gerelateerdeInformatieobjecten". Dit is een read-only veld dat alle gerelateerde informatieobjecten van een (enkelvoudig) informatieobject toont. Hieronder worden de drie eerder besproken documenten bevraagd door middel van een GET-operatie en kunnen we direct hun onderlinge relaties bekijken. Op basis van de referentietabel wordt derolvan het gerelateerde informatieobject in de relatie toegevoegd.GET /enkelvoudiginformatieobjecten/<<doc1>>Respons:
[ { "url": "<doc1>", "uuid": "<<doc1>>", ... "gerelateerdeInformatieobjecten": [ { "informatieobject": "<doc2>", "rol": "gestempelde_versie", "relatie": "<rel1>" }, ] } ]GET /enkelvoudiginformatieobjecten/<<doc2>>Respons:
[ { "url": "<doc2>", "uuid": "<<doc2>>", ... "gerelateerdeInformatieobjecten": [ { "informatieobject": "<doc1>", "rol": "ongestempelde_versie", "relatie": "<rel1>" }, { "informatieobject": "<doc3>", "rol": "publiceerbare_versie", "relatie": "<rel2>" } ] } ]GET /enkelvoudiginformatieobjecten/<<doc3>>Respons:
[ { "url": "<doc3>", "uuid": "<<doc3>>", ... "gerelateerdeInformatieobjecten": [ { "informatieobject": "<doc2>", "rol": "ongepubliceerde_versie", "relatie": "<rel2>" } ] } ]Beta Was this translation helpful? Give feedback.
All reactions