search

culturecreates / artsdata-data-model

Overview of how data is modelled in Artsdata.ca.
https://culturecreates.github.io/artsdata-data-model/
Creative Commons Zero v1.0 Universal
12 stars 6 forks source link

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

Closed fjjulien closed 8 months ago

fjjulien commented 12 months ago

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 :

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 commented 12 months ago

En guise d'information, voici les recommandations de Google pour la propriété "name" : image Source : https://developers.google.com/search/docs/appearance/structured-data/event#structured-data-type-definitions

christianroy commented 12 months ago

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

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:

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 commented 12 months ago

@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é :

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

Exemple 1 - Nom de l'oeuvre en H1

image

Exemple 2 - Nom de l'artiste en H1

image

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 commented 11 months ago

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:

  1. 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 commented 11 months ago

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 https://github.com/culturecreates/artsdata-data-model/issues/100 ?

christianroy commented 11 months ago

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:

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 commented 11 months ago

@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 commented 11 months ago

@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 https://github.com/culturecreates/artsdata-data-model/issues/100)?

fjjulien commented 11 months ago

@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 commented 10 months ago

@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:

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:

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:

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...

Screenshot 2024-01-03 at 3 55 27 PM

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 commented 10 months ago

@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 https://github.com/culturecreates/artsdata-data-model/issues/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 commented 10 months ago

@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 commented 10 months ago

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.

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 commented 10 months ago

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 commented 8 months ago

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.