[#37073] Fødested for faddere, dåpsvitner, pårørende m.fl

[Gjest Geir Thorud]

Kyrre kan tolkes slik at man krever at det skal kunne registreres fødested for faddere, dåpsvitner, (forlovere), pårørende, fødselshjelper, vaksinatør, lysningsforlanger, melder, brudgoms far og bruds far.Jeg har ennå tilgode å se at fødested er oppgitt for disse (og enda flere) roller i kirkebøkene. Å ha felter for dette i et registreringsskjema virker derfor helt undøvendig og kompliserende.For viede står det dog at dette gjelder brud og brudgom, men feltet er alikevel tillat å overføre for de andre rollene i en vielse.Er det riktig å tolke Kyrre slik at disse fødestedene må kunne registreres, eller kan man utelukke disse fra registreringsskjemaer og utelukke at man vil motta en fil der disse feltene er fyllt ut?

[Gjest Leif Kåre Solberg]

Jeg er prinsipielt for at registreringssystemer som dette, skal være mest mulig åpent for alle eventualiteter, slik at det ikke bare fanger opp ”det som er vanlig”. Denne fleksibiliteten bør etter mitt skjønn benyttes i stor grad når det gjelder spørsmål som å la være å legge inn unødvendige begrensninger på for eksempel antall roller eller rolletyper pr. hendelse.Derimot når det gjelder antall felt pr. rolle stiller saken seg annerledes. For mange felt pr. subenhet (rolle) lager et tungt håndterlig og uoversiktlig system både når det gjelder registrering og senere søking. Jeg er derfor enig i den hovedlinjen som er fulgt i Kyrre; antall felt pr. person er stort sett sanert på en fornuftig måte.Sporadiske registreringer av fødsler gir ikke grunnlag for å lage søkerutiner til felt som uansett vil være nærmest tomme. Eventuell fødestedinformasjon kan med fordel legges i merknadsfeltet. Da vil den være tilgjengelig, og nyttig, når personen først er funnet på annen måte.Hvis man virkelig ønsker å opprettholde et felt for fødested for alle rolletyper bør det begrunnes på en overbevisende måte. I motsatt fall bør det gjøres klart i Kyrremanualen at bare i de kirkebokskjema hvor fødested er eksplisitt oppført som kolonneoverskrift (vigsler fra 1820), skal det registreres i dedikert felt, og da bare for de aktuelle roller som kolonneoverskriften angir. Andre sporadiske opplysninger om fødested skal føres i merknadsfeltet.

[Gjest Geir Thorud]

Har Digitalarkivet sluttet å svare på spørsmål vedr. Kyrre? Jfr innlegg 1.

[Gjest Bente K. Hervik]

I noverande versjon av Kyrre skal felt som fødestad vera med for alle personar i den endelege xml-fila. Om dette er den mest føremålstenlege måten, kan vurderast fram mot neste versjon av Kyrre.Korleis registreringsskjema etter Kyrre er utforma, er opp til den som lagar skjemaa. Digitalarkivet vil utvikla eit konverteringsprogram der ein koplar felt for utlegging i DA og konvertering til xml. Felt som ikkje er nytta under registrering vil då verta ståande tomme, men verta tatt med i xml-fila.Dei som ynskjer å laga program som konverterer til Kyrre sine xml-filar, må på ein eller annan måte få inn desse felta for at ein skal oppfylla krava til Kyrre.

[Gjest Geir Thorud]

Her må de være en misforståelse. I min versjon av Kyrre er ikke fødested obligatorisk i XML, hverken i DTDen eller i vedlegg 2, dvs fødested trenger ikke være med for alle personer i xml-fila. Et felt som ikke er obligatorisk trenger man ikke overføre tomme felter for - i XML. Jeg ser ingen grunn til å endre dette i versjon 2.0 av Kyrre. Hvilken funksjon/semantikk skulle man tilordne et tomt felt?Det er mulig at jeg har formulert spørsmålet klønete, men jeg tror ikke det. Det var ikke obligatorisk tilstedeværelse som spørsmålet gjalt, men om feltet overhodet skal kunne være tilstede og således må kunne håndteres av et generelt program som supporter Kyrre fullt ut. Dvs, problemet er ikke om et felt MÅ være tilstede, men at det KAN være tilstede.Det hadde vært fint hvis dere også prøvde å se dette fra en implementatør av registreringsprogram sin synsvinkel. Det er vel tvilsomt om noen vil implementere forskjellige skjema for registrering og skjema for å vise mottatte filer, dvs at skjemaet må kunne vise fram de felter som kan være tilstede i en innkommende fil. Det må derfor være standarden og ikke hver enkelt implmentør som avgjør hvilke felt som skal være tilstede. Jeg tenker nå på et generelt registreringsskjema for f.eks dåp i et skikkelig registreringsprogram, ikke et skjema som hver enkelt skreddersyr til den aktuelle kilden i f.eks Excel.Konverteringsprogrammet som du nevner er i denne sammenheng lite interessant, og jeg forstår ikke hva det du skriver om tomme felter har med saken å gjøre.Det hadde også vært fint om dere sa ifra allerede nå hvis dere mener at det er behov for fødested i de rollene som er nevnt. Slik saken står ber dere essensielt om at man for versjon 1.0 av Kyrre implementerer en masse felter som etter mitt og andres skjønn er totalt bortkastede, og kompliserende i et registreringsskjema, for så å evt vrake det hele når versjon 2.0 kommer. En profesjonell standardsetter ville ha sørget for å rydde opp i slike ting så raskt de ble oppdaget, f.eks ved å utgi en versjon 1.1 eller en 'Implementors guide'. Med de stadige henvisninger til ting som bør vurderes i versjon 2.0 av Kyrre er det et spørsmål om man ikke bør vente på versjon 2.0 før man implementerer.Problemet gjelder ikke bare fødested, men også fødselsdato og andre felter som tidligere er nevnt i temaet om plassering av felter på hendelse/person nivå (tema 36122).

[Gjest Geir Thorud]

En tabell for hver type handling som langs den ene aksen lister roller og langs den andre lister felt, med med et kryss som markerer tillatte felt for rollen, ville løse problemet - hvis det er enighet om at f.eks fødested og fødselsdato er uaktuelt for faddere etc.

[Gjest Bente K. Hervik]

Det er mogleg å tenka seg at fødestad, fødselsdato etc. for t.d. fadrane er oppgitt i kyrkjebøkene, og eg meiner difor at desse felta ikkje bør fjernast for desse rollene.Når det gjeld om felta er obligatorisk eller ikkje, så forstår eg det slik at det ikkje treng vera utfylt, men at det skal vera med i xml-fila.I Augustus og ein del andre registreringsprogram kan ein skjula dei felta ein ikkje treng slik at skjemaet vert enklare, og dette ser eg på som ei god løysing for å få eit meir oversiktleg registreringsskjema utan at ein fjernar moglegheitene til å bruka felta om det skulle verta naudsynt.Eg skal be Lars Nygaard gje deg eit meir utfyllande svar.

[Gjest Lars Nygaard]

Her er det flere forhold som er tatt opp, og jeg vil prøve å svare på de viktigste. Jeg tar utgangspunkt i avsnitt 1 og 3 i Geir Thoruds innlegg 5:Det han sier i avsnitt 1 er riktig: Felt som ikke er markert som obligatoriske i vedlegg 2 og DTDen, trenger ikke å være med i XML-filen. Det er en av de gode tingene med XML at man bare tar med de opplysningene man reelt har, bortsett fra noen få essensielle felt som er markert som obligatoriske i tilhørende DTD. Når det gjelder filer i formatet 'SDV Flat struktur', gjelder det samme: Her er det mulig å tilpasse feltutvalget til den enkelte kilden. Feltene må deretter 'mappes' interaktivt mot den komplette Kyrre-strukturen i det konverteringsprogrammet Bente snakker om. Formatet 'SDV hierarkisk struktur' er imidlertid avhengig av at alle personposter har like mange felt i en fast rekkefølge, så her må f.eks. feltet for fødested for alle bipersoner også tas med selv om det i praksis alltid er tomt for noen av rollene. En struktur der feltutvalget i personpostene tilpasses hver enkelt rolle, slik Geir antyder i innlegg 6, blir for komplisert å hanskes med. Vi ser det som en fordel med feltstrukturen i Kyrre at den tar høyde for uvanlige opplysninger, f.eks. fødested på faddere.Så til forholdet mellom registreringsprogrammer og fremvisningsprogrammer. Etter min oppfatning bør begge disse ha den samme (komplette) datastrukturen i den underliggende databasen, og alle fremvisningsprogrammer bør vel også kunne vise fram alle lagrede opplysninger. Jeg forstår det slik at Geir utvikler et registreringsprogram med faste felt for ulike roller i skjermbildene, og han kan da velge å utelate helt usannsynlige felt for noen av rollene. Men det kan være at andre lager registreringsprogrammer med et tabellfelt for alle personene, og da får alle roller automatisk det samme feltutvalget. Det samme vil skje hvis noen registrerer i en enkel to-tabells database (handling/person), f.eks. i direkte i Access. Det kan altså ikke utelukkes at det skapes Kyrre-datafiler (i alle de tre formatalternativene!) der det f.eks. forekommer fødested på faddere eller andre bipersoner.Jeg håper dette var litt klargjørende. Hvis ikke, får jeg komme tilbake med et nytt forsøk.

[Gjest Geir Thorud]

Det er mye man kan TENKE seg kan finnes i kirkebøker, men hvis vi skulle ha felter for alt dette ble det nok mange felter som måtte legges til i Kyrre.I tema 34944 argumenteres det MOT å ha felter for Mor/Fars leiermål nummer i Kyrre, med den begrunnelse at det ikke finnes felter for dette i kirkebøkene. Heller ikke for faddere, eller de andre rollene som er nevnt, finnes det felt med overskrifter som angir at fødested eller fødselsdato skal registreres, og da bør vel det samme argumentet gjelde for disse. Jeg utelukker ikke at det et sted eller to kan finnes innført fødested for en fadder, men jeg våger å påstå at leiermål nr forekommer minst hundre ganger oftere i kirkebøkene enn fødested/fødselsdato for faddere. Det virker ikke på meg som om dette er noen spesielt konsekvent argumentasjon. Hvis det er så mye om å gjøre å få inn fødested etc. som praktisk talt aldri forekommer, hvorfor har man da ikke tatt inn felter for andre typer informasjon som faktisk er mye mer hyppig forekommende i kirkebøkene.Jeg kan ikke tolke svaret på annen måte enn at DA ikke kjenner til at Fødested og Fødselsdato i vesentlig grad faktisk forekommer for de nevnte roller i kildene, ellers hadde man vel argumentert med det. Det kan være greit å ha dette på det rene før man går videre, og er min tolkning feil så får noen protestere. Jeg har mer tro på Lars sin forklaring som essensielt går ut på at man har valgt å favorisere en bestemt måte å implementere standarden på, den kom da heller ikke som noen stor overraskelse.Jeg har ikke noen virkende versjon av Augustus så jeg vet ikke hva man gjør der. Men å skjule feltet er ikke nok, det vil allikevel oppta plass i registreringsskjemaet – opp til 26 felter. Å lage et dynamisk utformet registreringsskjema vil kreve så mye arbeid at det på ingen måte kan forsvares for å løse et problem som ikke burde eksistert.

[Gjest Geir Thorud]

Det over (9) er svar på Bentes innlegg nr (7). Jeg kommer tilbake til Lars sitt innlegg senere.

[Gjest Geir Thorud]

Til Lars sitt innlegg nr (8). Dette blir langt, men det kreves for å gå inn på realitetene i saken.1. Jeg skiller i det følgende mellom tabeller som finnes i den underliggende datastrukturen (lagringstabeller) og de som brukes i registrering/framvisningsskjemaet (skjematabeller). Jeg er enig i at en tabell for hendelse og en tabell for personer/roller er en god løsning for den underliggende strukturen, men jeg er ikke enig i at dette er noen god løsning for skjemaet. Skjemaet bør bruke flere skjematabeller for rollene, som alle lagrer data i den samme underliggende lagringstabellen. For døpte kan man f.eks ha en skjematabell for foreldre (og evt. barnet) og en for faddere, vitner, etc, der man i den enkelte skjematabell velger ut de felter fra lagringstabellen som for de aktuelle roller faktisk forekommer i kildene. Selv om fødested etc. for rollen finnes i lagringstabellen, vises feltene ikke i skjematabellen, og det blir ikke mulig å registrere data i feltene for faddere etc. Sammenlignet med å bruke bare en skjematabell for alle roller, unngår man på denne måten å forkludre skjemaet med et stort antall felter som aldri vil bli benyttet. Den måten Kyrre spesifiserer hvilke felter som kan være tilstede, utelukker dessverre en slik optimal design av skjemaet.Å bruke flere skjematabeller krever mindre plass på registreringsskjemaet, det er det viktigste, men man får også brukket opp en kjempestor tabell slik at det blir lettere for øyet å finne rollene (det blir også vanskeligere å bomme på linjene), og man hindrer at det ved en feiltakelse registreres data i et felt som aldri er i bruk i kildene. For de som ønsker å lage seg sitt eget personlige leketøy av en registreringsdatabase i Access (noe jeg tror man blir fort lei når man ser hvilket arbeid som ligger bak Augustus og andre mer fullstendige implementasjoner) er det en meget enkel sak å implementere flere skjematabeller. Når man først har laget en tabell med en spørring for å velge roller, er det gjort på noen få minutter å lage en til.Skulle noen allikevel ha ønske om å ha kun EN skjematabell for alle roller finnes det mange måter å hindre at det registreres data i felter som ikke finnes i kildene. I en seriøs implementasjon trenger man f.eks funksjoner for å kunne hoppe over felter som ikke brukes i den aktuelle kilden, og da vil det være en enkel sak å hindre at visse felter aldri brukes, uansett kilde. De som mener at det er fordeler med en tabell bør også være de som rydder opp etter seg, og ikke forhindrer andre å lage en bedre løsning, ved å kreve at man må implementere en masse felter som ikke er i bruk. Eller er det slik at Kyrre er skreddersydd for late programmerere som lager dårlige brukergrensesnitt, og samtidig hindrer de som vil gjøre en seriøs jobb?Jeg har laget en skisse som viser implementasjon av de to alternativene i skjema i Access. Se http://www.slektshistorielaget.no/kyrre_eks.jpg Alternativet med flere skjematabeller øverst, det med en stor tabell nederst.2. Jeg bør vel også presisere at problemet ikke bare gjelder fødested og fødselsdato, men også fødselsår, alder og i verste fall en rekke andre felter som i Kyrre er tilordnet roller. Kyrre tillater at vielsesdato registreres for faddere, at dødsårsak registreres for pårørende, at ekteskapsnummer og vaksinasjon registreres for forlovere, for å nevne noen eksempler. Er det ingen grense for hva som kan registreres av informasjon om faddere, pårørende, forlovere etc., eller kreves det at alle program skal kunne registrere/vise slik info? Hvordan kan en vite hvilke felter en annen implementasjon, som man mottar en fil fra, har tillat registrering av for alle roller? I noen tilfelle er det vel selvsagt at et felt ikke er aktuelt for en rolle, men det er ikke alltid like lett. Er det ikke standardens oppgave å presist beskrive hvilke felter som er aktuelle?En presis spesifikasjon hindrer ingen måter å implementere på, men det gjør Kyrre nå. 3. Kyrre hevder å være en standard. I all seriøs utarbeiding av åpne standarder for datautveksling der flere interessenter er involvert, har man i minst 40 år hatt et grunnleggende prinsipp om at standardene skal være mest mulig uavhengig av implementasjonsmetode. Når det er uenighet om måten å implementere på, søker man å bruke nøytrale/objektive kriterier for å spesifisere hvilke data som kan overføres, basert på de data i den virkelige verden som standarden er ment å overføre. I dette tilfelle vil et slik kriterium være å PRESIST spesifisere hvilke data som faktisk forekommer i kildene med en viss sannsynlig minimum hyppighet, og ikke tillate en masse data som ikke forkommer i kildene, fordi man favoriserer en bestemt (og etter mitt skjønn mindre god) måte å implementere på. Det er ingen grunn til å favorisere enkle leketøysbaser fordi behovet for slike vil bli borte hvis Augustus blir et bra program, men det kan jo være at problemet er at Augustus ikke kommer til å ha en bedre løsning enn en kjempestor person tabell?4. Det at man har plassert informasjon som bare skal registreres en gang pr handling f.eks Dødsårsak, Lækjar, Ekte/Uekte, og mange flere, på personnivå kompliserer implementasjonen mye mer enn f.eks å bruke flere skjematabeller som nevnt over – med mindre man i en del tilfeller bruker ekstremt stor skjematabell for rollene. Det virker ikke som dere har tenkt så mye gjennom hvordan standarden skal implementeres i registreringsprogram.5. Jeg mener derfor fortsatt at det er behov for en presisering av hvilke felt som kan registreres for en rolle, f.eks i form av en tabell som nevnt i innlegg (6).6. Jeg tviler på at jeg noen gang kommer til å se en fil av typen SDV hierarkisk struktur, så jeg har ikke noe problem med at det sendes tomme felt for fødested, fødselsdato etc for alle rollene i dette formatet (eller XML), men feltene kan etter min mening aldri ha reelt innhold. (Jeg tror dog man i dag skal lete lenge etter et implementeringsverktøy (database/regneark) som ikke ved import håndterer at slike tomme felter mangler på slutten av en ”datalinje”/post.)