BREED - over de grenzen van informatie
NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
TMLO-element: 19.3 - Structuur
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:
19.3 - Structuur
| Definitie: | Omschrijving van structuur van record (op verschillende aggregatieniveaus). |
| Waardering: | Verplicht i.v.t. |
| Waardering Richtlijn: | Verplicht |
| Herhaalbaar: | Nee |
| Overerving: | Nee |
| Toelichting: | De interne structuur van een record betreft bijv. de archiefstukken in een dossier, de structuur van een database of de bestanden waaruit een archiefstuk is opgebouwd (bijv. een email met bijlagen). Vullen van dit element is van toepassing als de structuur van het record niet eenvoudig af te leiden is uit de inhoud van het record. Zo is de hoofdstukindeling van een record, zijnde een archiefstuk, zijnde een rapport, eenvoudig te bepalen: het staat er in. Dat ligt anders bij een samengesteld bestand waaruit een record is opgebouwd (meerdere malen element 21). Of bij een dossier dat uit diverse records bestaat. Advies: Bepaal de vereiste structuur per soort record. |
| Waardenverzameling: | Tekst |
| Voorbeelden: | - |
Berichten in deze discussie
-
Permalink Antwoord van Marius Jansen op
-
Element 19.3 lijkt misschien logisch, maar laat zich lastig vertalen naar een concrete beschrijving bij een recordregistratie. Na een behoorlijke zoektocht naar een eenduidige definitie van het begrip "vorm" in deze context kom ik alleen maar tegenstrijdige verklaringen tegen. De toelichting bij dit element lijkt een nadere uitwerking van element 15 (relaties), maar dan in de vorm van een beschrijving van de aard van deze (samengestelde) relaties. Maar dat wordt al beschreven in element 15.2. De passage in de toelichting van 19.3 'samengesteld bestand waaruit een record bestaat' is erg vraag en verwarrend, zeker in relatie met de passage 'Of bij een dossier dat uit diverse records bestaat'. De verwijzing naar element 21 heeft alleen betrekking op het formaat. De vraag die blijft is wat ga je hier nu precies beschrijven bij een recordregistratie? Jammer dat hier geen concrete voorbeelden zijn opgenomen. Dat had waarschijnlijk verheldering gegeven met een sterk gevoel van 'oh, bedoelen ze dat!'.
Wie heeft er al ervaring met het concreet registreren van dit element, en/of kan helder en eenduidig aangeven wat hier precies bedoeld wordt? Ben erg benieuwd naar jullie reacties.
-
-
Permalink Antwoord van Wout van der Reijden op
-
Dag Marius,
Als voorbeeld gebruik ik zelf de email met bijlagen. De email wordt als record/archiefstuk beschreven in TMLO, element 19.3 zou gebruikt kunnen worden om te vermelden, als dat van toepassing is, dat de email een aantal bijlagen bevat, zeg 4. Als deze 4 bijlagen losse bestanden zijn, kunnen deze afzonderlijk worden beschreven met behulp van element 21. Element 21.10 zou je mijns inziens ook kunnen gebruiken om een relatie te leggen tussen die bestanden, maar ook tussen de bestanden en het record waar zij onderdeel van uitmaken.
Op dossierniveau vind ik het wat verder gezocht, door middel van relaties (element 15) kan je records aan een dossier koppelen, waardoor je met een zoekopdracht ook wel een overzicht kan krijgen van de records die zijn gerelateerd aan een dossier.
Ik denk eerlijk gezegd niet dat applicaties er op zijn ingericht om dit subelement automatisch of handmatig vast te leggen. Om het gegeven mee te geven in bijvoorbeeld een export ben je dan veelal genoodzaakt om dit handmatig te doen, wat een inspanning vergt die het gebruik van het element niet ten goede komt. Een concrete invulling van dit element heb ik vooralsnog dan ook niet gezien.
Mvg,
Wout
-
-
Permalink Antwoord van MGroels op
-
@Wout: Waarom zou je aangeven (met tekst?) dat het record een e-mail is mét bijlagen. Dit wordt na het openen van het bestand ook duidelijk net als het voorbeeld aangeeft dat je niet de hoofdstukindeling van een document gaat vermelden in dit element. Of dient het dan voor toekomstige event plannen m.b.t. conversie of iets dergelijks?
-
-
-
Dag Wout em Mike,
Bedankt voor jullie input. Het lijkt erop dat dit element eigenlijk al door andere elementen wordt afgedekt. Het is ook niet verwonderlijk dat tot nog toe nergens en niemand hier concrete voorbeelden van kan tonen.
-
-
-
Dag Mike,
Er wordt wel meer vastgelegd dat ook duidelijk wordt na het openen van een bestand. Dat is een bijkomstigheid van beschrijvende metadata :-)
Ik zou me kunnen voorstellen dat het invullen van een element als deze input kan vormen voor bijvoorbeeld element 20. Als je bij 19.3 vastlegt dat er 4 bijlagen bij een email horen en je ziet er maar 2, wat zou dit betekenen voor de inhoudelijke integriteit van een record?
Maar zoals ik zei, ik heb (nog) niet gezien dat dit element automatisch (of uberhaupt) wordt vastgelegd. De vraag is of dat erg is..
Mvg, Wout
MGroels zei:@Wout: Waarom zou je aangeven (met tekst?) dat het record een e-mail is mét bijlagen. Dit wordt na het openen van het bestand ook duidelijk net als het voorbeeld aangeeft dat je niet de hoofdstukindeling van een document gaat vermelden in dit element. Of dient het dan voor toekomstige event plannen m.b.t. conversie of iets dergelijks?
-
-
-
Scherp, maar dan slaat de toelichting over hoofdstukindeling bij het element ook nergens op. De samenhang tussen de documenten zou niet duidelijk moeten zijn zelfs ná het openen, dat is bij een e-mail wel het geval.
Als het ter controle voor de integriteit dient, kun je je afvragen of degene die 4 heeft ingevuld wel goed heeft gekeken of getypt.
-
-
-
Eens dat het twijfelachtig is wat hier ingevuld zou moeten worden, het moet wel toegevoegde waarde hebben en niet afgeleid kunnen worden uit andere metagegevens. Wel kan ik me voorstelle dat het een tekst als "E-mail met vier bijlagen" bevat. Het record bestaat dan uit vijf bestanden (vijf maal het element Fomaat). Dat daarin een structuur zit, is niet direct uit die vijf formaten af te leiden. Dan ga je interpreteren: 'eentje is een e-mail, de andere niet, dan zal het wel een e-email met bijlagen zijn'. Wat als één van die bijlagen ook een e-mail is? Welke is dan die e-mail met die bijlagen? Dan zou zelfs de tekst "E-mail [naam_e-email] met vier bijlagen" opgenomen moeten worden.
-
-
-
Uitkomst van een discussie tijdens een van de workshops voor het informatiemodel TMLO:
Naar mening van de deelnemers voegt dit subelement weinig tot niets toe en kan het in de regel alleen handmatig worden vastgelegd. Voorstel is derhalve om dit subelement te schrappen. -
-
-
In de bijeenkomst van de Werkgroep ImMLO op 12-12-2016 is hierover opnieuw gesproken.
Uitkomst is dit element optioneel te maken. Indien geen toegevoegde waarde dan niet vullen.
-
-
-
N.a.v. de discussie is de toelichting bij het element in het Informatiemodel MLO (versie 0.8) t.o.v. het TMLO aangepast zodat duidelijk is dat het alleen van een waarde moet worden voorzien indien relevant.
-
Partner(s)
Sponsor(s)
Direct naar...
© 2024 Gemaakt door Marco Klerks.
Verzorgd door
