SsODNet: Solar system Open Database Network

Context. The sample of Solar system objects has dramatically increased over the last decade. The number of measured properties (e.g., diameter, taxonomy, rotation period, thermal inertia, etc.) has expanded even more quickly. However, this wealth of information is spread over a myriad of studies, with different designations reported per object. Aims. We provide a solution to the identification of Solar system objects based on any of their multiple names or designations. We also compile and rationalize their properties to provide an easy access to them. We aim to continuously update the database as new measurements become available. Methods. We built a Web Service, SsODNet , which offers four access points, each corresponding to an identified necessity in the community: name resolution ( quaero ), compilation of a large corpus of properties ( dataCloud ), determination of the best estimate among compiled values ( ssoCard ), and a statistical description of the population ( ssoBFT ). Results. The SsODNet interfaces are fully operational and freely accessible to everyone. The name resolver quaero translates any of the ∼ 5.3 million designations of objects into their current and official designation. The dataCloud includes about 105 million parameters (osculating and proper elements, pair and family membership, diameter, albedo, mass, density, rotation period, spin coordinates, phase function parameters, colors, taxonomy, thermal inertia, and Yarkovsky drift) from over 3000 articles (updated continuously). For each of the known asteroids and dwarf planets ( ∼ 1.2 million), a ssoCard that provides a single best-estimate for each parameter is available. The SsODNet service provides these resources in a fraction of second upon query. Finally, the extensive ssoBFT table compiles all the best estimates in a single table for population-wide studies.


Introduction
The first decade of the 2000s saw an order of magnitude increase in the sample of known Solar System objects (SSOs) from roughly 50,000 to 600,000.While this number has doubled since, the revolution of most recent decade has seen an even faster growth on the part of the measured properties of these bodies.About 2000 diameters and albedo had been determined from IRAS mid-infrared observations (Tedesco et al., 2002) and over 150,000 are available today (e.g., Mainzer et al., 2011;Masiero et al., 2011;Grav et al., 2011).Hundreds of detections of the Yarkovsky effect (Vokrouhlický et al., 2015) are available (e.g., Del Vigna et al., 2019;Greenberg et al., 2020) just 20 years after the first-ever detection (Chesley et al., 2003).
The ssoBFT catalog is available at the CDS via anonymous ftp to http://cdsarc.u-strasbg.fr/ or via http://cdsarc.u-strasbg.fr/viz-bin/qcat?J/A+A/xxx/Axxx The benefit of all these developments has not, however, come to full fruition.If some catalogs are publicly available in machine-readable formats on the Planetary Data System1 (PDS), the Centre de Données astronomiques de Strasbourg2 (CDS), or alternative repositories (with unfortunately an endless variety of formats), a significant fraction of results have only been tabulated within the relevant papers.Some journals offer machinereadable versions of these tables on their online versions, but only for recent articles.Furthermore, the designation of small bodies often evolves over time, going from several possible provisional designations to a single number and then ultimately establishing an official name.Hence, the same object can be referred to with different labels in different studies, making its cross-identification over several sources a complex task.Accessing to all the characteristics of a given body or population can thus prove tedious and even impractical.
Compiling estimates of SSO properties and deriving the best estimate for each is of high practical relevance for the computation of ephemerides in the Virtual Observatory (VO) Web services we maintain (Miriade, SkyBoT, Berthier et al., 2006Berthier et al., , 2008)).Dynamical properties (i.e., osculating elements) are required to compute the position of SSOs and physical properties are required to predict their apparent aspect as seen by an observer, such as (i) the apparent magnitude in V band, rely-ing on the phase function (HG or HG 1 G 2 , Bowell et al., 1989;Muinonen et al., 2010), (ii) the apparent magnitude in any other band, requiring a color index derived from the spectral class (e.g., DeMeo & Carry, 2013;Popescu et al., 2018), (iii) the flux at mid-infrared wavelengths, computed from the diameter and albedo through a thermal model (Harris & Davies, 1999), (iv) the shape and orientation of a target on the plane of the sky (often referred to as physical ephemerides), based on its 3D shape model, rotation period, and spin-vector coordinates (e.g., Marciniak et al., 2012).
Beyond the ephemerides computation, an extensive and rationalized compilation of SSO properties has many applications, from detailed in-depth studies on specific targets to populationwide statistical description of parameters.Over the years, publicly available compilations of data have flourished, for instance, the Jet Propulsion Laboratory Small Bodies Database3 , the Las Cumbres Observatory NEOExchange4 (Lister et al., 2021), the Lowell observatory Minor Planet Services5 (Moskovitz et al., 2021), the NEOROCKs physical properties database6 (Zinzi et al., 2021), the Observatoire de la Côte d'Azur Minor Planet Physical Properties Catalog7 (MP3C, Delbo et al., 2018), the Size, Mass and Density of Asteroids (SiMDA8 , Kretlow, 2020), and the SUPAERO ECOCEL9 (Kovalenko et al., 2022).While these services fulfill many of the community's needs, most of them do not provide a fast machine-machine interface.
Thus, we have designed a fully scriptable Web Service named the Solar system Open Database Network (SsODNet) which is aimed at providing the best estimate of a variety of parameters for every SSO.Owing to the complexity of compiling SSO data as depicted hereinabove, SsODNet consists of a suite of chained steps: from the identification of objects to the massive compilation of data, ending with the selection of best estimates, and summarizing them in a table.As each of these steps represents a typical task relevant for the community, we propose a dedicated front-end (a Web service associated with an Application Programming Interface -API) for each.
In Section 2, we describe how quaero builds a unique identifier for each object, associating all its aliases and providing the identity of the SSO.In Section 3, we describe how dataCloud compiles the measurements and estimates of properties from many sources, providing the most-possible comprehensive data set of SSOs.In Section 4, we describe how ssoCard provides the best estimate of each SSO property, and lists them in a single organized identify card.In Section 5, we describe how ssoBFT summarizes the most-commonly requested of these parameters for all SSOs.We then describe how to query these services in Section 6 before discussing the future developments of SsODNet in Section 7.

