Skip to content
This repository has been archived by the owner on Oct 15, 2021. It is now read-only.

enforce agreement between existing terms and labels where ever applicable #4

Open
jmcmurry opened this issue Feb 3, 2017 · 4 comments

Comments

@jmcmurry
Copy link
Contributor

jmcmurry commented Feb 3, 2017

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
Copy link
Collaborator

@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:

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

@jmcmurry
Copy link
Contributor Author

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
Copy link
Collaborator

@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
Copy link
Contributor Author

jmcmurry commented Jul 5, 2017

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants