En premier lieu, je remercie le Docteur Pierre FAFOURNOUX, directeur de l'équipe Proteostasis, de m'avoir accueilli et permis de réaliser mon stage au sein de son équipe. Je tiens à remercier la doctorante Laura CUSSONNEAU ainsi que la docteure Lydie COMBARET de m'avoir encadré au cours du stage. Elles ont su me faire confiance, me partager leurs savoirs faire et m'ont permis de travailler dans les meilleures conditions. Pendant ces 10 semaines, leurs connaissances scientifiques m'ont permis de m'enrichir et d'approfondir mes bases dans le domaine. Je remercie leurs gentillesses, leurs patiences et leurs bonnes humeurs tout au long de ce stage. Je remercie également Christiane DEVAL, Valérie CARRARO ainsi que Dulce PERIS-MORENO pour tous les conseils et aides qu'elles m'ont apportés.

Enfin, je tiens à remercier l'ensemble de l'équipe Proteostasis de m'avoir chaleureusement accueilli, ainsi que pour toutes les choses apprises.

Abréviations

Liste des figures

II. L'Unité de Nutrition Humaine (UNH)

L'Unité de Nutrition Humaine est localisée sur 2 sites : le site de la Faculté de Médecine et le site de Theix, au sein duquel j'ai réalisé mon stage. L'unité est composée de 5 équipes de recherche et de 3 infrastructures d'appui : la plateforme d'exploration du métabolisme, l'installation expérimentale en nutrition (animalerie) et l'équipe administrative. On retrouve un effectif de plus de 100 agents permanents. Dirigée par le Dr. Didier REMOND, l'UNH a pour objectif de développer des stratégies nutritionnelles innovantes afin de diminuer ou prévenir les désordres associés au vieillissement et/ou aux maladies chroniques.

III. L'Equipe Proteostasis

Dirigée par le Dr. Pierre FAFOURNOUX, l'équipe Proteostasis concentre ses recherches sur l'étude du métabolisme des acides aminés et des protéines en cas de dérégulation métabolique. L'équipe étudie ainsi les origines et les conséquences des dérégulations protéiques pour développer par la suite des stratégies nutritionnelles ou pharmacologiques. Ces dernières peuvent être de nature préventive, il faut alors agir avant afin d'empêcher l'apparition de dérégulations de l'homéostasie protéique ou alors de nature curative, et donc corriger ces dérégulations et rétablir l'homéostasie protéique.

Contexte de l'étude

Le muscle squelettique est essentiel pour l'Homme, il assure la mobilité, le maintien de la posture, la contraction musculaire mais également sert de réservoir d'acides aminés permettant la défense de notre organisme (par exemple la défense immunitaire). Il représente 40% de la masse corporelle totale d'un individu. Lors de plusieurs conditions cataboliques (inactivité physique prolongée, vieillissement…), le muscle subit une atrophie musculaire qui se caractérise ainsi par une diminution de la masse globale du muscle. L'atrophie musculaire perturbe également l'homéostasie corporelle globale entrainant des réponses moins efficaces aux traitements et une morbidité plus importante. Aucun traitement préventif ou curatif efficace n'existe à ce jour, c'est pourquoi cela reste un enjeu de santé publique.

L'atrophie musculaire est la conséquence d'un dérèglement de l'homéostasie protéique provoqué par la suractivation ou l'inhibition d'un ensemble de voies de signalisation comme la voie eiF2a-ATF4, qui répondent à différents stress. Cette voie de signalisation trop activée conduit à une protéolyse trop importante, alors qu'une activation modérée et temporaire en amont d'une situation catabolique, est suggérée par l'équipe comme pouvant prévenir en partie l'atrophie musculaire. L'équipe a donc réalisé un protocole expérimental chez des souris pour tester cette hypothèse. La voie eIF2a-ATF4 a été activée (ou non) de façon modérée et transitoire pendant 3 semaines par une molécule pharmacologique, l'halofuginone et les animaux ont ensuite été soumis (ou non) à une inactivité physique grâce au modèle de suspension par le train arrière. L'objectif de mon stage a été de caractériser l'effet d'un pré-conditionnement à l'aide de l'halofuginone, en amont d'une atrophie musculaire provoquée par la suspension des pattes arrières chez la souris. Lors de mon stage, je me suis tout particulièrement intéressé à l'expression de différents marqueurs du dérèglement de l'homéostasie musculaire (protéolyse et synthèse protéique), ainsi qu'à l'expression de gènes cibles de la voie ATF4 dans les muscles gastrocnémiens des souris.

III. La voie de signalisation eiF2α -ATF4

En réponse à différents stress (cf. figure 6), différentes kinases (PERK, PKR, HRI, GCN2) peuvent être activées entrainant la phosphorylation de eIF2α sur la sérine 51 [START_REF]L'activation de la voie eIF2α-ATF4, une réponse adaptative au stress cellulaire[END_REF] Suite aux 3 semaines, 8 souris de chaque groupe ont été suspendues par la queue (cf. figure 8) pendant 3 jours (souris HS3) et 8 autres pendant 7 jours (souris HS7). Les 8 dernières souris de chaque groupe ont servi de contrôle à l'expérience puisqu'elles n'ont pas été suspendues.

De plus, 30 minutes avant le sacrifice, les souris ont reçu une injection de puromycine par voie intrapéritonéale à une dose de 0.04 µmol/g de poids corporel dans le but d'estimer la synthèse protéique musculaire (cf. figure 2). Au terme du protocole, les souris ont été sacrifiées, puis l'équipe a ainsi récupéré les muscles gastrocnémiens pour les peser et les conserver à -80°C jusqu'à utilisation. automate qui est la « G-Box » (Syngene), pendant une minute (Lampe TLUM, Filtre Upper wave). Cette étape est nécessaire car elle va permettre aux molécules trihalométhanes comprises dans le gel de s'associer aux acide aminés tryptophane des protéines sous l'action de la lumière UV. Ceci nous permet ainsi de visualiser les protéines contenues dans les gels. Ces images nous ont permis par la suite de quantifier la quantité de protéines déposée et de corriger les résultats d'éventuels problèmes de dépôts en normalisant la valeur des signaux anticorps par cette valeur TGX.

II. Western Blots

Ensuite, par une technique de transfert liquide, les protéines ont été transférées sur une membrane de PDVF (polyvinyldene difluroride) dans une cuve d'électrophorèse à un courant constant de 0.15A (Ampère) sur toute la nuit, sous agitation magnétique et à 4°C. Les membranes ont préalablement été activée dans de l'éthanol 100% pendant 30 secondes afin d'enlever le caractère hydrophobe de ces dernières et donc permettre le transfert des protéines sur les membranes.

A la suite du transfert, les membranes ont ensuite été plongées dans une solution de blocage (BSA 5% -TBS 1X -0.1% Tween 20) pendant 1 heure sous agitation à température ambiante. Ces dernières ont ensuite été hybridées avec l'anticorps primaire (cf. tableau 2). Les membranes ont ensuite subi un lavage rapide, puis une succession de 3 lavages de 15 minutes dans une solution de lavage (TBS 1X Tween 0.1%). Puis, elles ont été hybridées avec un anticorps secondaires marqué à la HRP (Horseradish Peroxydase) (cf. tableau 3), à température ambiante pendant 1h et sous agitation. Suite à cela, les membranes ont subi le même lavage que pour l'étape précédente. Afin de visualiser les signaux, nous avons réalisé une révélation en chimiluminescence ; pour cela, nous avons utilisé le substrat « Forte » (Immobilon® Forte Western HRP Substrate).

Ce substrat réagit avec la HRP qui est présente sur l'anticorps secondaire ; ainsi le produit de cette réaction émet une luminescence et est donc visible sous l'automate (« G-Box »). Les signaux et images capturés ont été acquis par le logiciel « Genesys » puis la quantification a été réalisée avec le logiciel « ImageJ ». Les valeurs ont ensuite été normalisées contre la quantité totale de protéines déterminée par les gels TGX. La baisse moins importante de la quantité de puromycine incorporée dans les protéines chez les souris suspendues ayant reçu le traitement à l'HF par rapport aux souris traitées à l'H20 suggère que le pré-condionnement par l'HF a préservé en partie la synthèse protéique dans les muscles de ces souris pendant la suspension.

III. RT-qPCR

III. Etude de l'expression des atrogènes et des gènes impliqués dans la balance protéique a. Analyse de l'expression des atrogènes

Conclusion

Mes objectifs étaient d'étudier l'expression de différents marqueurs du dérèglement de l'homéostasie musculaire (protéolyse et synthèse protéique), ainsi que l'expression de gènes cibles de la voie ATF4 dans les muscles gastrocnémiens des souris, afin de préciser les mécanismes par lesquels l'HF avait permis de préserver partiellement la masse musculaire pendant une atrophie induite par la suspension.

J'ai pu montrer pendant ce stage que la synthèse protéique musculaire était réduite pendant la suspension de façon moins importante chez les souris préconditionnées par l'halofuginone.

J'ai également montré que les atrogènes impliqués dans la protéolyse UPS ou lysosomale (autophagie) étaient induits pendant la suspension de la même manière quel que soit le traitement. De plus, j'ai montré que l'induction de la voie ATF4 pendant la suspension n'était pas affectée par le pré-conditionnement. Ceci suggère donc que l'effet de l'HF sur la préservation de la masse musculaire pendant la suspension s'exercerait principalement sur la synthèse protéique, sans impact ni sur la protéolyse, ni sur la voie ATF4.

Ce stage m'a apporté une première approche du monde professionnel qui est celui de la recherche. Durant ces 10 semaines, j'ai rencontré des problèmes lors de Western Blot pour le transfert ou encore la préparation des gels mais j'ai su trouver des alternatives en me tournant vers les personnes de l'équipe ayant plus d'expérience afin de m'aider. J'ai aussi suivi le protocole entier d'un RT-qPCR de l'extraction des ARN aux résultats. Ainsi j'ai pu développer mon sens critique sur mes propres résultats, approfondir mes connaissances théoriques et compétences techniques que j'ai acquises durant ces 2 ans à l'IUT mais aussi devenir plus autonome.

