dataesr/scientific-paragraphs-categorization huggingface dataset:
An interesting outcome was that the BROW baseline seemed to do better than other baselines; we observe this phenomena because in the BROW mobility model, people select to move to adjacent locations, where they stay for some time. Overall, this produces semantic trajectories largely located in only one area, which allows the distance to be approximated with a simple maximum. We observe this phenomenon for the GeoLife dataset as well. Clearly, SmartSPEC was able to significantly outperform all baselines in the campus scenario. For the GeoLife dataset, we made splits of 1 month, but kept the same binning strategy as described above. Since this dataset spans over 2 years, we report the range of semantic trajectory distances (km) computed using the boxplots in Fig. 12(a). Our results similarly show that SmartSPEC was able produce semantic trajectories in a large city setting that were close to that of real-world semantic trajectories: the average percentage difference was -13% compared to the 177%, 18%, 159% and 159% of the RAND, BROW, LÉVY and EPR baselines, respectively.
A comparison of the baselines directly against SmartSPEC also reveals that the average distance across months was 4. 4, 1. 4, 2. 9 and 2. 9 times larger. It is clear that the RAND, LÉVY, and EPR baselines were unable to produce realistic semantic trajectories: the resulting values were significantly larger than what was expected. We note that for the BROW baseline, we observed the same phenomena as with the campus dataset: the produced semantic trajectories are mostly in one area. However, since the GeoLife dataset is on a city-scale, the effect of producing semantic trajectories in one area is more significant -people will typically not walk across the entire city to get from one place to the next. Overall, SmartSPEC outperforms the baselines for the GeoLife dataset.
Evaluating generated occupancy We evaluate the realism of the synthetic datasets produced by SmartSPEC with respect to occupancy of each space. Our experiments continue using the same datasets that were generated for the semantic trajectory analysis in the previous section, and use the same mobility models as baselines. We computed the occupancy of each space in 10 min intervals. The results for the campus dataset, as listed in Table  3 , show that the occupancy of spaces inferred by the semantic trajectories of people generated by SmartSPEC was close to occupancy found from our real-world data. On average, there was a 36% change in the occupancy counts per space in the synthetic dataset produced by SmartSPEC, compared to the 120%, 96%, 114%, and 107% change in the datasets produced by the RAND, BROW, LÉVY, and EPR mobility models, respectively.
When compared against SmartSPEC, these baselines produce We note that the reported standard deviations for the real row measure the deviation of one week of data against each of the other weeks, while the standard deviations for SmartSPEC and the mobility models are across multiple simulated runs. We observe that in general, the average occupancy counts per space for SmartSPEC do not vary significantly across multiple simulated runs. This suggests, along with the corresponding results of the average trajectory similarity in Table  2 , that although people take different trajectories to move throughout the space, the attendance for events inside these spaces is still relatively stable. Thus, SmartSPEC does much better than each of the baselines with respect to occupancy in the campus dataset.
We present the results for GeoLife in Fig. 12 (b) as a boxplot which shows the average occupancy difference per space, over all 1-month dataset splits. The results show a -37% difference in occupancy when comparing real space occupancy and SmartSPEC occupancy. In contrast, the RAND, BROW, LÉVY, and EPR baselines all have around a 68. 5% difference. In fact, each of the baselines also has similar behavior in terms of the distribution of the occupancy difference found: they have the same average and interquartile range, with a heavy, one-sided tail. This implies that most of the 1-month datasets that were synthetically produced are similar to each other, but that there was a number of outlying datasets skewed results to high occupancy levels. We observe that SmartSPEC produces datasets that vary less from real-world data; there are also fewer outlying occupancy differences.
Evaluating synthetic sensor observations We evaluate the sensor observations produced by our implementation for a number of people-activated sensors (i. e. , sensors that produce observations based on the presence/absence of people): WiFi APs, door sensors, and temperature sensors. We compare our sensor data against baseline methods of producing synthetic sensor data at scale, for varying scenarios. Our validation is performed based on the campus dataset only because many of the implemented sensors are used within the scope of a building. In our implementation of people-activated sensors, we used domain knowledge of the typical operation of these sensors in a smart building setting, as they interact with people and their activities. We used a trajectory dataset as a ground truth for the activities occurring in the smart space.
25 • F for every hour they remain in the space. To generate validation data, we use the trajectory datasets generated for the experiment in Section 7. 2, which we consider as a ground truth for the activities in the smart space. This dataset and the parameters used for its generation (i. e. , number of people, spaces, etc. ) are provided as input to both the sensor data generation baselines, as well as our sensor observation generation module. In our experiment, we also explore the effects of several hypothetical changes to the underlying semantics of the smart space, which were inspired by real use-cases and recent world events. Specifically, we examine building activity as observed by synthetic sensors for the following hypothetical scenarios: (i) social distancing (Scenario 1): the capacity of all spaces and attendance for events are reduced to 1/3 of its original values; (ii) social distancing/work from home (Scenario 2): the conditions of case (i) are applied, and the number of people in the simulation is reduced to 1/4 of its original value; and (iii) scalability in number of people (Scenario 3): the number of people is scaled up by 25%.
For each case, we generated 3 sets of sensor observation datasets, and average the results across all generated datasets, across all weeks. Correlation with the number of people. We first examined the degree to which the sensor data produced by our people-activated sensors correlated with the number of people that were present in the space, as determined by the ground truth trajectory dataset. This was accomplished by computing an appropriate time-series of the activation of the sensor (i. e. , the recorded observations). Then, a line of best-fit to correlate the number of people present with this timeseries was found. For WiFi AP sensors and door sensors, the computed time-series counted the number of times that a connection was made/sensor was activated in 15 min intervals for all sensors.
The computed time-series for temperature sensors consisted of the recorded observations in 15 min intervals for all sensors. In Table  4 , we report the best R 2 value found from fitting a linear regression line between the number of people in the sensor's covered spaces over time (derived from trajectory dataset), and the associated sensor time-series, for various people-activated sensors in different scenarios. Intuitively, the R 2 value is a statistical measure that represents the ability of the fitted linear regression model to explain the correlation between two variables: typically, the closer R 2 is to the value 1, the more variability is explained by the linear regression model. In general, our results show that SmartSPEC was able to produce synthetic sensor data that adhered to the semantics of the underlying smart space.
Comparing the three types of sensors in the original scenario (where no semantics were changed), we find that 69% of the variability between the number of people present and the produced data could be explained, as opposed to 36% and 53% for the STAT and SEED baselines, respectively. However, we find several other interesting results between SmartSPEC and the baselines. First, in the original scenario, we note that the SEED baseline significantly outperformed the STAT baseline in generating data correlating to the number of people for WiFi AP sensors and door sensors. In particular, the trained STAT ML models attempt to create data based on a deterministic prediction for the next observation time, and a probabilistic model for the next visited sensor. This produces a ''new'' dataset that drops important dependencies between underlying smart space entities.
On the other hand, in the SEED baseline, the noise added to a given seed dataset did not fundamentally change attendance counts for sensors. The opposite is true for temperature sensors: the learned STAT ML model was able to realistically predict a temperature given the current time, while too much noise was added to the dataset generated by the SEED baseline. However, we note that the average R 2 value for both baselines is smaller than that for SmartSPEC, which shows that SmartSPEC was able to utilize the underlying smart space semantics best. As we evaluate scenarios for which the semantics of the smart space have changed, we find that only SmartSPEC was able to adjust for the differences in the number of people present to activate sensors: the average R 2 across all new scenarios remained consistent, with little change.
In contrast, R 2 values for each of the sensors in the STAT baseline decreased by an average of 10%, 10% and 8% for the three different scenarios, while the R 2 values in the SEED baseline decreased by an average of 12%, 13% and 12%. This result indicates that both baselines were unable to produce an appropriate set of sensor observations that adequately considered the presence of people. In essence, for people-activated sensors, the effort taken to simulate trajectories and semantics increases the realism of produced sensor datasets. From this analysis, one important question that arises is why SmartSPEC produced sensor observation data that did not directly correspond with the exact number of people in the space (i. e. , R 2 = 1). This is due to the simplistic implementation of the sensor observation functions used in the experiment.
In our implementation of the functions, we note that there is a lingering effect of people in spaces that are oftentimes captured by sensors. For example, both WiFi AP sensors and door sensors are largely affected by the connections and activations made by people moving through to space to get from one place to the next. For temperature sensors, we used a weighted sum between the previously recorded values and the current value: the temperature of a room is partially determined by the temperature in the previous time step. Note that SmartSPEC enables the definition of more sophisticated functions by users. Outliers in generated sensor data. Next, we explore the realism of the generated sensor dataset with respect to the number of ''outliers'' that were produced. Intuitively, we wish to count the number of times where a sensor produced observations that did not correlate well with the number of people covered by the sensor -i.
e. , a large/small number of observations corresponding to a small/large group of people. To this end, we first constructed a time-series consisting of the sensor, the number of sensor activations (WiFi AP, door) / observation value (temperature), and the actual attendance as dictated by the trajectory dataset for the original scenario. Then, the time-series was partitioned on the sensor and the attendance in groups of 5 (i. e. , 0-5 people, 6-10 people, etc. ) to yield sets of sensor observations during times where there are similar attendance numbers. The mean and standard deviation of each set is computed, which represents an expected observation value and a corresponding measure of spread for each sensor and attendance count. We define an outlier as a sensor observation that falls outside 2 standard deviations (as computed from the original scenario) of the respective mean (as computed from the evaluated scenario).
Note that we only use the standard deviation from the original scenario as changing the space semantics should not have an effect on how a given number of people interact with sensors (e. g. , if there are 30 people in a space, then their effect on temperature sensors should be the approximately the same regardless of scenario). In Table  5 , we report the average number of outliers over all sensors and groups of attendance counts using the procedure described above. Several conclusions can be made from the results in Table  5. In particular, we note that for the original scenario, the average number of outliers found across all sensor generation methods were fairly comparable. This is expected because both baselines generate their respective datasets as a function of a provided trajectory dataset, which itself was generated using the same underlying semantics as the evaluation trajectory dataset.
On the validity of SmartSPEC datasets While SmartSPEC is designed to be flexible in its ability to allow users to construct and generate various hypothetical scenarios of interest, there are several threats to the validity of the produced datasets. We first acknowledge the inherent faults associated with leveraging any seed dataset. Our approach is instantiated using a connectivity seed dataset, as mentioned in Section 4. We believe that this is a useful approach, since such datasets are becoming more prevalent in organizations today. However, this relies on the assumption that sensor data is directly related to people, as captured through WiFi APs and Bluetooth connections. In using this data, preprocessing steps derived from domain expert knowledge may be required, depending on the granularity of coverage (e.
g. , associating coverage regions of WiFi APs with the rooms in a building). This can ultimately affect the quality of generation. Domain-specific biases that exist in a seed dataset can also largely reduce the utility of learned models towards new scenarios and applications. This, along with the implicit assumption that any seed dataset must contain sufficient examples of the desired behavior from which to learn, places limitations on the types of scenarios that can be realistically generated using a seed dataset. To mitigate the impact of such biases, we introduce constraints in Section 3. 2 defined by a human-in-the-loop to encode and enforce complex, external domain knowledge. In the real world, anomalies, errors and faults can create outliers in the generated data. Specifically, the question of how outliers should (or should not) be generated, and their relevance for the modeled scenario is a challenge.
This is connected to the uncertainty present in real human behavior. While the design of SmartSPEC relies upon event-driven processes to generate realistic datasets, implicit assumptions on the trajectories of people, (e. g. , schedule adjustments through time profiles to attend assigned events) are made. In general, we acknowledge that other methods of generating data (and handling outliers) may also be appropriate, depending on the application and scenario at hand. This also extends to the evaluation of realism for such synthetic data. For example, our analysis for the trajectory distance of datasets leveraged the properties of the Fréchet distance and trajectory matching for a set of control variables. Notably, these choices can change with the definition of realism for varying domains.
Lastly, the utility of the resulting datasets is largely dependent upon the quality of the provided input models; that is, models which provide few details about the semantic smart space are unlikely to yield robust datasets for testing/evaluation. We plan to enhance the SmartSPEC toolkit by adding data processing modules and heuristics that can help determine the quality of the seed dataset. As can be observed from the above discussion, the validity can be improved by incorporating more domain-specific knowledge. Our objective in SmartSPEC is to facilitate a rigorous approach to specify, capture and tune the domain-specific semantic models for the generation of new data, with the help of local experts and other stakeholders.
Conclusions and future directions In this article, we presented SmartSPEC, an event-driven smart space simulator that produces customizable smart space datasets using semantic models of spaces, people, events and sensors. Our approach employs ML techniques to extract metamodels depicting profiles of people and types of events from input connectivity data, which are leveraged to define new scenarios and generate both semantic trajectory datasets and sensor observation datasets. Such input can also be constructed manually using the SmartSPEC graphical tool. To evaluate the realism of synthetic data, we introduced a new structured methodology that assesses various aspects of smart space datasets, namely trajectories of people and occupancy of spaces. Our experimental evaluation shows the feasibility of SmartSPEC in generating realistic smart space datasets in complex real-world contexts.
Our results show that SmartSPEC outperforms traditional mobility model baselines where trajectories are simplified to their endpoints. Additionally, SmartSPEC produces synthetic sensor datasets that are able to preserve the semantics of the underlying space, even when there are large changes in the number of people or their interactions with the underlying space. However, modeling complex scenarios accurately and efficiently at varying levels of granularity is still an ongoing challenge in the research community. SmartSPEC has been leveraged in the planning and creation of new, diverse spaces and scenarios; it has been used to generate synthetic data for defense applications  [61] , smart assisted living  [62]  and modeling and generating airports and shopping malls. Data generated by SmartSPEC can also be utilized for technology validation at different levels of the system stack, including: application development in smart spaces  [63] , energy-efficient building performance  [64] , sensor network planning and operator placement  [65, 66] , middleware platforms for timely, reliable data exchange  [67] , Edge-to-Cloud computation for predictive analytics  [68] , and formal methods for faithful execution of pervasive applications  [69, 70].
Acknowledgments This material is based on research sponsored by  Defense Advanced Research Projects Agency (DARPA), United States  under Agreement No. FA8750-16-2-0021. The  U. S. Government  is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of  DARPA  or the  U. S. Government. This work is also supported by  National Science Foundation NSF  Grants No. 2032525 ,  1952247 ,  2008993  and  2133391.
Radial velocities In an attempt to revisit the physical and orbital properties of the HD 196885 system, we considered all data from past radial velocity surveys already published in  Chauvin et al. (2011)  for the primary host HD   Correia et al. 2008; Fischer et al. 2009; Chauvin et al. 2011, and this work). SOPHIE data were acquired in High-resolution mode as part of the program dedicated to the follow-up of ELODIE candidates. Data from 2007 to June 2011 were reduced thanks to the SOPHIE pipeline  (Bouchy et al. 2009 ). In June 2011, an update of the instrument was done. It consists mainly in the addition of octogonal fibers to light guiding from the telescope to the spectrograph  (Bouchy et al. 2013 ). Data after this date were then reduced as in  Heidari et al. (2022).
Here, the GRAVITY interferometer only observed the A and B components. The observations were pre-processed with the Public Release 1. 5. 0 (1 July 2021) of the ESO Gravity pipeline  (Lapeyrere et al. 2014). The reduced data are then processed to extract astrometry using the GRAV-ITY python tools offered to the community 4. The astrometric values are presented in Table  3.
Resolving the astrometric wobble due to the giant planet HD 196885 Ab The main objective of our GRAVITY program was to measure the astrometric wobble in the separation of a binary system related to presence of the giant planet, and in such a circumstance be able to derive the orbital properties of the binary companion and the giant planets, but also to confirm the planetary nature of HD 196885 Ab. To date, such observation have only been performed in the context of the γ Cep system by  Benedict et al. (2018). Combining all the available measurements obtained from radial velocity, adaptive-optics imaging, speckle interferometry, and dual-field interferometry, we have revisited the system properties using a Bayes-based orbital elements estimation inspired in a previous study by our team to triple hierarchical stellar systems  (Villegas et al.
Acknowledgements. We would like to thank the staff of  ESO VLT/I  for their support at the telescope at  Paranal  and  La Silla , and the preparation of the observation at Garching. This publication made use of the SIMBAD and VizieR database operated at the  CDS, Strasbourg, France. This work has made use of data from the  European Space Agency (ESA)  mission Gaia (https:// www. cosmos. esa. int/gaia), processed by the Gaia Data Processing and Analysis Consortium (DPAC, https://www. cosmos. esa. int/web/gaia/ dpac/consortium). Funding for the DPAC has been provided by national institutions, in particular the institutions participating in the Gaia Multilateral Agreement. This work is partly based on data products produced at the  SPHERE Data Centre  hosted at  OSUG/IPAG, Grenoble. We thank  P.
Delorme  and  E. Lagadec  ( SPHERE Data Centre ) for their efficient help during the data reduction process. RAM and MV acknowledge partial support from  FONDECYT/ANID  Grant No. 1190038  and to the  Chilean National Time Allocation Committee  for their continuous support of our  SOAR Speckle survey of southern  binaries and multiple systems through programs  CN2018A-1 ,  CN2019A-2 ,  CN2019B-13 , and  CN2020A-19 ,  CN2020B-10 , and  CN2021B-17. CV and MV acknowledge support from the visiting program of the  CNRS French-Chilean Laboratory for Astrophysics. VF acknowledges funding from the  National Aeronautics and Space Administration  through the  Exoplanet Research Program  under Grant No. 80NSSC21K0394  (PI:  S. Ertel ). Based in part on radial velocities obtained with the SOPHIE spectrograph mounted on the 1.
331 VLTI/UTs GRAVITY 24-08-2021 59450. 195 VLTI/UTs GRAVITY 02-10-2021 59489. 151 SOAR HRCAM 20-10-2021 59507. 082 VLTI/UTs GRAVITY I I K1 I K1 I I K K K I K SI SI DBI SI DBI SI SI MED MED MED SI MED 3 3 21 3 2 2 2 3 3 3 3 3 400 400 35 400 30 400 400 20 12 12 400 12 0. 024 0. 024 2 0. 024 2 0. 024 0. 024 10 30 30 0. 024 30 1. 75 0. 72 0. 95 2. 9 1. 2 3. 4 0. 64 5. 0 0. 90 2. 6 1. 00 2. 8 4 https://version-lesia. obspm. fr:/repos/DRS_gravity/ gravi_tools3 5  The original software is available on GitHub: BinaryStars codebase: https://github. com/mvidela31/BinaryStars under a 3-Clause BSD License. Its evolution used in this study will soon be released. A114, page 4 of 11 Chauvin, G. , et al. : A&A proofs,  of the Bayesian inference algorithm for binary stars developed by Videla et al. (2022) , which is based on the No-U-Turn Sampler (NUTS) algorithm (Hoffman et al.