Offer Modelling

[saumier]

Offer

In an Offer (Offer class) there are several properties, such as availablity, which are optional and are often not available from the source website. There is also no standard for indicating that an event requires registration, meaning that the person must register for a free event. An event requiring registration is usually free but can also be paid such as the workshops offered on the Culture Outaouais calendar which first require registration and are paid only after the workshop is confirmed to have enough participants.

Also see culturecreates/artsdata-data-model#80

Questions

1. Can availability, priceCurrency and validFrom be optional?
2. What should be done when there is no Offer url?
3. How are free events marked?
4. How are events marked when they require registration?

• offers

  {
    "type": "Offer",
    "availability": "InStock",
    "price": "69.00",
    "priceCurrency": "CAD",
    "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/TDEyMzE0MDI%3D",
    "validFrom": {
      "type": "xsd:dateTime",
      "@value": "2022-12-09T14:50:00+00:00"
    }
  }
  

[christianroy]

Q1: yes they can be optional.

As a side question, the current La Vitrine database has a field for availabilityStarts but not validFrom. However, we are not sure on what the difference is for those properties in Schema. The current Artsdata doc says that validFrom is "The date when the item becomes valid.". Geneviève has an old printed version of the documentation (dated March 1st, 2021 and version 0.2) which says "The date when tickets go on sale".

[saumier]

Artsdata uses 'validFrom' as it is used in schema.org examples of Offer (see B.B.King along with 'validThrough'), and documented on the Google Event structured data. We didn't write the documentation ;-) but copied it from schema.org and Google, where both versions of the text your found describe 'validFrom'. My feeling is that 'availabilityStarts' is more for things like a limited time podcasts. AvailabilityStarts has a Github issue that may shed some light schemaorg/schemaorg#1741

Looking at the data of all the thousands of webpages we have crawled, most use 'validFrom'. The only websites using 'availabilityStarts' where eventbrite.com and ladansesurlesroutes.com.

validFrom

https://schema.org/validFrom
Schema.org description: The date when the item becomes valid.
Google description: The date and time when tickets go on sale (only required on date-restricted offers)

availabilityStarts

https://schema.org/availabilityStarts
Schema.org description: The beginning of the availability of the product or service included in the offer.
Google: not documented in their event structured data.

[christianroy]

ah! Ce sera validFrom alors! On avait mal compris la nuance, mais ça devient clair! On en parlait avec @GenFab28 ce matin et elle voudra probablement aussi ajuster son vocabulaire interne, ce ne sera juste pas possible immédiatement. Mais pour le flux dont il est question ici, on y va avec validFrom.

[fjjulien]

@christianroy Je crois que la confusion entre availabilityStarts et validFrom vient de deux causes :

1. Le libellé de availabilityStarts est plus « signifiant » (meaningful) que validFrom du point de vue du secteur du spectacle. En effet, dans le jargon du secteur, quand on dit que des billets sont « disponibles », ça veut dire que la vente a commencé et qu'il reste encore des billets à vendre.
2. availabilityStarts a un libellé ressemblant à availability et on pourrait aisément croire qu'ils communiquent le même genre d'informations, puisque la liste des valeurs pour la cible de availability semble concorder avec des valeurs qu'on associerait, dans le jargon du secteur, à des billets de spectacle. Mais elles ont un domaine différent. "available" s'applique tant à des offres qu'à des demandes. Surtout, leur définition diffère :
   "available" refers to the availability of the subject item, that is, in the context of a performing arts event, the Offer (for example, a single ticket or a festival pass).
   "availablilityStarts", as Gregory pointed out, refers to the "beginning of the availability of the product or service included in the offer", that is, in the context of a performing arts event, the Event itself.

"validFrom" is quite similar to "available": it has a broad domain and the definition refers to the item, that is the Offer. The label may not sound intuitive to a performing arts brain, but the definition leaves no doubt: "validFrom" is to be used to designate the date when tickets go on sale.

"availabilityStarts" is unlikely to serve much purpose in the performing arts setting. Since the service is the event itself, the value of "availabilityStarts" should always be the same as the event start time (or door time), which is already documented with the "startDate" property (or "doorTime"). There are a few uncommon scenarios, where "availabilityStarts" could serve a need in the performing arts setting:

• if an additional service (for example, access to exclusive content online) is bundled with the ticket offer and described as an addOn.
• if a festival pass is in the form of an electronic bracelet and this bracelet can be picked up before the festival's actual start time.

Besides these few odd cases, I don't see "availabilityStarts" being used very often in the performing arts.

"validFrom", on the other hand, may become a necessity for an increasingly frequent Artsdata use case: a third-party data provider seeking to mint an Artsdata ID before the tickets go on sale. In this scenario, the platform would want to ensure that the event information isn't consumed by search engines via Artsdata until the tickets actually go on sale. They might therefore want to submit their event information along with a "validFrom" date. This use case may not even exist yet, but it is bound to become more frequent as Artsdata partners become aware of the availability (and the value) of Artsdata IDs for events.

[christianroy]

Merci pour les détails, très éclairant! Et ce sera donc validFrom, comme mentionné plus haut

[saumier]

Q2: What should be done when there is no Offer url?

Footlight CMS has an approach to handle this by adding a url to a type AggregateOffer.

For example, when a buy button url is needed for the UI of an application, and there is no url in an individual schema:Offer, Footlight CMS creates a type of Offer called "Aggregate Offer" (class schema:AggregateOffer) which contains a url that represents a general url to buy any of the offers.

[christianroy]

Est-ce qu'on pourrait simplement répéter le URL que vous mettez dans le AggregateOffer pour chaque Offer?

[saumier]

Yes. I can easily add a url to the Offers if there is none.

Do the following cases work from your point of view?

Case 1: repeated ur in each schema:Offer.

{
  "type": "AggregateOffer",
  "additionalType": "Paid",
  "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/TDEyMzE0MDI%3D"
  },
 {
  "type": "Offer",
  "price": "69.00",
  "name": "Adults",
  "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/TDEyMzE0MDI%3D"
},
 {
  "type": "Offer",
  "price": "0",
  "name": "Children under 12",
  "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/TDEyMzE0MDI%3D"
}

Case 2: No individual Offer, only an AggregateOffer.

{
  "type": "AggregateOffer",
  "additionalType": "Paid",
  "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/TDEyMzE0MDI%3D"
  }

Or do you think in Case 2 that the AggregateOffer should be replaced with an Offer?

[christianroy]

Case 1 : parfait.
Case 2 : oui, un Offer.

[saumier]

Q3: How are free events marked?

Footlight CMS has an approach to handle this by adding an schema:additionalType to AggregateOffer.

The types are: Free, Paid, Registration.

[saumier]

Check out the discussion here and Fred's latest idea. culturecreates/artsdata-data-model#80 (comment)

[fjjulien]

I'm hesitant about the "free" and "paid" types.

"free" and "paid" is information that can be inferred from the price property. "free" might be useful if there is no price property in the source data (in which case, we could programmatically insert the missing attribute value-pair). But "paid" is not really not a meaningful term.

Besides, there can be many flavours of "paid" offers: subscriber-only, discount price for age < 25, dynamic pricing, etc.

[saumier]

@fjjulien I agree. I have attempted a new Artsdata Offer model here based on the discussions... I can update the LaVitrine export after we have come to a conclusion on an Artsdata approach.

[christianroy]

La réflexion du côté de la Vitrine (pour ses cas d'utilisation spécifiques) était la suivante:

1. S'il y a un ou des prix, on sait que l'événement est payant, et donc on s'attend à avoir une URL pour l'acquisition.
2. Si le prix est absent, il y a plusieurs scénarios:

a) l'événement est gratuit (mais pourrait être en accès libre, ou être gratuit sous réserve de s'inscrire)
b) l'événement est payant mais le paiement est dans le cadre d'une autre offre (ex: c'est une représentation accessible aux détenteurs de laisser-passer pour un festival)
c) l'information est simplement manquante

Pour régler ces ambiguïtés, on a introduit deux propriétés:

• gratuit, booléen. Vrai pour confirmer la gratuité, et inféré comme étant faux dès qu'un prix est documenté.
• demande une inscription, booléen. Vrai pour dire qu'il faut s'inscrire, et inféré comme étant vrai dès qu'un prix est documenté.

