enforce agreement between existing terms and labels where ever applicable

[jmcmurry]

Enforce agreement between existing terms and labels where ever applicable. Change a term it fetches the correct label. Change the label and it fetched the new term, insist on a different label and you are generating/requesting a new term.

[DoctorBud]

@jmcmurry I'm not exactly sure what you mean here, or whether this is still relevant. We need to distinguish between two types of id/label pair:

• iriID/iriLABEL: where the user should be able to override the default label that is constructed from the pattern
• fooID/fooLABEL: where the pair should be bound together and kept in sync. Ideally, this binding would be a single column as you describe in For ID-label pairs for which label is fixed, collapse to one column #2

There is a known problem now where fooLABELcan be customized and the corresponding fooID is not invalidated (working on that bug now).

[jmcmurry]

Here's my latest understanding; I defer to @cmungall for confirmation.

Current need:

• Enforce only iriID/iriLabel (as you describe)

Medium-term need:

• Allow label to be overwritten (warn user) optionally log mismatched data.
  This override feature was one @pnrobinson had mentioned; I don't know how vital it still is.

Eventual need (term request mechanism):

• Allow fooLABELs to be entered (require a validated ID prefix only), but warn user of the mismatch and notify them that all term requests will be processed upon session exit.
• Upon user's exit from session, generate term requests, possibly in some other table-editor capacity or just an email or something.
• If integration is exceptionally tight, we could consider issuing a provisional identifier for the pending term in the annotation. Depends on the workflow.

[DoctorBud]

@jmcmurry There is currently a diversity of opinion about when and where certain types of checks, user feedback and data transformation should occur. Right now, we are favoring a 'dumb' inca-form and a (not yet written) 'smart' backend. A similar issue was discussed here regarding duplicate detection. #32

IMHO, the inca-form should be 'smart' and try to avoid users entering bad data, but we are also trying to avoid maintaining a server to handle this. So if we can't put the code in the browser, we have to either defer it (via Travis/Jenkins), or write a server. Some of our tooling can potentially be adapted to work in the browser (e.g., Scala via ScalaJS), but Python/Java code is useless in the browser.

[jmcmurry]

I'm missing something; why does it need a server? Can't browser just do a check using the existing API calls and check the label on record?