Datasæt beskrivelse

Før data uploades til EnergyDataDK, skal dataejere angive specifikke oplysninger om deres data.

Disse oplysninger er afgørende for at sikre en gnidningsfri brug af data for både brugere og dataejere.
De fleste af oplysningerne er – medmindre andet er angivet – synlige for alle brugere.

Denne vejledning består af to dele:

  1. Oprettelse af et datasæt
  2. Oprettelse af en datastrøm

Opsætning af et datasæt

Et datasæt er i bund og grund en samling af indbyrdes forbundne datastrømme. Derfor er der ikke behov for mange oplysninger for at oprette et. Datasættet skal naturligvis have et navn, så det kan identificeres, et MQTT-emnepræfiks, for at identificere datasættet for en databroker, en beskrivelse, for at specificere detaljer om de data, der er indeholdt i datasættet, og endelig kan et billede tilføjes for at gøre datasættet visuelt lettere at identificere i datasætoversigten.

TL;DR

Datasæt skal have et unikt navn og et præfiks til MQTT-emnet (MQTT topic prefix). Sidstnævnte udgør i bund og grund det første niveau i et hierarki. I dette eksempel på et MQTT-emne denmark/hovedstaden/lyngby, ville præfikset være: denmark. Præfikset må udelukkende bestå af bindestreger, understregninger og alfanumeriske tegn.

Datasæt skal desuden have en fyldestgørende beskrivelse, der oplyser om kilde, tidsperiode, uregelmæssigheder, anvendelse og en kontaktperson.

Der er mulighed for at uploade et billede, der visuelt repræsenterer datasættet.

Dataset navn

Navnet på datasættet vil være den primære måde, hvorpå EnergyDataDK-brugere kan identificere, hvilke data datasættet indeholder. Navnet bør være intuitivt for dataejeren samt for interne og eksterne brugere. Vi foreslår at inkludere navnet på et projekt, en virksomhed eller et laboratorium samt oplysningstypen. Her er nogle eksempler:

  • Project name/Wind data
  • Master thesis/X data;
  • Company name/Project name

MQTT topic præfiks

MQTT-emner er en fundamental del af, hvordan MQTT-protokollen sender beskeder mellem udgivere og abonnenter. De fungerer som “adresser”, der definerer, hvor hver besked skal leveres. MQTT-emner er hierarkiske og har niveauer adskilt med skråstreger (/). Så du kan betragte præfikset som det første niveau i hierarkiet.
For eksempel, hvis dette ville være vores MQTT-emne: usa/california/san-francisco/silicon-valley, så ville usa være vores MQTT topic præfiks.

Et topic præfiks er en enkelt streng af alfanumeriske tegn, understregninger og bindestreger. Da MQTT topics desuden skelner mellem store og små bogstaver, anbefales det kun at bruge små bogstaver. Topic præfikset er kun synligt for datasætsejere. Du kan læse mere om dets brug i API-beskrivelsen.

Kun alfanumeriske tegn, bindestreger, understregninger og skråstreger er tilladt; mellemrum kan ikke bruges til at adskille ord.

Beskrivelse

Det er meget vigtigt at datasæt-beskrivelsen indeholder alle oplysninger en bruger har behov for, for at afgøre om dataene i datasættet er brugbart for dem. For at sikre det skal datasættet indeholde følgende oplysninger:
  • En general beskrivelse af data
    • Hvilken type data datasættet indeholder
    • Datakilde
    • Frekvens
    • Datastrøm navngivning logik
  • Tidsperiode (tidligste og seneste målinger)
  • Kendte uregelmæssigheder
  • Adgangsbegrænsninger (hvem kan tilgå dataene og under hvilke vilkår)
  • Ejer (hvem man kan stille spørgsmål til, eller bede om adgang)
Selvom datasæt-beskrivelsen kan blive rettet efter oprettelsen, anbefaler vi at du tidligst muligt laver en ordentlig beskrivelse og holder den opdateret.

Eksempel på en beskrivelse af et datasæt

Eksempel af en datasæt-beskrivelse

Dette datasæt indeholder aggregerede data om fjernvarmeforbrug, leveret af energileverandør X.
Dataene omfatter målinger per time fra adskillige varmemålere på transmissionsledninger.
Kontekstuel information om området og måletypen fremgår af datastrømmens navn.

Navngivningsformatet for datastrømme: <net_id>-<postnummer>-<by_navn>-<maaling>
For eksempel: KOP-2400-KoebenhavnNV-sum_varme_pr_time

Dataene dækker perioden fra 1. april 2023 til i dag og suppleres løbende hver time.

Der mangler værdier i tidsrummet mellem kl. 14.00 og 18.00 den 4. juli 2024 som følge af servervedligeholdelse, der blev udført på det tidspunkt.

For at kunne bruge datasættet skal brugeren underskrive en fortrolighedsaftale.

For yderligere oplysninger om datasættet og fortrolighedsaftalen (NDA), bedes du kontakte: kontakt@fiktiv.person

Billede

Det er valgfrit at tilføje et billede, men det gør det lettere at identificere datasæt.
Hvis du har mange datasæt, bør du undgå at bruge det samme billede til dem alle, da det ville modvirke formålet.

Billedet bør være intuitivt, både for dataejeren og for brugere med adgang til dataene.

Opsætning af datastrømme

En datastrøm er i bund og grund en kanal, hvor der modtages data fra en sensor, en måleenhed eller lignende.
Alle observationer i kanalen består af et sæt (en tupel) med et tidsstempel, der angiver tidspunktet for observationen, samt den målte værdi.
Alle tidsstempler i EnergyDataDK er angivet i UTC-tid.

Hver datastrøm tildeles et navn, et MQTT-emnesuffiks og en datatype, og den beskrives af en række obligatoriske tags (metadata), der kvalificerer dataene.

TL;DR

Datastreams skal have et unikt navn og et MQTT-emnesuffiks. Sidstnævnte er i bund og grund den del af MQTT-emnet, der ligger efter præfikset (første niveau) i den hierarkiske struktur. I dette eksempel: denmark/hovedstaden/lyngby, vil suffikset være hovedstaden/lyngby.

Suffikset må kun bestå af bindestreger, understregninger, skråstreger og alfanumeriske tegn.

Datatypen (heltal, double eller streng) i datastrømmen skal deklareres.

Der er et fast antal obligatoriske felter, der skal udfyldes, og du kan tilføje yderligere brugerdefinerede egenskaber, så der i alt er op til 100 metadatafelter.

Datastrøm navn

Ligesom med datasættet er det vigtigt at vælge et navn omhyggeligt, der gør det nemt for enhver bruger at forstå, hvilke data der registreres i strømmen.

MQTT topic suffix

Som beskrevet ovenfor er MQTT-emnet (topic) en grundlæggende del af, hvordan meddelelser dirigeres. Kombinationen af ​​præfikset og suffikset i MQTT-emnet bruges til at identificere en datastrøm; derfor skal suffikset være unikt! MQTT-emnets suffiks er udelukkende synligt for ejeren eller ejerne af datasættet samt for brugere med læseadgang til datasættet. Et MQTT-emnesuffiks må udelukkende bestå af alfanumeriske strenge adskilt af tegnet “/”, der angiver niveauerne i emnehierarkiet.
Hvis dette for eksempel skulle være vores MQTT-emne: usa/california/san-francisco/silicon-valley, så vil california/san-francisco/silicon-valley være vores MQTT-emne suffiks.

Kun alfanumeriske tegn, bindestreger, understregninger og skråstreger er tilladt; mellemrum kan ikke bruges til at adskille ord.

Datatype

You must specify the datatype of the datastream. This can be one of the following:
  • Integer heltal uden decimaler.
  • Double Tal med decimaler. Vær opmærksom på at du skal bruge punktum, ikke kommaer!
  • String Ord eller hele sætninger, dette kan inkludere tal og speciale karaterer.

Egenskaber

Hver datastrøm har et antal obligatoriske felter, der kvalificerer de indeholdte data.
Du kan også tilføje et stort set ubegrænset antal brugerdefinerede felter.

Comment

Her skal du indtaste mere detaljerede oplysninger om datastrømmen, som ikke allerede fremgår af dens navn.

Data license

Her er nogle CC-licenser, som beskriver brugsbetingelserne, og de er anført fra mest til mindst tilladt nedenfor.

Hvis du er usikker hvilken licens er passende kan du bruge dette flowdiagram:

Commercial use Kommerciel anvendelse Do you allow modifications or adaptations? Tillader du ændringer eller bearbejdninger? CC BY-ND Must modified versions use the same license? Skal ændrede versioner anvende samme licens? CC BY-SA CC BY Do you allow modifications or adaptations? Tillader du ændringer eller bearbejdninger? Must modified versions use the same license? Skal ændrede versioner anvende samme licens? CC BY-NC-ND CC BY-NC-SA CC BY-NC

Hvis du stadig ikke er sikker, og du ikke har noget imod at din data kan tilgås uden restriktioner kan du bruge CC0.

GDPR classification

Selvom GDPR ikke pålægger en specifik klassificeringspolitik, kræver den, at organisationer kategoriserer og beskytter data på passende vis baseret på følsomhed og risiko. Der er flere kategorier af data.

  • Persondata
    Information relateret til en identificeret eller identificerbar individ, for eksempel navne, lokation, telefonnumre, etc.
  • Følsom data
    Information vedrørende race eller etnisk herkomst, politiske holdninger, religion, fagforening, genetisk data, biometrisk data, eller sundhed.
  • Pseudonymiseret data
    Persondata bearbejdet således ar det ikke længere kan henføres til et bestemt individ uden yderligere oplysninger.
  • Anonymiseret Data
    Data behandlet på sådan en måde at dataemnet ikke kan identificeres.
  • Non-personal data
    Any information that can’t be used to identify a person.

Geo tag

De geografiske koordinater for det sted, hvor dataene er indsamlet. Du kan blot indtaste en region eller adresse i tekstfeltet, så vil systemet tilbyde matchende resultater til din forespørgsel med deres tilsvarende geolokationskoordinater.

Lokation

Navnet på den installation, hvor dataindsamlingen finder sted.

Organization

Navnet på den organisation, der er ansvarlig for dataindsamlingen.

Project tag

Navnet på det projekt, som dataene indsamles til.

Theme tag

Dette kategoriserer datastrømmen ved dets emne. Da dette sandsynligvis vil primært blive brugt som søgeord burde det være en term man sandsynligvis ville bruge for at finde datastrømmen.

Her er nogle eksempler: “Sol energi”, “CO2 udstød”, “byvarme”, osv.

Enhed

Måleenheden for dataene i datastrømmen. Systemet vil foreslå en mulighed baseret på dit input.

Brugerdefinerede egenskaber

Du kan til føje yderlige brugerdefinerede egenskaber til din datastrøm, ud over de obligatoriske You have the option of adding additional custom properties to your datastream, besides the mandatory ones. This could be anything you or other users may find relevant.
A datastream can have up to 100 total properties.

Keep in mind that the naming must be very clear and intuitive, since these will be nonstandard fields. You may also want to consider adding some documentation about these metadata fields in the description of the dataset.