Si je comprends bien la proposition initiale du schema:additionalType, les correspondances seraient:

• free = gratuit, sans inscription
• registration = gratuit, avec inscription
• paid = payant, avec inscription
• (sous entendu que la combinaison payant, sans inscription n'existe pas)

Du point de vue de la Vitrine, ces informations sont suffisantes, elle nous souhaite pas afficher plus de détails sur les modalités.

cc. @GenFab28 qui pourra commenter si j'ai oublié une préoccupation!

[christianroy]

Pour donner suite à la discussion... Pour l'instant, on s'attendra au schema:additionalType avec les valeurs indiquées, et on s'adaptera si une autre approche est utilisée, tant qu'elle permet de distinguer les cas mentionnés dans l'échange.

[saumier]

Here is a consolidation of the thread thus far.

Mandatory properties

• additionalType

Optional properties

• availability
• url
• validFrom
• validThrough
• price
• priceCurrency
• name (mandatory en:, fr:, @none)

Rules:

1. Each Offer MUST have schema:additionalType but no other property is required
2. schema:additionalType can be Free, Paid, or Registration
3. When there is only a single buy url for all offers, the buy URL is repeated in each Offer
4. schema:AggregateOffer is optional and MAY be used for a name or url that applies to all Offers.

Case 1: l'événement est payant avec plusieurs prix

Event is Paid even though one of the Offers has a price of 0 for kids, so each Offer has an additionalType of Paid.

 {
  "type": "Offer",
  "additionalType": "Paid",
  "price": "69.00",
  "name": {"en": "Adults"},
  "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/TDEyMzE0MDI%3D"
},
 {
  "type": "Offer",
  "additionalType": "Paid",
  "price": "0",
  "name": {"en": "Children under 12"},
  "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/TDEyMzE0MDI%3D"
}

Case 2: l'événement est payant mais le prix est manquante (pay at the door)

{
  "type": "Offer",
  "additionalType": "Paid",
  "name": {"en": "Pay at the door"}
  }

Case 3: l'événement est gratuit (accès libre)

{
  "type": "Offer",
  "additionalType": "Free"
  }

Case 4: l'événement est gratuit (sous réserve de s'inscrire)

{
  "type": "Offer",
  "additionalType": "Registration",
  "url": "https://register.com/link"
  }

Case 5: l'événement est payant avec de l'info general sur le billetterie

 {
  "type": "Offer",
  "additionalType": "Paid",
  "price": "46",
  "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V"
},
 {
  "type": "Offer",
  "additionalType": "Paid",
  "price": "42",
  "name": {"fr": "carte Odyssée"},
  "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V"
},
 {
  "type": "AggregateOffer",
  "additionalType": "Paid",
  "name":  {"fr": "Des frais supplémentaires s’appliquent sur les achats en ligne et par téléphone"},
  "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V"
}

[saumier]

@christianroy Let me know if you agree with this answer. I think the additionalType should be mandatory so developers can always have a consistent way to check how the offers relate to the event event if info is missing such as price or buy url.

[christianroy]

LGTM! Ça me convient.

@GenFab28 j'attire ton attention sur le cas 2. Je ne sais pas si tu avais anticipé que cette situation peut exister (je pense que ça se peut!) pour l'affichage aux visiteurs du site. C'est vraiment un détail de présentation, il faut juste que le UI prévoit une façon élégante de dire que c'est payant sans qu'on sache le prix.

[GenFab28]

@christianroy @saumier : Nous n'avons pas d'enjeu de ce côté en UI puisque le prix est une information secondaire. Ce qui nous importe, c'est d'avoir une façon de déterminer (boolean) si oui ou non l'offre est gratuite. Ce n'est pas la propriété Price dans notre modèle qui le détermine.

On regardera Christian, mais pour moi aussi c'est LGTM!

[saumier]

An event has offers modelled using schema:Offer and schema:AggregateOffer. When an event has a single Offer then schema:Offer MAY be used. If there are several offers, then schema:AggregateOffer MUST be used with an array of Offer or AggregateOffer nested inside.

How are free events marked?

Free events MUST have a price: 0 in the Offer or AggregateOffer directly linked to the Event.

