Difference between revisions of "PSA Dictionary"

From The SBN Wiki
Jump to navigation Jump to search
(Safety Save)
 
(Safety Save)
Line 228: Line 228:
 
----
 
----
  
= Schematron Note =
+
= Schematron Notes =
  
There are hard-coded rules to check that context reference LIDs follow very specific naming rules and are in the PSA namespace. These appear to follow the PDS3 catalog object relationships.
+
* There are hard-coded rules to check that context reference LIDs follow very specific naming rules and are in either the PSA or PDS namespace, depending on context object type. These appear to follow the PDS3 catalog object relationships. Seems like this would be problematic for Rosetta and long-term.
 +
* Product_Document is prohibited in data collections.  This is problematic for overview documents.
 +
* All observational products are required to have a spacecraft somewhere in their observing system.  This is problematic for the ground-based data.
 +
* There is a rule enforcing the prohibited targets mentioned in the conventions document by testing against the context LIDs.
 +
* There is a rule requiring Investigation_Area in Observation_Area (where it is schematically required anyway) and Context_Area (where it is not).
 +
* There is a rule limiting all collection ID segments to the list in the conventions document.
 +
* There is a rule requiring the present of at least one Mission_Area in Observation_Area (but not in Context_Area).
 +
* There is a rule requiring Modification_History in the Identification_Area.
 +
* There is a rule excluding '''telemetry''' as a processing_level.
 +
* There is a rule that appears to think it is limiting data collections to contain only Product_Observational products, but it instead requires that a Product_Observational is inside a "data_*" collection (which isn't quite the same thing.
 +
* There is a rule that duplicates the schematic requirement that an Observation_Area contain an Observing_System class.
 +
* Primary_Result_Summary, Science_Facets, and at least one Observing_System_Component of type '''Instrument''' are required in Product_Observational.

Revision as of 13:29, 29 May 2019

PDS Schema, version 1.1.0.1, from the XSD and Schematron files.

Exposed Elements:

  • Mission_Information
  • Observation_Context
  • Processing_Context
  • Quality_Information
  • Sub-Instrument

Note that none of the classes or attributes is defined.


<Mission_Information>

REQUIRED

Required by Schematron rules.

<spacecraft_clock_start_count>

OPTIONAL

ASCII string; no validation.

<spacecraft_clock_stop_count>

OPTIONAL

ASCII string; no validation.

<mission_phase_name>

REQUIRED

ASCII string; no validation.

<mission_phase_identifier>

OPTIONAL

ASCII string; no validation.

<start_orbit_number>

OPTIONAL

Non-negative integer

<stop_orbit_number>

OPTIONAL

Non-negative integer; not validated against start_orbit_number.


<Observation_Context>

OPTIONAL

No minimal existential requirement for content.

<instrument_pointing_mode>

OPTIONAL

Must have one of these values:

  • Surface
  • Atmosphere
  • Limb
  • No Pointing
  • Space

<instrument_pointing_description>

OPTIONAL

ASCII string limited to 255 characters and no formatting.

<observation_identifier>

OPTIONAL

ASCII string; no validation.


<Processing_Context>

OPTIONAL

<processing_software_title>

REQUIRED

ASCII string

<processing_software_version>

REQUIRED

ASCII string

<Processing_Inputs>

OPTIONAL


<Processing_input_Identification>

REQUIRED, repeatable

<type>

REQUIRED

Must be one of:

  • telemetry
  • PDS product
  • SPICE kernel
  • auxiliary

Note that there is an empty Schematron rule on the equivalent context and some dicey syntax in the rule with the standard values that make this validation problematic.

<file_name>

REQUIRED

<pds:Internal_Reference>

OPTIONAL

No values are defined for <pds:reference_type> in this class.


<Quality_Information>

OPTIONAL

<quality_flag>

REQUIRED

ASCII string

Note that the value is unconstrained in any way (as well as undefined).

<Sub-Instrument>

OPTIONAL

<identifier>

REQUIRED

ASCII string

<name>

REQUIRED

ASCII string

<type>

REQUIRED, repeatable for up to 3 values

Must be one of:

  • Accelerometer
  • Biology experiment
  • Chemistry laboratory
  • Compilation
  • Dust analyser
  • Electric field instrument
  • Gamma ray detector
  • Gas analyser
  • Gravimeter
  • Imager
  • Imaging spectrometer
  • Interferometer
  • Langmuir probe
  • Magnetometer
  • Mass spectrometer
  • Microphone
  • Microscope
  • Mutual impedance probe
  • Neutron detector
  • Not applicable
  • Particle analyser
  • Polarimeter
  • Radar
  • RadioReceiver
  • RadioScience
  • Relaxation sounder
  • SPICE kernels
  • Seismometer
  • Sensor suite
  • Spacecraft sensors
  • Spectrograph
  • Spectrometer
  • Spectrum analyser
  • Sub-surface tool
  • Surface tool
  • Temperature sensor
  • Weather station

<subtype>

OPTIONAL, not repeatable

ASCII string.

Note that there is an empty Schematron rule where one would expect a permissible values list.



Schematron Notes

  • There are hard-coded rules to check that context reference LIDs follow very specific naming rules and are in either the PSA or PDS namespace, depending on context object type. These appear to follow the PDS3 catalog object relationships. Seems like this would be problematic for Rosetta and long-term.
  • Product_Document is prohibited in data collections. This is problematic for overview documents.
  • All observational products are required to have a spacecraft somewhere in their observing system. This is problematic for the ground-based data.
  • There is a rule enforcing the prohibited targets mentioned in the conventions document by testing against the context LIDs.
  • There is a rule requiring Investigation_Area in Observation_Area (where it is schematically required anyway) and Context_Area (where it is not).
  • There is a rule limiting all collection ID segments to the list in the conventions document.
  • There is a rule requiring the present of at least one Mission_Area in Observation_Area (but not in Context_Area).
  • There is a rule requiring Modification_History in the Identification_Area.
  • There is a rule excluding telemetry as a processing_level.
  • There is a rule that appears to think it is limiting data collections to contain only Product_Observational products, but it instead requires that a Product_Observational is inside a "data_*" collection (which isn't quite the same thing.
  • There is a rule that duplicates the schematic requirement that an Observation_Area contain an Observing_System class.
  • Primary_Result_Summary, Science_Facets, and at least one Observing_System_Component of type Instrument are required in Product_Observational.