Teknisk Vägledning metadata

Transkript

1 PM 1(40) Teknisk Vägledning metadata

2 PM 2(40) Innehåll 1 Inledning Varför metadata Nationell metadataprofil Styrande och vägledande standarder Beskrivning av alla element... Fel! Bokmärket är inte definierat. 3 Tillhandahållande av data och tjänster inom den Nationella infrastrukturen för geodata Publicering som WMS-tjänster Publicering som WFS-tjänster Paketering av data med ATOM-filer Publicering av REST/SOAP tjänster Metadata för tjänster Resurstyper Tillhandahållande-modeller till data Kategorier av tjänster Inspires princip för dokumentation av tjänster WMS-tjänst Nedladdning(WFS) Nedladdning(Atom) Principer för dokumentation av WMS tjänster Metadata för en wmstjänst och dess komponenter Instruktion för dokumentation av WMS tjänster Detaljerad introduktion till dokumentation av visningstjänster Nedladdningstjänst Dokumentation av generella webbservices ex SOAP- eller REST-tjänster Gränssnitt mot geodatakatalogen via API Översikt Katalogtjänsten för den Nationella Geodatakatalogen Att söka via CSW Gränssnitt mot Öppna data Publicering av metadata som datamängder Fördjupning av vissa sektioner av metadataprofilen Initiativ Kontakter Tidsinformation Begreppet Resurs Tillhandahållande Tjänsteklassificering Format... 37

3 PM 3(40) 8.8 Kvalitetsrapporter Dokumentation med ISO 19115/ISO och Capabilities Publicering av metadata Publicering via webbaserad editor Publicering via kataloggränssnittet CSW Uppladdning av XML-filer Inledning 1.1 Varför metadata Produktionen av data och tjänster ökar hos alla myndigheter. Med den stora mängd data som tillgängliggörs blir det allt svårare att veta att rätt information för att lösa en uppgift hittats. Därför behövs beskrivningar av data på ett enhetligt sätt som gör att användare enkelt kan finna det som är relevant.informationen om data måste även vara tillräckligt omfattande så användaren kan bedöma om data är användbara. 1.2 Nationell metadataprofil En nationell metadataprofil är framtagen av SIS/TK323 i samverkan med den nationella profilen för geodata. Denna profil definierar de metadataelement som kan användas för att publicera metadata i Geodataportalen. Den nationella profilen definierar de element som är centrala för publicering av metadata i Geodataportalen och vilka specifika krav som ställs för att uppfylla Inspires krav på metadata. Det finns metadata element i den nationella metadataprofilen som inte är relevanta för alla typer av resurser som det publiceras metadata om. Det innebär att resurser kan publiceras i Geodataportalen med olika omfattning av metadata. Grovt kan vi se nedanstående kategorier av information. Resurser som tillhandahålles inom ramen för Inspire-direktivet Resurser som tillhandahålles inom ramen för Geodatasamverkan Resurser som tillhandahålles som Öppna data Resurser som inte ingår i någon av ovanstående kategorier (ex kommersiella data) Versioner av Nationell Metadataprofil Profil från SS-EN ISO 19115:2005-geodata.se Versioner Denna profil är giltig fram till Profil från 2017 SS-EN ISO 19115:2005-se Version 4 Denna är giltig från Från och med hösten 2017 kan denna profil användas för publicering i Geodataportalen

4 PM 4(40) 1.3 Styrande och vägledande standarder Inom ISO (International Standards Organization) har ett antal standarder för geografisk information tagit fram. Dessa ligger normal i serien ISO 191 xx ISO19115 anger vilka metadata som kan registreras enligt ISO och hur dessa element hänger samman. ISO19119 anger hur tjänster skall beskrivas med metadata samt kategorisering av olika tjänster ISO19139 definierar hur metadata enligt ISO19115 skall beskrivas i XML för att kunna användas vid kommunikationen mellan olika system. ISO19128 definierar WMS tjänster (karttjänster) enligt WMS 1.3. Som en del av detta dokument beskrivs även hur metadata för en WMS-tjänst skall hanteras via anropet GetCapabilities. För Inspire gäller följande dokument. Inspire genomförandebestämmelser för metadata: Anger vad som skall dokumenteras för Inspire-teman. Commission Regulation (EC) No. 1205/2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata was adopted on of 3rd December 2008, and published on the Official Journal of the European Union on 4th December (OJ L 326, , p ). Technical guidelines for metadata är en vägledning som är ett stöd i hur metadata kan skapas inom Inspire och även uppfyller ISO-standarder. Det finns två versioner av denna som är giltiga under en övergångsperiod. Version 1.3: Giltig fram till år 2020 INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO and EN ISO version 1.3 Version 2.0: Giltig från och med 2017 Technical Guidance for the implementation of INSPIRE dataset and service metadata based on ISO/TS 19139:2007 Version 2.01 Publicerad Nationell metadataprofil framtagen av SIS är ett stöd som beskriver hur vi på nationell nivå ska beskriva metadata vilket bl.a. täcker Inspires krav. Aktuell version är Denna motsvarar Inpires Technical guidelines version 1.3 Version 4.0 är under framtagning och beräknas vara färdig under hösten Inpires Technical guidelines version 2.0

5 PM 5(40) 2 Tillhandahållande av data och tjänster inom den Nationella infrastrukturen för geodata 2.1 Publicering som WMS-tjänster 2.2 Publicering som WFS-tjänster 2.3 Paketering av data med ATOM-filer Generella krav på nedladdningstjänsten enligt Inspire finns i: TDB [INSP 1] Genomförandebestämmelser TDB [INSP 2] Technical Guidelines TDB [INSP 3] Svenska vägledning Generella krav på hur nedladdningstjänster skall hanteras beskrivs i TBD Nedladdningstjänster med Atom Nedladdningstjänster som skapas med atom ger en stor flexibilitet i möjligheten att paketera olika filer för en enskild datamängd. Paketeringen kan ske med Olika format Olika referensområden Olika geografiska beskärningar Utan att nya metadataposter behöver skapas för respektive fil I sin enklaste form kan man tänka sig följande figur Atom Tjänsteflöde Atom Data Flöde 1 Atom Data Flöde 2 Atom Data Flöde 3 Atom Data Flöde 4 Figur 1.Figuren visar den grundläggande strukturen för nedladdningstjänster via Atom. I figur 1 visas hur det på högsta nivån finns en feed som beskriver själva tjänsten. Från tjänsten pekas sedan ett antal datamängds feeds ut. I dessa datamängds feeds kan det finnas länkar till datafiler i olika format, referenssystem eller omfattning. Det finns ingen begränsning på nivån datamängds feed. Här kan man skapa ytterligare nivåer med feeds om så behövs för att skapa en flexibel struktur.