ADN =

  Acide désoxyribonucléique ANOVA = Analysis of variance APS = Ammonium persulfate ARN = Acide ribonucléique ATF4 = Activating transcription factor 4 ATG = Autophagy Gene BET = Bromure d'éthydium BSA = Bovine serum albumin CDKN1A = Cyclin Dependent Kinase Inhibitor 1A CTSL = Cathepsine L EDTA = Éthylènediaminetétraacétique eIF2α = eukaryotic initiation factor 2 alpha EIF4EBP1 = Eukaryotic Translation Initiation Factor 4E Binding Protein 1 FBXO = F-Box Protein FOXO3 = Forkhead Box 03 GADD45A = Growth arrest and DNA-damage-inducible protein 45 alpha HF = Halofuginone HRP = Horseradish peroxydase HS = Hindlimb suspension PA700 = Proteasome activator 700 PCR = Polymerase chain reaction PhIC = Phosphatase inhibitor cocktail PIC = Protease inhibitor cocktail PVDF = Polyvinylidene difluroride qPCR = quantitative Polymerase Chain Reaction RT = Reverse transcriptase SDS-PAGE = Sodium dodecyl sulfate polyacrylamide gel electrophoresis TBS = Tris buffer saline TBST = Tris buffered saline with tween TCEP = Tris(2-carboxyethyl)phosphine) TEMED = Tétraméthyléthylènediamine TG = Tris Glycine TGX = Tris-Glycine eXtended TRIB3 = Tribbles Pseudokinase 3 TRIM63 = Tripartite Motif Containing 63

Figure 1 :Figure 2 :

 12 Figure 1 : Schéma de la traduction d'un ARN messager en protéine

Figure 3 :

 3 Figure 3 : Schéma du mécanisme d'UPS (Ubiquitin Proteasome System) et des gènes impliqués dans cette voie de dégradation protéique

Figure 4 :Figure 5 :Figure 6 :Figure 7 :

 4567 Figure 4 : Schéma du mécanisme de l'autophagie et de gènes impliqués dans cette voie de dégradation protéique

Figure 8 :Figure 9 :Figure 10 :Figure 11 :Figure 12 :Figure 13 :Figure 14 :Figure 15 :

 89101112131415 Figure 8 : Modèle de souris suspendue par la queue (Hindlimb suspension, HS)

Figure 16 : 1 Contexte

 161 Figure 16 : Expression relative d'ARNm de gènes impliqués dans l'autophagie : Atg5 (a), Atg12 (b), Atg16 (c) chez des souris pré-conditionnées à l'Halofuginone puis suspendues ou non

Figure 1 :Figure 2 :

 12 Figure 1 : Schéma de la traduction d'un ARN messager en protéine

Figure 3 :Figure 4 :

 34 Figure 3 : Schéma du mécanisme d'UPS (Ubiquitin Proteasome System) et des gènes impliqués dans cette voie de dégradation protéique

Figure 5 :

 5 Figure 5 : Schéma de la balance protéique en condition physiologique (1) ou en condition d'atrophie musculaire (2).

Figure 6 :

 6 Figure 6 : Schéma de la voie de signalisation eIF2a-ATF4 (Bruhat and al. -2015)

Figure 7 :

 7 Figure 7 : Schéma illustrant le protocole expérimental sur l'animal Les souris ont reçu un pré-condionnement à l'Halofuginone (0.25µg/g) pendant 3 semaines à une fréquence de 3 gavages par semaine, puis ont été suspendues par le train arrière pendant 3 (HS3) ou 7 (HS7) jours.

Figure 8 :

 8 Figure 8 : Modèle de souris suspendue par la queue (Hindlimb suspension, HS)

  a) Extraction et dosage des protéines Nous avons utilisé un protocole pour séparer les protéines nucléaires des protéines cytosoliques. Les muscles gastrocnémiens ont été broyés à l'aide d'un mortier sur glace carbonique, puis environ 50mg de cette poudre a été homogénéisée à l'aide d'un Tissue Ruptor dans 1mL de tampon d'extraction B1 (cf. tableau 1). Les protéines ont été ensuite centrifugées à 800g pendant 15 minutes et à 4°C (cf. figure 9). Le surnageant S0 contenant les protéines cytosoliques a été récupéré afin d'être centrifugé à nouveau dans les mêmes conditions mais pendant 10 minutes. A la fin de ces 10 minutes, le surnageant résultant S1 a été de nouveau centrifugé 10 minutes à 11 000g ; ce dernier surnageant S2 contenait les protéines cytosoliques. Il a été congelé et stocké à -80°C jusqu'à utilisation.

Figure 9 :

 9 Figure 9 : Schéma récapitulatif des différentes étapes de l'extraction protéique

  a) Extraction et dosage des ARN L'extraction d'ARN (Acide Ribonucléique) a été réalisée avec le kit « NucléoMag » ainsi qu'avec l'appareil Thermo Scientific KingFisher Duo Prime composé de pointes magnétiques; 20mg de poudre de muscle gastrocnémien ont été ajouté dans 300µL de tampon de lyse composé de thiocyanate de guanidinium 60% et d'un agent réducteur qui est le TCEP (tris(2-carboxyethyl) phosphine). Suite à cela, nous avons utilisé le Precellys, un automate qui permet de broyer et d'homogénéiser nos échantillons pendant 15s à 6000 RPM. Puis nos échantillons ont été centrifugés pendant 5600g pendant 5 minutes afin de récupérer le surnageant dépourvu de débris cellulaires. Ce kit « NucléoMag » est basé sur la liaison réversible des acides nucléiques à des billes magnétiques dans des conditions tampons appropriées à température ambiante. Dans des plaques 96 puits, nous avons donc déposé sur la première ligne les surnageants, un tampon MR2 « Binding Buffer » composé de propanol 100% afin de favoriser la liaison des acides nucléiques aux billes magnétiques ainsi que des billes magnétiques « NucleoMag® B-Beads ». L'appareil Thermo Scientific KingFisher Duo Prime est composé de pointes magnétiques permettant de réaliser les étapes suivantes : (1) une agitation de 5 minutes afin d'homogénéiser les 3 réactifs et de permettre aux acides nucléiques de se fixer sur les billes magnétiques, (2) une digestion de l'ADN vers la ligne suivante de la plaque par un mélange de rDNase (Recombinant desoxyribonuclease) pendant 15 minutes, (3) des lavages successifs à l'aide du tampon de lavage MR3 (thiocyanate de guanidinium 60% -éthanol 55%) pour éliminer les contaminants et les sels, (4) une dernière étape de lavage à l'aide du tampon MR4 (éthanol 90%) afin de retirer par séchage à l'air l'éthanol résiduel, (5) enfin une élution de l'ARN purifié avec 50 µL d'eau sans RNase. L'ARN peut à cette étape être directement utilisé pour des applications en aval. Suite à l'extraction, un dosage des ARNs a été réalisé. La technique consiste à déposer 1µL d'ARN élué, sur un appareil de mesure qui est le « Nanodrop ». Le principe du Nanodrop repose sur une spectrophotométrie UV/visible qui mesure la concentration des ARN purifiés qui absorbent à 260nm. Des ratios sont ensuite à contrôler (A260/A230 et A260/280) afin de vérifier s'il y'a des contaminations ou non.

Figure 10 :

 10 Figure 10 : Contrôle et vérification de l'intégrité des ARN sur gel d'agarose

Figure 11 :

 11 Figure 11 : Melting curve et Standard curve de vérification des amorces de Fbxo21

Figure 12 :

 12 Figure 12 : Gel d'agarose sous UV avec visualisation de la taille des amplicons de chaque amorce Les amplicons ont été déposé sur un gel d'agarose à 2 % contenant du bromure d'éthidium afin de visualiser les bandes sur UV et d'analyser leur taille par rapport à la taille théorique attendue. Taille théorique attendue : Foxo3a = 116pb / Mef2c = 178 pb / Mef2d = 139 pb / Fbxo21 = 95 pb Nous pouvons ainsi voir sur le gel et grâce à l'échelle nucléique que la taille des amplicons est la même que celle attendue, ce qui a permis de valider les amorces.

Tableau 4 :

 4 Séquences nucléotidiques des amorces utilisées pour la q-PCRLes valeurs obtenues ont été normalisées par le gène de ménage TBP (TATA binding protein), gène ne présentant pas de variation d'expression dans nos conditions expérimentales. Enfin, les valeurs normalisées ont été rentrées dans le logiciel « GraphPad » afin de tracer les graphiques et de réaliser des tests statistiques. f) Analyse statistique Le test statistique ANOVA (Analysis of variance) à deux facteurs (facteur traitement et facteur suspension) a été utilisée pour comparer les différents groupes. Par la suite les données ont été comparées 2 à 2 par un test de Fisher. Les différences d'expression d'ARNm ont été considérées comme statistiquement différentes à un seuil de 5% (P<0.05).

Figure 13 :

 13 Figure 13 : Expression relative de puromycine incorporée dans les protéines chez des souris pré-conditionnées à l'Halofuginone (HF) puis suspendues (HS) ou non

Figure 14 :

 14 Figure 14 : Expression relative d'ARNm d'atrogènes chez des souris préconditionnées à l'Halofuginone puis suspendues ou non L'expression relative de Trim63 (a), Fbxo32 (b), Ctsl (3), Foxo3 (d), Fbxo21 (e), Fbxo30 (f) a été mesurée dans le muscle gastrocnémien des souris préconditionnées à l'eau (H20) ou l'halofuginone (HF) et ensuite suspendues pendant 3 et 7 jours (HS3, HS7) ou non (Ctrl). Les données ont été exprimées par rapport au groupe « H20 Ctrl » corrigé à 1 et sont des moyennes ± SEM pour n = 48. * : P<0,05 / ** : P<0,01 / *** : P<0,001 / **** : P<0,0001 (test ANOVA).

Figure 15 :

 15 Figure 15 : Expression relative d'ARNm des gènes cibles de la voie de signalisation ATF4 chez des souris pré-conditionnées à l'Halofuginone puis suspendues ou non L'expression relative de Cdkn1a (a), Eif4ebp1 (b), Gadd45a (c), Trib3 (d) et Atf3 (e) a été mesurée dans le muscle gastrocnémien des souris préconditionnées à l'eau (H20) ou l'halofuginone (HF) et ensuite suspendues pendant 3 et 7 jours (HS3, HS7) ou non (Ctrl). Les données ont été exprimées par rapport au groupe « H20 Ctrl » corrigé à 1 et sont des moyennes ± SEM pour n = 48. * : P<0,05 / ** : P<0,01 / **** : P<0,0001 (test ANOVA).

