providedBy field missing from some models (first occurrence 2018-07-10)

[lpalbou]

I was looking at the snapshots of production models, before the upcoming release on August for rdf.geneontology.org and I noticed a few models without providedBy.

Normally, this type of query should work on any model and display the providedBy:

PREFIX metago: <http://model.geneontology.org/>
PREFIX providedBy: <http://purl.org/pav/providedBy>
  
SELECT  *
{  	    
  GRAPH metago:5b528b1100000331 {  	
    ?gocam providedBy: ?providedBy .			 
  }
}          

But there is none for this one and none for the following models:

• gomodel:5b528b1100000331
• gomodel:5b528b1100000251
• gomodel:5b528b1100000023
• gomodel:5b528b1100000000
• gomodel:5b318d0900000906
• gomodel:5b318d0900000182
• gomodel:5b318d0900000355

[kltm]

Affected models:
http://noctua.berkeleybop.org/editor/graph/gomodel:5b318d0900000355
http://noctua.berkeleybop.org/editor/graph/gomodel:5b318d0900000182
http://noctua.berkeleybop.org/editor/graph/gomodel:5b318d0900000906
http://noctua.berkeleybop.org/editor/graph/gomodel:5b528b1100000000
http://noctua.berkeleybop.org/editor/graph/gomodel:5b528b1100000023
http://noctua.berkeleybop.org/editor/graph/gomodel:5b528b1100000251
http://noctua.berkeleybop.org/editor/graph/gomodel:5b528b1100000331

Note that after we figure out what is going on, we may have to re-apply #458 / geneontology/noctua-models#84

[kltm]

Also note eerily similar to something that might be caused by #569 , although the times do not quite align (so far).

[kltm]

Good dates:

• 2018-07-17
• 2018-07-19
• 2018-08-06

Bad dates:

• 2018-07-31 (sabrina, gomodel:5b528b1100000331, gomodel:5b528b1100000251)
• 2018-07-24 (sabrina, gomodel:5b528b1100000023)
• 2018-07-23 (sabrina, gomodel:5b528b1100000000)
• 2018-07-19 (knc, gomodel:5b318d0900000906)
• 2018-07-19 (knc, gomodel:5b318d0900000906)
• 2018-07-12 (harold, gomodel:5b318d0900000182)
• 2018-07-11 (sabrina, gomodel:5b318d0900000355)
• 2018-07-10 (harold, gomodel:5b318d0900000182)

Given that, it does not seem to be systematic (timewise). I think maybe looking at tools might be the next step.

[kltm]

Isolating gomodel:5b528b1100000023 activity on 2018-07-24.

grep "5b528b1100000023" /tmp/minerva.log | grep "2018-07-24" | grep -v "export-legacy" | grep -v "intention=query" | grep -v "workbench/annpreview" | grep -v '"operation":"get"' | grep "provided-by" | wc
      0       0       0

vs more general

cat /tmp/minerva.log | grep "2018-07-2" | grep -v "export-legacy" | grep -v "intention=query" | grep -v "workbench/annpreview" | grep -v '"operation":"get"' | grep "provided-by" | wc
    137     959  139841

So, a "tool" and not a minerva problem--there is no group info coming in.
Okay, that leaves us with either the clients or barista failing at translation.

[kltm]

The barista logs are spotty here (an issue unto itself) and will be uninformative.
Okay, let's try and extract as much as we can from one model on one day:

grep "5b528b1100000023" /tmp/minerva.log | grep "2018-07-24" | grep -v "export-legacy" | grep -v "intention=query" | grep -v "workbench/annpreview" | grep -v '"operation":"get"' | grep "intention=action" | grep "operation%22%3A%22add"

Gives:
https://gist.github.com/kltm/103704ac2fdb631d83ef2014cd917059
These are very big ops sets; my intuition says that these would be very hard to generate in the graph editor, which would leave us with barista doing something squirrely or SAE.

[kltm]

Feedback from one of the model creators. It looks like it may have been a mixed-tool workflow, originating in the form.
I have a couple of ideas; will try and simulate.
As well, double check gist/logs to see if/when relations were added after the fact (and confirm workflow with log).

[kltm]

Okay, I don't think I'll be able to get a definitive answer for what happened in this case. My current guess is an unknown failing in barista.
I'm going to close this out but spawn two issues: fix the models that managed to get by and get a strict mode in barista so that it will not attempt sensitive ops without a group.