Fréquence de rafraîchissement des données

[fjjulien]

Geneviève Fabio a soulevé une question pertinente par courriel :

Le branchement dont La Vitrine a besoin est un branchement qui permet la mise à jour hebdomadaire des données. Toutes les sources branchées à La Vitrine fourniront de la donnée à une fréquence régulière, minimalement hebdomadaire pour toutes les sources qui traitent d'événements et de représentations. Évidemment, il y a quelques nuances à cette récurrence pour les sources qui ont une programmation mensuelle ou unique une fois par an, etc., mais ici n'est pas le propos. Ce que je questionne, c'est la capacité à exploiter les données d'Artsdata hebdomadairement avec une mise à jour conséquente. Pour que le branchement soit pertinent, je dois m'assurer de la capacité à fournir une donnée mise à jour en temps réel avec ce qui se fait sur les sites moissonnés. Est-ce le cas?

Une question similaire a aussi été posée par les membres du comité d'évaluation du programme Accroître hier.

Plutôt que de répondre à Geneviève par courriel, il me semble utile d'aborder cette discussion dans Github.

[fjjulien]

Une fréquence hebdomadaire, comme Geneviève le propose, me semble réaliste mais je me demande si ça va demeurer faisable et souhaitable au fur et à mesure que le nombre de sites moissonnés augmentera. Il faut considérer la capacité technique de moissonner un nombre donné de sites, les coûts financiers et l'empreinte énergétique.

L'entente de moissonnage convenue afin de répondre aux besoins de La Vitrine prévoit 24 sites. Cependant, on doit faire nos prévisions en fonction d'une croissance du nombre de sites moissonnés. En incluant les sites au Québec et hors-Québec, il y a plus de > 80 graphes avec événements à venir actuellement dans Artsdata. Si on veut établir une stratégie qui demeurera valable dans 1 ou 2 ans, il faudrait en fait prévoir sur l'hypothèse d'au moins 100-150 sites moissonnés.

Dans le court terme, dans l'objectif d'aider La Vitrine (et les autres usagers d'Artsdata) à avoir les données les plus actuelles possibles, nous pourrions envisager la synchronisation des mises à jour:

• À 100 sites moissonnés, serait-il possible pour Artsdata d'actualiser tous ces sites, par exemple, pendant la nuit du mardi au mercredi de chaque semaine, de sorte que les données soient rafraîchies juste avant les soirées les plus achalandées de la semaine?

Advenant une croissance plus rapide qu'anticipée du nombre de sites moissonnés, nous pourrions envisager de moduler la fréquence de rafraîchissement des données en fonction du nombre d'événements sur le site. Par exemple, pour les sites avec moins de 20 événements à venir, la fréquence pourrait être réduite à un moissonnage par deux semaines.

Est-ce que de tels scénario sont faisables techniquement en date d'aujourd'hui et possiblement durables dans le temps?

[saumier]

@fjjulien Thanks for asking this great question.

The short answer is yes, from my calculations Artsdata Databus can process data from about 100 web sites overnight with the current architecture.

On average it takes under 1 minute to upload a small site like Gatineau cloud (about 6,000 triples) and about 3 minutes for a medium web site like place des arts (about 200,000 triples). This includes loading, running data quality tests (SHACL), some basic transformations, and adding metadata about the provenance.

If I make projections with an average of 2 minutes per website, Artsdata can process 30 websites per hour, so overnight (midnight to 7AM) it can process 210 websites on average.

When Artsdata grows far beyond the current size, I have planned for greater performance, and less energy consumption. The current version of Artsdata code replaces the entire graph with each upload. This is fine for now, and I have not invested time in optimizing this yet. But when optimization is needed, I have already some improvements in mind. The first is to update only the "changes" in the data, rather than drop and load everything in the graph. The next is to reduce unnecessary inferencing (graphs are generally slow to load because graph db calculates and stores all inferences when inserting data). I estimate these improvements to be around 1 order of magnitude, meaning 300 websites per hour. All of these projections are still using the free version of GraphDB which limits inserts to a single thread (queries are multi-threaded and run in parallel with inserts). I have excluded the idea of a paid license, which would allow multiple inserts in parallel, because it is very expensive in license fees and unnecessary for the needs of the current Artsdata projections.

The other consideration is the actual web scraping. This is done outside of the Artsdata server, and can be done massively and in parallel. Currently Footlight does most of the crawling, but there are also websites that get crawled by Huginn and now Github workflows for website that have good JSON-LD. My current preferred approach is to use Github workflows which are free and run in parallel. Github workflows scale by default. Huginn will take about 1-3 minutes to crawl a website like GTQ. These tools can run in parallel so thousands of websites can be crawled in a single night.

Since Artsdata Databus only receives data and does not control when data gets sent to it, the current status is that about 20-30 web sites are sent daily, about another 30-40 weekly, and the rest can range quite a bit (some datasets are people, organizations, places and not events). The date of each dataset load is stored in the graph's metadata

Let me know if that answers your questions.

Gregory

[fjjulien]

Thank you for this detailed response.

How difficult would it be to implement a "push" system by which a registered user could explicitly request a data refresh after a website update? I know it's technically possible since CAPACOA has this feature in place for the LIVE Performing Arts Directory. But could we scope the costs and add this to the list of features for the Nebula editor? I think it would be useful to alleviate any concern about Artsdata's capacity to deliver up-to-date data.

And could we also scope the costs of implementing improvements for energy efficiency purposes?

[saumier]

I have added the Use Case: Trigger a Data Refresh following a Website Update to the annex of the Nebula document. The estimate is between 4 hrs and 16 hrs.

[saumier]

@fjjulien It is not possible for me to scope the costs of implementing improvements only for energy efficiency alone. At Culture Creates we have a development culture that values energy efficiency, as well as performance and FAIR principles. As we work on the expansion of Artsdata we are driven to improve both performance and energy efficiency. If you need a budget, then I propose a 6 month expansion of Artsdata from 100 websites (today) to 1000 websites or something in that nature.