Closed vanaukenk closed 2 years ago
Note: still need to determine the desired structure and text of comments for 'internal test' models.
@balhoff Would you agree that Minerva does not seem to have any controls on what is used for the "annotation state" for a model?
Added to Noctua project as desired for spec creation, etc.
@vanaukenk How would you feel about just "internal", as I suspect that this tag will be used for more than tests in the future? If you feel the phrasing "internal_test" is important, I'd suggest "internal_test" as the official label given what I saw of the shortening/expansion.
@kltm - I'm agnostic on exactly what we call the state, so long as there is a straightforward way to retrieve test model ttls for the shex, or any other, testing.
If we prefer to tag shex test models with a comment, that's okay, we just need input on exactly what text to put as the comment.
@vanaukenk My understanding from the call this morning was that the current preferred approach was 1) a single new state tag and 2) TBD structured text in the model-level rdfs:comment
list. Does this sound correct to you?
@kltm - how about we stick with 'internal test' for now and for model-level comments, we suggest the following structure:
PASS or FAIL 'some meaningful text'
For example:
FAIL multiple-occurs-in
Comments would be added to the model in the 'Edit Annotations' window.
Would you agree that Minerva does not seem to have any controls on what is used for the "annotation state" for a model?
@kltm I think this is right.
@balhoff Thank you--just a client change then (for now, we'll eventually want minerva having an opinion about these).
@vanaukenk Okay, I'll use "internal-test" then as the internal "label" to avoid the space, if you have no issue. For comment structure, I'd recommend something maybe more like "FAIL:multiple-occurs-in", if you are intending on controlling it or, if you are wanting to be a little more free: "FAIL: whatever you want to talk about here whatevs"--I think generally the combination of the state tag and the "(FAIL|PASS):" should be pretty safe. (Although, ideally, meaningful data should never be stored in comments. @balhoff Would you know of a testing ontology?)
@kltm @balhoff
Ooohhh...a testing ontology. I like that idea.
And I guess this raises the perennial dash vs underscore issue. I tend to prefer underscores, but if there's a reason to choose one over the other, let me know.
So, for comments, the structure would be like this:
FAIL:multiple_occurs_in
Thx.
Just found this: https://www.w3.org/WAI/standards-guidelines/earl/
The Evaluation and Report Language (EARL) is a machine-readable format for expressing test results. The primary motivation for developing EARL is to facilitate the processing of test results, such as those generated by web accessibility evaluation tools, using a vendor-neutral and platform-independent format.
@vanaukenk Druthers all the way down. I'll add "internal_test" as preferred.
Will need https://github.com/geneontology/noctua/pull/609 as currently tracking that on noctua-dev
@kltm - this issue has come up again in the context of discussing Noctua-Protein2GO communication.
More generally, I still think it'd be very helpful to have a new state of 'internal test' or whatever else we want to call it to distinguish those models that are tests and often don't have real data from those models that are truly WIPs and should be marked as 'development'.
Hm.
Looking at noctua-dev, this already seems to be in there at least on dev
? The commit implies that it may in fact be on master
as well? https://github.com/geneontology/noctua/commit/4858a98d0c33d771193a09c0737875dcdc7859e3
I get the feeling this may have been sidetracked by some other factor.
Thanks @kltm
Yes, I see now that it's available on the graph editor but not on the form. Ugh.
@tmushayahama - can we add 'internal_test' to the state options on the Noctua form?
I'm closing this ticket and leaving open the accompanying Noctua form ticket as that's where I believe the remaining work needs to be done.
For creating specific test models for software testing and curator training, we would like to have a new model state 'internal test' to clearly mark these models.