6 PM 6(40) Atom Tjänsteflöde Atom Data Flöde 1 Atom Data Flöde 2 Atom Data Flöde 3 Atom Data Flöde 4 Atom Data Flöde 4.1 Atom Data Flöde 4.2 Atom Data Flöde 4.3 Figur 2.Figuren visar hur den grundläggande strukturen för nedladdningstjänster via Atom kan utökasmed ytterligare nivåer för feeds på datamängds nivå. Ett möjligt (fiktivt) exempel kan vara att i exemplet ovan motsvarar dataflöde 1,2,3,4 datamängder som beskriver de olika meteorologiska parametrarna nederbörd, vindhastighet, luftfuktighet och temperatur. För den fjärde parametern temperatur vill man tillhandahålla olika paketeringar av temperaturmätningar. Exempel på möjliga paketeringar är: Dataflöde 4.1 är alla mätningar genomförda paketerade stationsvis Dataflöde 4.1 är alla mätningar under innevarande år paketerade stationsvis Dataflöde 4.3 är dygnsvisa paketeringar av alla stationers data senaste veckan I varje datamängds feed kan länkar finnas tillgängliga som ger möjlighet till åtkomst av data i olika format (exempelvis shape och gml) och referenssystem. De krav som finns vad gäller metadata för Atom-flöden när de används för nedladdningstjänster är att metadata för de underliggande datamängderna skall pekas ut från flödet på tjänstenivå.

7 PM 7(40) Figur 3.Figuren visar ett exempel på hur ett tjänsteflöde med Atom har tre stycken entry s. Varje respektive Entry pekar ut ett datamängd-flöde. I tjänste-flödet ovan ses att i denna fil finns 4 stycken länkar med relationen describedby. (XMLelementet link med attributet rel). Länken med numret 1 pekar ut nedladdningstjänstens metadatapost i en katalogtjänst. Länkarna med numret 2 pekar ut metadata för respektive Entry s datamängd. Även här pekar länken mot en katalogtjänst dit metadata publicerats. För metadata inom Inspire och Geodatasamverkan rekommenderas att dessa poster finns publicerade till den nationella metadatakatalogen. Därigenom garanteras att prestanda och tillgänglighetskrav uppfylles. XML-struktur för Atom-filer Normalt finns tillägg till de vanligaste webbläsarna att läsa Atom-flöden och presentera innehållet på ett lättläst och strukturerat sätt. Exempel på detta visas nedan med en Atom-tjänst från Sveriges Geologiska Undersökning öppnad i internet explorer.

8 PM 8(40) Figur 4.Figuren visar hur en Atom-fil kan presenteras i en webbläsare om den följer vissa givna regler för hur en Atom-fil skal skrivas. För att att ändå kunna publicera användbara Atom-filer beskrivs nedan några möjligheter att designa dem så de är läsbara. Notera att dessa bara finns med som stöd för ideer till egna implementeringar. De är inte några referens implementeringar.

9 PM 9(40) Exempel på design av Atom-filer Sveriges Geologiska Undersökning Denna sidas xml-design är utformas enligt nedan Figur 5. XML-filen är exempel på en implementering av Atom-feeds från SGU.

10 PM 10(40) Detta flöde skiljer sig från [Insp 2] blanda annat genom att länkar till subflöden använder attributet Enclosure istället för Alternate. Sammanfattningstexten använder sig även av elementet Content utöver att den anges i Summary som är definierad av [Insp 2] Från JRC Utdrag ur den underliggande XML-filen visas nedan

11 PM 11(40) Figur 6. XML-filen är exempel på en implementering av Atom-feeds från JRC. Värt att notera här är att man använt CDATA-sektioner i xml-strukturen och skapat länkar till subflöden genom att skapa länkar i dessa CDATA-sektioner. Detta gör informationen lättläst men maskin till maskin kommunikation blir svårare. 2.4 Publicering av REST/SOAP tjänster Metadata enligt den nationella metadataprofilen kan användas för att publicera generella REST/SOAP tjänster. I den nationella metadataprofilen version 4.0 kommer speciella regler definieras för hur webtjänster som täcker något av de 34 Inspire-teman skall dokumenteras och publiceras. 3 Metadata för tjänster Tjänster med geografisk information är en viktig beståndsdel i den nationella infrastrukturen för geodata. För att informationen i tjänsterna skall vara fullt användbar och tydlig för användarna behöver tjänsterna dokumenteras enligt specifika regler. För tjänster som har hårt kopplade data dvs redan vid tjänstens framtagning så är det bestämt vilka data som tjänsten arbetar mot, t ex WMS och WFS -tjänster, är det viktigt att även de ingående datamängderna dokumenteras. Metadata för andra typer av tjänster ex REST- och SOAP-tjänster också kan publiceras till Geodataportalen. För att förstå varför metadata för tjänster behövs är en förståelse av hur ISO:s principer för hantering av olika resurstyper datamängder, serier och tjänster nödvändig. 3.1 Resurstyper Det finns olika typer av saker som vi vill kunna dokumentera och göra synliga på internet. Det kan tex vara en datamängd, en tjänst, ett dokument, en applikation, en webbapplikation eller en webbsida. Alla dessa typer av objekt kallas med ett gemensamt namn för Resurser. Detta för att slippa lista alla typer som kan tänkas bli dokumenterade.

