Property für eine Berechnungsregel in der DS odta:Offer Property schema:priceSpecification

[dklinge]

Bei der Abbildung von Preise in Rahmen einer Preisspezifikation macht es sich fast immer erforderlich eine Berechnungsregel für den angegebenen Preis mitzugeben. Die einzelnen Preise unterscheiden sich oft genau in diesem Punkt. Ein Preis kann pro Person, Gruppe, Familie, Leistung u.v.a.m. gültig sein. Hinzu kommen Nuancen wir Alter von Personen, Status wie Schüler oder Student, Begleitpersonen von Behinderten usw.
Nur mit einer entsprechenden Ergänzung der Klasse schema:PriceSpecification lassen sich die mitunter sehr vielschichtigen Preismodelle vieler POI abbilden und für den Gast Transparent darstellen.

[sumutcan]

is ein Unterklasse von schema:PriceSpecification und erfüllt genauso diesen Zweck. Für die Nuancen wie Alter oder Studium kann man schema:eligibleCustomerType von schema:Offer verwenden.

[dklinge]

Können wir im odta-Vokabular schema:eligibleCustomerType als Property auch der Klasse schema:PriceSpecification zuordnen? In der Praxis ist es meist so, dass sich die Angebote. z.B. der Eintritt in ein Museum für die einzelnen schema:eligibleCustomerType nicht unterscheiden. Name, Beschreibung, Verfügbarkeiten, URL usw. sind da immer gleich. Nur die Preise unterscheiden sich eben.
Wenn wir schema:eligibleCustomerType bei der Klasse schema:Offer nutzen würden, müssten wir, wenn ich es richtig verstehe, für jeden Preis der abhängig von der Art der Person ist, ein separates Angebot anlegen. Dies ist z.B. bei den sehr vielfältig strukturierten Preistabellen z.B. bei den Museen, Bäder oder Freizeiteinrichtungen nicht praktikabel.

[sumutcan]

Ich finde derzeitiges Model von schema.org flexibler, weil es auch sein kann, dass Offer-Beschreibungen sich auch zwischen unterschiedlichen Preiskategorien leicht ändern. Trotzdem bin ich nicht gegen @dklinge's Vorschlag, wenn mehrere ODTA-Mitglieder zustimmen, können wir PriceSpecification mit eligibleCustomerType erweitern.

[FabianBerner1]

Ich stimme @sumutcan zu, finde jedoch, dass die resultierende Flexibilität durch Hinzufügen von eligibleCustomerType zu PriceSpecification sehr lohnenswert ist. (Bsp. Preis für Familien, mit eligibleCustomerType=Famlie im Offer und zwei PriceSpecifications, mit eligibleCustomerType= Erwachsener und eligibleCustomerType= Kind)

Jedoch sehe ich ein Problem mit dem expected Value, welcher sich aus GoodRelations ableitet, da dort z.B. Kinder, Studenten und Gruppen nicht abgedeckt werden.
Dementsprechend müsste diese Enumeration mit unseren spezifischen Anforderungen erweitert werden.

Enumeration Member, die ich vorschlage, sind:
Erwachsener, Kind, Familie, Gruppe, Ermäßigt, Senioren

[dklinge]

Unsere Intention ist eine Regel die den Eintrittspreis in Abhängigkeit vom Gast und seinem Auftreten oder anderen Faktoren bestimmt. Der Preis soll für den Gast transparent und die Preisbildung nachvollziehbar sein. So müssten die von @FabianBerner1 vorschlagenden Enumeration Member in
pro Erwachsener
pro Kind
pro Familie
pro Gruppe
pro Senior
ermäßigt
umbenannt werden.

Daraus ergeben sich aber viel Unschärfen. Ab wieviel Personen ist es eine Gruppe. Was ist eine Familie? (Eltern und Kinder oder auch Großeltern und Enkel) Ab welchem Alter zählt eine Person als Erwachsener? Wann besteht der Anspruch auf einen ermäßigten Preis? usw.
In Projekt ThüCAT findet man diese Spezifikationen Property schema:description der schema:PriceSpecification
Um die Preisbildung möglichst transparent und nachvollziehbar zu gestalten müssten Enumeration Member folgender Art für das Property https://schema.org/eligibleCustomerType vorgesehen werden:
pro Gruppe
pro Person
so weit so gut. Wie sieht es aber mit folgenden Anwendungserfordernissen aus:
pro Einheit
pro Stunde (z.B. Mietgebühr)
pro Tag (z.B. Mietgebühr)
pro Minute (z.B. Mietgebühr)
pro Nacht und Einheit (Unterkunft)
pro Person und Nach (Unterkunft)
pro Fahrtzeug und Stunde (Parkgebühr)
pro Fahrrad (z.B. Tarif in Verkehrsmitteln)
All das Letztgenannte ist nicht von der Person abhängig. Ist dafür das Property https://schema.org/eligibleCustomerType wirklich gut geeignet?

[sumutcan]

Für unterschiedliche Einheiten können die Preise mit schema:UnitPriceSpecification beschrieben werden. https://schema.org/UnitPriceSpecification

Da haben wir unitCode bzw. unitText Eigenschaften. Also grundsätzlich Einheiten und eligibleCustomerType können zusammen verwendet werden. (entweder durch Offer und UnitPriceSpecification, oder direkt mit UnitPriceSpecification, falls wir eligibleCustomerType auch auf PriceSpecification definieren ).

Die Bedingungen für einen bestimmten Kundentyp erst in der Beschreibung von EnumerationMember angegeben werden.