Figure 16 :

 16 Figure 16 : Expression relative d'ARNm de gènes impliqués dans l'autophagie chez des souris pré-conditionnées à l'Halofuginone puis suspendues ou non L'expression relative de Atg5 (a), Atg12 (b), Atg16 (c) a été mesurée dans le muscle gastrocnémien des souris préconditionnées à l'eau (H20) ou l'halofuginone (HF) et ensuite suspendues pendant 3 et 7 jours (HS3, HS7) ou non (Ctrl).Les données ont été exprimées par rapport au groupe « H20 Ctrl » corrigé à 1 et sont des moyennes ± SEM pour n = 48 (test ANOVA).

  Néanmoins plusieurs travaux de l'équipe convergent vers l'hypothèse qu'une activation modérée et temporaire de la voie pourrait au contraire limiter la perte de masse musculaire en permettant une meilleure réponse musculaire au stress. Ainsi, activer la voie eIF2α -ATF4 dans des conditions optimales avant un stress, ce que l'on appelle un pré conditionnement, pourrait avoir un effet bénéfique sur la préservation de la masse musculaire.

		2 ème abattage
		+
	Récupération	Récupération
	des muscles	des muscles
	gastrocnémiens	gastrocnémiens
	C'est pourquoi, l'équipe Proteostasis, a émis l'hypothèse qu'une activation modérée,
	transitoire et répétée dans le temps de la voie eIF2α -ATF4 pouvait permettre de préparer le
	muscle à mieux répondre à un stress catabolique induit par une immobilisation prolongée
	(suspension par la queue) chez le rongeur. Ce pré-conditionnement a duré 3 semaines, à une
	fréquence de trois gavages par semaine d'halofuginone, qui est une molécule pharmacologique
	très bien décrite dans la littérature pour activer la voie eIF2α-ATF4. Une préservation partielle
		. Cette
	phosphorylation de eIF2α a deux conséquences : l'inhibition de la synthèse protéique globale
	et l'activation de la traduction de certains ARNm, comme le facteur de transcription ATF4. Ce
	dernier entraine la transcription de gènes cibles ayant un rôle dans l'autophagie, la biosynthèse

et le transport des acides aminés, et la lutte contre le stress oxydant ; ceci permet aux cellules de mieux s'adapter à un stress. Cependant, cette voie est connue pour favoriser l'atrophie musculaire quand elle est fortement activée, avec l'expression de gènes tels que Cdkn1a

[START_REF]CDKN1A protein expression summary[END_REF]

ou Eif4ebp1.

de la masse des muscles gastrocnémiens des souris a été observée pour ces souris traitées à l'halofuginone en amont d'une suspension par le train arrière.

IV. Mes objectifs

Mes objectifs au sein du stage ont été d'étudier les mécanismes moléculaires sous-jacents impliqués dans la préservation partielle de muscles gastrocnémiens chez la souris ayant subi un traitement à l'halofuginone (HF) ou non en amont d'une situation d'atrophie musculaire (suspension par la queue). Pour ce fait, j'ai étudié l'expression de différents marqueurs du dérèglement de l'homéostasie musculaire (protéolyse et synthèse protéique), ainsi que l'expression de gènes cibles de la voie ATF4 dans les muscles gastrocnémiens des souris.

Remerciements

Les souris ont reçu un traitement par l'halofuginone (HF) (0,25 mg/kg) ou de l'eau (H20) 3 trois par semaines pendant 3 semaines en amont d'une atrophie musculaire induite par la suspension par le train arrière pendant 3 (HS3) ou 7 (HS7) jours (n = 48). La quantité de puromycine incorporée dans les protéines a été analysée par Western Blot à partir de 40µg de protéines.

Quantité de puromycine incorporée dans les protéines (membranes)

Abstract

Keywords : Muscle atrophy, Halofuginone, Protein homeostasis, Preconditioning

Nowadays, there are pathologies with no real effective treatment, such as muscle atrophy.

Muscle atrophy is represented by a loss of muscle mass in various catabolic situations due to a deregulation of protein homeostasis. The eIF2α -ATF4 signalling pathway is involved in this protein homeostasis, so studying the expression of its target genes by qPCR allows us to visualize the intensity of pathway activation in muscle atrophy situation. Halofuginone (HF) is a molecule that induces the phosphorylation of eIF2α and thus the activation of ATF4. A pre-conditioning was carried out on mice, HF was administered for 3 weeks upstream of a muscle atrophy induced by hindlimb suspension. My objectives were to study (1) the expression of different markers of muscular homeostasis (proteolysis and protein synthesis), as well as (2) the expression of ATF4 pathway target genes. Our results show that HF limits the decrease in muscle protein synthesis during atrophy. In addition, the results of the expression of ATF4 target genes and atrogenes suggest an increase during suspension in the same way regardless of treatment. The effect of HF could then act primarily on protein synthesis without impacting proteolysis or ATF4 pathway.




  Two of them are short reviews on the Autophagy-Lysosome system in muscle(Vainshtein et al. 2013, Sandri 2011). I will review the main points of these two reviews during the 1 st half hour of class.  The remaining hour will be dedicated to the analysis of a 3 rd article where the title and abstract have been removed. o Read the introduction part and carefully analyze the figures with the help of the material and method part. Make sure you describe for each figure  what is the question raised?  what is the chosen strategy for addressing it?  what are the observations you can make of the figure?  what is the conclusion of the figure in one sentence. o Write an abstract including 1-2 sentences for the introduction, 3-4 sentences for the results and 1 sentence for the conclusion. After the course, you will be able to compare yours to that of the authors. o Find then a title for this paper. Work in pairs. Each group should report on one part of the article. Each pair will probably have to work on two or more parts of the paper. Consider 7 parts: introduction, 5 figures, general conclusion. Please send your work in the week before the course.




  Two of them are short reviews on the Autophagy-Lysosome system in muscle(Vainshtein et al. 2013, Sandri 2011). I will review the main points of these two reviews during the 1 st half hour of class.  The remaining hour will be dedicated to the analysis of a 3 rd article where the title and abstract have been removed. o Read the introduction part and carefully analyze the figures with the help of the material and method part. Make sure you describe for each figure  what is the question raised?  what is the chosen strategy for addressing it?  what are the observations you can make of the figure?  what is the conclusion of the figure in one sentence. o Write an abstract including 1-2 sentences for the introduction, 3-4 sentences for the results and 1 sentence for the conclusion. After the course, you will be able to compare yours to that of the authors. o Find then a title for this paper. Work in pairs. Each group should report on one part of the article. There are only a few of you., share the work among yourselves. Each pair will probably have to work on two or more parts of the paper. Consider 7 parts: introduction, 5 figures, general conclusion.


Mathdoc E Miot

Centre Mersenne

The centre Mersenne

The centre Mersenne is a public comprehensive Diamond Open Access (free to read, no charge to publish) publishing infrastructure for scientific publications.

The centre Mersenne

The centre Mersenne is a public comprehensive Diamond Open Access (free to read, no charge to publish) publishing infrastructure for scientific publications.

Governance

The scientific council evaluates candidate journals; advises on orientations and priorities; comprises 8 to 12 scientists (mainly mathematicians) assisted by a pool of experts.

The steering committee

takes advice from the scientific council; decides on priorities and allocates resources; comprises Mathdoc directors and representatives of Mersenne's supporting institutions.

Plan of the talk

The

  It provides editorial teams with a publishing platform for hosting and dissemination of open access research publications; a range of editorial and technical tools and services to help to manage the journal workflow (peer-review process, publication. . . ). The centre Mersenne is developed by Mathdoc, a French Support and Research unit of Centre National de la Recherche Scientifique and Grenoble University. The centre Mersenne has been launched in 2018 with 10 mathematics journals.

  It provides editorial teams with a publishing platform for hosting and dissemination of open access research publications; a range of editorial and technical tools and services to help to manage the journal workflow (peer-review process, publication. . . ). The centre Mersenne is developed by Mathdoc, a French Support and Research unit of Centre National de la Recherche Scientifique and Grenoble University. The centre Mersenne has been launched in 2018 with 10 mathematics journals. The centre Mersenne What kind of publications? Resarch journals and proceedings; newly created or already existing; flipping journals are welcome of all scientific disciplines in the fields of STEM (science, technology, engineering and mathematics), with an initial kernel in maths; compliant with best editorial practices; formatted with L A T E X ideally; published in Diamond Open Access (no charge to read, no charge to publish). The articles are distributed with a Creative Commons CC-BY licence. The centre Mersenne What kind of publications? Resarch journals and proceedings; newly created or already existing; flipping journals are welcome of all scientific disciplines in the fields of STEM (science, technology, engineering and mathematics), with an initial kernel in maths; compliant with best editorial practices; formatted with L A T E X ideally; published in Diamond Open Access (no charge to read, no charge to publish). The articles are distributed with a Creative Commons CC-BY licence. Trajectory 10 journals, 210 articles published (7 000 pages). Mathematics. 13 journals, 270 articles published (9 000 pages). + Geomechanics 21 journals, 600 articles published (12 700 pages) + Chemistry, Physics, Biology, Earth Sciences (= Comptes Rendus de l'Académie des sciences) 22 journals, 884 articles published (17 834 pages) + several scientific disciplines (= Peer Community Journal) 23 journals, 872 articles published (18 804 pages) ≥ 24 revues, + Computer Sciences. Staff & governance Services Business model A focus on 2 examples On-going projects & perspectives The staff The team is composed of Mathdoc staff 15 people 10 FTE dedicated to the centre for part of the typesetting activity). E. Miot (Mathdoc) Centre Mersenne The centre Mersenne Staff & governance Services Business model A focus on 2 examples On-going projects & perspectives

  services systematically provided: Online publication and dissemination of articles on the centre Mersenne platform: creation of a specific and customised website for each publication attribution of DOI (Digital Object Identifier) with Crossref crosslinking with reference databases, interoperability, an OAI-PMH server... long term preservation through CLOCKSS plagiarism detection Statistics "counter", cited-by tool Creation of a customised L A T E X template Installation and maintenance of Open Journal System (OJS): customisation of a dedicated instance adapted to the editorial board's evaluation process; maintenance and support; documentation and training.

Figure :

 : Figure: Authentification, automatic translation then human post-editing

Supporting institutions

The centre Mersenne is developed by Mathdoc Centre Mersenne: On-going projects

Full-text for all articles: L A T E X → HTML online. Should be available by the end of 2023.

Semi-automatic translation of articles: an online interface enabling scientists or professional translators to translate automatically and post-edit articles of the Compte Rendus de l'Académie des sciences. Available by mid-2023 for Chemistry, Biology, Earth sciences. See next slide.

Comments online: plateform enabling authentified scientists to post comments on articles. Should be available by the end of 2023 for the Comptes Rendus de l'Académie des sciences.

Semi-automatic translation: focus on the project

Project sponsored by the French Ministry of Higher Education and Research and the French Ministry of Culture. Two-fold objective:

Establishing a bilingual scientific corpus that could be utilized as a dataset to train an AI;

Developing a comprehensive computer-assisted translation software set up on the publication website of the Comptes Rendus de l'Académie des sciences.

Features

Principle: machine translation via DeepL possible, and systematically followed by human voluntary or professionnal post-editing of articles.

Pivot format: HTML.

Publication of the translation in PDF (via an intermediate L A T E Xformat) and HTML with a CC-BY licence next to the original work.

Means: 1 professional translator and 1 IT developer during 12 months, 1 freelance translator, + Mersenne staff Outcome after 12 months: 25 articles translated and the interface being tested on a test site.

Difficulty: math formulas are usually not handled by computer-assisted translation softwares.

Conclusion: Main challenges for the centre Mersenne

Face the increasing volume of publication since 2018.

Adapt to new editorial practices because new scientific disciplines involved specific adaptations on OJS and on the platform.

Adapt our platform to new formats (not all the journals in L A T E X).

Develop efficient and ethical services (semi-automatic translation, full-text...). Improve quality, and avoid relying on bibliometric indicators.

Achieve the administrative and financial procedures and contracts taking into account the public administration constraints.

Hire and form people, minimize the outsourcing for typesetting.

Convince the community that the centre Mersenne is a nice, reliable and long-term publishing solution to create or to flip journals in open access.

E. Miot (Mathdoc) Centre Mersenne

Conclusion: Main challenges for the centre Mersenne

Face the increasing volume of publication since 2018.

Adapt to new editorial practices because new scientific disciplines involved specific adaptations on OJS and on the platform.

Adapt our platform to new formats (not all the journals in L A T E X).

Develop efficient and ethical services (semi-automatic translation, full-text...). Improve quality, and avoid relying on bibliometric indicators.

Achieve the administrative and financial procedures and contracts taking into account the public administration constraints.

Hire and form people, minimize the outsourcing for typesetting.

Convince the community that the centre Mersenne is a nice, reliable and long-term publishing solution to create or to flip journals in open access.

Thanks!

Why Mersenne?

Marin Mersenne (1588-1648) has been nicknamed "the secretary general of the republic of scientific letters", as he acted as a hub for scientific information of his time, just before the advent of journals and academies.

Why Mersenne?

Marin Mersenne (1588-1648) has been nicknamed "the secretary general of the republic of scientific letters", as he acted as a hub for scientific information of his time, just before the advent of journals and academies.

A quotation (Baillet, 1691)

" Mersenne s'etoit rendu comme le centre de tous les gens de lettres Why Mersenne?

Marin Mersenne (1588-1648) has been nicknamed "the secretary general of the republic of scientific letters", as he acted as a hub for scientific information of his time, just before the advent of journals and academies.

A quotation (Baillet, 1691)

" Mersenne was like the center of all scholars by the continual commerce he maintained with all, and all with him. It was to him that they sent their doubts and their difficulties to be proposed by his means to those whose solutions were awaited; and when he had received them, he sent them back to them, having almost in the body of the whole Republic of Letters the function which the heart makes in the human body with regard to blood. The Italians regarded him, as we do, as the great mediator of the Letters, who furnished provisions to others, and was able to demand of them what they were capable of producing. "

E. Miot (Mathdoc) Centre Mersenne

Why Mersenne?

Marin Mersenne (1588-1648) has been nicknamed "the secretary general of the republic of scientific letters", as he acted as a hub for scientific information of his time, just before the advent of journals and academies.

A portrait E. Miot (Mathdoc) Centre Mersenne


Bruno Dutailly
email: brunodutailly@u-bordeaux.fr

RIS3D, a Referenced Information System in 3D

Keywords: CCS Concepts:, Computing methodologies → Graphics systems and interfaces, Virtual reality, • Human-centered computing → Visualization techniques, Visualization systems and tools, • Applied computing → Arts and humanities Computer vision, digital humanities, data visualization

3D Geographical Information Systems (GIS), Building Information Modeling (BIM), . . . These words are increasingly used for Cultural Heritage studies to refer to the necessity to connect heterogeneous data with a 3D model.

In this paper, we introduce and formalize the notion of "Referenced Information System in 3D" -RIS3D, which extends the concept of GIS to 3D supports and generalizes it. For this purpose, we propose a generic and modular client-server approach that brings the required flexibility, extendibility and sustainability to deal with heterogeneous data. For queries and their visualization in a 3D environment, we push forwards the notions of layers and markers.

We also provide the readers with our technical choices that allowed us to develop our own implementation of a RIS3D solution. We demonstrate it on a real-case scenario: the preservation of the Lascaux painted cave where our solution has been deployed and is in use.

The proposed notion and generic architecture of RIS3D, its implementation and its deployment show the suitability of such an approach and its potential applications.

walls or ceilings. In recent years, many papers have proposed dedicated solutions to address thos problems (cf. Section 2): Geographical Information Systems (GIS) 3D, use of Building Information Modeling (BIM) . . . Inspired by the GIS definition where data are geo-referenced we introduce in this paper the notion of "Referenced Information System in 3D" -RIS3D (cf. Section 3) where data are 3D-referenced, formalized by a proposed generic architecture and some definitions. It shares similar features and concepts but it is not limited in the azimuthal 2D view. However, to make it possible to reference any data in a generic 3D environment, our approach thus proposes the following new features:

• a complete architecture composed of interoperable modules thanks to open protocols;

• data organization and typing that ensure the genericity and the upgradability of searchable information;

• solutions to ensure the independence between data and 3D support while preserving the cross-referencing;

• an extension of definitions from standards like "layers" and "queries"; • a visualization architecture to display and query data in a 3D environment.

We also propose a full implementation of those architecture and concepts (cf. Section 4).

Finally, we also demonstrate how our new software for storing, searching, and displaying scientific data in a 3D environment meets the user's needs (cf. Section 5). It is currently used by the scientific team in charge of the preservation of the Lascaux cave. We believe that our solution is not limited to heritage and can be scaled to any filed. This case study which already offers thousands of data from different fields is described and discussed.

PREVIOUS WORK

The most commonly known referenced information system is the 2D Geographic Information Systems (GIS). It has been used for decades [START_REF] Quinn | GIS Essentials[END_REF] to record data with a geographical localization. In addition to classical database features, 2D GIS offers functions to organize records in layers, and makes it possible to perform queries based on 2D geometry, such as finding out elements inside a polygon or computing a distance. Those features are well adapted to archaeology since sites are excavated layer after layer, and elements are recorded accordingly. A lot of work and reviews have been published in this field with some of them leading to 3D wondering [START_REF] Herrmann | GIS applied to bioarchaeology: an example from the Rio Talgua caves in Northeast Honduras[END_REF][START_REF] Lock | Spatial thinking in archaeology: Is GIS the answer[END_REF][START_REF] Scianna | GIS applications in archaeology[END_REF]. The first idea is to take advantage of existing 2D GIS and to add the support of 3D data or referencing [START_REF] Katsianis | A 3D digital workflow for archaeological intra-site research using GIS[END_REF][START_REF] Landeschi | Re-enacting the sequence: combined digital methods to study a prehistoric cave[END_REF]. Then the 3D GIS appears and has been explored in a lot of dedicated solutions with either simple adaptations of 2DGIS or 3D models with associated database.

Moving GIS from 2D to 3D

3D GIS in the field of archaeology has been widely described as building information systems (BIM) and historical building information systems (HBIM) [START_REF] Chenaux | a Review of 3d GIS for Use in Creating Virtual Historic Dublin[END_REF][START_REF] Dore | Integration of Historic Building Information Modeling (HBIM) and 3D GIS for recording and managing cultural heritage sites[END_REF][START_REF] Drap | A GIS tool box for Cultural Heritage. An application on Constantine, Algeria, historical center[END_REF]. These works are well adapted to existing buildings, big amount of buildings, and virtual restoration of remains since they rely on BIM for urban managements such as GityGML [START_REF]GityGML: open data model and XML-based format for the storage and exchange of virtual 3D city models[END_REF]. In fact, for acquisitions made with laser scanner or photogrammetry, a process to convert them to buildings with their dedicated structuring is necessary to benefit from classical BIM. Such a specific structuring is hard to generalize to the diversity we can encounter in archaeology, from a single artifact up to a complex field like a cave.

Another approach is to segment 3D data into pieces homeomorphic to planes, and import them into classical 2D GIS [START_REF] Marco Campanaro | 3D GIS for cultural heritage restoration: A 'white box' workflow[END_REF][START_REF] Ployon | Le SIG comme outil fédérateur de recherche interdisciplinaire: application à la grotte Chauvet-Pont-d'Arc (Vallon-Pont-d'Arc[END_REF]. This workaround brings too many constraints on setting up 3D data for complex meshes like caves, but shows that it is justified to use a common database for heterogeneous data. Vertical dimension can be added, leading to what is commonly named as 2.5D models.

Other work focuses on extending 2D GIS features into 3D with the aim to provide a similar approach and workflow in the data management. As PostGIS [START_REF] Obe | PostGIS in action[END_REF] for extending PostgreSQL to 2D GIS features, SFCGAL [START_REF]SFCGAL is a C++ wrapper library around CGAL with the aim of supporting ISO 19107:2013 and OGC Simple Features Access 1.2 for 3D operations[END_REF] is used to perform 3D queries such as volume intersection, area and distance computation [START_REF] Jedlička | A comprehensive overview of a core of 3D GIS[END_REF] and has been integrated to GeoServer [START_REF] Ryoo | Development of an extension of GeoServer for handling 3D spatial data[END_REF]. The SFCGAL project and its usage, shows how transposing 2D geometric operations to 3D is complex.

In conclusion, for these previous approaches, 3D in GIS are either simple 3D viewers, or vertical/height-field projection of more generic 3D data where multiple points cannot span the 3 rd dimension.

Starting from 3D and add a database

On the other hand, fully 3D-based solutions start with semantic annotations based on 3DHop [START_REF] Ivan Apollonio | A 3D-centered information system for the documentation of a complex restoration intervention[END_REF] or including the full process of 3D acquisition like Aïoli [START_REF] Manuel | A Hybrid Approach for the Semantic Annotation of Spatially Oriented Images[END_REF]. Those solutions are in general too closely associated to a given kind of object [START_REF] Ivan Apollonio | A 3D-centered information system for the documentation of a complex restoration intervention[END_REF] or to a 3D reconstruction method (photogrammetry in the case of Aïoli). They do not offer the customization of data storage and are not able to query contents. 3D real time open source softwares offer to build new features to get close to 3D GIS [START_REF] Calori | VR WebGIS: an OpenSource approach to 3D real-time landscape management[END_REF][START_REF] Fanini | Interactive 3D landscapes on line[END_REF]. Those developments are specific to use cases and are not generic enough. Futhermore, the Barreau's perspective work [START_REF] Barreau | Exploration, analyse et gestion d'environnements archéologiques virtuels[END_REF] paves the way to a database displayable in 3D, but no implementation is proposed and the project is more suitable to virtual reality. A generic information system referenced in 3D has been initiated within the research program "ArTaPOC" [START_REF] Feruglio | Un outil de relevés 3D partagé en ligne : premières applications pour l'art et la taphonomie des parois ornées de la grotte de Cussac (ArTaPOC / programme LaScArBx)[END_REF]. It consisted in the development of a 3D tool to free-handed crop a 3D mesh, and record metadata on it. 3D meshes and metadata were stored in a database, accessed by a WEB server through a WEB service, allowing to work together. The following "PHYT" [START_REF] Dutailly | Accéder en 3D aux données de terrain pluridisciplinaires-un outil pour l'étude des grottes ornées[END_REF] project has seen the developments of a more complex database to record analytical data in an experimental cave. Each discipline of the research team was able to create 3D anotations by picking landmarks on the 3D mesh, recording free texts and attaching any file. Quickly, scientists managed to define a common rule to formalize recorded texts in order to perform more accurate queries than looking for a word and then go beyond anotation. They also feedback the need to record analytical data directly in the database rather than in an attached file to perform queries on it. Those needs of a generic database and a finer-grained analysis of numeric data are parts of the guidelines that presided to the development of a RIS3D.

OVERVIEW

To overcome previous limitations, our proposed solution is a generic database able to be both queried and displayed in full 3D. This database implements the ontology [START_REF] Wn Borst | Construction of engineering ontologies for knowledge sharing and reuse[END_REF] chosen by the user to fullfit their needs. It consists in a classical database without added limitation on data types (i.e., there is no need to define in advance what data will be inserted into), and a 3D visualization with query interactions. This genericity offers a new freedom to the user to define its own data type, and to query it. The visualization of such data is also a lock to be addressed. Definition 3.1. A referenced information system in 3D (RIS3D) is a computer framework for storing, accessing, and displaying data related to positions on 3D models.

It is related to geographical information systems but adapted to the specificities of 3D models as well as the required extended genericity due to the multiplicity of potential objects that can be addressed. Similarly to text annotation [START_REF] Marshall | Reading and writing the electronic book[END_REF], we use the same definition for "anchors" and "marker", adapted to 3D, and call "user's data" what is called "body" for a text annotation.

It is worth to notice that such a concept extends (and is thus compatible with) existing solutions that can be considered as partial implementations of a RIS3D.

Suggested Architecture

Seeking for modularity as shown in figure 1, our proposed architecture is composed of four main modules. First, we choose to propose a classical database engine with standard query language. Since modern database engine supports tree of graph representation and generic data storage, we consider that any ontology on data can be addressed this way. The 3D visualization is a separate module able to discuss with the database. A module between these two elements like a web server can ensure the communication and give an access to the managing interface module without a 3D support. It also facilitates the management of access rights and security controls with the supports of standards protocols in the field. The couple database and web server can be distant, if needed, and is able to accommodate multiple viewers and access at once. The communication language and protocol between the web server and the 3D viewer are open and allow to replace any module easily. Non-3D features can be accessed as web pages through the managing interface module.

Database module

3.2.1 Type handling. Setting a type to any stored data will facilitate its manipulation through dedicated features like inserting a new one, editing, displaying. Any type handled by a RIS3D must be storable in a classical database, compatible with queries, and displayed in a 3D viewer. Accordingly to users' needs and to existing database storage systems, a RIS3D is supposed to handle numbers, texts, booleans, and dates. This list is extended with images, documents, list of texts, and colors that are less common but needed. Following users' needs, new types can be added since they can be stored in the database using a combination of existing types. Those fields are parsed accordingly to their types to get full featured typed data. Then sensors or samplings could implement 2D graph as list of values, allow queries and show it as graph. Once defined, these types are used to store data and to give a handy access to it through dedicated interface and operator.

Data organization.

Once the types are defined, data are organized in a graph or tree structure. This structured organization is needed by users to deal with the big amount of data that comes from different fields. In classical relational database engine, this is done by adding new tables and link them together with keys. In recent database engines, the JSON data type [START_REF]Information technology -The JSON data interchange syntax. Standard[END_REF] can handle the tree structure natively. Moreover, the tree organization is already well accepted by users since they use it daily to store their files on their computers in the hierarchical structure of folders. Spatial analysis can be done by the chosen database engine. This could be PostGIS or SFCGAL. The web server can handle this as well on client side, thanks to libraries like treeJS [START_REF]The JavaScript 3D Library[END_REF] 3.2.3 Anchors: objects supporting data. All this custom data must be supported by an object in 3D we call an anchor. The most simple anchor is a 3D point defined by (X,Y,Z) coordinates. However there are other ways to anchor data in 3D. Definition 3.2. An anchor is an object in 3D hosting user's data. The RIS3D handle four different anchors in the four dimensions:

(1) 0D: a 3D point defined by its (X,Y,Z) coordinates. This location is provided by the user, from an external source or by pointing it in the 3D viewer. If available, the normal can be stored to be used afterward while displaying this point. (2) 1D: a 3D segment or a 3D path. This is an ordered list of 3D points.

(3) 2D: a surface. Defining and storing such data is a complex task. We choose to store the user gesture while drawing a shape defining a surface. The camera parameters and transformation are also stored. These most native information can be replayed to build a 3D object regarding the 3D viewer implementation and performance. (4) 3D: a volume. We distinguish 2 ways to define a volume.

• a 3D manifold mesh. This can be used for 3D architectural data based on simple 3D primitive, with a small count of polygons. • a grid of voxels. Those data can be obtained by geomagnetic survey, computer tomography acquisition, . . . From 0 to 3D anchors, their definitions are simple to complex data to store in a database. The storage of a 3D point is obvious, but the storage of 1D to 3D anchors has to be addressed in the implementation.

Web server

The web server ensures the compatibility with the database engine and the communication between the user and the database. It offers a web service to communicate with the 3D viewer and web pages for non-3D operations like users permissions, integrity checks, . . . It also secures communications through the web and controls if the user has rights access to the data.

3D Viewer

3.4.1 3D geometry as backdrop.

Definition 3.3. A 3D backdrop geometry is one or multiple 3D representation of the real studied site or object as a backdrop in the 3D environment.

These representations can be multiple as they describe differently the same part with different resolution of geometry or texture, or different modality like mesh or point cloud. Thus, any kind of 3D representation of this site or object is suitable for a RIS3D. 3D textured meshes built from 3D digitization or computer assisted design are usual in the field. The quality of the backdrop geometry is at the user's discretion. However, precision and resolution are important to set anchors with accuracy. This 3D geometry is separated from the database. The link between 3D backdrops geometry and the database is granted by anchors since both use the same coordinates system. It is up to the 3D viewer to deal with projection issues if any, and hidden transformation if needed. This separation ensures to be able to load different versions of the same 3D geometry without having to convert, rebuild, nor redo records in the database. This happens when there are several hypotheses of restitution, different level of detail for the same geometry, new data acquisition, or evolution over time.

Layers.

Definition 3.4. A layer is the association of a query and a display setup of the answer.

The layer term is similar to a classical 2D GIS, but in 3D, there is no natural notion of above and below since it is given by the third dimension, so layers are not sorted. As in classical database, a query is a list of conditions to be verified to accept a record in the answer.

3.4.3 Display. Since the user can store any kind of data, and any amount of data, a choice must be done while displaying each record returned by the answer. Definition 3.5. A display setup of a layer is a marker and a set of data mapped from the query answer to the marker capabilities. Definition 3.6. A marker is the way of displaying user's data on an anchor in 3D.

Showing anchors as 3D object depends on the implementation of a RIS3D. However whatever the dimension of the anchor -0 to 3D-, showing it in 3D is not trivial since the 3D backdrop geometry is neither related to data nor to anchor. This means that the marker can be hidden by the 3D backdrop geometry. A marker is not only a 3D object, but it also provides functions. Each function can have one argument, and is able to change the aspect of the marker. Definition 3.7. A marker display function is a function that can change the aspect of the marker accordingly to a given typed argument. A marker can implement zero to as many function as needed.

The user can map values from the database to these functions through its arguments. That means that each record returned by the query can be displayed differently according to the data itself. For example, all temperature sensor car be displayed with a ball which size represents the temperature value. Then large balls show high temperature whereas small ones show low temperature. This function system requires having the same type from the database field to the function argument. For more flexibility, a RIS3D includes converters to change the type of data. Definition 3.8. A converter is a function reading a typed data as input and returning this data modified or in another type. It can be parameterized with arguments. This conversion can be basic like changing an integer number to its text representation or parameterized like changing a floating-point number to its text representation with the precision given as argument. Thanks to this converter, a numeric value can be displayed in a text field of a marker.

Another simple converter is an algebraic formula evaluation to transform numeric values. Indeed, it is not required for a RIS3D to deal with unit of measure. If the 3D environment is defined in meter, 3D markers will be displayed in meter. The formula converter is then useful for transforming numeric values into more adapted values for display purpose.

Converters can be chained since the output of a converter is used as input of the next converter. The first converter will use a recorded data as input, and the output of the last converter will feed the marker display function.

Finally, mapping a database field value to a display function consists in picking a field address in the tree representation of data, optionally transform it through one or multiple converters, and feed a marker display function. An illustration of a layer's structure with converters and marker display functions is provided in Figure 2.

It is also possible to feed display function with static values not picked from database, but setup by the user. The same value will be used for all records displayed. For example, this is useful to scale all 3D markers to the same size without linking this appearance to a database field. Fig. 2. Structure of a layer with converters and marker display functions detailed in a) and an example in b). Brackets shows optional elements. In the example, blue balls are the small ones with temperatures less than 10 degrees Celsius and red ones are the biggest with temperatures higher than 14. Temperatures between 10 and 14 are not selected by the query.

Data explorer.

Once queried, data can be consulted and edited using a 2D user interface. It consists in a tree view showing the stored data, and providing tools to edit each element. As stated in the type handling section 3.2.1, each type defines how the data is displayed and edited. This 2D user interface can be displayed in 3D as a floating panel, attached to a marker, or in virtual reality, attached to a controller or to the player [START_REF] Tung | Comparing Spatial Interaction Modalities for 2 D-Widgets in Productivity Applications in Virtual Reality[END_REF].

TECHNICAL DETAILS

For our RIS3D implementation, we have chosen a subset of features and we have done a number of technical choices (language, software, formats, database structure, web server, 3D viewer). In this section, such choices are explained and further detailed as an illustration of the generic definition of a RIS3D.

JSON

The JSON for JavaScript Object Notation [START_REF]Information technology -The JSON data interchange syntax. Standard[END_REF] is a standard text format for data structured in a tree. It comes with couples of keys and values, where values can be a sub-tree, an array, a text, a boolean, a number, or a null value. We choose this format to describe user's data since any data can be stored as values organized in a tree structure. JSON is also used for user's preferences and personal data, and for communications between the web server and the 3D viewer.

Database structure

Most of database engines may be used according to RIS3D specifications defined in the previous section. We have chosen PostgreSQL [START_REF] Riggs | PostgreSQL 10 Administration Cookbook[END_REF] since, at that time and among other advantages, it offers one of the most adapted and effective JSON manipulation: JSON and binary JSON (JSONb) types and many functions to access and edit a part or a value inside a JSON record. Furthermore, it is compatible with the chosen web server. Finally, we use a unique JSON file to describe both an ontoloy (see section 5.3.1) and the database structure: evolution is thus easy to handle.

Mandatory data (i.e., non user defined data). They are stored in typed field. For 0D anchor and normal, the X, Y and Z coordinates are "double" fields. Two "timestamp" fields store the creation date and last modification date through default values or triggers functions integrated to the database. We discuss future possible implementation including database storage of 1 to 3D anchors in section 6.

User's data. They are stored in a JSONb field. The native JSON types are extended to a list of types meeting user's needs. Our full set of types are detailed in the supplemental materials section 1. The typed structure describing the tree organization of user's data with types for each field is defined as a JSONb record in a table "structure". Tree leaves values are all strings containing types of our RIS3D framework. More details can be found in the supplemental materials section 2. The user is free to build its own structure and fill it but the user's data are supposed to match this structure. If not, data will be ignored.

External documents. A table for external document is used to manage binary files stored in the web server, paths, names, and thumbnails for images. This table ensure the management of these files without making blob or base64 values in the JSON user's data. Links are made with a unique key referenced from the user's data. User account. A table "account" stores user's id, login and encrypted passwords in fields, and a JSONb field contains preferences, user's personal data, layers, access control lists (ACL) and registered group of users.

Web server: the information multiplexer

Between the 3D viewer and the web server, all communications are transmitted in JSON. Between the web browser and the web server, web pages templates are sent in HTML, and data to feed them are sent in JSON.

NodeJS [START_REF]Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine[END_REF][START_REF] Tilkov | Node.js: Using JavaScript to build high-performance network programs[END_REF] (v10.11.0) with the "express" [START_REF]Fast, unopinionated, minimalist web framework for Node[END_REF] (v4.16.3) module is the web server engine of our RIS3D framework since its JavaScript language is perfectly adapted to JSON manipulation. A second key point is its ability to deal with many requests thanks to the non-blocking asynchronous system. In fact, the 3D viewer communicate with the web server sending frequently small requests, like performing a query to the database, updating a JSON field, downloading a document, saving settings, . . . Many other modules are used like express-session (v1.17.1) for login session, bcrypt (v4.0.1) for password encryption, pg (v7.5.0) for PostgreSQL interface, . . . The non-3D features are supported by the web server through web pages in a web browser. Front-end technologies are JQuery (v3.4.1), JQueryUI (v1.12.1), Lodash (v4.17.11), and VueJS (v2.5.17). The list of non-3D features is given in supplemental materials, section 3.

Web service communication.

A request to the web service is a JSON object that must contain at least the key "action" which value is a string defining the action. It may contain other keys that parameterize the chosen action. More details are provided in the supplemental document, section 4.

Once the request is performed on the web server, it returns a JSON object to the caller. This object contains an error code, an error message, and optionally a "response" key containing the data. The response data structure depends on the action requested. While performing a query to the database, the returned data is the set of matching records.

4.3.2

Setting up the data structure. The structure is a JSON object and can be easily edited by the JSONEditor [START_REF]JSON Editor is a web-based tool to view, edit, format, and validate JSON[END_REF] (v5.32.4) library and interface. It is also checked to ensure there is no mistakes like an unknown type set to a key.

At this stage, our RIS3D framework can handle complex operation to apply on data regarding modifications made to the structure. For example, renaming a key in the structure will lead to rename this key in all records using it. This is the same for removing a key. If the user remove a key, he is asked to remove the corresponding data.

Data import.

Filling the database with user's data is a very important feature and CSV is commonly used for such an action. However, an important step consists in mapping the columns headers to the fields of the database structure. This is done manually through a web page where the user drags the columns heads to the unfolded tree structure as shown in figure 3. Real-time preview ensures that the mapping is correct.

Once the mapping is validated, the user can import all or a part of the input data at once. Since the type of each field is known, the mapping process includes a data conversion, like formatting dates, or converting text to boolean values for example. All this processing, until adding records to the database, are done in javascript in the front-end page. The CSV file is not uploaded to the server. 4.3.5 Database checks. The database structure is checked and updated if needed. This includes table fields and their types, triggers and functions. The user can also export database, drop tables, and import a table or the entire database. The user's data can be checked according to the typed structure. Our RIS3D framework is capable to list fields in user's data that are not declared in the structure, empty text values, text values which are supposed to be an element of a list declared in the structure, but which are not found in the list. It also checks all links between user's data and the table for external file management and thus provided list of unreferenced files and missing files.

3D viewer

We chose Unity as the 3D engine of our RIS3D framework. Note that all the database, communication and 2D/3D concepts for visualization and interactions are independent of this choice, and can be transposed to similar platforms. However, it allows fast development since it combines many features:

• it offers a very good 3D environment for loading complex 3D backdrop geometry, with textures, and even with levels of detail, if needed; • applications can be built for numerous platform and devices;

• it includes communication with a web server through the unity C# WWW object;

• it comes with a user interface (UI) support, with simple widgets can be displayed on 2D screen or on 3D floating panels. Furthermore, Unity supports the last rendering technologies like shaders, virtual, augmented and mixed reality. The scripting language is C# and is compiled during the build process, which is suitable for real time 3D .

The viewer in our framework is a Unity scene containing the user interface to be able to navigate into the 3D environment, to discuss with the web server and to display data in 3D. Backdrop geometries are added afterward as "addressable assets", built in a separate Unity scene. Our implementation of a RIS3D also uses the asset "new ui widgets" [START_REF]New UI Widgets is a set of widgets and UI interactions; it also includes a widgets generator for the custom data types and converter from default Text to TextMeshPro[END_REF] available on the asset store. This asset adds sophisticated widgets like list and tree views, colors and date pickers, and layouts. Virtual reality is available thanks to SteamVR plugin [START_REF]With SteamVR developers can target one API that all the popular PC VR headsets can connect to[END_REF] for Unity.

Finally, JSON manipulation uses C# Linq library. Translations for internationalization are stored in a JSON file per language and loaded dynamically at startup. 4.4.1 Navigation. All navigation controls [START_REF] Jankowski | A Survey of Interaction Techniques for Interactive 3D Environments[END_REF] are possible. We have implemented "rotate around" and "fly" modes.

The "rotate around" mode has a target located in the 3D environment: the view always look at, and rotate around it. To avoid up-side-down configuration, rotation are limited to zenith and nadir views. With this mode, the user has access to the mouse pointer and is able to set the target position to a point of a backdrop geometry, to create new record, to select displayed data, and to access to the 2D user interface.

A minimap is available and can display rasters provided by the user (see figure 7). It also displays active markers as dots. If a setColor function is used by a marker, the dot is colored with the color passed to this function. The minimap can handle positions and orientations. Those cameras are saved as the current view transformations in the user's settings and can be used to restore the current camera at this view.

3D backdrop geometries and other data to be imported.

There is neither file reader nor importer in our RIS3D framework. In our Unity implementation, 3D backdrop geometries must be either setup in a fresh scene and exported as addressable objects with correct labeling. Labels are used to automatically import prefabs in the right way, for example, to distinguish a 3D backdrop geometry with a 2D raster for the minimap. The user can also label 3D object as invisible colliders for VR teleportation.

