portal dataset passthrough editor

[mbjones]

Describe the feature you'd like A common use case is for a portal “passthrough” capability — where a portal for e.g., a lab exposes the MetacatUI editor for Members of that portal to create new datasets and edit existing ones. This is an advertised feature of our current promotional docs and flyers, but we haven't yet fleshed it out for implementation. The editor would then set defaults for new datasets for that portal, including:

• default control directives such as group write access
• default keywords/vocabulary/annotations for associating the dataset with the portal
• common grant numbers that might be selected for all or most datasets in the collection
• common controlled vocabularies to be used for things like taxonomy
• common site list to select one or many study locations that autofills bounding boxes and geographic descriptions

Is your feature request related to a problem? Please describe. The problem is mainly associated with inefficiencies in the current process. Enabling this feature would make it easy for groups to remain consistent and standardized, and streamline metadata input for them.

Additional context Prior mockups from much earlier versions of MetacatUI proposed some ways to have group-specific controlled metadata snippets that could be saved and reused. These should be in the nceas-design repo.

The "passthrough editor" would work differently when it is deployed on member repositories versus the DataONE coordinating node. On member nodes, the edited entries would be submitted to that same node (e.g., a portal on the Arctic Data Center would be submitted to the Arctic Data Center). On DataONE, a portal that spans repositories would have a dropdown list in the editor for selecting which repository (from a limited list) the dataset should be sent to. That list of candidates would be configurable for each portal, and allow the default to be specified (which might be a single repo if the portal so chooses). This would likely be used by hosted repositories that want to send data to their hosted repo, but that wants a portal spanning datasets from multiple repositories.

[mbjones]

This issue is probably a duplicate of #1070, but there are relevant details in each. The tickets should likely be consolidated.

[robyngit]

From #1070, @mbjones said:

At DataONE, a strong use case emerged for DataONE-deployed portals to be able to be configured to include a MetacatUI-based data submission and editing form. The concept is to provide a place for data submissions from DataONE portals that get passed through to one of the member repositories in DataONE such as KNB or ADC or others. This is dependent upon 1) the target repo supporting the Tier 3 API, and also supporting the type of content to be submitted (EML metadata and data types initially).

We can see two deployment scenarios:

• deploy portal that gives the user a dropdown list of submission targets
• deploy portal that is tied directly to one backend repository (e.g., KNB)

Both of these give a targeted user community a way to submit to a particular repository. They also provide an opportunity for the submission form to be customized for the particular portal, which should include features like:

• ability to set default metadata fields through a "template" metadata document
• ability to constrain choices in specific metadata fields to a specific controlled vocabulary
  • example 1: choose from a pre-configured site list for geographic descriptions
  • example 2: add an annotation field to tie a dataset to a controlled vocab of sampling locations
  • example 3: add one or more controlled keywords from a specific vocabulary either to the keyword set or an annotation field

Let's discuss approaches and details and figure out how this fits into the implementation plans.

[mbjones]

Smithsonian just voiced a request for this portal-based editor specialization feature for their hosted repository. They would like to be able to:

• associate a dataset with a portal when it is created
• based on the portal chosen, assign different access control groups for curation

They basically would like to use it to allow portals to be the main vehicle for data curation at their sub-unit levels, rather thsan repository-wide.