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.

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

Beskrivelse

For at sikre en gnidningsløs anvendelse af data for både brugere og dataejere er det afgørende at give fyldestgørende oplysninger om datasættet. Dette bør omfatte følgende:
  • Generel beskrivelse af dataene (type, kilde osv.)
  • Datasættets granularitet
  • Den periode, datasættet dækker
  • Kendte uregelmæssigheder
  • Anvendelsesbegrænsninger
  • Kontaktperson

 

Beskrivelsen af ​​datasættet kan redigeres af dataejere, efter at datasættet er oprettet, og bør opdateres hurtigst muligt, når ovennævnte oplysninger foreligger, eller hvis der sker ændringer.

Eksempel på en beskrivelse af et datasæt

Datasættet består af syntetiske data genereret til demonstrationsformål. Det indeholder tilfældigt genererede poster, der repræsenterer forskellige datatyper, der almindeligvis anvendes i strukturerede datasæt. Datasæt struktur:
  • Alphanumeric Data: 2 independent datastreams containing randomly generated text strings.
  • Heltalsdata: 3 uafhængige datastrømme med tilfældigt genererede tal.
  • Booleske værdier: 1 datastrøm, der repræsenterer sand/falsk-værdier.
Datasættet indeholder 100 registreringer, der dækker perioden fra den 1. april 2023 til den 5. april 2023. Der mangler værdier i tidsrummet mellem kl. 14.00 og 18.00 den 4. april som følge af servervedligeholdelse, der blev udført på det tidspunkt. Data registreres med timers mellemrum. For at bruge datasættet skal brugeren underskrive en fortrolighedsaftale. For yderligere oplysninger vedrørende datasættet og fortrolighedsaftalen, kontakt venligst: example@email.com

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 ud over præfikset (første niveau) i den hierarkiske struktur. Så i dette eksempel: denmark/hovedstaden/lyngby, ville suffiksen være hovedstaden/lyngby.

The suffix must only consist of hyphens, underscores, slashes and alphanumeric characters.

The type of data (integer, double, or string) in the datastream must be declared.

There are a fixed number of mandatory fields which must be filled out, and you can add additional custom properties up to a total of 100 metadata fields.

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.
Vigtigt: 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
Commercial use
Do you allow modifications or adaptations?
Do you allow modific...
CC BY-ND
CC BY-ND
Must modified versions use the same license?
Must modified versio...
CC BY-SA
CC BY-SA
CC BY
CC BY
Do you allow modifications or adaptations?
Do you allow modific...
Must modified versions use the same license?
Must modified versio...
CC BY‑NC‑ND
CC BY‑NC‑ND
CC BY‑NC‑SA
CC BY‑NC‑SA
CC BY‑NC
CC BY‑NC
Text is not SVG - cannot display

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.

Location

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.