dataesr/scientific-paragraphs-categorization huggingface dataset:
While substantial previous work has been attempted to address these issues, no (image) metadata standard can address the aforementioned issues completely. Efforts like OceanBestPractices (https://www. oceanbestpractices. org/) are trying to collect standards and methods  32, 33. However, while the bottom-up nature of the loose collection is a valuable step towards reproducibility and comparability, it does not aim at selecting one gold standard to make all data sets interoperable. Established standards such as Schema. org, Dublin Core and Darwin Core provide key terms, yet are too unspecific. Those standards provide the central metadata concepts around which more dedicated standards should be developed. They need to be as generic as they are to accommodate all data types and use cases. Standards from medical imaging such as DICOM (Digital Imaging and Communications in Medicine) or OME (Open Microscopy Environment) are tuned for medical applications and hence incompatible with Earth-science applications  34.
Audubon  35  , MEDIN  36  and ISO19115 for image data address some aspects required to achieve FAIRness of marine image data. However, they lack components on the purpose of imaging, geometric scaling of image data for size and volume quantification and particularly they lack components to address the content of image data such as derived features or annotations. Hence, those standards are incomplete and too generic to capture the specific demands of imaging in the oceans. The standard that is most compatible to the demands for marine image data is the Planetary Data System (PDS4)  37. This standard is used by e. g. , NASA for remote sensing data acquired by satellites. This standard uses XML to encode metadata and has strong components on data encoding which are relevant for satellite data but not employed in marine imaging which relies on standard data formats for imagery.
PDS4 lacks technical aspects to document camera type and setting used for acquisition and is agnostic of imaging use cases. While it may be a good fit for some remote sensing data, it does not cover all requirements of the marine sciences or for marine imaging. As a solution, we propose the use of image FAIR Digital Objects (iFDOs) and present an infrastructure environment to create and exploit such iFDOs  38. The iFDO format solves the issues of technical heterogeneity and semantic un-structuredness. The infrastructure environment solves the challenge of handling vast image data sets. But only in combination can the iFDOs and the infrastructure environment that works with iFDOs achieve FAIRness of marine images. iFDOs are designed to be applied to all marine image data: in-situ and ex-situ imagery, photos and videos and datasets consisting of single images to thousands of images.
Results iFDOs -image fair digital objects. iFDOs consist of various metadata fields, grouped into three sections (see Fig. 1 ). Some fields are required, and some are recommended or optional. FAIRness can only be achieved by populating all the fields in the required iFDO core section. Visibility and credit for valuable image data can only be created by populating the recommended fields in the iFDO capture section. This section captures how the image data was created. Semantic structure within image data can only be extracted by populating the optional fields in the iFDO content section. All three sections of image metadata need to be stored together in one iFDO file. The file must be human and machine-readable, hence the YAML (Yet Another Markup Language) format was chosen for all current tool developments.
Creating iFDOs. Creating iFDOs requires a factory process that merges image-derived and acquisition-related information such as position data. This factory process will be a algorithmic method "produces" a digital iFDO object. Figure  2  provides an overview of the most common steps required to create an iFDO. The specific steps for on dataset or use case depend on the type of image acquisition and available accompanying data. In general, it is essential to verify timing of the images in UTC (Coordinated Universal Time) to Fig. 1  Setup of image FAIR Digital Objects. Key information and image data is stored in a dedicated infrastructure (yellow squares). iFDOs only contain persistent identifiers to those external information resources. Additionally, specific metadata for marine imaging use-cases is stored inside the iFDO files.
iFDOs consist of three sections: (1) the required core part which includes the persistent identifiers as well as licensing information; (2) the recommended capture part that addresses the technical heterogeneity of image acquisition; and the (3) the optional content part that captures semantic information from within the images to address the heterogeneous nature of image data. Together, these three sections constitute one iFDO file. This file contains header information on the entire image data set as well as detailed information on each image item within a defined set of images. allow correlation with accompanying data by time point. Position data needs to be curated to remove outliers and smooth tracks. UUIDs (Universally Unique Identifiers) need to be created and handle URLs registered.
In an image curation step, UUIDs need to be minted into the image files and images be renamed to include project, timing and camera information. This curated image data can then be made available through FAIR infrastructure and serves as the input to compute further derived information such as image scale (pixels per meter) and to compute SHA256 hashes for file validation. We provide the MarIQT python package (https://gitlab. hzdr. de/datahub/ marehub/ag-videosimages/mariqt) to provide algorithms and tools for all these steps. Step-by-step material on iFDO creation is available as an OceanBestPractice document  39. FaIR marine image infrastructure environment. iFDOs address only particular aspects of making marine image data FAIR. Additionally, an infrastructure environment is needed that exploits the information contained in iFDOs and that the iFDOs link to through PIDs.
An iFDO factory software component collates information from all acquisition products and bundles them into an iFDO file. Persistent identification of images is enabled by assigning UUIDs. UUIDs are generated at random for each image item, with an additional UUID generated for the entire image set. These UUIDs constitute a key component that addresses several FAIR metrics and should be a part of the handle URLs, linking to the image data and metadata. The initial iFDO file needs to be published in an open access data repository such as OSIS (Ocean Science Information System), PANGAEA or another long-term repository featuring persistent identification. A handle server is required as a single-point-of contact to resolve requests for data. Such a handle server can cover use cases beyond image data.
Such incentives are created by providing established community tools with plugins or API (application programming interface) extensions that allow using iFDOs in particular tools. At present, integration plugins into the Robot Operating System (ROS) for marine robotics, an integration into BIIGLE for image and video annotation and an integration into QGIS for geographical mapping are under development. These tools will be released in 2022. Once a growing group of tools can exploit information from iFDO files, Reusability of image data products will be achieved. Aside from the SOPs for image acquisition, SOPs on iFDO creation and image curation were developed by the MareHub working group  39, 40. These SOPs complement this manuscript by e. g. , providing hands-on material for expeditions.
By also providing specific implementations for components of the infrastructure environment, we support adoption of iFDOs in existing workflows. We currently develop software to create iFDOs, after cruises or already during marine robotic deployments, as well as plugins to established tools such as BIIGLE  41, 42  or QGIS. Furthermore, we develop vocabulary servers to validate iFDO versions and tools to assess the reusability of data sets for different use cases. To address all current requirements of FAIRness (see Table  1 ), additional building blocks are needed. These include setting up a machine-readable vocabulary server. On top of that an iFDO validation service is needed, in addition to the validation algorithms already existing in the MarIQT Python package (https://gitlab. hzdr. de/ datahub/marehub/ag-videosimages/mariqt).
The image annotations are then encoded in the image-annotations field as a list of objects. These objects consist of a set of pixel coordinates, one or many label IDs, one or many annotator IDs and an optional confidence value. The format of the pixel coordinates is flexible such that point annotations, bounding boxes, polygons or whole image annotations can be stored. iFDO fixed term icons. Some iFDO fields may only be set to a restricted set of values. These restricted fields can be used to group or filter data sets. It is further possible to encode the allowed values with icons, to enable a rapid overview by humans on the content of an image data set. Such icons can be used in documents like data processing reports to provide a quick visual access to a dataset. The complete set of icons can be found in the online material (https://www.
marine-imaging. com/fair). The icons are released for public use under CC-0. Developing the iFDO format and setting up the infrastructure environment. This work originates in discussions of the Marine Imaging Community workshops  7, 46  and the MareHub initiative of the Helmholtz association. It builds upon concepts that have since evolved into the presented principle  18. Draft versions of iFDOs were developed in cross-institute and international working groups. Feedback from three stakeholder groups was incorporated into the current version of the iFDO format and documentation: data managers, researchers, and research software engineers. The exchange platform is an open Gitlab group (https://gitlab. hzdr. de/datahub/ marehub/ag-videosimages). It contains the complete iFDO documentation, Python code and Jupyter notebooks and is used to receive stakeholder feedback and contributions in the form of tickets and merge requests.
acknowledgements We thank the DataHub of the Helmholtz association and the  Helmholtz Metadata Collaboration. Their financial support and framework allowed to develop and implement the concept for FAIR marine image data. TS was supported by the  H2020  project  iAtlantic  ( H2020  grant  818123 ). CK and TS were supported by the DataHub information infrastructure initiative of the Helmholtz Earth and Environment research field. MZ was supported by  BMBF  project  COSEMIO  ( FKZ 03F0812C ). KH was supported by the  Initiative and Networking Fund of the Helmholtz Association  in the framework of the  Helmholtz Metadata Collaboration  project call. HJH was funded by the  DFG  (grant  HO 5569/2-1 ;  Emmy Noether Junior Research Group  awarded to HJH). RK acknowledges support via a  "Make Our Planet Great Again" grant  of the  French National Research Agency  within the " Programme d'Investissements d'Avenir "; reference " ANR-19-MPGA-0012 " and from  NOAA  Award  NA21OAR4310254.
AP acknowledges support of the  Helmholtz-funded infrastructure program FRAM (Frontiers in Arctic Marine Research ). KK and DN were supported by  German Research Foundation (Deutsche Forschungsgemeinschaft, DFG ) Projektnummer 396311425, through the  Emmy Noether Program. AN was supported by the  HMC  project  FDO-5DI  through the  Helmholtz Initiative and Networking Fund. JMD was supported by iAtlantic and Towards Turing 2. 0 under the  EPSRC Grant   EP/W037211/1  &  The Alan Turing Institute. KOM was supported by the  European Commission 's  H2020 Framework Programme  under grant agreement No. 871153 ,  JERICO-S3 Transnational Access program. JF was supported by funding of the  Alfred Wegener Institute, Helmholtz Centre for Polar and Marine Research.
Mostly, software tools like exiftool or ffmpeg are used which is also the case in the MarIQT Python package. The image-set-uuid only needs to be part of the iFDO file and not written to any image file. Using UUIDs for persistent identification is essential to achieve FAIRness by making images uniquely identifiable. Those UUIDs need to be registered in a long-term data repository and data portal to facilitate Findability of images.
The fluctuation of the shift parameter, Δβ, is shown in Fig. 2  for repeated measurements of the O w. On the right-hand y-axis, we display the corresponding effect of such an angular shift on the energy calibration at the O w line (574 eV) and the neon K-edge (870 eV). In our experiment we requested the reported monochromator energy and angle settings twice for each scan step; once before data acquisition with the SDD and once after. We found that the reported energy values before the SDD acquisition often showed unreasonably high fluctuations, probably attributable to the relaxation of the beamline to the selected energy immediately after moving the monochromator, even after the allowed settling time. For this reason we only used the values reported after each scan step for our further analysis.
The uncorrected data is again given here for reference (blue points). c: Residuals between model and data as ratio. d: Sum of the fluorescence spectra produced in the EBIT measured by the two SDDs. The calibration line was modeled with Voigt parameters σ = 0. 082 eV and Γ < 0. 001 eV energy determination is drift in the monochromator energy scale. Based on the analysis in  [28]  we estimate this uncertainty to be 40 meV for these lines. Direct comparison of the results with the literature is in general not possible due to the blending of transitions. However, the 3pπ u transition is easily identifiable in our scan as well as in recent measurements  [45] [46] [47]. Additionally, its energy is very close to our calibration line and, hence it has much smaller shifts due to drift. Using this as a reliable reference energy, we see that the Rydberg complex from  [46]  appears at  (c) Unresolved blend of π * and 3sσ, reported in  [50]  For comparison the experimental values of  [45, 46]  are listed.
SF 6 fluorine K-edge We scanned the fluorine K-edge of SF 6 in the range from 685 to 705 eV measuring the photoionization yield of the gas in the gas cell. The calibration is based on the O K γ transition of He-like oxygen (E O Kγ = 697. 7859(5) eV,  [25] ). Following  [56] , we describe the spectrum by a sequence of five Voigt profiles together with an error function to account for the photoelectric absorption edge at the Rydberg series limit. In  [56]  an arctangent function convolved with a Gaussian was used to describe the edge, but given our resolution we cannot discriminate between these choices. Hence, for simplicity we used only an error function to model the edge. The calibrated data and resulting best fit are displayed in Fig. 5. Similarly to  [56] , we have to add a line around 696 eV, otherwise an excess of events remains visible in the data in comparison with the model.
Modeling K-edge absorption spectra from first principles In order to assist in the interpretation of the experimental data we performed ab initio TDDFT simulations of the oxygen K-edge excitations in CO 2 (shown in Fig. 6 ) and fluorine K-edge in SF 6 (shown in Fig. 7 ). The computation of the molecular orbitals associated with the excited states allows us to attach symmetry labels to the experimental peaks. Moreover, the arbi-    [56]  and the edge as measured in  [57]  (indicated with diagonal marks). The gray curve outlines the measurements of  [56]  scaled to match the present results. b: Ratio between the data and the best-fit model. c: Sum of fluorescence spectra measured with the two SDDs. The calibration line is modeled with the Voigt parameters σ = 0. 079 eV and Γ = 0. 031 eV trarily high resolution of the simulated spectra can help to understand whether observed peaks originate from single broadened transition lines or if there is a richer spectral structure which cannot be resolved experimentally.
Acknowledgements Financial support was provided by the  Max-Planck-Gesellschaft (MPG)  and  Bundesministerium für Bildung und Forschung (BMBF)  through project  05K13SJ2. We thank  HZB  for the allocation of synchrotron radiation beamtime at BESSY II. C. S. acknowledges the support by an appointment to the  NASA   Postdoctoral Program  at the  NASA Goddard Space Flight Center , administered by  Universities Space Research Association  under contract with  NASA , by the  Lawrence Livermore National Laboratory  (LLNL) Visiting  Scientist and Professional Program  Agreement No. VA007036  and  VA007589 , and by  MPG. Work by  UNIST  was supported by the  National Research Foundation of Korea  (No. NRF-2016R1A5A1013277 ). Work by LLNL was performed under the auspices of the  U. S. Department of Energy  under Contract No.
( a )cFig. 5 a a5 Fig. 5 a: SF6 photionization spectrum (blue points) calibrated by simultaneous measurement of the O Kγ transition and modeled by five Voigt profiles and one error function (red solid line, components red dashed lines). The position of the calibration line is indicated by the dotted vertical line. The solid green lines indicate the measured peak positions from [56]  and the edge as measured in [57]  (indicated with diagonal marks). The gray curve outlines the measurements of [56]  scaled to match the present results. b: Ratio between the data and the best-fit model. c: Sum of fluorescence spectra measured with the two SDDs. The calibration line is modeled with the Voigt parameters σ = 0. 079 eV and Γ = 0. 031 eV.
Introduction In the last few years, we have witnessed a paradigm shift towards Open Science, greatly increasing the availability of scientific articles, datasets, software, and other research outcomes. This represents an historical opportunity to support researchers with new tools enabling more sophisticated search, exploration, and analytical services than the ones currently available. However, the current document-centric scholarly communication paradigm does not enable scholars to efficiently explore, categorize, and reason on this knowledge  [17]. Scientists need instead to find and manually analyze large number of static PDF files in order to gain a (often incomplete) understanding about recent research advancements  [9]. In recent years, we saw the emergence of several solutions for producing machine-readable, semantically rich, interlinked descriptions of the content of research publications, typically encoded as knowledge graphs  [22, 40, 12, 36, 46].
For instance, the Open Research Knowledge Graph 5  [22]  offers an infrastructure for describing articles in a structured manner, making it easy to find and compare them. The resulting knowledge graph includes about 10K articles, 4. 5K research problems, and 3. 3K datasets. Similarly, Nanopublications 6  [19]  allow users to represent scientific facts as knowledge graphs and have recently been used to support "living literature reviews", which can be continuously amended with new findings  [46]. A common drawback of these solutions is that they are limited to a relatively low number of articles, either because they rely on human experts to summarize information from the literature  [24, 22]  or because they focus on very specific domains (e. g. , computational linguistics  [16] , intrusion detection  [48] ).
In this paper, we focus on the second category. One of such knowledge graphs is ORKG  [22] , where articles are associated with the relevant topics, approaches, datasets, and evaluation methodologies. Nanopublications  [19]  enable users to represent in a minimalistic way various facts from academic publications. One of the drawbacks of both ORKG and Nanopub is that they are manually curated resources, where the representations of research articles are filled by crowdsourcing. Therefore, they cover a limited number of articles and require an important manual effort. Biology is the only field offering some sizable and high-quality knowledge bases of relevant entities, such as UMLS 11. Other research areas, including Computer Science, are very lacking in this respect. Some recent efforts focused on producing methods and tools able to automatically extract fine-grained semantic information from the content of the papers.
For instance, Luan at al. [27]  implemented a deep architecture that carries out multitask learning on top of shared span representations to build a knowledge graph on a dataset of 110K papers. Jiang et al. [23]  used instead a recurrent neural network model to carry out joint entity and relation extraction. In their work, they extract also "conditional" tuples that represent constraints on other statements: they assume that some facts are not universally valid but depend on the context of application. Their final resource contains 756 fact tuples and 654 condition tuples. Wang at al. [45]  targeted specifically articles on Covid-19. Specifically, they adapted an entity recognition tool to extract 75 different types of entities, using distant supervision. The advantage of distant supervision is that it does not require expensive human annotation.
Following the best practices of Linked Data, entities in CS-KG are associated with a set of alternative labels that are used to refer them in the scientific literature. For example, the entity cskg:recurrent_neural_network is associated with the labels recurrent neural network, recurrent trainable neural network, and recurrent neural network paradigm. CS-KG also provides 31K owl:sameAs links to DBPedia  [4] , 27K links to Wikidata 14 , and 6K to the Computer Science Ontology (CSO)  [37]. For instance the entity cskg:feedforward_neural_network is linked to the CSO topic cso:feedforward_neural_network, to the DBpedia entity dbpedia:Feedforward_neural_network, and to the Wikidata entity wd:Q5441227. CS-KG can support several intelligent services that require a high quality representation of research concepts and currently rely on alternative knowledge bases which cover a smaller number of publications (e.
Extraction Modules The proposed methodology employs four complementary tools to extract entities and relationships from plain text (typically the titles and abstracts of the articles). These tools are: - -PoS Tagger (PoST). This module is built on top of the Stanford Core NLP suite  [28]. It uses part-of-speech (PoS) tags to find all verbs that exist in sentences between pairs of entities. For example, given a sentence s and two entities in it e i and e j where e i , e j ∈ E Dy ∪ E CSO , this module builds triples <e i , v, e j >, where v is a verb in s between e i and e j. This module uses a window of size 15 as the maximum number of tokens that can occur between two entities to extract verb relations. It returns the set of triples T P oS. The sets T Dy , T OIE , and T P oS are given as an input to the Entities and Relations Handler Module.
We then manually refined this schema to produce a final set of 39 representative predicates mapped to 464 verbs from the articles  16. These same predicates were also used to produce the relevant relations in the CS-KG ontology. All verbs of sets T OIE , and T P oS are mapped using this schema. The relations generated by DyGIEpp in the set T Dy are also mapped to the same representative predicates  17. For example, two triples which share the same entities such as <a, embeds, b> and <a, contains, b> will be merged in a single triple <a, includes, b>, given that embeds and contains are mapped to includes. After mapping all the relations of the sets T Dy , T OIE , and T P oS , the module yields the set of triples T.