dataesr/scientific-paragraphs-categorization huggingface dataset:
Therefore, improving uniformity in the search and access of digital resources by improving the metadata dictionary and information models (sections 4. 1. 3. 2 and 4. 2. 3) will make our data more readily consumable by machine-learning algorithms and interoperable across domains, broadening our science and building connections to other domains. As noted in section 4. 1. 3. 2, however, extensions and rethinking of the SPASE schema may still be needed to support unique identification and thus discov-ery of ML-ready datasets. Engaging the community will be important for extending the SPASE schema and improving its effectiveness in servicing AI/ML data, as discussed in section 4. 1. 3. 2. The categories that are important to add will come into greater focus once the community reaches a minimal agreement on how they shall be defined.
Directly and indirectly, therefore, SPASE could help build a broader community by supporting data science methods. This will permit space physics to embrace trends toward open science discussed above. A challenge is the current lack of consensus about what determines analysis readiness versus AI/ML-readiness. The concept of ''analysis ready" data  (Ramachandran et al. , 2018)  is indeed an active area of discussion in the AI/ML community, and has recently been expanded to include conversations about AI-readiness (see discussion across the Earth Sciences https://wiki. esipfed. org/Data_Readiness), analysis ready-cloud optimized (e. g. ,  Abernathey et al. , 2021) , and numerous other perspectives on the topic. The Heliophysics community has maintained a living discussion of AI-readiness defined in the context of space physics (https://github.
com/ rmcgranaghan/data_science_tools_and_resources/wiki/ Curated-Reference%7CChallenge-Data-Sets) that will be an important guide for SPASE extensions to include this growing area in our field. While it is beyond the scope of this paper to formally define the SPASE extensions for describing AI/ML datasets, we endeavor to identify several characteristics common to AI/ML-ready data such that the incorporation of their descriptions in SPASE would enable those datasets to be discovered and reused more easily (note that these common characteristics have also emerged from the community discussion in the Github Wiki page linked above): Data are calibrated, promoted in level, standardized, etc. , so that values correspond well to the physical system being studied Spurious data and non-physical values are either corrected or identified Data are interpolated, patched, and harmonized, to provide even or consistent sampling and cadence Data labels or categories (such as features and event indicators), if relevant, are made compatible with the feature set, i.
e. , labels ''Y" made compatible for learning with feature set ''X" as an input Data is then made available in a format that is easy to read into an AI algorithm (e. g. , Keras, PyTorch). The sheer variety of AI/ML techniques requires numerous methods of processing data. Metadata, alone, does not enable AI/ML. However, descriptive data are vital to making an explicit and traceable data transformation pipeline that a data analysis or machine learning process uses and to making the resultant dataset findable. There are several elements of SPASE to make such datasets more findable, including but not limited to: Resource attributes pertaining to how to access the resource, availability and storage format (such as AccessInformation and AccessURL as shown in Figs. 3  and 8 ); Information on the execution platform for a resource, including operating system and necessary hardware (ExecutionEnvironment under Software in Infrastructure domain shown in Fig.
2 ); Information about the level of processing at which a given resource is provided (ProcessingLevel as an optional attribute as shown in Fig. 8 ); and Information that describes traceability of the data processing pipeline for a dataset (by using the RevisionHistory optional attribute under ResourceHeader as shown in Figs. 3  and 8 ) Once a given dataset is discovered, it is expected that more bespoke elements of the data processing are provided by the researcher who created them and can be understood by other researchers. It is indeed important to capture these processing steps, however complex. This is the 'metadata' that a published article's methodology section provides. SPASE as it exists now supports this information, too, through elements such as InformationURL. The role of SPASE in this instance is to provide the metadata categories that help these datasets be found and thus supply a connection to them for the researcher.
2. 3). With the support of SPASE metadata, not only data services can be supported via conventional data queries of time, platform (spacecraft or ground station), and instrument, but science-based queries are also possible. For example, the nascent HDO  (Fung et al. , 2021)  can also provide data searches queried by observing spacecraft location, as in the case of Fig. 13 , and by magnetospheric state conditions  (Fung et al. , 2022). We have described in sections 4. 2. 1 and 4. 2. 2 how metadata data can be searched and used to access resources for heliophysical event and statistical studies. Compiling datasets with multiple events pertaining to a given phenomenon is largely a manual and often laborious process. With community-wide adoption of SPASE metadata standards, particularly with robust descriptions of Annotation resources (Figs.
Software libraries Publicly available software supporting science is also becoming more and more popular in Heliophysics. While proprietary code-based software like IDL SolarSoftWare (https://www. lmsal. com/solarsoft/; https://www. mssl. ucl. ac. uk/surf/sswdoc/) has been developed since the beginning of the SOHO mission era in the mid-1990 s, a community of developers and scientists supporting python packages for Heliophysics has been growing for more than a decade, though not fully coordinated at the beginning. The Python in Heliophysics Community (PyHC; https://pyhc. org/) was set up in 2018 to promote and facilitate the use and development of Python in the Heliophysics community. Since then, PyHC has promoted a set of standards of development (https://github. com/heliophysicsPy/standards/ blob/main/standards.
md) that has been adopted by seven core Python libraries (https://heliopython. org/projects/): SunPy, PlasmaPy, pySPEDAS, HAPI client, Kamodo, SpacePy and pysat. These python packages cover the fields of solar physics (SunPy), solar wind and magnetospheric physics (pySPEDAS), ionosphere, thermosphere and atmospheric physics including ground-based experiments like SuperDARN (pysat), plasma physics (PlasmaPy), space science (SpacePy), the heliophysics API for time series (HAPI) and interpolation through data, especially simulation results (Kamodo), to simplify model-data comparisons. Let us present here two examples of how these python libraries know where/how to obtain data, and what metadata is extracted from those libraries/routines. For the latter, a submodule of the SpacePy package called pycdf provides a Python interface to the Common Data Format (CDF) library and enables the extraction of all their global attributes and variable attributes (https://spacepy.
github. io/pycdf. html), often in the ISTP/SPASE standard. The second example is related to the access of Solar Orbiter data at ESA. A SunPy plugin for accessing data in the Solar Orbiter Archive (SOAR) called sunpy-soar was developed to access the Solar Orbiter Archive (SOAR) at ESA using the unified Finding and Downloading SunPy Fido object (https://github. com/sunpy/sunpy-soar), again based on metadata. In addition to the more conventional aspects of infrastructure already discussed, heliophysics infrastructure is increasingly dependent on such softwares for data utilization, analysis, and visualization. In some cases, a portion of these capabilities are made possible through an online platform, such as the Virtual Solar Observatory (VSO: https://sdac. virtualsolar. org/cgi/search), while other more flexible options are available as software packages.
An increasingly useful collection of software packages in Python is available via the PyHC and on the Heliophysics System Observatory (HSO) Connect website (https://hsoconnect. hpde. gsfc. nasa. gov). These and additional options in other languages are typically hosted on GitHub. Efforts are underway to streamline and connect these software resources together as a more interoperable web of tools in the interest of open science. The PyHC website is now becoming a one-stop shop maintaining an up-to-date list of 60 + known Python packages available in the worldwide community. This website also provides a growing gallery of examples that are particularly useful for newcomers. PyHC has enabled the development of a community of developers working hand-inhand under the PyHC umbrella. For more information on PyHC, its current status and future outlook, see  Barnum et al.
(2022)  and the PyHC. org website. However, while various space weather services (including simulations) are being provided by various groups and organizations, not all of them are accessible via these libraries. There are also compatibility issues between these libraries where SPASE metadata could play a central role. SPASE is not yet used in any of these python packages but is clearly something on the PyHC to-do list especially as phenomenon keywords become available in SPASE. Software registration is another area that needs attention. The open science initiative discussed above calls for open data and open software. While open data has become the de facto standard practice among the heliophysics research community in recent years, there remain outstanding technical and legal issues surrounding the practicality of open software in terms of licensing, proprietary and intellectual property rights, maintenance, citation, versioning, ethics, security, export control, etc.
While the legal issues must be worked out by the source institutions, there is promise for solutions on the technical side through a forming collaboration, e. g. , between PyHC and PyOpen-Sci. Apart from these issues, an open software community must enable users to discover what software is useful and how to access and use a particular piece of software for a particular research project. Software is a SPASE resource type (Fig. 2 ), so it is possible to develop a software products SPASE registry enabled with proper DOI referencing as discussed in section 3. 5, which can then be served by an HDP-or HDO-like middleware (Fig. 12 ) to provide search and access functionality for software tools.
1. A central SPASE registry, where metadata in different repositories (i. e. , under different NamingAuthorities) are shared, like the one maintained by the SPASE Group (https://github. com/hpde/), would make a more efficient environment for data exchange (section 4. 2) and data discovery (section 4. 2. 3). It is hoped that through discussions in international forums such as IHDEA, COSPAR and other national and international organizations, agreements can be reached by the international heliophysics and space weather community to establish a uniform SPASE data dictionary (section 3. 1) and a fully open SPASE registry (section 3. 2), i. e. , a lingua franca for metadata to support sharing of heliophysics and space weather resources across international boundaries.
Over the past several years many technologies needed for an open data infrastructure have been developed and deployed. SPASE is now an internationally adopted metadata standard (Appendix C) and recommended for adoption by the international space weather community (COSPAR Panel on Space Weather, 2021). Together with DOIs, standard data formats (CDF, FITS, HDF, netCDF), data archives with search portals (SPDF, CCMC, HDP, HDO, etc. ), and data visualization and analysis tools (e. g. , AMDA, Autoplot, JHelioviewer or PyHC python packages), the capabilities collectively enabled by SPASE can form the basis of an open science infrastructure. As expected for grassroots efforts, the development of each of the data infrastructure technologies occurred asynchronously, each addressing a recognized community need.
Section 3. 4 and 4. 1. 3. 1 have shown that the SPASE information model can also be extended in order to accommodate new description requirements. As pointed out in section 4. 2. 1, the NASA Heliophysics Division has already taken a concrete step in their latest science and data management policy (https://science. nasa. gov/science-red/s3fs-public/atoms/files/HPD_Data_Pol-icy_Final_20220209_TAGGED. pdf) by requiring all NASA-sponsored datasets and data collections to be described by using the SPASE information model. From here, it will be of interest to consider how the SPASE metadata model may work with other metadata systems, such as the Planetary Data System information model (https:// pds. nasa. gov/datastandards/documents/im/current/index_ 1J00. html) to support open science. The future ahead appears bright.
Each of the mentioned technologies complements each other in a growing data environment, especially one based on the FAIR principles. We assert then that a FAIR-compliant information architecture enabled by a standard metadata model, for which SPASE is a strong candidate, would result in a significantly improved and effective Heliophysics data environment. With enhanced end-to-end integration, it will be possible to create a citable data resource by observation or with software, along with a corresponding SPASE description. The SPASE description will be consumed by search portals that provide search engines to locate the desired resources. Visualization and analysis tools will be able to use the portals to locate resources relevant to a research topic, acquire the resources with standard API, perform analysis and display the resources.
EU framework 7 projects Near-Earth space data infrastructure for e-Science (ESPAS) (https://www. espas-fp7. eu/portal/). An e-Infrastructure to support access to observations, modeling and prediction of the near-Earth space environment extending from the Earth's atmosphere up to the outer radiation belts. Integrated Medium for Planetary Exploration (IMPEx) (http://impex-fp7. oeaw. ac. at/). An integrated interactive computational framework where data from planetary missions are interconnected with numerical models. France Centre de Donnees de la Physique des Plasmas (CDPP) (http://www. cdpp. eu/). Automated Multi-Dataset Analysis (AMDA) (http:// amda. cdpp. eu/). Provide integrated analysis of multi-point and multiinstrument data for case studies and statistical studies of plasmas in space physics.
Germany German Research Centre for Geosciences (https://www. gfz-potsdam. de/en/home/). Information System and Data Center for geoscientific data (http://isdc. gfz-potsdam. de/). An access point for all manner of geoscientific geodata, its corresponding metadata, scientific documentation and software tools. The majority of the data and information, the portal currently offers to the public, are global geomonitoring products such as satellite orbit and Earth gravity field data as well as geomagnetic and atmospheric data for the exploration. Exploring Semantic web ontologies for use with reasoners and semantic searches. Japan IUGONET (https://www. iugonet. org/product/). Provides a unified metadata database and seamless data environment for ground-based observations of the upper atmosphere acquired by a global network of radars, magnetometers, optical sensors, helioscopes, etc.
, and stored individual databases. United States: NASA heliophysics Division HPDE Repository (https://github. com/hpde/). Provides comprehensive access to all registered metadata in NASA's Heliophysics Division. HPDE Landing Page (https://hpde. io/). Formatted information about each registered resource in the HPDE repositories. Heliophysics Data Portal (http://heliophysicsdata. gsfc. nasa. gov/). Provides a quick and easy way to find and access a comprehensive set of NASA and other datasets, images, movies, and associated services. Heliophysics Digital Observatory (HDO) (https://msqs. gsfc. nasa. gov/hdo/public). The goal of the NASA HDO is to provide a convenient portal for searching and accessing digital resources to support heliophysics and space weather research. To that end, the HDO focuses on providing higher-level search capabilities for meeting digital resource requirements stemming from heliophysics cross-disciplinary, system-science research tasks.
Acknowledgments K. M. acknowledges support by the  NASA   HGI program  ( 80HQTR19T0028 ), the  NASA  cooperative agreement  NNG11PL10A  and  80NSSC21M0180. M. A. R. acknowledges the  Austrian Science Fund (FWF) :  P34437. HDRL including  SPDF ,  SDAC ,  HDMC , and SPASE groups are supported by  NASA. CCMC is a multiagency partnership of  NASA ,  United States Air Force ,  National Science Foundation ,  NOAA , and  Office of Naval Research. CDPP Team acknowledges the support of  Benjamin Renard ,  Alexandre Schulz  and  Myriam Bouchemit  for implementing SPASE in AMDA. The authors would like to express sincere gratitude to the Reviewers and Editor for their constructive comments and considerations during the extended review process that at the end helped make a much-improved paper.
Version 1. 2 (https://hpde. gsfc. nasa. gov/Heliophysics_ Data_Policy_v1. 2_2016Oct04. html). Version 2. 0 (https://science. nasa. gov/science-red/s3fspublic/atoms/files/HPD_Data_Policy_Final_20220209_ TAGGED. pdf). NASA Satellite Situation Center (SSC) Web services (https://sscweb. gsfc. nasa. gov/WebServices/). netCDF, Network Common Data Form (https://www. unidata. ucar. edu/software/netcdf/). NOAA,  National Oceanic and Atmospheric Administration  (https://www. noaa. gov/). NSSDC, NASA Space Science Data Coordinated Archive (https://nssdc. gsfc. nasa. gov/). OMNI Web and Datasets (https://omniweb. gsfc. nasa. gov/). Open Madrigal Initiative (https://cedar. openmadrigal. org/openmadrigal). ORCID, Open Researcher and Contributor Identifier (https://orcid. org/). P2SA, ESA Proba-2 long term archive (http://p2sa.
esac. esa. int). SolarSoft (https://sohowww. nascom. nasa. gov/solarsoft/ ). SPASE dictionary (https://spase-group. org/data/model/ search/index. html). SPASE Group (https://spase-group. org/about. html; https://spase-group. org/connect. html). SPASE registry on Github https://github. com/hpde/. SPASE simulation extension data model (https://spasegroup. org/data/simulation/spase-sim-1. 0. 0. pdf). SPASE, Space Physics Archive Search and Extract (https://spase-group. org/).
ACKNOWLEDGEMENTS As acknowledged in the IWGDF Practical Guidelines, we would like to stress here again that we are very grateful to the 69 working group members who have collaborated tirelessly, lending their time, expertise and passion to the realization of the IWGDF guideline. We would also like to thank the 119 independent external experts and patient representatives for their time to review our clinical questions and guidelines. These collective 186 experts with lived, clinical or research experience are from a total 63 different countries, from all continents. Author Contributions. Jaap van Netten drafted the manuscript. Jaap van Netten, Jan Apelqvist, Sicco A. Bus, Robert Fitridge, Fran Game, Matilde Monteiro-Soares, Eric Senneville, and Nicolaas C. Schaper provided critical input and all authors agree with the submitted manuscript.
HALE drone MDO formulation OpenAeroStruct to Eco-HALE. We choose to derive our work from the OpenAeroStruct package with the wingbox full design ( 17 ). OpenAeroStruct is mainly utilized to study commercial aircraft which we modified to model a HALE drone. To validate our code, we used the single-boom HALE drone test case (data from FBhale publication  14  ). First, as there is no need for a 2. 5 G maneuver on a HALE drone, we changed the design points used. We used one cruise flight design point where the lift and power constraints must be satisfied, and one gust design point where the structural constraints must be satisfied. The OpenAeroStruct constraint on performance, based on the Bréguet equation 26 cannot be used for a solarpowered HALE aircraft, as the total weight of the aircraft does not change during flight and the range is not limited.
Conclusion The authors have developed a low fidelity MDO framework for preliminary design of solar powered HALE. The code is opensource and available for the community. Material choice was successfully integrated in a continuous multidisciplinary design optimization regarding CO 2 emissions. The simple HALE model developed showed acceptable agreement with more complex models such as FBhale, which was designed using much more sophisticated and costly tools. Our modified version of OpenAeroStruct includes certain improvements with respect to the original version of the tool. For instance, it is adapted to HALE drones and contains more physics: material choice from among a discrete catalogue, batteries, solar panels, buckling constraint, etc. A key result is that an optimal material in terms of drone total weight is also optimal in terms of drone total CO 2 emissions, even for an electrical drone.
Fragility analysis and damage assignment Fragility curves at component or element level serve as a fundamental tool to understand how different components of a system behave during an earthquake. A fragility function is the conditional probability of exceeding a predefined limit state given the intensity measures for each component. In  Pitilakis et al. (2014a) , existing fragility curves have been documented for various infrastructure systems at the component level. Similar documentation may be found in HAZUS  (FEMA 2020). Databases of fragility and vulnerability functions for common typologies of residential, commercial, and industrial buildings already exist and are compatible with open-source tools like for example the OpenQuake-engine  (Yepes-Estrada et al. 2016; Martins and Silva 2021) , but unfortunately, so far, they do not cover most of the components typically present in infrastructure systems.
Implementation of infrastructure risk in OpenQuake The precedented short review allows us to demonstrate the complexity that an infrastructure system possesses heterogenous typologies and structural/operational characteristics for its component and element, and the need for a globally recognized simple and easily applicable methodology and tool. Moreover, it allowed us to elaborate the main components of an efficient methodology to implement it in a powerful tool capable to perform in a unified and comprehensive manner the whole infrastructure risk assessment, all the way from the generation of the seismic event and the source characterization to the connectivity loss of infrastructure network at risk. The engine that has been used for this purpose is OpenQuake (https:// github. com/ gem/ oq-engine).
The library for other elements at risk i. e. bridges is also extensively enriching. In the frame of the present work, specific damage and vulnerability functions have been proposed together with adequate connectivity and performance metrics. Based on these advantages it is expected that the implementation of an efficient infrastructure risk module in the OpenQuake engine will provide a uniform and powerful platform allowing also the systemic analysis of systems considering intra and interdependencies. The implementation made herein takes on one hand, advantage from the advanced tools and methodology developed in the past developed models and methodologies mainly in SYNER-G, and on the other hand, the capacities offered by the OpenQuake engine. This will allow further improvement of certain parts of the existing methodology, for example with regard to the hazard assessment and the selection of appropriate metrics, which is important to gain wide acknowledgment and applicability.