Event name: should it match the performer name or the workPerformed name?

[fjjulien]

Il n'y a pas de convention claire et couramment acceptée en ce qui concerne la valeur à saisir pour la propriété schema:name d'une représentation de spectacle :

• En musique ou en humour, on emploie le plus souvent le nom de l'artiste interprète principal ;
• En cirque ou danse, ça peut être soit le nom de la compagnie, soit le nom de l'oeuvre (selon lequel des deux a le plus de chance d'être signifiant ou d'être reconnu pour l'acheteur potentiel) ;
• En théâtre, on emploie le plus souvent le nom de l'oeuvre.

Ces façons de faire divergentes peuvent avoir des conséquences sur la découvrabilité des représentations de spectacles. À preuve cette anecdote, relatée dans un échange de courriel avec Maude Fraser, responsable du calendrier Signé Laval :

Salut Maude,

Je suis en train de chercher des exemples pour les formations sur la découvrabilité que Dessa et moi allons offrir ce dimanche. Je me base sur les artistes en conférence à la conférence CAPACOA, dont Tentacle Tribe.

J'ai fait une recherche pour connaître les spectacles à venir de Tentacle Tribe. Le seul résultat que j'ai obtenu, c'est une représentation à la Maison des arts de Laval, récupérée par Google sur le site de la compagnie.

Je me suis alors interrogé : pourquoi est-ce que Google ne m'a pas donné de résultat à partir de Signé Laval ?

J'ai donc vérifié vos données structurées sur Schema Validator:
La propriété "performer" n'est pas utilisée pour lier votre événement à l'entité "Tentacle Tribe" (K-10-183) sur Artsdata ou encore la décrire avec la propriété "name".
Les mots clés "Tentacle Tribe" apparaissent bien dans votre description, mais au milieu d'une longue chaîne de 2600 caractères. Google n'a de toute évidence pas estimé qu'il s'agissait de mots-clés pertinents dans cette longue description.
Il n'y a pas non plus d'additionalType indiquant qu'il s'agit d'un spectacle de danse.
Est-ce que tu serais en mesure d'ajouter la propriété "performer" dans Footlight puis de demander à Google d'indexer à nouveau la page dans Google Search Console?

Je serais curieux de savoir si les résultats seront alors différents...

En observant ce contre-exemple, je me demande par ailleurs si nous devrions réfléchir à des moyens de mieux utiliser la propriété "description". Devrions-nous créer un nouveau champ dans le CMS Footlight pour entreposer une description longue comme celle-ci et ainsi libérer la le champ "description" pour une description mieux optimisée pour la découverte (par exemple, « Spectacle de danse de la compagnie montréalaise Tentacle Tribe. » - juste des mots clés importants) ? Ou devrions-nous mettre ce genre de contenu dans la propriété "disambiguatingDescription" ?

Ce même enjeu a été soulevé hier par Christian Roy, en commentaire aux instructions spécifiques à Artsdata :

La question de la différence entre le nom de l'événement et le nom de l'artiste pourrait être soulevée ici. Et j'aurais des approches différentes selon que le destinataire des données est Artsdata (ou autre base de données plus formalisée) ou Google. Idéalement l'artiste serait dans performer, et name serait réservée au titre du spectacle. Par exemple, "Chansons hivernales" comme name, et l'entité Person "Pierre Lapointe" comme performer. Mais si les données sont publiées à l'intention de Google, je pense qu'il faut mettre Pierre Lapointe dans "name" si on veut bénéficier du référencement et d'une bonne visibilité dans les caroussels d'événements ou dans le Event Finder. Les instructions de Google ne sont pas limpides à ce sujet. Performer est optionnel. Donc dilemme (en tout cas pour moi), donc on peut présumer que ça pourrait être aussi un dilemme pour les utilisateurs du document!

