Option to annotate models with a curation state

[hdietze]

The goal is to provide more fine grained control for the state of a model (other than deprecated). A biocurator should be able to designate state of the annotations in a model.

This will be implemented as model annotations with a new AnnotationProperty (IRI) and different literal strings for indicating the state. The cardinality for the annotation is 0..1 (Which means: before setting a new value, the existing annotation has to be deleted)

TBD: values of the field

One idea could be by default it assumes the model is work-in progress and released could be added once the model is deemed to be done by the curator. Amigo (and the translation to GPAD/GAF) should only load the models marked as released.

We also use noctua models as examples for c16 relations, these could be annotated with a different value, maybe?

@cmungall to determine the IRI

[kltm]

How about:

• production - considered Good, always exported
• review - between production and development, may still be exported in data, but has possibly been flagged (in a manual or automated process) or is just setting out from development for the first time
• development - the model is a work in progress, would only be exported in development environments; the standard initial state
• deprecated - hidden from most views, never in any exported data

[hdietze]

The deprecation is an orthogonal annotation. It should not be folded into the curation state. Use case: A released/production model is deprecated due to a retracted paper.

[cmungall]

There is something called SPAR https://www.google.com/search?q=publication+status+ontology&ie=utf-8&oe=utf-8 which has a vocab for status of published docs (models are somewhat like docs)

not available as it's on sourceforge! So abandoned..?

@mellybelly @mbrush any suggestions for standard vocab for the status of a model in noctua?

[kltm]

Okay, we didn't get much out of looking at the other resources. How about:

• production - considered Good, always exported
• review - between production and development, may still be exported in data, but has possibly been flagged (in a manual or automated process) or is just setting out from development for the first time
• development - the model is a work in progress, would only be exported in development environments; the standard initial state (public)
• closed - editable, but never exported

Orthogonal:

• deprecated - hidden from most views, never in any exported data

Also, I'm starting to think about whether it might be a good idea to look per-model group type permissions and how they might be implemented. Is this a use case we really need to worry about in the long run, or can we merrily go along with the (easy) per-server model of permissions?

[kltm]

@hdietze has added label mapping for this, so we will access it under "model-state".

[kltm]

@kltm has chosen the default annotation to be "development", to be added at model creation. No complaints from the crowd.

[mbrush]

May be late in the game, but there are a couple of active ontologies we use that deal with artifact status. The SIO has a small hierarchy of status classes under SIO_001033 'text quality' - just a few classes such as 'draft', 'reviewed', 'finalized'. And the IAO has a 'curation status specification' class with instances for describing to the status of ontology terms. These are similar in spirit to what we might want for describing the status of models. Examples include 'uncurated', 'pending final vetting', and 'ready for release'.

So, neither of these have exactly what we want, but represent places where it might be appropriate to implement what we want so it is more visible and re-usable.

[cmungall]

Thanks for the suggestion. So under 'written' You mean http://semanticscience.org/resource/SIO_001039.rdf

I see some subclasses. But I think 'written' is not the right semantics for us. We'll roll our own and then we can have some kind of weak skos-like link connecting these

[mbrush]

Yes, I agree - neither SIO or IAO has the correct semantics for what we need in their existing classes. But given that these are active and relatively widely used ontologies, it might be worth implementing our desired terms in one of these places so they can be re-used by others.

[kltm]

We're going to go ahead with an open field to begin with, and circle back later if things change.