Forums

>> a) If an sboTerm attribute is present on a KineticLaw
>> object, the 'math' field must also contain a formula.
>> A model containing an sboTerm on a KineticLaw lacking a
>> math field would be deemed invalid.

bshapiro> Why? (taking a "devil's advocate" position: the
bshapiro> information is completely redundant so why
bshapiro> bother? If my tool can read/write the ontology
bshapiro> why do I need to make my file work for people
bshapiro> who can't read the SBO?

It's because the SBO information is only an optional
annotation, and tools would not be required to use it.

Looking at it another way: if we want the Math to remain
authoritative, then we can't allow an either/or situation
with sboTerm. Logically, if you don't allow sboTerms alone,
then you have no choice, I think: you have to stipulate that
the always has to be present.


bshapiro> same concern. Also: will an SBO entry ever
bshapiro> change? or once its there is it fixed for life?

The way that these ontologies/CVs work is that terms are
never removed. If a term is obsoleted, it's still left in
and the CV has pointers to replacements. So there's no
danger of ending up with a dangling reference.


bshapiro> This and the following puts a certain about of
bshapiro> constraint on the SBO maintainers: they have to
bshapiro> create and maintain a minimal set of
bshapiro> functionality so that a program can make a call
bshapiro> to the ontology (e.g., via some sort of set of
bshapiro> single line commands such as
bshapiro>
bshapiro> "http://something.com/something.php?somthing="myquery"
bshapiro>
bshapiro> that return things like kinetic laws, etc.
bshapiro>
bshapiro> The set of commands is defined by the SBO
bshapiro> designers and not by SBML.

Yes, agreed. I think this is technically doable.


bshapiro> I am not convinced that requiring consistency
bshapiro> checking of any type should be required for an
bshapiro> SBML-compatible reader. Shouldn't a tool that
bshapiro> can read any file that is assumed to be correct
bshapiro> SBML be considered SBML (read) compliant?

Yeah, I guess that's true. I mean the consistency checking
to be in the sense of "it's generally a good idea" and not
"it's critical to do this".


bshapiro> Also suggest: If a tool does not understand SBO
bshapiro> terms it should be able to ignore them
bshapiro> completely, i.e., not required to write any of
bshapiro> the SBO terms back out. I would suggest the
bshapiro> following:

That sounds reasonable.

The sboterm handling stipulations for non-sboterm-aware
tools could be made stronger: we could say that unless a
tool understands sboterms, then if it makes any changes to a
model (except in notes and annotations), it should strip out
all the sboterms. This would be even safer, at the cost of
even greater loss of information, and possibly also more
work on the programmer's part.

MH