Extracting ODRL Policies from Business Process Models: A Graph Traversal Approach to Compliance-by-Extraction

Stel je een wereld voor waarin elke keer dat je een winkel binnenloopt, een robotbewaker je ID, je boodschappenlijst en je budget controleert voordat hij je een enkel artikel laat oppakken. Die robot raadt niet zomaar wat; hij volgt een strikt regelboek geschreven door de winkelier. In de digitale wereld wordt dit regelboek een "policy" genoemd. Het vertelt computers wat ze wel mogen doen, wat ze moeten doen en waarvan ze strikt verboden zijn. Lange tijd was het schrijven van deze digitale regelboeken als het proberen te bouwen van een wolkenkrabber met de hand, steen voor steen. Het is traag, foutgevoelig en als je één steen verkeerd legt, kan de hele structuur instorten.

Hier komt het concept "compliance" om de hoek kijken. Dit is het chique woord voor het zorgen dat iedereen zich aan de regels houdt. In de zakenwereld besteden bedrijven jaren aan het uittekenen van kaarten die laten zien hoe hun werk wordt uitgevoerd. Deze kaarten worden Business Process Models (BPMN) genoemd. Beschouw ze als de blauwdrukken voor een fabriek of het script voor een toneelstuk. Ze laten zien wie wat doet, wanneer, en in welke volgorde. De grote vraag die wetenschappers zich hebben gesteld is: "Als we al deze gedetailleerde blauwdrukken hebben, waarom moeten we dan het regelboek opnieuw schrijven?" De blauwdrukken bevatten de regels al; ze spreken alleen een andere taal. Dit artikel gaat over het bouwen van een vertaler die die blauwdrukken rechtstreeks omzet in een modern, machineleesbaar regelboek, zodat we de regels niet twee keer hoeven te schrijven.

De Magische Vertaler: Van Blauwdrukken naar Regels

De auteurs van dit artikel, een team van onderzoekers uit Spanje en Italië, hebben een slimme pijplijn gebouwd die werkt als een digitale detective. Hun taak is om naar de proceskaart van een bedrijf (het BPMN-bestand) te kijken en automatisch de verborgen regels daarin te extraheren, om ze vervolgens om te zetten in een formaat dat ODRL wordt genoemd. Je kunt ODRL zien als de "universele taal" voor digitale rechten en regels, een standaard die computers overal kunnen begrijpen.

Zo werkt hun "detectivewerk", opgedeeld in eenvoudige stappen:

1. De Blauwdruk is Al een Regelboek
De onderzoekers realiseerden zich dat de manier waarop een proceskaart wordt getekend, feitelijk een reeks regels is. Als een kaart laat zien dat een werknemer een bestelling moet controleren voordat deze wordt verzonden, dan is dat een regel genaamd een "Duty" (plicht). Als de kaart laat zien dat een werknemer een stap kan overslaan als aan een bepaalde voorwaarde wordt voldaan, dan is dat een "Permission" (toestemming). Als de kaart laat zien dat een werknemer niet verder kan gaan totdat een specifieke gebeurtenis heeft plaatsgevonden, dan is dat een "Prohibition" (verbod). Het probleem is dat deze regels opgesloten zitten in de tekening. De nieuwe pijplijn ontgrendelt deze regels.

2. De Graph Traversal (De Maze Runner)
De software van het team behandelt de proceskaart als een doolhof. Het maakt gebruik van een techniek genaamd "graph traversal", wat in feite een systematische manier is om door elk pad in het doolhof te lopen om te zien wat er gebeurt.

• De "Moet-Doen" Check: De software vraagt: "Als we deze taak verwijderen, kan het proces dan nog steeds worden afgerond?" Als het antwoord "Nee, het proces stopt" is, dan is die taak een Duty (een moet-doen).
• De "Kan-Overslaan" Check: Als de taak op een pad ligt dat niet altijd wordt bewandeld, is het een Permission.
• De "Wacht"-regel (De Grote Ontdekking): Hier wordt het papier echt slim. Bij oudere methoden, als een proces moest wachten op een e-mail of een signaal (een zogenaamde "intermediate catch event"), werd de regel vaak genegeerd of behandeld als een eenvoudige vertraging. De auteurs stellen dat dit onjuist is. Zij zeggen: "Als je wacht, ben je eigenlijk verboden om verder te gaan totdat het signaal arriveert." Daarom hebben ze een nieuwe manier uitgevonden om deze momenten te labelen als Prohibitions (verboden) met een "lifting constraint" (opheffingsvoorwaarde). Het is als een rood licht dat pas groen wordt wanneer een specifieke auto (de gebeurtenis) voorbijrijdt.

3. De Output
Na het doorlopen van het doolhof spuugt de software een schoon, geldig regelboek uit in een formaat dat JSON-LD wordt genoemd. Dit is een bestand dat computers direct kunnen lezen. Het beste eraan? Het bedrijf hoefde geen enkele nieuwe regel te schrijven. De software heeft simpelweg de regels die al in hun bestaande kaarten verborgen zaten, eruit gehaald.

Wat Ze Vonden (en Wat Ze Niet Vonden)

Het team heeft hun vertaler getest op vijf verschillende "benchmark" scenario's, variërend van een eenvoudig "Dispatch of Goods" (verzending van goederen) proces tot een complex "Self-Service Restaurant" met drie verschillende personen (pools) die met elkaar interageren.

• Het Succes: In alle vijf de gevallen slaagde de software erin om de kaarten om te zetten in regelboeken zonder vast te lopen. Het identificeerde correct wie wat moest doen, wie stappen kon overslaan en wie moest wachten. Zo begreep het in het "Credit Scoring" scenario bijvoorbeeld dat een bank moet aanvragen om een score, maar dat een scoringdienst de score niet kan berekenen totdat de gegevens zijn gearriveerd. Het hanteerde zelfs de lastige "wacht"-regels perfect door ze te labelen als verboden die worden opgeheven zodioden de gebeurtenis plaatsvindt.
• De Limieten: Het artikel is eerlijk over waar de magie ophoudt.
  • Loops: Als een proces een loop heeft (zoals een klant die het steeds opnieuw probeert), vereenvoudigt de software dit. Het behandelt de loop als een enkele "moet-doen" taak, wat veilig is, maar de nuance van "herhalen tot succesvol" verliest.
  • Namen: Soms hebben de kaarten geen namen voor de betrokkenen (zoals "Bank" of "Clerk"). In die gevallen gebruikt de software gewoon generieke labels zoals "Participant_1", wat het regelboek wat lastiger leesbaar maakt voor mensen, ook al begrijpt de computer het perfect.
  • Complexe Timing: De software kan nog geen complexe timingregels uitdrukken zoals "Taak A moet precies 5 minuten voordat Taak B begint, voltooid zijn." Het legt de volgorde vast, maar niet de precieze timing.

Waarom Dit Belangrijk Is

Het artikel beweert niet dat het alle problemen in de wereld van regels heeft opgelost. Het zegt niet dat dit de definitieve, perfecte oplossing is. In plaats daarvan bewijst het dat een specifieke, automatische manier om proceskaarten om te zetten in regelboeken werkt.

Voorheen, als een bedrijf wilde voldoen aan nieuwe wetgeving (zoals privacywetten), moesten ze experts inhuren om handmatig duizenden beleidsdocumenten te schrijven. Dit was traag en duur. Als het bedrijf zijn proces veranderde, moesten ze ook de beleidsregels opnieuw schrijven. Deze nieuwe aanpak suggereert dat als je je proceskaart aanpast, het regelboek zichzelf automatisch bijwerkt. Het creëert een directe, controleerbare link tussen wat een bedrijf doet en de regels die het volgt.

De onderzoekers merken er terecht bij op dat hoewel hun methode uitstekend werkt voor standaard proceskaarten, er nog steeds meer werk nodig is om complexe loops en precieze timing te behandelen. Maar voor nu hebben ze aangetoond dat de regels er al zijn, verborgen in het volle zicht, wachtend op een vertaler om hen vrij te laten. Het is een stap naar een toekomst waarin compliance geen papierwerk-nachtmerrie is, maar een natuurlijk bijproduct van hoe we ons werk vormgeven.