dataesr/scientific-paragraphs-categorization huggingface dataset:
nih. gov/bioproject/ PRJNA384940 nih. gov/nuccore/ KT168332 NCBI GenBank Publicly available at (accession no: NCBI Short Read Archive (accession no: KT168332) Heintzman PD, 2017 Mitochondrial genome sequence https://www. ncbi. nlm. PRJNA384940) Publicly available at Heintzman PD, Shapiro B Shapiro B 2017 Mitochondrial genome sequence from YG 303. 371 from YG 404. 662 https://www. ncbi. nlm. nih. gov/nuccore/ KT168317 nih. gov/nuccore/ KT168333 NCBI GenBank Publicly available at (accession no: NCBI GenBank (accession no: KT168333) Heintzman PD, 2017 Mitochondrial genome sequence https://www. ncbi. nlm. KT168317) Publicly available at Heintzman PD, Stil-ler M, Shapiro B Shapiro B 2017 Mitochondrial genome sequence from YG 133. 16 from YG 404. 480 https://www. ncbi. nlm. nih. gov/nuccore/ KT168318 nih.
gov/nuccore/ KT168334 NCBI GenBank Publicly available at (accession no: NCBI GenBank (accession no: KT168334) Heintzman PD, Stil- 2017 Mitochondrial genome sequence https://www. ncbi. nlm. KT168318) Publicly available at Heintzman PD, Shapiro B ler M, Shapiro B 2017 Mitochondrial genome sequence from YG 29. 169 from YG 401. 235 https://www. ncbi. nlm. nih. gov/nuccore/ KT168319 nih. gov/nuccore/ KT168335 NCBI GenBank Publicly available at (accession no: NCBI GenBank (accession no: KT168335) Heintzman PD, 2017 Mitochondrial genome sequence https://www. ncbi. nlm. KT168319) Publicly available at Heintzman PD, Stil-ler M, Shapiro B Shapiro B 2017 Mitochondrial genome sequence from YG 401. 387 from YG 404. 205 https://www. ncbi. nlm. nih. gov/nuccore/ KT168320 nih. gov/nuccore/ KT168336 NCBI GenBank Publicly available at (accession no: NCBI GenBank (accession no: KT168336) Heintzman PD, 2017 Mitochondrial genome sequence https://www.
ncbi. nlm. KT168320) Publicly available at Heintzman PD, Shapiro B Kapp JD, Shapiro B 2017 Mitochondrial genome sequence from YG 404. 663 from LACM(CIT) 109 / 150807 https://www. ncbi. nlm. nih. gov/nuccore/ KT168321 nih. gov/nuccore/ MF134655 NCBI GenBank Publicly available at (accession no: NCBI GenBank (accession no: MF134655) KT168321).
However, subsequent analysis of the high purity polyethylene vials obtained from ActLabs revealed that Br content in the vials was 0. 03 ppm. Thus sample transfer is an unnecessary step except for samples that have Br concentrations near the detection limit. Samples were counted 5 to 6 days after irradiation for 10,000 seconds on a Broad Energy Germanium Detector (Canberra Instruments). Gamma ray energies and peak areas were determined using Genie 2000 software (Canberra Instruments). For Br determinations, the isotope of interest is 82 Br. There are a number of potential analytical gamma ray peaks for this isotope. In our work we used the 554. 35 keV and 776. 52 keV gamma ray peaks which are the most intense peaks in the gamma ray spectrum. If the sample contains W, the third most intense peak, 619.
A C C E P T E D M A N U S C R I P T gamma ray interference will persist throughout the optimum counting window (4-7 days) for 82 Br. The other gamma rays in the 82 Br spectrum yield reasonable results but, because of their lower relative intensities, there is a greater analytical uncertainty associated with these gamma ray energies. Decay, flux and geometry corrections were done using in-house software. Bromine concentrations were determined by reference to the USGS geochemical standard MAG-1. The reported Br content for this sample ranges from 232 to 251 ppm (GeoRem database). We have determined the Br content for this reference standard using a primary standard (DIONEX Combined 7-anion Standard II) which is directly referenced to NIST SRM 3184. Our new value for MAG-1 is 222 ± 3 ppm. This value was used to calculate the Br concentrations in the glasses.
For the measurements described here a beam of approximately 55 µm 2 was used and the analysis time was 120 seconds. The measurements were performed in fluorescence mode (sample at 45 degrees to both the beam and the detector). A nine-element Ortec germanium detector was used. The energy of the beam on the sample was tuned at 15 A C C E P T E D M A N U S C R I P T keV. An aluminium filter in front of the detector ensured reduction of the substantial Fe signal to prevent saturation of the detector and promote Br signal-to-noise ratio. The acquired fluorescence spectra were processed by  PyMca (Sole et al. , 2007) , an open source X-ray Fluorescence Toolkit developed by the Software Group of the European Synchrotron Radiation Facility (ESRF). In the raw spectra, the K-lines of Br in the sample were identified and an iterative peak fitting procedure applied to reveal the net peak areas free of background and interference from other elements.
Laser ablation inductively coupled plasma mass spectrometry (LA-ICP-MS) We We meticulously cleaned the sample cell before and after each analytical session by using a dilute nitric acid solution followed by ethanol or acetone. Each analysis lasted about 2 minutes: one minute of background signal acquisition, followed by ~50 seconds of ablation. Data were collected in time-resolved graphics in order to evaluate signal stability, to detect possible inhomogeneities during the ablation, and to select the most reliable portions of the signal over time. Quantification of Br was achieved by comparing the ratio of Br and Mg signals (in counts per second) measured by the LA-ICP-MS to the nominal content (in ppm) of Br (i. e. , the amount loaded in the capsule). We also performed data reduction using GLITTER™, a software for the laser ablation microprobe, developed by the ARC National Key Centre for Geochemical Evolution and Metallogeny of Continents and Exploration and Mining  (Griffin et al.
order to have a coherent dataset of Br values for all the standards, we use loaded Br values to compare SR-XRF, LA-ICP-MS and SIMS results. Loaded Br contents are initially compared to the signals measured with the three different techniques (Figs. 2, 3, 4). The net peak area after blank subtraction from SR-XRF analyses and 79 Br (cps) / 24 Mg (cps) from LA-ICP-MS analyses are plotted versus nominal values (Figs. 2 and 3, respectively), while the relative sensitivity factor for Br relative to SiO 3 ( 79 Br/SiO 3 ) from SIMS analyses are plotted.
Acknowledgements This work was partly funded by the  "Laboratoire d'Excellence VOLTAIRE" (Université d'Orléans, France)  and by the  ANR-12-JS06-0009-01  project  InterVol. A. C. thanks  J. L. Devidal  ( LMV, Clermont-Ferrand ) for interesting exchanges about LA-ICP-MS Br measurements and for performing some trace element measurements in andesitic and rhyodacitic standard glasses. J. Andujar  ( ISTO, Orléans ) provided the andesitic ( USC-2 ) starting dry glass. A. P. is grateful to  M. Walle  ( ETH, Zurich ) for useful suggestions. A. A. , K. B, K. G. , T. A. M. and D. M. P. acknowledge the  Diamond Light Source  for time on Beamline I18 under Proposal sp8797. A. A. and K. B. acknowledge the  European Research Council  under the European Union's  Seventh Framework Programme  ( FP7/2007/2013 )/ ERC  grant agreement n°  305377  (PI, Aiuppa) and 307356 (PI, Berlo) and G.
At the moment, however, our modes of publication create unnecessary duplication of effort (cf. Fitzpatrick 2011) : the closed format of paper publications (or paper-surrogate formats like PDF) makes bringing sources of data together a lengthy process of extraction, re-organisation and re-digitisation. What is missing is a sensible way to create shared cumulative datasets or common procedures to link digital datasets for shared advantage  (Schloen & Schloen 2014 , Vinck & Clivaz 2014). Despite the potential advantages to archaeological interpretation through re-use and re-flection, there is certainly some reluctance to adopt an Open Science approach, at least where it applies to data and methods rather than just publications  (Harley, Acord, Earl-Novell, Lawrence, & King 2010 , Kelty 2014).
A considerable amount of ground was covered in 2015 using a GPS-based grid that allowed relatively regular sampling shapes and hence fast tract recording (Figure  1 ). Beyond the specific archaeological aims, two interrelated innovations were employed as part of the Open Science-inspired pilot (references and more detailed information describing the installation and interrelationship of the software used can be found in the appendices and the tables). These were instigated and implemented by N. Strupler and T. C. Wilkinson. 1. Born-digital field data entry system: The first innovation was the application of in-the-field data entry using the same handheld device, which was also used for GPS navigation. Using the OpenDataKit (henceforth ODK) software suite, tract data which normally would have been recorded in notebooks or on paper forms was entered immediately by the team leader at the end of each tract.
2. Distributed version-control data management platform: The second innovation was the application of a distributed version-control system (Git) and a related web-platform (GitLab CE) to facilitate the project's data management and the collaboration between team members (whether in the field or beyond). Data and text of all types was structured into purpose-specific Git 'repositories'. Additionally, the version-controlled data-management platform was also used to manage and enhance two diverging but commonly employed practices within survey archaeology, namely prose-oriented reflexive commentary and GIS-oriented mapping of survey results: 1. Methodological transparency: grey literature, reflexive commentary, multi-vocality and transparency of data collection: The project's 'daily log' was entered and reviewed into one of the Git collaborative repositories, which also held more general information about the project methods, aims and practicalities in the field for the whole team.
The long-term aim was also to make this archive open alongside the data as an equivalent to an open lab diary and a re-usable record of the way that the field methods were designed. 2. Computational reproducibility of survey mapping and analysis: Rather than simply providing finalised maps as output, we used a scripted approach to GIS (=geographical information systems) by creating procedures which made explicit the process of re-organising data and correcting mistakes, as well as recording the combination with pre-existing spatial information. Code for this analysis was written using R and stored in a Git repository, with the aim of enabling its evolution to be tracked and for readers to review, reproduce and make their own modifications to the analysis and visualisation. 3 Innovation 1: Born-digital Field Recording: ODK and Raw Data One of the potential epistemological objections to Open Data in archaeology is the idea that archaeology, unlike many 'hard' sciences (e.
g. meteorology), rarely has access to the sort of large-scale collection of objective raw measurements (especially through scientific instruments) that warrants digital distribution. With the expansion of geophysical prospection and the oncoming juggernaut of automated morphometrics (e. g. 3D scanning) and easy photogrammetry, one can easily question the scale argument. But even the digitisation of low-level primary observations from the archaeological method can benefit from early digitisation and subsequent release. In the past, most of such observations were collected in excavation or survey log books or, more systematically, in the form of standardised paper forms. With the advent of computing, data from the types of records have been digitised through transcription into digital documents or grid databases and, increasingly, various archaeological projects have experimented with creating digital recording forms directly into the field (e.
g. Ellis 2016 , Wallrodt 2016 ). This 'born-digital' approach helps to decrease the distance (and time) between field observations and incorporation of the data into results and dissemination. Nonetheless, at the time of the project design in spring 2015, we were unaware of any other intensive survey project in Turkey which had implemented a truly 'born-digital' data collection. We selected a free and Open Source software OpenDataKit (or ODK) as the platform for our pilot. ODK is an extremely flexible and easy to implement software suite designed to facilitate digital surveys; originally for social or medical research undertaken in the developing world by individual data collectors on a mobile device (e. g. phone) before being aggregated across an internet connection into a central database for analysis  (Anokwa, Hartung, Brunette, Lerer, & Borriello 2009).
The advantage of DVCS is that it allows the creation and preservation of complex version 'trees' in which multiple authors can contribute to the full history of a project independently. DVCS also includes procedures to manage the merging of conflicting versions, to preserve 'dead-ends' and errors, and simultaneously to maintain a 'head' (i. e. latest version) that can be seen as the endless evolving 'canonical' version. To manage the pilot survey's data, we decided to use Git, a cross-platform, actively developing Free Software DVCS. The software's specifics and the motivations behind its selection are explained in more detail in the Git appendix. One remarkable observation to be made about a data flow strategy for fieldwork oriented around Open Science policies and a version control platform such as Git is the parallel between the task of an archaeologist (who creates a story of the past based on searching for relations between objects/traces in the present) and the task of an Open Science reviewer or a data historian (who creates a story about a project's past based on searching for relations between fragments of data left in the archive, cf.
GitLab CE: User-Friendly Data Version-Control and Access Management GitLab CE is a mature web platform which provides a visual web-based interface to track Git repositories, as well as a suite of functions needed to manage collaborative digital projects such as team members and access permissions, a communication platform for issues (e. g. bugs or task lists), and systems for automated tasks (i. e. continuous integration and triggers). Like Git, it is primarily designed for managing computer code projects, but the principles are surprisingly applicable to more general data-project management. There are a number of ways that GitLab can be run (more details can be found in the GitLab appendix), but for Project Panormos, we chose to set up our own server instead of relying on an external infrastructure.
Whether this will indeed become the case is currently difficult to tell. Both fieldwork methodology and archaeological interpretation necessarily involve the accumulation of a pool of knowledge and a set of practices which are based on earlier operations and adapted to new places, but this inheritance process is often implicit. This is what C. Kelty calls modulation, the practice of looking at a project, understanding how it works and re-using it for different goals  (Kelty 2008). This is exactly the principle used in Free Software, where lines of code are re-employed and modified, small programs integrated within others, all through established licensing and proper attribution to source  (Kelty 2005). In the world of research, there is, of course, a built-in resistance to overt in extenso modulation of text, since it is seen as a kind of plagiarism, even when sanctioned.
1). For the provisional post-fieldwork analyses designed to visualise our results at the end of the season, N. Strupler wrote a number of cleaning scripts organised under the survey-data repository and RMarkdown documents organised under the survey-analysis repository. The scripts in the survey-data repository process the raw data as exported from ODK, correcting errors and then export to a cleaned canonical version. The analysis script, which was written in RMarkdown, described the process of import of this canonical data, the transformation of this data into appropriate structural format for analysis, and then its output into a series of visualisations of, for example, pottery density, using customised colour, etc. Managing this code in a Git repository had further benefits: first, the history of how it was coded could be tracked (so that changes which introduced errors might be more easily spotted); second, the code could be immediately shared amongst other team members with appropriate access who could replicate, review the output, or make new modulations.
Data Flow in the After an area of land had been covered, the printed maps were used as the basis to digitise tract shapes using two well-known GIS programs, ArcGIS's ArcMap and QGIS, converted into text-oriented geographic standard format (GML) and then committed to the relevant Git repository survey-spatial. Meanwhile, identified finds from the survey were processed in the project house as per normal archaeological procedures. Data about each find was input into a spreadsheet and saved in CSV format. This in turn was added to the survey-data repository. The RMarkdown scripts, themselves stored in a repository and also written toward the end of the field season, drew on data about tracts, spatial location and finds to create the visualisations of find distribution (e. g. by date). The scripts could be updated almost instantly as the latest version of the data was pushed to the centralised project server, and can be easily re-used in future seasons.
The advantage of the powerful decentralised and collaborative nature of Git as a DVCS became very obvious. Since less time had elapsed between data collection and data visualisation than is often the case in database-oriented projects, errors in the data could easily be identified, corrected and tracked via the data history. Team members could also work on different (or indeed the same) repositories simultaneously, experimenting with various data or analytical structures, without the immediate risk of breaking others' work on the same databases. Each user could also use the most familiar software tools appropriate to the task (e. g. QGIS; ArcGIS; Vim; LibreOffice Calc; RStudio) before committing changes to the Git repository history using the command-line tools or GUI-equivalents (SourceTree, SmartGit).
This encouragement to compress the pipeline from data-creation via data cleaning to data analysis and the nature of Git architecture also had ancillary benefits for the long-term archiving of the project. Since the current tools available to manage Git repositories work most efficiently with plain-text-based formats, and since we were working in a cross-platform environment (different team members were using computers with Debian, Ubuntu, Windows, Mac OS X and even iOS operating systems), from the outset we were structurally encouraged to follow good data sharing and archiving practices. As has long been recognised by data archivists and advisors, plain-text formats (CSV, XML, JSON or similar) increase the likelihood of both long-term readability and re-use of data, since they are widely recognised and documented, can easily be imported by most software and, in extreme instances of loss of format protocols, are the most likely ones to remain humanly-readable and thus potentially translatable long into the future (Marwick 2016, table  1 ).
For Panormos, the standard format for storing data from the field or finds became CSV (either exported from the ODK Aggregate server or spreadsheet software), and for GIS data we used GML (exported from the GIS software, primarily QGIS). Though each has particular limitations, both of these formats are widely recognised and recommended for archival deposit of research data (e. g. Zenodo, figshare, ADS, DANS, IANUS).
The application of GitLab CE and the encouragement of all team members to use it to produce their daily log was thus a good indicator of how typical users might interact with such complex models and points to ways that such software might become less exclusive to an emergent coding clique. Encouragingly, all our team members were happy and willing to use GitLab CE to access the team repository and edit documents with the web pages: the basic paradigm of online editing of files (and even the use of Markdown as a basic markup format) appeared to be sufficiently familiar and intuitive for all members of whatever age (ranging from 20 to 40) or gender. There was some variation in the relative interest and willingness to learn about the underlying structure of the software and the motivation behind using it (in an admittedly small sample, most interest came from younger male team members, which also reflected a general interest in computing in archaeology).
In response to this limitation, non-standard but more complex extensions have been developed to manage large binaries. The two most popular include Git Large File Storage (developed by GitHub), and git-annex (developed by Joey Hess), support for which was integrated into versions of GitLab CE after the pilot was begun, but which requires the installation of additional software on both the server (to enable access and control of the files via the GitLab CE server) and client machines (on each user making direct use of Git). These extensions are particularly apposite in cases where large binaries need to be kept together in sync with other text-oriented versionable data (e. g. source code and fixed but relatively unchanging binary assets). However, the tools to manage changes between binary versions are still limited (each version is stored in its entirety rather than a more efficient record of changes, called deltas, which is how Git acts on text or code).
Although we initially continued to use a Git repository to back up and sync the large raster assets for the short-term as a matter of platform convenience, it became clear that Git was not a good platform for maintaining the photographs, especially because the images themselves did not require version control, since we did not expect to edit the files. The only useful function of versioning here would be an archive history of when images were entered into the repository so that users could identify if they had the full database or not. A further problem with using Git with large files was the limitations imposed by the internet connection in the field. We found that in practice even separating the images into a separate photo-archive repository was impractical because our internet connection was too weak to enable uploading of large commits.
Attributing Work to Authors The Git model is based on the assumption that collaborators are independent and differentiated, but interact in relatively similar ways with the code (i. e. on the computer). Diagrams that allow reviewers to trace responsibility for changes to certain contributors are thus easy to construct in Git. This is useful to trace bugs, for example, but also to recognise the degree to which different users contribute to the project. We had hoped that the use of Git version control would enable a greater deal of recognition of work done before publication by tracking contributions to the data sets, but Git is not designed to document the effort expended in the sort of non-computer based tasks which are essential to archaeological work (e. g. find drawing, washing ceramic, cooking).
Data Cohesion, Data Models and Databases in DVCS As a version-control system designed primarily to manage code development, Git tries to be as contentagnostic as possible. As such, it necessarily makes no attempt to monitor the semantic cohesion of the repository's content. Nonetheless, in a coding context, its ability to keep a level of cohesiveness by tagging of versions (and hence syncing different parts of a code project) is often emphasised as one of its strengths for collaborative work. Scientific data often has similar requirements for cohesion, especially where different data sets need to be linked together for comparison or analysis. In the digital age, the most proficient archaeological projects have put such data into relational databases (MySQL, Access, and other SQL-type database) using 'keys' (or 'IDs') to link data between different tables through querying.