@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.