Name resolver: quaero
The SsODNet.quaero name-resolution service is built to address the issue of identification of SSOs and, more generally, of all planetary and artificial objects gravitationally bound to a star.Upon the submission of any of the possible designations of a target, quaero returns its official or main designation, together with all its aliases.To be compliant with the spirit of the VO ("name resolver") quaero can also return the equatorial coordinates of the object at a given epoch.

Context
The Solar System is populated by widely different types of celestial bodies: from planets and their satellites to minor planets (comets, asteroids, Centaurs, Kuiper-belt objects, etc.) and their satellites, and further on to artificial satellites, space probes, and space debris.Since the first exoplanet detection by Mayor & Queloz (1995), today we know of about 5000 planetary objects that orbit around other stars than the Sun.A few rogue planets (e.g., OTS 44 or Cha 110913-773444) and two interstellar objects (1I/ Oumuamua and 2I/Borisov) complete the picture of the planetary zoo.
The nomenclature of SSOs is entrusted to two groups under the auspices of the International Astronomical Union (IAU) Division F. The first is the Working Group for Planetary System Nomenclature (WG-PSN), which is in charge of naming features on planets, satellites, and asteroids.This group also names planets (although the IAU has not named a planet as of yet) and the natural satellites of major planets.The second is the Working Group for Small Bodies Nomenclature (WG-SBN), which is responsible for naming of all other small bodies (minor planets, satellites of minor planets, and comets).Both working groups share responsibility for naming dwarf planets (IAU, 2020a).
As of today, there are no official name for exoplanets assigned by the IAU.The public names, assigned through a public naming process such as NameExoWorlds10 is distinguished from the official scientific designation, which follows the rules of the system used for designating multiple-star systems as adopted by the IAU (IAU, 2020b).
Spacecraft, together with launchers, payloads, and space debris, are indexed for safety and cooperation purposes.They are usually named by their funders (space agencies, laboratories, or companies).They are also assigned an International Designator (COSPAR ID), under the responsibility of the Committee on Space Research (COSPAR) of the International Council for Science (ICSU), and a Satellite Catalog Number (NORAD ID) attributed by the United States Space Command (USSPACE-COM).
Since the designation of the major bodies of the Solar System (the Sun, the Moon, the eight planets), more than 1.2 million objects have been inventoried, classified, and named.As of today, there are more than 5.3 million designations used to name them all.Objects can have multiple designations owing to the evolution of knowledge as well as changes in nomenclature over time11 .We illustrate this with the first asteroid discovered in 1801: Ceres.It is classified today as a dwarf planet.Its official designation is "(1) Ceres:" a number in parenthesis followed by a name.This official designation thus already contains two labels.However, Ceres was also named using provisional designations over the years, assigned to past astrometric observations that had not been immediately connected to its orbit: "1801 AA," "1899 OF," and "1943 XB," and the corresponding packed names12 "I01A00A," "I99O00F," and "J43X00B".Thus Ceres can be known by eight different names.The all-time  Overall, SsODNet.quaero is designed to fulfill four main functionalities: 1) to identify a SSO from its designation; 2) to explore the naming of SSOs using wildcard, regular expression, or fuzziness; 3) to resolve the name of a SSO into sky coordinates; and 4) to provide an autocomplete feature that can be used to offer SSO name suggestions when a user types in an input field.
To achieve this goal, once a week we gather all the available planetary object designations from the Minor Planet Center (Marsden, 1980) for asteroids and dwarf planets, the IMCCE's CometPro Database (Rocher & Cavelier, 1996) for comets, the Extrasolar Planets Encyclopaedia (Exoplanet-Team, 2021) for exoplanets, and CelesTrak (Kelso, 2021) for spacecrafts and debris.These designations are then stored and indexed in a dedicated database.
We use the NoSQL database Elasticsearch 13 to manage the millions of designations.It is a full-text search engine based on 13 https://www.elastic.co/the Apache Lucene library14 .Each object is defined by a set of fields (document) defining its Id, name, aliases, parent, type, and so on.Documents are stored in an Elasticsearch index as JSONformat data.By default, Elasticsearch tries to guess the correct mapping for fields, but to meet the challenges of planetary object identification, we specified our own mapping.
If SSO designations are indexed as individual strings, then a user can only find whole names.To allow for the search of a name on a part of a designation, we decompose all the SSO designations into small chunks (tokens).However, at this step, each token is still matched literally.This means (among other things) that a search for a name with or without an accent or a special character, or one with mixed lowercase and uppercase characters, would possibly not result in a match with any name.To solve this issue, we defined the normalization rules to allow for the matching of tokens that are not exactly the same as the search names, but similar enough to still be relevant.For the full technical information, we refer to the documention15 of the SsODNet.quaeroAPI.

Compilation of properties: dataCloud
The SsODNet.dataCloud service is designed to compile all published measurements and estimates of SSO properties.The dataCloud uses SsODNet.quaero to identify objects over their multiple designations.It also associates every estimate with a bibliographic reference and a method.Upon request, the dataCloud returns all the estimates of a given property or parameter for the requested SSO.