Setting up 3D data this way is useful to prepare the data, customizing textures, behavior with lights, levels of details, . . . The user is free to use the power of Unity. Only custom scripts are prohibited. Since all the code must be compiled with the main application, it is not possible to import code in addressable assets. The list of 3D backdrop geometries is accessible in the 2D interface and each can be turned on or off. 4.4.3 2D user interface. All 2D interface are setup in a "canvas". This canvas includes the minimap and is mainly composed by the layer panel. This panel offers the list of layers already available and a way to create new layers. Each layer can be unfolded to show the list of records answered by the query. Two buttons give access to two panels: one for setting up the query, and the other to choose and customize the appearance of the marker. A button force the query to be executed on the server and another force all markers to be redrawn. Other buttons are used to delete, duplicate, rename, or share the layer. Query Interface. As illustrated in figure 4, the panel dedicated to edit the query is split in two parts. On one hand, the structure tree gives access to all elements available in the database. On the other hand, a query can be filled by logical operators AND and OR, or by a function. A function is constructed with a field that can be filled by the user with the help of completion or drag'n'dropped from the structure tree, an operator picked in a list, and the optional argument freely filled. The illustrated interface ensure there are a minimum of two sub elements to a logical operator, and a function has no sub element. The tree defining the query is serializable in a JSON string for storage purposes and for transmission to the web server.

The panel for customizing a marker's appearance is a bit more complex. First of all, a marker is chosen from a list. In our current implementation, we support three different 0D markers: the ball, the cube, and the billboard. The ball and the cube have a function to scale the geometry, and another to change the color. The billboard has a function to change the 2D icon displayed as a rotating sprite, a function to set the size of this icon, a function to set the height of the mast supporting the icon, a function to set the color of the mast and the icon, and three functions to set three texts around the icon.

Like in the query panel, a first part is dedicated to the available structure fields. This list is enlarged by the types defined in our framework in order to define, if needed, constant values rather than values recorded in the database. A second part is the list of rules to be applied to the marker. Drag'n'dropping a type or a structure field in the list creates a new rule. A fresh rule is composed by the input field or a typed defined in our framework and a marker display function. For these types, an input widget is used to set the constant value. This widget depends upon the type. The display function is a list of available display functions according to the input type given in the rule. A default value can be set on this display function and will be used if the input field is not found in the database record. Between these two elements, the user can insert several converters. Each converter has an input and an output type. The input type must be the same as output type of previous converter or constant type or structure field type if it is the first converter. The output type of each converter must be the same type as input type of next converter or marker display function input type if it is the last converter. If needed, arguments can be given to each converter. Those arguments are typed and widgets are provided for each argument to be filled. Some of provided converters are basics like changing a number to its text representation, or changing a text to a color if the text is well formatted. Others are more sophisticated and need to be parameterized with arguments. It is the case of the converter from the type "list of texts" to the type "color". In this converter, arguments are a color for each word of the list. With this converter, a marker can change its color to represent a text recorded as an element of a list. A list of converters is available in supplemental materials section 5.

Figure 5 shows a set of four rules, with constant and database field inputs, and the use of a converter with its arguments. Our RIS3D framework will check the complete chain of types and warn the user if there is a wrong type connection. The choice of the marker and all rules, including converters, are serializable in a JSON string for storage purposes.

Marker backstage.

Markers are made in Unity as prefabs and implements an interface script to provide display functions. Since each marker is unique, scripts are unique too, so creating new markers needs a rebuild of our RIS3D framework. A marker is a 3D geometry that must fit in a one-unit cube. This rule ensures the scale functions to be uniform for all markers. A collider must be provided to make the marker clickable in our framework. In order to be interfaced with our implementation, a marker must implement a derived class and define an exposed function to communicate display functions and arguments to our RIS3D framework. The complete process is the following: for each record returned by the query, the chosen marker is instantiated, and all rules defined in the marker customization for this layer are applied, fed by records or constant values. Our implementation of a RIS3D comes up with several markers, and can be easily enhanced with new markers developed as plug-ins.

4.4.6

Access to user's data. With markers, user's data are visible in the 3D environment, and the aspect of the marker inform about the record contents. Some markers provide text displays in 3D, but it is difficult and obviously utopian to show all user's information since the amount is unlimited. This is the reason why a 2D panel is dedicated to display all these data in a tree view representing the data of one record. This panel is accessed by clicking on a marker or on a record in the response list of a layer.

Existing fields can be edited with a dedicated widget, regarding the associated typed structure (see supplemental materials section 6). A field can also be deleted. To create new fields, the structure tree is available and a drag'n'drop of a field will create the key in the tree view.

Each operation is sent to the web server to update the database accordingly.

CASE STUDY: LASCAUX DECORATED CAVE

Disclaimer: Data presented in this section are only a part of the whole existing databases. This section shows a usage of Lascaux RIS3D, a dedicated implementation of our RIS3D framework and not scientific results about a study on Lascaux cave.

Presentation and needs

5.1.1 The Lascaux cave. The Lascaux Cave has been discovered by four teenagers on September the 12th, 1940, nearby Montignac village, France. It has been ranked "Monument Historique" on December the 27th, the same year. It became very quickly famous all over the world for its parietal wall paintings.

After huge work on accessibility, the cave is open to the public in 1948. The amount of visitors is constantly growing until 122,500 during the year 1962. But these visits and some morphological modifications (concrete planar floor, stairs) have weaken the preservation conditions of paintings. After the appearance of phenomena such as the white disease of the green disease,the French minister of culture, André Malraux, has decided to close the access to the public in 1963. Since 1972, the French Government is the owner of the cave. In 1979, it has been included in the UNSECO World Heritage List with fourteen other prehistoric sites and caves of the Vézère Valley.

Multidisciplinary monitoring.

The scientific team in charge of monitoring the cave is composed by numerous specialists using different methodologies. They gather samples, measurements from sensors, observe the evolution of paintings, engravings and surfaces. Raw data are stored on a common server, but there are multiple databases on different engines, and it is time consuming to cross-check information between them. This tasks is made easier by a RIS3D which main goal is to put all data together in a common referential providing also a full access to all data to each user. A conversion process is an essential but hard task to take benefit from a RIS3D, and it depends on the input format.

3D inputs

3D backdrop geometries.

The main backdrop geometry is a 3D mesh of the whole cave carried out by the Perazio Engineering company in 2014. It was acquired with a laser scanner for the geometry and hundreds of photos/photographs for texturing. The 3D model is segmented in smaller parts corresponding to the rooms of the cave. Each room is a separate mesh with multiple high-resolution textures (16k x 16k). This segmentation is visible in Lascaux RIS3D interface and each room is displayable independently.

The second is a meshed digital elevation map, also built by Perazio Engineering, for the land over the cave. It has no texture. An uniform green material has been applied for the display purpose. Trees have been virtually removed. They can be displayed as 0D markers since they are recorded in the database.

The figure 6 shows both backdrop geometries set up in a unity scene before exporting them to Lascaux RIS3D. Other backdrop geometries have been imported, such as high resolution surface details issued from photogrammetry, or the fence of the parcel.

All backdrop geometries are setup in the same referential and unit, but can differ by their purposes, resolution, textures, or age.

Rasters.

A raster map (see figure 7) representing the cave and the surrounding land in a nadir view is chosen as a minimap. Another version of this map with a shaded digital terrain from a LIDAR acquisition (created by Xavier Muth from Get In Situ) is also available. 5.3.1 Ontology. The ontology (see figure 8) has been defined by the scientific team and meets the different existing databases already in use. Naturally, the first level of the tree organization of the structure is dedicated to this dissociation. The team starts with three main sections: sensors, samplings, and trees.

Input typed data

Sensors are composed by: identification numbers, a type taken in the list of words such as "temperature" and "CO2" that will be extended to other types of sensors, a label as free text to describe the sensor, a boolean to state if the sensor is active, an image which is a picture of the sensor in-situ and, a file field to attach a file containing measures.

Samplings contain more information and some of them are ranked in subsections. At a root level, identification numbers and a volume can be found. Then a first subsection named "operation" describes who, when and how the sampling was made. A subsection "localization" is used to record where the sampling was done and where the sample is stored. And a last subsection "study" stores information about the type of sampling, who order it, from which organism, and the goal.

Trees has one level as sensors. It stores dimensions (height, diameter, circumference), species, type, observations, and identification tags. 5.3.2 CSV import from user's data. The database of Lascaux RIS3D have been fed with CSV exports from existing databases as these data were mostly previously stored in Excel documents. Importation of these data has consisted in defining a mapping between CSV columns and the structure defined in the previous section. This was done through the web interface of Lascaux RIS3D. It took few tens of minutes to map keys but, afterward, the importation of all data is very fast. More than thousands of trees, near 700 samplings, and 70 sensors have been imported that way. Note this is currently only a part of the whole existing databases.

Layers

The first feature that takes advantage of a RIS3D is to simply data visualization in 3D. Since data stored in each record is heterogeneous, it must be filtered by simple queries. We have created three layers (e.g., figure 9) corresponding to the three first-level sections of the structure (cf. figure 8). Each query consists in checking the availability of a section in the data. Then, layers are displayed in 3D as 0D markers for each record filtered by the query. Each marker can have its own appearance defined accordingly to the data it represents. This is done by using the display configuration system of Lascaux RIS3D.

Sensors layer.

We choose colored spheres for sensors, where the color represents the type of the sensor. Temperatures are red and CO 2 are blue. To achieve this, we map the data key sensor/type to the marker function setColor. Type of sensor/type is enum and setColor accepts only color as argument, so we add a converter from enum to color named enumToColor. This converter is configurable since Lascaux RIS3D detects the list of words in the enum. The default markers' size (unit value, so 1 meter) is easily scaled using a constant value mapped to setDiameter function of a marker. In our case, we scale down to 0.2 meter.

Samplings layer.

We have chosen icons as markers for samplings. The are chosen according to the field sampling/study/nature. Each icon is associated to a UNICODE and, once again, we use a converter to change the word taken from the enum to a string containing the UNICODE which is passed to the marker function setIconFromUNICODE. We also set some texts displayed around the icon, and as for sensors, we uniformly scale icons to acceptable values.

Trees layer.

Like for samplings, trees are displayed using icons, but a unique one that is as a constant string mapped to the setIconFromUNICODE function. A color is assigned to each species contained in the data key tree/specie by converting enum to color as for sensors. The size of the icon itself is taken from the key tree/diameter and the height of the mast is taken from tree/height. Both are floating point numbers, but diameter is in centimeter in the database, and height is in meter. So for both settings, the Expression converter is set to do algebraic operation on the value, that consists in simply scaling it, and set better values for display purposes.

Advanced queries.

As illustrated before, the customization of markers according to existing typed data available in a RIS3D leads to a natural and intelligible exploration of information: customizing markers following data in records is a good way to distinguish data variation in the same query. But we can go further with complex queries to more advanced filtering of data together with new tailored display customizations.

As an example, a layer displaying samplings made in 2017 is defined with a query composed with two conditions: field sampling/operation/date must be greater or equal to 01/01/2017 and the same field must be lesser or equal to 31/12/2017. Note that the database engine return false in the absence of the requested field, so it not necessary to test its existence. In this layer, the display customization is the same as the samplings layer defined before.

As a second example, another layer showing all microbiology samplings is set with a condition on the field sampling/study/nature that must be equal to Microbiology. In this case, the color of the marker is changed according to the field sampling/localization/room. Indeed, the samplings layer had the color set to the nature, and in this new layer, all records are microbiology, and the color attribute visually reveals another information available in the records: the grouped localization as shown in figure 10. This view can reveal misplaced samplings, in their room record, or in their position in the 3D space.

Data view

Whatever conditions are in a query or display setup, all data of each record returned by a query are available in a tree view for reading, writing and deleting. Thanks to the typed database, each key has a dedicated widget according to its type to help the user to view and edit the value. The tree structure helps to find and set values, but it has been agreed to have formatted forms dedicated to subtree to ease the reading and recording.

VR support

A VR support has been tested during work sessions. While a user was moving in the cave usingVR device, another was on the desktop computer with the same view, and used the mouse as a laser pointer to point a region of interest. The VR and desktop view can be forecasted with a video projector allowing other users to discuss with the firsts.

Benefits

The use of the dedicated RIS3D by the scientific team of Lascaux is at the very beginning. It has already raised some errors of type in the existing databases, and some misplaced records without border effects on scientific interpretation of data so far. It thus already help in improving the database.

The 3D view of data has shown the distribution of samplings and strengthen the policy setup for up-coming sampling operations. It is also very suitable for discussions about sensors to be sure that every one are talking about the right sensor at the same time. The distribution of trees is also helpful for defining tree cutting strategy regarding species for the land preservation.

It is planed to feed the database with sensor values and query them to reveal uncommon behaviors like excessive temperatures or high CO 2 rates.

Beyond the actual setup, users are able to create their own data structures and layers, which is a major advantage to the monitoring team of Lascaux.

LIMITATIONS AND FUTURE WORK

The features we have deployed are based on the needs of the presented application. However, a RIS3D includes to others features that we have considered and we are working on.

3D queries. We have designed our RIS3D to be close to traditional 2D GIS with similar features. However the addition of a dimension drastically complicate all 2D operations like "is inside a polygon", or "rasterize my data". In fact, the equivalent of a 2D closed polygon in 3D is a manifold mesh. Testing if a 2D point is inside a 2D closed polygon is easy and can be done with several libraries, and moreover directly in database engine like the PostGIS extension of PostgreSQL. Equivalents in 3D are still experimental like in SFCGAL. Even worse, testing if a 3D point is inside a manifold mesh is complex and CPU consuming.

For regular structure, the 3 rd dimension also increases the required resources. As an example, the rasterization of data in 2D GIS consists in making a 2D image where data are discretized into pixels. In 3D, it will result in a 3D image, such as a voxel grid.

Cross table queries. The actual interface allows only queries in one table at once. So it is not possible yet to make a connection neither with another table nor with itself. Since the 0D anchor is the only table available so far, the first idea is to make a self-join to find 0D anchors relatively to another 0D anchor. This could be done to find all 0D anchors closed to another with a distance lesser or equal to a value. The data structure and database is already able to perform such query, but the user interface is not ready to for such an inclusion.

Anchors and markers. Regarding storage in the database, a 1D anchor is a list of 0D anchors, so it can be addressed by a table junction, or a custom JSON field. For 2D anchors, like surfaces, the work in progress is to store a JSON representation of all data needed to replay the user gesture of the clipping operation. This ensures the separation between user's data and 3D backdrop geometry. Finally, for a 3D anchor, 3D manifold mesh or a voxel grid can be used, and could be stored in a separate file or in a binary field of the database.

For each of these new anchors, besides storage, custom database operations, edition, and markers must be addressed.

New types of data. Since types are specifics to an implementation of a RIS3D, it can be freely extended with the condition the underlying data is serializable in JSON. This is what have been done with the type "camera" storing parameters in a sub-object.

We plan to add 2D plots as a series of 2D coordinates with some additional information about axis, titles, scales, . . . We also want to expand database operations to be able to query these series and get underlying information, like a specific value, the minimum, the maximum, . . . Displaying such complex data will be also a challenge. The main idea is to create an image of the plot and display it as a 2D sprite.

Another user need is to show small custom 3D assets as meshes and store it in the database. This could be done as a new type "mesh" referencing a file (e.g., PLY or OBJ), or serialized as a list of vertices and faces, eventually extended with UV maps and textures. Displaying this kind of data in 3D will be done through a marker which geometry is the stored mesh rather than its own geometry. Position, orientation and scale will need to pay attention and stored with the mesh. Applications are numerous, especially on sites that have brought artifacts digitized in 3D.

Dealing with huge amount of data. Retrieving records send all user's data of each through the network. This can be a huge amount of data at once. The idea is to send only fields asked in the where statement of the query and the first level of the tree structure to show at least a cross section of the data. Data used by the marker for the adaptation of its aspect have to be sent too. Then, small request in real time will be done on the data if the user asks for it in the data view feature. There is no lock with this improvement but we must tell the 3D application that JSON is incomplete and where it is incomplete. We also have to deal with merging JSON at each small request.

CONCLUSION

In this paper, we propose, formalize, implement and, test the notion of "Referenced Information System in 3D" -RIS3D as a tool to store, link, cross-query and display heterogeneous data around full 3D digital models of a Cultural Heritage artifact or site. Inspired from Geographical Information Systems, a RIS3D is based on a client-server architecture with interoperable modules. This modularity allows to choose different technologies for the database, the web server and the software to display 3D in real time. The storage can be local through portable software or distant thanks to the web server interface.

For sustainability, our implementation relies on open protocols. For the same purpose, we propose a data organization and typing leading to genericity and scalability of searchable information. Typed structure ensure also both a general robustness and the ease of querying the database, adding and editing data, and displaying the data in the 3D environment.

Our RIS3D approach promotes the independence between data and 3D support. For the visualization, we have propose a dedicated architecture to display and query data in a 3D environment. Visual presentation is organized by the way of markers and layers.

Our implementation of a RIS3D has been tested on a concrete case: the preservation of Lascaux cave. It is now fully deployed and the scientific team is using it to track the evolution of all the measurements and observations. This case demonstrates that such an approach and our actual implementation can bring answers to existing needs and is already suitable for many use cases, especially in heritage preservation where many data are collected.

The application domain is certainly not limited to Cultural Heritage and there are opportunities that a RIS3D can be used in other fields. The current implementation developed for a given application scenario fits users' needs, but does not yet support the full set of potential features. However, the number of application scenarios are increasing quickly and we are already working of such improvements to reach the full genericity of a RIS3D.

Fig. 1 .

 1 Fig. 1. Our proposed generic architecture of a RIS3D built with separated modules and open protocols. Grey texts are examples for implementation.

Fig. 3 .

 3 Fig. 3. CSV import: CSV column headers are drag'n'dropped to keys in the data structure and a preview shows in real-time the five firsts parsed lines organized in a tree following the structure.

4. 3 . 4

 34 Exporting data. Data export can be done for the entire database, by table, or by layer. Export format are JSON, CSV and Excel. The library Excel4Node[START_REF]Excel4node is a full featured xlsx file generation library allowing for the creation of advanced Excel files[END_REF] (v1.7.2) has been used for excel export. For CSV and Excel formats, user's data are flattened to fill columns. The column header is the path to the field constructed with keys attached with slashes.

Fig. 4 .

 4 Fig. 4. User interface of a query with two functions and a logical AND between.

Fig. 5 .

 5 Fig. 5. User interface of marker parametrization. A rule with a converter is detailed at the bottom.

4. 4 . 5

 45 Converters backstage. A converter is a C# class derived from a mother class that defines name, input type, output type, arguments, and functions to apply the conversion. As for markers, creating a new converter implies to rebuild our RIS3D framework.

Fig. 6 .

 6 Fig. 6. Backdrop geometries for Lascaux RIS3D: the Lascaux cave and the above terrain (colored in green), set up in a Unity scene before the export into Lascaux RIS3D.

Fig. 7 .

 7 Fig. 7. (a and b) Rasters of Lascaux imported to Lascaux RIS3D for the minimap. (c) The minimap following the 3D view orientation and showing a raster and 2D markers.

Fig. 8 .

 8 Fig. 8. Chosen ontology for Lascaux defined as a tree. Dark to light blue represents the depth in the tree.

Fig. 9 .

 9 Fig. 9. Simple layers revealing sensors and samplings on the left, and trees on the right.

Fig. 10 .

 10 Fig. 10. Layer showing micro-biology samplings colored by room.

  4.4.7 Adaptations for Virtual Reality. Our RIS3D framework has been tested on a HTC VIVE VR headset. Simple and invisible colliders are used for teleportation. All 2D interfaces are displayed on a 3D panel attached to a controller. A laser pointer used by the other controller can target markers and interact with them. The same laser pointer simulate mouse click on the 2D interface panel, and all features are available in VR. By contrast, keyboard inputs are not supported. Some interactions are studied like speech to text or virtual keyboards to support data editing.

ACM J. Comput. Cult. Herit., Vol. 1, No. 1, Article 1. Publication date: January 2022.

ACKNOWLEDGMENTS

This study receive the financial support from the DRAC (Direction Régionale des Affaires Culturelles) of Nouvelle-Aquitaine, French ministry of Culture. We would like to thank previous financial support through research programs leading to this study: the Artapoc and PHYT projects. We would also to thank researchers and curators who use our implementation for their feedback and ideas. Future work will be supported by the French government in the framework of the University of Bordeaux's IdEx "Investments for the Future" program / GPR Human Past. Thanks to JOCCH reviewers for their objective remarks and advice.