1. Sachant que les propriétés "performer" et "workPerformed" sont optionnelles et très peu fréquemment utilisées pour le moment, comment pourrions-nous parer à ce problème potentiel de découvrabilité?
2. Devrions-nous recommander l'emploi de la propriété alternateName pour que les deux noms (celui de l'artiste et celui de l'oeuvre) soient toujours associés au nom de l'événement?
3. Si oui, devrions-nous proposer une norme à savoir lequel des deux devrait être saisi sous "name" et lequel devrait être saisie sous alternateName? Ou devrions-nous tout simplement recommander de saisir sous "name" le nom de l'entité la plus susceptible d'être reconnue par un acheteur potentiel (et de saisir le nom de l'autre entité sous "alternateName")?
4. Y aurait-il aussi lieu de nous appuyer sur la propriété disambiguatingDescription pour rendre plus facilement repérables non seulement les noms mais aussi les mots-clés associés au type d'événement?

[fjjulien]

En guise d'information, voici les recommandations de Google pour la propriété "name" :

Source : https://developers.google.com/search/docs/appearance/structured-data/event#structured-data-type-definitions

[christianroy]

Quand je disais que les instructions de Google ne sont pas limpides, je faisais référence à la contradiction entre:

• d'une part, l'affirmation «Don't include extraneous information like URLs, prices, or performers. Instead, use the appropriate properties for those values.»
• et d'autre part, le fait que la propriété performer soit optionnelle, et que dans les faits, quand Google affiche de l'information d'un événement, il utilise seulement le contenu de name.

D'où le dilemme... Si on veut faire de «bonnes» données et mettre le nom de l'artiste dans performer, on est pénalisés sur l'affichage et la recherche dans Google parce que le nom de l'artiste est souvent plus notoire que le nom du spectacle.

En réaction aux 4 questions-propositions de @fjjulien, j'aurais tendance à proposer:

• name contient le nom de l'entité la plus susceptible d'être reconnue par un acheteur potentiel (ou les deux entités si c'est utile). Ex: «Louis-José Houde - Mille mauvais choix»
• performer contient l'identification claire de l'artiste. Ex: «Louis-José Houde»
• workPerformed contient le titre du spectacle. Ex: «Mille mauvais choix»

Je pense que c'est le meilleur compromis pour être Google-compatible tout en permettant aux utilisateurs de données plus stricts (ArtsData) d'avoir des données de qualité.

[fjjulien]

@christianroy Merci pour ton commentaire.

Plus je réfléchis à cette question plus il m'apparaît de plus en plus évident que...

Pour des fins découvrabilité :

• La valeur à privilégier pour le nom de l'événement doit être le nom le plus notoire : celui qui a le plus de chances d'être reconnu par Google comme une entité clairement identifiable (et par l'acheteur du billet aussi).
• Dans la grande majorité des cas, ce sera le nom du "performer" principal. Dans d'autres cas, comme par exemple une représentation de Casse-noisette par Les grands ballets canadiens, ce sera le nom de l'oeuvre.
• Étant donné la diversité des cas, il ne serait donc pas pertinent de proposer une norme en faveur du nom de l'artiste ou du nom de l'oeuvre : c'est celui des deux qui est le plus notoire qui doit être mis de l'avant.

Pour des fins de réutilisation de la donnée (par exemple, la consommation de données dans un calendrier culturel) :

• Il est très commun dans des calendrier culturels de voir le nom de l'artiste et le nom de l'oeuvre affiché en succession avec deux niveaux de texte différents (voir les exemples plus bas).
• L'option que tu proposes («Louis-José Houde - Mille mauvais choix») permettrait peut-être d'afficher «Louis-Josée Houde» au style H1 et «Mille mauvais choix» en H2, mais ça exigerait d'utiliser un Regex pour séparer les deux chaînes de caractères et cela ne fonctionnerait que si toutes les valeurs suivent une syntaxe similaire.
• Si l'on veut automatiser au maximum l'intégration des données dans des calendriers ET fournir au gestionnaire de calendrier la possibilité d'employer des niveaux de sous-titres différents (H1 pour celui des deux noms qui est le plus notoire et H2 pour celui qui est moins susceptible d'être reconnu), il faudrait préférablement que ces données apparaissent dans des champs séparés.
• La modélisation qui s'impose pour ce cas d'usage, c'est : name + schema:alternateName.

Exemple 1 - Nom de l'oeuvre en H1

Exemple 2 - Nom de l'artiste en H1

Sur la base de ce qui précède, je propose donc :

1. Que nous intégrions la propriété alternateName au modèle d'Artsdata (pour les événements et aussi pour d'autres classes); et,
2. Que nous recommandions aux fournisseurs de données de saisir sous name celui du nom de l'artiste interprète ou du nom l'oeuvre qui est le plus notoire, puis de saisir l'autre valeur sous schema:alternateName.

Il serait souhaitable de valider ce scénario auprès de nos trois principaux calendriers: La Vitrine, Signé Laval et Tout culture.

Notez bien : Je ne m'attends pas à ce que cette pratique soit adoptée rapidement par le secteur. Cependant, d'ici à ce qu'elle le soit, Artsdata peut mettre en oeuvre des processus de transformation qui permettrait de livrer les données aux consommateurs en suivant ce format.

@saumier Qu'en penses-tu?

[christianroy]

Je suis d'accord avec tout le raisonnement qui mène à ceci:

• Si l'on veut automatiser au maximum l'intégration des données dans des calendriers ET fournir au gestionnaire de calendrier la possibilité d'employer des niveaux de sous-titres différents (H1 pour celui des deux noms qui est le plus notoire et H2 pour celui qui est moins susceptible d'être reconnu), il faudrait préférablement que ces données apparaissent dans des champs séparés.