Context
Starting with the planetary motion (Newton, 1760), the first studies of SSOs focused on their dynamics (Gauss, 1809), which is required to compute their ephemerides.From the distribution of their orbital elements, Hirayama (1918) discovered the dynamical families.Time-series photometry has led to the determination of numerous rotation periods in the first half of the twentieth century (e.g., Bailey & Pickering, 1913).The 1970s saw the advent of compositional and physical studies, with the first studies of diameter and albedo (e.g., Cruikshank & Morrison, 1973), mass and, hence, the density (Schubart, 1974), along with the spectrophotometry and taxonomy (e.g., Chapman et al., 1975).The handful of SSOs with spin-vector coordinates and triaxial dimensions of the 1980s (Drummond & Cocke, 1989) grew to several hundreds in the 2000s thanks to the light-curve inversion technique (Kaasalainen & Torppa, 2001).Similarly, estimates of thermal inertia and Yarkovsky drift are common nowadays (Hanuš et al., 2018;Greenberg et al., 2020), even though the first studies were completed only two decades ago (Lagerros, 1996;Chesley et al., 2003).
Benefiting from these progresses is complex, however, as the fast-growing number of measured properties is spread over a myriad of articles.Machine-readable catalogs delivered by authors to the PDS or the CDS only represent the tip of the iceberg.Furthermore, there is a large heterogeneity in how SSOs are labeled (number, name, packed designation, etc.) and in how quantities are reported: masses, M, in terms of kg or solar masses (M ) or as a GM product or the albedo in linear or logarithmic scale, for instance.
The sample size of individual articles may be small, but their sum is large.In particular, some size-limited sample may be extremely valuable, such as results on a single target obtained during a spacecraft rendezvous for example.Therefore, the goal of compiling every estimate should not be overlooked by the community.
SsODNet.dataCloud compiles in a single database as many estimates as possible for a variety of SSO properties.Such a centralization of data may appear anachronistic in the current landscape of connections to remote databases, such as what is regularly done in the VO (Bayo et al., 2008).It is, however, required here.First, the remote databases do not exist.Second, owing to the issue of SSO naming, on-the-fly cross-matches between resources would be slow upon query.We chose to place the workload on the server side, in an asynchronous process, to provide a fast service to users.Such a solution is already used for the ESA Gaia archive 16 , in which time-consuming cross-matches of Gaia catalog (Gaia Collaboration et al., 2016, 2018, 2021) with other common large catalogs (e.g., SDSS DR9, 2MASS, allWISE, Ahn et al., 2012;Skrutskie et al., 2006;Wright et al., 2010;Cutri et al., 2013) are already computed and stored (see details in Marrese et al., 2017).

Method
The design of the dataCloud is very simple: the parameters are grouped by collection of properties in SQL tables, such as diameter and albedo (as they are seldom derived independently), mass, thermal inertia, taxonomy, astrometry (the MPCAT-OBS database, MPC, 2021), and so on.There are a few exceptions to this general scheme.The osculating elements of asteroids from the Minor Planet Center (MPC, Marsden, 1980) and the Lowell observatory (Bowell et al., 1994), as well as those of comets from the IMCCE (Rocher & Cavelier, 1996), are stored in separated tables.The Appendix A provides the list of collections composing the dataCloud ecosystem.
Each entry of tables corresponds to a single determination of a parameter for a given target.Parameters are stored with their uncertainties, the method used to obtain them (see Appendix B), a selection flag (used to discriminate among estimates; see Section 4), and the bibliographic reference of the source of data.A given SSO, or bibliographic reference, may be repeated multiple times: some studies include many objects and the same SSO may have been analyzed in multiple studies.Figure 2 shows the distribution over time of the publications (currently 3007) used to build the dataCloud database.For convenience, a file compiling all the bibliographic references in bibtex format is available 17 .
A key aspect of the collections is the unique identifier assigned to each SSO, built upon their name and used to identify them across tables.At every update of the database, the name of each SSO (as published by authors) is tested with SsODNet.quaero and updated upon ingestion.Hence, all properties are linked together using the most up-to-date designation.
For each parameter, we started the compilation from scratch, individually adding each bibliographic reference.The only exceptions to this are the masses and the spins.For both, we first input a previous compilation of data, taken from Carry (2012) and Warner et al. (2021) respectively.

Selection of the best estimates: ssoCard
The SsODNet.ssoCard provides a practical solution to the question of finding the best estimate for a wide range of parameters of SSOs.From the dataCloud, it builds the resume of each SSO, named ssoCard.These ssoCard are small files that can be easily downloaded and read upon user request.The present first release of SsODNet.ssoCardproposes ssoCard for asteroids and dwarf planets only.We plan to offer ssoCard for other types of SSOs (comets, satellites) in subsequent releases (see Section 7).

Context
Among the hundreds of articles compiled in the dataCloud, a significant fraction report the same parameter for a given SSO.A question then arises about the most optimal way to choose a value.A simple statistical averaging cannot address the question: some methods are intrinsically more precise than others and some are direct measurements, while others are modeldependent.Moreover, uncertainties associated with values often do not account for possible biases, namely, for external errors.This implies that the choice of the best value cannot entirely rely on criteria that are based on the repeatability of the measurements.
The structure and format of data must also be addressed.The usual table format (i.e., rows and columns) is not very well adapted to these purposes.Some SSOs have estimates across a wide variety of parameters (osculating elements, proper elements, diameter, mass, density, colors across many filters, taxonomy, and so forth), while others have a few parameters only (e.g., osculating elements).Structuring the data in a flat 2D table implies that a vast majority of cells will be empty.With the current data in SsODNet, the filling factor of such a table would only be ∼15% (see Section 5).
Furthermore, the association of data with meta-data (i.e., method, bibliographic reference, and units) is also an issue with regard to the table format.Considering that a human-readable bibliographic reference is composed of at least four fields (title, authors, year, bibcode), the number of columns will increase by a factor of four for each group of properties.In the current ecosystem of SsODNet.dataCloud,composed of 15 collections exposing 591 fields, it would imply a final table composed of 651 columns.
Considering all these elements, we chose to structure the parameters in a key-value data format allowing for nested objects and arrays.We chose the open standard file format JSON (Bray, 2017).A XML-based format such as VOTable 18 could have been suitable to include metadata, but given it is rather verbose in nature, it would significantly increase the volume of data to exchange.

