dataesr/scientific-paragraphs-categorization huggingface dataset:
Captioning system understanding Systems are conditioned by training datasets to produce sentences with certain properties (e. g. length), which limits their ability to fully describe the acoustic scene in a single caption. When tasked with producing multiple captions, some systems may output variations of the same sentence while others may describe the scene more comprehensively at the cost of lower precision. Because SPICE+ compares semantic elements extracted from captions, it can also enable better understanding the behavior of captioning systems in such conditions. 4 Full results and technical reports at dcase. community/challenge2022 As a first experiment in this direction, SPICE+emb is computed for the DCASE2022 challenge baseline with varying number of generated captions from 1 to 20, obtained with a beam size of 25.
CONCLUSION We introduced SPICE+, a modification of SPICE including pre-trained language models for dependency annotation and graph comparison. The metric achieves competitive accuracy on a candidate ranking benchmark, but should be used in combination with a fluency measure due to its sensitivity to grammatical errors. Compared to full sentence embedding comparison, SPICE+ is more interpretable as it evaluates individual semantic elements. It is also adaptable through its hyper-parameters to the needs of specific applications that may arise in the community. Still, some improvements should be investigated in future work. Parts of the captions are currently omitted from the graph, such as adverbs. The similarity between same-graph tuples is not accounted for in the score computation, which gives more importance to nodes with multiple attributes or relations.
Abraham et al. 2018)  and exoplanets (e. g. de Beurs et al. 2022) , or classifying observations (e. g. Wu et al. 2019; Walmsley et al. 2021; Whitmore et al. 2021). In this study, we develop NNs that can efficiently analyse numerous spectra in the optical wavelength range of young low-mass stars. We prepare our networks to analyse data observed by the Multi Unit Spectroscopic Explorer (MUSE) of the Very Large Telescope (VLT) adopting the wavelength coverage and spectral resolution of MUSE. In the follow-up paper, we will apply our tool to the spectra of young stars in the Carina nebula that were observed with VLT/MUSE. We adopt the conditional invertible neural network (cINN) architecture developed by  Ardizzone et al. (2021). Estimating physical parameters from observed measurements is a non-trivial task.
Because the information we obtain from observations is limited due to information loss during the forward process (i. e. translation from physical systems into observations), different physical systems can be observed similarly or almost identically, which we call a degenerate system. The cINN architecture is specialised to solve the inverse problem of the degenerate system (i. e. from observations to physical systems). In particular, cINN has its own advantage in that cINN always provides a full posterior distribution of the physical system without any additional computations. In astronomy, the cINN approach has so far been used to characterise the internal properties of planets  (Haldemann et al. 2023) , analyse photometric data of young stars  (Ksoll et al. 2020) , study emission lines in H II regions  (Kang et al.
2022) , or infer the merger history of galaxies  (Eisert et al. 2023). The cINN architecture adopts a supervised learning approach that learns the hidden rules from a number of well-labelled data sets of physical parameters and observations. Because it is difficult to collect a sufficient number of well-interpreted real observations, synthetic observations have commonly been used instead to generate enough training data. In this study, we use Phoenix stellar atmosphere libraries (e. g. Allard et al. 2012; Husser et al. 2013 ;  Baraffe et al. 2015)  to train cINNs. Selecting the Settl, NextGen, and Dusty Phoenix libraries, we introduce three cINNs (Settl-Net, NextGen-Net, and Dusty-Net) that were trained on each of these libraries. A few studies have developed NNs to analyse low-mass stars from photometric or spectroscopic data (e.
Moreover, our network provides a posterior distribution by adopting a cINN architecture, which is useful for studying the degeneracy between parameters. In this paper, we focus on validating the performance of the three cINNs. We evaluate our networks not only on Phoenix synthetic observations, but also on real spectra of 36 young low-mass stars to investigate how well our cINNs work on real observations. These stars are template stars in the class III phase that have been well interpreted in the literature (e. g. Manara et al. 2013 Manara et al. , 2017;; Stelzer et al. 2013). The paper is structured as follows. In Sect. 2 we describe the structure and principles of cINN and explain implementation details on the machine-learning side. In Sect. 3 we introduce our three networks and three training databases.
Databases and networks We analysed the cINN performance based on each of the three spectral libraries described in the previous section. Accordingly, we constructed a training data set for each spectral library using the interpolation scheme we outlined. For the target parameter space, we adopted the limits described below. For NextGen and Settl, we limited T eff to the range of 2600 to 7000 K and log(g/cm s -2 ) from 2. 5 to 5. The Dusty library has an overall smaller scope, and therefore we can only probe from 2600 to 4000 K in T eff and from 3 to 5 in log(g/cm s -2 ) here. For A V , we selected the same range of 0 to 10 mag for all three libraries, where we used the  Cardelli et al. (1989)  extinction law with R V = 4. 4 to artificially redden the model spectra. We chose R V = 4. 4 considering the application of our networks to the Carina nebula  (Hur et al.
2012)  in the follow-up study. As some of the template stars used in this paper (Sect. 4) are dereddend assuming R V = 3. 1, we also experimented with training data sets using R V = 3. 1. We found no significant difference in our main results and therefore continue to use R V = 4. 4 in this study. In terms of wavelength coverage, we matched the range of the template spectra described in Sect. 4 (i. e. ∼5687 to ∼9350 Å) and adopted the MUSE spectral resolution by subdividing the wavelength interval into a total of 2930 bins with a width of 1. 25 Å. 1 We downloaded the theoretical spectra from the websites https:// osubdd. ens-lyon. fr/phoenix/ and http://svo2. cab. intacsic. es/theory/newov2/ A175, page 3 of 26  A&A 674, A175 (2023)  Additionally, we normalised the spectra to the sum of the total flux across all bins.
To generate the training data, we opted for a uniform random sampling approach, where we sampled both T eff and g in log space and only A V in linear space within the limits specified above for the three libraries. We generated a total of 65 536 synthetic spectra models for each library. We also experimented with larger training sets, but found no significant increase in the predictive performance of our method, such that we deemed this training set size sufficient. Finally, we randomly split each of these three initial databases 80:20 into the respective training and test sets for the cINN. The former subsets mark the data that the cINN was trained on, whereas the latter were withheld during training and served to quantify the performance of the trained cINN on previously unseen data with a known ground truth of the target parameters.
Validations with synthetic spectra In this section, we validate whether the trained networks learned the physical rules hidden in the synthetic Phoenix models well. We use the test set of each database, that is, the synthetic models that are not used for the training, but share the same physics as the training data. As mentioned in Sect. 3. 2, we only used 80% of the database for training and retained the rest for validation. Each test set consists of 13 107 test models.
Prediction performance We introduce an accuracy index to evaluate the parameter prediction performance of the network. The accuracy of the prediction is defined as the deviation between the posterior estimate of the parameter and the ground-truth value (x * ) of the test model. In this section, we calculate the accuracy on the same physical scales as we used to build the databases in Sect. 3. 2, meaning that we use the logarithmic scales for the effective temperature and surface gravity and the linear scale for the extinction magnitude. We either used all posterior estimates sampled for one test model or the maximum a posteriori (MAP) point estimate as a representative. To determine the MAP estimate from the posterior distribution, we performed a Gaussian kernel density estimation on a 1D posterior distribution and determined the point at which the probability density maximises, similar to the method used in  Ksoll et al.
(2020)  and  Kang et al. (2022). In most parts of this paper, we use the MAP estimate to quantify the accuracy of the prediction. We evaluated the three networks (Settl-Net, NextGen-Net, and Dusty-Net) by using all 13 107 test models in the corresponding test set. For each test model, we sampled 4096 posterior estimates and measured the MAP estimates for three parameters from the 1D posterior distributions. In Fig. A. 1 we present 2D histograms to compare the MAP values estimated by Settl-Net with the true values of the entire test models. Settl-Net predicts all three parameters extremely well, so that the data points all lie on the one-to-one correspondence line. The NextGen-Net and Dusty-Net also show extremely good results on the test set. The results of the other two networks are very similar to the result of , and therefore we do not include figures of them in this paper.
To quantify the average accuracy of the network for multiple test models, we measured the root mean square error (RMSE) A175, page 4 of 26  Kang, D. E. , et al. : A&A proofs, manuscript   following RMSE = Σ N i=1 (x MAP i -x * i ) 2 N. (6) In the case of the Dusty-Net, the training ranges of the effective temperature and surface gravity are narrower than the range of the other two networks. As the total number of models is the same for all three databases (i. e. 65 536 models), the number density of the model for the effective temperature and surface gravity in the Dusty database is higher than the other two. We therefore defined the normalised RMSE (NRMSE), NRMSE = RMSE x training max -x training min , (7) by dividing the RMSE by the training range. In Table  2  we list the RMSE and NRMSE of each parameter for three networks.
Resimulation To further validate the prediction results of the cINN on the synthetic test data, we verified whether the spectra that correspond to the MAP estimates match the respective input spectrum of  A V log T eff log(g) A V Settl 4. 260 × 10 -4 1. 211 × 10 -2 7. 893 × 10 -3 9. 904 × 10 -4 4. 846 × 10 -3 7. 893 × 10 -4 NextGen 3. 064 × 10 -4 6. 742 × 10 -3 6. 499 × 10 -3 7. 123 × 10 -4 2. 697 × 10 -3 6. 499 × 10 -4 Dusty 7. 274 × 10 -5 1. 573 × 10 -3 2. 517 × 10 -3 3. 888 × 10 -4 7. 863 × 10 -4 2. 517 × 10 -4  Notes. For each parameter and each network, we present the RMSE, the mean accuracy of the MAP estimates, and the RMSE normalised by the parameter range covered in the training data (NRMSE). The test set of each network is drawn from the corresponding synthetic database. each test example.
MAP estimate T eff (K) [∆ lit ] log(g/cm s -2 ) [∆ lit ] A V ( The stellar parameter values (i. e. effective temperature, surface gravity, and extinction) provided by previous papers  (Manara et al. 2013 (Manara et al. , 2017;; Stelzer et al. 2013 ) are listed in Table  1. The 36 template stars include cases for which the literature value of the effective temperature exceeds the training range of the cINNs, or for which the literature gravity value is lacking. Two out of 36 stars have temperatures below 2600 K, which is beyond the temperature range of all three databases. Moreover, 14 stars with temperatures between 4000 and 7000 K exceed the training range of the Dusty-Net. These stars were excluded from some analyses in the following sections. Using each network, we sampled 4096 posterior estimates per star and measured MAP estimation for three parameters.
In this section, we showed that the discrepancy between the network MAP prediction and literature value varies with the characteristics of the stars. Based on the overall results, a star of M6. 5-K1. 0 (2935-5000 K) for Settl-Net, M4. 5-K1. 0 (3200-5000 K) for NextGen-Net, M5. 5-M0. 0 (3060-4000 K) for Dusty-Net agrees especially well with the literature values. Settl-Net agreed best with the literature values overall. Dusty-Net also agrees well for stars whose temperature is within the Dusty database of 2600-4000 K. NextGen-Net has relatively large errors compared to the other two, but it still shows reliable performance for early-type stars. Because Settl-Net and NextGen-Net cover a wider range of temperatures (i. e. 2600-7000 K) and gravity (2. 5-5 log(cm s -2 )) than Dusty-Net, Settl-Net is the best choice among the three networks.
Important features for M-, K-, and G-type stars We drew three groups from the test set according to the temperature of the test model: M-type (2600-3850 K) group, K-type (3900-5110 K) group, and G-type (5150-6000 K) group, and evaluated the feature importance across the wavelength for each group per network. In the case of Dusty-Net, we only evaluated this for the M-type group because the highest temperature of the Dusty database is 4000 K. Figure  9  presents the feature importance of Settl-Net for M-type stars. To compare the important features with the locations of stellar parameter tracers existing in the real spectrum, we plot the median flux of M-type template stars in the first row and indicate the locations of several tracers of stellar parameters (Table  5)  Allen & Strom 1995), TiO 6080-6390, 7053-7270 Å (T eff ,  Kirkpatrick et al.
The cINN adopts a supervised learning approach, meaning that the network is trained on the database consisting of numerous well-labelled data sets of physical parameters and observations. However, it is difficult to collect a sufficient number of well-interpreted observations in reality. Therefore, we instead used synthetic observations to generate enough training data. In this work, we used three Phoenix stellar atmosphere libraries (i. e. Settl, NextGen, and Dusty) to produce the database for the training and evaluation of the network. By interpolating the spectrum in the temperature -gravity space and adding the extinction effect on the synthetic spectra, we produced a database for each Phoenix library consisting of 65 536 synthetic models. To produce the databases, we randomly sampled three parameters from the given parameter ranges.
The Settl and NextGen databases cover the temperature range of 2600-7000 K and the log(g/cm s -2 ) range of 2. 5-5. The Dusty database covers the temperature of 2600-4000 K and log(g/cm s -2 ) of 3-5. All three databases have extinction values within 0-10 mag. Then, we built and trained cINNs using each database, but only used 80% of the synthetic models in the database to train the network and retained the rest for evaluation. We presented three cINNs that learned different Phoenix atmosphere models: Settl-Net, NextGen-Net, and Dusty-Net. We validated the performance of our cINNs in various methods. Our main results are listed below. 1. All three networks provided perfect predictions on the test set with an RMSE lower than 0. 01 dex for all three parameters, demonstrating that the cINNs are well trained.
Acknowledgements. This work was partly supported by  European Union 's  Horizon 2020 research and innovation program  and the  European Research Council  via the  ERC Synergy Grant "ECOGAL"  (project  ID 855130 ), and the  Marie Sklodowska-Curie grant   DUSTBUSTERS  (project No  823823 ), by the  Deutsche Forschungsgemeinschaft (DFG)  via the  Collaborative Research Center "The Milky Way System " ( SFB 881 - funding  ID 138713538 - subprojects  A1 ,  B1 , B2 and B8), by the  Heidelberg Cluster of Excellence  ( EXC 2181 -390900948 ) " STRUCTURES ", funded by the  German Excellence Strategy , and by the  German Ministry for Economic Affairs and Climate Action in project "MAINN"  (funding  ID 50OO2206 ). We also thank for computing resources provided by the  Ministry of   Science, Research and the Arts (MWK)  of the  State of Baden-Württemberg  through bwHPC and  DFG  through grant  INST 35/1134-1 FUGG  and for data storage at SDS@hd through grant  INST 35/1314-1 FUGG.
Trust is associated in SR with the aspects of the social system where a technological system is used its context. Context of use SR influence user requirements (FR and other SR) as well as product qualities (FR and NFR). In this work, we focus on trustworthiness requirements (TwR) that can be associated with FR and NFR contributing to trust between the entities (e. g. , a user and a software product) in a given sociotechnical system (see Figure  1 ). We define trustworthiness requirement as a statement made by a trustor about the expected trustworthiness of a trustee. This statement has to clearly express an operational, functional, design or other characteristic, which, according to trustor's believes, positively impacts trustworthiness of this trustee and interaction between the two. The nature of trustor, trustee, relationship between them as well as trustworthiness factors can vary depending on the type of trust (see Table  1 ).
Similar to SR from  [36] , TwR for a given product can be emergent and can vary depending on characteristics of a trustor (e. g. , her propensity to trust, perception of risk) and the context where the interaction with the product will take place; if explicitly defined, TwR can change (extend) the set of product requirements (see TwR' in Figure  1 ). Whereas trustworthiness is considered as an important factor of product satisfaction  [34]  and recognized as an antecedent of adoption, little research explicitly addresses trust and trustworthiness as a part of system requirements. In  [37]  the role of trustworthiness in the software development lifecycle is examined. Trustworthiness requirements are derived from user trust concerns and include usability, availability, reliability, transparency.
Trust and Trustworthiness in Blockchain In practice, digital trust solutions consist in implementing a set of control mechanisms, which intend to modify the feasible set of alternatives (undesirable scenarios) that can be realized within a trustor-trustee interaction in a digital environment. Paraphrasing Gambetta  [1] , digital trust can be seen as "a device for coping with the freedom of others", which increases the probability that the other party will not (be given an opportunity to) act in a harmful way. Blockchain technology enforces digital trust by providing a set of such control mechanisms as intrinsic features. Blockchain technology has emerged as a potential solution to cope with mistrust in traditional (centralized) institutions and online intermediaries in general  [8]. Blockchain can be defined as a distributed database that allows its users to transact in a public and pseudonymous setup without the reliance on an intermediary or central authority  [38].
Related Works Trustworthiness of blockchain solutions is widely discussed in the related secondary studies. In  [42] , the authors evaluate the potential of blockchain against traditional databases in four domain areas, including required trust assumptions, context requirements, performance characteristics and required consensus mechanisms. The literature review in  [43]  examines how trustworthiness of data provider ("the oracle") is addressed by blockchain solutions. In  [44] , the authors evaluate blockchain solutions and discuss requirements and considerations related to trust for identity management in healthcare domain. The literature review in  [10]  examines the barriers to blockchain adoption and highlights the issues related to high computing power requirements and implementation costs.
Search Strategy and Selection Process The flow diagram adopted from PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses)  [49]  presents an overview of the source selection process in Figure  2. Using the PICOC criteria  [20] , we define the search terms forming the following search string: "blockchain" AND ("trust" OR "trustworthy" OR "trusted") AND "requirement" AND ("architecture" OR "design" OR "development" OR "engineering" OR "adoption"). We limit the publication year (PUBYEAR < 2023) to obtain a consistent set of publications that will not be affected by more recent apparitions. We conducted an automated search in the selected databases and identified 793 records in total. After removing duplicates and non-primary sources (e. g. , proceedings, books etc. ) we kept 415 records for screening.
2: Screening Relevant Publications. We screened titles and abstracts of identified records and eliminated publications based on the following exclusion criteria: EC1: A study is unavailable for retrieval EC2: A study is not a peer-reviewed publication EC3: A study is not primary research EC4: A study does not focus on requirements EC5: Issues or requirements motivating the solution are not related to trust or trustworthiness. We kept 78 records for the full text assessment. 3: Eligibility Assessment. We examined the full text of the preselected publications for eligibility based on the exclusion criteria EC3-EC5. The full text assessment was executed by the two authors independently; the results were compared and the conflicts were resolved. 48 records were kept for the final data set. 4: Snowballing and Final Data Set.
We conducted backward and forward citation analysis of the eligible publications from the previous step (a so-called "snowballing" technique) using other databases (e. g. , Google scholar) and identified a set of 26 records which was reinjected into the process. These records were screened and assessed for eligibility following the steps above. 18 records have been eliminated. The selection process resulted in a final data set of 56 articles (  [7] ,  [11] ,  [16] -  [18] ,  [30] ,  [40] ,  [49] -  [97] ). The overview of the selected studies is presented in Table  2. In our further analysis, we use consecutive enumeration of the studies: S1-S56.
Data Extraction, Analysis and Synthesis Table  3  defines the data items that have been systematically extracted from the selected sources. Each data item is defined in connection with one of the research questions. Year of publication and Application domain provide a descriptive information about our data set and are not explored any further in this study. Overview of the extracted data is presented in Table  2. The results of our data analysis are presented in the next section. For the analysis of contributions, we used the guidelines of Wobbrock  [98]  to code the contribution types and research outcomes. For the qualitative analysis of trustworthiness requirements, first, we examined which underlying theories of trust are used in the studies and to which definition of trust (social or technology-centric) the studies adhere.
Next, we extracted text evidences of trust issues and trustworthiness requirements. Further, the extracted data was coded by the authors following both semantic and latent approaches  [99]. We defined the codes for our trustworthiness requirements based on the trustworthiness properties specified by the related secondary studies (Table  4 ). The codes most frequently used in these studies are: Security, Privacy, Data integrity, Confidentiality, Availability, Reliability, Accountability. Other codes used are: Decentralization, Costs/resource efficiency, Traceability, Immutability, Transparency, Resilience, Authenticity. During the analysis, the set of codes was refined and new codes have been added. For instance, considering that Security is closely associated with other categories (e. g. , Confidentiality, Integrity, Availability, Authentication) in the literature, we removed it from our code list.