Vanaf 1 mei kan op de dag van de arbeid de dialoog op dit Breednetwerk plaatsvinden

over het Toepassingsprofiel Metadata Lokale Overheid.

 

Weergaven: 7121

Berichten in deze discussie

Op de dag van de arbeid publiceert het programmabureau Archief 2020 het toepassingsprofiel metadata lokale overheid, TMLO. Organisaties die al een profiel hebben of zij die hiermee aan de slag willen worden hier op het Breednetwerk van harte uitgenodigd om ervaringen met de eigen  toepassing te delen.

Op dit moment ligt bij mij de focus op één "optioneel" element, nl. geo metadata, 9.2 geo grafisch gebied

Deze uiterst belangrijke metadata mogelijkheid, heeft veel voordelen (zie toelichting).

Optioneel = niet verplicht=vaak gelijk aan doen we dus niet.

Verder zou ik als je XY noemt direct ook de "Z" =Hoogte of diepte maar meenemen.

In onze pilot e-depot vraag juist veel aandacht voor dit metadata gegeven, juist i.v.m. de "(re)presentatie" mogelijkheden.

 

@Henk: goed punt! en de eerste reactie, scherp en attent. Dank daarvoor.

De ontsluiting van ruimtelijke informatie of locatiegebonden informatie is een item. Door de decades heen niet uitermate helder vastgelegd. Door nu niet te verplichten wordt wellicht een kans gemist.

Mbt x-y lijkt mij z (hoogte of diepte) inderdaad een extra die ertoe doet. De kwaliteit van die gegevens zien we ook in de onlangs verschenen evaluatie BAG opkomen.

Zeer interessante casus in jullie pilot e-depot (HCO en Deventer ca). Kunnen we daar al ergens meer over 'lezen' en van leren?

Het profiel is een richting en biedt in H3 implementatiestappen. Zou het in Deventer helpen als het een verplicht veld is: of is het juist goed om er in het eigen metadata beleid aandacht voor te vragen, naast de verplichte metadata?

 

wat is je mail adres?? ik heb .ppt wat voor project DEV gemaakt mijn directeur staat er op dat geo meegenomen wordt dus ik ben in het voordeel.
 
André Plat zei:

@Henk: goed punt! en de eerste reactie, scherp en attent. Dank daarvoor.

De ontsluiting van ruimtelijke informatie of locatiegebonden informatie is een item. Door de decades heen niet uitermate helder vastgelegd. Door nu niet te verplichten wordt wellicht een kans gemist.

Mbt x-y lijkt mij z (hoogte of diepte) inderdaad een extra die ertoe doet. De kwaliteit van die gegevens zien we ook in de onlangs verschenen evaluatie BAG opkomen.

Zeer interessante casus in jullie pilot e-depot (HCO en Deventer ca). Kunnen we daar al ergens meer over 'lezen' en van leren?

Het profiel is een richting en biedt in H3 implementatiestappen. Zou het in Deventer helpen als het een verplicht veld is: of is het juist goed om er in het eigen metadata beleid aandacht voor te vragen, naast de verplichte metadata?

 

@Jean-Luc Rouvroye 2 goede vragen, het zou zomaar kunnen dat hier wijzigingsvoorstellen inzitten, mogelijk krijg je bijval op deze voorstellen hier op het breednetwerk.
 
Jean-Luc Rouvroye zei:

Ik heb 2 vragen:

1. Waarom ontbreekt de klant? In de naamomschrijving wordt deze niet genoemd. Bij een gemeente zal zo'n driekwart van de zaken gestart worden door een externe trigger. Lijkt mij het belangrijkste element voor de bedrijfsvoering. Per zaak leg je vast: klant, product, datum aanvraag.

2. Waarom is een classificatie code verplicht, als je al een classificatie omschrijving hebt?

Alleen even op pnt 2:

De UDC (en op basis daarvan de BAC) is een "universele cijfercode" voor "machines" handig.

Ik heb in het verleden gebruik gemaakt voor het toen aan te maken "fileplan" van de "begrotingnummers".

Op die wijze kun je de "relatie" (=metadata) tussen begroting en rekening en "documentaire bewijslast" goed behouden.

nu na 7 jaar werkt het nog steeds zo.

Maar binnenkort krijgt het "bestuur" een (en alleen nog maar) digitale jaarrekening met een "app". Dus in de jaarrekening zitten extra"functionaliteiten" gebakken. Dat wordt smullen voor de PDF- "aanhangers"

Andre, stemmen jullie dit profiel ook af met leveranciers van DMSsen ? Zou wenselijk zijn.