12 PM 12(40) Inom den Svenska infrastrukturen för geodata definierar vi idag endast 3 resurstyper Datamängd Serie Tjänst Den grundläggande principen för dessa är. Datamängder och serier beskriver data och dessa egenskaper. Innehåll, aktualitet, kvalite, informationsansvariga mm. Tjänster beskriver en tjänstebaserad åtkomst till data 3.2 Tillhandahållande-modeller till data Tillhandahållande av data kan göras via flera olika modeller: A För att tillhandahålla datamängder som information online är målsättningen att information skall tillhandahållas via tjänste-gränssnitt för enkelt utbyte maskin-maskin. Via en tjänst kan man exempelvis fråga tjänsten efter tillgängliga metoder för åtkomst och metadata för tjänsten. Exempelvis har en WMS metoden GetCapabilities och från GetCapabilities kan man anropa automatiskt få en adress för metadata. Denna princip är central för hur ISO och OGC definierar hur datamängder konsumeras via tjänster. Med denna princip gäller att: En datamängd kan tillhandahållas via många tjänster Datamängden beskriver inte själv tjänste-gränssnittet I tjänste-metadata dokumenteras tjänstens egenskaper såsom licenser, prestanda, tillgänglighet, kontaktinformation Datas innehåll skall inte beskrivas i tjänsten Tillhandahållande av filbaserade data görs även detta via nedladdningstjänster med formatet ATOM. I den Svenska Infrastrukturen för Geodata kan man dock dokumentera andra typer av datamängder och tjänster enligt en enklare modell. Följande är tillsvidare tillåtet: B En metadatapost beskriver en viss avgränsad mängd data. För att tillhandahålla denna paketeras data som en zip-fil och länken till zip-filen registreras direkt i datamängdens metadata. C En metadatapost beskriver en viss avgränsad mängd data. Metadata skapas med resurstypen datamängd. För att tillhandahålla denna skapas ett API exempelvis som ett REST-api. Adressen till rest-api:t registreras direkt i datamängdens metadata. D En metadatapost beskriver en viss avgränsad mängd data. Metadata skapas med resurstypen tjänst. För att tillhandahålla denna skapas ett API exempelvis som ett REST-api. Adressen till RESTapi:t registreras direkt i tjänstens metadata. 3.3 Kategorier av tjänster Tjänster som kommer att publiceras till Geodataportalen är av olika karaktär. Visningstjänster (OGC:WMS) Nedladdningstjänster (OGC:WFS, Atom) Generella Webbservices (SOAP, REST)

13 PM 13(40) WMS och WFS skiljer sig från övriga två tjänster genom att dessa är Fast kopplade (Tightly coupled) tjänster. DVS tjänsten har i förväg definierade datakällor som inte kan ändras av användaren. Principerna för metadata för dessa tjänstetyper blir därmed speciella. I tjänstemetadata som dessa tjänstetyper erbjuder beskrivs både vilka operationer de tillhandahåller och länkar till vilka data som ingår. Vid publicering av WPS (Web Processing Services) och generella Webservices till portalen kommer fokus att vara bara på vilka operationer som tjänsterna tillhandahåller och vilken ingående och utgående information som tjänsten konsumerar/producerar. Ytterligare metadata kommer här att behövas för att tjänsten skall kunna användas utan manuell konfiguration. Med detta menas att metadata om tjänsten måste vara så fullständig att ett annat system kan koppla upp sig med automatik mot en tjänst utan manuella steg. 3.4 Inspires princip för dokumentation av tjänster En grundläggande princip för dokumentation av tjänster enligt ISO och OGC som tekniskt realiserats i technical guidelines för Inspire-direktivet är att: Både tjänsten och dess underliggande datamängder skall dokumenteras. Man skall kunna nå tjänstens metadata direkt från tjänsten (dvs tjänsten skall själv ha information om var metadata som beskriver den finns) Metadata för datamängder skall kunna nås från tjänsten Detta kan exemplifieras med nedanstående figurer som beskriver de just nu aktuella tjänstetyperna. Visning (WMS) Nedladdning (WFS och Atom) 3.5 WMS-tjänst WMS-tjänst Tjänste metadata Sync Capabilities OperatesOn MetadataURL Figur 7. Beskriver relationerna mellan en WMS-tjänst och dess metadata. Tjänstens capabilities-dokument pekar ut metadata för tjänsten som helhet. Varje lager pekar även ut metadata för varje lagers datamängd via MetadataURL. Tjänstens metadatapost pekar också ut metadata för varje ingående datamängd via OperatesOn. Dessa relationer kommer att beskrivas mer detaljerat i kommande kapitel.

14 PM 14(40) 3.6 Nedladdning(WFS) Direktåtkomst WFS-tjänst Tjänste metadata OperatesOn Datamängds-metadata Capabilities MetadataURL Figur 8. Beskriver relationerna mellan en WFS-tjänst och dess metadata. Tjänstens capabilities pekar ut metadata för tjänsten som helhet. Varje featuretype pekar även ut metadata för varje objekttyps datamängd via MetadataURL. Tjänstens metadatapost pekar också ut metadata för varje ingående datamängd via OperatesOn. Dessa relationer kommer att beskrivas mer detaljerat i kommande kapitel. 3.7 Nedladdning(Atom) Tjänste metadata OperatesOn Datamängds-metadata ATOM-flöde link Atom/Feed link Figur 9. Beskriver relationerna mellan en Atom-flöde och dess metadata. Tjänstens Atom-flöde på tjänstenivå pekar ut metadata för tjänsten som helhet. Varje entry (datamängd) i Atomfilen pekar även ut metadata för varje datamängd via link-elementet. Tjänstens metadatapost pekar också ut metadata för varje ingående datamängd via OperatesOn. Dessa relationer kommer att beskrivas mer detaljerat i kommande kapitel. 3.8 Principer för dokumentation av WMS tjänster En WMS-tjänsts beståndsdelar

15 PM 15(40) Figur 10. Beskriver en wms-tjänsts logiska struktur. En tjänst består av ett antal lager. Paketeringen av ett antal lager i en tjänst kan göras utifrån olika behov. Exempel på detta är lagren i en tjänst kan innehålla geografiskt heterogen information över skilda geografiska områden och med skilda geografiska referenssystem. Det tematiska innehållet kan även variera. Men det är även möjligt att skapa en tjänst med data som täcker ett specifikt område för presentation i ett gemensamt geografiskt referenssystem och som innehåller data för ett specifikt tematiskt område. Denna flexibilitet gör att dokumentationen av tjänsterna måste vara flexibel och tillgodose ovanstående varierande behov. Därför beskrivs tjänsten separat från de ingående datamängderna. Det är möjligt för en datamängd att användas som datakälla i olika lager i två skilda tjänster. Historiskt har i flera fall WMS tjänster publicerats efter tre olika principer Tjänsten innehåller ett fåtal tematiska lager samt en bakgrundskarta som referens. Tjänsten behövde alltså ingen extern tjänst för att kunna användas Tjänsten innehåller ett fåtal lager med ett närliggande tematiskt innehåll Tjänsten innehåller ett stort antal lager med stora skillnader i tematiskt tinnehåll, aktualitet mm. Med denna utgångspunkt har det för de två översta typerna räckt att beskriva hela tjänsten med metadata då denna har haft ett så homogent och specialanpassat innehåll. Men med det tredje alternativet blir tjänsterna så pass heterogena att det inte räcker med en (1) metadatapost för tjänsten som helhet. Tjänsten är bara en behållare för lager av olika beskaffenhet. För att kunna hantera ovanstående vid publiceringen till den nya versionen av portalen under 2017 är det därför möjligt att publicera metadata om en datamängd som har flera olika distributionsformer. För en och samma datamängd kan det alltså vara möjligt att den har exempelvis: - En länk till en nedladdningsbar zip-fil med data - En länk till en tjänst där datamängden är datakälla till ett eller flera lager - En länk till ytterligare en tjänst där datamängden är datakälla till ett annat lager Ovanstående synsätt delas inte av alla. I många länder har man hittills inte dokumenterat tjänster på datamängdnivå utan endast dokumenterat tjänsterna som helhet. Detta är delvis styrt av ambitionsnivå då arbetet blir mer omfattande när varje enskild datamängd skall dokumenteras. Inom arbetet med den svenska infrastrukturen har vi dock ansett att informationen för användaren inte blir tillräckligt användbar om inte de ingående datamängdernas relation till lager i en tjänst blir tydligt för användaren. Därför är målsättningen att alla tjänster som publiceras till den nationella infrastrukturen skall dokumentera de ingående datamängderna. Alternativ för dokumentation av en WMS-tjänst En WMS-tjänst kan dokumenteras på två olika sätt. Metod 1 Via dokumentation med en metadatapost enligt ISO19115/ISO19139.

16 PM 16(40) Metod 2 Genom att tjänsten dokumenteras i sin helhet i tjänstens Capabilitiesdokument Orsaken till att båda ovanstående metoder för att dokumentera en tjänst finns är att de standarder som idag används har tagits fram genom 2 olika organisationer, ISO och OGC. ISO har arbetat fram standarderna ISO19115 för generella metadata och ISO19119 för metadata om tjänster. WMS-tjänster och dess hantering av metadata som del av tjänstens gränssnitt ( via metoden GetCapabilities) har utvecklats av OGC (Open Geospatial Consortium). Arbete pågår att försöka få en enhetlig hantering av ovanstående 2 standarder, men fram tills dessa metoder existerar är en enhetlig metodik det bästa vi kan åstadkomma. Det finns ett visst överlapp i hanteringen av metadata från ISO och OGC. Det finns även en tredje möjlighet att dokumentera en tjänst och då mera ur ett tekniskt gränssnittsperspektiv. Det är beskrivning av en tjänst med en wsdl-fil. Detta används huvudsakligen för beskrivning av generella webbservices (REST/SOAP). Principiellt ligger en WMS-tjänsts capabilities-dokument nära innehållet i en wsdl-fil. Utökade beskrivningar av hur wsdl-filer kan integreras med beskrivning av generella webbservices med ISO19115 kommer att tas fram inom Inspire arbetet inom det närmaste året. Det pågår därför diskussioner hur ovanstående tre metoder för dokumentation skall kunna integreras så metadata inte behöver hanteras på fler ställen. Dock har inga tydliga lösningar på detta framtagits som kan användas ännu. Metod 1 Dokumentation med ISO19115 Tjänsten kan dokumenteras i sin helhet med metadata i ISO19115/ISO19119 så att metadata följer Inspires krav. Detta kan exempelvis göras i Redigeringsverktyget för metadata eller i de webbaserade formulären. Metod 2 Dokumentation med Capabilities-dokument En WMS-tjänst har en adress som kan anropas med tre huvudsakliga operationer. GetCapabilities GetMap GetFeatureInfo WMS-tjänsten har alltså en definierad adress som kan svara på dessa anrop. Exempelvis: Metadata för tjänsten kan beskrivas i tjänstens Capabilities-dokument. Dock kan inte all information som hanteras i ISO19115 anges i Capabilities-dokumentet. Därför är det just nu rekommenderat i den Svenska Infrastrukturen för Geodata att tjänstens fullständiga metadata hanteras i ett separat metadatadokument enligt ISO19115 (metod 1). Längre fram i texten beskrivs fler alternativ för att hantera tjänstemetadata enligt Inspires krav.

17 PM 17(40) 3.9 Metadata för en wmstjänst och dess komponenter Tjänste metadata OperatesOn Datamängds-metadata WMS-tjänst Sync Capabilities MetadataURL Figur 11. Beskriver hur en wms-tjänst kan beskrivas med metadata. Tjänsten beskrivs i ett capabilities-dokument som är integrerat i kartjänsten (wms-tjänsten). Varje lagers underliggande data i tjänsten kan även beskrivas med en metadatapost enligt ISO Hela tjänsten kan även dokumenteras med ett dokument enligt ISO Capabilities En wms-tjänst är dokumenterad med ett capabilities-dokument. Detta beskriver tjänsten som helhet men även dess ingående lager. I varje lager som beskrivs capabilties-dokumentet kan man referera (via MetadataURL) till ett metadata dokument i ISO19115 som beskriver varje enskilt lagers underliggande datamängd. Datamängds metadata Varje enskilt lagers underliggande datamängd i tjänsten kan beskrivas med metadata enligt ISO Observera att det inte är varje enskilt lager som dokumenteras utan det är de underliggande datamängder till respektive lager som dokumenteras. Tjänstemetadata ISO19115/ISO19119 Tjänsten kan som helhet även beskrivas med ett metadatadokument enligt ISO19115/ISO19119 Relationer mellan tjänstemetadata i ISO19115/ISO19119 och Lagermetadata Som pilarna i figuren ovan visar kan man skapa relationer mellan Tjänstemetadata i ISO9115/ISO19119 och dess ingående lager. Det gör att man för tjänsten kan beskriva vilka datamängder som ingår i tjänsten. För att få fram den omvända informationen dvs i vilka tjänster en viss datamängd ingår saknas denna information i metadataposten för datamängden. Informationen är dock tillgänglig genom att denna fråga kan ställas mot katalogtjänsten. Vilka tjänster opererar på denna datamängd För att beskriva i dokumentationen för en tjänst vilka lager som ingår skall man använda elementet Kopplade resurser Lager respektive datamängder i en WMStjänst En tjänst har en eller flera lager definierade i sin capabilities-fil. Det är lager (Layer) som anropas när man vill ange vilka delar av en tjänst som skall ritas upp. Dock är det normalt den underliggande datamängden som skall dokumenteras och publiceras som metadata. Det är dock inte alltid ett 1-1 för hållande mellan ett lager och dess data. Som figuren nedan visar kan en datamängd ingå i flera olika lager. Det kan vara skillnader mellan olika lager som använder samma datamängd som exempelvis: Skala som lagren visas i

