Project

General

Profile

Innmeldte kommentarer #1071

Kodelisteverdier i henhold til navneregler

Added by Magnus Karge about 5 years ago. Updated almost 5 years ago.

Status:
Tilbakemelding
Priority:
Normal
Assignee:
I6 med flere fra tidligere STU
Start date:
2016-10-11
Due date:
Standard:
SOSI standard Regler for UML-modellering
Kontaktperson:
Magnus Karge
Bedrift, etat, virksomhet:
Kartverket
E-mail kontaktperson:
magnus.karge@kartverket.no
Utdyping av beskrivelse:
Ansvarlig arbeidsgruppe:
SOSI AG1
Type melding:
Kommentar
Beslutning:

Description

krav/navning i SOSI Regler for UML-modellering 5.0 oppfattes å være for strengt. Kravet sir eksplisitt at egenskapsnavn (= kodenavn) skal starte med liten bokstav. Dette er ikke en bra løsning i alle tilfeller.

Foreslått endring: Legge til en setning "Der forkortelser er brukt som egenskapsnavn kan navnet starte med stor bokstav."

---------------------------------------------------------------
DOKUMENTERT MAILUTVEKSLING:
---------------------------------------------------------------

Jeg er tilhenger av bisetningen Magnus nevner, det virker meningsløst med lowerCamelCase i de eksemplene han nevner (bIM, rGB og nS3420). Ut over det får vi skaffe oss litt flere erfaringer fram mot en revisjon. D

Jeg har også lurt litt på tolkningen av krav 16, hva er skilletegn? Under krav 6 fikk vi inn en presisering av hva som er ulovlige tegn. Se også anbefaling 10, som sier at vi helst ikke skal bruke «-» og «_».

Et viktig moment er også det krav 6 sier om at kodene skal være forståelige. Jeg mener det må være viktigere enn en rigid bruk av lowerCamelCase, og at det da også må være greit å bruke de lovlige skilletegnene «-» og «_».

Oppsummert/konklusjon: For meg ser det ut til at vi er enige om at det kan brukes fornuft i tolkningen av krav og anbefalinger her.

Jeg skal jobbe videre med scriptet mitt for omkoding fra NVDB-verdier til SOSI-verdier, skal se på Kent sitt script også.

Mvh
/Knut Jetlund

Fra: Magnus Karge [mailto:]
Sendt: 30. september 2016 11:00
Til: Erling Onstein <>; Kent-Jacob Jonsrud <>; Jetlund Knut <>; Morten Borrebæk <>
Kopi: Børnes Vilhelm <>
Emne: SV: Kodelisteverdier i henhold til navneregler

Tror det som Erling konkluderer med passer ganske bra med det som er påkrevd i 5.0 regler for UML-modellering.

Krav/7 oppfatter jeg til å sikre at den fulle forklaringen som Erling nevner er på plass.

/krav/7 Alle koder er konsepter, og skal ha tilstrekkelig definisjon. Det vil si alle unntatt lister over kjente egennavn.

Krav/6 sir at kodenavn skal følge regler for egenskapsnavn og skal være forståelige/huskbare (= ikke meningsløse?, mener i en tidligere versjon brukte vi ordet meningsløs som ikke overlevde høringsrunden). Krav/6 leder oss også til krav/navning som sir eksplisitt at egenskapsnavn (= kodenavn) skal starte med liten bokstav. Akkurat det siste er vel det som både Knut, Kent og jeg oppfatter som litt for strengt. Så en bisetning her à la: "Der forkortelser er brukt som elementnavn, kan navnet starte med stor bokstav" vil hjelpe oss at vi ikke er nødt til å innføre et enda større krypteringsnivå (bIM? rGB? nS3420?) og vil fortsatt være konform med NCName-regler.