Method
The best estimate for each SSO property depends mainly on the method used to measure it: for example, a direct measurement from an in situ space mission can be considered to be more valuable than an indirect determination based on telescopic observations acquired from the Earth.Similarly, a modern measurement is often more accurate than an earlier measurement owing to technological advances.On the other hand, an old value remains useful because it increases the temporal validity of the measurement and can be unique.Finally, the accuracy (closeness to the true value) and precision (repeatability of the value) of measurements must be considered to choose a particular value among a data set or to compute a statistical average.For each set of properties, we defined a decision tree that is schematized in Figure 3.The methods are ordered in a preferential order.Among the ordered methods, the first available is chosen, and the weighted average µ is computed from N multiple estimates, x i , by the least-squares estimator: where is the arithmetic mean of the upper and lower uncertainties σ +,i and σ −,i .
Similarly, the upper and lower uncertainties on µ are computed as: When the uncertainty of a value is unknown, we set it to 100% of the value to weight the mean.At this stage, the 18 https://ivoa.net/documents/VOTable/N estimates used to compute the average may be less than the total number of estimates available.Every single entry in SsODNet.dataCloud has a selection flag (see Section 3).Only three values are possible for this flag: -1, 0 (default), and 1.Any estimate with a selection flag of -1 is discarded from the computation of the best estimate.If an estimate is flagged with 1, it is considered to be the best estimate (we refrain from using it).The overwhelming majority of entries in dataCloud have a selection flag of 0.
We describe below how the preferential order is defined for each parameter and we provide the exhaustive order in Appendix C. Exceptions to this scheme of averaging include family membership, albedo, taxonomy, and the orbital elements of SSOs.

Osculating elements
We store in SsODNet.dataCloud the complete catalogs of osculating elements of asteroids and dwarf planets proposed by the MPC (mpcorb, Marsden, 1980) and the Lowell Observatory (astorb, Bowell et al., 1994).Osculating elements are a consistent ensemble for each SSO.Thus, we do not select them individually, but as a group.As the primary source, we chose the astorb catalog for the ssoCard, completed with elements from mpcorb for SSOs that are not listed in astorb.
For each SSO, we used its osculating elements (semi-major axis, a, inclination, i, and eccentricity, e) to compute its Tisserand parameter (Tisserand, 1889) with Jupiter (T J ) and report it in the ssoCard: taking a J = 5.203 363 01 au (mean J2000 orbital element).
The most recent and largest update on asteroid proper elements is provided by the Asteroid Families Portal20 (Novakovic & Radovic, 2019).It thus prevails over the others and we included it in SsODNet.dataCloud to report proper elements of SSOs in ssoCard.As Jupiter Trojans and KBOs are not reported in this catalog, we complemented it with the proper elements for these populations from AstDyS.

Families
The existence of asteroid families has been recognized over a century ago (Hirayama, 1918).Many authors have been working on the subject over the last decades, using mainly the Hierarchical Clustering Method (HCM, Zappala et al., 1990).A new method has recently emerged, called V-shape (Bolin et al., 2017).
As families are groups of SSOs, the selection is familybased in contrast with other parameters that are SSO-based.We set as a reference the most-recent large-scale study (presently, Vinogradova, 2019).All the families listed in the reference are considered valid and SSOs belonging to these families have a family item in their ssoCard describing their membership.
We then complete these families with those reported in the other studies listed in SsODNet.dataCloud.We distinguish two cases.For articles studying families in general (e.g., Milani et al., 2014), we add the families not reported in the reference data set.A complexity arises from the fact that different authors may label the same family under different names (such as Minerva and Gefion being two names pointing at the same family, Milani et al., 2014;Nesvorny, 2015).We thus compute the fraction of common members between reported families.Whenever the overlap is smaller than 10%, the families are considered different.Alternatively, if one family is significantly smaller than the other (at most 20% in number of members), we include it to the list of families as it is likely a sub-family of the larger one.
For articles focusing on a single family (e.g., Tsirvoulis, 2019), we consider that they supersede the reference data set.If the family they describe is present in the reference data set, we replace the family membership of all SSOs in the family.If not, we simply add the new family (e.g., Delbo et al., 2019).We illustrate the dynamical families of in the asteroid belt available in SsODNet in Figure 4.

Pairs
Pairs of asteroids are objects on highly similar heliocentric orbits, first discovered by Vokrouhlický & Nesvorný (2008).They are similar to dynamical families with only two members and are thought to be formed by rotational fission (Scheeres, 2007;Pravec et al., 2010).They are identified from the distance d between their orbits (in m.s −1 ): with ∆a, ∆e, ∆ sin i, ∆Ω, and ∆ as the difference in semimajor axis, eccentricity, sine of inclination, longitude of the ascending node, and argument of perihelion, respectively; n and a are the mean motion and semi-major axis of either component; and the numerical constants are k a = 5/4, k e = k i = 2, and Pravec et al., 2019).Backward integration has confirmed many of these pairs, with recent epochs in the past during which the two components were within their Hill sphere (see Žižka et al., 2016, for instance).These epochs are considered the ages of the pairs, the time at which the two components became gravitationnally unbound.
We consider all the pairs listed in the different sources compiled in the dataCloud.However, for the determination of the age, for the ssoCard we select the most recent determination over older studies.

