Forum: LTDP SAFE

GMV S.A.U.

During the PDR-C collocation meeting, it was agreed to analyse the possibility of providing a separation of the EO collection metadata and the Earth Observation Product metadata within the SAFE metadata model. This idea was previously introduced by a discussion started in the forum about this issue (see https://wiki.services.eoportal.org/tiki-view_forum_thread.php?comments_parentId=1044 )

The attached document “EO Collection and EO Product metadata separation trade-off” (PDGS-SAFE-GMV-TN-12/0185) provides the analysis and conclusions reached on this topic.

All your comments will be appreciated.

Adrián Sanz (GMV)
LTDP SAFE Project Manager

Stephan Zinke

EUMETSAT agrees with the findings presented in this paper.
The new approach looks much better, because it more clearly separates product from (redundant) collection-metadata and it is aligned with what ESA HMA has defined (although it makes the usage a bit more complex because of cross-links between the different packages).

Perfectly agree with the content of the document.

However, I have a question:

Since collections are much more dynamic than products, and they keep changing, it is foreseeable that products will become part of more and more collections as time goes by. Is this handled well by this solution? In particular, can products belong to more than one collection (this is a very realistic scenario: think of "all ASAR products" and "all ASAR products over Europe")? How is this handled in SAFE and was it addressed in HMA?

Thanks,

Paulo

GMV S.A.U.

Apparently this was not explicitly addressed in HMA. The way HMA links a product with the collection is via the parentIdentifier, whose cardinality is 0 to 1, so it does not allow for multiple collections unless some type is redefined. In the proposed SAFE structure it is feasible via the redefinition of the EOP type “EarthObservationMetadataType” to increase the cardinality of the parentIdentifier. The space for the EOP redefined types was already foreseen in our approach, so there is no change in the structure.

For the redefinition there are some options:
- First, removal of “parentIdentifier” by restriction, and after, addition of same “parentIdentifier” element with unbounded cardinality
- Extend “EarthObservationMetadataType“ with a different element “otherParentIdentifiers” with unbounded cardinality

Below there is a preliminary guess about the first option for the redefinition:

Current definition in EOP: eop.xsd
…
<xs:complexType name="eop:EarthObservationMetadataType">
<xs:sequence>
  …
   <element name="parentIdentifier" type="string" minOccurs="0">
    <annotation>
      <documentation>Collection Identifier.
        </documentation>
    </annotation>
   </element>
  …
</xs:sequence>
</xs:complexType>
…

Step 1) redefinition in SAFE (removes the current parentIdentifier): eop-safe1.xsd
…
<xs:redefine schemaLocation=”eop.xsd”>
…
  <xs:complexType name="EarthObservationSAFEMetadataType">
   <xs:complexContent>
    <xs:restriction base="eop:EarthObservationSAFEMetadataType">
     <xs:sequence>
      … All elements except for parentIdentifier
     </xs:sequence>
    </xs:restriction>
   </xs:complexContent>
  </xs:complexType>
…
</xs:redefine>
…

Step 2) redefinition in SAFE (adds a new parentIdentifier with the right cardinality): eop-safe.xsd

…
<xs:redefine schemaLocation=”eop-safe1.xsd”>
…
  <xs:complexType name="EarthObservationSAFEMetadataType">
   <xs:complexContent>
    <xs:extension base="eop:EarthObservationSAFEMetadataType">
     <xs:sequence>
      <element name="parentIdentifier" type="string" minOccurs="0" maxOccurs="unbounded">
       <annotation>
        <documentation>Collection Identifier.
        </documentation>
       </annotation>
      </element>
     </xs:sequence>
    </xs:extension>
   </xs:complexContent>
  </xs:complexType>
…
</xs:redefine>
…

Result) A valid portion of the XML instance would be as follows (replacing … by the right namespaces):

