 So hello, sorry I'm not fluent in English so I will read my notes. I will talk about matching work between tables coming from different field recording systems used in archaeological, preventive archaeology. After a quick presentation of the context of field recording system in RAP, I will present the steps of these two work done on two major databases, EDARC and Klavier. It's therefore a question of explaining models of the tables of these databases. Then the translation that was made on the 16 mapping of these models. And we will insist in the end on the programs on countered and resulting proposals. In RAP, National Institute of Preventive Archaeological Research is a public institution under the supervision of the French Ministry of Research and the Ministry of Culture and Communication. Archaeologists had to make a diagnostic test before a development work of the territory and then excavate land reach in archaeological remains before destruction. Currently several different field recording systems are used by archaeologists. Four of them have been selected for this work. BDA, Archaeological Database, CADOC, Archaeological Site and Documentation, SISLAT, a field system developed as part of a school excavation site in the south of France and spreadsheets created by different archaeologists or specialists. A comparative study has been carried out between these different systems. Actually with a few exceptions all of them deal with the same entities since archaeology is based on common protocols. The scientific and technical department of the institute has therefore developed a database design to provide an answer to heterogeneity of data models and various systems. It's EDARC, Archaeological Data Resistration. EDARC has been taught to be used in different contexts and across various data. It uses an internet browser but never requires access to a connection. The data record is stored in a local SQLite database which allows interfacing into a GIS software and data is exported in XML format. In EDARC even main tables have been chosen. Those that describe archaeological data, the tables operation, metadata, trends, survey, stratigraphic unit, fact, archaeological site, sampling, object, design and photo. These tables give information about history of the archaeological site, the document. They give information of the metadata of archaeological operation and its database. They give information on the raw data direct on the site and on the data interpreted by archaeologists. Taking into account time and our ongoing training in this area, it was decided to carry out mapping using the CEDOC CRM common ontology. And since archaeology is essentially specialized, we want to use CRM archaeology, CRM georextensions. And we use also the CRM SRA extension in order to characterize metadata. As you can see on the screen, the data physical model was realized thanks to the 3M software developed by the Forth Institute. The 11 tables were mapped by defined first entities as entrance of over domain property range triplets. We also wanted to have a look of fields of attribute tables on the three main spatial layers of data produced for each archaeological sites and operations. In this case, it's data of a medieval site located in the city of Le Mans. It is a diagnostic operation at a place near to the gardens of the cathedral. Since 2013, the systematization of the use of a gy... sorry... allows to constitute a catalog of the spatial data produced by the institute. Its name is Kavya. The main layers of each operations are gathered in a post-gest, post-gray SQL server and constitute the main data of the catalog. Perimeters are a surface which are to be investigated by an operator or another. The second one is dragging or opening that is to say survey or trends. And archaeological observations especially represented with polygons. Like EDARC, the input entities are E25 main features for the shape of remands. SP6 declarative place difference spatial entities. The shape opening specified in E27 site and the shape perimeter specified in A1 excavated process unit. In 3M, link can be made to the maze application which allows to visualize the analysis of mapping and to obtain graphs. Here we can observe graphs from the mapping of EDARC database and of 3M shapefights from Kavya. For each of tables, we respect the association with the input entities associated with each table explained previously and also between different other mapping in order to respect the meaning associated with each entity. And especially the most difficult thing was this choice of the first entity as input. Behind formalisms of Psydox ERN, there is existence of a variety of users and of semantic possibilities through extensions. For the mapping of the metadata for example here, I referred to the entity of E7 activity since metadata are related to preventive archaeological activity. However, some of them characterize the technical support itself, that is to say EDARC database. George Bruce Kerr, who is aware with the Psydox dig extension, used it as input and chose the entity D1 digital object. We both get a given price. Therefore, we wondered about the relevance of different mapping that is possible to produce and about important role to choose the first entity. This same observation appeared during the mapping of the operation table. In the first case, my colleague Christophe Tiffery chose the entity E7 activity. After knowing extension, I hope for the entity EFT 53 place since it offered a better declination of the subject of archaeological operation with the CRM, Gero and RQ. Indeed, the fact is that an ontology functions as a tetherless. Also, a large part of this study was dedicated to the appropriation of the nested triplet domain property range. I really want to understand links with properties to get closer to the primary meaning of each field database. In my opinion, final entities will take more meaning if we specified characteristics and domains to which they refer. Here, for example, A1 excavation process unit and SP3 reference space. All table sections have been explained and I want to emphasize the richness that allows both to describe sources, rights, name, locations, persons and the fact of dating remains that it is, sorry, which is essential in archaeology. The only drawback remain expression of uncertainty, what we are called estimated dates. But I'm not sure about the association I made to express the difference between estimated and certain date. I introduce the entity of E2 temporal entity before the traditional E52 time spline. Linked to the subject of archaeological observation and interpretation of extents, symbols and objects, I would like to stress the importance of choosing the CRM SCI extension in the presence of the entities S for observation and S6 data evaluation. Regarding mapping of shapefiles, I treat them as the same way of their database counterparts. I focus on disturbing space. Here, for example, the reference entity is SP6 declarative place. Usual references follow to archaeology, to interpretation, to document and to over spatial references. The only difference is, and not the least, the possibility to referring to the W, KT, the well-known text format through the CRM Geo. Associated with attribute table of shapefiles, this is a standard text format that stores information such as coordinate system reference, geometry type, and maximum extents of vector geometric object. I would like to talk about a fact of expression type of things. When previous entity is clearly defined such as A8 stratigraphic unit or E22 main object, entities like E55 type or E17 type assignment are good enough. But as part of the description of dimension, measurements, shape, and orientation for trenches or objects, these entities are not precise enough, and there are no refined properties. Also, as these categories are used by any researchers, could we consider the possibility of creation over entities inside of CRM for lengths, widths, or depth, or in the CRM Geo for forms or orientations? Yes, I'll see. Two minutes. An over point. And certainty type, it's a recurrent subject in archaeology because they are depending on the context of search. Data are often incomplete and can be difficult to interpret. Also, in terms of uncertainty related to the interpretation of women's types, US, or facts, how to express it. Could we also create new entities? I use S9 property type here associated to comment of unsung term type, but it doesn't account to initial semantics. Last problem, and at the least in archaeology, the one refers to relative chronology. At least three items, structure, stratigraphic diagrams. US section correctly described and two over items, US on it and US above it. Even if there's a lot of property which could make it possible to move throughout this, it appears that triplets domain range type still remain the same. In conclusion, the different observations and requirements mentioned to begin, let us recall the interests of the choice of the main entity. It's important to explain all the main sections, then what is fundamental for realization of mapping. Technical support, database, or geo databases, activity that describes it, or discipline that causes. Then we saw that it was difficult to get as close as possible to the primary meaning of the field table names. So how to preserve a best semantic difference emitted by community of archaeology. For example, and by following when we want to associate a type of category, like E55 type before in, is the S9 property type of the CRM SCI still not too general. In addition, we consider development of specific entities in PsyDoc CRM or in extensions related to dimensions types. Similarly, for CRM archaeo, questions still the same about stratigraphic relationships. Finally, is attribute data linked to spatial layers must be directly related to spatial phenomena like spatial extent resolutions coordinates through CRM zero or must they be defined compare their technical support and the use of extensions like CRM SCI or CRM DIC. The project will be in the next months to redo mapping of these three shapefiles by using the CRM DIC to observe if mapping starting with an entity such as the D1 digital object could be linked to CRM zero entities. And it's the real conclusion. To clarify and advance on these topics, it's also considered to redo the mapping of metadata table using CRM DIC extension and to apply it to each metadata on other tables. I also hope that our colleagues will be able to join these projects in order to compare several mapping and especially to generate genuine realises to carrier and to over interrupt the databases. And later it will be time to develop a script to follow the proper exploitation and interrogation of archaeological data present in these databases. Thank you for your attention. Thank you.