Avec une petite nuance ici:

mais ça exigerait d'utiliser un Regex pour séparer les deux chaînes de caractères et cela ne fonctionnerait que si toutes les valeurs suivent une syntaxe similaire

Je ne proposais pas de séparer les chaînes de caractères, je suis d'accord que c'est trop sujet à problèmes. Je proposais de mettre dans workPerformed.name le nom du spectacle, dans performer.name le nom de l'artiste, et dans name une appellation libre du spectacle, qui tient compte des éléments de notoriété, et qui est optimisée pour les moteurs de recherche.

Je pense que ça permet de répondre aux besoins que tu as documentés et que ça enlèverait l'ambiguïté de cette proposition:

2. Que nous recommandions aux fournisseurs de données de saisir sous name celui du nom de l'artiste interprète ou du nom l'oeuvre qui est le plus notoire, puis de saisir l'autre valeur sous schema:alternateName.

J'oublie peut-être un bout, mais l'ambiguïté vient du fait qu'un script consommateur de données ne peut pas savoir où est le titre du spectacle et le nom de l'artiste, puisqu'on laisse la liberté à l'utilisateur de les mettre là où ça l'arrange plus.

[fjjulien]

Je proposais de mettre dans workPerformed.name le nom du spectacle, dans performer.name le nom de l'artiste, et dans name une appellation libre du spectacle, qui tient compte des éléments de notoriété, et qui est optimisée pour les moteurs de recherche.

Je suis bien sûr d'accord avec ce que tu proposes ici. Il resterait à définir ce qu'on entend par « optimisée pour les moteurs de recherche », sans quoi cela risquerait être interprété comme un encouragement à y saisir plusieurs informations distinctes avec des séparateurs (comme on en voit souvent dans les balises <title>).

Cette recommandation ne répondrait toutefois pas au cas d'usage que je décrivais plus haut, c'est-à-dire, le gestionnaire de calendrier culturel qui souhaite pousser deux valeurs distinctes dans deux niveaux de titre différents : pousser dans un élément de niveau H1 le libellé répondant le mieux aux critères de notoriété et de découvrabilité, puis pousser dans un élément de niveau H2 un libellé secondaire qui fait office de sous-titre de l'événement.

Outre le soucis d'avoir un modèle de données le plus simple possible, y a-t-il des raisons de ne pas intégrer la propriété alternateName dans le modèle Artsdata pour des fins comme j'ai décris ici et dans #100 ?

• Savons-nous si cette propriété contribue ou non à l'optimisation par les moteurs de recherche Google et Bing?
• Est-ce parce que peu de solutions off-the-shelf (comme les plugin Schema) intègrent cette propriété à leur schémas?

[christianroy]

Je suis bien sûr d'accord avec ce que tu proposes ici. Il resterait à définir ce qu'on entend par « optimisée pour les moteurs de recherche », sans quoi cela risquerait être interprété comme un encouragement à y saisir plusieurs informations distinctes avec des séparateurs (comme on en voit souvent dans les balises <title>).

Oui! Tu as raison, évitons les références au SEO! L'idée est de suggérer d'y placer un nom clair.

Cette recommandation ne répondrait toutefois pas au cas d'usage que je décrivais plus haut, c'est-à-dire, le gestionnaire de calendrier culturel qui souhaite pousser deux valeurs distinctes dans deux niveaux de titre différents : pousser dans un élément de niveau H1 le libellé répondant le mieux aux critères de notoriété et de découvrabilité, puis pousser dans un élément de niveau H2 un libellé secondaire qui fait office de sous-titre de l'événement.

Effectivement, ça ne donne pas l'information de élément principal / élément secondaire. Si on tient à combiner à la fois des éléments de présentation (adaptés aux moteurs de recherche et au besoin d'avoir des niveaux 1 et 2) et des éléments sémantiques précis, il faudrait suggérer 4 propriétés:

• name pour le nom d'affichage principal (selon ce qui a le plus de notoriété)
• alternateName pour le nom secondaire ou complémentaire
• performer.name pour le nom d'artistes
• workPerformed.name pour le nom du spectacle

En sachant qu'il est possible que la même valeur revienne dans plus d'un champ.

• Savons-nous si cette propriété contribue ou non à l'optimisation par les moteurs de recherche Google et Bing?

Non, on ne sait pas. Mais Google ne la mentionne même pas comme étant optionnelle, donc je doute qu'elle ait de l'impact. Et dans toutes les sections de SERP liés à des données struturées (carousels, snippets ou entrées dans la boîte d'information à droite) ou dans le Event Finder, il me semble qu'il y a toujours seulement une information affichée, qui correspond à name.

[fjjulien]

@dlh28 Que penses-tu de ce que Christian et moi avons conclu à propos de name, alternateName, performer.name et workPerformed.name ? Si tu trouves que ça a du sens, il faudra modifier les instructions du modèle Artsdata ainsi que le gabarit des événements en conséquences.

[fjjulien]

@saumier What do you think about this discussion thread? Do you have any objection to adding alternateName to the list of Event properties (and possibly to Place properties as well, as per issue #100)?

[fjjulien]

@christianroy @dlh28 J'ai rédigé des descriptions alternatives pour les propriétés name et alternateName dans le chiffrier des instructions spécifiques à Artsdata (colonne G):

name
Saississez une appellation par laquelle l'événement est susceptible d'être recherché et reconnu. Il peut s'agir de la même valeur que le nom de l'artiste principal (performer.name) ou le nom de l'œuvre-spectacle (workPerformed.name), selon la notoriété de chacun. N'ajoutez pas d'autres informations (comme le lieu ou la date) ni de séparateur (comme on retrouve souvent dans des balises "title"). Au lieu, saisissez ces autres informations à l'aide des propriétés appropriées.

alternateName
Saisissez une appellation complémentaire à la valeur saisie sous 'name' et qui conviendrait pour désigner un sous-titre de l'événement. Il peut s'agir du nom de l'œuvre-spectacle, de l'artiste principal ou de la compagnie. Il peut aussi s'agir du nom de l'artiste qui assure la première partie de la représention ou encore du nom du festival dans le cadre duquel est représenté l'événement. Ne saisissez pas de variante(s) d'épellation du nom déjà saisi sous 'name'.

Si ces instructions vous conviennent, vous pouvez remplacer les instructions actuelles (colonne F) et proposer une traduction anglaise.

[saumier]

@fjjulien @christianroy

This is a really good thread, are highlights the difficulty in trying to make data feed a UI template in a consistent manner.

These 3 properties make a lot of sense to me:

• name pour le nom d'affichage principal (selon ce qui a le plus de notoriété)
• performer.name pour le nom d'artistes
• workPerformed.name pour le nom du spectacle

I have doubts about formalizing alternateName because it is defined in schema.org as 'An alias for the item.' It sounds very different than a secondary level - that would add information. I don't think it will ever be reliable enough to use in a webpage template, even if Artsdata recommends it.

In Wikidata, the alternateName is already used everywhere to accompany things like schema:name "Québec" with schema:alterateName "PQ" which really are aliases of the same item.

From the data collected in Artsdata from the "wild" (not from Footlight) there is only one site called levivier.ca that uses both schema:name and schema:alternateName in their structured data. Coincidently that also use it to layout the main title from the secondary title. Note that the secondary title (schema:alternateName) has many uses and sometimes includes the artist but can also include additional info like "Dans le cadre de la Semaine du Neuf" or "Cinquième anniversaire de Stick&Bow"

Examples:

• https://levivier.ca/fr/concert/saison-2023-24/cinco
• https://levivier.ca/fr/concert/saison-2023-24/le-hasard

Here is the SPARQL for Artsdata:
https://s.zazuko.com/2VH2i7n

If we want to promote reuse of structured data for display in a webpage template, then I think we should think about this differently. Instead of changing the semantics of schema.org (which is pretty hard) we keep the focus of structured data without adding needs to support layout. We keep the focus of structured data on the "best" title for both humans and machines to get 'bums in seats', and shift the task of separating titles and subtitles for presentation to Artsdata. In Artsdata, where we mostly know the performers, the works Performed, and the event type, an algorithm can generate 2 new properties for the layout needs of websites.

So I propose the following idea:

• Use Artsdata to generate level 1 and level 2 titles for page display purposes
• Add 2 new explicit properties: adr:titleLevel1 and adr:titleLevel2
• Do not ask website owners to change their structured data

This is something that can be curated by leveraging the data processing capabilities of a knowledge graph. It also adds value to Artsdata for consumers. This opens the door to do some "marketing optimization" across the sector, where the "best" title and subtitle could eventually be improved with statistics. This is far from happening today, but I am simply opening the door ;-)

This is not immediate. So in the mean-time the current practise is to display only a single title. This title gets edited in the website CMS (Footlight or other) if needed by the website owner.

Another part of the puzzle is beginning to appear on Artsdata. We are seeing multiple versions of titles of the same event. Artsdata mints events and links to the versions of the same event from multiple websites, each with their version of the title.

For example, the event "Virginie Fortin" in Gatineau has data from 3 websites: salle odyssee, tout culture and ovation ticketing platform. If you click the little stacked icon for the title (show all versions when the icon is red), you can see the title from Ovation is "Virginie Fortin (Mes sentiments)" and from the other sites it is "Virginie Fortin".

https://artsdata-nebula-d1ec887e2637.herokuapp.com/entity?uri=K23-316

This is still a work in progress...

So Artsdata is already taking a step towards curating titles of events, by selecting the most common one for now. But I see a potential opportunity here in the future to providing titles with layout options :-)

[fjjulien]

@saumier I really like your proposed solution. Explicit Artsdata Level1 and Level2 properties will be yield much more consistent data outputs for data consumers than any attempt at formalizing the use of alternateName.

Here are a few additional thoughts:

1. Please consider naming the properties adr:nameLevel1 and adr:nameLevel2. I believe these names would be more intuitive to developers, as they would signal a relationship to schema:name. In addition, a "name" nomenclature would be suited for entities other than Event type. For example, these properties could be used for Place entities - and therefore address the issue I raised in Place: Providing BOTH the room name AND the building name #100
2. The algorithm for determining Level1 and Level2 values should be publicly documented and some community input/review process should be put in place. Rationale:
   • Data providers should be able to understand how their data input will be transformed and served to data consumers. This would give them the opportunity of adapting their data structure to meet both their own display needs and to control how the information will be displayed in secondary events listings.
   • Conversely, each data consumer may have their own display preference. A community process for achieving consensus on the algorithm's rules would ensure the data meets the needs of the largest possible number of data consumers. This doesn't need to be a labour intensive process. It could be something as lightweight as a Github discussion thread with an annual meeting if and only if issues need to be discussed face-to-face.
   • Besides, a publicly documented algorithm would be a good means of promoting the use of performer.name, workPerformed, and any other data input required by the algorithm (for example, Artsdata event types).
3. The Virginie Fortin case is a perfect illustration of why we need two explicit title properties and why the algorithm for populating these properties should be publicly documented.

I think we have a roadmap for resolving this issue. And if you agree, we'll also have another good user story illustrating how Artsdata can deliver better data than primary source data.

[saumier]

@fjjulien @tammy-culture @christianroy @troughc I am adding this idea of generating nameLevel1 and nameLevel2 properties for events to the use cases in the annex of the Artsdata Nebula Report so we can plan this feature in the road map. I will also link back to this thread for reference.

[fjjulien]

J'ai proposé les instructions suivantes pour la propriété alternateName dans le chiffrier des instructions spécifiques à Artsdata :

Saisissez une appellation complémentaire à la valeur saisie sous 'name' et qui conviendrait pour désigner un sous-titre de l'événement. Il peut s'agir du nom de l'œuvre-spectacle, de l'artiste principal ou de la compagnie. Il peut aussi s'agir du nom de l'artiste qui assure la première partie de la représention ou encore du nom du festival dans le cadre duquel est représenté l'événement. Ne saisissez pas de variante(s) d'épellation du nom déjà saisi sous 'name'.

@saumier y a réagi avec ce commentaire :

In my opinion this should be an alias that can be substituted with the event.name. So I don't think we should ask to make it about something complementary like the name of the festival, for which it is not an alias.

I'll be responding here to keep traces of this conversation and to allow other to weigh in.

• A text string's suitability to be substituted to name isn't the only good criteria to determine what values are proper values to serve as an alternateName. An alias is name by which a thing can "also be known as" (and searched by). « Salle Louis-Fréchette » is likely to be frequently searched by the more generic name « Grand théâtre de Québec », but that doesn't make the latter a proper substitute name to K5-179. Yet, « Grand théâtre de Québec » is an entirely fine alternateName to « Salle Louis-Fréchette » in my opinion, because a lot of people don't bother to make a distinction between a building and a room within it.
• The same logic should apply to event names : any name string that is broader or more generic than the actual event name can be suited alternateName if it's a string by which someone may look for the event. For example, someone in Moncton may have heard on the radio or seen an ad about emerging singer songwriters being presented as part of a « Coup de coeur francophone » performance (as in this example). But when browsing their phones, they may use the name of the series as their keyword rather than the names of the individual artists. I agree with Gregory that a festival name isn't always a good alias for a performance name. For example, "Ottawa Bluesfest" wouldn't be a useful alias for "Mötley Crüe". But I can't think of plenty of cases where the name of the super-event (be it a one-day mini-festival or a branded series) would be more likely to be searched than the name of the individual event.
• Similarly, "Featuring iskwē" would not be a good substitute for the name of an where "Jeremy Dutcher" is the main performer. But it's an entirely appropriate complementary value to populate as an alternateName.
• In the same vein, if a presenter decides to name an event only by the performer.name, then the workPerformed.name is a good complementary value to provide as an alternateName. Otherwise, someone looking for all possible performances « En marge du texte » by David Goudreault might miss this performance in Gatineau.

En tenant compte des commentaires de Gregory, je proposerais donc cette nouvelle version des instructions :

alternateName
Saississez une autre appellation par laquelle l'événement est susceptible d'être recherché et reconnu. Il peut s'agir du nom de l'œuvre-spectacle ou de l'interprète principal (si celui-ci n'est pas déjà saisi sous 'name'). Il peut aussi s'agir du nom de l'artiste qui assure la première partie de la représention, du nom du super-événement ou de toute autre appellation qui conviendrait pour désigner un sous-titre de l'événement. Ne saisissez pas de variante(s) d'épellation du nom déjà saisi sous 'name'.

Qu'en pensez-vous?

[dlh28]

Cette nouvelle instruction me convient. Si tout le monde est d'accord, je peux la traduire en anglais et on peut la formaliser dans le chiffrier

[fjjulien]

Dessa et moi avons mis en oeuvre les bonnes pratiques définies plus haut dans le chiffrier des instructions spécifiques à Artsdata. J'ai créé une copie d'archive de la version 2 et j'ai renommé l'onglet courant « v3 ».

Je vais me charger d'intégrer ces nouvelles instructions au gabarits de données structurées.

@saumier From my point of view, this issue can be closed.