Open goodb opened 4 years ago
The BL:category annotation should match a predefined shape. e.g. anything tagged bl:category [GoMolecularFunction:] must match the shape and must not match anything else.
How does this interact with "inheritance"/shape intersection? The following definitions imply to me that a node matching the <Complex>
shape will have two values for bl:category
: GoComplex:
and GoMolecularEntity:
. Is that a problem for this principle?
<Complex> @<MolecularEntity> {
bl:category [GoComplex:] ;
}// rdfs:comment "a protein complex"
<MolecularEntity> EXTRA bl:category {
bl:category [GoMolecularEntity:] ;
}// rdfs:comment "a molecular entity (a gene product, chemical, or complex typically)"
I think it is, but its something we could implement around if we needed to. Basically, do we allow multiple BL categories for individual nodes or not? I feel like we probably do not want to recreate hierarchies with category tags. So here we should either make
I think explanations will be massively important in the long run but we have some time to defer on this as we can make do with geeky explanations in the short term while the modeling group iterates over some of the basics.
I do think we will need to refer to complexes in the schema, for example to state the expected has-part structure
@cmungall they key thing is to get the computation of the multi-node, model-level validity in place. Once that is done, the explanations, geeky or otherwise, will fall out easily.
When we apply the shapes to a go_cam model, we need to formalize what the code should be providing in response. The shex libraries provide a mapping of the RDF nodes in the model to the labels of the shapes in the provided schema. This alone seems insufficient for users. I'm thinking of a response that would require some additional logic, something that contained additional elements like:
On computing model-level validity, I'm thinking something like: For each named individual in the model: