Regler for navning/modellering av geografisk informasjon for det videre arbeidet med SOSI-objektkatalogen samt produktspesifikasjoner

Transkript

1 Regler for navning/modellering av geografisk informasjon for det videre arbeidet med SOSI-objektkatalogen samt produktspesifikasjoner Versjon.0

2 2 Del Historikk og status Historikk og status Retningslinjer for modellering av geografiske data ble første gang utgitt av en arbeidsgruppe vinteren Det har i lengre tid vært etterspurt regler for modellering og navning av elementer innen fagområdet geografisk informasjon, ikke minst i forbindelse med SOSI-arbeidet. SOSIsyntaksen er i utgangspunktet veldig åpen, men det er kommet ønske fra ulike miljøer om å komme med regler for objekttypenavn, elementnavn, etc, basert på praktiske behov samt overordnede standarder for å oppnå at ulike modeller med tilhørende navning fremstår som enhetlige standarder. Dette dokumentet tar spesielt utgangspunkt i følgende standarder: ISO 903 Conseptual Schema Language (ISO/TC 2 Committee draft) ISO 909 Rules for Application Schema (ISO/TC 2 Committee draft) ISO 90 Feature Cataloge Methodology (ISO/TC 2 Committee draft) ISO-standard 79, part 5, Naming and Identification Principles for Data Elements. Standarder utgitt i regi av ISO/TC 2 som er nådd CD-nivå (Committee draft) kan fortsatt være gjenstand for betydelige endringer, så en skal være forsiktig med å bruke dette som en fasit. En skal samtidig også være klar over at disse kan påvirkes ut fra våre erfaringer. Dette dokumentet er ment å være en norsk oversettelse (profil) av det som står i de internasjonale standardene, samt en ytterligere detaljering som vi av praktiske og historiske grunner ønsker å benytte innen standardisering av geografisk informasjon i Norge. Der vi har regler i dag (i SOSI) som går på tvers av det som er foreslått, vil dette komme fram som merknader for nærmere diskusjoner. I forbindelse med remodellering av modellene (og objektene) i SOSI del2 i henhold til prinsippene nedfelt i ISO/TC 2 kan nye objekter oppstå og eksisterende forsvinne. Dette har ingen betydning for de eksisterende data, hverken i form av proprietære implementasjoner eller SOSI-filer, men har stor betydning for hvordan en modell av disse vil presenteres i form av inndeling i objekter. Dette er selvsagt en jobb for arbeidsgruppene og vil bli en del av deres arbeid utover versjon 3.2. Versjon Dato Utført av Grunnlag for endringen Modelleringsregler: Arne-Jørgen Berre Steinar Høseggen SOSI-sekr Navneregler: Per Ryghaug SOSI-sekr Overordned struktur: SOSI-sekr Vurdert og akseptert av SOSI-AG Opprinnelig versjon Aktuell ansvarlig: SOSI-sekretariatet IT-tjenesten Tlf

3 3 Del Innledning 2 Innledning 2. Bakgrunn Bakgrunnen for dette dokumentet er at dagens nasjonale SOSI-standard vil gjennomgå endringer for å kunne være kompatibel med ISO 900-standardene. Referansegruppe K76 har en klar strategi på å konvergere SOSI mot internasjonale standarder, da spesielt ISO 9xx serien. Spesielt modelleringsreglene i dette dokumentet er vinklet mot dette. Utgangspunktet for navnereglene er ikke spesielt rettet mot ISO 9xx, men til navning av elementer i datasatammenheng generelt. Derfor er det viktig at navnereglene tilpasses modelleringskonseptene som er spesielle for geografisk informasjon. I SOSI har det tidligere vært vedtatt å å innskrenke navnene på objekttyper til 6 karakterer (OBJTYPE), ikke minst av praktiske årsaker. De relativt stringente navnereglene i dette dokumentet har utgangspunkt i denne beskrankningen, men konseptet rundt navnereglene har betydning ut over dette. I SOSI versjon fra og med 3.3 er lengden på objekttypenavn økt til 32 karakterer. 2.2 Formål Retningslinjene skal være retningsgivende for det videre arbeidet med SOSI og produktspesifikasjoner, både i forbindelse med AREALIS, FKB og andre produktspesifikasjoner for geodata. Dette dokumentet gir imidlertid ikke føringer for hvor raskt denne endringen skal skje. Dette vil komme som et eget dokument. Disse retningslinjene er i liten grad anvendt for gjeldende versjon av SOSI, men er førende for det videre arbeidet framover, både utvikling av nye objektkataloger og produktspesifikasjoner, samt for konvergeringen mot internasjonale standarder i regi av ISO/TC Referanser ISO 903, Geographic information Conceptual schema language [CSL] ISO 904, Geographic information Terminology ISO 907, Geographic information Spatial Schema ISO 909, Geographic information Rules for application schema [RAS] ISO 90, Geographic information Feature cataloguing methodology. [FCM] ISO 92, Geographic information Positioning by Geographic Identifiers ISO 93, Geographic information Quality Principles ISO 95, Geographic information Metadata ISO 98, Geographic information Encoding ISO 79, part 5, Naming and Identification Principles for Data Elements. UML v.. Semantics, Appendix B - Glossary 3

4 4 Del Ord og termer 3 Ord og termer Dette dokumentet benytter både norske og engelske begreper. Det er her gjort forsøk på en sammenligning mellom disse: Merknad. Flere av termene knyttet til standardisering av geografisk informasjon er fortsatt omstridt, også internasjonalt, men de som listes opp her begynner å bli stabile. For lettere å kunne relatere dette til internasjonale standarder er engelske termer tatt med i oversikten. Siden dette dokumentet blant annet gir føringer for hvordan en generell beskrivelse av objekter avbildet fra en nærmere angitt virkelighet skal modelleres er det tatt med begreper fra både generell modellering og det skjemaspråk som er valgt innenfor geografisk informasjon, UML. Siden dette ikke bare er definisjoner av termer, men også forklaringer og merknader, er disse satt opp i en tabell og avviker fra hvordan termer vanligvis settes opp i en standard. Term Forklaring Engelsk term Merknad Objekttype En avbildning av et fenomen i den virkelige verden. Feature Type Class of real world phenomena with common properties I vår sammenheng underforsått en avbildning av et stedfested objekt, f.eks hus, vann, vei, etc) Objekt Forekomst (instans) av en Feature Objektkatalog Egenskap Relasjon objekttype. Definisjon og beskrivelse av objekttyper, objektegenskaper samt relasjoner mellom objekter, sammen med eventuelle funksjoner som er anvendt for objektet. Instance Feature Catalogue (Feature) Attribute (Feature) relationship Eksempel på objektkatalog er SOSI del2. relationship reified semantic connection among model elements. Kinds of relationships include association, generalization, metarelationship, flow, and several kinds grouped under dependency. Her benyttes også termen association. Association: semantic relationship between two or more classifiers that involves connections among their instances. Data type Data type specification of a legal value domain and legal operations on values in this domain EXAMPLE: Integer, Real, Boolean, String, Date and GM_Point. NOTE A data type is identified by a term, e.g. Integer [ISO 95, ISO 98] Beskrankninger Avhengighet/begrensning Constraint semantic condition or restriction represented as an expression. [UML] [ISO 903] Følgende begreper er relatert til UML. Term Forklaring Engelsk term Merknad UML-pakke? Package general-purpose mechanism for organizing elements into groups. Packages may be nested within other packages. Both model elements and diagrams may appear in a package. [ISO 903 terminology] 4

5 5 Del Ord og termer Lukket kodeliste Kodeliste Spesifiserer verdier i et lukket verdidomene, f.eks sann/usann for boolske operatorer. Denne benyttes nå det samtlige verdier i verdidomene er spesifisert. Spesifiserer verdier i et åpent verdidomene. Dette betyr at verdidomene kan endre seg. Ekempelvis vil de fleste egenskapene i SOSI være definert i form av en kodeliste. Enumeration Codelist Type Subtype Supertype Generalization A data type whose instances form a list of named literal values. Enumeration means a short list of well-understood potential values within a class. Classic examples are Boolean that has only 2 (or 3) potential values TRUE, FALSE, (and NULL). Most enumerations will be encoded as a sequential set of Integers, unless specified otherwise. The actual encoding is normally only of use to the programming language compilers. ISO CD 99 CSL Can be used to describe a more open enumeration. <<CodeList>> is a flexible enumeration that uses string values through a binding of the Dictionary type key and return values as string types; e.g. Dictionary (String, String). Code lists are useful to for expressing a long list of potential values. If the elements of the list are completely known, an enumeration should be used; if the only likely values of the elements are known, a code list should be used. Enumerated code lists may be encoded according to a standard, such as the ISO standard for two-letter country codes or for twoletter language code. Code lists are more likely to have their values exposed to the user, and are therefore often mnemonic. Different implementations are likely to use different encoding schemes (with translation tables back to other encoding schemes available). ISO CD 99 CSL A stereotype of class that is used to specify a domain of instances (objects) together with the operations applicable to the objects. A type may not contain any methods. In a generalization relationship the specialization of another type, sthe supertype. See generalization. [UML Sematics, version.] In a generalization relationship the generalization of another type, the subtype. See generalization [UML Sematics, version.] A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed. [UML Sematics, version.] Det vil arbeides videre med det som mangler. 5

6 6 Del Overordnede føringer 4 Overordnede føring er ISO903 beskriver hvordan vi skal uttrykke oss i UML - Unified Modelling Language. Alle ISO-standardene opererer med grafiske UML-modeller og UML klassenavn, egenskapsnavn, relasjonsnavn á lá: Eksempel på hovedelementene i UML Kjøretøy Person vekt : Real..* +eier 0..* Bil Start() 3..* Hjul Figur Eksempel på UML-modell Forklaring til notasjonen: En Person kan ha en angitt egenskapsverdi for sin vekt. En Person kan være eier av null eller flere biler. (0..*) En Bil må være eid av minst en Person. (..*) En Bil kan utføre en opereasjon Start(). En Bil er en subtype av Kjøretøy. En Bil har (komponenter) minimum tre Hjul. ISO909 beskriver hvordan vi skal bruke UML til å dokumentere vårt fulle "applikasjonsskjema" som skal vise alle objekttyper med egenskaper, relasjoner og oppførsel, og bruken av standard profiler av geometri og metadata. ISO90 er metodologi for beskrivelse av objekttyper, og deler denne inn i tre hoveddeler: Objekttype navn - Daglignavn på objekttypen Objekttype kode - Kort kode for objekttypen, alfanumerisk kode. Objekttype beskrivelse - Lang fritekst. Det er her objekttypen virkelig defineres! I SOSI har vi ifra versjon 2.0 hatt en slags todelt struktur, med et halvt leselige men i enkelte tilfelle kryptiske navn, begrenset til 6 tegn, fullstendig logisk navn og til slutt en lengre verbal beskrivelse (Disse er ikke fylt ut i alle tilfeller) SOSI sin struktur for Gruppeelementer og Basiselementer er litt mer lik ISO, der vi har SOSInavnet, og et tilhørende "Fullt navn", og så beskrivelsen. Det foreslåes at vi endrer vår praksis til å beskrive objekttypenavnet i henhold til navnereglene angitt i dette dokument og legge inn en fyldig verbal beskrivelse. Så kan vi seinere tildele kortkoder til objekttypene, eller enda bedre - koble oss inn på og benytte et felles internasjonalt fundament for kortkodene dersom dette vil komme. Andre organisasjoner, bl.a. GDF, IHO og DGIWG har laget sine egne standard objektkataloger og begrepskataloger for sine fagfelt, og det er også eksperimentert med lyd, bilde og video for å dokumentere objekttypene bedre. F.eks. en skisse av et fagverkstårn for telekommunikasjon. Dette er svært instruktivt, og kan inntil videre sees på som en enkel utvidelse av innholdet i beskrivelsesfeltet. Dette betyr i praksis at alle SOSI arbeidsgruppene må fylle inn et logisk navn, og en fyldig beskrivelse på hver av sine objekttyper. Geometriforhold kan avklares, d.v.s. hvilke punkt som linjer kan ende i, og hvilke linjer som flater kan avgrenses av. Skisser eller bilder av 6

