Flytte datatype fra metadataelementene i objektsortert metadatakatalog til metadatakatalogen

[hanber]

Siden datatypen er knyttet til metadataelementet uavhengig av objektene elementene inngår i, bør datatypen knyttes direkte til metadataelementet i den ikke-objektsorterte katalogen. Jeg foreslår derfor å fjerne datatype fra tabellene i objektsortert metadatakatalog, og legge til datatype som en egenskap ved metadataelementene i yaml-filene.

[petterreinholdtsen]

[Hans Fredrik Berg]

Siden datatypen er knyttet til metadataelementet uavhengig av objektene elementene inngår i, bør datatypen knyttes direkte til metadataelementet i den ikke-objektsorterte katalogen. Jeg foreslår derfor å fjerne datatype fra tabellene i objektsortert metadatakatalog, og legge til datatype som en egenskap ved metadataelementene i yaml-filene.

Tror dette er en god ide. Det fjerner en kilde til inkonsistenser i spesifikasjonen, hvis datatype fjernes fra tillegg B. Merk, datatype er allerede i YAML-filene, så dette løses ved å fjerne datatype fra listene over objektsorterte elementer i tillegg B. Eneste ulempen jeg ser er at noen datatyper i objektsortert katalog omtaler ikke bare datatype, men også hvilken entitet det henvises til (eksempel arkivdel.systemID og registrering.systemID). Jeg har ikke sjekket om det er konsistent oppgitt i tillegg B, slik at enhver bruk av M### henviser til samme entitet, men hvis ikke vil litt informasjon gå tapt. Det kan løses ved å sikre at M###-entiteter alltid gjelder for et spesifikt objekt, hvilket jeg tror er tilfelle i dag. Da gjenstår det vel kun M-koden, navn, N4-navn og multiplisitet i tabellene i tillegg B.

…

-- Vennlig hilsen Petter Reinholdtsen

[oivkru]

Hvis det er riktig at vi har vært konsekvente her, at datatypen er den samme i alle objektene metadataelementet inngår i, er jeg helt enig.

Forekomster er også i både metadatakatalogen og i objektsortert, men kolonnen i tabellene i objektsortert sier ikke det samme som feltet i metadatakatalogen. I metadatakatalogen er forekomst enten En eller Mange. I objektsortert er det varianter av 0-1, 0-M, 1, 1-M. Man må kombinere Forekomster med feltet Obligatorisk/valgfri i metadatakatalogen for å få samme informasjon som i objektsortert. Jeg har ingen kontroll på om vi har vært konsekvente her, men samme prinsipp gjelder vel, det bør stå kun ett sted.

Er det fortsatt nødvendig å vise tilbake til N4-navnet, eller kanskje den kolonnen kan fjernes? De som har behov for å sjekke det kan uansett gjøre det ved bruk av versjonene frem til nå.

[petterreinholdtsen]

[Øivind Kruse]

Hvis det er riktig at vi har vært konsekvente her, at datatypen er den samme i alle objektene metadataelementet inngår i, er jeg helt enig.

Så vidt jeg vet er det tilfelle. Alle avvik er feil i spesifikasjonen. Det har vært endel som er fikset.

Forekomster er også i både metadatakatalogen og i objektsortert, men kolonnen i tabellene i objektsortert sier ikke det samme som feltet i metadatakatalogen. I metadatakatalogen er forekomst enten En eller Mange. I objektsortert er det varianter av 0-1, 0-M, 1, 1-M. Man må kombinere Forekomster med feltet Obligatorisk/valgfri i metadatakatalogen for å få samme informasjon som i objektsortert. Jeg har ingen kontroll på om vi har vært konsekvente her, men samme prinsipp gjelder vel, det bør stå kun ett sted.

Merk, dette er ikke lenger tilfelle. Forekomst-informasjonen ble fjernet fra YAML-filmene som utgjør metadatakatalogen i c3bd9d2, med henvisning til #24 og #61. Obligatorisk/valgfri er også fjernet fra metadatakatalogen i e887608 med henvisning til #24 og #62, da en verdi kan være valgfri i et objekt og obligatorisk i et annet.

Er det fortsatt nødvendig å vise tilbake til N4-navnet, eller kanskje den kolonnen kan fjernes? De som har behov for å sjekke det kan uansett gjøre det ved bruk av versjonene frem til nå.

Aner ikke. Jeg har ikke hatt nytte av N4-navnene.

…

-- Vennlig hilsen Petter Reinholdtsen

[petterreinholdtsen]

[Petter Reinholdtsen]

Merk, datatype er allerede i YAML-filene, så dette løses ved å fjerne datatype fra listene over objektsorterte elementer i tillegg B.

Jeg tok en ekstra titt, og riktig nok er datatype i alle YAML-filmene, men den blir ikke vist frem i tillegg A. Det kan enkelt fikses ved å legge inn denne endringen i programmet som lager innholdet i tillegg A, slik: diff --git a/scripts/metadata2rst b/scripts/metadata2rst index a19a66c..5944df6 100755 --- a/scripts/metadata2rst +++ b/scripts/metadata2rst @@ -67,6 +67,7 @@ def main(): else: fields = ('Nr', 'Navn', + 'Datatype', 'Definisjon', 'Arkivenhet', 'Kilde', Skal vi endre? Datatype har ikke vært med i tillegg B helt fra den var egen docx-fil, dermed ble den heller ikke med i det nye git/RST-baserte opplegget.

…

-- Vennlig hilsen Petter Reinholdtsen

[hanber]

Ja, ta med datatype fra YAML-filene i 110-vedlegg_1_metadatakatalog-auto.rst, og kall datatypen ID der hvor datatypen i objektsortert er .systemID. Ikke slett kolonnen Datatype i objektsortert før vi har fått med beskrivelse av hvilke objekttyper som kan refereres i Betingelser i YAML-filene, f.eks. "Må referere til en ".

Jeg synes også vi kan droppe N4-feltene nå.

[petterreinholdtsen]

[Hans Fredrik Berg]

Ja, ta med datatype fra YAML-filene i 110-vedlegg_1_metadatakatalog-auto.rst, og kall datatypen ID der hvor datatypen i objektsortert er <objekttype>.systemID. Ikke slett kolonnen Datatype i objektsortert før vi har fått med beskrivelse av hvilke objekttyper som kan refereres i Betingelser i YAML-filene, f.eks. "Må referere til en <objekttype>". Jeg synes også vi kan droppe N4-feltene nå.

Jeg laget <URL:#116 > for å legge inn datatype fra YAML-filene i tillegg A. De øvrige omskrivningene må nok i stor grad gjøres i YAML-filene, ikke i skriptet som lager 110-vedlegg_1_metadatakatalog-auto.rst fra YAML-filene, og krever mer jobb.

…

-- Vennlig hilsen Petter Reinholdtsen

[hanber]

Jeg har lagt inn "Må inneholde gyldig systemID for (aktuell arkivenhet)" som betingelse i de aktuelle YAML-filene.

Ved gjennomgangen ser jeg at
M221 referanseForrigeMoete burde referere til moetemappe, ikke mappe.
M222 referanseNesteMoete burde referere til moetemappe, ikke mappe.
M215 referanseAvskrivesAvJournalpost burde referere til journalpost, ikke registrering.
M223 referanseTilMoeteregistrering burde referere til moeteregistrering, ikke registrering.
M224 referanseFraMoeteregistrering burde referere til moeteregistrering, ikke registrering.

Jeg har ikke endret disse, i tilfelle det faktisk er ment slik. @oivkru, @monadani, @AnnKnu: Vet dere noe om dette?.

[petterreinholdtsen]

[Hans Fredrik Berg]

Ved gjennomgangen ser jeg at M221 referanseForrigeMoete burde referere til moetemappe, ikke mappe. M222 referanseNesteMoete burde referere til moetemappe, ikke mappe. M215 referanseAvskrivesAvJournalpost burde referere til journalpost, ikke registrering. M223 referanseTilMoeteregistrering burde referere til moeteregistrering, ikke registrering. M224 referanseFraMoeteregistrering burde referere til moeteregistrering, ikke registrering.

Kan det ha noe med at systemID-verdien som skal være i referansen hører til mappe og registrering, ikke moetemappe, journalpost og moeteregistrering?

Jeg har ikke endret disse, i tilfelle det faktisk er ment slik. @oivkru, @monadani, @AnnKnu: vet dere noe om dette?.

Håper noen av dem vet hvorfor det ble slik. :) Jeg skal få oppdatert RST-filer og PDF i kveld.

…

-- Vennlig hilsen Petter Reinholdtsen

[hanber]

Det kan nok være en forklaring, men hvis man f.eks. har definert en eiendomsmappe som spesialisering av mappe og lar referanseForrigeMoete referere en eiendomsmappe blir det feil. Jeg har lyst til å rette det med en gang, men det har kommet så mange krav fra brukerne om å flytte metadata fra spesialiseringene til generaliseringene at det er mulig det er gjort med overlegg.

[oivkru]

Jeg har lagt inn "Må inneholde gyldig systemID for (aktuell arkivenhet)" som betingelse i de aktuelle YAML-filene.

Ved gjennomgangen ser jeg at
M221 referanseForrigeMoete burde referere til moetemappe, ikke mappe.
M222 referanseNesteMoete burde referere til moetemappe, ikke mappe.
M215 referanseAvskrivesAvJournalpost burde referere til journalpost, ikke registrering.
M223 referanseTilMoeteregistrering burde referere til moeteregistrering, ikke registrering.
M224 referanseFraMoeteregistrering burde referere til moeteregistrering, ikke registrering.

Jeg har ikke endret disse, i tilfelle det faktisk er ment slik. @oivkru, @monadani, @AnnKnu: Vet dere noe om dette?.

Vet ikke med sikkerhet, men regner med det er som @petterreinholdtsen skriver, at det er fordi systemID er på arkivenheten, og ikke spesialiseringen. Det ser ut som alle referansemetadata refererer til systemID på arkivenhet.

Hvis en lar referanseForrigeMoete vise til en eiendomsmappe, eller andre spesialiseringer av mappe som ikke er moetemappe, er det en åpenbar feil. Er det en reell risiko, og er det nødvendig å endre for å fjerne risiko for dette? Bruker som legger inn referansen vil uansett ikke forholde seg til systemID, og taste dette manuelt inn når referansen opprettes, vil anta brukergrensesnittet vil legge til rette for at dette gjøres på en litt lettere måte, som reduserer risiko for slik feil?

[hanber]

Jeg endrer gjerne betingelsene i yaml-filene slik at dette blir riktig.

Det aktualiserer diskusjonen om datatypen til systemID.
I metadatakatalogen står det nå (foreløpig) at datatypen til f.eks. M202 referanseForloeper er systemID, men M001 systemID er ikke en datatype, men et metadataelement av typen Tekststreng.
i metadatakatalog.xsd er det et metadataelement M016 ID, men jeg mener det ikke er noe metadataelement, men en datatype. Det er ingen objekt som inneholder metadataelementet M016 ID, men mange har M001 systemID.
systemID er da et metadataelement av typen ID, på samme måte som M011 saksaar er av typen integer og M100 saksdato er av typen date (inntil videre). Verken integer eller date er definert som metadataelementer, hvorfor skal da ID være det?
Jeg foreslår at vi beholder ID som en datatype (definert ved et regulært uttrykk), men legger det øverst i skjemafilen uten et metadatanummer (M016).
I så fall får f.eks. M202 referanseForloeper datatypen ID (ikke systemID).
PS. Jeg er klar over at skjemaet bare beskriver typer, men jeg oppfatter saksdato som en attributtype mens jeg oppfatter date som en datatype, på samme måte som at systemID er en attributtype, mens ID er en datatype.