BREED - over de grenzen van informatie
NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Entiteiten Relaties Diagram Toepassingsprofiel
Voor de inrichting van DM/RM/BPM omgeving heb ik een Entiteiten Relatie Diagram gemaakt zodat er netjes kan voldoen aan het Toepassingsprofiel. (zie document)
Er zitten een aantal elementen in waar ik enige discussie over heb. Onder andere element 4 aggregatie. Volgens het toepassingsprofiel is dit een verplicht veld dat niet herhaalbaar is. In mijn analyse zou dit wel een herhaalbaar veld moeten zijn om dat er meerdere (geaggregeerde) contexten zijn waarin de record wordt gecreëerd, ontvangen of wordt gebruikt. Kan de classificatie, zaak, proces, inhoudelijk dossier, bestanddeel, et cetera zijn.
De vraag is wat is juist en of wijsheid hier.
- Bijlagen:
-
-
ERD toepassingprofiel.docx, 50 kB
-
Berichten in deze discussie
-
Permalink Antwoord van Erik Huurman op
-
Beste Wil,
Ik denk dat je het antwoord al zelf hebt gegeven!
Maar je zou hier twee kanten op kunnen 1 verplichtveld, maar dan voor alle contexten waarin een record word gecreëerd of voor elk context een verplicht veld aanhouden. Wij maken gebruik van Parentfields met daarop enkele aanvullingen. Daarmee behoud je de vrijheid om het invoerveld voor elk context te gebruiken die je maar wil.
Maar goed wat is wijsheid? Ik zou beide mogelijkheden eens uitwerken om te zien wat de mogelijke uitwerking zou kunnen zijn.
Succes en ik ben benieuwd naar je bevindingen.
Met vriendelijke groet,
Erik
-
Permalink Antwoord van Wil Rombout op
-
Hallo Erik,
Dank voor je reactie. De aangegeven oplossingsrichting is een optie, ook al aan gedacht.
Probleem is niet dat het een verplicht veld is, want dat vertaald zich naar één of meerdere aggregaties.
Maar volgens het toepassingsprofiel kan dat niet want het veld is niet herhaalbaar. De logica achter deze eis voor een digitale archiefomgeving ontgaat me dus en stelt me niet in staat om uit te leggen waarom dit een eis is.
Dus eigenlijk stel ik de eis(en) ter discussie.
In een analoge archiefomgeving is die overigens logisch en verklaarbaar.
Met vriendlijke groet,
Wil
-
Permalink Antwoord van MGroels op
-
Beste Wil,
Wij zijn in het kader van een pilotproject e-depot bezig met het TMLO: het mappen van de "oude" naar de nieuwe TMLO-waardige metadata en het vaststellen van nieuwe op TMLO gebaseerde metadata, zodat we aan alle verplichtingen voldoen. Op zoek naar voorbeelden kwam ik je bericht tegen.
Ik vraag me af hoe je het aggregatieniveau (element 3, niet 4?) van een record herhaalbaar kunt laten zijn?
Een record is toch altijd maar onderdeel van een niveau (serie, dossier, zaak, document en alle eventueel tussenliggende aggregatieniveau's). Voor de meerdere aggregatieniveau's waaronder een record/document/bestand wordt gecreëerd leg je de onderlinge relaties vast met element 15.1 en 15.2? (zoals record is onderdeel van dossier, dossier is onderdeel van werkproces, werkproces onderdeel van taakveld of iets dergelijks)
Of zie ik het verkeerd?
-
-
Hallo Mike,
Dank voor je reactie (het is 3 natuurlijk).
Je geeft aan dat voor meerdere aggregaties verwijs je naar het element 15. Daar begint (in mijn redenatie) het ook al te wringen omdat dit element vooral gericht is op aard van de relatie tussen records in een geaggregeerd niveau. En bovendien niet herhaalbaar is. Voor dat laatste een voorbeeld van hoe het kan knellen: een type relatie is bij voorbeeld een besluit op. Maar dezelfde record kan in een anderprocesactiviteit bijvoorbeeld een ondersteunende relatie hebben in een daar te nemen besluit. Twee relaties, maar je mag er maar één vastleggen.
Aggregeren is volgens mij het volgens bepaalde (formele) kenmerken groeperen van records. En dat kunnen er volgens mij meerdere zijn die niet altijd een vastgestelde hiërarchie hebben.
Mijn redenatie kan natuurlijk niet kloppen, maar ik denk dat de verschillende invalshoeken (archieftechnisch of gebruikstechnisch in een gedigitaliseerde dynamische werkomgeving) leiden tot interpretatieverschillen.
En of jij of ik het verkeerd ziet kan ik niet beoordelen. Eigenlijk zou er een autoriteit moeten zijn die dit soort interpretatieverschillen slecht.
-
-
Hoi Wil,
Element 15 is wél herhaalbaar, vandaar dat je dus relaties kunt leggen naar andere records. Daarnaast: "In het 1-entiteitmodel wordt het element Relatie gebruikt voor het koppelen van een record aan andere records op hetzelfde of een hoger aggregatieniveau." Daarna volgen voorbeelden die volgens mij schetsen wat jij ook beschrijft. Dus in mijn ogen heb je een record (besluit), dat gerelateerd is volgens element 15 aan andere records op hetzelfde aggregatieniveau maar bij een andere zaak of dossier, maar ook aan zijn eigen dossier of zaak op een andere aggregatieniveau. Zijn eigen aggregatieniveau is toch echter altijd archiefstuk of iets dergelijks - vandaar dat element 3 niet herhaalbaar is - lijkt mij.
Ik bedoelde of ik jouw verhaal verkeerd zag, maar dat was dus niet zo. En tja, wachten op een autoriteit die dan uiteindelijk weer iets niet kristalhelder beschrijft... dan kunnen we blijven wachten ben ik bang en daar hebben we geen tijd voor.
-
-
Halo Mike,
Interessant. In het Toepassingsprofiel Metagegevens Rijksoverheid is dit geen herhaalbaar veld.
Dus klaarblijkelijk zijn wijken TPR en TPLO op onderdelen van elkaar af.
Ik kan je verder volgen, maar ik ben van meming dat met relatie de aard van relatie aangegeven wordt en aggregratie om hierarchische aggregraties vast te kunnen leggen. Overigens doet een herhaalbaar veld 'aggregratie' niet af aan de eis als beschreven in TPR. Je hebt namelijk meerdere aggregraties, maar één van die aggregaties is niet herhaalbaar met een mogelijke waarde als: stuk of dossier of archiefbestandeel of........
-
Permalink Antwoord van Hans Dekker op
-
Een betere vertaling en uitleg van het aggregatieniveau vind je m.i. in ISAD(G) Nederlandse vertaling in hoofdstuk A1 op blz. 37 http://www.vvbad.be/sites/www.vvbad.be/files/bericht/bestanden/isad... Hier wordt gesproken over 'ordeningsniveau'.
Een bestanddeel kan uit meerdere stukken c.q. besluiten bestaan.
Partner(s)
Sponsor(s)
Direct naar...
© 2024 Gemaakt door Marco Klerks.
Verzorgd door