Er vind afstemming met leveranciers plaats in het regulier overleg van KING met leveranciers en (daarbij enkele) gebruikersverenigingen. Die wenselijkheid zien wij ook. Wij juichen ook toe dat het TMLO gebruikt gaat worden en dat bij die toepassing ook TMLO vanuit organisaties wordt geïmplementeerd. Daarbij is het handig om via klankbordgroep (Decos) en gebruikersverenigingen (Verseon en BCT) de leverancier om een collectieve 'change' te vragen. Voor gebruikers van Filenet, Hummingbird, E-docs en wat er verder nog meer 'draait' zijn die leveranciers nog bij KING, nog via gebruikersvereniging in NL niet in 'beeld'. Daar zal het vooral moeten komen van lokaal samenwerkende gebruikers. Het zou ook zomaar kunnen zijn dat het toepassingsprofiel redelijk denkend in de software gedekt wordt: daarom juist hier een oproep om de toepassing met elkaar te delen. Het aantal reacties tot nu toe is kwalitatief bemoedigend, echter kwantitatief nog zeer dun. Zo ontbreekt de toepassingspraktijk of de wens dit te gaan doen door advies en inspecties m.i. nog geheel. Enfin: in het archiefwezen heeft alles 'net als goede koffie' en het 'houden van goede muziek' even tijd nodig. Kortom leveranicers hebben de aandacht: naar wij hopen vooral 'in het veld'. Implementatie bij leveranicers maakt wel deel uit van het pva fase 2 'implementatie': we mikken daar op KING en 'de crowd'.

Van BCT (Corsa) heb ik bericht ontvangen dat ze het willen oppakken. Als je de contactgegevens nodig hebt, laat het me weten. Zij zijn tevergeefs op zoek gegaan naar een contactpersoon bij de VNG over dit onderwerp, maar ik heb ze nu actueel kunnen informeren.

Goedemorgen Jean-Luc,

1. Bij het TMLO (en ookal bij het TLO) mis ik ook inhoudelijke elementen maar dan bedenk ik me weer dat het toepassingsprofiel niet bedoeld is als een standaard om het zaakgericht werken te ondersteunen of om vorm te geven aan het model van een DMS, of richting te geven aan inhoudelijke processen of iets dergelijks.

Bij de gemeente Haarlem schenken wij er aandacht aan vanuit de pilot e-Depot met het Noord-Hollands Archief. Het TMLO lijkt mij dan ook ingestoken op het archiefbeheer wat volgt na de dynamische fase. Het richt zich op de metadata die later van belang zijn. Niet zozeer wat er nu binnen een archiefvormende organisatie nodig is. Het belang van de uitgewerkte elementen is duidelijk maar voor de dynamische fase is het niet afdoende. Vandaar ook, lijkt mij, dat een 'klant' niet vast te leggen is binnen het TMLO. Overigens, elke organisatie kan zijn eigen toepassingsprofiel opstellen en vaststellen, toch? Als je daarbinnen maar rekening houdt met de 'standaard'.

2. Wat betreft de BAC zeg ik hetzelfde als Henk Sligman. De code op zich is een universele cijfercode die gemakkelijk uit te lezen is. Lastiger vind ik dat het TMLO het verplicht stelt om naast deze code (ons allen bekend) ook nog vast te leggen welke omschrijving, bron en datum er bij de code hoort. Tuurlijk kan ik het zelf onderbouwen en begrijp ik waarom het handig is, maar 'ons' DMS heeft hier op het moment de voorzieningen niet voor. Al jaren worden alleen de codes vastgelegd. Zien anderen dit probleem ook?
 
 
 
Jean-Luc Rouvroye zei:

Ik heb 2 vragen:

1. Waarom ontbreekt de klant? In de naamomschrijving wordt deze niet genoemd. Bij een gemeente zal zo'n driekwart van de zaken gestart worden door een externe trigger. Lijkt mij het belangrijkste element voor de bedrijfsvoering. Per zaak leg je vast: klant, product, datum aanvraag.

2. Waarom is een classificatie code verplicht, als je al een classificatie omschrijving hebt?

@Josine, zie eerdere gedachtewisseling over BAC en zaakgericht werken via BREED link


@Henk en v.w.b. Geografisch gebied (element 9.2), eens dat dit een zeer relevant gegeven is. Er is evenwel zoveel mogelijk aangesloten bij de Richtlijn Metadatering Overheid en bij het Toepassingsprofiel Rijksoverheid. Gezien de 'nieuwheid' van het TMLO als standaard werd het nog te vroeg geacht om meer verplicht te stellen. Idealiter groeit die behoefte, en daarmee het draagvlak, in het gebruik. Bijvoorbeeld n.a.v. wijzigingsvoorstellen (m.i. 'Verplicht i.v.t.").

V.w.b. de derde dimensie, de Z-coördinaat, geen enkel probleem. Kan zonder meer. Codeer je locatie op de meest ideale en universele manier d.m.v. de "GML-string van de polygoon waarmee de locatie geografisch afgebakend wordt" (citaat uit het TMLO). Succes.

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden