dataesr/scientific-paragraphs-categorization huggingface dataset:
Limites et apports d'un relevé en trois dimensions de l'art pariétal avec Blender Les possibilités offertes par le logiciel Blender de mener à bien un projet de relevé d'art pariétal constituent une formidable occasion de mieux documenter cette expression artistique paléolithique et de mieux rendre compte des relations entre les images et leur support, ainsi que de la capacité des artistes à exprimer leurs choix formels en fonction de la paroi. Cette approche est également intéressante pour comprendre et illustrer les phénomènes naturels ayant pu affecter la paroi ornée (constat d'état). Les limites de la méthode présentée ici sont avant tout d'ordre technique. En effet, Blender n'est pas un logiciel spécifiquement dédié au dessin sur objet 3D. De manière générale, il ne constitue pas un outil « clé en main » et le temps dédié à la mise en place d'un espace de travail adapté et à l'exécution de certaines tâches témoigne d'un manque d'ergonomie.
La technique du « bake », qui permet notamment de reporter les données de relief sous forme de texture sur un volume simplifié, est généralement déconseillée : les changements qu'elle suppose sont le plus souvent incompatibles avec une analyse précise des volumes des parois. La question du matériel doit donc être soigneusement considérée pour que ce dernier soit en compatible avec le type de modèle traité. Un processeur type Intel Core i5, 8 Go de RAM ainsi qu'une carte graphique type Nvidia GTX 1080 ou équivalent sont conseillés pour une configuration minimale, adaptée aux modèles les moins lourds, à l'image de ceux présentés au fil de cet article. Un processeur et une carte graphique plus performants s'avèrent indispensables pour travailler sur des objets de plus haute définition. De même que pour les logiciels de traitement d'image, l'usage de la souris est peu adapté à l'exercice et il est conseillé de réaliser les relevés à l'aide d'une tablette graphique ou d'avoir recours à des ordinateurs hybrides, particulièrement appropriés au terrain et assez puissants pour faire tourner de petits modèles sur Blender.
Les outils et fonctionnalités mis en place confèrent une grande flexibilité, à la fois dans l'exécution et le rendu des relevés. Ils autorisent ainsi l'enregistrement de la plupart des oeuvres peintes, sculptées ou gravées, et de l'état de la paroi, ainsi qu'une gestion simplifiée de données et un croisement rapide et dynamique des informations, sans jamais perdre en lisibilité, grâce à une hiérarchisation claire de l'ensemble. L'exploitation des relevés exécutés sur un modèle 3D soulève la question de la visualisation des résultats. Blender étant gratuit, son format natif constitue un bon moyen de partager les travaux entre chercheurs. La publication de résultats sous forme d'images reste possible grâce aux fonctionnalités de rendu du logiciel. Le positionnement de la caméra est libre et les angles de vue peuvent être multiples, mais un choix de projection reste nécessaire.
Ainsi, le chercheur peut exporter des vues orthographiques ou en perspective, donc sans déformation mais n'affichant qu'une information partielle. Ces exports 2D seront nécessairement des points de vue uniques sur la surface relevée et pourront illustrer le propos synthétisant la connaissance acquise lors de l'étude. Ces exports participent à l'interopérabilité de la démarche. Enfin, les solutions de visualisation en ligne constituent également une option intéressante. C'est le cas de Sketchfab 5 , dont les modèles peuvent être intégrés dans des pages Web ou téléchargés avec toutes les ressources associées (textures, calques, etc. ) dans des formats logiciels OBJ, FBX ou autre. Les cas d'étude que nous avons retenus illustrent les avantages que présente le recours à la 3D dans des contextes où les contraintes d'accès peuvent constituer une entrave pour les chercheurs.
Les technologies disponibles aujourd'hui autorisent la production de doubles numériques de haute définition qui, s'ils ne peuvent se substituer totalement au site, possèdent toutefois un degré de précision suffisant pour constituer des supports à même de dépasser les difficultés liées au terrain. Les dispositifs, processus et fonctionnalités mis en oeuvre dans le cadre de nos travaux contribuent à offrir aux chercheurs un écosystème 3D structuré, afin de faire de ces modèles numériques de véritables outils de travail -voire de prospection -virtuels et complémentaires, lorsque cela est possible, aux visites sur le site original. Dans ce sens, un livret méthodologique permettant aux chercheurs de s'approprier pas à pas le logiciel Blender pour les relevés d'art pariétal a été finalisé par le Centre national de préhistoire à partir de ces expérimentations (Centre national de préhistoire 2022).
Le logiciel, avec sa large gamme de solutions, permet de croiser divers procédés de relevé au sein d'un même dispositif, facilitant ainsi le travail collaboratif par l'usage de bibliothèques de référence partagées. Enfin, ces travaux nous amènent à soulever la question de l'usage de la réalité virtuelle dans le cadre de relevés d'art pariétal. Celle-ci propose une approche simulant une présence in situ. Quelques outils, bien qu'instables encore, accordent aux utilisateurs de Blender la possibilité de manipuler des objets 3D au sein d'une interface virtuelle immersive. Mais les logiciels tels que les moteurs de jeu présentent aujourd'hui des perspectives plus prometteuses. Les laboratoires virtuels appliqués à des sites ornés difficilement accessibles sont à l'étude et le CNP travaille actuellement à l'analyse d'une grotte ornée au sein d'un dispositif ayant recours à cette technologie.
to exploit the linked nature of graph data by allowing for navigations along deep paths in the graph. The optimization of recursive queries is notoriously known as a difficult problem. Recently, 𝜇-RA  [12]  introduced a clean generalization of Codd's relational algebra for the optimization of recursive queries, enabling in particular richer query evaluation plan spaces than with earlier approaches. We demonstrate a system for recursive query answering over graph datasets. The system includes a complete implementation of the theory of the recursive relational algebra and concepts introduced in  [4, 5, 7, 8, 12, 14]. The system also includes parsers and compilers so that one can formulate, optimize and answer queries that navigate recursively in knowledge and property graphs. We explain the main components of the 𝜇-RA system (parser, optimizer and translator) and then the backend evaluator to evaluate the best estimated plan in a centralized or distributed way  [4, 5].
One major novelty and advantage of this system resides in being a layer on top of an unmodified backend like PostgreSQL. In other terms, the optimization layer can be easily plugged or unplugged on top of existing relational backends, not requiring any modification of PostgreSQL for example. Yet, the overall system offers comparable or even superior performance with respect to recent graph-specific engines (such as MilleniumDB  [20] ) for recursive query answering over practical graphs such as Yago  [10, 18]. The purpose of this demonstration is to present the system in an interactive manner, showing: (i) a discovery and practical tour of the different components and functionalities of the system using concrete queries over real practical graphs; (ii) demonstrating that the system also supports expressive path patterns (regular and not regular) not supported by other systems, yet useful in formulating meaningul queries on real datasets.
By composition, all these rules enable new query evaluation plans (in particular merged fixpoints, and their further transformations) that were not possible with earlier approaches. Overall, this results in a richer query evaluation plan space. For enumerating the plan space, there are two possibilities: (i) a bottom-up enumerator where the application of rewrite rules is applied to one term at a time; (ii) a top-down plan enumerator  [7, 8]  where the plan space is explored by transforming sets of terms at once. The second subcomponent is a cost estimator that picks an estimated most efficient term, based on cost estimations for the algebraic operators and cardinality statistics of the datasets. This cost estimation technique is inspired from  [13, 14]. The optimizer component can be plugged or unplugged.
It makes it easy to measure the performance gains brought by the logical optimizations. A translator. that translates the estimated best term into SQL using Recursive Common Table Expression (CTE) or PL/pgSQL with WHILE loops for more general forms of recursion not expressible with CTEs. This is for instance the case of merged fixpoint terms for the PostgreSQL backend. The distributed evaluator component uses in one of its distributed evaluation plans the SQL translator to compute the fixpoint on PostgreSQL evaluators present on parallel workers  [4]. A backend evaluator. which provides two possibilities: (i) a relational database managment system in charge of evaluating the translation of the best estimated plan. For this demonstration, the relational backend used is PostgreSQL. (ii) a distributed evaluator that distributes the evaluation of 𝜇-RA terms on Spark  [4, 5].
Regular Path Query scenario We start by showing an example of an UCRPQ (Unions of Conjunctions of Regular Path Queries) query of the form (𝑎 + /𝑏 + ) over the Yago dataset. We use a preprocessed version of the real world Yago2s  [10, 18]  dataset. This dataset version contains 83 predicates and 62,643,951 rows (graph edges). They correspond to general knowledge about people, cities, countries, etc. This example is shown in Figure  2. The user writes the query, sets a time budget for the plan space enumeration, and then calls the optimizer with these inputs. The call to the optimize procedure successively invokes the following components: the parser, the plan enumerator, and the cost estimator (see Sec. 3). The user can then retrieve information such as the total number of explored plans and the chosen plan.
Expressivity scenario In the second scenario, we focus on the expressive power of queries supported by the system. This scenario focuses on two key aspects: (i) An erroneous statement of  [15]  states that 𝜇-RA cannot express (𝑎𝑏𝑐 (𝑑𝑏𝑐) * )+. This statement is wrong because the query corresponds to a regular path query, hence trivially supported in 𝜇-RA. For example, 𝑎𝑏 * stands for 𝑎|𝑎𝑏+. Hence, (𝑎𝑏𝑐 (𝑑𝑏𝑐) * )+ can be simply expressed as (𝑎𝑏𝑐 |𝑎𝑏𝑐 (𝑑𝑏𝑐)+)+. We further explain using a concrete example why the statement is not true by writing and evaluating a query of this form over the Yago dataset. We use the query :  We also describe how this query is optimized in the 𝜇-RA system. The optimized term is sent to PostgreSQL and evaluted in 0. 6 seconds on a commodity laptop. Note that the query given in  [15]  and query Q cannot be expressed in Cypher 9 language  [11].
(ii) 𝜇-RA supports some queries with particular non-regular forms of recursion 2 , currently not supported in  [15]. An example of a supported non-regular query pattern is 𝑎 𝑛 𝑏 𝑛 , that returns the pairs of nodes connected by a path composed of a number of edges labeled 𝑎 followed by the same number of edges labeled 𝑏. We can express a query of this form on wikitree  [9] , a well-known genealogy dataset. We propose a query that retrieves pairs of people that are of the same generation (which is a special case of 𝑎 𝑛 𝑏 𝑛 ). This query can be written in 𝜇-RA  [12]  syntax as follows: Figure  6  shows the plan space explored when this query is processed by the plan enumerator of the 𝜇-RA system.
Performance comparison scenario In this scenario, we focus on the performance gains brought in practice. For this purpose, we consider a recent state-of-the-art system: MilleniumDB  [20]. We assess the two systems on a common set of third-party queries over the public Yago dataset. Furthermore, 2 going beyond the expressive power of regular patterns and UCRPQs in particular. to evaluate the impact of the 𝜇-RA optimizer, we also disable it and compare with the evaluation times obtained with a plain-vanilla PostgreSQL that receives a (non-optimized) translation of the initial query (see the black and red arrows in Figure  1 ). We evaluate 7 queries (Q1-Q7) taken from  [1]  and 2 queries (Q8-Q9) taken from  [21] , on 𝜇-RA, MilleniumDB (MDB) and PostgreSQL. Results are shown in Figure  7. 𝜇-RA outperforms clearly the other two systems.
2021)  La cartographie réalisée est multidisciplinaire, elle vise à rendre compte de l'ensemble des activités éditoriales. Le travail se démarque, car les données ne sont pas issues d'enquêtes mais directement des sites web des revues, mises à disposition par le récent outil OpenEditors (openeditors. ooir. org). Cette méthode, enrichie manuellement, permet d'avoir une vue globale à l'échelle de l'université ; elle inclut par exemple les activités d'édition en santé, là où les enjeux économiques sont importants, ou encore les liens entre sociétés savantes et publishers commerciaux. Le périmètre est celui d'Université Paris Cité, multidisciplinaire, lauréate en 2018 de l'Initiative Excellence (IdEx, ANR-18-IDEX-0001). « UPCité » recouvre environ 130 unités de recherche, 4 500 chercheurs et 16 000 publications scientifiques annuelles.
Du bruit dans les affiliations Affiliation data used to link outputs to institutions has limitations and biases. This is true of any dataset  (Diprose et al. 2023)  La porte d'entrée pour identifier les revues est directement l'affiliation mentionnée dans les comités éditoriaux. Dès lors, la méthode se confronte inévitablement au récurrent problème français du « mille-feuille des affiliations »  (Pontille et al. 2016) , lequel produit du désordre dans les affiliations. Pour l'illustrer brièvement précisons (i) que le champ pour renseigner l'affiliation est un champ libre, côté auteur comme éditeur, et (ii) que les remous incessants entre unité de recherche et tutelles provoquent de fortes ambiguïtés. À titre d'exemple, voici quelques variations pour l'unité Géographie Cité : Aussi, le reviewing pouvant se faire occasionnellement en tant qu'expert -au fond, l'activité serait plutôt à tracer au niveau des publications et non des revues -et, de surcroît, afin d'éviter des biais entre domaines et plateformes, l'activité n'a pas été retenue.
Cet article aborde le problème de l'ordonnancement des actions portants sur les effecteurs d'un habitat intelligent. Le déclanchement de ces actions peut être demandé par les habitants ou des programmes gérant des automatismes. Nous montrons que ce problème est complexe et ne peut être résolu a priori car il dépend du contexte. Nous défendons l'idée que le problème doit être abordé sous l'angle d'un système d'exploitation dont le moteur d'ordonnancement pourrait être basé sur le langage CCBL (Cascading Contexts Based Language). CCBL est un langage de programmation pour utilisateur finaux de l'habitat. Il permet de coder des automatismes basés sur les appareils et services de l'habitat. Nous donnons plusieurs exemples de stratégies d'ordonnancement programmées avec CCBL et montrons que programmer de telles stratégies n'est pas fondamentalement différent que d'utiliser CCBL pour programmer des automatismes.
) et les acteurs logiciels (les programmes). Dans certains contextes, différents acteurs peuvent vouloir appliquer des commandes différentes aux mêmes appareils ou services. Par exemple, un acteur humain et un des programmes qu'il a installés peuvent vouloir agir sur le chauffage ; l'humain pour augmenter la température (car il reçoit des invités à l'improviste) et le programme thermostat pour la baisser  [25]. Le résultat de ces différences est un comportement erratique et insatisfaisant de l'habitat. La problématique que nous abordons dans cet article est celle de l'ordonnancement de l'accès aux commandes par ces différents acteurs. Nous proposons d'aborder ce problème sous l'angle du Développements par l'Utilisateur Final (DUF, ou EUD en anglais) (cf. [5] ) et présentons comment le langage CCBL (Cascading Contexts Based Language)  [21, 22]  peut être utilisé pour exprimer la priorité entre ces acteurs selon le contexte.
La commande directe La forme la plus directe pour un habitant de faire réagir l'habitat en fonction de ses besoins est d'utiliser une interface pour commander les appareils et services de l'habitat. Différentes solutions d'interactions sont proposées. La plus courante, offerte par toutes les boxes domotiques, est de contrôler directement les appareils et services à l'aide de télécommandes logicielles graphiques. Les assistants comme Google Home ou Amazon Alexa permettent quant à eux d'utiliser des commandes vocales. Enfin, il existe des solutions de télécommandes physiques dédiées, comme celle proposée par  [23]  ou par Sevenhugs (2) , qui permettent de piloter les appareils en les pointant. De nombreuses solutions permettent l'accès aux appareils au sein de l'habitat ou à distance. Le scénario 1 (Table  2.
Cascading Context Based Language (CCBL) CCBL est un langage de programmation pour utilisateurs finaux (c'est-à-dire non informaticien) conçu pour les habitats intelligents et plus généralement les environnements intelligents à petite échelle comme un appartement, une maison ou un bureau  [21, 22]. Dans cet article, nous donnons une description plus détaillée du langage CCBL et introduisons la notion de programmes. CCBL a été développé pour combler les lacunes d'ECA (Event Conditions Actions) qui, bien qu'étant le paradigme de programmation dominant dans les habitats intelligents  (Demeure et al. , 2015) , introduit des difficultés de programmation pour les non-informaticiens  [15, 22]. Le domaine d'application de CCBL ainsi que son usage des contextes et relations d'Allen permet de le rapprocher du langage de description d'état proposé par  [24].
Ces programmes peuvent être écrits en CCBL (à l'aide de contextes, de canaux, etc. ) ou dans un autre langage (en fournissant une API compatible). Ils peuvent, en conséquence, proposer une implémentation quelconque, par exemple basée sur de l'apprentissage automatique. Une autre possibilité est que le programme soit une télécommande (graphique, vocale ou autre) permettant à l'utilisateur de contrôler des appareils et des services via des canaux, émetteurs et événements CCBL. De cette façon, l'interaction par commande directe se trouve intégrée au système de façon similaire aux autres programmes. La figure 3. 5 reprend l'exemple du contrôle du volume sonore de la chaîne hifi décrit dans la figure  3. 1 en y ajoutant un programme lié à une télécommande logicielle fonctionnant sur un smartphone.
Implémentation et premiers retours sur CCBL Nous avons implémenté un interpréteur CCBL dans le langage TypeScript (5) et avons publié la bibliothèque correspondante sur GitHub (6). Les exemples d'ordonnancement présentés dans cet article ont été implémenté et testés sur des environnements simulés. L'objectif n'est cependant pas de populariser CCBL tel quel. Nous travaillons sur un éditeur graphique du langage qui est encore en phase de développement. Nous avons voulu tester auprès d'utilisateur (programmeurs et non programmeurs) si la logique sous-jacente à CCBL était bien comprise, en particulier les notions de contexte et de cascade. Nous avons pour cela réaliser une expérimentation dont les résultats sont présentés dans  [22]. L'objectif de cette étude était de vérifier si les utilisateurs pouvaient utiliser aussi facilement CCBL qu'un langage de type ECA (qui est la forme de langage dominante pour programmer l'habitat).
Toutefois, il est possible que cette notion d'objectivité soit limitée et qu'il faille considérer d'autres aspects de ces dessins (au-delà du fait qu'ils sont tracés par un sujet individuel et pas par un appareil impersonnel). Nous verrons comment cet exemple peut être considéré comme un cas d'objectivité disciplinaire. En effet, l'hypothèse de Lopes est que les dessins, comparés aux photographies, sont davantage capables de capturer les données reconnues comme pertinentes. L'étude des artefacts se base sur des informations précises. Ces informations doivent donc apparaître dans les images. Le néophyte croit naïvement qu'il lui suffit de regarder ces images pour voir l'information qu'elles contiennent. Toutefois, ces images ne sont pas simplement regardées, mais à proprement parler lues, comme si elles étaient une base de données.
Remerciements Nous remercions  Catherine Allamel-Raffin ,  Anouk Barberousse et Amirouche Moktefi , pour leurs commentaires à la première version de cet article. Cette recherche était financée par le Septième Programme Cadre  de la Communauté Européenne  sous une  Marie Curie Intra-European Fellowship for Career Development , numéro de contrat  220686-DRB  (Diagram-based Reasoning).
Dans l'Histoire des traductions en langue française. XIX e siècle, Wilfert-Portal consacre presque cent pages à la traduction d'ouvrages de fiction pour montrer leur place mineure dans la production éditoriale française  (Wilfert-Portal 2012, 255-344). Partant du constat que la traduction se spécifie d'être publiée avant toute considération esthétique ou traductologique Wilfert-Portal et Guérin ont créé la base « Intraduction. Traduire en français, 18 e -19 e siècle » à partir des volumes 1 à 27 du Catalogue général de la librairie française rassemblant des notices bibliographiques des ouvrages publiés entre 1840 et 1915. Pour importante dans l'histoire littéraire et bibliométrique que soit cette base de données qui n'a pas été étendue à d'autres époques ou aires linguistiques (Wilfert-Portal et Guérin 2012, 49-63) 3 , elle masque les traductions parues en périodiques, lesquelles sont plus difficilement repérables.
Si la traduction relève de la publication, de l'imprimé, seul le secteur du livre semble susciter l'intérêt bien que dans un article plus récent, Wilfert-Portal évoque enfin la traduction de la littérature étrangère dans les revues  (Wilfert-Portal, 2018, 261-84). Si la base de données « Petite presse »  (Vaillant, sd)  ne semble plus accessible, le projet PRELIA (Petites Revues littéraires et artistiques) dirigé par Schuh dédié à l'étude des petits médias entre 1870 et 1940, dépouille partiellement 51 titres dont La Vogue, L'Ermitage et Le Mercure, La revue blanche, Vers et Prose, en se concentrant sur les textes littéraires et sans présenter les traductions. La traduction en périodique apparaît comme un point aveugle de la recherche alors que la lecture attentive de nombreux périodiques témoigne de sa présence et d'une part qu'il faut évaluer plus précisément.
Une histoire littéraire plus hybride et plus complexe s'en dégage. À cette fin, Caroline Crépiat, post-doctorante à l'Université de Bourgogne en 2019-20, Arnaud Millereux (ASI, MSH, Université de Bourgogne), et moi-même avons développé la « Décabase »  (Coste, Crépiat, Millereux, 2019/). Cette base de données (decabase. u-bourgogne. fr) recense les traductions de poésie décadente britannique en français dans 10 revues entre 1880 et 1914. Nous entendons la Décadence littéraire comme un phénomène culturel transnational critique de la modernité, principalement marqué à partir de la seconde moitié du dix-neuvième siècle et trouvant son origine en France à travers les figures de Gautier, Baudelaire, Huysmans. Cette définition relativement large est à implicitement l'oeuvre chez les poètes britanniques dits décadents : Ernest Dowson, John Gray, Lionel Johnson, Oscar Wilde, (le jeune) W.