BREED - over de grenzen van informatie
NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
TMLO-element: 7 - Plaats
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:
7 - Plaats
| Definitie: | Fysieke of virtuele locatie van record. |
| Waardering: | Verplicht i.v.t. |
| Waardering Richtlijn: | Optioneel |
| Herhaalbaar: | Nee |
| Overerving: | Ja |
| Toelichting: | Doel is het beheer en de terugvindbaarheid van het record en de bestanden die er deel van uit maken. Het gaat hier over de vindplaats van het archiefstuk, dossier, serie of het archief. De metagegevens van het record kunnen apart van de bestanden opgeslagen worden of bij die bestanden. In de praktijk zal het waarschijnlijk een combinatie van gescheiden opslag en embedding (inkapseling) zijn. Inkapseling heeft als voordeel dat de metagegevens onlosmakelijk verbonden zijn met het bestand maar een dergelijke decentrale bewaring heeft nadelen bij automatische zoekopdrachten. Opslag van de metagegevens in een centrale databank is daarom beter, maar vraagt een bijzondere zorg voor de koppeling met de desbetreffende bestanden.De locatie kan in de loop der tijd wijzigen. Indien zinvol kunnen ‘oude’ locaties geregistreerd worden met element 12: Event geschiedenis. |
| Waardenverzameling: | Fysieke locatie: het BAG-adres van de desbetreffende locatie, in de volgorde straatnaam, huisnummer, -letter en toevoeging, postcode, woonplaats. Virtuele locatie: de url van de virtuele locatie, beginnend met “http”. Andere locaties: benaming van bijvoorbeeld applicatie met unieke sleutel of locatie van offline storage. |
| Voorbeelden: | “Hamburgerstraat 28, 3512NS Utrecht” (adres van de archiefbewaarplaats) “http://ergens/absoluut/URI/met/absolute/verwijzing/naar/tekst.txt” |
Berichten in deze discussie
-
Permalink Antwoord van Marco Klerks op
-
Ik zou element 7. Plaats herhaalbaar maken. Voor bescheiden waarbij vervanging nog niet geregeld is, is er vaak een fysiek én een digitaal exemplaar.
-
-
-
Bij de waardeverzameling van 7. Plaats zou ik “http” niet eisen bij virtuele locaties, maar slechts als voorbeeld noemen. Andere protocollen zijn mogelijk.
-
-
Permalink Antwoord van Joost Salverda op
-
In element 21.1 worden voorbeelden gegeven van identificatiekenmerken van bestanden waarin soms ook de locatie is opgenomen (omdat die een bestandsnaam uniek kan maken) en bovendien wordt er gesteld dat het hier zou gaan om de identificatie (van de vindplaats) van telkens één bestand. Het lijkt er dus op dat (een deel van) 7 herhaald wordt om een bestand te identificeren. Dat lijkt me niet zuiver. Zou het niet beter zijn dit uit elkaar te trekken en te stellen dat 7 + 21.1 leiden tot een uniek identificeerbaar bestand op een virtuele locatie?
-
-
-
Duidelijk dat meerdere plaatsen van toepassing kunnen zijn. Maar, herhaalbaar of expliciet benoemen: fysieke plaats en virtuele plaats? Oftewel twee subelementen? Of kennen we nog andere typen plaatsen?
Marco Klerks zei:Ik zou element 7. Plaats herhaalbaar maken. Voor bescheiden waarbij vervanging nog niet geregeld is, is er vaak een fysiek én een digitaal exemplaar.
-
-
-
Kun je voorbeelden geven van andere protocollen? Doel je bijvoorbeeld op een bestandslocatie, de plaats in een map op een fileserver?
Marco Klerks zei:Bij de waardeverzameling van 7. Plaats zou ik “http” niet eisen bij virtuele locaties, maar slechts als voorbeeld noemen. Andere protocollen zijn mogelijk.
-
-
-
In de Richtlijn metagegevens overheid is met dit veld bedoeld de fysiek of virtuele plaats in de zin van postadres of mailadres (om contact met de beheerder van het archief te kunnen leggen neem ik aan). Wordt de RMO wel juist geïnterpreteerd op dit punt in TMLO? De toelichting uit TMLO doet vermoeden van niet, dus misschien zit daar het probleem. Wellicht dat de virtuele locatie van bestanden dan logischer op zijn plek is in veld 21.1? Of 21 moet worden uitgebreid met een dergelijk veld (virtuele locatie)?
-
-
-
De RMO verwijst naar NEN-ISO 23081-2, 2.4. Daar tref ik geen verdere info aan (het lemma bestaat niet), wel onder 9.2. Hieruit leid ik af dat het om zowel de fysiek als de virtuele locatie kan gaan: 'Plaats. Informatie over de locatie, de ligging of het gebied die verband houdt met de entiteit, zoals waar de entiteit zich bevindt of is opgeslagen, of waar er contact mee gemaakt kan worden gelegd. De plaats kan fysiek of virtueel zijn.' Veld 7 in TMLO staat echter geen herhaling toe (de RMO ook niet). In de huidige opzet kun je dus niet beide soorten locaties registreren, of moet je ze als één veld opnemen (wat me niet handig lijkt).
-
-
-
Een opmerking vanuit het rapport van de pilot e-Depot Achterhoek:
Uitsplitsen in twee subelementen: 'fysieke locatie' en 'virtuele locatie'? De laatste betreft een webadres. Of ook nog Bestandslocatie (server/map)? En is dat dan voldoende? Of nog een open andere mogeljkheid?
Wat betekent dit voor de vulling? Kunnen ze allevier gevuld zijn? Een webadres is bij voorkeur altijd gevuld en verwijst direct naar het desbetreffende record. Dus overerving vermijden?Opmerking besproken tijdens een van de workshops voor het informatiemodel TMLO:
Het lijkt handig dit te splitsen in fysieke en virtuale locatie. Denk bijvoorbeeld aan een maquette die fysiek bewaard moet worden. Er moet wel rekening gehouden worden met dat de fysieke en virtuele locaties veranderen bij overbrenging naar een e-Depot.
-
-
-
Scope was de gehele werkelijkheid, dus ook papier. Lijkt me dus een prima conclusie.
Op archiefniveau wil je wellicht het actuele post-, bezoek-, mail- en websiteadres van de archiefvormer opnemen. Op bestandsniveau de bestandslocatie. Wellicht ook in geval van series (bv beherende afdeling/dienst)?
Zie verder mijn vraag van 9 november: waar hoort de bestandslocatie thuis? Hier, of in 21? -
-
-
Als aanvulling op het voorstel vanuit de workshops: virtuele locatie wordt vastgelegd dmv een URI, deze dient te corresponderen met het identificatiekenmerk van het bestand.
-
-
-
N.a.v. de discussie is het Informatiemodel MLO (versie 0.8) t.o.v. het TMLO aangepast waarbij het element is gesplitst in twee subelementen:
- Fysieke locatie (tekst) en
- Virtuele locatie (d.m.v. een URI).
Er is niet voor gekozen om 'Plaats' op het niveau van Bestand op te nemen. Een enkel bestand staat niet op zich maar vormt tezamen met andere bestanden het archiefstuk. Je benadert dus altijd de bestanden van een archiefstuk als geheel, niet direct afzonderlijk (denk bijvoorbeeld aan de diverse bestandjes waaruit een webpagina is opgebouwd). -
Partner(s)
Sponsor(s)
Direct naar...
© 2024 Gemaakt door Marco Klerks.
Verzorgd door