7 7 Del Overordnede føringer objekttypen bør vurderes som tillegg. De nevnte kortkodene kan vi eventuelt finne/velge seinere. Remodellering Motivasjon for remodellering Fram til og med versjon 3. har eksisterende SOSI-filer ikke vært påvirket av endringer i objektklassifiseringene. Men fra den versjonen vi bestemmer at OBJTYPE er påkrevet hovedklasseinndeling, og TEMAKODE er et valgfritt tillegg, så kan vi IKKE LENGER endre på disse "i vilden sky". Da skal ALLE SOSI-filer inneholde EKSAKT hvilke type som hver instans er av. Derfor er dette tiden for å rette opp modellene! Kvalitetskontrollprogrammet KVAKK har i mange år hatt denne forutsetningen at en må bestemme hvilke objekttype en skal sammenlikne med før en kan si noe om kvaliteten på hver instans på SOSI-fila. Denne utvalgsprosessen har vært et ekstra mulig feilkilde for KVAKK. Råd om "god" modelleringspraksis er det ikke alltid enighet om, men noen ting kan nevnes: Studer interessefeltet, den "virkelige verden" og bestem klasser av objektinstanser med samme typer egenskaper, relasjoner og oppførsel. Denne valgte hovedklassifiseringen gir objekttypene. Dersom to slike objekttyper har samme egenskapstyper, relasjonstyper og oppførselstyper, så er de kandidater for sammenslåing til EN objekttype. Dersom en objekttype kan ha variabelt innhold av egenskapstyper, relasjonstyper eller oppførselstyper, så må en vurdere å splitte i TO objekttyper. Alt som smaker av "subjektiv vurdering" og situasjonsbetinget klassifisering omformes til objektive mål. F.eks. "stor" og lignende er fyord, beskriv en objektiv verdi eller et verdiintervall. Lesbarhet og fattbarhet bestemmer hvor "generisk" eller fin-inndelt modellen skal være. Husk at en kan benytte egenskapstyper til å beskrive detaljer og "alternative klassifiseringskoder". Bestem hvilke geometrityper om kan anvendes, og hva som er lovlige relasjoner via geometrien. (Hvilke linjegeometrier som kan avgrense ulike flater, o.l.) Dersom interessefeltet har et (nasjonalt eller internasjonalt) organ så kan en allerede ha en objektkatalog der. Da kan en måtte bryte noen av de andre reglene og heller utveksle "data idag". Forøvrig henvises til kapittel 5 modelleringsregler. 7

8 8 Del Retningslinjer for datamodellering 5 Retningslinjer for datamodellering 5. Retningslinjer. Oversikt over datamodellen Ref. RAS Oversikten lages ved å benytte UML s package mekanismer Bruk UML avhengigheter for å vise hvilke andre standard modeller / skjema som modellen benytter seg av. Bruk notes i UML til å vise hvilke definisjoner som benyttes i de andre modellen 2. Identifisering av objekttyper og etablering av UML klasser Ref. RAS 8. Studer den del av virkeligheten som skal modelleres (Universe of Discourse) og identifiser de klasser av geografiske objekter (objekttyper) som tilhører applikasjonen. Konkrete geografiske objekttyper (Se eksempel: Veg, Bygning,..) Abstrakte (faglige) geografiske objekttyper (Se eksempel: veglenke, Vegnode, ) Objekttyper modelleres som UML klasser Ref. RAS Supertype / Subtype Organiser objekttypene i en struktur hvor generalisering og spesialisering av klassene framkommer. Kriterier for dette er En objekttype er en subtype av en annen. (Se eksempel: Europaveg, Riksveg, kan modelleres som subtyper av veg.) Flere objekttyper har flere felles egenskaper. Det kan være nødvendig å introdusere nye klasser som representer supertypen. (Se eksempel: Kilometrert veg) 4. Egenskaper/ Ref. RAS 8.3 Egenskaper til objekttyper modelleres som UML attributter i de klasser som representerer objekttypen. Dette gjelder også egenskaper som refererer til klasser i andre standardmodeller Egenskaper i klasser som representerer objekttyper skal være definert som datatyper Egenskapnavn starter med liten bokstav. Hvis navnet er sammensatt av flere, benyttes STOR førstebokstav fra og med andre navn (Se eksempel: trafikkretning) Merknad: Å gjennomføre siste punkt krever omftattende endringer i eksisterende SOSI, hvor alle gruppe og basiselementer (egenskaper) har store bokstaver. Det er her ikke tatt stilling til omnavning av eksisterende SOSI-elementer. 5. Relasjoner mellom objekttyper Ref. RAS 8.3 Logiske relasjoner i applikasjonen mellom objekttyper modelleres som UML association mellom tilhørende klasser. Roller skal angis (Se eksempel: Rollen +sammenknytter i relasjonen mellom Vegnode og Veglenke). Rollenavn skrives med små bokstaver. Kardinalitet skal angis (Se eksempel: I relasjonen mellom Vegnode og Veglenke er en Veglenke alltid være knyttet til 2 Vegnoder ) 8

9 9 Del Retningslinjer for datamodellering 6. Kvalitet og andre metadataelementer Ref. RAS 8.5 Ref. RAS Kvalitet knyttet direkte til en objekttype modelleres i form av en egenskap i klassen som representerer objekttypen. (Se eksempel: Egenskapen klassifikasjonsnøyaktighet ). Kvalitet knyttet til en egenskap modelleres ved at egen klasse Ref. RAS etableres, hvor både egenskapen for objekttypen og dens kvalitetsinformasjon modelleres inn som egenskaper i denne klassen. Koplingen mellom klassene ivaretas av en UML association. Relasjonens rollenavn, ny klasse og egenskap som bærer verdien til opprinnelig egenskap i objekttypen gis samme navn. (Se eksempel: Klassen Geometri ). Kvalitet til geometri Ref. RAS Geometri Ref. RAS 8.7 Geometri modelleres i applikasjonsmodellen som egenskaper til objekttyper, med bruk av de klasser som ISO 907 Spatial Schema tilbyr (Eksempel: Posisjon: GM_Point) Felles geometri, dvs objekttyper deler geometri-beskrivelser, modelleres ved å bruke GM_CompositePoint, GM_CompositeCurve, GM_CompositeSurface, eller ved bruk av UML association til klassene i Spatial Schema. Ref. RAS Ref. RAS Erstatt implisitt modellering med eksplisitt beskrivelse Relasjoner som ofte ligger i sammenhenger på geometrinivå, kan komme til uttrykk i modellen. (Se eksempel: I gamle VBASE var Vegnode implisitt beskrevet via KP i SOSI data) 9. Definisjon av verdidomener: Lukket kodeliste [Enumeration] Brukes til å definere et gitt lukket verdidomene for en gitt egenskap (Se eksempel: Dag i ukedag) Dersom en applikasjon bare skal utnytte et gitt subsett av et større sett av en verdi domene, etableres en egen enumerasjon som et subsett hvor lovlige verdier angis. (Se eksempel: Vegmedium som subset av Medium) Ref. CSL Definisjon av verdidomener: Kodeliste [Code List] Ref. CSL Brukes når man vil definere et verdidomene som man regner med vil kunne utvides, der det er hensiktsmessig med en String representasjon.(se eksempel: Vegnummer). Definisjon av verdidomener: Gazetteer Ref. RAS 8.0 Brukes når det er verdier som ligger i andre databaser (f.eks Postnr, Adresse) Referanser til Gazetteer skal benytte SI_LocationInstance som er definert i Gazetteer Schema. 2 Definisjon av enheter Ref. CSL Brukes for å presisere måledomene for egenskaper, f.eks. med SI Units. 9

10 0 Del Retningslinjer for datamodellering 3 Beskrive beskrankninger (Conditionals) Conditionals knyttet til egenskaper og relasjoner beskrives i notes og knyttes til det element i modellen som den beskriver (Se eksempel: Note knyttet til Veglenke) Conditionals skal beskrives om mulig i OCL (Se eksempel: Innhold i note knyttet til Veglenke) 4 Navngiving Ref. CSL 7.9 Bruk regler for små og store bokstaver som beskrevet i kapittel 6 og CSL 7.9 0

11 Del Retningslinjer for datamodellering 5.2 Eksempel: UML modell av VBASE (SOSI Vegnett) 5.2. Modellering i objektkatalog. (Dvs den semantiske delen) Objektkatalogen inneholder ikke et fullstendig applikasjonsskjema. Blant annet inneholder ikke objektkataloger informasjon om geometriske primitiver, kvalitet, etc. I utgangspunktet er modellene i objektkatalogen den semantiske delen av applikasjonsskjema. For tiden er det usikkerhet knyttet til om objektkatalogen tillater geometrisk/topologisk informasjon. I forordet står det klart at geometri, tid og kvalitet ikke skal angis i en objektkatalog. På den annen side angis dette som egenskapert, og egenskaper er en selvfølgelig del av en objektkatalog. En nærmere avklaring av dette må finne sted før praktisk arbeid igangsettes Modellering av applikasjonsskjema NB. Det er her tatt utgangspunkt i VBASE s. Det presiserer derimot at dette bare er en teoretisk modell, basert på modelleringsreglene. Det var ingen eksperter med veifaglig bakgrunn med i dette arbeidet, og modellen må ikke oppfattes som noen ny versjon av VBASE Eksempel oversikt over d atamodell Dette diagrammet angir hvilke delmodeller (Schema) som inngår i den komplette modellen. De stiplede pilene viser hvilke delmodeller som er avhengige av hvilke andre. Kommentarboksene (med brettet hjørne) angir mer spesifikt hvilke objekttyper som refereres, men disse kan igjen dra med seg andre underordnede typer.

12 Eksempel datamodell av vegnett if medium = På v annov erf laten then linjetema =720 Posi sj on posisjon : GM_Point posisjonsnøyaktighet : DQ_Positionalaccuracy +posisjon Vegpunkt punkttema : Temakode medium : VegMedium kommunenummer : Knr dato : TM_Instant vegstatus : Vegstatus vegnummer (0..) : Integer +sammenknytter..* +ligger på KilometrertVeg - vegnummer : Integer - vpa : Vpa - kjørefeltkode : String - veglenkedato : Date - trafikkretning : Integer Veglenke linjetema : Temakode=700 medium : VegMedium kommunenummer : Integer dato : Date vegstatus : Vegstatus veglenkeid : Integer trafikkretning (0..) : Integer klassifikasjonsnøyaktighet : DQ_ThematicAccuracy +geometri AnnenVeg Geometri geometri : GM_Curve posisjonsnøyaktighet : DQ_PositionalAccuracy +starter /slutter i 2 Vegnode vpa : Vpa +inngår i 0.. +inneholder 0..* PunktPåVeg 0..* Europav eg Riksveg Fylkesveg Skogbruksv eg Gangv eg Priv atveg KommunalVeg Kryss Endepunkt Tv angspunkt Ferjekai Kommunedele Vegbom VegUnderBane <<Code List>> Kommunenr (from SOSI konsepter) Planov ergang <<Data Type>> Lengde mlengde : Integer enhet : ISOStandardUnits <<Data Type>> Vpa hovedparsell : Integer meterfra : Lengde metertil : Lengde <<Enumeration>> Vegstatus Framtidig anlegg vedtatt Framtidig anlegg ikke vedtatt Eksisterende veg Tidligere veg Veg med midlertidig status <<Enumeration>> Medium (from SOSI konsepter) <<Subset>> <<Enumeration>> VegMedium I bygning I luft På vannoverflaten På sjøbunn / på bakkenivå Under terreng "Kunstig" bruk av medium f or klassif ikasjon av v egnettet? - Vanlig v eg = På bakkeniv å - Bro = I luf t - Tunnel = Under terreng - Vegov erby gg = I by gning - Bilf erjestrekning = På v annov erf laten 2 2

13 Retningslinjer for datamodellering Eksempel SOSI konsepte r og definisjoner <<Enumeration>> Medium I bygning Tidvis under vann På isbre Under isbre I luft På vannoverflaten På sjøbunn / på bakkenivå Under terrenget Alltid i vann Under sjøbunnen <<Code List>> Kommunenr Trondheim : String = 60 Nøtterøy : String = 0722 Lukket kodeliste (Enumeration) for Medium er her benyttet som eksempel. I praksis vel en kanskje ha behov for å utvide denne lista etterhvert, og da ville kodeliste være et bedre valg, 3

