10749
Reporter: trobertson
Type: NewFeature
Summary: Implement the "register me" pages in the portal
Priority: Major
Resolution: WontFix
Status: Closed
Created: 2012-02-02 16:07:45.735
Updated: 2016-09-05 13:35:36.926
Resolved: 2016-09-05 13:35:36.895
Description: Wireframes exist for the register me, but need to be implemented such that they are operational, and manipulate the registry.
Requires some thought and design of how this will operate for each protocol (including triggering endorsement procedures).
]]>
Author: ahahn@gbif.org
Comment: Presently, the registerme pages are linked in from the "About" section in the "More" area of the main menu, bottom of the text block on the page ("Share your data on GBIF" link, http://portal-static.gbif.org/static/about.html). It needs to be lifted to a more visible level for now (e.g. footer section, add line under "Join the Community" reading "Share your data"), but will ultimately need coordination with communication portal development.
Created: 2012-02-07 11:09:28.987
Updated: 2012-02-07 11:09:28.987
Author: mdoering@gbif.org
Created: 2012-02-07 11:24:04.507
Updated: 2012-02-07 11:24:04.507
ok, change applied in revision 474.
The link to share your data should probably ultimately also go into the homepage? If so we could add such a link temporarily until visuality has designed it to not forget about it...
Author: ahahn@gbif.org
Created: 2012-02-08 16:57:04.848
Updated: 2012-02-08 16:57:04.848
general workflow (to be detailed in tasks; including tasks relevant for registry as well as portal)
Portal side (-> issues under POR):
basic decision: in order to publish a dataset through GBIF, the submitter needs to be registered and logged in to their GBIF (data portal) account (name, email, possibly institutional affiliation), so that a communication channel is ensured.
- entry to "registerme" area (http://staging.gbif.org:8080/portal-web-dynamic/dataset/register-step-1) giving brief introduction and providing relevant links to further information / tools etc.; sketch of what to expect on registration (accepted only after confirmation by data publisher; indexing, rollover -> public database version); prominent "my access point already exists" link to proceed to registration step
- "registerme" page (http://staging.gbif.org:8080/portal-web-dynamic/dataset/register-step-2):
-- allow for entry of access point URL, selection of publisher name (branch: suggest new publisher and specify Participant Node for endorsement - naming publisher name as well as contact name and email obligatory; do in a way to encourage proper checking of existing entries before creation of a new one), select relevant protocol; in this step, multiple services may be registered, but selecting the same service type a second time should not be allowed
-- perform some tests: duplicate avoidance (is the same URL already registered?), functional access point (connect possible?); valid access point (protocol conform?); feedback on issues detected; functions: publisher support, spam control
-- (possible future improvement, but parked for the time being): run test on data content, provide feedback on issues spotted that need to be fixed before indexing will be possible (missing data, invalid characters, messages from database,...; alternatively, provide links to checking tools)
-- retrieve metadata from access point and display for feedback (branch: if retrieving the metadata takes too long, e.g. extraction from a large data archive, inform user, then provide asynchronous feedback by email and allow submitter to proceed from there)
-- (possible future improvement, but parked for the time being): provide the feedback on extracted metadata in form; metadata-schema-provided fields locked, others allow manual edits for submission (protocol-specific locks required). Open question: how will future updates on such fields work (editing rights in registry), and how to ensure that future automatic enrichment does not generate conflicts?
-- explicit submit through user. Prominent information that doing this means agreeing to the GBIF Data Sharing Agreement.
- "thank you" page (http://staging.gbif.org:8080/portal-web-dynamic/dataset/register-step-3):
-- basic feedback on name of dataset and publisher registered under
-- reminder that an approval procedure is to follow before the access point will be handled in indexing
Registry side (-> issues under REG):
- on submission of a new data resource access point, a dataset entry/dataset entries is/are generated in the registry (insert), but flagged as provisional and not connected to a publisher entry
- if an existing publisher was selected, the publisher contacts get notified of the dataset, and approval is requested to add this dataset to the list of their contribution (accept / deny / request more information)
- if a new publisher entry was suggested, make sure that manual registration and endorsement procedure (Participant Node) are initiated (notify registry admins; feedback to submitter that endorsement procedure has been initiated, but may take some time); once this is concluded, follow up with publisher notification as above
- on publisher accept: connect dataset entry to publisher entry (how to persist information of the connection in between?); notify submitter of accept, notify Participant Node of new dataset under their domain
- on publisher deny: delete dataset from registry, notify submitter of refusal
- on publisher request more information: initiate direct email link between publisher and submitter to resolve potential issues
- in parallel: provide administrative pages to maintain overview of pending processes (-> POR); workflow on irresponsive contacts needs to be detailed (automatic delete after x time? escalation to helpdesk case? other?)
- notes field for registry entries: allow manual additions with user id / timestamp, allow automatic additions on system actions (merge, metadata override etc). List or simple text field append?
- notifications: at various levels, messaging needs to supply the mechanism for notifications, and listeners need to be set up depending on the purpose (dataset approval request/response, endorsement request/response, status update for submitter (acceptance, refusal, detected issues), information of Participant Node, etc)
