ISO - AircraftID (additional attribute) mapping to actual Aircraft

Another somewhat related question is regarding campaigns.  Some datasets, particularly for IceBridge, will have multiple campaigns associated with them.  While it's possible that some of these campaigns may use the same airplane/platform with corresponding sensors, it's also possible that a new campaign may use a different airplane (with a different tail number/ID) with the same or different sensors.  How will these be mapped and linked together during ingest, so that the right airplane/aircraftID/sensors are connected?

On behalf of Amanda Early: While I can't speak to ISO directly, the UMM-Common has a Platform/Characteristics field that would allow you to enter an identifier that is directly linked to a specific platform.

I see that section now in the mapping spreadsheet.  I think that place makes sense, and I will get that implemented in the ISO in that spot.  The question then becomes whether we should still be including these ID's as "additional attributes" as shown above?  At this point, I'm guessing no, because the ID's don't really make a lot of sense in that context, as they wouldn't be connected to anything.  However, maybe those attributes are used for searching purposes, in which case it would make sense to have the ID's in both places.

Or, as I look closer, the "eos:AdditionalAttributes" bit in the above may have been referencing this place to begin with, as that's the ISO place that is mapped to "characteristics".

One thing I noticed about this is, while it does seem to work as expected, it gives a warning:

"After translating item to UMM-C the metadata had the following issue: /Platforms/0/Characteristics/0 object has missing required properties (["Unit"])"

In the case of an AircraftID, there really isn't an associated unit.  (In fact, that may be the case for other Characteristics of DataType STRING?)

It's just a "warning" in the response right now.  If there's something that should be put there instead, I can certainly do so.

I added this example into the Platform thread as well.

Emily is correct and below is my ISO example that follows the airborne's group recommendations:

<gmi:platform>
  <eos:EOS_Platform id="Aircraft1">
    <gmi:identifier>
      <gmd:MD_Identifier>
        <gmd:code>
          <!-- The aircraft short name -->
          <gco:CharacterString>B-200</gco:CharacterString>
        </gmd:code>
        <gmd:codeSpace>
          <!-- for all identifiers I am using the codeSpace to let software know what kind of ID this is
               I understand that in this example there is only one identifier, but at the identificationInfo
               level there can be many, so we are using this for all identifiers -->
          <gco:CharacterString>gov.nasa.esdis.umm.platformshortname</gco:CharacterString>
        </gmd:codeSpace>
        <gmd:description>
          <!-- The aircraft long name -->
          <gco:CharacterString>Beechcraft King Air B-200</gco:CharacterString>
        </gmd:description>
      </gmd:MD_Identifier>
    </gmi:identifier>
    <!-- This is UMM Platform Type -->
    <gmi:description>
      <gco:CharacterString>Aircraft</gco:CharacterString>
    </gmi:description>
    <gmi:instrument xlink:href="#Instrument3"/>
    <eos:otherProperty>
      <gco:Record>
        <eos:AdditionalAttributes>
          <eos:AdditionalAttribute>
            <eos:reference>
              <eos:EOS_AdditionalAttributeDescription>
                <eos:type>
                  <eos:EOS_AdditionalAttributeTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/eosCodelists.xml#EOS_AdditionalAttributeTypeCode" codeListValue="platformInformation">platformInformation</eos:EOS_AdditionalAttributeTypeCode>
                </eos:type>
                <eos:name>
                  <gco:CharacterString>Tail Number</gco:CharacterString>
                </eos:name>
                <eos:description>
                  <gco:CharacterString>Aircraft Tail Number</gco:CharacterString>
                </eos:description>
                <eos:dataType>
                  <eos:EOS_AdditionalAttributeDataTypeCode codeList="https://cdn.earthdata.nasa.gov/iso/resources/Codelist/eosCodelists.xml#EOS_AdditionalAttributeDataTypeCode" codeListValue="string">string</eos:EOS_AdditionalAttributeDataTypeCode>
                </eos:dataType>
                <eos:parameterUnitsOfMeasure>
                  <gco:CharacterString>Not Applicable</gco:CharacterString>
                </eos:parameterUnitsOfMeasure>
              </eos:EOS_AdditionalAttributeDescription>
            </eos:reference>
            <eos:value>
              <gco:CharacterString>EER2365876</gco:CharacterString>
            </eos:value>
          </eos:AdditionalAttribute>
        </eos:AdditionalAttributes>
      </gco:Record>
    </eos:otherProperty>
  </eos:EOS_Platform>
</gmi:platform>

By Placing the additional attributes inside the platform the CMR can associate that the tail number is part of the platform.

Your second question about campaigns.  I was talking with Jon Pals last year and while I can't find the ticket I wrote, I wrote another  ECSE-189 to document your question.  In the next set of changes to the UMM, I would like to expand on Campaigns to accommodate airborne data.

Instead of including the aircraft ID in two places, one for searching and the other for associating the tail number with the platform, I wrote a new CMR issue CMR-4058 to include searching on Platform/Characteristics/Value so that the tail number can be searched.  

You can add the following for items that do not have a unit :

                <eos:parameterUnitsOfMeasure>
                  <gco:CharacterString>Not Applicable</gco:CharacterString>
                </eos:parameterUnitsOfMeasure>

Thanks!  I think my bit about campaigns, too, was partly from a misunderstanding on my part as to where this additional characteristic should go; I was putting it in the wrong place, rather than with the platform itself.  But it's good to know that the Platform Characteristics will be searchable to avoid having it put in two places

Erich, just to follow up on a couple things with the AircraftID bit:

We've been using the attribute name "AircraftID", whereas you have "Tail Number" above.  Theoretically we could change, but talking with Cathy it sounds like the Descriptor Maker expects the attribute to be called "AircraftID". Was the "Tail Number" bit above just an example, or does it need to be that exact term for something on the ingest side?

Similarly, with the description of the attribute, the example above just says "Aircraft Tail Number", where the description we were going to use was "The identifier of the airplane used by the FAA to uniquely identify each aircraft".  Does it matter which is in that field?  I just want to make sure that it doesn't break ingest or anything.

The Descriptor Maker will look for Additional Attributes in the UMM-C representation of the collection metadata and add them to the SDPS Descriptor file.

The AircraftID shows up in the UMM-C as a Platform Characteristic and so it is ignored by the Descriptor Maker.

If you want the granule metadata to contain the AircraftID (or TailNumber), then it should be in the Additional Attributes section of the UMM-C or we need to figure out a way to tag Platform characteristics that are additional attributes to separate them from platform characteristics that are not additional attributes.