18 PM 18(40) Symboliseringen kan variera Urval av objekt kan variera I normalfallet är det alltså de underliggande datamängderna som skall dokumenteras. Tjänst Lager Lager Lager Lager Datamängd Datamängd Datamängd Figur 12. Visar relationen mellan lager i en tjänst och dess underliggande datamängder. En datamängd kan användas som källa i flera olika lager. En datamängd kan även användas i flera olika tjänster En datamängd kan ingå i flera olika tjänsters lager. Det är inte bara i flera lager i en enskild tjänst som en enskild datamängd kan finnas Instruktion för dokumentation av WMS tjänster Nedanstående kan ses som en vägledning till hur en tjänst och dess ingående lager kan dokumenteras. Genom att följa principerna för denna så uppfyller man kraven från Inspire och tar fram olika dokument i den ordning som behövs. Referera till metadataposter I nedanstående dokument anges att man från en resurs skall peka ut metadata för en annan resurs. Det som normalt avses är då att metadata skall peka på en publikt åtkomlig adress där metadata för en annan resurs lagras. Alla användare skall kunna nå denna metadatapost. Det finns möjlighet att lägga denna metadatapost på valfritt ställe. Följande möjligheter kan ses: Publicera metadataposten till Geodataportalen och referera till den via katalogtjänstens GetRecordByID, exempelvis nedan där metadataposten med ID=35afbd3a-fa94-4b52-97d d89ae8 kan nås. (Denna metod rekommenderas av Geodataportalen, då driftssäkerhet i relation till bl.a. Inspires krav säkerställs) request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full& id= 35afbd3a-fa94-4b52-97d d89ae8& outputschema=csw:isorecord

19 PM 19(40) Publicera metadataposten till en egen myndighets-driven katalog (exempelvis myndighetens egen CSW-katalog) och referera till den via GetRecordByID Publicera metadataposten genom att lägga upp den som en XML-fil på en myndighetsdriven webbplats/ftp och referera till den via en URL som pekar ut filen. Observera att alla ovanstående metoder innebär att metadata skall vara tillgängligt via http/https utan lösenord. Övergripande checklista för att dokumentera en tjänst och dess ingående datamängder. I. Analys a. Identifiera information om det som skall dokumenteras. b. Vilken avgränsning skall göras på vilken information som skall ingå i den specifika tjänsten. c. Identifiera datamängder som skall användas för tjänsten d. Definiera vilka lager som tjänsten skall innehålla II. Skapa tjänsten a. Notera adressen till tjänsten (URL) b. Capabilities-informationen för tjänsten behöver ej vara komplett i detta i detta ögonblick III. Skapa metadataposter a. Skapa en metadatapost för respektive datamängd i. Notera fileidentifier för varje metadatapost (unikt medatadataid). b. Skapa en metadatapost för tjänsten. i. Notera fileidentifier för tjänsten (unikt metadataid). ii. Kopplade resurser skall peka ut de datamängder som används av tjänsten. Detta skall ske genom att metadataposterna i katalogtjänsten pekas ut Exempelvis. <srv:operateson xlink:href=" request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full& id= Datamangd1-fa94-4b52-97d d89ae8& outputschema=csw:isorecord"/> <srv:operateson xlink:href=" request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full& id=datamangd1-fa94-4b52-97d d89ae8& outputschema=csw:isorecord"/> <srv:operateson xlink:href=" request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full&

20 PM 20(40) id=datamangd1-fa94-4b52-97d d89ae8& outputschema=csw:isorecord"/> iii. Online-Linkage skall peka ut WMS-tjänsten. (II:a) IV. Uppdatera capabilities för tjänsten a. Tjänstens metadataurl skall peka metadataposten för tjänsten (III:b) Använd ex en URL med GetrecordById b. Varje enskilt lagers metadataurl skall peka på respektive datamängd. (III:a) Använd ex en URL med GetrecordById V. Publicera alla ovanstående metadataposter VI. Tester a. Kontrollera att tjänsten går att förhandsgranska i Geodataportalen. Du måste redan ha en tjänst publicerad från din organisation för att kunna testa detta. Om du inte har det testa tjänsten i ex ArcGIS eller QGIS. i. Online linkage skall peka på tjänstens adress ii. Tjänsten skall följa regelverk för WMS 1.3 b. Kontrollera att tjänstens OperatesON variabler pekar på fungerande adresser (kan vara en eller flera) c. Kontrollera att metadata kan visas för varje ingående lager i tjänsten. d. (bonus) kontrollera om ingående datamängder har länk till det/de lager i WMS-tjänsten som de presenteras via.

21 PM 21(40) 3.11 Detaljerad introduktion till dokumentation av visningstjänster Nedanstående figur beskriver mer detaljerat hur en visningstjänst, dess ingående datamängder samt korrensponderande metadata relaterar till varandra. Metadata Resurser WMS-tjänst D MetadataURL Capabilities H Beskrivs i Lager 1 A Beskriver C Resursadress E MetadataURL (lager) F Definierar Lager 2 Lager 3 Lager 4 Datamängd 1 B Beskriver Datamängd 1 WMS-tjänst A Sammankopplad resurs Datamängd 2 B Beskriver Datamängd 2 G Nyttjar data Datamängd 3 B Beskriver Datamängd 3 Figur 13. Visar hur en wms-tjänst och dess ingående datamängder relaterar till de metadata som beskriver dem. Dessa relationer beskrivs i detalj nedan. Resurser kontra metadata I figuren visas de resurser som skall dokumenteras till höger (tjänst samt datamängder). Till vänster visas de metadata som beskriver dessa resurser. WMS-tjänst och data WMS-tjänsten och de delar som är relaterade består av följande delar.

22 PM 22(40) Visningstjänst (WMS-tjänst) Detta är själva tjänsten som genererar kartbilder via ett standardiserat gränssnitt (WMS). Capabilities-dokumentet WMS-tjänsten dokumenteras via ett capabilities-dokument. Capabilities-dokumentet beskriver tekniska aspekter av tjänsten. Det finns möjlighet att beskriva mer generella metadata i capabilities-dokumentet också. Vi rekommenderar dock att hantera dessa metadata i ett separat metadatadokument. Lager I capabilitiesfilen definieras ett antal lager som kan anropas vid uppritning av en kartbild. Varje lager har en underliggande datakälla. Flera lager kan nyttja samma datakälla. I capabilities-filen skall metadata för dessa underliggande datamängder pekas ut. Detta görs genom att adressen till en publik URL där dessa metadata ligger anges i elementet MetadataURL för varje lager.

