In adding the AircraftID characteristic, I noticed that there may be some discrepancy between what the DIF-UMM_ECHO Mapping.xlsx file says (v1.9) and how the ingest is actually happening.
Looking at rows 489-492 in particular:
- The "gmd:description" tag under the main EOS_Platform tag shows in the Spreadsheet to have it's Character String value "= Type:" (not really sure what this is)
- The Short Name should be in a "gmi:identifier/gmd:MD_Identifier" tag, with the "gmd:code" being the short name value, and the Description being text that simply says "Platform Short Name", and a "gmd:codeSpace" tag along with it (wasn't clear on how that should be used)
- The Long Name is similar to the Short Name above, except the Description says "Platform Long Name" (and a corresponding value for gmd:codeSpace)
However, in practice, it doesn't seem like it actually ingests that way. For one thing, it seems to be invalid to have multiple "gmi:identifier" tags. In the ingest ISO that we are currently sending, it looks like this:
<gmi:platform>
<eos:EOS_Platform id="PLATFORM_IDENTIFIER">
<gmi:identifier>
<gmd:MD_Identifier>
<gmd:code>
<gco:CharacterString>PLATFORM_SHORT_NAME</gco:CharacterString>
</gmd:code>
<gmd:description>
<gco:CharacterString>PLATFORM_LONG_NAME</gco:CharacterString>
</gmd:description>
</gmd:MD_Identifier>
</gmi:identifier>
<gmi:description>
<gco:CharacterString>PLATFORM_DESCRIPTION</gco:CharacterString>
</gmi:description>
<gmi:instrument xlink:href="#INSTRUMENT_ID"/>
</eos:EOS_Platform>
</gmi:platform>
Essentially, the Short Name is in the "gmd:code" part of the identifier, but the Long Name is the "description" of the identifier (and not a separate identifier). The description of the platform itself is not "Type:" but rather seems to actually be the description of the platform.
My guess is the spreadsheet is incorrect in this case, and that the way we are writing the ISO is indeed the correct way to specify short name, long name, etc. (After ingesting, when we look at the UMM, for instance, the fields seem to be populated based on the values above).
A related note, too, is that if the value of PLATFORM_DESCRIPTION is longer than 80 characters, it throws a warning message about it. While this may be a necessary restriction for something on the back-end, it's not really clear from the spreadsheet, and many of our platform descriptions may be longer than 80 characters. We could truncate, but it would make these descriptions somewhat less useful.
Mostly need clarification as to the "proper" way to ingest platforms.
3 Comments
Lauren Frederick
Scott Lewis
Erich Reiter is the best to answer these questions, but he is out until tomorrow. We have tickets in the next sprint to update our code to match the spreadsheet, so what you are saying is correct. Right now it is slightly off. From what I can see, what you are doing is correct.
As for the platform description length, Erich will have to speak to that and if that is something we would want to increase.
Erich Reiter
I have updated the spreadsheet I think early last week, because I also noticed that only one identifier was allowed in the platform. Download it again to see the latest updates. I had the same issue for instrument, instrument composedOf (old sensor), and project.
Other issues:
PLATFORM_DESCRIPTION - since ISO platform/description is mapped to UMM Platform/Type the CMR will expect the controlled vocabulary as defined in number 1) above. If it is desired to have a platform description, we will need to add prefixes to this element so that it can hold both the platform type and the description. If we allow both values then we would have to allow many more characters than 80 for this element. To follow Ted's examples the description would look like the following:
Here is my ISO example for an aircraft platform where the description just contains the UMM Platform/Type value:
Here is how is it translated into UMM:
Scott Lewis
Thanks, this makes a lot of sense, and I think it will allow us to go forward.