dataesr/scientific-paragraphs-categorization huggingface dataset:
KU 2849/3  and  2849/9. A. P. acknowledges financial support from the  UNAM-PAPIIT IN111421  grant and the  Sistema Nacional de Investigadores of CONACyT. R. G. -M. acknowledges support from  UNAM-PAPIIT  project  IN104319. A. P. and R. G. -M. also acknowledge support from  CONACyT Ciencia de Frontera  project number  86372. R. E. P. is supported by an  NSERC   Discovery grant. This research made use of Astropy 2 , a community-developed core Python package for Astronomy (Astropy Collaboration et al. 2013, 2018). This research made use of photutils, an Astropy package for detection and photometry of astronomical sources (Bradley et al. 2021).
e. , data, actuators, sensors, etc. ) and devices with their conceptual meaning, also it is possible to create abstract services which transcends their technical implementation. The WoT greatly facilitates service composition by decoupling applications from the details needed to access servers that expose things. For instance, one server might expose things using the oneM2M standards  [10] , whilst another might instead use the standards from the Open Connectivity Foundation (OCF)  [11]. Both servers may use the same underlying protocol, e. g. , HTTP (Hypertext Transfer Protocol), but in incompatible ways. The WoT further allows applications to access and reason with the metadata for services using RDF as a common framework, independently of the underlying IoT systems, allowing to expose the things included in the Thing Descriptor (TD), which is essentially a list of all devices included.
MongoDB Database MongoDB  [23]  is a general purpose, distributed, document-based database, that supports different JSON documents: JSON, BSON, XML and BLOBs. Queries are JSON, and thus easily composable, overcoming SQL queries. It uses a powerful query language that enables field filtering and sorting, bringing solutions to more complex use-cases  [24]. MongoDB is used to store the Thing Description generated for the devices installed in the SHLL and to track their state changes in a consistent way, allowing scalability and better performance in the management of data in JSON format.
Three-Tier Architecture As well as for the infrastructure, the LLG solution needs certain degrees of flexibility and separability, achieved by grouping components in layers. The LLG architecture follows a three-tier pattern. The topological distribution of an application modules can change depending on the system requirements. The above-mentioned tiers are logical layers, and can be described as follows: a Presentation Tier, a Middle Tier and a Data Tier. The presentation tier (i. e. , user services layer) provides access to traditional application and Web-based applications and presents data, allowing its manipulation and new data entry. The middle tier is the business services or logic layer. Its components can be allocated on a server machine and are designed to keep data structure consistency across diverse databases.
Implementation Scenarios Scenario 1 (addressing Plan4Act project's needs) is the remote control of living lab devices by a hardware embedded classifier of neural data extracted from monkeys in real time. This is Plan4Act project's Demo 1 and comprises a variant in which the house control can be executed remotely from an interface located in an experimental protocol employing Rhesus macaques. This scenario is illustrated in Figure  1  below: In this scenario, a Field Programmable Gate Array controller (where the mentioned neural controller is embedded) commandedthe SHLL devices (both IoT and KNX ® devices) through the LLG. Sequences of commands are sent by the controller in two modalities: sequential mode and proactive mode. The first, consists in emitting commands one by one (e. g. , open the main door and, once this action is done, turn the lights on).
Results In this section, the implementation of the LLG's service infrastructure is addressed, this is, the microservices architecture based on a RESTful approach, security and authentication for stateless service. The LLG has a three-layer infrastructure. The first layer represents the physical KNX ® infrastructure that connects all the devices. The second layer is a critical point of access because it maps the KNX ® datapoints into IP datagrams and it does not provide security, yet its access is blocked by a firewall when the connection is made from inside the Lab. In order to provide access from outside the lab a whitelist is set up allowing communication only from the LLG at the third layer. Layers 1 and 2 are in the same living lab installation while layer 3 is in the cloud. The Calimero Library  [37]  provides a discovery feature that is used for scanning KNX ® servers and datapoints, a feature that is used by the LLG to populate a MongoDB database.
As shown in Figure  3  below, the physical KNX ® infrastructure and the KNX ® -IP bridge are installed on the SHLL, while the LLG relies on a cloud infrastructure. This layer is deployed using container and orchestrator technologies. Two Docker containers and a cloud file system are orchestrated within a Kubernetes cluster. The first Docker container is mapped on a cloud load balancer Kubernetes service that manages a Java backend application, while a MongoDB Docker container, connected with a network file system on the cloud provider, manages the data representing the devices' WoT interfaces. This configuration of the Kubernetes cluster allows a high availability and reliability for (a) the entry point service (the Java backend application); (b) the WoT interfaces of the devices (the MongoDB container); and (c) decoupling between hardware and software components of the SHLL.
Dynamic ConfiGuration and Injection of Devices The LLG provides a functionality that builds automatically a Thing Description (TD) either through an API (collecting a list of devices from a database or allowing the injection of new devices) or by listening to the KNX ® 's bus, thus creating the internal database of the available devices of the LLG. The database can be privately edited in order to add also additional information to the devices such as description, name, properties, data types and so on. However, this functionality is not publicly available in the main TD of the living lab. This feature allows to modify a device on demand, enabling the user to change the current configuration of the lab. For instance, if it is needed to arrange the SHLL configuration to represent an office, it would be possible to redefine the door as office door, the living room as meeting room and so on.
Through Calimero library, it is also possible to "listen" when a new datapoint is added to KNX ® BUS or when a value of a datapoint is written on the BUS. The LLG is constantly checking on these events and maintains consistency between the MongoDB database and the current state of KNX ® devices. Moreover, it supports some functionalities similar to Amazon Alexa or Google Home, as new devices can be connected through third party APIs. Thus, it is possible to inject other non-KNX ® devices in a common infrastructure. A key endpoint that is used to populate the list of devices with external IoT devices is /add endpoint. This feature requires the user to perform an HTTP PUT request including the JSON Schema in the code snippet shown in Figure  4  below. This request will add a TD of the device into the local database, including its properties and interactions, as defined by the information provided and making it accessible from the devices list.
Once the threats are identified, their DREAD classification is determined, and for each given threat, a mitigation action is assigned. Table  2  shows this analysis. As it can be seen, most actions correspond with a organizational process placed to avoid the threat, for example placing physical barriers, performing reviews, backups and updates. The mitigation action of Controlled Network management, is defined using the Open Systems Interconnection (OSI) reference model  [38]. At Data link layer (OSI layer 2) the Virtual Machine (where the LLG is running in containerized form) is connected to the SHLL's physical network infrastructure through a Virtual Local Area Network (VLAN) following the IEEE 802. 1Q specification. At Network level (OSI layer 3) the LLG's VM is configured with dual network; one subnet is used to access the livinglab devices, each with its own IP address; another subnet makes the LLG present in a De-Militarized Zone (DMZ) network, which is populated with other protected servers.
This ensures communication uses state-of-theart confidential point to point encryption. The transmitted information is only readable between each public client and the LLC's endpoint. In the LLG's software stack, The application level (OSI layer 7) the passwords are stored at the database as hashed strings encrypted with sha256 algorithm (i. e. , 256 bits Secure Hash Algorithm) following Linux system's password shadow approach  [40]. Furthermore, password fields are escaped and validated, avoiding unwanted string injection in MongoDB queries. Additionally. Moreover, authentication and authorization mechanisms implemented are based on JSON Web Token (JWT) standard. A client, before starting any interaction with the devices, must be authenticated and at each service call, needs to provide the access token in the message header which is approved for authorization, being token maximum lifetime 24 h.
Certainly, property names such as "title" or "author" have no meaning to a computer, however, by using a shared vocabulary such as the one defined by Schema. org, machine-understandable meaning can be associated to data. Thus, when using self-descriptive data, it is possible to automate the interactions between systems with no human assistance. The process description to define context sensitive data mappings to bridge between two contexts with JSON-LD is shown in Figure  7 , representing the JSON-LD that includes two contexts (+C1, +C2). If we remove the contexts (-C) we have just a JSON, but when we add different contexts (e. g. , +C1 for SAREF, +C2 for universAAL) we can map data on different ontologies. Taking an example from from the Smart House, Figure  8  describes the TD displayed by LLG of a on/off device (bathroom light) linked to SAREF and universAAL device ontology, as implemented: This TD is describing the device named "Bathroom Light switch" as a Thing but also as a SAREF light and universAAL switch.
Infrastructure and Deployment The SHLL infrastructure is a premises components (KNX ® -BUS and IP-KNX ® ) and cloud components hybrid deployment. This section describes how the LLG has been deployed in the cloud by using the Kubernetes engine, ensuring a reliable management of external requests of interaction with the SHLL. The LLG is formed by a java application and a database in MongoDB, packaged in Docker images, which run in containers. The containers are then grouped in the same logical pod using kubernetes engine. The MongoDB database container, deployed in the Kubernetes pod, uses persistent volumes and persistent volume claims to store data, being those independent of pod life-cycles and able to retain data by restarting, reprogramming, and even deleting pods. Additionally, the database requires a Persistent Volume to store data, while the Persistent Volume Claims make requests for storage, allowing a user to consume abstract storage resources with varying performance properties, delegating the management reliability, availability, bandwidth and other variables to the cloud provider.
The following Kubernetes manifest shown in Figure  9  (used to create, modify and delete Kubernetes resources) describes single-instance MongoDB Deployment. The Mon-goDB container mounts the Persistent Volume at /var/lib/mongodb and then claims the provider for it. Figure  10  shows a manifest which describes the single-instance java Deployment. The java app will access the database deployment within the same pod and it is defined as a Service. The important point in the deployment of the java application is that the service is associated with a Load Balancer that delegates to the cloud provider the management of the availability of the service across different instance replicas of the servers. By using Persistent Volume, Persistent Volume Claim and Load Balancer, LLG's scalability, fault tolerance and availability is granted by the cloud provider that manages the Kubernetes cluster where the pod (that is instantiating the LLG) is running.
Interestingly, the properties conferred by WOT standard allow the composition of more complex and powerful services by combining each device's properties, data and available interactions, thus re-orienting and adding value to those elements and resources, revamping their original purpose with no extra costs. Another interesting feature successfully implemented is the inclusion of universAAL devices ontology. It might not be as popular as other ontologies on the domain, for this reason we have mapped also the SAREF ontology, which has more support from the community and the European commission. However, both ontologies complement each other, where universAAL has deeper taxonomy of home automation sensors and actuators, SAREF focuses more on the process, adding extra versatility to the solution in terms of device description and usability.
The proposed approach in this article differs from the presented examples in several aspects. Compared to eWot, our solution uses JSON-LD instead of RDF for a more human readable description to describe all resources, relying on ontologies to describe the context to translate each one into a machine-understandable format. Also our proposal does not use Software web enablement, as IoT-SIM, but rather implements a Secure, trustable and scalable API to deal with devices description, data and interoperability. Regarding the model presented by the authors in  [20] , we consider that our solution provides a substantial simplification to resolve what they call User request description and User request resolutions (aimed at retrieving data or information of an entity or interacting with it), as our solution is based on the standard and extensively used HTTP protocol.
Communications metadata was also included in the Thing Descriptor, which describes how the client platform can access things, supporting the implemented protocols and standards. Moreover, security metadata was added to the description, stating what is needed for secure access to a thing. In this case, the Security schema (JSON Web Token Bearer) to be used in order to access to specific content that exposes how to access and interact with the Smart House resources. Given the different deployment settings at the SHLL and the results presented, it is possible to state that the LLG achieved the expected results for device management and is viable to be implemented as a Smart Home resources management system, to overcome technology fragmentation in a scalable, trustable, and secure.
However, Herschel bands do not bene-fit from the negative K-correction because they probe emission near the peak of the dust SED rather than the Rayleigh-Jeans tail  (Blain, Smail, Ivison, Kneib, & Frayer 2002; Casey, Narayanan, & Cooray 2014) , thus Herschel datasets tend to have reduced sensitivity to unlensed DSFGs beyond z ∼ 2-3. Furthermore, this technique may select against high-redshift DSFGs with atypically warm SEDs, due to the degeneracy between dust temperature (or SED peak wavelength, λ peak ) and redshift. There have also been some attempts to constrain the z > ∼ 3 DSFG population through measurements of anisotropies in the Cosmic Infrared Background (CIB;  Maniyar et al. 2018 Maniyar et al. , 2021) )  though Herschel is largely insensitive to the high redshift tail. This paper presents data from a new large ALMA mosaic conducted at 2 mm (band 4), whose aim is to efficiently select DSFGs at z > ∼ 3 -4 and measure their volume density at these epochs with more precision than has been done before.
This program is called the Mapping Obscuration to Reionization with ALMA (MORA) Survey, for its focus on this especially early epoch of DSFG formation. The MORA survey is based on the hypothesis that 2 mm dust continuum is an efficient 'filter' for z > ∼ 3 -4 systems. Surveys conducted at 850µm-1. 2 mm benefit from the very negative K-correction, meaning that their expected flux density is not redshift dependent for a given fixed IR luminosity (i. e. at fixed L IR , S 850 ≈ C, where C is a constant without redshift dependence). Moreover, surveys at 2 mm have an even more extreme negative K-correction, such that 2 mm flux density increases with redshift (i. e. at fixed L IR , S 2 mm ∝ (1+z) η , where η ≈ 0. 5 -1. 0). As a result of this extreme negative K-correction, z > ∼ 3 galaxies of matched luminosity should appear brighter at 2 mm than those at z ∼ 1 -3.
DATA & OBSERVATIONS MORA Survey observations were originally designed to cover 230 arcmin 2 in two tunings, both in ALMA band 4 at 2 mm in the center of the Cosmic Evolution Survey (COSMOS) field  (Scoville et al. 2007; Capak et al. 2007; Koekemoer et al. 2007). Figure  1  shows the context of the proposed and observed MORA mosaics in the larger COSMOS field relative to other key datasets in the field. The COSMOS field was chosen as the location of the mosaic due to its rich multiwavelength data (discussed more in § 3. 1) and, specifically, the CAN-DELS portion of the COSMOS field  (Grogin et al. 2011; Koekemoer et al. 2011 ) was chosen for its even deeper near-infrared imaging with Hubble/WFC3. The nearinfrared depth will be significantly enhanced with the addition of James Webb Space Telescope (JWST) data from the PRIMER and COSMOS-Webb surveys.
Only P10-P20 are spatially adjacent such that they have been stitched together in one contiguous mosaic, and the P03 data is a separate mosaic of its own. This table states the final continuum RMS achieved in each position of the final mosaic product, yet the synthesized beam is measured for a representative subsample of pointings in each individual dataset. The last two rows state the resulting synthesized beams and total on-source time spent for the two end-product mosaics: the P03 mosaic and the P10-P20 mosaic. ing was centered on a local oscillator (LO) frequency of 147. 28 GHz (referred to as 'Tune147') and covered the frequency ranges 139. GHz. This tuning is sensitive to the detection of CI(1-0) at 2. 44 < z < 2. 52. The second tuning is centered on a LO frequency of 139. 03 GHz and covered the frequency ranges 131.
Several channels covering a 140 MHz wide frequency range centered on an atmospheric absorption feature at 142. 2 GHz were flagged for removal in the Tune147 datasets, while no channels were flagged in the Tune139 datasets. We determined that the channel flagging in the Tune147 datasets improved the RMS depth of the map by 3% on average (see also  Zavala et al. 2021). To analyze the computational time required to produce the full mosaic, we tested time binning the data by 5 s, 10 s, and 30 s. Time binning did substantially speed up the process of combining the visibilities with tclean and the resulting mosaic images were consistent with one another. For our final analysis, we use the 10 s time averaged maps. Our final mosaics 3 cover 184 arcmin 2 of the proposed 230 arcmin 2. Most of the area is in the P10-P20 mosaic (156 arcmin 2 ) while the remaining 28 arcmin 2 is in the P03 mosaic.
THE 2 MM-SELECTED SAMPLE Extensive tests of large extragalactic mosaics from ALMA  (Umehata et al. 2015; Dunlop et al. 2016; Hatsukade et al. 2016; Walter et al. 2016; Aravena et al. 2016; González-López et al. 2019 , 2020; Franco et al. 2018 Franco et al. , 2020) )  show that ALMA deep fields exhibit Gaussian noise in the absence of bright (SNR > 10) sources. This is demonstrated for the MORA mosaics in our accompanying paper, Z21, which analyzed the number counts and noise characteristics of this dataset in depth. In  Casey et al. (2018a)  we simulated completeness and contamination rates for mock ALMA datasets using the assumption that the noise is Gaussian. As argued in 2 While source confusion is often discussed in the context of single-dish (sub)mm maps, it should be noted that the density of 2mm sources on the sky is much lower than at 850µm or shorter wavelengths, and therefore confusion would only set in for very low resolution (∼1 beam), deep (<1 mJy RMS) 2mm maps.
COSMOS Ancillary Data We make extensive use of the rich ancillary data available in the COSMOS field including the two most recent generations of the optical/near-infrared photometric catalog, COSMOS2015  (Laigle et al. 2016 ) and COSMOS2020  (Weaver, Kauffmann et. al. , submitted). There are over 30 bands of optical/near-infrared (OIR) imaging that make up these photometric databases, from deep broadband coverage (with depths of 26-28 magnitudes for 5σ point sources) to intermediate and narrow band imaging campaigns (with depths 25-26 magnitudes). COSMOS also contains a wealth of multiwavelength data, from the X-ray  (Civano et al. 2012 (Civano et al. , 2016) )  through the radio  (Schinnerer et al. 2007; Smolčić et al. 2017). We include details of detections at these other wavebands where relevant.
Particularly important for this work are the other millimeter and submillimeter datasets in the field, including SCUBA-2 at 850µm  (Casey et al. 2013; Geach et al. 2017; Simpson et al. 2019) , 450µm  (Casey et al. 2013; Roseboom et al. 2013)   4  , Herschel PACS and SPIRE at 100-500 µm  (Lutz et al. 2011; Oliver et al. 2012 ), AzTEC at 1. 1 mm  (Scott et al. 2008; Aretxaga et al. 2011), and Spitzer at 24µm (Le Floc'h et al. 2005). In addition, a variety of ALMA archival datasets have built up in the field -see  Liu et al. (2018)  for details on the A3COSMOS project -at a range in observed frequencies, with the most common tunings in band 6 (1. 2 mm) and band 7 (870µm). We make use of these data to refine the spectral energy distribution fits for galaxies detected in the MORA maps.
MORA-9 The tenth source of the sample, MORA-9, has been detected at 850µm in  Simpson et al. (2019)  at 4. 4σ significance; it had not been detected in the earlier compilation of  Geach et al. (2017). Aside from its detection at 2 mm and 850µm, the source is also detected at 3. 6µm and 4. 5µm from Spitzer and at low significance in Ultra-VISTA K-band imaging. This source is undetected in all other datasets, but its K-band counterpart renders it present in the COSMOS2020 photometric catalogs with an OIR photometric constraint of z OIR = 4. 57 +1. 33  -1. 22. It is one of only two >5σ sources not already surveyed by ALMA at other wavelengths (the other being MORA-12). The ratio of 850µm-to-2 mm flux density is highly suggestive of a high-z solution; we derive a millimeter photometric redshift of z mm = 5.
5 +0. 6  -0. 8 for this source. Manning et. al. describe this source's characteristics and derive a hybrid photometric redshift for MORA-9 of z phot = 4. 3 +1. 3  -1. 0 which includes this millimeter photometric redshift along with OIR constraints using photometric redshift fitting techniques eazy and magphys. We adopt the Manning et. al. hybrid photometric redshift for the rest of this paper. The eleventh source of our sample, MORA-10, is well characterized as a known DSFG detected at both 450µm and 850µm from SCUBA-2 (named 450. 09; Casey et al. 2013) , with a near-infrared spectroscopic redshift of z = 2. 472 as reported in  Casey et al. (2015). The source is one of many DSFGs in the COSMOS field that sits in a protocluster environment at z ∼ 2. 5, the same structure that motivated the dual spectral tunings for the MORA program  (Chiang et al.