Re: [SED-ML-discuss] KISAO

[Anna Z. <zhu...@eb...>]

>>         1. classes
>>         a. move deprecated classes into another 'development' ontology document so
>>         they don't show up in the release version
>         These (now deprecated) classes were used in the 1.0 version of
>         KiSAO, so in KiSAO 2.0 we marked them deprecated (instead of
>         removing) in case someone already had references to them. I'd
>         say it's more a problem of an appropriate ontology browser. In
>         OBO-Edit these deprecated (obsolete for OBO) classes are not
>         shown in the main hierarchy tree, but in a special 'Obsolete'
>         branch, which can be folded up. If there is an option to hide
>         deprecated classes in Protege (I've sent them such a feature
>         request
>         <https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=3160&start=0>),
>         then the problem will be solved, won't it?
>
>
>     hmm - i haven't checked, but do the classes appear in the
>     bioportal version too?
>

No, obsolete classes do not appear in the Bioportal.

>>         b. 'isHybridOf' - more generally - 'is variant of'
>         Can you please explain what 'is variant of' will mean?
>         Now I don't see the difference between 'is variant of' and
>         inheritance:  LSODAR and LSODES are variants of Livermore Solver.
>
>
>
>     in strict inheritance, it is the case that the child inherits all
>     attributes of the parent.
>
>     'is variant of' indicates that there is a similarity and
>     difference among the entities that is rooted in one or more
>     attributes.
>
>         The idea of 'isHybridOf' relation was to show that some
>         algorithm is a combination of several other ones: "the whole
>         system is subdivided into appropriate parts and different
>         simulation methods operate on these parts at the same time."
>         Example of hybrid algorithm is Pahle's method (used in
>         COPASI). It combines the stochastic Gibson-Bruck's next
>         reaction method with different algorithms for the numerical
>         integration of ODEs. "The biochemical network is dynamically
>         partitioned into a deterministic and a stochastic subnet
>         depending on the current particle numbers in the system. The
>         stochastic subnet contains reactions involving low numbered
>         species as substrate or product. All the other reactions form
>         the deterministic subnet. The two subnets are then simulated
>         in parallel using the stochastic and deterministic solver,
>         respectively."
>
>
>     right, so 'is hybrid of' considers two things : i) variation in
>     that there is similarity and differences from another entity and
>     ii) causality - that portions of that entity have led to this one.
>     in SIO, this would be a subproperty of 'is variant of' and 'is
>     causally related from'
>

Thanks, I get it.

>>         a. given that you're starting to develop a hierarchy of datatypes, you
>>         should**strongly**  consider converting all of your datatypes into classes
>>         with restrictions on the kind of value that hold e.g. 'relative tolerance'
>>         (using manchester owl syntax)
>>
>>         'relative tolerance'
>>           subClassOf
>>           'quantity'
>>           and 'has value' some decimal
>>           and 'has value' only decimal
>>
>>         If there are other aspects that differentiate a 'relative tolerance' from
>>         'tolerance', then now you can formalize it with other axioms.
>         Just to be sure we talk about the same things: you call them
>         datatypes, but they are not datatypes, but datatype properties
>         (linking individuals to data values).
>
>     yes
>
>         I agree the way of representing parameters which you propose
>         is more flexible if we decide to add axioms describing aspects
>         other than domain (simulation algorithms that uses the
>         parameter)  and range. But it will entail the problem with the
>         OBO version of KiSAO. Now we convert the OWL datatype
>         properties to OBO relations (and keep information about
>         domains and ranges), for example:
>
>         [Typedef]
>         id: KISAO:0000228
>         name: tau-leaping epsilon
>         domain: KISAO:0000039 ! tau-leaping method
>         range: xsd:decimal
>
>         But if we do as you propose: replace datatype properties with
>         owl classes, their domains with axioms containing object
>         property 'is used in', such as:
>
>         'tau-leaping epsilon'
>         subClassOf
>         ('is used in' some 'tau-leaping method')
>
>         and replace ranges with axioms containing datatype property
>         'has value':
>
>         'tau-leaping epsilon'
>           subClassOf
>         ('has value' some xsd:decimal
>           and 'has value' only xsd:decimal)
>
>         then axioms containing 'is used in' object property can be
>         easily converted to OBO:
>
>         relationship: 'is used in' 'tau-leaping method'
>
>         but it's not possible (is it?) to convert axioms containing
>         _datatype_ property 'has value', because there's no OBO term
>         for 'xsd:decimal':
>
>         relationship: KISAO:0000259 xsd:decimal   ! --<-- this is not possible as xsd:decimal is not a term
>
>         while for the range tag not only terms, but also XML-Schema
>         primitives can be used in OBO:
>
>         range: xsd:decimal
>
>         Do you, probably, see a better solution for OBO?
>
>
>     OBO is looking more and more like OWL, but without all the
>     necessary semantics nor analysis required to support the
>     constructs in the language (consider that OBO 1.4 allows one to
>     place restrictions on transitive properties - good luck with this
>     in practice).
>
>      My advice is to go with a language for formal knowledge
>     representation that was designed as such from the beginning, and
>     is an essential part of the Semantic Web effort.
>
>
> I discussed the issue with Chris Mungall - we both wonder why you need 
> compatibility with OBO at this point?

The idea was to try to have the both versions of ontology, containing 
all the information, if it is possible. But you are right, it's becoming 
unjustified. Thanks for pointing it out.  We'll convert the algorithm 
parameters to owl classes.

-- 
Anna Zhukova
Intern, Computational Systems Neurobiology Group,
European Bioinformatics Institute,
Wellcome Trust Genome Campus,
Hinxton, Cambridge
CB10 1SD, United Kingdom