dataesr/scientific-paragraphs-categorization huggingface dataset:
We are allowing two different isolation modes. First, one is another instance of Cesium aimed toward visual fidelity, by means of high resolution meshes optimized for web display (glTF 2. 0 with hierarchical LOD), and temporal visualization for which a slider is available and allows users to observe data evolution over time (for example, excavation progress). Second, one is built from Potree, another JavaScript library for massive point cloud visualization, and is subtitled "metrological instance". The subtlety at play here is that we are now only working with point clouds. As a raw byproduct of any 3D acquisition, point clouds are as accurate as the acquisition itself, but the process of 3D surface reconstruction is inherently degrading spatial information by skipping points or by creating intermediary points as a/the vertex: "The goal of surface reconstruction can be stated as follows: given a set of sample points P assumed to lie on or near an unknown surface S, create a surface model S' approximating S.
A surface reconstruction procedure cannot guarantee the recovering of S exactly"  [Remondino 2003 ]. Most of the generic tools, which include measurement tools, are available through the "metrological instance". Most data-management requirements are inherited from the joint use of Cesium and Potree. Vectors are formatted as JSON or directly as CZML, which is a specific variation of JSON standard. Imagery, either tiled (WMS, TMS, etc. ) or untiled, is usually served as PNG. Point clouds can undergo a different type of conversion and indexing depending on the situation. For small to medium data sets, LAZ format  [Isenburg 2013 ] will be preferred for Potree, whereas PNT format  [Lilley et al. 2017] , based on JSON standard, will be used with Cesium. For massive data sets, both Cesium and Potree require a specific indexing, namely entwine  [Manning 2017 ], with help from an auxiliary streaming server named Greyhound.
Finally, complex 3D models are served as glTF 2. 0. The glTF standard is promoted as the "JPEG of 3D" by the Consortium Khronos Group (including Intel, NVIDIA, Google, Sony, Apple, Samsung, IBM). A glTF asset is constituted by a JSON file (node hierarchy, cameras, materials), binary files (geometry, animation, etc. ) and JPG or PNG files  [Trevett 2017 ]. From a back-end perspective, we are willingly pushing open-source format, but the amount of work dedicated to achieve that goal can vary extensively, depending on the existing workflow and data-management behind different projects. More often than not, it can prove to be a bit chaotic in archaeology. We are also suggesting the use of PostgreSQL databases with a PostGIS extension. Some people are also looking into NoSQL databases such as Apache Couch, but it seems that spatial index extensions like Geocouch are not advisable yet in terms of performance.
For the past few years, the amount of digital data produced annually has become so extensive that the research center's capacity to manage and exploit this information influx is dangerously close to becoming congested, impacting, as a consequence, the pace of scientific publication. This situation illustrates clearly some issues and concerns expressed in the introduction. Consequently, in the course of 2017, Bibracte engaged a new program for digital equipment and digital tools development: Bibracte numérique (BibNum). BibNum is aimed toward a wide scope of users. Indeed, professional archaeologists are concerned but also a broad variety of specialists and researchers linked to ongoing projects, students, and, more subtly, the general public. Synergy between BibNum and Aspectus arises from the joint philosophy of both projects: in light of an integrated approach, we are   INRAP).
Musings on future directions While the PC2 2017 case study was compelling, Aspectus was only implemented for testing. Our goals were first to evaluate the robustness of our 3D visualization system and second to assess the workload required to process a great variety of heterogeneous data sets that were not optimized at all to fit in our pipeline. We had to bring together some of the previous recording (raster maps, various GIS datasets and LiDAR) with the new comprehensive photogrammetric recording of PC2. The "hub" gave access to a multi-resolution terrain model derived from LiDAR data with an overlay of highresolution satellite imagery or a hillshade raster. On top of it, we displayed multiple JSON (past excavation, recent excavation and interpretation) extruded in 3D with contextual information and multi-resolution mesh of our PC2 excavation (Fig.
Moving from a "dirty" shapefile to a "clean" JSON can prove really time consuming. By "clean", we mean retaining a clear and efficient structure for storing geometry, appearance and attributes in accordance with the JSON standard. Attributes were in this case hardcoded inside the data itself, since no global database was operational at the moment. As a side note, shapefiles with z-values were difficult to manage because it seems that Agisoft Photoscan is unable to close geometry when people are directly drawing over photogrammetry. It must also be noted that the pipeline (Cesium Terrain Builder) to produce a high-quality multi-resolution terrain model from a digital elevation model (DEM), in our case LiDAR data, is challenging, to say the least. Native 3D information data sets, in the form of point clouds, were clearly easier to interact with, both in terms of initial processing and multi-resolution mesh generation.
Besides, there is still lot of room for improvement on the script side. We are also looking forward to strengthening synergy between different software blocks. For instance, Potree main developer M. Schuetz is currently trying to allow Potree to be displayed on top of Cesium. This could prove to be a major enhancement, since point cloud display with 3DTiles is now relatively limited both in terms of performance and customization. Potree is also convincing when it comes to drawing in 3D over existing point cloud data. That new layer of user-made data, produced with Potree and stored in JSON, will then be available for display either in Potree or Cesium. It has become clear to us that JSON should be used directly in Cesium for small datasets, like user "drawing", but they must systematically be converted as 3DTiles as soon as they get more sizeable.
CLOSING THOUGHTS The increasing digitization efforts within the field of archaeology, and more generally cultural heritage, requires strategies for managing and serving an inordinate amount of 3D data to a broad array of researchers and an even broader public audience. At present, we are facing a vastly compartmentalized market and we recognize the lack of a comprehensive software solution that encompass multiple complementary approaches: high quality 3D web visualization, data analysis and annotation tools, and an online workplace platform. In other words, making complex 3D data accessible and prone to analysis in a collaborative environment. We are trying to close this gap with Aspectus but we are still at an early stage of development. A robust theoretical framework has been set with multiple cornerstones in mind: ease of access and collaboration incentives, flexibility, and preservation of the information context through the use of spatial data.
Most of our efforts were directed toward the latter. What blocks do we choose to efficiently display the information and how do we manage the information that we feed to those blocks Both Augustodunum and Bibracte were proving grounds in this regard. Cesium and Potree proved to have great synergy and to be complementary in terms of visualization and interactions. They also provide great flexibility for a project with such a small team of archaeologists behind it and almost no funding. This is also why the former cornerstone, collaboration, is still lagging behind. Therefore, we are relying on partnership to move forward and, recently, we have been discussing the possibility of creating a bridge with the above-mentioned Aioli project. They would benefit from contextualization and spatialized information whereas we would learn a lot from their multi-layer data annotation tool.
The creation of the Artist Libraries Project was sparked by the observation that artist libraries are still not well known, yet many art historians are interested in this archive for the value it adds to understanding the person behind the artist and his or her creative process. The problem is that these libraries are rarely physically preserved. To remedy this dispersion, we built an online database and a website www. lesbibliothequesdartistes. org that house this valuable source in the form of lists of books and their electronic versions. First data on Monet's library have been made available, and several additional artist libraries from the 19 th and 20 th centuries are on the way for 2019. By gathering all these bibliographical data in a central database, it's possible to explore one library and to compare several.
I CONTEXT The Artist Libraries Project 1 has been initiated by Ségolène Le Men within a larger project about 'dialectical images, imaginary museums, and virtual museums' which was selected in 2014 by the labex Les Passés dans le présent at Université Paris Nanterre (research team HAR histoire des arts et des représentations). The author has been in charge of its development since 2016. The project started with a challenging case study, asserting that Monet's library offered a source which showed that his art went beyond optical issues 2. Following the famous sentence of Cezanne, Monet ce n'est qu'un oeil mais bon dieu quel oeil!  1  The project is conducted in the framework of the Labex Pasts in the Present and has therefore benefited from the state aid managed by the ANR under the Investissements d'avenir program with the reference ANR-11-LABX-0026-01.
Such research is mostly conducted individually by researchers who adopt a monographic approach: a researcher interested in an artist finds his library and decides to study it as a new source to learn more about his personality or his work. Those lists of books are thus disseminated in monographic studies, published or unpublished academic works, articles, inventories of libraries. One of the major challenges of this project is to remedy this dispersion. To achieve this, digital technology, i. e. the creation of an online database, has appeared the best option, for several reasons. It makes it possible to handle large amounts of data, to cross-search by artist, work, author. , to enrich data thanks to interoperability and to browse digital versions. Several institutions keep artists' libraries but they are not distinguished as a separate fund.
That's why the reader can not easily identify and find them. By putting online not only a cartography of these libraries but also the inventory of the works they contain, this digital project gives an unprecedented access to an essential source of art history. Since 2015, the project is led at Paris Nanterre University by the Labex Pasts in the Present and the research team History of arts and representations, and conducted under the direction of Ségolène Le Men. The website www. lesbibliothequesdartistes. org was launched in Jan 2018 to house lists of works and electronic versions of works. First data on Monet's library were made available, and several additional artist libraries from the 19 th and 20 th centuries are on the way for 2019. By gathering all these bibliographical data in a central database, it's possible to explore one library and to compare several.
III CHALLENGES OF DIGITAL LIBRARY PROCESSING Whether genetic, iconographic or textual, whether monographic or global and contextual, there are many approaches to studying artists' libraries. Digital humanities are another way to enlighten the richness of this resource. The Artist Libraries Project is also characterized by interdisciplinarity, as it compels art historians, literary historians and curators working together to make accessible to researchers and the general public not only the lists of the publications in artists' libraries from the 19 th and 20 th centuries but also their digital version. The goal of the Artist Libraries Project is to build a database that contains the bibliographical information of each booki. e. editing, illustrations, annotations, dedication pages, placement on the shelf.
Their mere presence, and sometimes the annotations of price or handwritten notes they contain, reveals the sensibility of an artist. In the sales catalog of Degas's collection in 1918  17  , Monet had written the auction price of a painting by El Greco and Delacroix, thus leaving a hint of his artistic tastes. Publishing artists' libraries online satisfies above all a need for accessibility. Lists of books are thus no longer limited to the print edition but are accessible to everyone and everywhere. Database techniques facilitate search queries and comparison. Thanks to the database technology, we the analyses move from the monographic approach to the comparative one. According to Le dictionnaire de l'École nationale supérieure des sciences de l'information et des bibliothèques, "Digital libraries offer real digital collections, according to a defined documentary policy.
IV IDENTIFYING THE TOOLS One of the contributions of the digital humanities is the strengthening of the link between the tool and its use. Indeed, the search for suitable digital tools requires in-depth reflection on the objective of a given study. Moreover, building the database architecture involves questioning the nature of its corpus, its characteristics and its limits. An effort to define these elements must be the first step of such a project. What kind of documents are we processing? Transcribed texts, digitized texts, photographies, maps, plans, video material, audio material. Where do they come from? Who will consult them? Is the database likely to evolve or is it static? Should the database be interoperable? Is there an indexing vocabulary to describe our data? Is it a homogeneous or heterogeneous corpus? etc.
In our case, the corpus is simultaneously open and close. Open because we don't know yet all the libraries we will integrate into the database but close because it will always be bibliographical data: on the one hand, bibliographic records of the books of each artist's library, which mentions the transcription of handwritten dedications and all characteristics of a copy and, on the other hand, the bibliographical description of the digitized version of the books. Built on Monet's case, the digital tool as part of the Artist Libraries Project has to be reliable enough to support a large number of libraries but also flexible enough to adapt to the specificities of each. Our database is built on qualified Dublin Core vocabulary 21 , a descriptive format that initially included fifteen fields to describe any type of document.
Created in 1995, the Dublin Core has now been extended to fifty-five descriptive fields. The use of this standard makes the system interoperable, i. e. the bibliographic records we create can be retrieved by other systems and conversely, records created by other libraries can be retrieved. We also use RAMEAU indexation language 22 to describe the books. To give access to digital books, we choose not to scan or host the books stored in the libraries because they are often common books which are already digitalized by numerous projects such as www. gallica. bnf. fr or www. openlibrary. org. Moreover, systematic digitalization as part of an academic project is often too expensive. We recovered the digital books mostly via exportable readers. On the contrary, we will photograph the marks that individualize the copy (handwritten dedication, notes, erasures, bookmarks…) and make them accessible on the website.
Many require payment while some are free. After a long search for the most suitable management tool for the Artist Libraries Project, the choice was made to use the free software Omeka, developed by the Roy Rosenzweig Center for History and New Media at George Mason University (Fairfax, VA), which meets many of our criteria  24. Omeka is a Content Management System (CMS), a web publishing platform which manages digital contentin our case bibliographic records, linked to the digitized version of books. These data are organized by collectionseach a different libraryand we can consult them by list or via a search engine. While it performs the two functions, data management and dissemination remain well separated. The design or the different features can evolve or even change completely, and the content is not compromised.
Omeka also has the advantage of being built on Dublin Core vocabulary. In addition to being free, open-source software benefits from a large community of users who run blogs, post tutorials online and respond via forums to technical problems that may arise. Apart from the question of content management, there is also the issue of data dissemination, since the central challenge is to make this valuable resource accessible. It is therefore necessary to design a user-friendly search function and consultation interface. For this purpose we must first ask ourselves, who will be our public? Do we target a very specialized research audience or a wider audience? The underlying question, which is particularly relevant in today's research world, is that of valorization. The tools and discourses must be adapted to the intended audiences.
The libraries are classified by types (material founds, reconstituted, from inventory or sales catalogs). Thanks to the various tools (the plug-in) it offers, Omeka is a very adaptable CMS that can support these different goals. Alongside the database and its connected visualization tools, the project functions as an entire website. A second step has consisted of checking this list of works against those kept at the Bibliothèque nationale de France and already digitized on Gallica. If they are not, the aim is to include these books in its digitization process. This phase has required more time than expected. This is partly due to the nature of the works kept in Monet's library. A large part of these books are best-selling publications of the time, which were subsequently reprinted or reissues many times, sometimes in close succession.
Because we want to know what the artist actually read and saw, we normally consider only the right edition. But it is also important that the user can at least read the text. That's why, when the right digital version doesn't exist, we give access to an approximated edition. The most important issue is to clarify each case: is the digital version exactly the same as the one the artist had, or an approximate version? The time needed to achieve this work is also due to technical reasons. Because of the accuracy we need in our bibliographical matching between our primary resource and the digital version, it was not possible to know automatically if Monet's books were already digitized by Gallica. We had to check all 900 books manually 27  ! After cleaning data and choosing digital tools, the project then entered the implementation phase.
All of Monet's books are now available online. In addition to its obvious scientific intrigue, this first case study was used to test and validate the choices we made, to be able to apply them to other libraries and other artists, whether painters, sculptors, architects, etc. The choice of Monet offers many advantages: first the amounts of books. 900 are enough to test the digital tools on a large scale but not too much when you have to correct some bugs. Our knowledge of the subject was an asset too. Because if we built a general database in which every library can be catalog, each one is in fact specific. For that reason, Monet's library was not a good choice for the question of reading marks. Monet almost never annotated his books. If we have still taken in account this crucial aspect of a private library, we have never managed it in the full magnitude it can have.
VI THE PROJECT IN THE FUTURE The shift from a monographic scale to a global scale will create the right conditions for developing analytical and critical thinking about artists' libraries, both considered as an entity in its own right and as a set of independent objects, themselves composed of pages sometimes annotated and illustrated. By comparing the libraries, the goal is no longer only to reveal the reader's portrait behind that of the artist, his interactions with the cultural sphere of his time and past, and a part of his creative process, but also the cultural environment of a time. To achieve this goal we are currently working on libraries of other impressionists. It is a longterm job because no other, except that of Monet, is materialy kept. In the mean-time, the choice of the next library to be included in the database is partly pragmatic.
One of the next libraries is the one of the painter Edouard Detaille (1848-1912). His library is known thanks to a sales catalog, kept in the National Labray of France 28. If his aesthetic is far from that of the impressionists, our first research shows that some readings are common. This first comparison proves that through the study of libraries we will certainly discover the importance of a shared culture well beyond the traditional division established by art history. It is the same logic that drives us to take an interest in the library of the sculptor Antoine Bourdelle (1861-1929). We will also open a new contemporary field with the libraries of Hans Hartung (1904-1989) and his also painter wife Anna-Eva Bergman (1909-1987) and the sculptors Alberto Giacometti (1901-1966). At the end of 2019, those libraries will be included in the database and disclosed on the website.
We also continue to fuel the map. The developments envisaged are not only about resources but also technique. Today we have two options to integrate a new library: either book by book by the Dublin Core form in omeka back office or massively via a CSV file. This second option is much faster. When we work with a partner institution, we firstly fill their database, then we extracts the data in excel format, works on the spreadsheet to adapt it to the project standards and finally integrate the data to our database. The next step is to use the interoperability to retrieve the data automatically, when the inventory is already done. Omeka-S, the newest version of the software could be effective because it supports web semantic languages. The other major works in progress is on the illustrations contained in the books.
Originally, one of the project goals was to discover a lesser known part of the artists' musée imaginaire built on those illustrations. We wanted to identify all of these illustrations. There are far too many of them to do manually. We thought that it would be quite easy by working on the digital versions. But when Gallica scans the books, they don't differentiate between text and picture. That's why it is impossible at this time to process automatically. The question of automatic recognition is a topical interest at the BnF so that we can hope that this will be developed soon. It may also be interesting to set up customization, i. e. the user can organize and structure the data in his own way. This would allow them to create their own thematic library, take notes or directly annotate the works, and then share the results.
Acknowledgments The authors wish to thank  Renaud Jardri  and  Frank Laroi  for organizing the  International Consortium for Hallucination Research, in Lille, France , November 6-8, 2017, where this review was presented. The authors also wish to thank  Sarah Kamens ,  Angela Woods , and other commenters for their valuable feedback on previous drafts of this work. None of the authors has any conflicts of interest related to this work.