23 PM 23(40) Datamängd Detta är de datamängder som skall publiceras till Geodataportalen. Det är alltså inga separata poster som publiceras bara för tjänsten. Dessa datamängder skall pekas ut från lager-definitionerna i capabilities-filen. Metadata för WMS-tjänst och datamängd Metadata för ingående datamängd Varje datamängd som är utpekad enligt dataspecifikationen enligt varje tema skall dokumenteras med en metadatapost. Denna post skall publiceras till den nationella geodataportalen. I tjänstens capabilities-dokument skall man referera till denna datamängd genom att ange adressen till metadata via elementet MetadaURL som kan anges för varje lager i tjänsten Metadata för tjänsten Enligt figuren ovan skall det finnas en post med metadata som beskriver tjänsten som helhet. Denna metadatapost skall pekas ut via elementet MetadataURL i Capabilities dokumentet för tjänsten. Detta är ett element som anges för tjänsten som helhet och inte bara för Man skall också för en tjänst kunna peka ut de underliggande datamängderna via tjänstens metadata. Detta anges i elementet OperatesOn. Tjänsten skall också via en Online-länk peka ut tjänstens URL.

24 PM 24(40) Ange länkar till lager i wms-tjänst vid registrering av datamängder För att datamängder som ingår i en tjänst skall vara lätt åtkomliga att finna igen kan man för en datamängd ange länken via Online-linkage till de lager som datamängden presenteras via. Detta är en rekommendation från Geodataportalen och ej ett krav från Inspire. Varje datamängd som dokumenteras som är en del av en WMS-tjänst rekommenderas ha en onlinelinkage till de lager som denna datamängd verkar mot. I adressen skall layer=lager1,lager2 etc. användas. Namnet på OnlineLinkage kan lämpligen vara samma titel som för Title-element för lagret i capabilities. Exempelvis om en tjänst är dokumenterad som har adressen I denna tjänst ingår en datamängd som innehåller avrinningsområden. Detta presenteras via ett lager i wms-tjänsten som heter SMHI_avromr. Då är det lämpligt att i metadata för datamängden ange en online-länk till specfika lager Nedladdningstjänst Atom eller WFS Implementering av nedladdningstjänster enligt Inspire-direktivet kan göras på två huvudsakliga sätt. WFS-tjänst Atom-feed Rent tekniskt skulle det vara möjligt att lösa kraven på nedladdningstjänster på andra sätt än dessa två men. Men genom att använda WFS eller Atom kan de tekniska riktlinjer som tagits fram användas och därigenom blir det enklare att säkerställa att genomförandebestämmelserna uppfyllts. För en nedladdningstjänst gäller samma principer som för en visningstjänst när det gäller dokumentation. Det som skiljer dem åt är att en visningstjänst av typ WMS har ett capabilitiesdokument som via MetadataURL pekar ut tjänstens metadatapost respektive datamängdernas metadataposterna. För en nedladdningstjänst av typen Atom hanteras motsvarande information med länkar i Atom-feed dokument.

25 PM 25(40) Metadata Resurser Atom Servicefeed C Resursadress D feed/link (described by) AtomDS Feed 1 AtomDS Feed 2 Feed/Entry/Link (described by) AtomDS Feed 3 AtomDS Feed 4 Datamängd 1 Datamängd 1 Nedladdningstjänst A Sammankopplad resurs Datamängd 2 Datamängd 2 Datamängd 3 Datamängd 3 Figur 14. Beskriver hur en Nedladdnings-tjänst av typ Atom och dess entrys/subflöden är relaterade till varandra. Figur 15. Beskriver hur en Atom-feed kan se ut på tjänstenivån (översta nivån). Den första linjen med understrykning visar en länk från Atom-feeden som pekar ut metadata för tjänsten som helhet. De övriga tre röda linjerna pekar ut en länk till metadata för varje datamängd (entry)som finns i Atom-filen.

26 PM 26(40) VII. Övergripande checklista för att dokumentera en Atom- tjänst och dess ingående datamängder. Analys a. Identifiera information om det som skall dokumenteras b. Identifiera datamängder som skall användas för tjänsten c. Definiera vilka lager som tjänsten skall innehålla VIII. Skapa tjänsten a. Notera adressen till Atom-filen på tjänstenivå (URL) IX. Skapa metadataposter a. Skapa en metadatapost för respektive datamängd Notera fileidentifier för varje metadatapost (unikt medatadataid). b. Skapa en metadatapost för tjänsten. Notera fileidentifier för tjänsten (unikt metadataid). i. Kopplade resurser skall peka ut de datamängder som används av tjänsten. Detta skall ske genom att metadataposterna i katalogtjänsten pekas ut (III:a). ii. OnlineLinkage skall peka ut Atomfilen (II:a) X. Uppdatera innehållet i Atom-filen på tjänstenivå a. Feedens element link med attributet describedby skall peka metadataposten för tjänsten (III:b) b. Varje entrys element link med attributet describedby skall peka på respektive datamängd. (III:a) XI. Publicera alla ovanstående metadataposter Exempel - Publicering av en Oceanografiska data med nedladdningstjänst via Atom Skapa metadataposter för datamängderna Dessa existerar redan innan publiceringen av WMS-tjänsten. Unik identfierare för metadata för dessa datamängder är f28575c a fb0 (Salthalt timvärde momentan) 75076d38-25e6-4ad6-9cb f93 (Strömhastighet timvärde momentan) bbe9d940-cd80-402e-bcc8-ac587d5be230 (Signifikant våghöjd timvärde 30-min medelvärde) 25076d38-25e6-4ad6-9cb f93 (Strömriktning timvärde momentan) Skapa en metadatapost för nedladdningstjänsten Notera för metadatamängdens identifierare för nedladdningstjänstens metadata post c2-11c3-4cb4-bcf0-d05924e16a10 Registrera OperatesOn för ingående datamängder i tjänsten Detta är samma datamängder som är källa för nedladdningstjänsten som för WMS-tjänsten (Det stämmer inte riktigt i alla lägen)

27 PM 27(40) <srv:operateson xlink:href=" request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full& id=f28575c a fb0& outputschema=csw:isorecord" /> <srv:operateson xlink:href=" request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full& id=75076d38-25e6-4ad6-9cb f93& outputschema=csw:isorecord" /> <srv:operateson xlink:href=" request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full& id= bbe9d940-cd80-402e-bcc8-ac587d5be230& outputschema=csw:isorecord" /> Figur 16. Exempel på Sammankopplade resurser som pekar ut metadata för de datamängder en tjänst opererar på. Registrera adressen till atomfilens root-nivå, dvs atom-filen på tjänste-nivå Figur Uppdatera MetadataURL:r i Atomfil I Atomflödets huvudnivå skall man ange MetadataURL till den fullständiga tjänstebeskrivningen i ISO 19115/ISO Detta görs med elementet <link> och med angivande av attributet describedby

28 PM 28(40) Figur 18. Figuren visar ett utdrag ur Atomfilen på tjänstenivå. En länk pekar ut metadata som helhet för tjänsten i en katalogtjänst. I Atomflödets huvudnivå skall man ange MetadataURL till metadata för varje ingående datamängd (entry). Detta görs med elementet <link> och med angivande av attributet describedby. Atomfilen innehåller data från tre datamängder och har därmed tre entrys och länkar till metadata. Figur 19. Figuren visar ett utdrag ur Atomfilen på tjänstenivå. En länk pekar ut metadata för varje datamängd (entry) 3.13 Dokumentation av generella webbservices ex SOAP- eller REST-tjänster Även generella webbservices som inte direkt genererar en kartbild kan publiceras till Geodataportalen. Exempel på sådana typer av webbservices är SOAP-tjänster REST-tjänster I princip kan alla typer av tjänster dokumenteras och publiceras med ISO19115/ISO Dessa kan normalt inte förhandsgranskas i Geodataportalen på samma sätt som WMS men de kan dokumenteras med liknande metadata som övriga tjänster.

29 PM 29(40) Utöver de metadata för tjänster som normalt rekommenderas är det därför lämpligt att ytterligare dokumentation av tjänsten görs tillgänglig via en länk från metadataposten. Det kan vara en länk till en webbsida eller ett pdf-dokument. Det man normalt beskriver i ett sådant dokument är exempelvis: Metoder och anrop som webbservices stöder Exempel på användning Länk till wsdl-fil Det är i huvudsak teknisk information riktat till utvecklare eller systemintegrerare så att man vet hur tjänsten kan användas. För en WMS-tjänst finns motsvarande information i capabilities-dokumentet. 4 Gränssnitt mot geodatakatalogen via API 4.1 Översikt Geodataportalen har ett gränssnitt för användare som vill söka efter information. Om istället en annan applikation vill söka i katalogen så finns det ett standardiserat gränssnitt för sådana dator till dator sökningar.. Detta gränssnitt heter CSW (Catalogue Service Web). Just nu är det version CSW ISO-API 2.02 som är aktuell version. 4.2 Katalogtjänsten för den Nationella Geodatakatalogen Denna katalogtjänst kan nås på: Denna adress ändrades under Tidigare var adressen eller Båda dessa kommer även i fortsättningen fungera under en övergångsperiod. 4.3 Att söka via CSW CSW stöder några olika operationer. Dessa är GetCapabilities GetRecords GetRecordById DescribeRecord Specifikationen för CSW 2.02 är följande: OpenGIS Catalogue Services Specification ISO Metadata Application Profile (1.0.0) Där kan man finna mer detaljerad information om hur man tex kan söka på olika kriterier. GetCapabilities

30 PM 30(40) GetCapabilities är en obligatoriskt operation som alla CSW-tjänster måste uppfylla. getcapabilities ger en klient möjligheten att fråga en CSW-tjänst vad den kan svara på för frågor. Det katalogtjänsten ger som svar är ett xml-dokument som beskriver vad tjänsten kan. För att anropa katalogtjänsten kan man använda nedanstående anrop Exempel på HTTP GET Request=GetCapabilities& Service=CSW& Version=2.0.2 Exempel på HTTP POST <?xml version="1.0" encoding="utf-8"?> <csw:getcapabilities xmlns:csw="http: // service="csw"> <ows:acceptversions xmlns:ows=" <ows:version>2.0.2</ows:version> </ows:acceptversions> <ows:acceptformats xmlns:ows=" <ows:outputformat>application/xml</ows:outputformat> </ows:acceptformats> </csw:getcapabilities> GetRecords The obligatoriska operationen GetRecords ger möjlighet att söka i data på olika sätt samt presentera resultatet enligt olika modeller. Frågan som skickas specificeras i två stycken parametrar. Constraint och typename. Constraint definierar urvals kriterier för de objekt som skall returneras. typenames definierar på vilka objettyper i metadatamodellen som frågor skall ställas mot. Resultatet som returneras styrs av följande argument: outputschema anger vilken xml-schema som resultatet returneras i ElementName/ElementSetName anger vilken del av xml-schemat som angivits i outputschema som skall returneras för varje post. Nedanstående fråga till katalogen frågar efter alla poster som innehåller texten GSD Exempel på HTTP GET request=getrecords& service=csw& version=2.0.2& namespace=xmlns(csw= resulttype=results& outputschema=csw:isorecord& outputformat=application/xml&

31 PM 31(40) maxrecords=10& typenames=csw:isorecord& elementsetname=summary& constraintlanguage=cql_text&constraint_language_version=1.1.0&constraint=anytext LIKE '%gsd%' GetRecordById Operationen GetRecordByID returnerar metadata för en eller flera poster genom att ange dess identifierare. Normalt används denna operation i kombination med GetRecord. i ett första steg söks ett antal poster ut med GetRecord. Därefter hämtas de aktuella posterna med GetRecordById. Exempel på HTTP GET request=getrecordbyid& service=csw& version=2.0.2& elementsetname=full& id= 35afbd3a-fa94-4b52-97d d89ae8& outputschema=csw:isorecord Exempel på HTTP POST <?xml version="1.0" encoding="utf-8"?> <csw:getrecordbyid xmlns:csw=" service="csw" version="2.0.2" elementsetname="breif" outputschema="csw:isorecord"> <csw:id> f-e712-4dbe ef525db26cb</csw:id> </csw:getrecordbyid> DescribeRecord DescribeRecord är en obligatorisk funktion som beskriver katalogtjänstens informationsmodell Exempel på HTTP GET htttp:// request=describerecord& service=csw& version=2.0.2 Exempel på HTTP POST <csw:describerecord xmlns:csw=" service="csw"

32 PM 32(40) /> version="2.0.2" outputformat="application/xml" schemalanguage=" 5 Gränssnitt mot Öppna data Beskriver hur vår profil kan mappas mot Öppna data och hur det rent tekniskt fungerar i vår katalogtjänst Hur våra element i ISO19115 mappas mot element i DCAT-AP 6 Publicering av metadata som datamängder För att datamängder som ingår i en tjänst skall vara lätt åtkomliga att finna igen kan man för en datamängd ange länken via Online-linkage till de lager som datamängden presenteras via. Detta är sedan 2013 en rekommendation från Geodataportalen men från 2017 är detta ett krav för organisationer som publicerar tjänster på Geodataportalen. Varje datamängd som dokumenteras som är en del av en WMS-tjänst rekommenderas ha en onlinelinkage till de lager som denna datamängd verkar mot. I adressen skall layer=lager1,lager2 etc. användas. Online-länkens namn i metadata kan lämpligen vara samma som för Title-element för lagret i capabilities. Exempelvis om en tjänst är dokumenterad som har adressen I denna tjänst ingår en datamängd som innehåller avrinningsområden. Detta presenteras via ett lager i wms-tjänsten som heter SMHI_avromr. Då är det lämpligt att i metadata för datamängden ange en online-länk till 7 Fördjupning av vissa sektioner av metadataprofilen Vid framtagningen av den nationella metadataprofilen och implementering av denna i Geodataportalen är det ett antal avvägningar som gjorts. Dessa avvägningar beskrivs här något mer utförligt och ger en bakgrund till hur ett antal element skall hanteras. Denna vägledning täcker inte in alla metadataelement, istället är en fördjupning gjord på de element som normalt skapar mest frågetecken för de som skall skapa metadata. Det är inte nödvändigt att läsa detta kapitel för att publicera metadata enligt den nationella metadataprofilen men avsikten är att skapa en förståelse till varför ett visst element hanteras som det gör 7.1 Initiativ Nyckelordslexikonet Initiativ är ett metadata element som finns med i Den nationella metadataprofilen som ett Nationellt krav. Elementet är villkorat för vissa typer av resurser. Definitionen av nyckelordslexikonet Initiativ är enligt följande Titel: Initiativ Publiceringsdatum: Version: 1.0 Giltiga nyckelord Nyckelord: Inspire

33 PM 33(40) Nyckelord: Geodatasamverkan Nyckelord: Öppna data Vid publicering av resurser till Nationella Geodataportalen kan man ange flera av dessa initiativ, exempelvis både Öppna data och Inspire. Initiativet Öppna data är en möjlighet för publicerande organisationer att synliggöra att data är avgiftsfritt och har en licens utan begränsande villkor. Open Knowledge Foundation har tagit fram en definition av Öppna data som sammanfattas enligt: "Data kan kallas öppna data om vem som helst fritt får använda, återanvända och distribuera dessa med som största motprestation att ange källa eller krav på att dela data på samma sätt." Nyckelordet Öppna data bör kompletteras genom att ange en referens (ex till den licens som är gäller för den aktuella resursen exempelvis i fältet Övriga restriktioner 7.2 Kontakter Vid registrering av kontaktinformation kan man göra detta på tre olika sektioner enligt profilen. 1. Metadatakontakt 2. Resurskontakt 3. Distributionskontakt För vart och en av dessa skall kontaktinformation anges på en generell modell där man anger: Organisationsnamn Ansvarsområde som denna organisation har E-post till organisationen Elementet Ansvarsområde skall vara ett värde som tas från en värdelista, ex Producent, Ägare, Vidareförädlare. Det har dock varit svårt att definiera vad respektive ansvarsområde/roll står för. Exempelvis begreppen upphovsman, ägare och förvaltare har olika betydelse beroende på vilken organisation man frågar. Därför är det definierat att man skall ange följande roller: Metadatakontakt Skall ha Ansvarsområdet kontakt Resurskontakt Skall ha en (max 1) kontakt med ansvarsområdet ägare. Utöver det är det tillåtet att registrera flera resurskontakter med andra ansvarsområden. Ansvarsområdet distributör skall dock ej användas för en resurskontakt. Distributionskontakt Skall ha Ansvarsområdet Distributör För resurskontakt gäller följande regler för användning av ansvarsområdet ägare Inom "Infrastrukturen för geodata" gäller följande. Man kan ange flera resurskontakter men man ska ange en ansvarig organisation för respektive

34 PM 34(40) resurs som publiceras i Geodataportalen och detta görs genom att ansvarsområdet "Ägare" reserveras för att registrera ansvarig organisation. Med "Ägare" avses i detta fall att man är avtalspart genom att tecknat samverkansavtal i Geodatasamverkan eller är informationsansvarig enligt lagen och förordningen om geografisk miljöinformation, genom tecknat medverkansavtal eller tecknat avtal om frivilligt medverkan enligt Inspire. Om resursen inte är relaterad till Inspire eller ingår i Geodatasaverkan anges ägare för den organisation som har huvudsakligt ansvar/upphovsmannaskap för resursen. 7.3 Tidsinformation Tid kan registreras enligt flera olika metoder: Referensdatum Temporal utsträckning Metadatadatum De används för att registrera tre olika tidsmässiga egenskaper. Referensdatum (Händelsedatum) Är en tidsangivelse som är relaterat till produktionen av resursen. Det är alltså inte innehållet i data som registreras. Det är olika processer (händelser) i resursens (datasetets eller tjänstens) framtagning som dokumenteras. Produktionsdatum Publiceringsdatum Revideringsdatum Tidsmässig utsträckning (Temporal utsträckning) Utgångspunkten är att en resurs beskriver och omfattar en viss verklighet. Denna verklighet utspelar sig en viss tidsperiod. Den temporala utsträckningen ska ange när verkligheten såg ut så som resursen beskriver. Sådana tidsperioder ligger vanligtvis bakåt i tiden men kan, om det handlar om planering och prognoser, även ligga i framtiden. Enligt den nationella profilen skall alltid referensdatum anges medan Temporal utsträckning är frivillig. Ett exempel: Ett flygfoto togs Det dokumenteras med temporal utsträckning Start: , Slut: Bilden producerades och behandlades till ett ortofoto Det dokumenteras med ett referensdatum med angivelse av händelse=produktion och datum sätts till Bilden publicerades och gjordes tillgänglig för beställning Det dokumenteras med ett referensdatum med angivelse av händelse=publicering ch datum sätts till Det är inte alltid som tidsangivelser är så givna att registrera. Det gäller framförallt kontinuerligt uppdaterade databaser. I dessa fall rekommenderas att de dokumenteras med ett öppet slutdatum. Ett exempel: