Festival model

[saumier]

Proposal and data dump for LaVitrine using real data of festivals across Quebec.

Festival
Event Series
Event (representation)

Case study with Festival La Quarence

[christianroy]

La proposition discutée le 22 mai prend la forme suivante:

• L’édition d’un festival est le premier niveau (Festival)
• Les modalités d’accès (passeport complet, ou pour une journée à la fois, etc.) sont des offres associées au festival (Offer)
• Le festival contient systématiquement des spectacles (EventSeries), qui présente les éléments descriptifs (photo, description, etc.)
• Le spectacle contient une ou plusieurs “représentations”, qui décrit la date, l’heure, le lieux, etc.

Donc, des cas exemples:

• GreenDay à Osheaga est un EventSeries avec une seule représentation
• une pièce présentée trois fois au Carrefour international de théâtre est un EventSeries avec trois représentations

[christianroy]

Alternative sur le nom des classes... et pour rendre le modèle plus générique, de façon à intégrer d'autres entités qui sont semblables à des festivals mais qui n'en sont pas vraiment (des séries quelconques):

• le premier niveau serait un EventSeries avec un additionalType précisant qu'il s'agit d'un festival. Le vocabulaire à utiliser reste à déterminer. On pourra introduire d'autres termes dans ce vocabulaire dans le futur pour les autres types de sries.
• le deuxième niveau serait également un EventSeries avec un additionalType différent

[GenFab28]

Discussion 22 mai 2024

Prendre en compte la notion de Programmation annuelle / trimestrielle / mensuelle qui sortirait comme "Festival" (EventSeries) dans le modèle Vitrine. On pourrait donc avoir deux types de "EventSeries".

Solution / Hypothèse :
Deux niveaux, distinctions des
EventSeries AdditionalType Festival
EventSeries AdditionalType "Séries" - à déterminer

Exemples d'une type "Série" :
La programmation trimestrielle de La Classique qui regroupe des événements de type :

• l'orchestre au parc de Joliette en mai pour 3 représentations
• un quatuor à corde en représentation unique à Louiseville
• une violoniste soliste à Terrebonne pour 5 représentations
• etc.

@saumier

[fjjulien]

@GenFab28 @christianroy L'idée de qualifier des EventSeries avec des additionalType est bonne car elle apporte à la fois une constance dans la modélisation et une flexibilité quant à la variété de séries différentes que l'on peut représenter. Beat Estermann me proposait récemment cette approche pour décrire une tournée ou une production ("run") d'un même spectacle.

Je me questionne cependant sur la pertinence de créer des entités EventSeries pour regrouper des événements sur une base temporelle (mois, trimestre, année, saison)? Ne serait-il pas plus simple d'effectuer ces regroupement avec des requêtes filtrant les événements en fonction de leur date?

[fjjulien]

En guise de référence, voici l'étude de cas du Festival La Quarence, préparée par @saumier et partagée par courriel :

Here is the beginning of a study to help with festival modelling.

I captured the example of Festival La Quarence happening this weekend since it was already in Artsdata from 2 different sources.

Work in progress...

Festival Model - Festival La Quarence

Cette étude de cas est très intéressante car elle illustre bien les différentes façons dont les informations d'un festival peuvent être représentées, selon que l'on consulte le site du Festival (Facebook, dans ce cas-ci), un site de calendrier culturel ou un site de billetterie. Dans ce cas particulier, seul le site de billetterie a des pages web distinctes pour les journées de festivals (en lien avec l'offre d'un laissez-passer quotidien).

@saumier : En ce qui concerne les laissez-passer quotidiens, je constate que tu leur as attribué le type Event et leur as assigné un identifiant Artsdata. Par contre, tu as choisi de ne pas les situer dans la hiérarchie subEvent/superEvent avec les représentations et l'édition de festival. Pourquoi alors leur attribues-tu le type Event, plutôt que de simplement les décrire comme des Offer? Ça m'intrigue.

Dans d'autre cas que celui de La Quarence, on voit parfois des sites web où les pages sont organisées par journée de festival. Ça pourrait donc justifier la création d'entité de type "FestivalDay".

Par ailleurs, pour des cas d'usage statistiques, afin de calculer la fréquentation totale d'un festival, il faut d'abord la calculer sur une base quotidienne. Ça pourrait aussi être une raison de créer des entités de type "FestivalDay" dans un système d'information.

[saumier]

Following the meeting today with LaVitrine (Geneviève, Theo), a10s (Christian) and Culture Creates (Gregory) it was agreed that Gregory will prepare a new dump of the Festival data as minted in Artsdata. This is a different approach from the other event dumps which are derived from specific websites and transformed by passing through Artsdata. If the Festival data minted in Artsdata proves to be preferable over selecting data from a specific website, then LaVitrine may decide in the future to switch all events to use data minted in Artsdata.

[saumier]

Updated slides here with suggested Festival Model for creating a dump of Festival data from Artsdata in August 2024
https://www.icloud.com/keynote/0a4eIGOiGj9UD8OA7FPYAd3OA#Festival_Model_-_Festival_La_Quarence

[GenFab28]

@saumier @christianroy Bien reçu Grégory! Ça part en analyse

[fjjulien]

@christianroy Dans ton commentaire du 22 mai, tu écrivais:

le deuxième niveau serait également un EventSeries avec un additionalType différent

Est-ce que l'emploi du type EventSeries réfère au modèle spécifique de La Vitrine ou si tu proposes cette modélisation pour tous les systèmes d'information? Si c'est pour tous les systèmes, alors je ne comprends pas pourquoi une représentation à l'intérieur d'une édition de festival pourrait être une EventSeries.

Merci d'avance pour la clarification.

[christianroy]

@fjjulien

Est-ce que l'emploi du type EventSeries réfère au modèle spécifique de La Vitrine ou si tu proposes cette modélisation pour tous les systèmes d'information?

La discussion était dans le contexte de La Vitrine, mais avec la préoccupation de rester cohérent et compatibile avec d'autres systèmes. Mais je précise que «deuxième niveau» faisait référence au spectacle et pas à la représentation. Dans nos discussions, les «niveaux» étaient:

• premier niveau: le festival (probablement plus l'édition du festival, à préciser), qui serait un EventSeries avec un type additionnel à déterminer ;
• deuxième niveau: spectacle, aussi un EventSeries avec un type additionnel différent ;
• troisième niveau: représentation.

[saumier]

I have updated the Festival La Quarence case study with a table showing the mapping of the vocabulary betwen Artsdata.ca schema.org and Wikidata.org.
https://www.icloud.com/keynote/0a4eIGOiGj9UD8OA7FPYAd3OA#Festival_Model_-_Festival_La_Quarence

The Artsdata controlled vocabulary for Event types uses ad:Festival for the Festival edition (wd:Q27968043), and proposes a new ad:FestivalSeries for the Festival that happens each year (wd:Q132241).

Keep in mind that the purpose of Artsdata is to capture events published across the cultural sector, and should be viewed as a light vocabulary that leans on Wikidata for enriched semantics. It is very important that entities in Artsdata can be mapped to entities in Wikidata so that more in depth semantics can be extracted from Wikidata when needed. Artsdata does not expect publishers of events on websites to add in depth information such as 2 levels of entities to model the Festival occurence and the Festival series. However, if a festival and its festival occurrences are added to Wikidata, then we can link all the events using Artsdata and Wikidata in a federated query.

The pipeline to export a dump for LaVitrine modifies the Artsdata model slightly to always have 2 levels for events: referentiel:Spectacle (a type of schema:EventSeries even if there is only 1 event) and its referentiel:Représentation (a type of schema:Event at a single dateTime)

In Artsdata an ad:Festival may consist of any combination of single events and event series.

[fjjulien]

@saumier Je vais reformuler en français pour m'assurer de bien comprendre (et aussi pour laisser une documentation en français)...

Une occurence de festival (wd:Q27968043) aurait le type: schema:Event et le additionalType: ad:Festival. Par exemple :

{
    "@context": "https://schema.org/",
    "id": "someURI",
    "name": "someFestivalOccurrence",
    "type": "Event",
    "additionalType": [
        "http://kg.artsdata.ca/resource/Festival",
        "http://www.wikidata.org/entity/Q27968043",
        "Festival",
        ],
    ...
}

Un festival, en tant que événement récurrent (c'est-à-dire une séries d'occurrences de festivals - wd:Q132241) aurait quant à lui le type: schema:EventSeries et le additionalType: ad:FestivalSeries. Par exemple :

{
    "@context": "https://schema.org/",
    "id": "someURI",
    "name": "someRecurringFestival",
    "type": "EventSeries",
    "additionalType": [
        "http://kg.artsdata.ca/resource/FestivalSeries",
        "http://www.wikidata.org/entity/Q132241"
        ],
    ...
}

Cette approche a une logique solide puisque l'occurrence de festival (ad:Festival / wd:Q27968043) a tous les attributs d'un événement unique : la Chose a une durée ininterrompue entre une startDate et une endDate, puis un ou des lieux. Cette Chose est elle-même composée d'une suite ininterrompue d'événements et d'activités de plus courte durée. La continuité temporelle double - du tout ET de l'ensemble de ses parties - justifie donc le type: schema:Event.

Le festival en tant qu'événement récurrent annuellement (ad:FestivalSeries / wd:Q132241) diffère de l'occurrence de festival en ce sens que ses parties ne forment pas une suite interrompue d'activités. C'est plutôt une suite ponctuelle, récurrente. Le type schema:EventSeries est donc approprié dans ce cas-ci.

[fjjulien]

Là où c'est ambigu pour un fournisseur de données du Québec, c'est l'arrimage avec le référentiel DataScène.

DataScène affirme, dans la description de la classe « Série » :

« Un festival est un exemple de série »
https://datascene.ca/modele/classes_principales/

La documentation de DataScène ne précise cependant pas si cet exemple réfère à une occurrence de festival ou à une série de festivals.

Considérant l'ambiguïté de DataScène, un organisateur de festival du Québec pourrait préférer assigner le type schema:EventSeries à ses occurrence de festivals. Cela ne devrait, à mon avis, pas pose de problème pour Artsdata tant que cet organisateur de festival utilise aussi la propriété additionalType et y saisit la valeur http://www.wikidata.org/entity/Q132241 ou la valeur http://kg.artsdata.ca/resource/FestivalSeries (lorsque ce concept aura été ajouté au vocabulaire contrôlé des types d'événements), n'est-ce pas?

De plus, un organisateur de festival pourrait aussi ajouter schema:Festival comme troisième additionalType. Il n'y a pas de mal à fournir plusieurs valeurs sous cette propriété dans l'objectif de répondre aux exigences du plus grand nombre de systèmes différents.