How are events marked when they require registration?

A controlled vocabulary is introduced to clarify the type of Offer or AggregateOffer that require registration:

• OfferRequiresRegistration
  Events that require registration MUST has an additionalType: OfferRequiresRegistration in the Offer or AggregateOffer directly linked to the Event.

Properties

ads:AggregateOfferNode
    sh:targetClass schema:AggregateOffer ;
    sh:property ads:additionalTypeProp ,
                ads:offers ,
                ads:lowPriceProp ,
                ads:highPriceProp ,
                ads:availabilityProp ,
                ads:priceProp ,
                ads:priceCurrencyProp ,
                ads:urlProp ,
                ads:nameProp ,
                ads:validFromProp ,
                ads:validThroughProp ;
    .

ads:OfferNode
    sh:targetClass schema:Offer ;
    sh:property ads:additionalTypeProp ,
                ads:availabilityProp ,
                ads:priceProp ,
                ads:priceCurrencyProp ,
                ads:urlProp ,
                ads:nameProp ,
                ads:validFromProp ,
                ads:validThroughProp ;
    .

Rules:

1. A free event MUST have the "price" : "0" in the Offer directly connected to the event (not the nested offers).
2. When there are multiple offers with different prices, the AggregateOffer price MUST be null or undefined (but not 0), and instead the lowPrice and highPrice MAY be filled in.
3. An Offer or AggregateOffer MAY have schema:additionalType which MUST be adr:OfferRequiresRegistration
4. When there are multiple offers with different urls, the AggregateOffer url MAY use the event webpage.
5. When an AggregateOffer has price: 0 then the nested Offers MUST NOT have prices > 0.

Case 1: l'événement est payant avec plusieurs prix

Event is Paid even though one of the Offers has a price of 0 for kids. Also, the individual offer urls are different and there is no good aggregate url so the event's webpage url is used instead.

 {
  "type": "AggregateOffer",
  "url": "https://event/webpage.com",
  "lowPrice": 0,
  "highPrice": 69,
  "offers": [{
          "type": "Offer",
          "price": "69.00",
          "name": {"en": "Adults"},
          "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/Adults"
        },
         {
          "type": "Offer",
          "price": "0",
          "name": {"en": "Children under 12"},
          "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/Children"
        }]
}

Case 2: l'événement est payant mais le prix est manquante (pay at the door)

This is assumed to be a paid event because the price is not 0.

{
  "type": "Offer",
  "name": {"en": "Pay at the door"}
   "url": "https://event/webpage.com"
  }

Case 3: l'événement est gratuit (accès libre)

{
  "type": "Offer",
  "price": 0,
   "url": "https://event/webpage.com"
  }

Case 4: l'événement est gratuit (sous réserve de s'inscrire)

{
  "type": "Offer",
  "price": 0,
  "additionalType": "OfferRequiresRegistration",
  "url": "https://register.com/link"
  }

Case 5: l'événement est payant avec de l'info general sur le billetterie

In this case the url is the same for all offers and can be used in the AggregateOffer.

{
  "type": "AggregateOffer",
  "name":  {"fr": "Des frais supplémentaires s’appliquent sur les achats en ligne et par téléphone"},
  "lowPrice": 42,
  "hightPrice": 46,
  "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V",
  "offers": [{
            "type": "Offer",
            "price": "46",
            "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V"
          },
           {
            "type": "Offer",
            "price": "42",
            "name": {"fr": "carte Odyssée"},
            "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V"
          }]
}

[saumier]

@christianroy Let me know if this summarizes our discussion this morning. Thx.

[christianroy]

When an event has a single Offer then schema:Offer can used. If there are several offers, then schema:AggregateOffer is used with offers nested inside.

Est-ce qu'on pourrait dire que systématiquement, on présente un AggregateOffer, même s'il contient une seul Offer nestée? Un peu dans le même esprit du choix de mettre systématiquement un EventSeries avec des représentations même s'il n'y en n'a qu'une.

When there are multiple offers with different prices, the AggregateOffer price MUST be null or undefined (but not 0), and instead the lowPrice and highPrice MAY be filled in.

Est-ce que ce serait compliqué de remplacer le MAY par MUST pour arriver à «the lowPrice and highPrice MUST be filled in»?

