How to handle schema:url on multilingual websites

[fjjulien]

@saumier raised the following very interesting question over email:

You can look at the capitol-nb-ca datafeed in Artsdata
http://kg.artsdata.ca/en/query/show?title=Event entities in capitol-nb-ca&sparql=list_events&graph=http://kg.artsdata.ca/capacoa/artsdata-orion/capitol-nb-ca

The last issue I have, is that there are 2 urls from en and fr webpages for the same event. The Artsdata data model wants a single url for the event. This same problem happened in Footlight console many years ago and was solved by doing 2 transforms:

1. creating 2 WebPage objects per event, each with a url and "inLanguage". That allows the reuse of the event with an unambiguous meaning for the 2 urls leading to en and fr webpages.
2. selecting 1 url to be the event main url based on the default language setting for the website in Footlight Console.

@frederic My question to you: should I use the same solution from Footlight Console described above, or do you see a different solution for an event’s multiple urls on a bilingual website?

The sample data shared by Gregory in his email looks like this:

    "url": [
         "https://capitol.nb.ca/en/tickets-events/melissa-bedard",
         "https://capitol.nb.ca/fr/spectacles-et-billets/melissa-bedard"
         ],

I'll break down my response in multiple comments, to it is possible for readers to upvote or cite specific comments.

[fjjulien]

For reference, the Artsdata instructions for the schema:url property read like this:

Enter the canonical (aka "official") URL of the event webpage on the organizer's website.
https://culturecreates.github.io/artsdata-data-model/classes/event.html

[fjjulien]

My initial reaction was to stick with the principle behind the "canonical" URL: that there should a single URL for defining the single source of truth for duplicate content.

However, in the case of different language versions of the same page, this is not considered duplicate content.

[fjjulien]

The big question with which I am struggling is this one: "Is it Artsdata's role to substitute itself to web browser and to attempt to provide the right language version of an event's official url, depending on the data consumer and their individual users?"

My gut reaction is "no". We should leave this as a conversation between web browsers and web servers.

In the above example, if we had a single url value and it was the English version, a French-speaking user would still be able to access the French page. If for example, this user's browser language settings set French as the only language, the browser would serve the French page. If this user's language settings set French as the primary language along with English, the browser would notify the user that a version in their preferred language is available.

[fjjulien]

This being said, I acknowledge that data consumers with multilingual platforms may want the ability to provide different URLs matching their own language versions. Could they solve this locally, by calling web servers and detecting <link rel="alternate"> tags?

[fjjulien]

From a code efficiency purpose, a single URL value would be much leaner.

[fjjulien]

Ultimately, I think Artsdata should reflect how the data is structured at the source.

• If the source defines a hreflang=”x-default” default language, then we should use this attribute to select and store a single url value.
• If the source defines a single rel="canonical" page across their language versions, then we should select and store this url value.
• If there is no single rel="canonical" (or if each language version points to itself as the canonical URL), then I am not sure what we should do.
  • Defaulting to en would be politically inaccurate and potentially offensive.
  • I guess if the organizer is located in Quebec, we could prefer the fr version since it is the official language in this province. However, unless the organizer is clearly identified, we cannot run any inference. Besides, the reverse inference in the Rest of Canada would be dismissive of Francophone minorities.
  • We could turn the question to organizer and set their preferred default language as a parameter in Orion prior to minting the events.
  • Or we could load both values and store them as WebPage objects, as suggested.

[saumier]

We could turn the question to organizer and set their preferred default language as a parameter in Orion prior to minting the events.

In Footlight Console, which is a service provided by Culture Creates, the Footlight Console has a setting called "website default language" which determines which url to use in the case of a bilingual website with 2 urls for the same event (one per language).

In the case of Artsdata crawling JSON-LD, there are no custom settings for Artsdata (Orion pipeline), and the expectation is that the meta-data is under the authority of the website and not a person at Artsdata.

[fjjulien]

I understand and fully agree with:

there are no custom settings for Artsdata (Orion pipeline), and the expectation is that the meta-data is under the authority of the website and not a person at Artsdata

[fjjulien]

If a single url value is needed (which I am still not sure about - see my question below), then we need an algorithm to make that decision. That's what I was attempting to define in my initial comment.

I think the first two "If" steps I describe could be written into an algorithm and respect the site's authority.

We would just need a simple decision process for the third step, and I'm not keen about defaulting to 'en' for political reasons. I guess we could make the rationale that it's consistent with the Google Event experience (which is only available in English), but when Google crawls Artsdata, they crawl data, not a website, so it's a poor rationale...

[fjjulien]

@saumier Has the use of WebPage objects (rather than a straight xsd:anyURI value) ever been a problem to some data consumers? If so, we should also take this into account. We wouldn't want to create unnecessary obstacles to data reuse.

[saumier]

The data consumer has a choice to use either the event's WebPage object or the event's url (official url of event). Because there is a choice, I do not think there is any barrier to reuse. The event's url is more direct. The WebPage object is more complete, and can be a totally different website than the official url.

This is a related discussion.
#112 (comment)

In the Artsdata datamodel JSON-LD template, the event's mainEntityOfPage is always linked to a WebPage object. This allows the "inLanguage" and "url" properties to be clearly identified. This is optional and is useful mainly when the official url of the event (using schema:url) is different than the linked WebPage.

   "mainEntityOfPage":[{
      "@type":"WebPage",
      "@id":"--URI constituant un identifiant unique de la page Web. Optionnel : URI constituting a unique identifier of the web page. Optional--",
      "inLanguage":"--fr pour français : en for English",
      "url":"URL de la page Web : Webpage URL",
      "lastReviewed":"--Date et heure de la dernière révision : Date and time of last revision--"
   }]

[fjjulien]

Your answer raises additional questions and does not get me much closer to a solution to the core problem, which is to identify the preferred the preferred single value for the url property.

I understand that we can easily populate more than one mainEntityOfPage object (and that is indeed an appealing alternative to populating two values under url).

Is it ok from a Schema and search engine standpoint to have two url values or should we strive to have single preferred value?

[saumier]

Is it ok from a Schema and search engine standpoint to have two url values or should we strive to have single preferred value?

@fjjulien This is the key question of this thread. I don't know the answer from a search engine point of view. The current situation for capitol.nb.ca (example Jimmy Rankin) is to have an event url from their English webpage and a second url from their French webpage with both stored under the event's url.

 "url": [
    "https://capitol.nb.ca/en/tickets-events/jimmy-rankin-with-special-guest-garrett-mason",
    "https://capitol.nb.ca/fr/spectacles-et-billets/jimmy-rankin-with-special-guest-garrett-mason"
  ]

I will keep this status quo until this question of picking a single url can be resolved one way or another.

Neither webpage has a canonical url defined. I am not sure if this is a real world use of canonical as both as different webpages because of language. I would hold off implementing this idea until it can be proven in the 'wild'.

But each webpage has the x-default as in <link href="https://capitol.nb.ca/en/tickets-events/jeremy-demay" rel="alternate" hreflang="x-default">

If you agree, I can check for hreflang="x-default" and use this to select the url to use as the official url.