How to handle schema:url on multilingual websites

[fjjulien]

@saumier raise 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.

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

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