When there are multiple offers with different urls, the AggregateOffer url MAY use the event webpage.

Ici aussi, est-ce que ça pourrait être un MUST? De cette façon on s'assure qu'il y a toujours une URL. À moins qu'on ne connaisse pas toujours la page de l'événement?

@GenFab28 que voudrais-tu qu'il arrive si il y a plusieurs liens d'acquisition pour une même représentation, et pas d'URL général sur l'événement? On prend le premier URL du bord? Ou au contraire tu préfères ne rien recevoir et faire en sorte qu'un agent de saisie fasse la recherche?

En complément sur les URL, le cas 5 pourrait mener à une règle supplémentaire:

• When there are multiple offers with the same urls, the AggregateOffer url MUST use that url.

[saumier]

@christianroy See my answers to you in the next comment...

[saumier]

@christianroy

Est-ce qu'on pourrait dire que systématiquement, on présente un AggregateOffer, même s'il contient une seul Offer nestée? Un peu dans le même esprit du choix de mettre systématiquement un EventSeries avec des représentations même s'il n'y en n'a qu'une.

I could make this change for LaVitrine but I am not sure about the semantics and it will introduce another difference from Artsdata which is not great. The properties of Offer and AggregateOffer are almost the same. I hesitate because most of the existing data on websites use just Offer. But I think there is a solution. If the url and price, needed to display on the webpage, can consistently be found by looking at the Offer directly connected to the Event (without going to the nested Offers) then a developer can consistently display price/price range and url using the same "path" and it does not matter if the type is called Offer or AggregateOffer. Since AggregateOffer is a sub-class of Offer, all the Offer properties apply. I think we achieve the consistency for a developer without compromising on the semantics.

Est-ce que ce serait compliqué de remplacer le MAY par MUST pour arriver à «the lowPrice and highPrice MUST be filled in»?

Good idea. I'll make this change and it will help with the consistency for developers, and not break the semantics.

Here is another revision of the rules... including @GenFab28 suggestions and a new rule about aggregated websites for the same Event.

Free Offer Rules:

1. A free event MUST have the "price" : "0" in the Offer directly connected to the event.
2. When an AggregateOffer has "price: 0" then the nested Offers MUST NOT have prices > 0 OR lowPrices > 0 OR highPrices > 0.
3. When there are multiple offers with different prices, the AggregateOffer "lowPrice" and "highPrice" MUST be filled in.

Registration Offer Rules:

1. An Offer or AggregateOffer MAY have schema:additionalType which MUST be "http://kg.artsdata.ca/resource/OfferRequiresRegistration"

Buy URL Rules:

1. When there are multiple nested offers with different urls, the AggregateOffer MUST have a valid "url" and MAY use the event webpage url if there is no general ticketing platform url available.
2. When there are multiple nested offers with the same url, the AggregateOffer MUST use that url.
3. The only case for an Event having more than one Offer or AggregateOffer directly linked to the Event is when Offers are aggregated from different Websites. In this case the subjectOf MAY link to the Website that the offer is from.

[saumier]

I all this makes sense, my next step will be a formal definition in SHACL. Let me know if you spot anything I missed.

[christianroy]

Ok parfait pour les Offer/AggregateOffer.

Les règles aussi me semblent complètes. Go pour le SHACL!

[saumier]

An event (single representation) has offers modelled using schema:Offer and/or schema:AggregateOffer.

When an event has a single offer then schema:Offer MAY be used. If there are several offers for the same event, then a single schema:AggregateOffer MUST be used and include the other offers nested inside the aggregate offer.

Formal model in SHACL

For the formal model please consult this SHACL file.

Properties (informative)

Offers can have the following schema.org properties:

• additionalType
• availability
• price
• priceCurrency
• url
• name
• validFrom
• validThrough

In addition, AggregateOffer (sub-class of Offer) can also include:

• offers - nested offers
• lowPrice
• highPrice

Buy url (informative)

1. There MUST be a url in the Offer or AggregateOffer directly connected to the event.
2. When there are multiple nested offers with different urls, the AggregateOffer MUST have a valid "url" and MAY use the event webpage url if there is no general ticketing platform url available.
3. When there are multiple nested offers with the same url, the AggregateOffer MUST use that url.

How are free events marked? (informative)

1. A free event MUST have the "price" : "0" in the Offer directly connected to the event.
2. When there are multiple nested offers with different prices, the "price" directly connected to the event MUST not be 0.

How are paid events marked? (informative)

1. In the absence of "price" : "0" the event can be considered to be a paid event.
2. If the event has no offers then it should be considered a paid event, and NOT a free event. On some websites, like Place des arts and Co-motion, the event can be announced before the tickets go on sale.
3. When there are multiple offers with different prices, the AggregateOffer "lowPrice" and "highPrice" MUST be filled in, but only when prices are present and when they can be coerced to a datatype 'xsd:decimal'.

How are events marked when they require registration? (informative)

1. An Artsdata controlled vocabulary is introduced to clarify offers that require registration: OfferRequiresRegistration
2. Events that require registration MUST have an "schema:additionalType" : "http://kg.artsdata.ca/resource/OfferRequiresRegistration" in the offer directly linked to the Event.

Examples

Case 1: l'événement est payant avec plusieurs prix

Event is Paid even though one of the Offers has a price of 0 for kids. Also, the individual offer urls are different and there is no good aggregate url so the event's webpage url is used instead.

 {
  "type": "AggregateOffer",
  "url": "https://event/webpage.com",
  "lowPrice": 0,
  "highPrice": 69,
  "offers": [{
          "type": "Offer",
          "price": "69.00",
          "name": {"en": "Adults"},
          "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/Adults"
        },
         {
          "type": "Offer",
          "price": "0",
          "name": {"en": "Children under 12"},
          "url": "https://am.ticketmaster.com/grandtheatre/fr-ca/ism/Children"
        }]
}

Case 2: l'événement est payant mais le prix est manquante (pay at the door)

This is assumed to be a paid event because the price is not 0.

{
  "type": "Offer",
  "name": {"en": "Pay at the door"}
   "url": "https://event/webpage.com"
  }

Case 3: l'événement est gratuit (accès libre)

{
  "type": "Offer",
  "price": 0,
   "url": "https://event/webpage.com"
  }

Case 4: l'événement est gratuit (sous réserve de s'inscrire)

{
  "type": "Offer",
  "price": 0,
  "additionalType": "http://kg.artsdata.ca/resource/OfferRequiresRegistration",
  "url": "https://register.com/link"
  }

Case 5: l'événement est payant avec de l'info general sur le billetterie

In this case the url is the same for all offers and can be used in the AggregateOffer.

{
  "type": "AggregateOffer",
  "name":  {"fr": "Des frais supplémentaires s’appliquent sur les achats en ligne et par téléphone"},
  "lowPrice": 42,
  "hightPrice": 46,
  "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V",
  "offers": [{
            "type": "Offer",
            "price": "46",
            "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V"
          },
           {
            "type": "Offer",
            "price": "42",
            "name": {"fr": "carte Odyssée"},
            "url": "https://reseau.ovation.ca/pesite.asp?CodeRepresentation=0E03ZS&CodeSiteClient=00000V"
          }]
}

Case 6: l'événement est payant avec plusieurs échelles des prix

In this case the nested offers are type AggregateOffer.

{
  "type": "AggregateOffer",
  "lowPrice": 42,
  "hightPrice": 75,
  "url": "https://event/webpage.com",
  "offers": [{
            "type": "AggregateOffer",
            "lowPrice": "42",
            "hightPrice": "75",
            "url": "https://reseau.ovation.ca/pesite.asp?par_terre"
          },
           {
            "type": "AggregateOffer",
            "lowPrice": "42",
            "hightPrice": "45",
            "url": "https://reseau.ovation.ca/pesite.asp?balcon"
          }]
}

[saumier]

@christianroy Let me know if you spot any problems ;-)

[saumier]

@christianroy You can also look at the data dumps. I believe I have implemented all the changes to offers now.

[christianroy]

J'ai lu les notes et ai observé rapidement les dumps du GTQ et de la PDA.

Ça me semble vraiment bien, je pense qu'on y est presque! J'ai bien vu la différence entre les offres des spectacles à plusieurs prix (la plupart des spectacles au GTQ) et ceux à prix unique (certains spectacles jeunesse ou famille).

Je consigne quelques notes et questions supplémentaires ici.

1. Je suis presque certain qu'on a abordé le sujet suivant seulement de vive voix, mais je ne suis plus certain de la conclusion. Je comprends des notes et de ma compréhension limitée que l'offre agrégée peu avoir une propriété availability. Toutefois, je ne suis pas certain de comprendre comment elle sera/serait déterminée. Et dans les faits, dans le dump, je ne vois pas de availability pour l'offre agrégée. Est-ce qu'il faut conclure que c'est au consommateur de la donnée de choisir ce qu'il fait des données?

2. En observant les dumps, j'ai constaté par hasard un problème potentiel dans les descriptions. Comme ce n'est pas lié à la modélisation des offres, j'ai créé une discussion distincte: Mise en page des textes des descriptions #19

3. J'ai aussi vu un cas que je ne suis pas certain de comprendre dans PDA. Pour la représentation dont l'id est http://kg.footlight.io/resource/placedesarts-com_nessuie-jamais-de-larmes-sans-gants#2023-12-13T150000-0500, il y a un AggregateOffer qui liste plusieurs offers (parfait), mais aussi un autre AggregateOffer, comme ceci:

"offers": {
            "@id": "http://kg.footlight.io/resource/placedesarts-com_nessuie-jamais-de-larmes-sans-gants#2023-12-13T150000-0500_WrappedOffer",
            "type": "AggregateOffer",
            "url": "https://placedesarts.com/fr/evenement/nessuie-jamais-de-larmes-sans-gants",
            "lowPrice": {
              "type": "xsd:decimal",
              "@value": "45.00"
            },
            "highPrice": {
              "type": "xsd:decimal",
              "@value": "55.00"
            },
            "offers": [
              {
                "@id": "http://kg.footlight.io/resource/placedesarts-com_nessuie-jamais-de-larmes-sans-gants#Offer_0",
                "type": "Offer",
                "availability": "InStock",
                "price": "45.00",
                "url": "https://am.ticketmaster.com/pda/fr-ca/virtual-venue/RDNEMTIxM1A="
              },
              ...
              {
                "@id": "http://kg.footlight.io/resource/placedesarts-com_nessuie-jamais-de-larmes-sans-gants#Offer_4",
                "type": "Offer",
                "availability": "InStock",
                "price": "55.00",
                "url": "https://am.ticketmaster.com/pda/fr-ca/virtual-venue/RDNEMTIxN1A="
              },
              **{
                "@id": "http://kg.footlight.io/resource/placedesarts-com_nessuie-jamais-de-larmes-sans-gants#AggregateOffer",
                "type": "AggregateOffer",
                "additionalType": "Paid"
              }**
            ]
          }

Est-ce normal?

[saumier]

@christianroy Yes I think we are almost at the conclusion....

Answers to your questions:

Je suis presque certain qu'on a abordé le sujet suivant seulement de vive voix, mais je ne suis plus certain de la conclusion. Je comprends des notes et de ma compréhension limitée que l'offre agrégée peu avoir une propriété availability. Toutefois, je ne suis pas certain de comprendre comment elle sera/serait déterminée. Et dans les faits, dans le dump, je ne vois pas de availability pour l'offre agrégée. Est-ce qu'il faut conclure que c'est au consommateur de la donnée de choisir ce qu'il fait des données?

I have ideas but I recommend leaving it up to the ticketing platform. But if this is very important I could sum up all the nested offers availability and if it includes at least one "InStock" then I can set the AggregateOffer availability to "inStock".

J'ai aussi vu un cas que je ne suis pas certain de comprendre dans PDA. Pour la représentation dont l'id est http://kg.footlight.io/resource/placedesarts-com_nessuie-jamais-de-larmes-sans-gants#2023-12-13T150000-0500, il y a un AggregateOffer qui liste plusieurs offers (parfait), mais aussi un autre AggregateOffer, comme ceci...

Good find. I will fix this by removing the extra nested AggregateOffer. That is part of the Artsdata way of modelling offers, and it should not be in the LaVirtine dump. I have opened issue #20 and will close it when done.