<div dir="ltr"><div dir="ltr">On Tue, Jun 15, 2021 at 3:27 AM Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Anne,<br>
<br>
On Mon, Jun 14, 2021 at 10:44:49AM -0400, Anne Catherine Raugh wrote:<br>
&gt; The tags are documented as part of the PDS4 Information model. They are<br>
&gt; part of the information model label taxonomy in what we call the<br>
&gt; &quot;Primary_Result_Summary&quot; class. The formal definition from the Information<br>
&gt; Model (IM) is here:<br>
&gt; <br>
&gt; <a href="https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1G00.html#d5e15413" rel="noreferrer" target="_blank">https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1G00.html#d5e15413</a><br>
<br>
This points to a ToC entry for me, which then points to <br>
<a href="https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1G00.html#d5e85" rel="noreferrer" target="_blank">https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1G00.html#d5e85</a><br>
<br>
-- and that I find intriguing, because its terms seem to be much<br>
closer to what for us is the relationship between a primary dataset<br>
and component artefacts, which we keep in the datalink/core<br>
vocabulary, <a href="http://www.ivoa.net/rdf/datalink/core" rel="noreferrer" target="_blank">http://www.ivoa.net/rdf/datalink/core</a>.  I&#39;m tempted to<br>
try and match the two vocabularies to see what we might be missing.<br></blockquote><div> </div><div>Check with Baptiste Ceccione - he may have attempted that very thing already, since we&#39;re a Planetary archive. I&#39;ve been reading IVOA standards for two weeks now and I&#39;m still working out in my mind how the mapping for our product might work in practice for an EPN-TAP interface. And then, of course, there are the structure translations to understand. That&#39;s the next set of standard on my reading list.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Out of curiosity: Do you have statistics on how much the different<br>
product types are being used, both in terms of depth (&quot;how many are<br>
there of each type?&quot;) and of breadth (&quot;how many projects are offering<br>
products of some type?&quot;)?<br></blockquote><div><br></div><div>I do not, and I am curious myself. Most of our data is still under the old standard (called &quot;PDS3&quot;) - little formal modeling, even less consistency, very, very hard to understand easily what is in our own archive and no access to holdings of other nodes. The PDS4 standard is the opposite - very structured, and it would be easy to poll across nodes if we all had all our data converted and registered. We&#39;re at least a year or two away from that. We have over 3500 data sets to convert, each of which contains from several hundred to several hundred thousand individual data products (a &quot;product&quot; for us would be, for example, one image with its PDS4 label, bad pixel map, quality map, and whatever other additional data unique to that image that the label describes).</div><div><br></div><div>My node specializes in small bodies (I&#39;m at the comet sub-node), so spectroscopy is always present in at least one form for every mission we work with, and sometimes there are multiple instruments producing spectral data in different ranges and formats. Some of the more recent missions for which we are the data archive are:</div><div><ul><li>Rosetta (PSA also archives these data)</li><li>New Horizons</li><li>Deep Impact/EPOXI</li><li>DAWN (the NASA mission)</li><li>Hayabusa</li><li>OSIRIS-REx</li><li>etc.</li></ul></div><div>It would be a major project to pull up even rough numbers for the data at my own site (the comet sub-node), which is largely why it has not been done. Once the data are migrated to PDS4 and registered, a query to the registry would provide the numbers easily.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Oh, and: From &quot;Class Hierarchy&quot; it would see to me that your (in<br>
effect) vocabulary is flat; for instance, I&#39;d have expected to see<br>
&quot;Context&quot; as somehow narrower than &quot;Document&quot;.  Was it a conscious<br>
design decision that it&#39;s not?<br></blockquote><div><br></div><div>Yes. As I understand it, the derivation exists in the ontology database (the Information Model &quot;lives&quot; in a Protegé database - the implementation is generated almost, if not entirely, automatically from the database), but there was push-back from many nodes representative about how complicated the full structure looked in a label. The argument was that it was so complicated that no user would ever use it, because they didn&#39;t want to be bothered. So we flattened the structure, which makes it look simpler but, in fact, makes it more complex to understand and use correctly (and also parse and interpret). Now that people are used to looking at XML (that was a big change from our old syntax), I think if we had that discussion again it would end differently. So I hope we will get to revisit it for our version 2.0.  I think it is key to discoverability across archives, not just PDS nodes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Closer to what we&#39;re trying in product-type is what I&#39;m finding in<br>
classes like &quot;Array_2D_Spectrum&quot;, which also have a deep hierarchy<br>
(cf.<br>
<a href="https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1G00.html#d5e3914" rel="noreferrer" target="_blank">https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1G00.html#d5e3914</a><br>
for an example).<br>
<br>
What I couldn&#39;t quite work out there: Is there a way for a machine<br>
(that, I think, would treat the class names as opaque) to work out<br>
that Array_2D_Spectrum and Array_3D_Spectrum offer spectrally<br>
resolved data?  And why is there no 1D spectrum?<br></blockquote><div><br></div><div>If the class name is ignored, then the signifier that a product contains spectral data would be the presence of the Spectral_Characteristics class in the Discipline_Area of the label. The core PDS4 namespace is extensible by adding namespaces to provide detailed metadata in more restricted contexts. There are a number of &quot;Discipline Dictionaries&quot; that are used across nodes to provide metadata specific to science discipline. The Spectral Discipline Dictionary identified spectral dimensions and defines binning parameters.  (I maintain this dictionary, so it has a detailed user guide on my wiki: <a href="https://sbnwiki.astro.umd.edu/wiki/Filling_Out_the_Spectral_Dictionary_Classes">https://sbnwiki.astro.umd.edu/wiki/Filling_Out_the_Spectral_Dictionary_Classes</a>.)  If a data submitter is providing spectral data (photon spectra, that is), then the node reviewing the data should ensure that the Spectral_Characteristics class is also included in the data labels. If this class is present, then the data object it describes contains spectral data. If this class is not present, then there should be no photon-spectra in the data. (Mass spectra, time-of-flight spectra, color spectra, etc. are not included in this dictionary.)</div><div><br></div><div>There is no Array_1D_Spectrum because 1D spectra are not presented as arrays. That looks like the single biggest problem we&#39;ll have making our linear (that&#39;s how I think of them) spectra available through an IVOA interface. Linear spectra are present in the archive in one of two formats: Either a table, where each row describes the measure value and all related parameters for one spectral bin; or as a table where each row contains one spectrum and related data for each bin. The vast majority of the time, these tables are ASCII, not binary. And the column content varies so widely that attempts to define standard column sets have failed. No attempt was ever made to define standard column names, because there was no enforcement mechanism apart from fallible (and fickle!) human review.</div><div><br></div><div>I suspect there are some binary spectral tables in the archive I&#39;ve forgotten about, and when we get to the realm of radio data I would expect binary rather than ASCII data. I always have to find an expert when I need to understand what is going on in a radio data set.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I&#39;m asking these questions because I&#39;d *expect* (without actual<br>
evidence) that &quot;I need spectrally resolved information on X&quot; is one<br>
of the more common use cases in this field of data discovery, and<br>
every time I think of it I reach a different opinion on whether it&#39;s<br>
a good idea to serve users cubes when they were presumably expecting<br>
to see plain ol&#39; 1D spectra and their client programmes will just say<br>
&quot;Can&#39;t open your file&quot;.  Do you have any experience with user<br>
expectations in one way or the other?<br></blockquote><div><br></div><div>Not directly. I&#39;m a programmer by training, rather than a researcher, so I don&#39;t have any significant personal experience. My user community is also different from an astrophysics community. They study small bodies - data are very, very scarce on any particular small body, so the typical question is &quot;Does any such data exist?&quot; If a researcher is lucky enough to find something, they will then figure out how to use whatever format the data come in. Every datum is precious.</div><div><br></div><div>Missions to small bodies don&#39;t have much of an effect on that, even though they can return large amounts of data. The parameters of mission data are well-known, and someone planning to analyze data from, say, the Alice spectrometer on New Horizons already knows it has an oddly shaped slit and a wavelength range in the UV and resolution that depends on which end of the slit you&#39;re examining - or at least that&#39;s the first thing they find out. Since no other mission has even remotely similar data on Pluto, there&#39;s really nowhere else to go.  If you don&#39;t enter parameters that would select the Alice spectra, you will be told no data exist.</div><div><br></div><div>So in the small body community, and in planetary mission data generally (maybe not for Mars), if you are too specific in your request parameters you are likely to find nothing because there is so little data. That seems likely to continue for the next generation or two at least. There are a LOT of small bodies, and it takes a long time to design and fly a mission to gather data.  Data coverage will probably continue to be little islands in vast oceans of nothing for some time to come.</div><div><br></div><div>I would expect this to be different for ground-based data as it becomes possible to search more and more observatory holdings for small bodies images. Then there will be enough potential coverage, at least, to make finer-grained searching a fruitful activity. For small bodies, it is valuable to be able to go back through historic data, looking for those precious data points.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; It was a struggle to get metadata like this into the PDS4 Information<br>
&gt; Model, because historically PDS has only ever described its data in terms<br>
&gt; of its source (which instrument, which spacecraft, which mission) and its<br>
&gt; target (which planet, and even non-planet targets were problematic). So I<br>
&gt; view it as a start, but I hope we can do better for version 2.0.<br>
<br>
Yeah -- good metadata is data altruism, as the data creators can do<br>
without much of it during initial data exploitation.  So, I think<br>
it&#39;s never an easy sell...<br></blockquote><div><br></div><div>It also takes a bit of imagination. If someone had thought at the time &quot;What happens 50 years from now, when NASA has flown a couple hundred planetary missions?  How will people find data if they don&#39;t know the names of the instruments that collected data before they were born?&quot;  - or, in other words, &quot;What if this archive is successful?&quot; - then perhaps they would have planned for success...</div><div> </div><div>Regards,</div><div><br></div><div>-Anne.</div></div></div>