Project

General

Profile

Task #8829

MNDeployment #3238: Idaho Northwest Knowledge Network member node

get DKAN connected to GMN

Added by Amy Forrester over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
High
Assignee:
Target version:
-
Start date:
2019-07-23
Due date:
% Done:

0%

Story Points:

Description

Matt J talked to Carrie -- They recently installed DKAN, and are now having trouble programatically uploading to GMN as Ed had been doing. She was interested in MetacatUI and that there could be a web-based form for uploading content. NKN was unaware that this might be possible with GMN and Metacat. She had lots of good comments about our new service models too. We should definitely follow up.

At a minimum we need to help them get DKAN connected to GMN, as none of their new content is making it into GMN.

History

#1 Updated by Amy Forrester over 2 years ago

  • Assignee deleted (Jing Tao)

#2 Updated by Amy Forrester over 2 years ago

Meeting scheduled - 7/23/19 carrie roever;james o'dell
dave.vieglais;john evans; roger.dahl; amy Forrester

epad Notes

#3 Updated by Amy Forrester over 2 years ago

  • Assignee set to John Evans

#4 Updated by John Evans over 2 years ago

There are no landing pages, so all the information must be taken from the metadata documents.

All metadata documents appear to be found at https://www.northwestknowledge.net/data/*/metadata.xml

There are 162 directories, but 20 do not have metadata.xml files. Those that do have metadata.xml exhibit an issue that may be on our end. The metadata xml files validate from within the slendernode client, but they do not validate when sent to the test gmn. My test gmn may be a few revs behind, I will look into that.

The issue seems to be that the lead element is "gmd:MI_Metadata" instead of "gmd:MD_Metadata". That should be ok, I think. If I change this on the fly, then 17 documents do validate but 98 fail.

There are no DOIs in the metadata documents. For the moment, I am substituting the gmd:fileIdentifier. But 34 of the 98 failures are due to the metadata document not having such an element. It appears that in each of these cases, the dataset is a series, see https://www.northwestknowledge.net/data/7bf46cda-403a-4a73-b591-efa5dabcdb72/ as an example. These documents do validate according to our own tools.

Again with the identifier, most of the gmd:fileIdentifier items are UUIDs, but not all of them.

There are at least 26 documents where a gmd:URL element is not a proper URI.

At least 11 documents (https://www.northwestknowledge.net/data/d986d1f3-89c1-4c76-9946-eb750f3e921a/metadata.xml) are invalid due to improper use of gmx:Anchor.

#5 Updated by John Evans over 2 years ago

It looks like the MI_Metadata-vs-MD_Metadata was a case of the gmn software on the server side being too far behind. After creating a new instance with updated versions of the gmn software, these documents harvested ok.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)