14 Navneregler 4 6 Navneregler Dette dokumentet må sees i sammenheng med retningslinjer for god modellering samt overordnede føringer fra det internasjonale arbeidet i regi av ISO/TC 2. De reglene som fremkommer i dette kapitlet må betraktes som utfyllende ut fra modelleringsreglene. Det bemerkes også at begrensningen på 6 karakterer i SOSI objekttypenavn har vært utgangspunktet for sterk fokus på dette, men at selve konseptet også har gyldighet uten en slik begrensning. Kommentar: I henhold til ISO 90 FCM skal ikke geometri/tidrerefering samt presentasjonsinformasjon være med i en objektkatalog. Her har vi en utfording, siden SOSI-del 2 har med geometrisk representasjon, slik som linje, kurve,etc, gjennom angivelsen av grafisk element/grafisk objekt. I utgangspunktet kan en jo bare stryke denne delen i objektkatalogen, men problemet er at flere av objekttypenavnene har (i alle fall i en viss grad) geometri i navnet, slik som Bergartprøvepkt. Hvis PKT er brukt som endel av navnet, så betyr det at geometrien i featuretypen er POINT. Dette vil være implisitt modellering! Mange forskjellige geometriprimitiver i ISO 900 kan være aktuelle som spatial representasjon, POINT, NODE, SURFACE, COMPLEX,... Samme problematikk vil være tilsted hvis det knyttes konvensjoner slik som REG, ANDRE, etc. Selvsagt skal en kunne bruke disse begrepene i navnet, men de skal ikke som konvensjon bety noe modelleringsmessig eller være bærere av metadata. De eksemplene som er benyttet her er knyttet til de eksisterende objekttypene i SOSI-del2, slik som bergartprøvepkt, og gir eksempler på hvordan disse burde vært navngitt etter disse reglene. I henhold til ISO 90 ville en få et objekt kalt bergartsprøve. Det ville da være opp til en produktspesifikasjon å angi hvilke geometriske primitiver som skal benyttes for nærmere spesifikasjon. Rent teoretisk bør en vel forsøke å modellere de respektive kapitlene i objektkatalogen i henhold til de retningslinjene som gjelder modellering, og følge disse navnereglene for generell navning av både objekttyper, relasjoner og elementer. I forbindelse med remodellering av modellene (og objekttypene) i SOSI del2 i henhold til prinsippene nedfelt i ISO/TC 2 kan nye objekter oppstå og eksisterende forsvinne. Dette har ingen betydning for de eksisterende data, hverken i form av proprietære implementasjoner eller SOSI-filer, men har stor betydning for hvordan en modell av disse vil presenteres. Dette er selvsagt en jobb for arbeidsgruppene og vil bli en del av deres arbeid utover versjon 3.2, Hvorvidt arbeidsgruppene ønsker å avvente navning av objekttyper bør avhenge av i hvor stor grad de ser for seg endringer i modellene knyttet til reglene i denne standarden. Disse navnereglene har ikke som målsetting å endre folkelige navn som er innarbeidet i fagmiljøet. Disse reglene er tenkt anvendt der folkelige termer ikke finnes, og en ser det som formålstjenlig med standard forkortelser og regler for å redusere størrelsen på navnerommet. I dag er objekttypenavnene satt til T6, men denne er økt til T32 fra og med versjon 3.3. Som underlag for navnereglene er det brukt prinsipper beskrevet i ISO-standard 79, part 5, Naming and Identification Principles for Data Elements. Objekttypene på vært nivå blir her kalt data element komponenter som består av navnekomponenter. Den første navnekomponenter er termen til objekttypen som kan etterfølges av en term for egenskapsterm (property term). En annen komponent kalles en framstillingsterm (representation term) som helst skal følge en på forhånd avtalt liste. På et mer applikasjonsnivå kan det være aktuelt å legge et tilleggsord (qualifier term) til det logiske navnet på objekttypen for å spesifisere dette nærmere. En navnekonvensjon kan inneholde regler for å håndtere komponenter som blir overflødige, dvs som kan utelates uten at navnet dermed blir tvetydig (ikke unikt). Videre er det lurt å ha visse regler for hvordan komponentene (ordene) kan forkortes. Det legges derfor vekt på at navnekonvensjonen følger et sett av semantiske regler basert på komponentene beskrevet 4