Diameter
There are a number different methods available to estimate the diameter of a SSO.As a general scheme, we favor estimates obtained by a space mission (either via flyby or rendez-vous, such as Belton et al., 1992) over all the others.Diameter estimates based on full 3D shape modeling (including direct measurement such as radar echoes, disk-resolved imaging, or stellar occultation) are then considered the most reliable (e.g., Hudson & Os-tro, 1994;Carry et al., 2010;Viikinkoski et al., 2015;Bartczak & Dudziński, 2018).
Then come the estimates from the analysis of mid-infrared fluxes with spherical models: STM (Lebofsky et al., 1986), FRM (Lebofsky & Spencer, 1989), NEATM (Harris & Davies, 1999), and NESTM (Wolters & Green, 2009).The last ones chosen are the diameter estimates based on the absolute magnitude, H, and the albedo, p V , (Section 4.2.6) when the latter has been derived from the polarimetric phase curve of the SSO (e.g., Delbò et al., 2007).We present the complete list of methods and their order for computing the best diameter estimate in Table C.1.

Albedo
In most cases, the albedo is derived by combining a diameter estimate (D) with the absolute magnitude, H, at visible wavelengths (more specifically in the Johnson V band, hence, the p V notation), using the canonical equation (Bowell et al., 1989): An albedo determination is thus closely linked with a diameter estimate and this is why both quantities are reported in a single table in SsODNet.dataCloud.Because the absolute magnitude is constantly refined with the new photometry associated with the astrometry reported to the MPC, we compute p V using the latest available absolute magnitude, H, and the best estimate of the diameter (Section 4.2.5) using Equation 5.The uncertainties are computed as: Uncertainty on H is seldom provided, and we use a default value of 0.3.The only exceptions to this approach are albedo estimated by space missions or, alternatively, from polarimetric phase curves (see Table C.2), which are not recomputed.We present the albedo against proper orbital elements in Figure 4.

Masses
The determination of the mass of an SSO relies on measuring the effect of its gravitational attraction on another celestial body: either a spacecraft or another(s) SSO(s).The only exception to this is the mass determination from the detection of Yarkovsky drift (Chesley et al., 2003).
The precision that can be achieved is strongly dependent on the type of interaction, whether that is with: a spacecraft, a satellite in orbit, or long-distance encounters (Carry, 2012;Scheeres et al., 2015).We thus favor mass estimates achieved by radio science experiments during spacecraft encounters (Yeomans et al., 1997;Pätzold et al., 2011).Secondary estimates come from  2014)), and taxonomy (fourth) against proper elements (semi-major axis and sine of inclination).The number of plotted objects is reported in each panel.masses determined in binary systems by studying the orbits of their moons (Merline et al., 1999;Pravec et al., 2000;Ostro et al., 2006;Vachier et al., 2012;Pajuelo et al., 2018).
Masses determined from SSO-to-SSO long-distance interactions: close encounters (Standish & Hellings, 1989;Siltala & Granvik, 2020) and ephemerides (Baer & Chesley, 2008;Fienga et al., 2008) follow.Finally, for an SSO with a detected Yarkovsky drift (Vokrouhlický et al., 2015), it is possible to determine its mass on the basis of a number of other parameters (diameter, albedo, obliquity, thermal inertia, etc., as per Chesley et al., 2014).We present the complete ordered list of methods for computing the best mass estimate in Table C.3.

Density
For each SSO with both a mass M and a diameter D estimates, we compute its density ρ (kg.m −3 ) and associated uncertainties as follows: In some cases, the density can be determined without knowledge of either the mass or the volume.This is often the case of small binary asteroid systems studied by optical light curves (Scheirich & Pravec, 2009;Carry et al., 2015).A few binary systems imaged by radar are also included in this case (Ford et al., 2014).Last, the density can be derived from a detected Yarkovsky orbital drift (Rozitis & Green, 2014).We did not set preference of a method over another and we chose to average these estimates together.The distribution of density for a few selected taxonomic classes is presented in Figure 5.

Spin solutions
In most cases, the only available information on the spin of an SSO is its rotation period (often reported as synodic period).In some cases, however, the orientation of the spin axis has been determined, and we report its coordinates both in ECJ2000 (as reference time, longitude, and latitude; see Kaasalainen & Torppa, 2001;Ďurech et al., 2010) and in EQJ2000 (as right ascension, declination, and the position of the prime meridian W 0 and Ẇ; see Archinal et al., 2018).Spin-vector coordinates determined with the light-curve inversion method (Kaasalainen & Torppa, 2001) are often degenerated with a mirror solution separated by 180 • in ecliptic longitude.We use the selection flag (Section 3) to remove this ambiguity whenever one of the two spin solutions has been rejected a posteriori (from comparison with stellar occultation or disk-resolved imaging for instance, Marchis et al., 2006;Ďurech et al., 2011).For each SSO with spin-vector coordinates, we computed its obliquity using these coordinates and its osculating elements (Section 4.2.1).We present the distribution of rotation period and obliquity against diameter in Figure 6.
Here, again, solutions obtained by spacecraft encounters are favored over any others.They are followed by spin solutions obtained by 3D shape modeling techniques that include direct disk- Spin solutions Average Fig. 7: Example of clustering of spin coordinates for (20) Massalia.Six solutions (blue) are possible (Kaasalainen et al., 2002;Hanuš et al., 2016;Cellino et al., 2019).The four separated spin coordinates (orange) of the four clusters are reported in the ssoCard.
The average spin coordinates are computed using Equation 1.However, as several ambiguous spin solutions may coexist for a given SSO, we identify which estimates correspond to which spin solution using K-Means clustering (Lloyd, 1982), as provided by the scikit-learn 21 python package (Pedregosa et al., 2011).We consider that up to four distinct spin solutions can be present, such as for (20) Massalia (Figure 7).Spin coordinates must be within 30 • of the average to be include in a cluster. 21https://scikit-learn.org We set default uncertainties of 30 • on spin coordinates whenever they have not been specified by the respective authors.We used a similar approach, based on K-Means clustering, for the rotation periods.In this case, the threshold to belong to a solution was set to 0.2 h.The default uncertainty was set to 1 h.

Colors
Stricto sensu, the colors of SSOs are observable and not derived properties.Nevertheless, we compiled the colors of SSOs in SsODNet.dataCloud, with the same rationale as for derived properties: many colors are available but spread over many studies (e.g., Dandy et al., 2003;Snodgrass et al., 2010;Dumitru et al., 2018) and they are usually not in machine-readable format.Furthermore, colors can be used for taxonomic determination (Carvano et al., 2010;DeMeo & Carry, 2013).
Several ancillary information for contextualization are recorded (Table A.3), such as the observing time, the source of measurement (plain English description and IAU Observatory code22 if available).The filters used to compute the colors are identified with the unique identifier of the SVO Filter Service23 providing transmission curves and zero points (Rodrigo et al., 2012;Rodrigo & Solano, 2020).Similarly, we record in which system the photometry is reported (Vega, AB, or ST).
The selection of best estimates is based on the time difference, ∆ t , between the observation of the two filters and how the color was computed.We favor (Table C.5) colors computed as a difference of absolute magnitudes from phase functions in each filter (Mahlke et al., 2021;Alvarez-Candal et al., 2021).In that case, we report the most-recent published value.Then we follow up with the colors computed as a difference of apparent magnitudes but corrected for light curve variations (Mommert et al., 2016;Erasmus et al., 2019).Last, we have the simple difference of apparent magnitudes (Popescu et al., 2018;Sergeyev & Carry, 2021).Whenever several estimates of the same color with the two latter methods are reported, we computed their average as in Equation 1, with the following weight to account for time difference: w i = 1/σ 2 i + 1/∆ 2 t .Whenever the information on ∆ t is missing, we set it to 1 h.
Last but not least, filter transmissions are different in each facility.For a given color (e.g., g-i), the values from different observatories may differ (e.g., between the Sloan Digital Sky Survey and SkyMapper, see Fig. 9 in Sergeyev et al., 2022).We did not merge colors obtained with different filter sets, for instance, SLOAN/SDSS (g -i) vs. SkyMapper/SkyMapper (g -i), but instead we report the most precise results.An example of these colors is shown in Figure 4.

Phase function
Phase functions describe the evolution of brightness with the phase angle (once it is corrected with respect to the Sun-target and target-observer distances).The absolute magnitude reported together with osculating elements (Section 4.2.1) is computed using the historical two-parameter HG phase function (Bowell et al., 1989), where G is generally assumed to be 0.15.This function has been shown to deviate from observed photometry at low and high phase angle, and a three-parameter HG 1 G 2 function has been proposed (Muinonen et al., 2010).We collect these parameters in the dataCloud and report them in ssoCard.Because phase functions are wavelength-dependent (Sanchez et al., 2012;Mahlke et al., 2021), we associate these parameters with the filter in which they were derived, again using the unique identifier of the SVO Filter Service (Rodrigo et al., 2012;Rodrigo & Solano, 2020).
A parameterized version of the phase function has been proposed for low-accuracy data (with two parameters, HG 12 , later refined as HG 12 , Penttilä et al., 2016).However, we stick to HG 1 G 2 parameters only, as they have been shown to convey taxonomic and albedo information (Shevchenko et al., 2016;Mahlke et al., 2021).
We present in Figure 8 the decision tree we applied to select the most relevant taxonomy for a given SSO.As a general rule, results from spectroscopy are favored over results from multifilter photometry.Within each observing technique, the results using both visible and near-infrared are favored, then those based on infrared only, and then finally those based on the visible only.Once the observing technique and wavelength range is selected, there may be several taxonomic schemes available, and we chose the Mahlke, Bus-DeMeo, SMASS, Bus, and Tholen taxonomies, respectively.
In an attempt to homogenize all the classes that have been reported for a given object, we also group similar classes under the term "complex," following the associations listed in Table C.8.We give an example of the orbital distribution of these complexes in Figure 4.

