dataesr/scientific-paragraphs-categorization huggingface dataset:
Computational Efficiency We have performed timing experiments with our reference implementation on a Skylake CPU. The results are presented in Table  2. They include the number of CPU cycles needed by the three operations key generation, signing and signature verification. These numbers are the medians of 10000 executions each. For the signing operation we also give the average number of cycles because the use of rejection sampling during signing has the effect that sometimes more time is needed than is indicated by the median cycle counts. Signing was performed with a message size of 32 bytes. The computer we have used is equipped with an Intel Core i7-6600U CPU. The system runs Ubuntu 18. 4 with Linux Kernel version 4. 15. 0 and the code was compiled with gcc 7. 3. 0.
Acknowledgements We are very thankful to the referees for their useful suggestions. This work is supported by the  European Commission  through the  ICT program  under contracts ICT-645622 (PQCRYPTO), ICT-644729 (SAFEcrypto), and through the  ERC Starting Grant   ERC-2013-StG-335086  (LATTAC). It is also supported by the  Swiss National Science Foundation  through the 2014 transfer  ERC Starting Grant   CRETP2-166734  (FELICITY) and by the  Netherlands Organization for Scientific Research (NWO)  through  Veni  grant  639. 021. 645 ( Cryptanalysis of Lattice-based Cryptography ).
Methods 5 P-T conditions for all samples were estimated using phase equilibrium modelling with the Perple_X software  (Connolly, 2005:  version 6. 6. 6) using the internally consistent thermodynamic data set of  Holland & Powell (1998 : 2004 upgrade). The calculations were performed in the MnNCKFMASHTi system using XRF whole-rock compositions (Table  S1 ). The following solution mixing models were used: garnet, staurolite, chloritoid  (Holland & Powell, 1998 ), biotite (Tajčmanová et al. , 2009) , ternary feldspar  (Fuhrman & Lindsley, 1988) , ilmenite (ideal mixing of ilmenite, geikielite, and pyrophanite end-members), 10 melt  (Holland & Powell, 2001)  and white mica  (Coggon & Holland, 2002). Iron was assumed to be Fe 2+ as the Fe 3+ content of the minerals considered is negligible and Fe 3+ oxides occur in negligible amounts.
Similar nappes 10 further south in the Caledonides do display evidence for underlying oceanic rocks (e. g. Andersen et al. , 2012). T path with rapid switching from extension and heating to compressional S2 shearing (melt-filled S2 axial planes in the Nordmannvik Nappe). However, paleomagnetic data from the Honningsvåg igneous complex on Magerøy suggests it intruded the Magerøy Nappe rocks when they were ~1350 km north of Baltica, supporting a possible early Silurian separation between Baltica and the RNC (e. g. Fig. 15B , C;  Torsvik et al. , 1992; Corfu et al. , 2006). Dallmeyer and Gee, 15 1986; Majka et al. , 2014). Both scenarios require the presence arc rocks either tectonostratigraphically between the RNC and KNC or below the KNC, which we do not observe. It is possible that subduction was relatively short-lived, providing too little time for a proper arc to develop.
Eastward-dipping subduction (e. g. Fig. 15a ;  Andréasson et al. , 2003)  seems unlikely or, at least, evidence for it is lacking so far. It is likely that the KNC (or at least its upper part) formed a microcontinent on the upper plate (e. g. Fig. 15b ), placing the suture below it. The RNC as a microcontinent on the upper plate (e. g. Fig. 15c ) is a also a promising model, assuming that a yet unrecognized suture is present between the KNC and RNC. Both of these models (Figs. 15b, c ) are possible in a scenario where early Silurian heating and gabbro intrusion 30 resulted from extensive magma underplating in a back-arc setting with a rapid switch to shortening and collision over ~10 million years. Discrepancies in the models could be due to uncertainties in observations (e. g. paleomagnetic datasets or P-T estimates), or due to oblique collision, introducing strike-slip aspects to the story, and a possible overprinted pre-collisional accretion history.
Acknowledgements We thank  L. Menegon  for helpful discussions in the field. C. Tinguely is thanked for help with the EMPA at the  University of Cape Town  and  K. Neufeld  for help with the SEM at  UiT The Arctic University of Norway. SIMS data were collected at the  NORDSIM Laboratory , operated under an agreement between the research funding agencies of  Denmark, Iceland, Norway and Sweden , the  Geological Survey of Finland  and the  Swedish Museum of Natural History. K. Lindén  and G. 5 Kenny assisted with the collection of SIMS data. We thank  UiT The Arctic University of Norway  and the  Norwegian Research School for Dynamics and Evolution of Earth and Planets  for supporting this work.
For all architecture contexts, we assume that all their viewpoints are enabled (further reduction is expected when some of those views are disabled). The data in Table  2  suggests that before applying our approach, the number of abstract syntax element create actions, which spanned all Packageable Elements in UML and SysML equaled 88. After applying our approach, the number is reduced by ~23% for UML, ~14% for SysML (lost the subset of UML not used in SysML but gained SysML specific subset), and ~72% for Profile (this is not surprising given that only a few elements from UML are needed). The table also suggests that the total number of concrete syntax elements (Model Kinds) create actions before our approach was 20 (14 UML diagrams+4 SysML diagrams+2 SysML tables). After our approach, the number is reduced by 35% for UML, 40% for SysML, and 90% for Profile.
Lightweight modeling tools have been developed to minimize the learning curve and reduce tool complexity. Examples of such tools include Umple and TxtUML  [16]   [17]  that enable users to create models quickly using textual editors. Other works proposed a light version of UML itself  [18]. These approaches do achieve some level of complexity reduction, but typically at the cost of compromised functionality. Existing modeling tools may provide global preferences or settings to allow users to enable and disable modeling notations and/or features. This is the case in Rational Software Architect  [19]. These global sittings are not tuned to the specific model(s) being worked on. Other tools provide pre-set preferences per role. For example, for an analyst role, the tool may hide away specific modeling notations and UI elements.
Introduction The Linked Open Data (LOD) paradigm for data representation, sharing and publishing has been more and more appealing to the world of museums and libraries over the past years. The LOD project and the semantic web in general offer technological means for data reuse, increased visibility and data sharing on the web, data federation and facilitated exchange of metadata by the creation of links across resources. Attracted by these possibilities, many major actors from the library world, such as the Library of Congress (LOC) or the French National Library (BnF), have embraced semantic web technologies with the goal to open their archives and catalogs to the web. This process has resulted in a number of openly available and explorable RDF graphs reflecting the rich content of numerous libraries and cultural institutions from all over the world  [1].
The DOREMUS project follows this line of research and practice, with a particular interest in classical and traditional music, so far relatively under-represented on the LOD. 4  Three major French cultural institutions-the BnF, Radio France (RF) and the Philharmonie de Paris (PP)-have joint efforts with data and social science academics in order to develop shared methods to describe semantically their catalogs of music works and events and open them to the web community. A major contribution of the project is the development of the DOREMUS ontology  5  which extends the well-known CIDOC-CRM and FRBRoo models for representing bibliographic information  6  , adapting it to the domain of music, thus filling an important representational gap. A number of shared vocabularies about music-specific concepts (such as musical genres or keys) have been collected or developed, linked and published using the SKOS standard.
The data from the catalogs of the three partner institutions comes in MARC or XML formats. Specific tools for data conversion to RDF following the DOREMUS model have been developed. This process results in the construction of several knowledge graphs about music works and events, which have been linked using a specifically developed for this purpose data linking tool. For evaluation purposes, a benchmark has been created manually by the library experts and shared to the semantic web community as part of the Ontology Alignment Evaluation Initiative (OAEI). The data fusion process results in the construction of a pivot graph of shared and unique musical works. Finally, an exploratory search engine is developed that allows to browse the knowledge graphs. This paper covers the components of the DOREMUS workflow described above, which altogether form a paradigm for lifting, linking and publishing music library metadata.
We present in detail the DOREMUS knowledge graphs with a focus on the (re-)used models and vocabularies and the processes that allow for their (re-)production and fusion. The contributions of this work are: ‚ A model for describing musical works and events extending FRBRoo together with a number of shared and linked music-specific controlled vocabularies. ‚ Three knowledge graphs about music works that represent the catalogs of three major French cultural institutions. ‚ An approach to interlink these graphs resulting in the construction of a pivot graph, containing all unique works and links to the original graphs. ‚ A set of benchmark datasets for data linking evaluation. ‚ A set of tools for data generation, vocabulary alignment and validation, data linking, pivot graph construction, and data search and exploration.
The remainder of the paper is structured as follows. In the next section, we provide general information about the graphs, their form and content, the (re-) used ontologies and controlled vocabularies, as well as statistics. In Section 3, we detail the different components of the DOREMUS data production pipeline, and in particular, the data conversion and linking approaches. In Section 4, we demonstrate how this resource has already been used and we discuss its wider expected impact. We present related initiatives in Section 5 before we conclude and discuss future work in Section 6.
The DOREMUS Datasets of Linked Musical Works The DOREMUS knowledge graph consists of several datasets, each containing the information coming from a specific database of an institution. In that, a given real-world entity (e. g. , a music work) is represented at most once in each graph. Currently, three stable datasets have been published: (1) bnf: Works and Artists, originally described in MARC records of the BnF; (2) philharmonie: Works and Concerts, originally described in MARC records of the PP; (3) itema3: Concerts and Recordings, originally described in XML records of RF. Each dataset has two access points: (1) A specific named graph in the DORE-MUS triplestore, accessible through a public SPARQL endpoint. Each graph follows the pattern http://data. doremus. org/<dataset_name>. (2) A set of RDF files in Turtle format, available to public download.
Content and Form of the Resource The DOREMUS knowledge graphs contain information about works (referred to as expressions) and related entities from the field of classical and traditional music. Each entity is identified by an univocal persistent URI, which follows the pattern http://data. doremus. org/<group>/<uuid>, where the group is determined by the class of the entity (e. g. expression) and the UUID (Universal Unique Identifier) is generated at conversion time in a deterministic way using the dataset name, the class and the identifier of the source record as seed. 8  Currently, the resource is shaped by three knowledge graphs of music works (one per institution), that are linked together in a pivot graph, which is the union of all unique expressions across the three bases, together with owl:sameAs links to the original graphs (cf.
Resource Development and Reconstruction The general workflow of DOREMUS is depicted in Fig. 1. The data from the three partner institutions is first converted to RDF following the DOREMUS model, resulting in three independent knowledge graphs (one per institution), which are then linked. After a manual validation of a set of uncertain links, a pivot graph is built containing identifiers of the union of all works found in the three graphs, together with identity links to the resources in each of the three institutional graphs. We detail on these stages of the workflow in this section.
Data Conversion The data collected from the BnF and the PP describing music works is represented in the UNI-and INTERMARC variants of the MARC format. A MARC file is a succession of fields, each carrying a 3-digit label, and subfields, delimited by the $ symbol (e. g. , "50011$313908188$qSonates$rPiano$sOp. 27, no 2$uDo mineur"). 10. We have developed an open source prototype, named marc2rdf to automatically convert UNI-or INTERMARC bibliographic records to RDF, implementing the DOREMUS model (link to the tool given in Table  1 ). The conversion process relies on explicit expert-defined transfer rules (or mappings), which provide the corresponding property path in the model as well as useful examples  [6]. We have used the DOREMUS properties to name the extracted relations (e. g. , mus:U12 has genre is the property describing the genre of a work).
Beyond being a documentation for the MARC records, these rules embed information on specific and distinct librarian practices in the formalization of the content (format of dates, syntax of textual fields, default values for missing information), making marc2rdf a robust generic converter for MARC files. The converter is composed of different modules that work in succession (Fig. 2 ). First, a file parser reads the MARC file and makes the content accessible by field and subfield number. We implemented a converting module for both the INTERMARC and UNIMARC variants. Then, it builds the RDF graph reading the fields and assigning their content to the DOREMUS property suggested in the transfer rules. The free-text interpreter extracts further information from the plain text fields, that includes editorial notes.
The marc2rdf tool allows to reproduce deterministically the conversion process at any moment in time, providing the opportunity to seamlessly take into account possible updates of the ontology (e. g. , the addition of a new property) and/or the data entries (a new record entering the catalog of one of the institutions), ensuring in that way the currentness and dynamics of the graphs. The works from Radio France, described in XML, are managed by an ad hoc software that parses the input file, collects the required information, creates the RDF graph structure and runs the string2vocabulary module.
Data Linking The three datasets that are currently subject to interlinking are highly heterogeneous: a given entity (e. g. , a musical work) can be described quite differently across the three institutions. In addition to well-known data discrepancies such as lexical, semantic (polysemy, synonymy) and orthographic mismatches of string literals, the use of acronyms and abbreviations or differences in formats and types of numerical values, we have encountered several commonly occurring issues that are specific to our data. We outline some of them below. -Differences in coverage and particularly lack of information in one of the graphs as compared to a richer description in another. In our case, the works coming from RF are systematically described by a considerably smaller set of attributes, than those found in the catalogs of the BnF and the PP (see Table  2 ).
-Different depths in the graphs, at which we find the value of interest-e. g. , the birthplace of a composer can be directly assigned to the entity in one graph, or via a longer property chain in another. -Presence of comments in the form of free text (given by the property ecrm:P3 has note) that are difficult to compare, as well as presence of institutionspecific resource identifiers (bibliographical records ID's) given under the same property name across different datasets, although not comparable. -Presence of blocks of highly similar in their descriptions, but yet distinct instances in each of the graphs-e. g. , the set of all piano sonatas by Beethoven, differing from one another in only one or two property values, which makes their disambiguation difficult and is likely to produce false positives.
In a first attempt to interconnect these graphs, we relied on state-of-theart linking systems  [7, 8]  that adopt a property-based philosophy where a set of attributes is selected in order to compare instances across two datasets based on (an aggregation of) similarity measures computed on their literal values. The results obtained proved to be not satisfactory. 11. Consequently, we develop our own linking tool, named Legato [10]-a generic data linking system motivated by the DOREMUS use-case scenario and data linking challenges. Legato is designed to match entities from highly heterogeneous graphs, effectively disambiguating highly similar yet distinct resources. Fig. 3  shows the generic workflow of the system. The data cleaning module ensures to only keep properties that are comparable across the datasets (hence, comments in the form of free text, as well as institution-specific instance identifiers are removed).
Given our knowledge of the DOREMUS data, we have customized the linking process for the purposes of the project in two respects. (1)  The linking workflow begins by searching for values of the composer name and catalog number properties, because the set of these two properties has been identified as a key by our experts. If values for these two properties are found for a given pair of instances, they are directly used for the comparison and Legato is executed on the remaining instances only. Note, however, that these properties do not have values for a very large number of works and in particular, no entry of itema3 has a catalog number (cf. Table  2 ). (  2 ) In order to speed-up the execution of Legato, we have partitioned the datasets per composer and linked pairs of subsets across two graphs that gather works by the same composer.
As explained above, as a result of these processes, we end up with three sets of "certain" links. Only links from that category will appear in the pivot graph. As Fig. 5  shows, the process of pivot graph construction and that of the manual validation of links are tangled up in a single workflow. The code of the algorithm for (re-)generating the pivot graph is released as open source (cf. Table  1 ). Currently, the manual validation process is in progress. Therefore, the published pivot graph contains the links that have been identified automatically (i. e. , corresponding to the patterns in Figs. 4(a)  and 4(b) ) by using the nonconservative thresholds of Legato tuned by the help of our benchmarks (0. 2 for bnf-philharmonie and 0. 5 for the other two pairs of datasets). The graph contains also the links of all unique works (those that have no matches found in any of the two other bases) to their original URIs.
The results of the automatic link discovery process on the three bases together with the resulting pivot graph in its current shape are available at https://github. com/DOREMUS-ANR/ knowledge-base/tree/master/linked-data. Links statistics. We have currently a total of 7495 links created automatically across the three graphs, among which we have 2520 links of type single link, 396 links of type triangle, 3378 links of type missing link and 261 links of type conflict (as labeled in Fig. 4 ), plus additional 940 links of type 1:many that are currently subject to post-processing. Updates in the datasets will not decrease the number of links since the source databases monotonically grow.
e. Strings), but also any of its narrower concepts (i. e. violin, cello, etc. ). A work-in-progress recommendation system is also implemented in Overture in order to suggest to the final user different works to discover. The recommended works have similar properties to the current one, like the genre, the composer and the foreseen instruments. The recommendation is realized by computing knowledge graph embeddings using node2vec  [13]  on the DOREMUS knowledge graph and selecting the closer works using the euclidean distance  [14]. Other client applications that also make use of the DOREMUS dataset include CityMus  [15] , a mobile application that generates Spotify playlist composed of DOREMUS tracks based on the surrounding important buildings of a geo-localized user in a city. More precisely, interesting paths in the DBpedia knowledge base between POIs and composer are sought and shown to the end user in order to explain the recommendation.
Related Work and Graphs There has been a significant effort in the last years to open and publish data from the field of cultural heritage  [17]. An overview of related projects is given in  [1] , where the authors provide an evaluation of the various initiatives with regard to the well-known five-stars open data rating, applied to the cultural domain. Regarding the more specific problem of producing linked data out of library records, addressed by the DOREMUS project, a number of related initiatives have recently been introduced. We refer to the multiple contributions of the Europeana project,  15  , unifying and making accessible the catalogs of numerous libraries, museums and archives across Europe. One of the early efforts in that respect is made by the Library of congress,  16  which has become a dataset of reference in the field.
In the same spirit, related projects include the German National Library linked data service,  17  the British National Bibliography Linked Data Platform,  18  the open data project of the French National Library BnF  19 or, more recently, the Virtual Library Miguel de Cervantes project  [18]. In the majority of the cases, data comes in a given MARC variant and has to be converted to RDF. In certain cases the migration process goes through an intermediate phase of translation to relational database  [18] , or data is being directly converted to RDF based on the standards of bibliographical description, such as FRBR. DOREMUS follows this line of work by implementing its own expert-defined mappings-based conversion mechanism, enriching FRBRoo with more than 40 classes and 100 properties. The resulting (DOREMUS) model fills the important gap between library content description and music metadata.
As compared to music-related datasets, we outline that the BBC open datasets have tracks only, the Dutch Library (part of Europeana) has only publications, CPDL  20  is specialized for chorus (with scores and midi), while DOREMUS is general and can glue these datasets. MusicBrainz  [19] , one of the most popular knowledge bases about music metadata, started a few years ago its process of exposing its data as semantic triples through the platform LinkedBrainz  [20]. In contrast to DOREMUS, which follows a librarian structure, MusicBrainz follows a more commercial practice giving a central role to tracks, albums and artists (un-distinguishing the composer from the performer), at the expense of all the information connected to the work concept (genre, casting, key, etc).