Validate Warning: Existing Context Product Used for a Second Purpose

[radiosci]

If an existing Observing System Component can also be a Target, should a new context product be written for the target situation?

For example, ground antennas in the Deep Space Network (DSN) are Observing System Components when used to collect radio science data from planetary missions. But they are also "targets" of DSN Monitor files, which record configuration and status of the data collection system.

Validate 3.6.3 has started throwing warnings when Telescope and ground Radio Science Instrumentation context products are referenced as targets in DSN Monitor file labels. At least three solutions have been proposed:

(1) A physical object should have only one context product; ignore the warnings (and hope future versions of validate don't promote them to errors).
(2) Copy the existing context product, then edit the copy so that it is now a Target (equipment) context product. There are now (at least) two context products describing the same physical object; but the warnings should go away so long as each is used correctly.
(3) Modify the code in validate so that context products used for multiple purposes are allowed to pass. If "yes", should there be restrictions?

This problem has arisen during lien resolution following a Cassini raw radio science data migration review. When originally delivered, the migrated data passed validation. Since then, validate has evolved and typical labels have a dozen warnings.

[jordanpadams]

@radiosci do you have an example label or two we could use for reference?

[radiosci]

An example bundle_gwe2.xml (as a *.txt file) has been added. In this form, validate generates two warnings (report2.txt). (1) The first wants "type=Equipment" to be changed to "type=Spacecraft", to match the existing spacecraft context product. But oXygen immediately gives an error (report3.png) disallowing "Spacecraft". (2) The second warning suggests replacing "type=Equipment" with "type=[N/A]", which resolves nothing.

[radiosci]

report2.txt

bundle_gwe2.xml.txt

[pdsen-ci]

@radiosci Thanks for the additional inputs here.

I am definitely OK with updating validate to support this, but what I think we need defined more clearly somewhere in the SR or elsewhere is if an Instrument Host is defined as a target, what is the type associated with that object? We could just ignore this check in these scenarios if we want to leave it open-ended, but it would probably be better if we standardized it. IMO, the type should really be the actual Instrument_Host.type since that is the type of the object as defined by the information model. It may be a target of something, but the object is still a Spacecraft. I would be OK with Equipment, but we should standardize on that mapping, versus allowing ad hoc types to be used.

Thoughts?

[radiosci]

Personally, I don't care. I have been using "Equipment" because that seems to reinforce the idea that my reused object is now the target of a monitoring observation. But there may be other scenarios in which the reuse would be completely different. I can't think of any; but that was the reasoning behind my question about possibly setting limitations on reuse. Since the reference is already within a Target object, perhaps that's good enough and the original type should be carried forward; but I don't know how or why EN needs to check for type mismatches.

[matthewtiscareno]

Hi all. @radiosci wants to forge ahead with his lien resolution, even if that he means he will just have to ignore the copious warnings he's receiving along these lines. EN: It would be great if you can let us know whether it seems like you can or will do anything about this? Also, should this discussion be turned into an issue, or left as it is?

[rsjoyner]

@radiosci @jordanpadams

(3) Modify the code in validate so that context products used for multiple purposes are allowed to pass. If "yes", should there be restrictions?

I think there could be a 4th option where the Context Product is defined to have / play a secondary role as a "target". This is consistent with other types of objects as well -- especially when referencing the many "roles" that DSN has.

This might complicate Validate a bit. But, I think it explicitly defines the "target" role and possibly other duality functions.....

What say you ?

[radiosci]

Would Product_Context.product_data_object (optionally) become multi-valued?

[matthewtiscareno]

@rsjoyner: I don't understand how your 4th option is different from @radiosci's 3rd option.

If a data product contains an observation of a spacecraft (say Cassini), then why exactly does the warning appear in @radiosci's label? Is it because the context product for Cassini includes Product_Context.Instrument_Host and not Product_Context.Target? Is that what causes the use of bundle_to_target to throw a warning?

[jordanpadams]

@matthewtiscareno that is about right. Basically, there is no where in the IM that would tell validate what "type" should be associated when this context object is a target. We can make assumptions (e.g. if target == Instrument_Host context object, then target type == Equipment), but that seems like something we shouldn't do. The other option is we just skip this check altogether and you could put anything you want, but that also doesn't seem ideal for data consistency.

For the latter option, I would recommend just using the --disable-context-mismatch-warnings

Ultimately, the standards do not "require" the type value match the value in the context product. This warning in validate is intended as a metadata quality check to ensure consistency between context objects and the data referencing them.

[matthewtiscareno]

Okay, so @radiosci and @mace-space are moving forward with this delivery. I suppose they will simply ignore the warnings. However, this is likely not the last time radio science will be targeting an object whose context product calls it an instrument host. It would be nice to have a general long-term solution for such situations.

Would it be a good idea to convert this discussion into an issue? If so, how would we do that?

[jordanpadams]

@matthewtiscareno You can turn this into an issue, but should this be an issue with the DDWG? It seems like this is something that should be clarified in the standards. As you say, if this is going to happen often, we should provide clear guidance for how this should be done moving forward so we are consistent.