Re: [SED-ML-discuss] KISAO

[Michel D. <mic...@gm...>]

On Tue, Apr 26, 2011 at 1:50 PM, Michel Dumontier <
mic...@gm...> wrote:

>
>
> On Tue, Apr 26, 2011 at 9:12 AM, Anna Zhukova <zhu...@eb...> wrote:
>
>>  Dear Michel,
>>
>> Thanks for your suggestion for KiSAO.
>> I'd like to discuss some of them.
>>
>>  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?
>
>  b. added disjointness among classes (this helps support reasoning on negated
>> existential axioms)
>> c. LSODA variants not axiomatically differentiated
>>
>>  Thanks, we'll do it.
>>
>>  2. object properties
>> a. deprecate 'lacksProperty', as you can create negated existential axioms
>>
>>  The 'lacksProperty' was added for OWL to OBO conversion: it is not
>> possible to represent negation in OBO, so we use ('lacksProperty'  ?X)
>> instead of (not 'hasProperty' ?X) in OBO version of KiSAO. So
>> 'lacksProperty' is necessary for an OBO version of KiSAO. But you are right,
>> we should deprecate it in the OWL version. Thanks.
>>
>>  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'
>
> 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?

m.


>
> m.
>
>
>> Thanks,
>>
>> Anna Zhukova
>>
>> Intern, Computational Systems Neurobiology Group,
>> European Bioinformatics Institute,
>> Wellcome Trust Genome Campus,
>> Hinxton, Cambridge
>> CB10 1SD, United Kingdom
>>
>>
>
>
> --
> Michel Dumontier
> Associate Professor of Bioinformatics
> Carleton University
> http://dumontierlab.com
>



-- 
Michel Dumontier
Associate Professor of Bioinformatics
Carleton University
http://dumontierlab.com