…
<...:metaDataProperty>
<...:EarthObservationMetaData>
  <...:identifier>DS_PHR1A_20010822110247_TLS_PX_E123N45_0101_01234</...:identifier>
   <...:parentIdentifier>COLL_ID_1</...:parentIdentifier>
   <...:parentIdentifier>COLL_ID_2</...:parentIdentifier>
   <...:parentIdentifier>COLL_ID_3</...:parentIdentifier>
   <…:acquisitionType>NOMINAL</...:acquisitionType>
   <...:productType>TBD</...:productType>
   <...:status>ARCHIVED</...:status>
   <...:downlinkedTo>
    <...:DownlinkInformation>
     <...:acquisitionStation codeSpace="urn:...:PHR:stationCode">TLS</...:acquisitionStation>
    </...:DownlinkInformation>
   </...:downlinkedTo>
   <...:archivedIn>
    <...:ArchivingInformation>
     <...:archivingCenter codeSpace="urn:...:PHR:stationCode">TLS</...:archivingCenter>
     <...:archivingDate>2001-08-22T11:02:47.999</...:archivingDate>
    </...:ArchivingInformation>
   </...:archivedIn>
   <...:processing>
    <...:ProcessingInformation/>
   </...:processing>
  </...:EarthObservationMetaData>
</...:metaDataProperty>
…

Regards,

Héctor.

Maybe we need to be pragmatic about this and limit the values of parentIdentifiers to valid product types and not use them for "collections" from the user point of view. Since SAFE is primarily an archive format (not dissemination), it is not desirable that the content of this field changes in time, that you can associate one product to more than one collection and that products go in and out of collections.

This would avoid any of the proposed changes.

Paulo

GMV S.A.U.

If limiting the values of the parentIdentifier is not a problem, I prefer this approach as well.
We would apply the limitation for the list of product types known at the time of the specification. In this case, things as "all ASAR products over Europe" wouldn't be allowed.

Héctor.

Bernhard Buckl

In the olde days of CEOS CIP we differentiated between Archive Collections and Thematic Collections where e.g. a restriction over Europe would be thematic if the product type itself is not restricted to Europe, but e.g. a Level 3 European Vegetation Index Collection could be an Archive Collection if only data over Europe are used for that product type.
So Thematic Collections build over Archive Collections and form a hierarchical graph structure with Thematic Collections as internal nodes and Archive Collections as leaf nodes.
I think in LTDP we deal with Archive Collections of which a Product should only have one parent. Archive Collections could have more than one Thematic parent but in this case it is not HMA metadata but ISO 19115/11939 which should have the 0..n multiplicity for the parent element.

In Collection metadata the region or temporal coverage or Geophysical Field could be encoded as spatial/temporal/keyword metadata. You would then search for "all ASAR Collections which contain at least products over Europe". Having identified the respective Collections a qualified Product search then identifies the wanted subset of the Archive Collections, in our example all products over Europe maybe from different Archive Collections.

I also share the conclusion of the study trade-off.

Regards,
Bernhard

Bernhard Buckl

I just checked back and saw that in ISO 19115/19139 the parentIdentifier also has multiplicity 0..1. Also in ISO metadata Archive Collections cannot have multiple parents. So indeed a field redefinition for SAFE Collection metadata seems to be appropriate, assuming that an ISO element multiplicity is carved in stone.

Bernhard

After reconsideration, see also my post in the Simplification Trad-off thread, I think that for archive collections the multiplicity of the parentIdentifier element should remain 0..1.

Bernhard

I agree on limiting the parentIdentifier to the product type.
However a restriction of the field to the known product types at the moment of the specification would create a lot of problem for the future. It would be better to specify in the Control Book 1 that the parentIdentifier has to match the product type without applying a restriction at core schema level. Such restriction can be applied at product type level as performed currently for SAFE 1.3

Forum: LTDP SAFE

EO Collection and EO Product metadata separation

Re: EO Collection and EO Product metadata separation

Re: EO Collection and EO Product metadata separation

Re: Re: EO Collection and EO Product metadata separation

Re: Re: Re: EO Collection and EO Product metadata separation

Re: Re: Re: Re: EO Collection and EO Product metadata separation

Re: Re: Re: Re: Re: EO Collection and EO Product metadata separation

Re: Re: Re: Re: Re: Re: EO Collection and EO Product metadata separation

Re: EO Collection and EO Product metadata separation

Re: EO Collection and EO Product metadata separation