internal reference management in registry: lost structure

[tloubrieu-jpl]

Describe the bug
When observing_system component's description is missing

<Observing_System>
OSIRIS-REx Camera Suite (OCAMS)
<Observing_System_Component>
OSIRIS-REx
Spacecraft
Origins, Spectral Interpretation, Resource Identification, Security - Regolith Explorer Spacecraft
<Internal_Reference>
<lid_reference>urn:nasa:pds:context:instrument_host:spacecraft.orex</lid_reference>
<reference_type>is_instrument_host</reference_type>
</Internal_Reference>
</Observing_System_Component>
<Observing_System_Component>
OCAMS
Instrument
<Internal_Reference>
<lid_reference>urn:nasa:pds:context:instrument:ocams.orex</lid_reference>
<reference_type>is_instrument</reference_type>
</Internal_Reference>
</Observing_System_Component>
</Observing_System>

In the registry:
"pds/Observing_System_Component/pds/description": "Origins, Spectral Interpretation, Resource Identification, Security - Regolith Explorer Spacecraft",
"pds/Observing_System_Component/pds/name": [
"OSIRIS-REx",
"OCAMS"
],
It is not possible to know to which of the 2 components the description is attached.

To Reproduce
Use attached XML as an example.
Harvest it is load it in the registry.

Expected behavior
TBD

** Version of Software Used**

Harvest 3.3.0

Applicable requirements
TBD

[tdddblog]

• The "flat" structure of Elasticsearch documents is optimized for search and not for data retrieval. The loss of a structural information is a known issue. We could not do anything about it. You can store the original label as a BLOB and then extract the information you need from the original XML file.
• <Observing_System> section contains redundant / duplicate information from corresponding context products, such as "urn:nasa:pds:context:instrument_host:spacecraft.orex::1.1". Context products should be the primary source of information about instrument host and instruments.

[jordanpadams]

@tloubrieu-jpl how did we decide we were going to handle this?

[tloubrieu-jpl]

@jordanpadams I don't remember if we had a solution for that.

I like the answer of @tdddblog as elasticSearch metadata is made for data search we should not use these fields to 'rebuild' the pds4 labels information but the XML file stored as a blob, or later the graph database.

I think we can close the ticket with that.

[jordanpadams]

closing this as wontfix for the time being. i imagine this is something that would be handled (if we care?) by a graphDB implementation.