watchdog: automated registration

Question

watchdog: automated registration

Opened this issue 8 years ago · 10 comments

I think the initial implementation approach should/could be in separate tools, like cf2rdf (specifically for CF), and our most recent one, orr-reg, which currently is for SWEET but could be made more generic. Perhaps after some initial working prototypes, we can decide on how to incorporate or integrate some of the functionality with the ORR.

Answer 1 · 2017-02-17T04:07:32.000Z

I still think this is a significant limitation of the system (or to put it more positively, would be a huge plus for the system), and is not terribly difficult to implement in a fully generic way. (If attribute autoupdate is true, download the ontology resource specified by the Original Source (or similar attribute), and if different from existing download (might have to keep and check against a checksum), re-import.

I'm not arguing for implementing it now, just emphasizing how valuable I think it will be.

Answer 2 · 2017-02-17T04:12:15.000Z

Ok, so I just marked it high priority (not sure about deadline, though)

Answer 3 · 2017-02-17T04:13:10.000Z

Yes, no deadline for this, there is no immediate user requirement.

Answer 4 · 2017-02-17T04:40:36.000Z

Closely related: #39

An option to specify a URL (instead of local file) will be incorporated in the first page of the current "Upload" sequence.

When selecting a URL, the user could indicate an number of possible "watchdog" options:

Automated registration of new versions:
- (√) Do not do perform
- ( ) Perform automated processing:
  - ( ) Check for updates every (.. day, week, ...)
  - ( ) Use webhook (an ORR webhook URL will be presented for the user to capture in external service associated with the remote ontology)
When automatically registering a new version:
- Status:
  - (√) Assign current status
  - ( ) Assign the following: ( ) draft ( ) testing ....
- Visibility:
  - (√) Assign current visibility
  - ( ) Assign the following: ( ) owner ( ) public

Answer 5 · 2017-02-17T07:25:05.000Z

I don't see a significant value in the web hook option (well, very nice for CF and maybe SWEET or others, I see how that would be nice -- but not essential if it's hard), and definitely not for the ability to set status on auto-uploads. It is a given that the resource at the named URL is under the control of the ontology provider, so whatever status they give the ontology originally, the rest of them will get the same status.

Answer 6 · 2017-07-27T13:50:13.000Z

Greetings all! ENV:earth_africa: developer here.

Auto-synchronising with ontology releases is very essential. As you probably know, tools like OntoBee and EBI's OLS have good auto-updating approaches which make sure there's no version (and therefore semantic) drift.

We (and other OBO ontologies) are using GitHub tagged releases when we update: https://github.com/EnvironmentOntology/envo/releases

PS: The metadata on ENVO in COR is not correct - can I edit/update this directly? Or perhaps you can harvest the metadata from the OBO Foundry registry, this is available for all OBO ontologies as a JSON-LD, YAML, or RDF/Turtle.

Answer 7 · 2017-07-27T14:36:59.000Z

Thanks Pier.

As discussed yesterday (offline), and given that the automated harvesting is still a TODO, I'm just going to remove this entry from the COR. Then, if you'd like, you can go ahead and exercise uploading ENVO and let us know how it goes. Ah, a related issue entry is mmisw/orr-portal#62

Answer 8 · 2017-07-27T14:42:18.000Z

Unregistration complete.
Please go ahead with the new registration at your convenience. New organization created, http://cor.esipfed.org/ont/#/org/obo , with plbuttigieg as member. Thanks!

Answer 9 · 2017-07-27T15:47:36.000Z

(oops, seems like I clicked the wrong button before -- this is still open)

Answer 10 · 2017-10-04T19:05:36.000Z

Hi @carueda I think the approach you've highlighted in #41 (comment) makes perfect sense.