15 Navneregler 5 ovenfor, syntaktiske regler som angir regler for hvordan komponentene er arrangert innbyrdes og leksikalske regler som omhandler de mer språklige aspektene ved navngiving. Følgende regler anbefales for navngiving av objekttyper samt egenskapstyper i SOSI. Semantiske regler:. Objekttype termen baseres på det mest folkelige/signifikante navnet på det fysiske objektet eller abstrakte fenomener. (Object class term) 2. Tilleggsord-termen muliggjør en mer presis beskrivelse av objektet og gjør det unikt i en spesiell sammenheng (eks. OBJTYPE RegFiskeOmr) (Reg = registrert) (Qualifier term) 3. Egenskapstermen er et supplement til objekttypenavnet, og utgjør ofte en del av navnet (eks. OBJTYPE bergartssymbol (Property term). 4. Framstillingstermen er en form for domene-verdi og sier noe om hvilken form/gyldighet/opptreden objektet har i naturen (eks. OBJTYPE ServituttgrFikt). En liste over gyldige termer og skrivemåter vil her være interessant. (Representation term) Syntaks regler:. Objekttype termen skal ha ytterste venstre posisjon i objekttypenavnet med unntak av når det er knyttet en tilleggsord-term til objektklassen, (eks. OBJTYPE AndreFornPkt). 2. Tilleggsord-termen skal komme foran objekttypenavnet (eks. OBJTYPE IkkeSjømåltOmr) og kan være forkortet. 3. Egenskapstermen skal følge etter objektklassetermen. Begrepet egenskapsterm virker noe uklart. Bør ha bedre eksempler før vurdering av hvordan denne eventuelt skal brukes. 4. Framstillingstermen skal være komponenten lengst til høyre. Leksikalske regler:. Ingen objekttypenavn skal ha mer enn 32 karakterer. Følger reglene for navning og navnerom i ISO 903 CSL. Enkelte deler er trukket fram her. For navnerelger for pakker (packages), se ISO 903 kapittel 7.9. Bruk presise og forståelige tekniske/logiske navn for objekttyper, egenskaper og relasjoner. Korrtnavn er OK dersom denne har mening eller er en definert forkortelse. Se forkortelser for framstillingstermer. Angi ikke navn ut fra type anvendelser dersom denne i utgangspunktet er generell. Dette reduserer felles anvendelse/etterbruk av elementer. Eksempel: Bruk medium, ikke f.eks skmedium, dersom denne i utgangspunktet er av generell karakter. Merknad: I enkelte tilfeller skal en være klar over at et generelt begrep har en spesiell betydning innenfor et fagområde. Da er det viktig å navne denne slik at fagområdet kommer klart fram. Bør unngå institusjonsnavn til fordel for domenenavn. Kombiner ord dersom dette er nødvendig for å lage presise og forståelige navn, men uten å benytte mellomromskarakterer, dvs blank ( ), -, eller _. Eksempel (teoretisk) : BergartprøvePkt (Ikke Bergartprøve Pkt eller Bergartprøve_Pkt) For navn på egenskaper,navn på den rollen relasjonen har (association roles), navn på operasjoner (operation names), samt for parametere benyttes stor bokstav for første karakter i hvert delord, men ikke for første bokstav. Eksempel: geoalderfra (Ikke geoalderfra eller GEOALDERFRA) 5

16 Navneregler 6 Merknad: SOSI benytter i dag bare store bokstaver i elementnavn. Dette er ikke i overensstemmelse reglene angitt her. Dette er en kjent og akspetert løsning i vårt hjemlige marked, og vi bør vurdere nøye konsekvensene av en endring. Dette bør diskuteres/avklares i AG, og vil ikke gjøres for versjon 3.2. I tillegg må en heller ikke blande sammen SOSI-egenskaper i SOSI-fila, som er en kodings-sak, med selve objektkatalogen. At SOSI-egenskaper i et overføringsformat skal ha store bokstaver er ikke nødvendigvis i motsetning til hvordan disse beskrives i en objektkatalog. Dette kan virke forvirrende. Bruk stor bokstav i det første ordet for navning av objekttyper, pakke (package), type spesifikasjon samt relasjonsnavn, samt stor bokstav i hvert delord. Eksempel: AndreFornPkt (Ikke andrefornpkt). Bruk dokumentasjonsfelt for å angi nærmere betydningen av navn. Merknad: Dette er allerede innført i SOSI-DB,, implementert i form av logisk navn som gir en fullstendig leselig beskrivelse, samt en beskrivelse som gir nærmere forklaring. Behold navn så korte som praktisk mulig. Bruk standard forkortelser dersom disse er forståelige, unnlat preposisjoner, samt verb når de ikke i tilstrekkelig grad øker forståelsen av navnet. 2. Substantiver skrives så fullt ut som mulig 3. Substantiver skal være entall og eventuelle verb skal skrives i presens. Gyldige forkortelse for framstillingstermer: Merknad: Dette er en svært redusert liste i forhold til de som er i bruk i dagens versjon. Utvidelse av objekttypenavn til 32 tegn samt modelleringsreglene i dette dokument vil også kunne føre til endringer. Objekttyper som i dag har en tileggsterm/framstillingsterm i objekttypenavnet, vil kunne remodelleres med disse termene som egenskaper. Andre forkortelser kan ikke benyttes om disse termene, men forkortelser av nye termer kan defineres i standarden. Termen kan benyttes uten å være forkortet. Forkortelse Navn Gr grense Ln Linje Omr Område. Benyttes der en tilleggsterm er nødvendig for forståelsen. Pkt Punkt Obs Observasjon (Spesielt for fenomener) Fk Forekomst Reglene for navning erkjenner behovet for standard forkortelser der disse er nødvendige. Disse bør derimot være av en karakter at det er flere elementer (i første omgang objekttyper) som har behov for (eller burde ha behov for) disse. Gyldige forkortelse for tilleggstermer: Adm Administrativ 6

17 Likheter/forskjeller mellom SOSI-del2 samt ISO 90 Feature Cataloge Methodology (Informativt) 7 Likheter/forskjeller mellom SOSI-del2 samt ISO 90 Feature Cataloge Methodology (Informativt) 7 Dette dokumentet er et forsøk på sammenligne SOSI objektkatalog med de krav som ISO 90 stiller med tanke på beskrivelse av en objektkatalog. Enkelte deler av ISO-standarden er tatt inn i dette dokumentet i sin helhet, uten oversettelse. I de tilfeller hvor utdrag er oversatt til norsk gjentas disse i sin opprinnelige engelske form. 7. Utgangspunkt ISO 99 Feature Catalogue Methodology Denne delen av ISO 9xx spesifiserer hvordan klassifikasjon av objekttyper er organisert i en objektkatalog og presentert til brukerne av et sett geografiske data. Denne standarden er anvendelig for å lage kataloger med objekttyper i tidligere ikke-katalogiserte fagområder samt gjennomgang av eksisterende objektkataloger for å oppnå kompatibilitet med denne standarden. Denne standarden anvendes for katalogisering av objekttyper som er representert digitalt. This part of the International Standard specifies how the classification of feature types is organized into a feature catalogue and presented to the users of a set of geographic data. This part of the International Standard is applicable to creating catalogues of feature types in previously uncatalogued domains and to revising existing feature catalogues to comply with standard practice. This part of the International Standard applies to the cataloguing of feature types that are represented in digital form. Følgende begreper er sentrale for forståelsen av denne standarden. Objektkatalog (feature catalogue) Definisjon og beskrivelse av objekttyper, objektegenskaper samt relasjoner mellom objekter som finnes i et eller flere datasett med geografiske data, sammen med eventuelle funksjoner som er anvendt for objektet. Definition and description of the feature types, feature attributes, and feature relationships occurring in one or more sets of geographic data, together with any feature functions that may be applied Selve formen på navnene angis etter følgende retningslinjer: Alle objekttyper, funksjoner, egenskaper samt relasjoner som er inkludert i objektkatalogen skal identifiseres ved et navn som er unikt innenfor objektkatalogen. Dersom navnet på objekttyper, funksjoner, egenskaper eller relasjoner brukes flere ganger i objektkatalogen, skal definisjonen være den samme for alle instanser. All feature types, feature functions, feature attributes, and feature relationships included in the feature catalogue shall be identified by a name that is unique within the feature catalogue. If the name of a feature type, feature function, feature attribute, or feature relationship appears more than once in the feature catalogue, the definition shall be the same for all occurrences. Formen på definisjonene (Form of definitions) Definisjoner av objekttyper, egenskaper, relasjoner og funksjoner skal angis i et naturlig språk, i vår sammenheng selvsagt norsk/(samisk). Definisjonen av objekttyper, egenskaper, relasjoner og funksjoner skal være inkludert i objektkatalogen, dersom ikke katalogen refererer til en separat kilde med definisjoner. Dersom den samme termen kommer til syne i både den refererte kilden samt i objektkatalogen, skal definisjonen i objektkatalogen anvendes. Definitions of feature types, feature attributes, and feature relationships, and descriptions of feature functions shall be given in a natural language. Definitions of feature types, feature attributes, and feature relationships shall be included in the catalogue, unless the catalogue specifies a separate definition source. If the same term appears in both the definition source and the feature catalogue, the definition in the feature catalogue shall apply. 7

18 Likheter/forskjeller mellom SOSI-del2 samt ISO 90 Feature Cataloge Methodology (Informativt) Krav til objekttyper (Requirements for feature types) Alle objekttyper skal defineres i et naturlig språk (norsk /samisk?) og opsjonelt i et funksjonsspråk ved benyttelse av en eller annen notasjon (F.eks. SQL, gopher,etc). Objekttypene kan også identifiseres ved hjelp av en alfanumerisk kode som er unik innenfor objektkatalogen, samt med bruk av alias. Objektkatalogen skal også inneholde (for hver objekttype) dens egenskaper samt eventuelle relasjoner samt funksjoner dersom slike finnes. Det anbefales å benytte et funksjonelt språk for å definere objekttypene. Each feature type shall be defined in a natural language and optionally in a functional language using scientific notation. Each feature type may also be identified by an alphanumeric code that is unique within the catalogue and by a list of aliases. The feature catalogue shall also include, for each feature type, its feature functions and associated feature attributes and feature relationships, if any. The use of functional language specifications to help define feature types is recommended. 7.3 Krav til objektegenskaper (Requirements for feature attributes) Alle objektegenskaper skal identifiseres og defineres for hver enkelt objekttype. Definisjonen skal inkludere en definisjon i et naturlig språk (norsk/samisk?) med tilhørende datatype. Alle objektegenskapene kan også identifiseres ved hjelp av en alfanumerisk kode som er unik innenfor katalogen. Feature attributes, if any, shall be identified and defined for each feature type. The definition shall include a natural language definition and a specified data type for values of the attribute. Each feature attribute may also be identified by an alphanumeric code that is unique within the catalogue. 7.4 Krav til objekttype-relasjoner (Requirements for feature relationships) Objekttype-relasjoner skal, dersom disse finnes, identifiseres og defineres for hver objekttype. Hver objekttyperelasjon kan også identifiseres ved hjelp av en alfanumerisk kode som er unik innenfor katalogen. For de objekttyper som har relasjoner, skal andre objekttyper som er berørt av relasjonen identifiseres. Feature relationships, if any, shall be identified and defined for each feature type. Each feature relationship may also be identified by an alphanumeric code that is unique within the catalogue. For each affected feature type, any feature attributes affected by the feature relationship shall be identified. 8

19 Likheter/forskjeller mellom SOSI-del2 samt ISO 90 Feature Cataloge Methodology (Informativt) Eksempler fra ISO 90 På bakgrunn av disse reglene er det sammenstilt en tabell som viser hva de respektive UMLklassene skal inneholde. 2 Feature Type Class of real world phenomena with common properties 3 Feature Type Name Text string that uniquely identifies the feature type within the dataset 4 Feature Type Definition Definition of the feature type in a natural language 5 Feature Type Code Code that uniquely identifies the feature type within a dataset 6 Feature Type Aliases 7 Feature Function Names 8 Feature Attribute Names 9 Feature Relationship Names M N Feature Catalogue Entity Elements 3-25 M text free text C/ Definition not provided by definition source? text free text O text free text Name(s) of equivalent feature term(s) O list free text Function(s) that may be performed on or by the feature type Characteristic(s) of the feature type Relationship(s) between instances of this feature type and instances of the same or a different feature type C/ feature function occurs in feature catalogue? C/ feature attribute occurs in feature catalogue? C/ feature relationship occurs in feature catalogue? list free text list free text list free text 7.6 Sammenhengen med SOSI-objektkatalog I SOSI objektkatalog har vi i dag (Eksempel) Kap 6. Beskrivelse av objekttypene (Inneholder objekttype navn og objekttype beskrivelser i naturlig språk) Eksempel: Landskapreg En landskapsregion er en geografisk enhet av store områder der totalinntrykket av overordnede drag i landskapet virker samlende, og skiller seg fra tilgrensende områder. Grensedragingen mellom ulike landskapsregioner er foretatt etter en samlet vurdering av naturforhold, arealbruk og bosetting. Kap 6.2 Kodeliste og detaljeringsgrad Eksempel Objekttype Aktuelle grafisk element/objekt Aktuelle SOSInavn Landskapreg FLATE OBJTYPE FTEMA LS_ID LS_RNR NAVN Verdi Landskapreg 4237 std/ Merknad opsj Navnet på objekttypen tilsvarer igjen Feature Type name Atkuelle SOSI navn tilsvarer Feature Attribute Name, Feature Relationships name og eventuelt Feature Function names.. Vi mangler imidlertid Feature Type Code og aliases, men disse er også opsjonelle. O S S O -45 9

20 Likheter/forskjeller mellom SOSI-del2 samt ISO 90 Feature Cataloge Methodology (Informativt) Tilsvarende for feature attributes 26 Feature Attribute Characteristic of the feature type O N Feature Catalogue 27 Feature Attribute Name 28 Feature Attribute Definition 29 Feature Attribute Code 30 Feature Attribute Value Data Type 3 Feature Attribute Value Measurement Unit Text string uniquely identifying feature attribute Definition of the feature attribute in a natural language Code that uniquely identifies the feature attribute within the dataset 20 Elements Entity M text free text C/ Definition not provided by definition source? text free text O text free text Data type of attribute value M text IDL basic data types Measurement unit for attribute value O text free text 32 Feature Attribute Value Domain Type 33 Feature Attribute Value Domain Indicates whether or not domain for feature attibute values is enumerated (if omitted, domain is not specified) Permissible values of feature attribute O integer 0 ="not enumerated" ="enumerate d" C/ Feature attribute text free text value domain type = 0 (not enumerated) I SOSI har vi kodet dette på følgende måte. Eksempel fra landskap LS_OPPL Landskapsopplevelsesverdi (Feature Attribute name) Opplevelsesverdi angis kun for landskapsområder. Klassifisering av landskapsområdenes opplevelsesverdi er basert på en samlet evaluering av inntrykkstyrke, mangfold og helhet i landskapsområdet. Evalueringen skal kunne gi oversikt over verdifulle karaktertrekk i landskapet og landskapets opplevelsesverdi. (Feature attribute definition) Definisjon Kode Forklaring.DEF.. LS_OPPL T2 A Klasse A inneholder det typiske landskapet i underregionen og har kvaliteter eller komponenter som gjør landskapet enestående med et særlig stort opplevelsespotensiale. Klasse A er den ypperste og mest enestående innenfor landskapsregionen. A2 B B2 C Høy inntrykksstyrke og variasjon. Klasse B representerer det typiske landskapet for underregionen, landskapet har gjengs gode kvaliteter men er ikke enestående. Klasse B omfatter det typiske og representative landskap. Mindre mangfold og enkelte uheldige inngrep. Inntrykksvake landskap med liten variasjon og/eller landskap dominert av uheldige landskapsinngrep. Klassen er ikke delt. T2 tilsvarer Feature Attribute Value Data Type. Det er mulig å angi at disse Feature relationships name. Dersom definisjonen inneholder koder tilsvarer dette Feature Attribute Value Domain Type, od re respektive kodene tilsvarer Feature Attribute Value Domain. Det vi ikke har (og som er opsjonelt i ISO) er følgende: Feature Attribute Code - Code that uniquely identifies the feature attribute within the dataset. Der ligger ingen andre føringer i denne enn at den er alfanumerisk, og det kan selvsagt hevdes av våre 6 karakterers navn på objekttyper er koder, men logisk navn er objekttypenavnet. Feature Attribute Value Measurement Unit - Measurement unit for attribute value Tilsvarende gjelder også for feature relationships. Her vises bare de respektive ISO-elementene. 20

21 Likheter/forskjeller mellom SOSI-del2 samt ISO 90 Feature Cataloge Methodology (Informativt) 2 38 Feature Relationship 39 Feature Relationship Name Relationship that links instances of the feature type with other instances of the same or a different feature type Text string uniquely identifying feature relationship O N Feature catalogue entity Elements M text free text 40 Feature Relationship Definition 4 Feature Relationship Code Definition of the Feature Relationship in a natural language Code that uniquely identifies the feature relationship within the dataset C/ Definition not provided by definition source? text free text O text free text 42 Feature Types Included 43 Feature Relationship Order Indicator 44 Affected Feature Attributes Names of feature types participating in the relationship Indicates whether the ordering of feature types is significant in the relationship Names of feature attributes affected by the relationship M list free text M integer 0 ="not ordered" ="ordered" C/ Feature attribute is affected? list free text 45 Feature Relationship Constraints Constraints on the feature relationship O list free text I SOSI har vi svært få relasjoner kodet inn i objektkatalogen. Hva hjelper dette oss vedrørende navning. Egentlig svært lite. Ser en på navn og koder er dette såkalt fri tekst. Det vil si at vi har strengere regler i vår objektkatalog enn vi får i ISO. Det pågår også en annen diskusjon i ISO, det som går på språknøytral angivelse av elementer. Her operere en med 3 ulike navn UML-Navn Short name Språknøytral identifikator Dette er navn som entydig beskriver typer, egenskaper,f,eks ikke blanke tegn) Dette er navn som benyttes som XMLtagger ved encoding. Dette er en språknøytral identifikator som benyttes for å sikre språkuavhengighet. Riktignok fortsatt basert på Latin Alphabet nr 6. ISO 90 har imidlertid en normative referanse til ISO/IEC 79-3 :994, Information technology Specification and standardization of data element Part 3: Basic attributes of data elements. Dette er den samme standarden som det henvises til for navnereglene, selv om dette er en annen part. Av denne grunn er det fornuftig å legge slike regler (semantiske, syntaktiske og leksikalske) til grunn, etter en nøyere gjennomgang. Her tenkes spesielt på de leksikalske reglene samt forkortelser. 2