/krav/navning Navn på egenskaper, roller, operasjoner og parametere skal starte med liten bokstav, og så fortsette med stor bokstav på hvert nytt ord (med unntak av konstruktøroperasjoner som har samme navn som klassen). Navn på pakker, klasser og assosiasjoner skal starte med stor bokstav. (Fra ISO 19103:2015 Anbefaling 11, se også /krav/6)

Dessuten har vi også /krav/16 som er mer generisk og sir at skilletegn ikke er lov (hvilke tegn det dreier seg om står også et sted i standarden). Så NCName-regler er der, selv om de ikke eksplisitt er nevnt i kravteksten.

Hilsen
Magnus

Fra: Erling Onstein [mailto:]
Sendt: 30. september 2016 09:15
Til: Kent-Jacob Jonsrud <>; Knut Jetlund <>; Magnus Karge <>; Morten Borrebæk <>
Kopi: vilhelm.bornes <>
Emne: SV: Kodelisteverdier i henhold til navneregler

I denne saken om kodelisteverdier er vi vel også på en veg med to grøfter.
I den ene grøfta (venstre side?) finner vi «meningsløse tallkoder», tallverdier som ikke gir noen som helst mening, og «bare» kan brukes som oppslagsnøkler til forskjellige slags kodeforklarings-tabeller, er samtidig helt avhengig av slike oppslagstabeller for å gi mening. I den andre grøfta (høyre side?) finner vi lange «avhandlinger» som må til for å forklare det vi er ute etter. Knuts eksempel med «701.2 - Tabellorienteringstavle for planskilt kryss på to- og trefeltsveg» er på vei ned i denne grøfta.

En god løsning når vi vil framover, er ofte å holde seg i veien, og ikke i grøftene. Midt poeng da er at for å holde oss mest mulig midt i vegen, må vi for kodelister ha en mulighet for «kortnavn». Med kortnavn mener jeg noe som på den ene siden gir mening når en tar på NCname-brillene for å få håndterbare database-nøkler. Samtidig bør kortnavn kunne gi en viss forståelse av hva det handler om. Et eksempel litt i retning høyre grøft, men kanskje ennå på vegen, er bygningstype-kodelistene.

Derfor: For kodelister må en ha et kortnavn (som egner seg i NCName-regelverket) og en full forklaring som kan kreve mye mer tekst. Og så må en passe seg for venstre grøft (meningsløse kortnavn).

Krever dette forandringer i Modelleringsregler 5.0?

Hilsen
Erling Onstein

Fra: Kent-Jacob Jonsrud [mailto:]
Sendt: 30. september 2016 08:26
Til: Knut Jetlund <>; Magnus Karge <>; Erling Onstein <>; Morten Borrebæk <>
Kopi: vilhelm.bornes <>
Emne: SV: Kodelisteverdier i henhold til navneregler

Hei, ja vi er klare over at kravene i standarden ble litt strenge.
Jeg har et knippe med de samme problemene i Stedsnavn-5.0.
Erkeeksemplet er kommunenummer som begynner med tall, tror ikke vi vil klare å endre denne praksisen.
Andre koder kan sikker prefikses med et eller annet fornuftig: 0,5 -> verdi0.5 eller avstand0.5?
Og < 1000 kbm blir like forståelig med mindreEnn1000kubikkmeter.
Meningen med de ulike tegna er vel også noe uklar, hva betyr skråstrek? deletegn eller og eller eller eller..?
Jeg laget et skript for automatisk å endre egennavn til ncname med understrek istedetfor blanke o.l.
Bruken av dette skriptet er beskrevet i en veileder for modellering av produktspesifikasjoner som utplukk fra fagområder.
Der er det også et skript som lager korrekte lowerCamelCase NCName.
Men jeg er usikker på om slike bør brukes der den gamle koden er en lang setning.
Der kodelista inneholder en rekke delkoder bør vel dette deles opp i koder for de enkelte komponenter.
Kravet om lowerCamelCase er også vanskelig der koden er egennavn eller en innarbeidet forkortelse (bIM, sSB, ?)
Kortversjoner som er mnemoniske bør kunne erstatte koder som er lange setninger, og setningen kan bli del av definisjonen.
Men satt inn som meningsfulle initialverdi vil de jo ikke endre kravet til koden.

Så jeg føler at vi nok må leve med noen av disse feilmeldingene en stund, intil vi kan revidere kravene i en 5.1-versjon.
Selvom dette vil svekke autoriteten av standarden og valideringen.
Kent

Fra: Jetlund Knut [mailto:]
Sendt: 29. september 2016 16:35
Til: Magnus Karge <>; Kent-Jacob Jonsrud <>; Erling Onstein <>; Morten Borrebæk <>
Kopi: vilhelm.bornes <>
Emne: Kodelisteverdier i henhold til navneregler

Hei, sender denne mailen til flere, skjønner at dere har hatt en diskusjon internt i Kartverket også.
ISO19103 og SOSI Del 1 versjon 5 sier at kodelisteverdier skal være på formen lowerCamelCase, uten spesialtegn osv. Jeg har sett på hvordan dette slår ut for kopien av NVDB Datakatalogen til SOSI Modellregister, og er usikker på hvordan vi skal håndtere det på beste måte.

I Datakatalogen har vi kodelisteverdier som
• 701.2 - Tabellorienteringstavle for planskilt kryss på to- og trefeltsveg
• < 1000 kbm
• 0,5
• X- og T-kryss, Uregulert/høyreregel
• BFOU (C) 250V 8x2x1.5 S4/S8 Blue

Disse blir jo ganske grisete, uforståelige og i mange tilfeller misvisende om vi skal følge reglene:
• 7012TabellorienteringstavleForPlanskiltKryssPåToOgTrefeltsveg
• 1000Kbm
• 05
• xOgTKryssUregulertHøyreregel
• bFOUC250V8x2x15S4S8Blue (!!!)

Jeg har eksperimentert litt med å bruke “_” og annet i de oversatte kodene, og får da verdier som:
• 701_2_Tabellorienteringstavle_For_Planskilt_Kryss_På_To_Og_Trefeltsveg
• under_1000_Kbm
• 0_5
• x_Og_T_Kryss_Uregulert_Høyreregel
• bFOU_C_250V_8x2x1_5_S4_S8_Blue

Denne kan nok utvikles videre - kan for eksempel kanskje kutte ut CamelCase ved bruk av “_”. Men hva med håndtering av parenteser, komma og skråstreker, som gjerne har en mening i opprinnelig verdi? I Datakatalogen har vi unike identer for alle kodelisteverdier, men dette blir jo mer som temakoder. Vi har også en del kortverdier («intialverdier»), men ikke for på langt nær alle, og dette sier jo uansett SOSI V5 at vi helst ikke skal bruke…

Det kom også opp et case i forbindelse med SOSI Landskapsarkitektur: Skal “BIM” oversettes til “bim”? Det synes jeg blir feil, og det har vel ingen praktisk betydning for implementasjon.

Noen som har noen tanker om hvordan dette kan håndteres på beste måte? Kanskje vi i fellesskap kunne komme fram til noen uoffisielle kjøreregler/anbefalinger her?

Med hilsen
Knut Jetlund

History

#1 Updated by Magnus Karge almost 5 years ago

Den nye formuleringen bør hete "Der forkortelser eller egennavn er brukt som egenskapsnavn kan navnet starte med stor bokstav." Der kodelister inneholder egennavn (kommunenavn, biltyper...) bør disse kunne skrives med store forbokstav.

Spørsmål: Hvordan forholder dette seg til "/anbefaling/8: Navn på alle modellelementer bør være presise og lett forståelige tekniske navn." og SOSI_presentasjonsnavn. Kan det tenkes at en streng tolkning betyr at også egennavn skal skrives som tekniske navn, altså med liten forbokstav, mens egennavn med vanlig skrivemåte skal plasseres i tagged value SOSI_presentasjonsnavn?

Also available in: Atom PDF