Import xml to feature class doesn't pull UUID

[torrin47]

From @jlholder on May 15, 2017 16:0

I'm upgrading the old metadata in the WAF and pulling it back into the feature classes in the gdb. Usually the WAF has the most updated metadata. When I upgrade those standalone xml files, everything goes smoothly - but when I import them back into the feature class, the UUID doesn't transfer. (Exporting xml from a feature class using EME 3 export maintains the UUID, though. Just an import issue?)

End goal is for the WAF and feature class to have identical copies of metadata (including UUID), but right now have to manually add the UUID back.

Copied from original issue: Innovate-Inc/EMEMetadataToolKit#153

[torrin47]

This is a problem - can you share what tool you used for the import? We might need to provide another custom tool for this process.

[torrin47]

From @jlholder on May 17, 2017 17:19

I've been using the import option on the description page, but per #154, I'm wondering if our older metadata isn't quite in the right format to begin with? Maybe causing a chain of complications...

So my original metadata, stand-alone XML is upgraded, good to go:

Using any of the highlighted versions of the import tools, I get this outcome:

[torrin47]

Finally had a chance to create a tool that I hope will address this issue by purging legacy metadata as part of the import. Would you mind giving it a shot before we compile it into the code?
EMEToolbox.zip

[torrin47]

From @jlholder on June 18, 2017 15:9

Good news - import is working nicely! Bad news - legacy metadata is still there. I used an upgraded standalone xml that still had all of the extra legacy junk. Anything in the original still carried across to the import.

Obviously we still have the legacy content to deal with, but this import works to push upgraded content in, and the EME 4.0 export works to pull the upgraded content out of feature classes. I may toss these tools over to Rebecca and we can make it work for the time being. Here if you need any more testing!

[torrin47]

Thanks, and I'm not sure anything's actually wrong, at least as far as the tool is currently designed, but I see how the in-context help is ambigous. The new tool is only for ensuring a complete replacement of feature class metadata with an imported document. It doesn't also do the upgrade/cleanup - that's the other tool. So the workflow would be to use the Upgrade/Cleanup tool to produce a completely clean standalone doc, and then use this import tool to get it back into the geodatabase. It would be possible to chain the two tools if you think that'd really be a big help to users. But as far as this tool is concerned, the real test is if you have a feature class with legacy content, whether any of that remains after an import of a cleaned up record. Make sense?

[torrin47]

From @jlholder on June 19, 2017 18:17

Yes, makes sense. I'm still having an issue with the new upgrade tool, though - ArcCatalog doesn't recognize that it has successfully upgraded. Then I don't always get the edit option once it's done. (#154) So I still can't use the whole workflow as-is. If the upgrade/clean don't give me a record I can edit, then it's not particularly useful.

[torrin47]

Can you confirm that you're following this workflow?

1. EPA Upgrade to ArcGIS Metadata (or EPA cleanup record) -> outputs standalone upgraded xml doc
2. EPA Import ArcGIS Record -> purges all legacy metadata from feature class and replaces with upgraded/cleaned doc

...and after those steps the metadata associated with the feature class still can't be edited, or still somehow has CSDGM content?

[torrin47]

From @jlholder on June 20, 2017 14:17

Ok, awesome. Workflow is looking good. I'm able to upgrade, cleanup, then import to a feature class. I am seeing that same pattern, that once I edit the new metadata record, then all of the import/export/validate options appear.

Two components in particular - fields and contacts - still don't transfer completely, so I don't know that we want to combine the upgrading/cleaning process just yet. Right now, I still have to go back and make sure to manually transfer the particulars of those pieces. For example, I can choose a contact from the metadata and add it to the resource POCs/Publisher as long as it's still sitting in the legacy content (but it isn't transferring automatically). Then, for fields, I have to go back and find all of the domain info and add it back.

[torrin47]

Contacts doesn't surprise me too much, because there are so many different places a contact could be listed in a CSDGM contact and the meaning of each is a little ambiguous - they lack the role definitions that ISO allows/requires. We tried to place particular emphasis on the contacts that had been identified as mandatory in EME 3.2.1, the others may need to be repopulated. Hopefully that's just a quick selection from a dropdown, not too burdensome.

The attribute transfer is more worrisome because technically, ArcGIS Metadata's support for entity/attribute documentation is 100% CSDGM. ISO spun entity/attribute information off into a completely separate standard, ISO-19110 Feature Catalog, and until recently it wasn't possible to even include entity/attribute information in an ISO-19115 metadata record. It is now possible, but Esri hasn't gotten around to implementing the latest flavor of ISO (19115-1/19115-3), so anything you see in ArcGIS Metadata hasn't been transformed at all - it's still pure CSDGM, which means there really shouldn't be any loss of fidelity. Do you mind sharing an example doc and at what point in the workflow the attribute domains disappear?

[torrin47]

This was a helpful exchange, and some of the issues still exist in Pro, but don't believe we need to leave this ticket open. Closing.