Thermal properties
Mid-infrared fluxes are often used to determine the diameter of an SSO (Section 4.2.5), from simple thermal models such as NEATM (Harris & Davies, 1999).More complex thermal models (referred to as thermophysical models, TPM, Lagerros, 1996) can also be used, but require additional information on the object such as spin, 3D shape, and so on.One parameter used in TPM is the thermal inertia (in J.s −1/2 .K −1 .m−2 ) controlling the resistance of the surface to changes of temperature.
The thermal inertia determination from spacecrafts are favored (Capria et al., 2014), followed by those determined from TPM using a priori knowledge on the spin and shape (Matter et al., 2013;O'Rourke et al., 2012), and, finally, the TPM applied to spheres (Müller et al., 2013), as listed in Table C.6.Thermal inertia (Γ) is a function of heliocentric distance (Vasavada et al., 1999;Rozitis et al., 2018).We thus report the thermal inertia at 1 au (Γ 0 ) from the Sun in the ssoCard, using the following relation:  Thermal inertia at 1 au (SI) Fig. 9: All 1681 SSOs with a thermal inertia above 1 SI (gray), the 419 with a S/N above 3 (black), and a linear regression on the latter of equation log(Γ 0 ) = 2.5 − 0.29 log(D), a result that is similar to the recent work of Hung et al. (2022).
where r H is the heliocentric distance at the time of the observations and we take α = −3/4 following Delbo et al. (2015).We present the distribution of thermal inertia against diameter in Figure 9.

Yarkovsky drift
While the orbital drift due to the delayed thermal emission by asteroid surface is extremely small (of the order of 10 −4 au/Myr, Vokrouhlický et al., 2015), it was detected for the first time almost two decades ago (Chesley et al., 2003).We favor detections that include both optical and radar observations (Farnocchia et al., 2014, for instance) over those using optical only (e.g., Del Vigna et al., 2018).Finally, we consider those (Table C.7) estimated based on the age of dynamical families (Carruba et al., 2017).Some authors have reported the semi-major axis drift, ȧ (Nugent et al., 2012), while others have given the transverse acceleration, A 2 (Greenstreet et al., 2019), as in the case of cometary dynamical models (Marsden et al., 1973).We report both parameters in the ssoCard, using the following equation from Farnoc-chia et al. (2013) to convert between quantities: with a as the semi-major axis, e as the eccentricity, and n as the mean motion (Section 4.2.1).

Summary for all SSOs: ssoBFT
The ssoCard service described in previous section provides convenient access to the best estimates of many parameters, but limited to a single SSO.The last service composing SsODNet thus provides a broad and flat table (ssoBFT) that compiles all the parameters of the ssoCard for all SSOs.This table is very large (over 591 fields for 1 223 984 SSOs, about 2.1 Gb).Yet, most fields are empty (i.e., there is no estimate of the given parameter for this SSO), resulting in only a 14.6% filling factor.We propose the ssoBFT as an enhanced character separated values (eCSV24 ) and an Apache parquet25 files for users interested in the statistical properties of the asteroid population.These files can be downloaded at static urls (eCSV26 , parquet27 ).We also provide this table to the CDS to ensure its fully VOcompliant access.

Accessing the services: SsODNet & rocks
We offer several access interfaces to the SsODNet service, described below.

REST interface
The quaero representational state transfer (REST) API is a lowlevel interface dedicated to developers.It is designed to offer an easy-to-use and fast solution to search for planetary objects (sso and search methods) to resolve their designations (resolver method) or to be used as an auto-completion mechanism for names (instant search method) into Web forms and applications connected to the Internet.In the framework of the Virtual Observatory, no standard protocol nor technical specification is quite capable of designing a fast-search engine.Thus, the core of SsODNet name resolver does not follow any current VO standard.Nevertheless, the underlying technology and the API we have chosen being intrinsically interoperable, the quaero service can easily be included in any VO ecosystem.

Web-service interface
We provide a Web-service interface, built upon XML and SOAP technology, that allows for a full interaction with SsODNet through several methods: (i) resolver: to identify SSO (high level API), (ii) datacloud: to retrieve all known values of SSO properties, (iii) ssocard: to retrieve the best estimates of SSO properties.The user can simply post a request to the method endpoints to gather corresponding data, using a data transfer program such as wget or curl.More advanced users can implement the SOAP Web service to ensure an application-to-application communication between SsODNet and a software or a public Web page.

Web form interface
The easiest way to search for a SSO and to quickly consult its properties may be to use SsODNet dedicated Web form.The best estimates of the physical and dynamic properties (the ssoCard) are displayed in a comprehensive manner, together with bibliographic references.We also provide links to all values (i.e., dataCloud entry for each property of the SSO), and to the subset used to compute the best estimates (as defined by the decision trees, see Section 4).

Python interface: rocks
We provide a python interface to SsODNet named rocks.It offers a programmatic entry point both for data exploration and data processing.The interaction with the SsODNet repositories is asynchronous and results are cached on the user-side, providing a responsive user experience.

$ rocks [command|parameter] [asteroid_identifier]
Here, the parameter can be any key from the ssoCard or dataCloud catalogs, while the asteroid_identifier is any identifier that can be resolved by quaero.The result of the query is printed in the console.Commands such as id and info serve to identify an asteroid and to print the asteroid's ssoCard.

$ rocks taxonomies ceres
The asynchronous interaction with the locally cached data and the remote SsODNet repositories allow for a fast analysis process without the use of resource-intensive multiprocessing or multi-threading strategies.To provide an estimate of the execution times, we identified all asteroids in the SDSS Moving Object Catalog DR1 28 and retrieved their ssoCard.The catalog contains observations of 10,585 unique minor bodies, largely referred to by designations that are no longer the main identifier of the object.Using a combination of quaero queries and a local asteroid name-number-designation index, rocks identifies all objects within 2.5 s.The ssoCards are retrieved within 320 s from SsODNet, about 30 ms per asteroid.rocks then performs data validation and deserialization (i.e., converting the JSON server response into a python object) within 120 s, that is, about 11 ms per asteroid.A second execution of the analysis script would benefit from the locally cached ssoCards, rendering any request to SsODNet obsolete.
To install rocks, we can use the python package index (PyPI) under the package name space-rocks.The online documentation29 provides a guide on getting started and tutorials to achieve more advanced data processing results.We note that rocks is actively developed and maintained by the authors of this work.

Future developments
We foresee several lines of development for the SsODNet service: data compilation and curation, expansion of the set of parameters and types of SSOs, and development of the interface.
Data compilation: First and foremost, we will continue to compile data into the dataCloud, aiming for completeness with respect to the listed parameters.Indeed, it is the building block of the ssoCard and the ssoBFT, which are automatically generated from the entries in the dataCloud.On the other hand, quaero has been working and been updated weekly for several years, following the growing list of SSOs listed by the MPC.Thus, a continuous scientific monitoring of publications is required for the service.
We welcome any feedback, especially on data sources that may be missing or erroneous entries.While we conducted multiple checks on the data included in SsODNet, some typographical errors may lurk in the unprecedented size of the data compilation.We will happily include sources that are not included in the current release of the service and correct entries.
Furthermore, SsODNet can be used by any group or researcher to publish regularly updated data.A simple file (VOTable, csv, ...), with sufficient metadata at a static url can be used as a source, without requiring a server or a database with a web service.

Set of parameters:
The set of parameters currently available in SsODNet is already broad, covering dynamical, surface, and physical properties (Table A.1).There are, however, other parameters of interest that will be added to the dataCloud (and, hence, ssoCard and ssoBFT), such as the source region probabilities for near-Earth objects (Granvik et al., 2017) and their minimal orbital intersection distance with planets (MOID, Marsden, 1993), activity for asteroids and Centaurs (Hsieh & Jewitt, 2006;Jewitt, 2009), and radar albedos (Neeley et al., 2014).Additional computed parameters can also be added in ssoCard, such as surface gravity or escape velocity.
Types of SSOs: The present release of SsODNet focuses on asteroids because they are the prime targets of study of the authors.The service was nevertheless designed to cope with all classes of SSOs: comets, planets, satellites, and interstellar objects.For instance, quaero already deals with the designation of all these categories.
We thus welcome partnership with everyone willing to contribute to build this community database.Beside the collection and curation of data, a set of parameters relevant for these celestial bodies must be defined (e.g., non-gravitational acceleration for comets, libration amplitude and frequency for satellites), together with decision trees to estimate the best parameters.SsODNet has been envisioned as a service to the community and any contribution to it will expand its advantages.
User interface: SsODNet is mainly a machine-machine service, allowing for on-the-fly data retrieval.Both quaero and ssoCard are designed to cope with constant queries.The dataCloud entries for a given SSO can also be dumped easily, and the ssoBFT downloaded as a whole.
We plan to develop more advanced possibilities to query the data, both in dataCloud and ssoBFT.Users may be interested by searching entries from a given bibliographic reference, rather than for a specific SSO for instance.Similarly, users may be interested in a subset of the ssoBFT only (e.g., some specific parameters only for SSOs fulfilling certain conditions).While the latter is possible with TAP on the version of the ssoBFT hosted at the CDS, the former requires development on the server side of SsODNet.

Conclusions
We present a new Web Service, SsODNet, which provides a convenient solution to the issues of SSO identification and the compilation of properties.It consists of a suite of applications, each with its own programming interface: quaero for name resolution, dataCloud compiling SSO properties, ssoCard providing the set of best estimates for each SSO, and ssoBFT compiling the latter for all SSOS.These entry points deliver JSON as native outputs.We have released a python interface for these services: rocks, available in the python package index (PyPI).SsODNet is fully operational.The name resolver quaero is updated weekly to follow SSO discoveries.We plan on monthly updates for the others applications, following compilation of data from continuous monitoring of new publications.The future evolution of the service includes an extension of the suite of properties and classes of SSOs, along with an advanced query interface to retrieve large corpus of data.

Mass from close encounter deflection
The mass is determined from the orbital deflection of smaller asteroids Standish & Hellings (1989) Bin-IM Mass from optical imaging a binary system Mass from a binary system imaged in the optical Merline et al. (1999) Bin-Radar Mass from radar observations of a binary system Mass from a binary system observed by radar echoes Ostro et al. (2006) Bin-PheMu Mass from mutual phenomena in a binary system Mass from a binary system from the timings and shape of mutual event from light curves Pravec et al. (2000) Bin-Genoid Orbit and mass from a multiple asteroidal system using Genoid algorithm Orbital elements and mass determination from a multiple asteroidal system with Genoid Yarkovsky_drift The order favors estimates from space mission encounters, then thermophysical models based on 3D shapes, and, finally, estimates from thermophysical models based on limited shape and spin information.

Fig. 1 :
Fig. 1: Histogram of the number of designations for each class of object.

Fig. 3 :
Fig. 3: General workflow used to compute the best estimate of each parameter.

Fig. 4 :
Fig. 4: Distribution of families (first panel), albedo (second), colors (third, using a color-scheme similar to Parker et al. (2008) based on a code by Ivezić et al. (2014)), and taxonomy (fourth) against proper elements (semi-major axis and sine of inclination).The number of plotted objects is reported in each panel.

Fig. 5 :
Fig. 5: Kernel density estimate (KDE) of the density of the C, S, X, and B complexes.The bimodal distribution of X-types highlights the P and M sub-classes (average p V of 0.044 and 0.129, below and above 2000 kg.m −3 , respectively).Similarly, Pallas is the sole contributor to high-density B-types.
Fig. 6: Rotation period (top) and obliquity (bottom) vs diameter for 17,201 and 2596 SSOs, respectively.Darker shades of grey indicate higher density of points.

Table 1 :
Statistics of the number of SSO designations by object class.
record is held by comets P/Halley (1P), with 59 designations, and P/Encke (2P), with 89 designations.We present in Figure1the distribution of the number of designations by type of SSOs and we present a summary in Table1.2.2.Quaero: /"k w ae " .ro:/This is the core of SsODNet.It ensures the reliability of the naming of SSOs and it allows us to cross-match identifications between their actual names and the designations used over time in the various data sets.In August 2022, we counted 1 288 838 solar and extra-solar objects for 5 360 208 designations (1:4 ratio).

Table A
Fields follows the original MPCORB data, see the online documentation https://www.minorplanetcenter.net/iau/info/MPOrbitFormat.html.

Table A .
11: Description of the fields in the collection pairs of the dataCloud.

Table A .
12: Description of the fields in the collection phase_function of the dataCloud.
Table C.6: Ranking of methods for thermal properties (thermal_properties).