Added a choice of target between strings or official nomenclatures

[J-Christophe]

Hi Trent,

I think it is important to add a controlled vocabulary for solar bodies name so that software can understand the semantic. I use the name of the planet when I am doing a drag n drop of the STAC catalog on my apps. According to the solar body name, I show a different background map.

So, I have modified a little bit your schema for adding this feature:
Added a choice of target between strings or official nomenclatures from https://planetarynames.wr.usgs.gov/Page/Planets.

Basically, this addition should not break your previous schema. It simply adds the choice between using for each element of the array a free string or an element of the controlled vocabulary from https://planetarynames.wr.usgs.gov/Page/Planets.

It should be great and very useful if you could propose this extension in https://stac-extensions.github.io/

Thanks,
Jean-Christophe

[thareUSGS]

@jlaura can you review also?

@J-Christophe In general, I am a fan of enumerations, but it also might be too limiting here and require regular updates. Currently, we are dealing with a PDS3 to PDS4 migration (for old Voyager data), where no target is specified and we painfully stuck with our current enumerations needing an update to be pushed into the PDS4 information model. Not hard, but takes time.

Is there some magical schema rule to have a recommended list, but allow it to be free-text?

Also the list on https://planetarynames.wr.usgs.gov/Page/Planets is a good place to start, but is probably doesn't have everything we need. For example, soon we will need Psyche (and should the Sun be there)?

[J-Christophe]

Is there some magical schema rule to have a recommended list, but allow it to be free-text?

I think I did that. A recommended list is an enumeration but with the "oneof", you can choose for each element of the array of ssys : one of the recommended list or a free text. Maybe, we need a special namespace related to the recommended list to show that the name is "standard". In this way, provider can see the difference in the json between recommended element and free text. The interest between the two concepts is that the software could implement a feature related to an enum but cannot do it / difficult to do if the text is free (this is my case). A free text is only good for displaying information but not for processing that information. Also the list on https://planetarynames.wr.usgs.gov/Page/Planets is a good

place to start, but is probably doesn't have everything we need. For example, soon we will need Psyche (and should the Sun be there)?

True. Sun should be added. It is not a problem to add an element in the enumeration with the time. However, modifying an element of the enum is not a good idea (because software could use a specific name for processing the information). If there is a need to do that , it is better to add a version number somewhere. Jean-Christophe

[jlaura]

Apologies that this languished for so long. I had not realized that it was open! I have a single comment that I think will clean up the schema a small bit. Let me know what your thoughts are!

[jlaura]

I do not believe that this needs to make use of oneOf. I think just:

"type":"array",
"minItems": 1,
"items": {
  "type":"string",
  "enum": [
    "Mercury",
    "Venus",
    "..."
    ]
},
"additionalItems": false

That should force at least one item from the enum be in the targets list.

[jlaura]

With #6, I don't know that having an enum limited to planet name makes sense any longer. Perhaps the correct thing to do is to update the documentation to link to the IVOA list of targets (which is itself a list of resources of targets). Thoughts?

[thareUSGS]

With #6, I don't know that having an enum limited to planet name makes sense any longer. Perhaps the correct thing to do is to update the documentation to link to the IVOA list of targets (which is itself a list of resources of targets). Thoughts?

I am fine with a smaller enumerated list (or using a longer list provided from elsewhere) as long as we can still enter a free text string. Above Jean-Christophe states, "A recommended list is an enumeration but with the "oneof", you can choose for each element of the array of ssys : one of the recommended list or a free text."

[jlaura]

If this is from a list or free text, my preference is to have this be an update to the README and not a 'sort of enum/free form' field. It seems we either do schema level validation or we don't This would be a partial validation that, from my perspective, doesn't make sense.

I would propose that we update the README to include something like:

The best practice is to use the official designation of the target as defined by IAU. This parameter is case sensitive (mixing lower/upper cases) and all values must use the standard spelling and case; unusual characters (such as intermediate spaces) are allowed, except quotes (preferably changed to _ , which is the single-character wildcard in TAP queries). Data providers must be aware that services which do not use the IAU designations might not be accessible by the clients. (From https://www.ivoa.net/documents/EPNTAP/20201027/WD-epntap-2.0-20201027.html#tth_sEc2.1.3)

Other best practices are listed below:
The Exoplanet Encyclopedia provides a nearly complete list of currently known extrasolar planets: http://exoplanet.eu/[3](https://www.ivoa.net/documents/EPNTAP/20201027/WD-epntap-2.0-20201027.html#tthFtNtAAD) (also available as an EPN-TAP service)
Meteorite catalogues can be found here:
http://www.nhm.ac.uk/research-curation/research/projects/metcat/search/indexsing.dsml[4](https://www.ivoa.net/documents/EPNTAP/20201027/WD-epntap-2.0-20201027.html#tthFtNtAAE)
and http://www.lpi.usra.edu/meteor/index.php[5](https://www.ivoa.net/documents/EPNTAP/20201027/WD-epntap-2.0-20201027.html#tthFtNtAAF)
The catalog of lunar samples is available here: http://www.lpi.usra.edu/lunar/samples/[6](https://www.ivoa.net/documents/EPNTAP/20201027/WD-epntap-2.0-20201027.html#tthFtNtAAG)
Other planetary samples are listed in topical web sites, e.g. samples from the Stardust mission are described here:
http://curator.jsc.nasa.gov/stardust/catalog/[7](https://www.ivoa.net/documents/EPNTAP/20201027/WD-epntap-2.0-20201027.html#tthFtNtAAH)
Asteroids: Usage is to use preferably name (if it exists) or principal designation (the number is not used here, it can be included in alt_target_name)
Calibration targets: Values can relate to existing names in a given archive (e.g., the PSA contains values such as bias, checkout, dark, flatfield, internal source…)

[J-Christophe]

OK, README is a good idea. +1
Jean-Christophe

[jlaura]

Closing in favor of #7. Please have a look at that PR!