schema:Event Interpretation von Terminen

[dklinge]

Offenbar gibt es in den unterschiedlichen touristischen Datenbanksystemen unterschiedliche Interpretationen zur Nutzung von schema:startDate, schema:endDate, schema:startTime und schema:endTime bei schema:Event und schema:Schedule. Daher die Frage an dieser Stelle ob folgende Aussagen korrekt sind:

1. schema:startDate beschreibt den Beginn einer einzelnen Veranstaltung als schema:Date oder schema:DateTime im Format ISO 8610 und einer Kardinalität von 1
2. schema:endDate beschreibt das Ende einer einzelnen Veranstaltung als schema:Date oder schema:DateTime im Format ISO 8610 und einer Kardinalität von 1
3. schema:eventSchedule/schema:startDate beschreibt den Beginn einer Veranstaltungsserie als schema:Date oder schema:DateTime im Format ISO 8610 und einer Kardinalität von 1 und damit nicht den Beginn einer einzelnen Veranstaltung.
4. schema:eventSchedule/schema:endDate beschreibt das Ende einer Veranstaltungsserie als schema:Date oder schema:DateTime um Format ISO 8610 und einer Kardinalität von 1 und damit nicht das Ende einer einzelnen Veranstaltung.
5. schema:eventSchedule/schema:startTime beschreibt den Beginn einer Veranstaltung in einer Terminserie sich wiederholender gleicher Veranstaltungen als schema:DateTime oder schema:Time im Format ISO 8610 und einer Kardinalität von 1+n.
6. schema:eventSchedule/schema:endTime beschreibt das Ende einer Veranstaltung in einer Terminserie sich wiederholender gleicher Veranstaltungen als schema:DateTime oder schema:Time im Format ISO 8610 und einer Kardinalität von 1+n.
7. Wird bei schema:eventSchedule/schema:startTime und schema:eventSchedule/schema:endTime die Range schema:Time genutzt, ergibt sich der Tag der Veranstaltung aus den Werten die in den Propertys schema:byDay, schema:byMonth, schema:byMonthDay und schema:byMonthWeek hinterlegt sind.
8. Wird bei schema:eventSchedule/schema:startTime und schema:eventSchedule/schema:endTime die Range schema:DateTime genutzt werden darf die Kardinalität bei der Propertys nur 1 betragen. Im anderen Fall wäre nicht klar welches schema:startTime welchem schema:endTime zuordnen wäre.

Zu vereinfachen Abbildung von Veranstaltungen folgender Gedanke:
Nicht immer finden sich wiederholende gleiche Veranstaltungen in Turnussen statt, die man mit den Regeln aus der Propertys schema:byDay, schema:byMonth, schema:byMonthDay oder schema:byMonthWeek einer schema:Schedule abbilden lassen.
In diesem Fall wäre es von Vorteil, bei schema:startDate, schema:endDate sowie bei schema:eventSchedule/schema:startTime und schema:eventSchedule/schema:endTime mehrere Werte angeben zu können. Dabei müssten die Propertys in 2 schema:IltemLists eingeordnet werden. Ein ItemList für der Beginn der Veranstaltung und ein ItemList für ihr Ende. Welche Werte für Beginn und Ende zueinander gehören könnten man dann am schema:position des Items festmachen. Wie müsste eine solches Schema konkret aussehen?

[FabianBerner1]

Zu 1,2: Ja, das verstehe ich auch so

Zu 3,4: Es können auch mehrere einzelne Schedules mit einzelnen Terminreihen, oder sogar Einzelterminen dort hinterlegt werden. Dementsprechend sind diese Felder nicht generalisierbar auf eine komplette Veranstaltung (mit n Terminen) oder Einzelveranstaltung bezogen, sondern nur auf das dementsprechende Schedule Element.

Zu 5,6: die Kardinalität ist dort meines Verständnisses nach nur 1, weil jedes Schedule Element nur eine Startzeit und Endzeit hat. Wenn ein Event mit mehreren Terminen pro Tag angelegt werden soll, würden zum Event mehrere Schedules mit den jeweiligen Zeiten/Terminen angelegt werden. Diese Logik lässt sich auch anhand von Beispiel 4 bei schema.org erkennen: https://schema.org/eventSchedule

Zu 7: ja der Tag ergibt sich dann aus dem Regelwerk (byDay, ..., startDate, endDate)

Zu 8: ich würde sagen, dass dort generell die Kardinalität 1 ist, siehe Erläuterung zu 5,6.

Ich würde vorschlagen, um Verwirrungen zu vermeiden, festzulegen, dass bei startDate und endDate nur Date als Datentyp als zulässig anerkannt wird und bei startTime und endTime dementsprechend nur Time. So wäre es einfacher, damit in den Zielsystemen umzugehen.

Weiterhin schlage ich vor festzulegen, dass nur entweder startDate/endDate ODER eventSchedule Elemente verwendet werden. Sonst könnten die dortigen Werte widersprüchlich verstanden werden, wenn beide Ansätze verwendet werden.

[sumutcan]

Mehrere startDate / endDate-Angaben wären problematisch, da wir nicht wissen können welche startDate gehört zum welchen endDate. @FabianBerner1 hat die Schedule-Logik gut erklärt. Es wäre tatsächlich sinnvoll einen Regel zu erstellen, dass startDate und endDate von Event nicht mit startDate endDate-Angaben für Schedule wiederprechen sollen. Dafür braucht man aber wahrscheinlich Änderungen bei den Datenverifikations-Tools für DS.