Closed jensscheerlinck closed 5 years ago
Misschien in deze discussie niet de juiste plaats, maar als we het hebben over een vocabularium van legistiek, vind ik wel dat we minstens de gehele levensloop van de wetgeving in beschouwing moeten nemen (en niet enkel het uiteindelijke artikel/paragraaf/hoofdstuk van een decreet/wet). Dan komen we al snel in een verhaal van groen- en witboeken, een samengaan met organen/organisaties en een aantal verantwoordelijkheden daarin. Misschien is het wel aangewezen hierover eens af te stemmen met collega's van het departement Kanselarij & Bestuur (die momenteel bezig zijn met de voorbereidingen voor een nieuwe methodiek rond beleidsvoorbereiding, decreetvorming). Misschien eens contact opnemen met frederik.vanlaere@vlaanderen.be?
Los van de voorgaande algemene bemerking, slaat de discussie Artikel/Paragraaf/Hoofdstuk op de structuur van een regelgevend stuk. Mijn aanvoelen is dat je dat beter typeert dan vastlegt in concepten. Cfr. ELI start je beter van een 'resource' dat je typeert en relateert aan andere resources. Geeft je de vrijheid om - naast zuiver Vlaamse decreten met een vaste structuur - ook andere regelgevende stukken interoperabel te krijgen (met hun rsp. inhoud). Zie bvb. https://overheid.vlaanderen.be/opstellen-van-een-decreet-bvr-of-mb voor richtlijnen over de structuur van een MB of een BVR (waar het niet gaat over hoofdstukken, maar een set van blokken).
@dhaeneth er loopt momenteel een impactanalyse voor de publicatie van de Vlaamse Codex als Linked Open Data. Hierbij werden ook mensen van het project 'digitalisering besluitvorming' betrokken. De link met het hele voorbereidend traject wordt dus mee in beschouwing genomen. Een eerste fase zal echter toespitsen op het publiceren van de documenten in de codex als Linked Open Data.
ELI voorziet momenteel een entiteit 'http://data.europa.eu/eli/ontology#LegalResourceSubdivision'
A component of a legal act, at an arbitrary level of precision, like a chapter, an article, an alinea, a paragraph or an list item. A subdivision can be linked with its parent and children subdivision using the properties eli:has_part / eli:is_part_of.
Ze voorzien dat deze entiteit verder kan gespecialiseerd worden naar bv. hoofdstuk/artikel/paragraaf. In het geval van de codex zou dit handig zijn omdat het URI schema zou toelaten om bv. naar een specifiek artikel te verwijzen, waarbij het artikel zelf een URI krijgt toegewezen.
Akkoord met @dhaeneth om een type-attribuut op te nemen, maar dan enkel op het onderdeel-aspect (hoofdstuk/artikel/...)
@brechtvdv bedoel je invoeren van een attribuut 'type' dan zowel op 'Legale Verschijningsvorm' als 'Rechtsgrond Onderdeel'? Dit kan dan iets applicatie profiel specifiek zijn, tenzij we een eigen attribuut voor 'type' definiëren i.t.t. bv. dublin core 'type'.
Jens, als ik het goed interpreteer is http://data.europa.eu/eli/ontology#LegalExpression (Legale Verschijningsvorm in jouw vertaling) zowat elk regelgevend stuk informatie dat er kan bestaan, gebaseerd op het FRBR-model (waarvoor het natuurlijk uitermate geschikt is). Akkoord om op dit niveau te enten, maar dan wel op een goede manier.
Wat mij betreft kan DC:Type (Definitie : Recommended best practice is to use a controlled vocabulary such as the DCMI Type Vocabulary [DCMITYPE].) zeker een oplossing bieden, maar dan moeten we er als overheid effectief een controlled typelist tegenover stellen. Lees : een centraal (praktisch) ondersteunde maar breed gedragen lijst van verschillende types. Die kan dan overgeërfd worden binnen 'Rechtsgrond onderdeel'.
Ik ben toch eerder voorstander om RechtsgrondOnderdeel te specialiseren in Artikel, Hoofdstuk, Alinea... Dit sluit dichter aan bij de visie van ELI en zorgt ervoor dat anderen dit makkelijker kunnen uitbreiden indien nodig.
:-). Als ik dan eventjes advocaat van de duivel mag spelen... Mijn eerste vraag zou dan zijn om ook relaties te definiëren op de subklassen. Ik wil immers graag eenvoudig alle alinea’s binnen een artikel, alle artikels binnen een hoofdstuk, .... kunnen opvragen (en als de concrete subklassen er dan toch zijn, heb ik graag op dat niveau de relatie). Ik hoop natuurlijk dat ik er mag van uitgaan dat dat steeds een mooie hiërarchie vormt? En dat elke alinea steeds behoort tot een artikel en een hooofdstuk en .... En aangezien ik het mogelijk acht dat zowel de klasse, de concrete specialisatie als de tussenliggende concrete relaties wel kunnen wijzigen in de tijd worden het allemaal OSLO:Objecten met een eigen prov.
In dit scenario
My two cents...
Uiteindelijk document-hiërarchie losgekoppelt van Legale verschijningsvorm :
OSLO-generiek uitgebreidt met Document en Document Onderdeel.
Document heeftOnderdeel Document Onderdeel.
Document Onderdeel isDeelVan Document Onderdeel.
Document Onderdeel bevat attributen: type (=artikel, hoofdstuk, paragraaf... / codelijst) en nummer.
Besluit is een subklasse van Document.
Via Document kan de link naar onderdelen gemaakt worden, waaronder Artikel dus.
@brechtvdv @GeertThijs Wordt in OSLO-generiek voor document_hiërarchie gebruik gemaakt van dcterms:hasPart/isPartOf of eli:has_part/is_part_of?
Voor AP Vlaamse Codex is het de bedoeling te kunnen uitwisselen volgens ELI specificatie dus gaan we mappen op de URI's van ELI (laatste). Maar aangezien deze subproperties zijn van dcterms lijkt er mij geen probleem te zijn indien op niveau van OSLO-Generiek voor dcterms gekozen is.
OSLO-generiek gebruikt dcterms:isPartOf.
eli:is_part_of is geen subproperty, maar specificPropertyOf. Dit staat dus los van dcterms. @jensscheerlinck eli:is_part_of heeft als range en domain Legal Resource. Vlaamse Codex wil ook hoofdstuk/paragraaf hiermee linken, maar deze zijn geen Legal Resources, maar Legal expressions? Vind je het ook niet raar dat de comment van eli:is_part_of over fysieke inclusie gaat (=legale expression)?
@brechtvdv Hoofdstuk, artikel en paragraaf worden gedefinieerd als LegalResourceSubdivision (subClassOf LegalResource). Elk van deze kan nog eens één of meerdere LegalExpressions hebben.
In v1.1 van de ELI Ontology staat dat:
starting from v1.1, is_member_of / has_member should be used instead of is_part_of / has_part for conceptual inclusions;
Dus voor het linken van hoofdstukken, artikels en paragrafen aan LegalResources zal gebruik gemaakt worden van is_member_of en has_member (ook eli:specificPropertyOf dct:hasPart en dct:isPartOf).
Maar valt dus te mappen om document hiërachie in OSLO Generiek, dus lijkt mij dat deze issue dicht mag!
You're right. Document/Document onderdeel werd toegevoegd om isPartOf te kunnen doen op legale expressies (voor lblod editor). In het geval van Vlaamse Codex zal dit op Legal resources zijn en kan is_member_of in het applicatieprofiel gebruikt worden.
Issue indicatief heropend tot aan publicatie na afspraak hierover.
Momenteel wordt bij besluit een 'Artikel' gedefinieerd als onderdeel van een juridisch document: http://data.vlaanderen.be/ns/besluit#Artikel
In de Vlaamse Codex is er ook nood aan het ontsluiten van andere onderdelen: