Community på Sveriges dataportal

@Andreas-Sundberg @Maria-Söderlind Just nu genomför vi en uppdatering av specifikationen, adressen är det som tidigare varit den geografiska aspekten men givetvis ska vi undersöka möjligheten att ha med koordinater även.

@Björn-Hagström Ni behöver använda egenskapen övriga mediatyper https://docs.dataportal.se/dcat/sv/#dcat_Distribution-dcterms_format-3 för GeoJSON då den inte inkluderas i vanliga mediatyper eller geografiska mediatyper.

För övriga mediatyper anger ni värdet för formatet enligt https://www.iana.org/assignments/media-types/media-types.xhtml

@Dennis_Priskorn Tack för feedback! Länkade data aspekten finns alltid med i dom specifikationer vi tar fram och den återfinns i schemat e.g (https://gitlab.com/sarskilt-viktiga-datamangder/point-of-interest/-/blob/main/schema.json)

Framgent kan vi absolut ha med JSON-LD exempel för hur man uttrycker data enligt den strukturen. Vi tar gärna emot din feedback på gitlab under (https://gitlab.com/sarskilt-viktiga-datamangder/point-of-interest/-/issues).

@Johan_Bard du kan titta på dessa CSV scheman gällande datatyper för tid och datum

https://gitlab.com/sarskilt-viktiga-datamangder/point-of-interest/-/blob/main/schema.json?ref_type=heads
https://gitlab.com/sarskilt-viktiga-datamangder/evenemang/-/blob/main/schema.json?ref_type=heads

Gällande "fee_payment_method" satte jag som array där man kan välja upp till tre möjliga alternativ - CASH, CARD, SWISH. Oklart vilka alternativ som bör finnas med, till exempel gör man i många länder skillnad på kontokort och kreditkort - ska det reflekteras häri? Oklart om array existerar som datatype i sammanhanget."

Du kan hitta inspiration i schemat från Points-of-interest, se exempel nedan med schema.org's vokabulär där jag utgått ifrån https://schema.org/PaymentMethod
json

           {
              "name": "payment_method",
              "titles": "Betalning",
              "dc:description": "Betalningstyp.",
              "datatype": {
                "base": "string",
                "format": "Cash|DirectDebit"
              },
              "required": true,
              "valueUrl": "http://purl.org/goodrelations/v1#{type}",
              "propertyUrl": "schema:acceptedPaymentMethod"
            },

@Dennis_Priskorn Gällande vokabulär ser vi ingen anledning att ta fram något nytt då vi återanvänder schema.org's vokabulär rakt igenom. I schema.json ser du mer information kring det. Gällande vandringsleder har vi haft ett pågående arbete nu under våren och vi kommer att ha en mer generell modell för alla typer av leder. Om du vill bidra till den specifikationen kan du göra det på gitlab!

Tack för din feedback återigen.

@jonor representerar inte DIGG. Har erfarenhet av arbete med informationmodeller och dataspecifikationer nationellt. Har tittat lite närmre på detta och det går att göra i en array i schemat som bör fylla syftet vi är ute efter i det här fallet.

Annars är det ingen rikare kardinalitet än obligatorisk och rekommenderat

Det ska alltså finnas både en "specifikation" som beskriver datamodellen, och ett JSON-schema som beskriver ett CSV-format?

Precis, schemat ska agera som validering och även kunna ge mig möjligheten att lägga till kontext på datamängden.

Hur fungerar det i praktiken, är kardinaliteten i en relation maskinläsbar? Tänker om man vill validera att data följer specifikationen? Från JSON-schemat kan man då bara läsa ut om egenskapen är obligatorisk/"required" i tabellformatet, dvs. antingen 0.., eller 1..?

Exakt men ska undersöka om det går att göra en rikare beskrivning i schemat för just kardinaliteten.

*Schemaexemplen verkar i en del avseeenden vara förenklingar som inte täcker in vanliga omständigheter i verkligheten.

Hur är det med fälten "opens" och "closes", är dessa standardegenskaper för öppettider så att det går att härleda ett tidsintervall för olika typer av verksamheter? Det finns väl annars inget i själva schemat som beskriver att de hör ihop som tidpunkter i ett intervall?

Vi har utgått från egenskaper ifrån denna klass https://schema.org/OpeningHoursSpecification
Datatypen "date" med formatet "HH:mm" indikerar att värdena kommer att representera specifika tider på dagen. Att använda "OpeningHoursSpecification" från schema.org ger en bra grund, men du har rätt i att det kanske inte täcker alla variationer i öppettider och prissättning. Att överväga specialiserade egenskaper eller tillägg kan vara ett sätt att hantera dessa variationer.

Det är vanligt att öppettider varierar över olika veckodagar, schemat för POI fångar inte den aspekten på ett strukturerat sätt. Fältet "openinghours" är ett strängvärde med risken att man skriver in varierande öppettider på ett ostrukturerat vis.

Håller med att det är svårt i detta fall och då ligger det till i själva strukturen. Har undersökt möjligheten att använda https://schema.org/specialOpeningHoursSpecification men det är svårt i en platt CSV struktur.

När det gäller fältet "price" är det väl på motsvarande vis vanligt att inträde kan variera för olika åldersgrupper eller andra kategorier. Där skulle också behövas ett sätt att strukturera detta, ett heltalsfält är troligen otillräckligt för att beskriva den prisinformation man ofta ser på informationssidor.*

Håller med att den inte täcker in allt, tanken är att få med baspriset och med url egenskapen kunna se mer information. Här kan man överväga att använda intervall också men det tappar lite kontext.

@Johan_Bard Specifikationen hittar du här - https://www.dataportal.se/en/specifications/badplatser/1.0#ref=?p=1&q=bad&s=2&t=20&f=&rt=spec_standard%24spec_profile&c=false

@ofallheden Inga större förändringar på gång!

@jonor Tack för feedback. Uppdaterar alla specifikationer med denna aspekt i README.md

De modeller som etableras på EU-nivå grundas i huvudsak efter:

https://www.w3.org/TR/prov-o/
https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/eli_xml
https://semiceu.github.io/CPSV-AP/releases/3.2.0/
https://www.dublincore.org/specifications/dublin-core/dcmi-terms/

Nationella anpassningar för liknande processer kring beslut

https://paf.link/#introduction

Det viktigaste att bejaka är formatet som vi även föreslår i modellen som exempel (vilket är Turtle) verkar vara den riktningen som flertalet aktörer och EU i sig självt föreslår när det kommer till den här typen av datamängder.