BREED - over de grenzen van informatie

NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER

TMLO-element: 9.1 - In tijd

Het Toepassingsprofiel Metadatering Lokale Overheden (TMLO) is een standaard voor metadatering bij alle decentrale overheden. Zij draagt bij aan de toegankelijkheid van informatie en de uitwisseling van informatie tussen overheden. Een groeiend aantal decentrale overheden legt inmiddels hun informatiesystemen langs deze standaard.

De toepassing in de praktijk roept soms vragen en discussie op. Om deze discussies in goede banen te leiden is per TMLO-element een aparte 'thread' gestart. Een overzicht van de threads vind je hier. Door in deze threads inzichten met elkaar te delen, kunnen vakgenoten elkaar helpen. Ook lezen de mensen die achter het TMLO zitten mee. De discussies levert hun bruikbare input op voor de eventuele doorontwikkeling van het TMLO.

In deze thread wisselen we inzichten uit over het TMLO-element:

9.1 - In tijd

Definitie:	Geeft positionering in de tijd aan, waarin iets van kracht is / was dan wel bestond.
Waardering:	Optioneel
Waardering Richtlijn:	Optioneel
Herhaalbaar:	Nee
Overerving:	Ja
Toelichting:	In het geval van een record zijnde een dossier betreft dit veelal de periode waarin het dossier behandeld of gecreëerd is, bijvoorbeeld de behandeling van een vergunningaanvraag. Voor bepaalde archiefstukken in dat dossier kan evenwel een andere periode van toepassing zijn Betreft de periode waarover de werking van het record zich uitstrekt, bijvoorbeeld de looptijd (werkingsduur) van een vergunning, ontheffing, uitlening etc. Dit is wat anders dan de periode waarin het record tot stand gekomen is. Dat wordt geregistreerd met element 12 (Event geschiedenis). Indien er voor een record geen sprake is van een werkingsduur, dan wordt het subelement niet van een waarde voorzien.
Waardenverzameling:	Datum begin periode (jjjjmmdd) en Datum einde periode (jjjjmmdd), gescheiden door een liggend streepje.
Voorbeelden:	”20120229-20120531”

Vind ik leuk

1 lid vind dit leuk

Berichten in deze discussie

Permalink Antwoord van Marco Klerks op 23 September 2015 op 21.00

Bij alle datum-elementen waarbij een periode aangeven kan worden (jjjjmmdd-jjjjmmdd) is het beter om dit op te splitsen naar twee elementen. Als het TMLO vertaald wordt naar concrete inrichtingen en koppelingen, dan is het technisch beter mogelijk om te borgen dat de ingevulde waarde daadwerkelijk een datum betreft. Als er vastgehouden wordt aan het format “jjjjmmdd-jjjjmmdd” dan is dit technisch gezien een tekstveld.

Permalink Antwoord van Leo Hollestelle op 1 Oktober 2015 op 11.48

Moet de datumnotatie altijd jjjjmmdd zijn of mag dd-mm-jjjj ook? Zie ook bij de elementen 5.4, 12.1, 13.1, 16.2, 17.2, 21.6.3, 21.7.3, 21.8.

Permalink Antwoord van 0rhsu7s4uvxna op 19 Oktober 2015 op 10.46

Sluit ik mij bij aan Marco. Buiten het feit dat het samenvoegen van twee velden in een export vanuit een applicatie technisch gezien mogelijk is, zijn de meeste applicaties geënt op twee aparte velden die automatisch (o.b.v. een trigger) dan wel handmatig worden gevuld met een waarde. De borging van de kwaliteit van de inhoud van dit veld (structuur) is ook in mijn eigen ogen beter te verantwoorden als je er een datumnotatie van maakt en de export op deze twee aparte velden laat aansluiten.

Heeft iemand hier een andere visie op?

Marco Klerks zei:

Bij alle datum-elementen waarbij een periode aangeven kan worden (jjjjmmdd-jjjjmmdd) is het beter om dit op te splitsen naar twee elementen. Als het TMLO vertaald wordt naar concrete inrichtingen en koppelingen, dan is het technisch beter mogelijk om te borgen dat de ingevulde waarde daadwerkelijk een datum betreft. Als er vastgehouden wordt aan het format “jjjjmmdd-jjjjmmdd” dan is dit technisch gezien een tekstveld.

Permalink Antwoord van 0rhsu7s4uvxna op 19 Oktober 2015 op 11.23

Wat zijn je argumenten om van de notatie jjjjmmdd af te wijken? Aangezien TMLO streeft naar uniforme uitwisseling van data (structuren) zou ik adviseren om niet beide formats te gebruiken. Althans; niet in je export. In de applicatie kan natuurlijk wel voor het format dd-mm-jjjj worden gekozen. Denk ook eens aan de mogelijkheden om deze waarden bij exporteren automatisch te laten omzetten, is dit een optie? Met die uitwerking zou je binnen de applicatie waarin de data zich nu bevindt geen waarden hoeven aan te passen (met terugwerkende kracht)? Dit vraagt natuurlijk wel om een consequent gebruik van de datumnotatie.

Ook is het mogelijk om de datumnotatie in de applicatie anders weer te geven/uit te lezen dan in de database. Op het scherm krijg je dan bijvoorbeeld 01-01-2015 te zien, terwijl in de database 20150101 staat. Lijkt me overigens sowieso een stuk gebruiksvriendelijk en waarschijnlijk wordt dit ook al wel toegepast. Hiervoor zal je contact op moeten nemen met de leverancier van je applicatie om na te vragen hoe deze waarden in de database staan opgenomen én hoe het zit met de (mogelijkheden van) datumnotatie in de uitvoer.

Leo Hollestelle zei:

Moet de datumnotatie altijd jjjjmmdd zijn of mag dd-mm-jjjj ook? Zie ook bij de elementen 5.4, 12.1, 13.1, 16.2, 17.2, 21.6.3, 21.7.3, 21.8.

Permalink Antwoord van 0rhsu7s4uvxna op 19 Oktober 2015 op 11.33

De periode waarin een dossier wordt behandeld of de periode waarover de werking van het dossier zicht uitstrekt zijn twee aparte (sub) elementen.

Bijvoorbeeld:

Periode behandeling: 20150901-20150914 (periode wordt gevormd door datum start zaak - datum afhandeling zaak)

Periode uitwerking: 20150930 (dag waarop de straat barbecue plaatsvindt)

Dit zou betekenen dat je twee sub elementen tijd (en dus ook plaats) bij element 9 kunt opnemen. Iemand hier andere ideeën over?

Permalink Antwoord van Wout van der Reijden op 19 Oktober 2015 op 15.50

@ Leo
Er is een ISO norm voor datumannotatie (ISO 8601) die vaak wordt gevolgd (ook door TMLO): jjjj-mm-dd. In ieder geval het e-Depot van het NA volgt ook die standaard. Mochten applicaties een andere annotatie hebben, dan zou je dat bij een export-import proces kunnen laten transformeren. Dit geef je dan aan bij het mappen van metadata.

@ Kevin
Het element is niet herhaalbaar, dus je kan maar een periode opnemen. De periode behandeling zou je kunnen vastleggen in de event geschiedenis (met start zaak en afsluiting zaak als events), de periode uitwerking zou je dan weer onder 9.1 kunnen vastleggen.

Permalink Antwoord van Marco Klerks op 19 Oktober 2015 op 21.27

Wout, ik heb mij ook een klein beetje verbaasd over de vormeis jjjjmmdd. Deze vormeis is heel specifiek, zeker als je deze vergelijkt met de vormeisen van andere elementen zoals "Wij raden aan om een beperkte waardenlijst te hanteren" of "Tekst".

In paragraaf 1.3 staat heel helder uitgelegd wat het verschil is tussen een toepassingsprofiel en een XML-sxhema. Ik vind deze strakke vormeis wel thuishoren in een XML-schema, maar niet in een toepassingsprofiel. In het toepassingsprofiel zou het m.i. volstaan om te adviseren om door het hele archiefsysteem een uniforme datumnotatie te hanteren. Zoals je al aangeeft is het technisch vrij eenvoudig om de ene datumnotatie om te zetten naar een andere datumnotatie. Dat kan ook in het koppelvlak of de export geregeld worden.

Permalink Antwoord van Wout van der Reijden op 20 Oktober 2015 op 9.13

Ik weet niet of het echt een eis is, of een suggestie. De toelichting in bijlage A van het TMLO heeft het bij waardenverzamelingen over '..waarden die van het element vastgelegd kunnen worden.' Kunnen, niet moeten. Dat laat ruimte. Maar wel met de gedachte dat als iedereen zoveel mogelijk hetzelfde doet, dit bijdraagt aan interoperabiliteit.

TMLO hinkt af en toe op twee gedachten - het zegt wat er moet vastgelegd en in een aantal gevallen ook hoe.
Dat laatste zou je eigenlijk in een informatiemodel moeten doen.

In de bovenliggende Richtlijn wordt bij een aantal datumvelden overigens verwezen naar een 'Richtlijn dateringen (datumstructuur), bijlage..'. Ik kan die richtlijn echterniet vinden. Dat is jammer, want het had wat handvatten kunnen geven.

Marco Klerks zei:

Wout, ik heb mij ook een klein beetje verbaasd over de vormeis jjjjmmdd. Deze vormeis is heel specifiek, zeker als je deze vergelijkt met de vormeisen van andere elementen zoals "Wij raden aan om een beperkte waardenlijst te hanteren" of "Tekst".

In paragraaf 1.3 staat heel helder uitgelegd wat het verschil is tussen een toepassingsprofiel en een XML-sxhema. Ik vind deze strakke vormeis wel thuishoren in een XML-schema, maar niet in een toepassingsprofiel. In het toepassingsprofiel zou het m.i. volstaan om te adviseren om door het hele archiefsysteem een uniforme datumnotatie te hanteren. Zoals je al aangeeft is het technisch vrij eenvoudig om de ene datumnotatie om te zetten naar een andere datumnotatie. Dat kan ook in het koppelvlak of de export geregeld worden.

Permalink Antwoord van Joost Salverda op 7 Oktober 2016 op 12.24

Bij de toelichting wordt gesuggereerd dat het kan gaan om de periode waarin een dossier gecreëerd of behandeld is. Dat zijn twee wezenlijk verschillende zaken (van daar dat neem ik aan element 9 ook herhaalbaar is). Creatie lijkt een beheergegeven dat onder 12 (event geschiedenis) thuishoort. Even verderop in de uitleg zie ik dat ook terug, maar daarmee spreekt de toelichting zichzelf tegen. Volgens mij klopt de eerdere passage uit de toelichting dus niet.

De definitie vind ik op dit punt ook niet helder: 'Geeft positionering in de tijd aan waarin iets van kracht is / was dan wel bestond'. Dat eerste lijkt me helder, dat is de werkingsduur, maar dat tweede vind ik moelijker te duiden. Slaat dat niet terug op dat wat in de toelichting wordt verwezen naar event geschiedenis?

Kan iemand voorbeelden geven van waardes die in een systeem in dit veld zijn ingevuld en waar die waardes betrekking op hebben?

Permalink Antwoord van Joost Salverda op 7 Oktober 2016 op 12.26

N.a.v. de eerdere discussie over herhaalbaarheid: element 9 op zich is wel herhaalbaar, dus als je twee gegevens in de tijd zou willen opnemen over een zaak of een stuk, dan herhaal je element 9, met daaronder subelement 9.1.

Permalink Antwoord van MGroels op 10 Oktober 2016 op 13.48

@Joost:

bijvoorbeeld de looptijd (werkingsduur) van een vergunning, ontheffing, uitlening

Ik versta onder dit element dan ook altijd de inhoudelijke tijdsaanduiding van een zaak, dossier of document. Wanneer iets bestond kan dan dus een gebouw, verbod, gebod, verordening of wat dan ook zijn.

Permalink Antwoord van Joost Salverda op 10 Oktober 2016 op 16.28

Bedankt voor je reactie, Mike! (Hoe) onderscheid je dit van de datum van creatie/afsluiting van een zaak? Of lopen die twee vaak juist parallel (en vul je dus in elementen 9.1 en 12 hetzelfde in)?