22 Likheter/forskjeller mellom SOSI-del2 samt ISO 90 Feature Cataloge Methodology (Informativt) Konseptuell modell av ISO s Feature Catalogue. Feature Type Feature Type Name : text = M Feature Type Definition : text = C Feature Type Code : text = O Feature Type Aliases : list = O Feature Function Names : list = C Feature Attribute Names : list = C..* +consists of..* Feature Relationship Names : list = C +to 0..* +linked by defined by 0.. Feature Functions Feature Functi on Attribute Names : li st = M Object Feature Type Names : li st = C Feature Functi on Textual Description : text = M Functi ona l Lan guag e : te xt = C +specifies 0..* Feature Catalogue +consists of 0..* Feature Relationship Feature Relationship Name : text = M Feature Relationship Definition : text = C Feature Relationship Code : text = O Feature Types Included : list = M Feature Relationship Order Indicator : int = M Affected Feature Attributes : list = C Feature Relationship Constraints : list = O FeatureFunctionFormalDefinition().. +shall include Feature Catalogue Identifi cati on Feature Catalogue Name : text = M Feature Catalogue Scope : text = M Feature Catalogue Fiel d of Appli cation : text = O Feature Catalogue Version : text = M De fi ni tion So urc e : te xt = O +shall include.. Feature Catalogue Producer Producer Name : text = M Producer Postal Address : text = O Producer Country : text = M Producer Telecommunications Address : text = O +consists of +observes or affects 0..*..* Feature Attribute Feature Attribute Name : text = M Feature Attribute Definition : text = C +characterized by Feature Attribute Code : text = O Feature Attribute Value Data Type : text = M 0..* Feature Attribute Value Measurement Unit : text = O Feature Attribute Value Domain Type : int = 0 Feature Attribute Value Domain : text = C {Feature Attribute Value Domain Type Enumeration = } 0..* Feature Attribute Value Feature Attribute Value Label : text = M Feature Attribute Value Code : int = 0 Feature Attribute Value Definition : text = O 22