sbml-annot — SBML L3 annotations discussion list

Re: [sbml-annot] BioModels.net qualifier discussion

[Stefan H. <sh...@vb...>]

Hello All,

On 1/17/11 6:44 AM, Nicolas Le novère wrote:
> Regarding modification, I think we could think about it. Let's try to
> encode them with the extended package first. Since we reify, would-it be
> possible to create something like species X is entity Y modified by Z?
>

In my opinion the last sentence makes one think abundantly clear and 
that is that we must get rid of the use of verbs as predicates. By doing 
that we probably discover that there is actually no difference between 
bqmodel and bqbiol. Lets look at the example:
    isDescribedBy => 'description' (in both cases)

In both cases the property is some kind of publication describing the 
subject. The differentiation is either artificial or a property itself.

Neil has made a very good point in pointing out the equivalency of RDF 
predicates and class attribute and the positive consequence of being 
able do derive properties. We should very much consider to construct the 
MIRIAM qualifier in this way.

Thanks,
Stefan


-- 
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax:   (540) 231-2606
Email: sh...@vb...

Re: [sbml-annot] [Biomodels-net-discuss] SBML Level 3 Annotation package proposal

[Nick J. <ju...@eb...>]

Hi,

I will track the suggestions, and preferences.
On the point of 'isPartOf', I quite like parthood to be honest. And I think Mike is right that the subject entity could be part of a larger object 
entity, which itself could conceptually form the subject of another entity, etc, etc. But it depends on the granularity of the annotation I think, you 
may well wish to refer to the first entity being a part of a 'whole'... (I hope that makes sense).

I think constituent is wrong though - the opposite sense is what is needed. eg. translating "SUBJECT has PREDICATE whose value is OBJECT" -> X has 
constituent whose value is Y, makes Y a 'subunit' of X.

cheers

Nick

Mike Hucka wrote:
> FWIW, my $0.02:
> 
>> 1) bqmodel:isDerivedFrom
>>
>> bqmodel:progenitor, bqmodel:antecedent, bqmodel:ancestor, bqmodel:basis, 
>> bqmodel:base, bqmodel:foundation, bqmodel:origin
>>
>> Neil favours "antecedent". I favour "origin".
> 
> I think origin is less desirable because IMHO it has a sense of an ultimate starting point, rather than "the thing right before".  So I would also favor antecedent or ancestor here.
> 
>> 2) bqbiol:isPartOf
>> bqbiol:encompassment, bqbiol:assembly, bqbiol:partship, bqbiol:parthood, 
>> bqbiol:whole, bqbiol:meronym
>>
>> Neil favours "parthood". I favour "whole".
> 
> This may be a stupid question, but is it always the case that the thing being referred to is in fact the "whole", as opposed to another subpart within a larger context?  I think it's the latter, and so I think "whole" isn't always going to be the appropriate sense.  I also dislike "parthood".
> 
> Would "constituent" be an option here?
> 
> MH
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] [Biomodels-net-discuss] SBML Level 3 Annotation package proposal

[Mike H. <mh...@ca...>]

FWIW, my $0.02:

> 1) bqmodel:isDerivedFrom
> 
> bqmodel:progenitor, bqmodel:antecedent, bqmodel:ancestor, bqmodel:basis, 
> bqmodel:base, bqmodel:foundation, bqmodel:origin
> 
> Neil favours "antecedent". I favour "origin".

I think origin is less desirable because IMHO it has a sense of an ultimate starting point, rather than "the thing right before".  So I would also favor antecedent or ancestor here.

> 2) bqbiol:isPartOf
> bqbiol:encompassment, bqbiol:assembly, bqbiol:partship, bqbiol:parthood, 
> bqbiol:whole, bqbiol:meronym
> 
> Neil favours "parthood". I favour "whole".

This may be a stupid question, but is it always the case that the thing being referred to is in fact the "whole", as opposed to another subpart within a larger context?  I think it's the latter, and so I think "whole" isn't always going to be the appropriate sense.  I also dislike "parthood".

Would "constituent" be an option here?

MH

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Nick J. <ju...@eb...>]

For those like myself who had problems accessing this document, remove the SBML part of the link ;p
ftp://ftp.dbkgroup.org/pub/annot/

cheers

Nick


Neil Swainston wrote:
> Hi all,
> 
> Looks like listserv has eaten the document.
> 
> Try the following:
> 
> ftp://ftp.dbkgroup.org/pub/annot/SBML Level 3 Package Proposal - Annot.doc
> 
> Cheers,
> 
> Neil.
> 
> Neil Swainston
> Experimental Officer
> 
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
> 
> On 17 Jan 2011, at 18:27, Neil Swainston wrote:
> 
>> Dear all,
>>
>> Final one from me today...
>>
>> Enclosed is the draft of the SBML Level 3 Annotation package proposal.
>>
>> We've come a long way since the initial meeting, so thanks very much to everyone for their contributions.
>>
>> I'd be very grateful if you could look through the enclosed document, which is essentially the cleaned-up wiki page that we've been editing on the SBML site. Please feel free to add comments, make changes, but please use "Track Changes" on Word so that we can follow the updates.
>>
>> You'll note that Nick Juty's suggestions for new predicates has been added as a table towards the end of the document. Where there are multiple candidates, I've highlighted my personal preference in bold, but obviously this is all open for discussion. Please let me know your preference (if you have one).
>>
>> My intention is to get this finished off and get this submitted to Nature Precedings so that we have a first, fixed version that can be looked over by the SBML Editors. I'd be therefore very grateful if you could make any changes or comments by Friday 28th January.
>>
>> Best wishes,
>>
>> Neil.
>>
>>
>>
>> Neil Swainston
>> Experimental Officer
>>
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>>
>> On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:
>>
>>> On 13/01/11 13:41, Ron Henkel wrote:
>>>> Hi,
>>>>
>>>> How strict is the requirement that a qualifier needs to be a noun (or
>>>> better exactly one noun)?
>>>>
>>>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>>>> might be confused, for example, with the person who is the encoder.
>>>>
>>>> So I was thinking if it is possible to use something as "encodingDNA".
>>>> It might ease the finding of proper qualifier terms. Would this still be
>>>> a valid predicate since it is not exactly a noun?
>>> I think this kind of thing would in principle be fine even if not elegant. 
>>> Note that in that case, it would not work because this is not restricted to 
>>> DNA. In general I would ban all biological meaning from the qualifiers.
>>>
>>> But I believe you found another candidate: encoding
>>>
>>>> Cheers,
>>>> Ron
>>>>
>>>> On 13.01.2011 14:23, Nick Juty wrote:
>>>>> Dear annotation package people,
>>>>>
>>>>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>>>>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>>>>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>>>>>
>>>>> Below is a list of potential candidate equivalents to existing qualifiers found here: http://biomodels.net/qualifiers/
>>>>>
>>>>> In some cases, the noun translation is quite apparent, and in others, not so much ;p I think if we iterate round a little, we can reach a moderate
>>>>> consensus.
>>>>>
>>>>>
>>>>> model-qualifiers
>>>>> ================
>>>>> is =>   'identity'
>>>>> isDescribedBy =>   'description'
>>>>>
>>>>>
>>>>> biology-qualifier
>>>>> ================
>>>>> hasPart =>   'part'
>>>>> hasProperty =>   'property'
>>>>> hasVersion =>   'version', (relates class to instance; animal is a hypernym of cat)
>>>>> is =>   'identity'
>>>>> isDescribedBy =>   'description'
>>>>> isHomologTo =>   'homolog(ue)'
>>>>>
>>>>>
>>>>> The next few are more difficult, and I have collected together candidate 'equivalents'.
>>>>>
>>>>> model-qualifiers:
>>>>> ================
>>>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>>>> Candidates: progenitor, antecedent, ancestor, basis, base, foundation, origin
>>>>>
>>>>> biology-qualifiers:
>>>>> ================
>>>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>>>> Candidates: encoder
>>>>>
>>>>> 'encodes' - e.g. DNA encodes protein
>>>>> Candidates: encodement
>>>>>
>>>>> 'isPartOf' - e.g. subunit A is part of complex B
>>>>> Candidates: encompassment, assembly, partship, parthood, whole, meronym (relates part to whole; finger is a meronym of hand)
>>>>>
>>>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>>>> Candidates: bearer, carrier,
>>>>>
>>>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>>>> Candidates: consociate, cohort, superclass, hyponym (relates instance to class to; cat is a hyponym of animal)
>>>>>
>>>>> 'occursIn' - may be sensible to split it into 'physical containment' and 'taxonomic instantiation' types.
>>>>> We could use 'encompassment' or 'containment' ('container'), for the physical type, and 'instantiation' for occurrence in a species.
>>>>>
>>>>> I'd appreciate your thoughts on these, and also on other qualifiers you guys have in mind.
>>>>>
>>>>> cheers,
>>>>>
>>>>> Nick
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> Sbml-annot mailing list
>>>>> Sbm...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>
>>> -- 
>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand 
>>> malware threats, the impact they can have on your business, and how you 
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Nick J. <ju...@eb...>]

should we set up a doodle poll for this? or will someone keep track?

Nicolas Le nove`re wrote:
> On 17/01/11 18:27, Neil Swainston wrote:
> 
>> You'll note that Nick Juty's suggestions for new predicates has been
>> added as a table towards the end of the document. Where there are
>> multiple candidates, I've highlighted my personal preference in bold,
>> but obviously this is all open for discussion. Please let me know your
>> preference (if you have one).
> 
> Since the discussion is not in the spec anymore, let's move it here plus 
> biomodels-net-discuss.
> 
> The "accepted" ones
> ===================
> bqmodel:is
> bqmodel:identity
> 
> bqmodel:isDescribedBy
> bqmodel:description
> 
> bqbiol:hasPart
> bqbiol:part
> 
> bqbiol:hasProperty
> bqbiol:property
> 
> bqbiol:hasVersion
> bqbiol:version
> 
> bqbiol:is
> bqbiol:identity
> 
> bqbiol:isDescribedBy
> bqbiol:description
> 
> bqbiol:isHomologTo
> bqbiol:homolog
> 
> bqbiol:isEncodedBy
> bqbiol:encoder
> 
> bqbiol:encodes
> bqbiol:encodement
> 
> The discussions
> ===============
> 
> 1) bqmodel:isDerivedFrom
> 
> bqmodel:progenitor, bqmodel:antecedent, bqmodel:ancestor, bqmodel:basis, 
> bqmodel:base, bqmodel:foundation, bqmodel:origin
> 
> Neil favours "antecedent". I favour "origin".
> 
> 2) bqbiol:isPartOf
> bqbiol:encompassment, bqbiol:assembly, bqbiol:partship, bqbiol:parthood, 
> bqbiol:whole, bqbiol:meronym
> 
> Neil favours "parthood". I favour "whole".
> 
> 3) bqbiol:isPropertyOf
> 
> bqbiol:bearer, bqbiol:carrier
> 
> Neil favours "bearer". I concur
> 
> 4) bqbiol:isVersionOf
> 
> bqbiol:consociate, bqbiol:cohort, bqbiol:superclass, bqbiol:hyponym
> 
> Neil favours superclass. I concur
> 
> 5) bqbiol:occursIn
> 
> This is tricky because we want to split it. At the moment it is used to 
> indicate containment, including "this model of human glycolysis is 
> contained in homo sapiens". This is stretching the containment.
> 
> Physical containment:
> bqbiol:encompassment, bqbiol:containment
> 
> Neil favours containment. I am not too happy with that. "container" would 
> be better, no?
> 
> Taxonomic instantiation:
> bqbiol:instantiation
> 
> I think this is not explicit enough. BTW, we do not want to limit the value 
> to a taxonomic unit. It could be a cell line or something similar.
> 

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Nicolas Le n. <le...@eb...>]

On 17/01/11 18:27, Neil Swainston wrote:

> You'll note that Nick Juty's suggestions for new predicates has been
> added as a table towards the end of the document. Where there are
> multiple candidates, I've highlighted my personal preference in bold,
> but obviously this is all open for discussion. Please let me know your
> preference (if you have one).

Since the discussion is not in the spec anymore, let's move it here plus 
biomodels-net-discuss.

The "accepted" ones
===================
bqmodel:is
bqmodel:identity

bqmodel:isDescribedBy
bqmodel:description

bqbiol:hasPart
bqbiol:part

bqbiol:hasProperty
bqbiol:property

bqbiol:hasVersion
bqbiol:version

bqbiol:is
bqbiol:identity

bqbiol:isDescribedBy
bqbiol:description

bqbiol:isHomologTo
bqbiol:homolog

bqbiol:isEncodedBy
bqbiol:encoder

bqbiol:encodes
bqbiol:encodement

The discussions
===============

1) bqmodel:isDerivedFrom

bqmodel:progenitor, bqmodel:antecedent, bqmodel:ancestor, bqmodel:basis, 
bqmodel:base, bqmodel:foundation, bqmodel:origin

Neil favours "antecedent". I favour "origin".

2) bqbiol:isPartOf
bqbiol:encompassment, bqbiol:assembly, bqbiol:partship, bqbiol:parthood, 
bqbiol:whole, bqbiol:meronym

Neil favours "parthood". I favour "whole".

3) bqbiol:isPropertyOf

bqbiol:bearer, bqbiol:carrier

Neil favours "bearer". I concur

4) bqbiol:isVersionOf

bqbiol:consociate, bqbiol:cohort, bqbiol:superclass, bqbiol:hyponym

Neil favours superclass. I concur

5) bqbiol:occursIn

This is tricky because we want to split it. At the moment it is used to 
indicate containment, including "this model of human glycolysis is 
contained in homo sapiens". This is stretching the containment.

Physical containment:
bqbiol:encompassment, bqbiol:containment

Neil favours containment. I am not too happy with that. "container" would 
be better, no?

Taxonomic instantiation:
bqbiol:instantiation

I think this is not explicit enough. BTW, we do not want to limit the value 
to a taxonomic unit. It could be a cell line or something similar.

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Nicolas Le n. <le...@eb...>]

On 18/01/11 09:15, Neil Swainston wrote:

> http://dl.dropbox.com/u/8980329/Annot.doc

I cannot access this version.

> Please note that I have taken Dagmar's advice on board and have removed
> any discussion on new qualifiers from the proposal.

I would be more nuanced than that. It is true that the qualifiers are not 
part of the spec per se. The spec should only say "here you must use a 
biomodels.net qualifier". But we can add them in appendix, with a note 
stating that these are the qualifiers as of DATE.

HOWEVER, all the examples should be written with nouns. That was the first 
broadly accepted change at the annotation meeting. I believe we should move 
ahead with that.

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

[sbml-annot] SBML Level 3 Annotation package proposal

[Neil S. <nei...@ma...>]

Hi all,

http://dl.dropbox.com/u/8980329/Annot.doc

For those experiencing problems accessing the file, the above link may be better than the previous one.

Please note that I have taken Dagmar's advice on board and have removed any discussion on new qualifiers from the proposal.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 18 Jan 2011, at 03:02, Mike Hucka wrote:

> Hi Neil,
> 
> Thanks for all this hard work.  I'm having trouble accessing that URL (it's refusing me to ftp there).  Would it be possible for you to put it up at some service like http://getcloudapp.com/ ?  I use that all the time and it works well.  There are probably other such services.  (I would have suggested drop.io, my favorite in the recent past, but they're no longer available.)  You could even upload it on sbml.org.
> 
> MH
> 
> 
> On Mon, 17 Jan 2011 18:32:57 +0000, Neil Swainston wrote:
>> Hi all,
>> 
>> Looks like listserv has eaten the document.
>> 
>> Try the following:
>> 
>> ftp://ftp.dbkgroup.org/pub/annot/SBML Level 3 Package Proposal - Annot.doc
>> 
>> Cheers,
>> 
>> Neil.
>> 
>> Neil Swainston
>> Experimental Officer
>> 
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>> 
>> On 17 Jan 2011, at 18:27, Neil Swainston wrote:
>> 
>>> Dear all,
>>> 
>>> Final one from me today...
>>> 
>>> Enclosed is the draft of the SBML Level 3 Annotation package proposal.
>>> 
>>> We've come a long way since the initial meeting, so thanks very much 
>>> to everyone for their contributions.
>>> 
>>> I'd be very grateful if you could look through the enclosed 
>>> document, which is essentially the cleaned-up wiki page that we've 
>>> been editing on the SBML site. Please feel free to add comments, 
>>> make changes, but please use "Track Changes" on Word so that we can 
>>> follow the updates.
>>> 
>>> You'll note that Nick Juty's suggestions for new predicates has been 
>>> added as a table towards the end of the document. Where there are 
>>> multiple candidates, I've highlighted my personal preference in 
>>> bold, but obviously this is all open for discussion. Please let me 
>>> know your preference (if you have one).
>>> 
>>> My intention is to get this finished off and get this submitted to 
>>> Nature Precedings so that we have a first, fixed version that can be 
>>> looked over by the SBML Editors. I'd be therefore very grateful if 
>>> you could make any changes or comments by Friday 28th January.
>>> 
>>> Best wishes,
>>> 
>>> Neil.
>>> 
>>> 
>>> 
>>> Neil Swainston
>>> Experimental Officer
>>> 
>>> Manchester Centre for Integrative Systems Biology
>>> Manchester Interdisciplinary Biocentre
>>> University of Manchester
>>> Manchester M1 7DN
>>> United Kingdom
>>> 
>>> On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:
>>> 
>>>> On 13/01/11 13:41, Ron Henkel wrote:
>>>>> Hi,
>>>>> 
>>>>> How strict is the requirement that a qualifier needs to be a noun (or
>>>>> better exactly one noun)?
>>>>> 
>>>>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>>>>> might be confused, for example, with the person who is the encoder.
>>>>> 
>>>>> So I was thinking if it is possible to use something as "encodingDNA".
>>>>> It might ease the finding of proper qualifier terms. Would this still be
>>>>> a valid predicate since it is not exactly a noun?
>>>> 
>>>> I think this kind of thing would in principle be fine even if not 
>>>> elegant. 
>>>> Note that in that case, it would not work because this is not 
>>>> restricted to 
>>>> DNA. In general I would ban all biological meaning from the qualifiers.
>>>> 
>>>> But I believe you found another candidate: encoding
>>>> 
>>>>> Cheers,
>>>>> Ron
>>>>> 
>>>>> On 13.01.2011 14:23, Nick Juty wrote:
>>>>>> Dear annotation package people,
>>>>>> 
>>>>>> I thought it would be worth opening up the discussion about 
>>>>>> BioModels.net qualifiers, in order to start moving forward more 
>>>>>> earnestly.
>>>>>> The premise is that we wish to have qualifiers that follow the 
>>>>>> "SUBJECT has PREDICATE whose value is OBJECT" statement, and 
>>>>>> thereby need to convert or
>>>>>> add additional qualifiers as nouns, rather than the existing 
>>>>>> situation where they are verbs.
>>>>>> 
>>>>>> Below is a list of potential candidate equivalents to existing 
>>>>>> qualifiers found here: http://biomodels.net/qualifiers/
>>>>>> 
>>>>>> In some cases, the noun translation is quite apparent, and in 
>>>>>> others, not so much ;p I think if we iterate round a little, we 
>>>>>> can reach a moderate
>>>>>> consensus.
>>>>>> 
>>>>>> 
>>>>>> model-qualifiers
>>>>>> ================
>>>>>> is =>   'identity'
>>>>>> isDescribedBy =>   'description'
>>>>>> 
>>>>>> 
>>>>>> biology-qualifier
>>>>>> ================
>>>>>> hasPart =>   'part'
>>>>>> hasProperty =>   'property'
>>>>>> hasVersion =>   'version', (relates class to instance; animal is 
>>>>>> a hypernym of cat)
>>>>>> is =>   'identity'
>>>>>> isDescribedBy =>   'description'
>>>>>> isHomologTo =>   'homolog(ue)'
>>>>>> 
>>>>>> 
>>>>>> The next few are more difficult, and I have collected together 
>>>>>> candidate 'equivalents'.
>>>>>> 
>>>>>> model-qualifiers:
>>>>>> ================
>>>>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>>>>> Candidates: progenitor, antecedent, ancestor, basis, base, 
>>>>>> foundation, origin
>>>>>> 
>>>>>> biology-qualifiers:
>>>>>> ================
>>>>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>>>>> Candidates: encoder
>>>>>> 
>>>>>> 'encodes' - e.g. DNA encodes protein
>>>>>> Candidates: encodement
>>>>>> 
>>>>>> 'isPartOf' - e.g. subunit A is part of complex B
>>>>>> Candidates: encompassment, assembly, partship, parthood, whole, 
>>>>>> meronym (relates part to whole; finger is a meronym of hand)
>>>>>> 
>>>>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>>>>> Candidates: bearer, carrier,
>>>>>> 
>>>>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>>>>> Candidates: consociate, cohort, superclass, hyponym (relates 
>>>>>> instance to class to; cat is a hyponym of animal)
>>>>>> 
>>>>>> 'occursIn' - may be sensible to split it into 'physical 
>>>>>> containment' and 'taxonomic instantiation' types.
>>>>>> We could use 'encompassment' or 'containment' ('container'), for 
>>>>>> the physical type, and 'instantiation' for occurrence in a 
>>>>>> species.
>>>>>> 
>>>>>> I'd appreciate your thoughts on these, and also on other 
>>>>>> qualifiers you guys have in mind.
>>>>>> 
>>>>>> cheers,
>>>>>> 
>>>>>> Nick
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>> can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>> _______________________________________________
>>>>>> Sbml-annot mailing list
>>>>>> Sbm...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand 
>>>> malware threats, the impact they can have on your business, and how you 
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>> 
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand 
>>> malware threats, the impact they can have on your business, and how you 
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>> 
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Neil S. <nei...@ma...>]

Hi Dagmar,

Interesting point. Having said that, most of the Annot proposal is actually not SBML-specific. The only bit that I can see that is specific to SBML is the section on Namespace and integration with SBML L3. The rest of it is just a recommendation of how to use RDF to annotate models. These models could be written in any XML language. Don't know if this is relevant / interesting / worth typing. More of an observation.

Anyways, I'm happy to throw this over to the biomodels.net list and let them work it out (with our help, of course), if people would prefer.

People?

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 21:47, Dagmar Waltemath wrote:

> Hello everyone,
> 
> 
> it seems I am the only one complaining about it, but I have to mention it again (sorry ;-)).
> I really find it a mistake to put the qualifiers into the Anot specification... 
> 
> The reason being that the spec it is an SBML package proposal.
> Therefore, the new qualifiers would be "limited" to SBML people... but they are a biomodels.net concept - and there we always claim not to be tight to SBML.
> 
> So, please, could we just refer to qualifiers out of the annot package, like link to the biomodels.net/qualifiers web site
> and leave the rest to the biomodels.net people (who are not too different from this list)?
> 
> That will allow others, like CellML people, to use the new qualifiers as well. 
> 
> 
> ...please, if you disagree with me, share you counter arguments with me :-)
> Dagmar
> 
> ________________________________________
> From: Neil Swainston [nei...@ma...]
> Sent: 17 January 2011 19:32
> To: Neil Swainston
> Cc: sbm...@li...
> Subject: Re: [sbml-annot] SBML Level 3 Annotation package proposal
> 
> Hi all,
> 
> Looks like listserv has eaten the document.
> 
> Try the following:
> 
> ftp://ftp.dbkgroup.org/pub/annot/SBML Level 3 Package Proposal - Annot.doc
> 
> Cheers,
> 
> Neil.
> 
> Neil Swainston
> Experimental Officer
> 
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
> 
> On 17 Jan 2011, at 18:27, Neil Swainston wrote:
> 
>> Dear all,
>> 
>> Final one from me today...
>> 
>> Enclosed is the draft of the SBML Level 3 Annotation package proposal.
>> 
>> We've come a long way since the initial meeting, so thanks very much to everyone for their contributions.
>> 
>> I'd be very grateful if you could look through the enclosed document, which is essentially the cleaned-up wiki page that we've been editing on the SBML site. Please feel free to add comments, make changes, but please use "Track Changes" on Word so that we can follow the updates.
>> 
>> You'll note that Nick Juty's suggestions for new predicates has been added as a table towards the end of the document. Where there are multiple candidates, I've highlighted my personal preference in bold, but obviously this is all open for discussion. Please let me know your preference (if you have one).
>> 
>> My intention is to get this finished off and get this submitted to Nature Precedings so that we have a first, fixed version that can be looked over by the SBML Editors. I'd be therefore very grateful if you could make any changes or comments by Friday 28th January.
>> 
>> Best wishes,
>> 
>> Neil.
>> 
>> 
>> 
>> Neil Swainston
>> Experimental Officer
>> 
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>> 
>> On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:
>> 
>>> On 13/01/11 13:41, Ron Henkel wrote:
>>>> Hi,
>>>> 
>>>> How strict is the requirement that a qualifier needs to be a noun (or
>>>> better exactly one noun)?
>>>> 
>>>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>>>> might be confused, for example, with the person who is the encoder.
>>>> 
>>>> So I was thinking if it is possible to use something as "encodingDNA".
>>>> It might ease the finding of proper qualifier terms. Would this still be
>>>> a valid predicate since it is not exactly a noun?
>>> 
>>> I think this kind of thing would in principle be fine even if not elegant.
>>> Note that in that case, it would not work because this is not restricted to
>>> DNA. In general I would ban all biological meaning from the qualifiers.
>>> 
>>> But I believe you found another candidate: encoding
>>> 
>>>> Cheers,
>>>> Ron
>>>> 
>>>> On 13.01.2011 14:23, Nick Juty wrote:
>>>>> Dear annotation package people,
>>>>> 
>>>>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>>>>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>>>>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>>>>> 
>>>>> Below is a list of potential candidate equivalents to existing qualifiers found here: http://biomodels.net/qualifiers/
>>>>> 
>>>>> In some cases, the noun translation is quite apparent, and in others, not so much ;p I think if we iterate round a little, we can reach a moderate
>>>>> consensus.
>>>>> 
>>>>> 
>>>>> model-qualifiers
>>>>> ================
>>>>> is =>   'identity'
>>>>> isDescribedBy =>   'description'
>>>>> 
>>>>> 
>>>>> biology-qualifier
>>>>> ================
>>>>> hasPart =>   'part'
>>>>> hasProperty =>   'property'
>>>>> hasVersion =>   'version', (relates class to instance; animal is a hypernym of cat)
>>>>> is =>   'identity'
>>>>> isDescribedBy =>   'description'
>>>>> isHomologTo =>   'homolog(ue)'
>>>>> 
>>>>> 
>>>>> The next few are more difficult, and I have collected together candidate 'equivalents'.
>>>>> 
>>>>> model-qualifiers:
>>>>> ================
>>>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>>>> Candidates: progenitor, antecedent, ancestor, basis, base, foundation, origin
>>>>> 
>>>>> biology-qualifiers:
>>>>> ================
>>>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>>>> Candidates: encoder
>>>>> 
>>>>> 'encodes' - e.g. DNA encodes protein
>>>>> Candidates: encodement
>>>>> 
>>>>> 'isPartOf' - e.g. subunit A is part of complex B
>>>>> Candidates: encompassment, assembly, partship, parthood, whole, meronym (relates part to whole; finger is a meronym of hand)
>>>>> 
>>>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>>>> Candidates: bearer, carrier,
>>>>> 
>>>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>>>> Candidates: consociate, cohort, superclass, hyponym (relates instance to class to; cat is a hyponym of animal)
>>>>> 
>>>>> 'occursIn' - may be sensible to split it into 'physical containment' and 'taxonomic instantiation' types.
>>>>> We could use 'encompassment' or 'containment' ('container'), for the physical type, and 'instantiation' for occurrence in a species.
>>>>> 
>>>>> I'd appreciate your thoughts on these, and also on other qualifiers you guys have in mind.
>>>>> 
>>>>> cheers,
>>>>> 
>>>>> Nick
>>>>> 
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> Sbml-annot mailing list
>>>>> Sbm...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>> 
>>> 
>>> 
>>> --
>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>> 
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Dagmar W. <dag...@un...>]

Hello everyone,


it seems I am the only one complaining about it, but I have to mention it again (sorry ;-)).
I really find it a mistake to put the qualifiers into the Anot specification... 

The reason being that the spec it is an SBML package proposal.
Therefore, the new qualifiers would be "limited" to SBML people... but they are a biomodels.net concept - and there we always claim not to be tight to SBML.

So, please, could we just refer to qualifiers out of the annot package, like link to the biomodels.net/qualifiers web site
and leave the rest to the biomodels.net people (who are not too different from this list)?

That will allow others, like CellML people, to use the new qualifiers as well. 


...please, if you disagree with me, share you counter arguments with me :-)
Dagmar

________________________________________
From: Neil Swainston [nei...@ma...]
Sent: 17 January 2011 19:32
To: Neil Swainston
Cc: sbm...@li...
Subject: Re: [sbml-annot] SBML Level 3 Annotation package proposal

Hi all,

Looks like listserv has eaten the document.

Try the following:

ftp://ftp.dbkgroup.org/pub/annot/SBML Level 3 Package Proposal - Annot.doc

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 18:27, Neil Swainston wrote:

> Dear all,
>
> Final one from me today...
>
> Enclosed is the draft of the SBML Level 3 Annotation package proposal.
>
> We've come a long way since the initial meeting, so thanks very much to everyone for their contributions.
>
> I'd be very grateful if you could look through the enclosed document, which is essentially the cleaned-up wiki page that we've been editing on the SBML site. Please feel free to add comments, make changes, but please use "Track Changes" on Word so that we can follow the updates.
>
> You'll note that Nick Juty's suggestions for new predicates has been added as a table towards the end of the document. Where there are multiple candidates, I've highlighted my personal preference in bold, but obviously this is all open for discussion. Please let me know your preference (if you have one).
>
> My intention is to get this finished off and get this submitted to Nature Precedings so that we have a first, fixed version that can be looked over by the SBML Editors. I'd be therefore very grateful if you could make any changes or comments by Friday 28th January.
>
> Best wishes,
>
> Neil.
>
>
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:
>
>> On 13/01/11 13:41, Ron Henkel wrote:
>>> Hi,
>>>
>>> How strict is the requirement that a qualifier needs to be a noun (or
>>> better exactly one noun)?
>>>
>>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>>> might be confused, for example, with the person who is the encoder.
>>>
>>> So I was thinking if it is possible to use something as "encodingDNA".
>>> It might ease the finding of proper qualifier terms. Would this still be
>>> a valid predicate since it is not exactly a noun?
>>
>> I think this kind of thing would in principle be fine even if not elegant.
>> Note that in that case, it would not work because this is not restricted to
>> DNA. In general I would ban all biological meaning from the qualifiers.
>>
>> But I believe you found another candidate: encoding
>>
>>> Cheers,
>>> Ron
>>>
>>> On 13.01.2011 14:23, Nick Juty wrote:
>>>> Dear annotation package people,
>>>>
>>>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>>>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>>>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>>>>
>>>> Below is a list of potential candidate equivalents to existing qualifiers found here: http://biomodels.net/qualifiers/
>>>>
>>>> In some cases, the noun translation is quite apparent, and in others, not so much ;p I think if we iterate round a little, we can reach a moderate
>>>> consensus.
>>>>
>>>>
>>>> model-qualifiers
>>>> ================
>>>> is =>   'identity'
>>>> isDescribedBy =>   'description'
>>>>
>>>>
>>>> biology-qualifier
>>>> ================
>>>> hasPart =>   'part'
>>>> hasProperty =>   'property'
>>>> hasVersion =>   'version', (relates class to instance; animal is a hypernym of cat)
>>>> is =>   'identity'
>>>> isDescribedBy =>   'description'
>>>> isHomologTo =>   'homolog(ue)'
>>>>
>>>>
>>>> The next few are more difficult, and I have collected together candidate 'equivalents'.
>>>>
>>>> model-qualifiers:
>>>> ================
>>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>>> Candidates: progenitor, antecedent, ancestor, basis, base, foundation, origin
>>>>
>>>> biology-qualifiers:
>>>> ================
>>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>>> Candidates: encoder
>>>>
>>>> 'encodes' - e.g. DNA encodes protein
>>>> Candidates: encodement
>>>>
>>>> 'isPartOf' - e.g. subunit A is part of complex B
>>>> Candidates: encompassment, assembly, partship, parthood, whole, meronym (relates part to whole; finger is a meronym of hand)
>>>>
>>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>>> Candidates: bearer, carrier,
>>>>
>>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>>> Candidates: consociate, cohort, superclass, hyponym (relates instance to class to; cat is a hyponym of animal)
>>>>
>>>> 'occursIn' - may be sensible to split it into 'physical containment' and 'taxonomic instantiation' types.
>>>> We could use 'encompassment' or 'containment' ('container'), for the physical type, and 'instantiation' for occurrence in a species.
>>>>
>>>> I'd appreciate your thoughts on these, and also on other qualifiers you guys have in mind.
>>>>
>>>> cheers,
>>>>
>>>> Nick
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>
>>
>>
>> --
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sbml-annot mailing list
Sbm...@li...
https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] SBML Level 3 Annotation package proposal

[Neil S. <nei...@ma...>]

Hi all,

Looks like listserv has eaten the document.

Try the following:

ftp://ftp.dbkgroup.org/pub/annot/SBML Level 3 Package Proposal - Annot.doc

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 18:27, Neil Swainston wrote:

> Dear all,
> 
> Final one from me today...
> 
> Enclosed is the draft of the SBML Level 3 Annotation package proposal.
> 
> We've come a long way since the initial meeting, so thanks very much to everyone for their contributions.
> 
> I'd be very grateful if you could look through the enclosed document, which is essentially the cleaned-up wiki page that we've been editing on the SBML site. Please feel free to add comments, make changes, but please use "Track Changes" on Word so that we can follow the updates.
> 
> You'll note that Nick Juty's suggestions for new predicates has been added as a table towards the end of the document. Where there are multiple candidates, I've highlighted my personal preference in bold, but obviously this is all open for discussion. Please let me know your preference (if you have one).
> 
> My intention is to get this finished off and get this submitted to Nature Precedings so that we have a first, fixed version that can be looked over by the SBML Editors. I'd be therefore very grateful if you could make any changes or comments by Friday 28th January.
> 
> Best wishes,
> 
> Neil.
> 
> 
> 
> Neil Swainston
> Experimental Officer
> 
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
> 
> On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:
> 
>> On 13/01/11 13:41, Ron Henkel wrote:
>>> Hi,
>>> 
>>> How strict is the requirement that a qualifier needs to be a noun (or
>>> better exactly one noun)?
>>> 
>>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>>> might be confused, for example, with the person who is the encoder.
>>> 
>>> So I was thinking if it is possible to use something as "encodingDNA".
>>> It might ease the finding of proper qualifier terms. Would this still be
>>> a valid predicate since it is not exactly a noun?
>> 
>> I think this kind of thing would in principle be fine even if not elegant. 
>> Note that in that case, it would not work because this is not restricted to 
>> DNA. In general I would ban all biological meaning from the qualifiers.
>> 
>> But I believe you found another candidate: encoding
>> 
>>> Cheers,
>>> Ron
>>> 
>>> On 13.01.2011 14:23, Nick Juty wrote:
>>>> Dear annotation package people,
>>>> 
>>>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>>>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>>>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>>>> 
>>>> Below is a list of potential candidate equivalents to existing qualifiers found here: http://biomodels.net/qualifiers/
>>>> 
>>>> In some cases, the noun translation is quite apparent, and in others, not so much ;p I think if we iterate round a little, we can reach a moderate
>>>> consensus.
>>>> 
>>>> 
>>>> model-qualifiers
>>>> ================
>>>> is =>   'identity'
>>>> isDescribedBy =>   'description'
>>>> 
>>>> 
>>>> biology-qualifier
>>>> ================
>>>> hasPart =>   'part'
>>>> hasProperty =>   'property'
>>>> hasVersion =>   'version', (relates class to instance; animal is a hypernym of cat)
>>>> is =>   'identity'
>>>> isDescribedBy =>   'description'
>>>> isHomologTo =>   'homolog(ue)'
>>>> 
>>>> 
>>>> The next few are more difficult, and I have collected together candidate 'equivalents'.
>>>> 
>>>> model-qualifiers:
>>>> ================
>>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>>> Candidates: progenitor, antecedent, ancestor, basis, base, foundation, origin
>>>> 
>>>> biology-qualifiers:
>>>> ================
>>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>>> Candidates: encoder
>>>> 
>>>> 'encodes' - e.g. DNA encodes protein
>>>> Candidates: encodement
>>>> 
>>>> 'isPartOf' - e.g. subunit A is part of complex B
>>>> Candidates: encompassment, assembly, partship, parthood, whole, meronym (relates part to whole; finger is a meronym of hand)
>>>> 
>>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>>> Candidates: bearer, carrier,
>>>> 
>>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>>> Candidates: consociate, cohort, superclass, hyponym (relates instance to class to; cat is a hyponym of animal)
>>>> 
>>>> 'occursIn' - may be sensible to split it into 'physical containment' and 'taxonomic instantiation' types.
>>>> We could use 'encompassment' or 'containment' ('container'), for the physical type, and 'instantiation' for occurrence in a species.
>>>> 
>>>> I'd appreciate your thoughts on these, and also on other qualifiers you guys have in mind.
>>>> 
>>>> cheers,
>>>> 
>>>> Nick
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>> 
>> 
>> 
>> -- 
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>> 
>> 
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

[sbml-annot] SBML Level 3 Annotation package proposal

[Neil S. <nei...@ma...>]

Dear all,

Final one from me today...

Enclosed is the draft of the SBML Level 3 Annotation package proposal.

We've come a long way since the initial meeting, so thanks very much to everyone for their contributions.

I'd be very grateful if you could look through the enclosed document, which is essentially the cleaned-up wiki page that we've been editing on the SBML site. Please feel free to add comments, make changes, but please use "Track Changes" on Word so that we can follow the updates.

You'll note that Nick Juty's suggestions for new predicates has been added as a table towards the end of the document. Where there are multiple candidates, I've highlighted my personal preference in bold, but obviously this is all open for discussion. Please let me know your preference (if you have one).

My intention is to get this finished off and get this submitted to Nature Precedings so that we have a first, fixed version that can be looked over by the SBML Editors. I'd be therefore very grateful if you could make any changes or comments by Friday 28th January.

Best wishes,

Neil.



Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 13 Jan 2011, at 13:52, Nicolas Le novère wrote:

> On 13/01/11 13:41, Ron Henkel wrote:
>> Hi,
>> 
>> How strict is the requirement that a qualifier needs to be a noun (or
>> better exactly one noun)?
>> 
>> For example the 'isEncodedBy' qualifier: if we used "encoder" here it
>> might be confused, for example, with the person who is the encoder.
>> 
>> So I was thinking if it is possible to use something as "encodingDNA".
>> It might ease the finding of proper qualifier terms. Would this still be
>> a valid predicate since it is not exactly a noun?
> 
> I think this kind of thing would in principle be fine even if not elegant. 
> Note that in that case, it would not work because this is not restricted to 
> DNA. In general I would ban all biological meaning from the qualifiers.
> 
> But I believe you found another candidate: encoding
> 
>> Cheers,
>> Ron
>> 
>> On 13.01.2011 14:23, Nick Juty wrote:
>>> Dear annotation package people,
>>> 
>>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>>> 
>>> Below is a list of potential candidate equivalents to existing qualifiers found here: http://biomodels.net/qualifiers/
>>> 
>>> In some cases, the noun translation is quite apparent, and in others, not so much ;p I think if we iterate round a little, we can reach a moderate
>>> consensus.
>>> 
>>> 
>>> model-qualifiers
>>> ================
>>> is =>   'identity'
>>> isDescribedBy =>   'description'
>>> 
>>> 
>>> biology-qualifier
>>> ================
>>> hasPart =>   'part'
>>> hasProperty =>   'property'
>>> hasVersion =>   'version', (relates class to instance; animal is a hypernym of cat)
>>> is =>   'identity'
>>> isDescribedBy =>   'description'
>>> isHomologTo =>   'homolog(ue)'
>>> 
>>> 
>>> The next few are more difficult, and I have collected together candidate 'equivalents'.
>>> 
>>> model-qualifiers:
>>> ================
>>> 'isDerivedFrom' - needs to reflect modifications to an original model.
>>> Candidates: progenitor, antecedent, ancestor, basis, base, foundation, origin
>>> 
>>> biology-qualifiers:
>>> ================
>>> 'isEncodedBy' - e.g. protein is encoded by DNA
>>> Candidates: encoder
>>> 
>>> 'encodes' - e.g. DNA encodes protein
>>> Candidates: encodement
>>> 
>>> 'isPartOf' - e.g. subunit A is part of complex B
>>> Candidates: encompassment, assembly, partship, parthood, whole, meronym (relates part to whole; finger is a meronym of hand)
>>> 
>>> 'isPropertyOf' - e.g. enzyme activity A is property of entity B
>>> Candidates: bearer, carrier,
>>> 
>>> 'isVersionOf' - needs to convey the sense of belonging to some class
>>> Candidates: consociate, cohort, superclass, hyponym (relates instance to class to; cat is a hyponym of animal)
>>> 
>>> 'occursIn' - may be sensible to split it into 'physical containment' and 'taxonomic instantiation' types.
>>> We could use 'encompassment' or 'containment' ('container'), for the physical type, and 'instantiation' for occurrence in a species.
>>> 
>>> I'd appreciate your thoughts on these, and also on other qualifiers you guys have in mind.
>>> 
>>> cheers,
>>> 
>>> Nick
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>> 
> 
> 
> -- 
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
> 
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Neil S. <nei...@ma...>]

Hi Nicolas,

Agree with all of that. Including the e-mail address issue.

One thing I would add though, that in some cases the use of literals is valid when the values that they specify are immutable. A given species will always have a specified formula, for example.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 16:00, Nicolas Le novère wrote:

> On 17/01/11 15:48, Neil Swainston wrote:
> 
>> I'm not sure that we do exclusively specify links to metadata in SBML. Take
>> the following example...
>> 
>> <rdf:RDF
>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns:dcterms="http://purl.org/dc/terms/"xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"xmlns:bqmodel="http://biomodels.net/model-qualifiers/">
>> <rdf:Description rdf:about="#metaid_recon1_1">
>> <dc:creator>
> 
>> "Neil" and "Swainston" and "2011-01-11" aren't links to metadata, they are
>> metadata. We already support the use of literals in the Core annotation.
> 
> Yes ...  you are right of course. I guess I just never considered those attribution annotation as proper parts of the "generic" RDF scheme. And accordingly they are very problematic. For instance, the e-mail addresses become invalid quickly. As soon as ORCID (http://www.orcid.org/) is adopted by the world and we have proper authors repository, I hope the creator and modifier bits will just point to orcids.
> 
>> Essentially, I'm not following your point on abandoning RDF when it comes
>> to specifying literals such as molecular weight or whatever. I'd have
>> thought that adding an entirely new way of specifying these independently
>> of RDF would be confusing.
> 
> I bow. RDFa would be the way to go.
> 
>> > But who will maintain the vocabularies? The formula, charge and ...
>> molecular weight, hydrodynamic radius, polarity, size, shape, conductivity,
>> etc. ?
>> 
>> Excellent question. I don't know. My thought is that these would be MIRIAM
>> qualifiers like any other. Like you point out, *someone* has to keep track
>> of them and their meanings.
> 
> This is done already. By PATO and others. The same way we use vCard and DCTERMS, we should use external vocabularies IMHO.
> 
> 
> -- 
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
> 

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Nicolas Le n. <le...@eb...>]

On 17/01/11 15:48, Neil Swainston wrote:

> I'm not sure that we do exclusively specify links to metadata in SBML. Take
> the following example...
>
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns:dcterms="http://purl.org/dc/terms/"xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"xmlns:bqmodel="http://biomodels.net/model-qualifiers/">
> <rdf:Description rdf:about="#metaid_recon1_1">
> <dc:creator>

> "Neil" and "Swainston" and "2011-01-11" aren't links to metadata, they are
> metadata. We already support the use of literals in the Core annotation.

Yes ...  you are right of course. I guess I just never considered those 
attribution annotation as proper parts of the "generic" RDF scheme. And 
accordingly they are very problematic. For instance, the e-mail addresses 
become invalid quickly. As soon as ORCID (http://www.orcid.org/) is adopted 
by the world and we have proper authors repository, I hope the creator and 
modifier bits will just point to orcids.

> Essentially, I'm not following your point on abandoning RDF when it comes
> to specifying literals such as molecular weight or whatever. I'd have
> thought that adding an entirely new way of specifying these independently
> of RDF would be confusing.

I bow. RDFa would be the way to go.

>  > But who will maintain the vocabularies? The formula, charge and ...
> molecular weight, hydrodynamic radius, polarity, size, shape, conductivity,
> etc. ?
>
> Excellent question. I don't know. My thought is that these would be MIRIAM
> qualifiers like any other. Like you point out, *someone* has to keep track
> of them and their meanings.

This is done already. By PATO and others. The same way we use vCard and 
DCTERMS, we should use external vocabularies IMHO.


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Neil S. <nei...@ma...>]

Hi Nicolas,

I'm not sure that we do exclusively specify links to metadata in SBML. Take the following example...

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#" xmlns:bqbiol="http://biomodels.net/biology-qualifiers/" xmlns:bqmodel="http://biomodels.net/model-qualifiers/">
        <rdf:Description rdf:about="#metaid_recon1_1">
          <dc:creator>
            <rdf:Bag>
              <rdf:li rdf:parseType="Resource">
                <vCard:N rdf:parseType="Resource">
                  <vCard:Family>Swainston</vCard:Family>
                  <vCard:Given>Neil</vCard:Given>
                </vCard:N>
                <vCard:EMAIL>nei...@ma...</vCard:EMAIL>
                <vCard:ORG rdf:parseType="Resource">
                  <vCard:Orgname>University of Manchester</vCard:Orgname>
                </vCard:ORG>
              </rdf:li>
            </rdf:Bag>
          </dc:creator>
          <dcterms:created rdf:parseType="Resource">
            <dcterms:W3CDTF>2011-01-11T21:14:48Z</dcterms:W3CDTF>
          </dcterms:created>
	</rdf:Description>
</rdf:RDF>

"Neil" and "Swainston" and "2011-01-11" aren't links to metadata, they are metadata. We already support the use of literals in the Core annotation.

Essentially, I'm not following your point on abandoning RDF when it comes to specifying literals such as molecular weight or whatever. I'd have thought that adding an entirely new way of specifying these independently of RDF would be confusing.

> But who will maintain the vocabularies? The formula, charge and ... molecular weight, hydrodynamic radius, polarity, size, shape, conductivity, etc. ?

Excellent question. I don't know. My thought is that these would be MIRIAM qualifiers like any other. Like you point out, *someone* has to keep track of them and their meanings.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 15:32, Nicolas Le novère wrote:

> On 17/01/11 15:22, Neil Swainston wrote:
> 
>> At first glance, I don't know whether this would be a new package or a more
>> flexible means of using Annot.
> 
> Whether it is a new package or the same does not matter much (except for namespace issues). What matters is that the current controlled metadata framework is a semantic web one. SBML controlled annotations do not store metadata. They store links to metadata, and relationships between data and metadata. What we are now discussing is to store the metadata within the SBML file. This is why I say it is different.
> 
>> I think that the bloated RDF/XML syntax scares users off a little. However,
>> RDF triplets can be specified in a number of ways.
> 
> Actually, I do not think we need RDF at all if the purpose is to store the metadata in the SBML itself.
> 
>> Doing a tiny bit of digging, I've found a document describing use of RDF in
>> the context of XHTML documents:
>> 
>> http://www.w3.org/MarkUp/2004/02/xhtml-rdf.html
>> 
>> The same, simplified syntax could be applied to SBML in the context of this
>> discussion. For example, the example from the document:
>> 
>> <html xmlns:dc="http://purl.org/dc/elements/1.1/">
>>         <head>
>>                 <title>How to complete Memorandum cover sheets</title>
>>                 <meta property="dc:creator">John Doe</meta>
>>                 <meta property="dc:rights">&copy; 1997 Acme Corp.</meta>
>>                 <meta property="dc:subject">corporate,guidelines,cataloging</meta>
>>                 <meta property="dc:date">1994-11-06T08:49:37+00:00</meta>
>>         </head>
>>         ...
>> 
>> 
>> ... could easily be rewritten:
>> 
>> <sbml xmlns:bqbiol="http://biomodels.net/biology-qualifiers/">
>>         ...
>>         <species id="glc" name="D-Glucose" ...>
>>         	<meta property="bqbiol:formula">C6H1206</meta>
>>                 <meta property="bqbiol:charge">0</meta>
>>                 <meta property="bqbiol:identity rdf:resource="urn:miriam:obo.chebi:CHEBI%3A4167"></meta>
>>         </species>
>>         ...
>> 
>> 
>> This, to me at least, is a lot more accessible for users and could in most
>> cases (ignoring more complex structures like reification) be mapped to the
>> proposals of the Annot extension.
> 
> But who will maintain the vocabularies? The formula, charge and ... molecular weight, hydrodynamic radius, polarity, size, shape, conductivity, etc. ?
> 
> 
> -- 
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
> 

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Nicolas Le n. <le...@eb...>]

On 17/01/11 15:22, Neil Swainston wrote:

> At first glance, I don't know whether this would be a new package or a more
> flexible means of using Annot.

Whether it is a new package or the same does not matter much (except for 
namespace issues). What matters is that the current controlled metadata 
framework is a semantic web one. SBML controlled annotations do not store 
metadata. They store links to metadata, and relationships between data and 
metadata. What we are now discussing is to store the metadata within the 
SBML file. This is why I say it is different.

> I think that the bloated RDF/XML syntax scares users off a little. However,
> RDF triplets can be specified in a number of ways.

Actually, I do not think we need RDF at all if the purpose is to store the 
metadata in the SBML itself.

> Doing a tiny bit of digging, I've found a document describing use of RDF in
> the context of XHTML documents:
>
> http://www.w3.org/MarkUp/2004/02/xhtml-rdf.html
>
> The same, simplified syntax could be applied to SBML in the context of this
> discussion. For example, the example from the document:
>
> <html xmlns:dc="http://purl.org/dc/elements/1.1/">
>          <head>
>                  <title>How to complete Memorandum cover sheets</title>
>                  <meta property="dc:creator">John Doe</meta>
>                  <meta property="dc:rights">&copy; 1997 Acme Corp.</meta>
>                  <meta property="dc:subject">corporate,guidelines,cataloging</meta>
>                  <meta property="dc:date">1994-11-06T08:49:37+00:00</meta>
>          </head>
>          ...
>
>
> ... could easily be rewritten:
>
> <sbml xmlns:bqbiol="http://biomodels.net/biology-qualifiers/">
>          ...
>          <species id="glc" name="D-Glucose" ...>
>          	<meta property="bqbiol:formula">C6H1206</meta>
>                  <meta property="bqbiol:charge">0</meta>
>                  <meta property="bqbiol:identity rdf:resource="urn:miriam:obo.chebi:CHEBI%3A4167"></meta>
>          </species>
>          ...
>
>
> This, to me at least, is a lot more accessible for users and could in most
> cases (ignoring more complex structures like reification) be mapped to the
> proposals of the Annot extension.

But who will maintain the vocabularies? The formula, charge and ... 
molecular weight, hydrodynamic radius, polarity, size, shape, conductivity, 
etc. ?


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Neil S. <nei...@ma...>]

Hi Nicolas,

At first glance, I don't know whether this would be a new package or a more flexible means of using Annot.

I think that the bloated RDF/XML syntax scares users off a little. However, RDF triplets can be specified in a number of ways.

Doing a tiny bit of digging, I've found a document describing use of RDF in the context of XHTML documents:

http://www.w3.org/MarkUp/2004/02/xhtml-rdf.html

The same, simplified syntax could be applied to SBML in the context of this discussion. For example, the example from the document:

<html xmlns:dc="http://purl.org/dc/elements/1.1/">
        <head>
                <title>How to complete Memorandum cover sheets</title>
                <meta property="dc:creator">John Doe</meta>
                <meta property="dc:rights">&copy; 1997 Acme Corp.</meta>
                <meta property="dc:subject">corporate,guidelines,cataloging</meta>
                <meta property="dc:date">1994-11-06T08:49:37+00:00</meta>
        </head>
        ...

... could easily be rewritten:

<sbml xmlns:bqbiol="http://biomodels.net/biology-qualifiers/">
        ...
        <species id="glc" name="D-Glucose" ...>
        	<meta property="bqbiol:formula">C6H1206</meta>
                <meta property="bqbiol:charge">0</meta>
                <meta property="bqbiol:identity rdf:resource="urn:miriam:obo.chebi:CHEBI%3A4167"></meta>
        </species>
        ...

This, to me at least, is a lot more accessible for users and could in most cases (ignoring more complex structures like reification) be mapped to the proposals of the Annot extension.

A key thing to getting users to use this would be the development of an API to make these things easy to read / write across different platforms / programming languages. If only someone would write a libAnnotationSBML...

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 14:44, Nicolas Le novère wrote:

> Hi Neil,
> 
> But if the purpose is to cope with a given tool that is not supporting the whole specification of SBML (controlled RDF has been introduced in L2V2 in 2005), is-it not a case for a proprietary annotation rather than bloating the common annotation scheme? If COBRA does not support SBML controlled and MIRIAM URIs, presumably, it does not support bq qualifiers as well. So adding the qualifiers would not change much. What you need would rather be an annotation in the COBRA namespace that replaces the notes of your example. Alternatively we could extend the scheme we used for InChIs.
> 
> Now, that led me to a reflexion that is a bit deeper than that, and I think it should be moved to sbml-discuss at some point.
> 
> Several times in the past, people have wanted to add metadata to SBML files, rather than pointers to metadata. This is the case with your example. FORMULA or CHARGE are not fundamentally different from SEQUENCE or STRUCTURE.
> 
> I wonder if the time has not come to design another metadata framework, parallel to the RDF one, which purpose would be to store the information together with the model. If we do that, we probably do not want to use elements such as <formular>, <charge>, <sequence> etc. However, we would like the element to be identifiers from MIRIAM Resources (NOT MIRIAM URNs, the identifiers of a data-type in MIRIAM Resources), PATO quality branch, the future BioDbCore etc. The spec would not list the elements, but the accepted source for the elements.
> 
> This is food for another L3 package.
> 
> On 17/01/11 14:19, Neil Swainston wrote:
>> Hi Nick (and Nicolas - this covers your recent mail re: InChIs, too),
>> 
>> You're right with this example - we do actually have a ChEBI identifier.
>> Where possible, we attempt to add "unknown" metabolites to ChEBI, who
>> curate and publish them super-quickly. (We have no problems with the speed
>> of response of the ChEBI guys).
>> 
>> The problem is a pragmatic one. These large models are analysed by software
>> that lags behind what we're doing with annotations. An example is the COBRA
>> Toolbox, which - like it or not - has become a well used tool for analysing
>> genome-scale metabolic models. This has been written in Matlab by people
>> who have no interest whatsoever in annotations. Their algorithms require
>> access to formulae and charges and such like, and the writers of the
>> software certainly wouldn't go to the effort of querying MIRIAM and ChEBI
>> webservices in order to pick these up. So, if we relied on annotations
>> alone, they simply wouldn't use the model, as it wouldn't (in their eyes)
>> contain sufficient meta-data to allow them to run their analyses over.
>> 
>> Although I can see that duplicating this info by specifying both a ChEBI
>> id, and adding terms like formulae to the notes is a bit rubbish from a
>> clean-and-proper sense, I think that we have to be realistic. Which is why
>> (in this case) I support both crappy notes and semantic annotations.
>> 
>> I believe, however, that there may be a middle-ground that would allow
>> properties to be specified more formally without expecting developers of
>> software packages to rely on querying web services to get these properties.
>> Even if that is the better way of doing things, and what we're doing now is
>> effectively warehousing some of the data from ChEBI. It's just a question
>> of being realistic with where we are.
>> 
>> Cheers,
>> 
>> Neil.
>> 
>> Neil Swainston
>> Experimental Officer
>> 
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>> 
>> On 17 Jan 2011, at 13:52, Nick Juty wrote:
>> 
>>> Hi Neil,
>>> 
>>> Couple of questions - I'm trying to figure out what you use this
>>> information for...
>>> 
>>> The example you have below contains much of the info that is held in a
>>> ChEBI entry:
>>> http://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:18090
>>> 
>>> Are you, in effect, using the model file to store information in lieu of
>>> that information being accessible through a MIRIAM identifier? Also, when
>>> you find such entities (which have no associable database reference), do
>>> you submit them to ChEBI for curation/incorporation? And if so, how long
>>> do they take to appear, and do you subsequently remove them from your
>>> files? Or alternatively, do you need this level of information for each
>>> entity in your model?
>>> 
>>> cheers
>>> 
>>> Nick
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Neil Swainston wrote:
>>>> Hmm... interesting questions.
>>>> I'm not sure that I know the answers, but I'll try.
>>>> The reason that SMILES, InChIs, charges, etc. have come into my
>>>> consciousness is that I'm currently wrestling with the human
>>>> genome-scale model, in which we have a number of metabolites for which
>>>> we *don't* have a KEGG or ChEBI identifier, but do know some properties
>>>> of the molecule.
>>>> We currently do this in a Palsson-friendly, COBRA-compatible way of
>>>> specifying them in the notes:
>>>> <species metaid="_meta_bamppald_c" id="_bamppald_c"
>>>> name="beta-Aminopropion aldehyde" compartment="c" sboTerm="SBO:0000247">
>>>> <notes>
>>>> <body xmlns="http://www.w3.org/1999/xhtml">
>>>> <p>NEUTRAL_FORMULA: C3H7NO</p>
>>>> <p>FORMULA: C3H8NO</p>
>>>> <p>CHARGE: 1</p>
>>>> <p>INCHI: InChI=1/C3H7NO/c4-2-1-3-5/h3H,1-2,4H2</p>
>>>> <p>ORIGIN: Recon 1</p>
>>>> </body>
>>>> </notes>
>>>> Not ideal, but currently necessary, as we have no other means of
>>>> specifying this. (Note that "charge" has been (correctly) dropped as an
>>>> attribute of species, as it should be an annotation. An annotation that
>>>> we currently can't express).
>>>> This problem has also been encountered by Brett and Frank, and they
>>>> propose a solution in their Flux package extension:
>>>> http://precedings.nature.com/documents/4236/version/1/files/npre20104236-1.pdf
>>>> To me at, least, it would be bad to have numerous ways of specifying a
>>>> concept such as charge or formula in a number of package extensions.
>>>> Also, for me, specifying the concept of SMILES in MIRIAM would not be
>>>> the way to go. MIRIAM does an excellent job of collating and specifying
>>>> identifiers, not properties. I would have thought that SMILES (or InChI
>>>> or formula) would be a free text field, independent of MIRIAM
>>>> identifiers, but with the semantic information that this free text
>>>> actually represents a SMILES string (or whatever) being held in the
>>>> predicate. To specify SMILES as a data type would mean that MIRIAM would
>>>> have to enumerate all possible SMILES strings. It would make even less
>>>> sense to enumerate all possible charges.
>>>> Specifying...
>>>> SPECIES has DESCRIPTION whose value is C6H6O6
>>>> SPECIES has DESCRIPTION whose value is -1
>>>> ...is ambiguous. What kind of description?
>>>> Going back to what I wrote earlier about schema classes...
>>>> http://www.w3.org/TR/rdf-primer/#schemaclasses
>>>> ...this would give us the mechanism to describe the concept of a charge,
>>>> and constrain it to be an integer, for example.
>>>> By the way, I consider all this to be next generation stuff, so it
>>>> shouldn't affect the first Annot package proposal, which I hope to send
>>>> out to you all later in the week for more fireworks.
>>>> Cheers,
>>>> Neil.
>>>> Neil Swainston
>>>> Experimental Officer
>>>> Manchester Centre for Integrative Systems Biology
>>>> Manchester Interdisciplinary Biocentre
>>>> University of Manchester
>>>> Manchester M1 7DN
>>>> United Kingdom
>>>> On 17 Jan 2011, at 11:44, Nicolas Le novère wrote:
>>>>> Indeed, we are adding qualifiers on a regular basis. Latest examples
>>>>> are isDerivedFrom, hasProperty and isPropertyOf.
>>>>> 
>>>>> I am worried about encoding particular qualities in qualifiers rather
>>>>> than generic relationships though. A chemical isDescribedBy a SMILE. As
>>>>> Nick pointed out, the SMILE itself would be a datatype if there was a
>>>>> namespace associated. Alternatively, the SMILE can be stored in the
>>>>> SBML file with a mechanism like the one proposed for InChIs. If we
>>>>> create a qualifier SMILE, then we basically need to create a qualifier
>>>>> for each entry of PATO as well.
>>>>> 
>>>>> Regarding modification, I think we could think about it. Let's try to
>>>>> encode them with the extended package first. Since we reify, would-it
>>>>> be possible to create something like species X is entity Y modified by Z?
>>>>> 
>>>>> On 17/01/11 11:32, Nick Juty wrote:
>>>>>> Hi Neil,
>>>>>> 
>>>>>> For the initial question, I would say we are more than happy to add
>>>>>> qualifiers upon request. Thats not a problem at all.
>>>>>> I do think, however, that we need to think carefully about what is an
>>>>>> appropriate qualifer. They should be providing information on semantics /
>>>>>> relationships. Specifically, I would have thought that SMILES would be
>>>>>> more
>>>>>> like a datatype, and so the subject of a MIRIAM Resources entry. Bear in
>>>>>> mind also that we plan to have a second branch in MIRIAM Resources to
>>>>>> handle those datatypes that are currently not able to be added for
>>>>>> whatever
>>>>>> reason. For modification, that sounds more like an SBO concept...
>>>>>> If I am getting the wrong end of the stick though, please let me know.
>>>>>> 
>>>>>> cheers
>>>>>> 
>>>>>> Nick
>>>>>> 
>>>>>> Neil Swainston wrote:
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> While we're at it, what are people's thoughts on adding new qualifiers?
>>>>>>> 
>>>>>>> For example, I and others would like concepts like formula, charge,
>>>>>>> SMILES, etc. and apply them to metabolites. "Modification" is another
>>>>>>> that occasionally arises for proteins.
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Neil.
>>>>>>> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...> wrote:
>>>>>>> 
>>>>>>>> On 14/01/11 14:25, Neil Swainston wrote:
>>>>>>>> 
>>>>>>>>> I think the goal is to recommend that the core annotations and "new"
>>>>>>>>> Annot annotations are used mutually exclusively. So, the core will use
>>>>>>>>> the old qualifiers and the Annot the new ones. In both cases, the
>>>>>>>>> qualifiers will be perennial.
>>>>>>>> Neil is correct. There won't be two schemes but only one scheme.
>>>>>>>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two
>>>>>>>> forms of the same qualifier. The definition on biomodels.net will just
>>>>>>>> be amended as follow:
>>>>>>>> 
>>>>>>>> hasPart, part
>>>>>>>> 
>>>>>>>> The biological entity represented by the model component includes the
>>>>>>>> subject of the referenced resource, either physically or logically. This
>>>>>>>> relation might be used to link a complex to the description of its
>>>>>>>> components.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>>>>>>>> in this I think that it would make sense to include a mapping from the
>>>>>>>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>>>>>>>> that was produced by Nick J recently).
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> Neil.
>>>>>>>>> 
>>>>>>>>> Neil Swainston Experimental Officer
>>>>>>>>> 
>>>>>>>>> Manchester Centre for Integrative Systems Biology Manchester
>>>>>>>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>>>>>>>> United Kingdom
>>>>>>>>> 
>>>>>>>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>>>>>>> 
>>>>>>>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>>>>>>>> going to be added, so that when reading a given model, a consumer can
>>>>>>>>>> figure out which qualifier scheme is being used? Or do you think it
>>>>>>>>>> won't be required, because the new terms will map one-to-one to the
>>>>>>>>>> old ones, and all a consumer would need to know is both terms for a
>>>>>>>>>> given relationship?
>>>>>>>>>> 
>>>>>>>>>> MH
>>>>>>>>>> 
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>>>>> malware threats, the impact they can have on your business, and how
>>>>>>>>>> you can protect your company and customers by using code signing.
>>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>>>>> _______________________________________________ Sbml-annot mailing
>>>>>>>>>> list Sbm...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>>>>> can protect your company and customers by using code signing.
>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>>>> _______________________________________________ Sbml-annot mailing list
>>>>>>>>> Sbm...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>>>> --
>>>>>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>>>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>>>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> 
>>>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>>>> can protect your company and customers by using code signing.
>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>>> _______________________________________________
>>>>>>>> Sbml-annot mailing list
>>>>>>>> Sbm...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> 
>>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>>> can protect your company and customers by using code signing.
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>> _______________________________________________
>>>>>>> Sbml-annot mailing list
>>>>>>> Sbm...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>> 
>>>>> --
>>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> BioModels.net Discussion Mailing List
>>>>> Bio...@li...
>>>>> Setting: https://lists.sourceforge.net/lists/listinfo/biomodels-net-discuss
>>>>> Website: http://www.biomodels.net
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>> 
> 
> 
> -- 
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
> 

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Nicolas Le n. <le...@eb...>]

Hi Neil,

But if the purpose is to cope with a given tool that is not supporting the 
whole specification of SBML (controlled RDF has been introduced in L2V2 in 
2005), is-it not a case for a proprietary annotation rather than bloating 
the common annotation scheme? If COBRA does not support SBML controlled and 
MIRIAM URIs, presumably, it does not support bq qualifiers as well. So 
adding the qualifiers would not change much. What you need would rather be 
an annotation in the COBRA namespace that replaces the notes of your 
example. Alternatively we could extend the scheme we used for InChIs.

Now, that led me to a reflexion that is a bit deeper than that, and I think 
it should be moved to sbml-discuss at some point.

Several times in the past, people have wanted to add metadata to SBML 
files, rather than pointers to metadata. This is the case with your 
example. FORMULA or CHARGE are not fundamentally different from SEQUENCE or 
STRUCTURE.

I wonder if the time has not come to design another metadata framework, 
parallel to the RDF one, which purpose would be to store the information 
together with the model. If we do that, we probably do not want to use 
elements such as <formular>, <charge>, <sequence> etc. However, we would 
like the element to be identifiers from MIRIAM Resources (NOT MIRIAM URNs, 
the identifiers of a data-type in MIRIAM Resources), PATO quality branch, 
the future BioDbCore etc. The spec would not list the elements, but the 
accepted source for the elements.

This is food for another L3 package.

On 17/01/11 14:19, Neil Swainston wrote:
> Hi Nick (and Nicolas - this covers your recent mail re: InChIs, too),
>
> You're right with this example - we do actually have a ChEBI identifier.
> Where possible, we attempt to add "unknown" metabolites to ChEBI, who
> curate and publish them super-quickly. (We have no problems with the speed
> of response of the ChEBI guys).
>
> The problem is a pragmatic one. These large models are analysed by software
> that lags behind what we're doing with annotations. An example is the COBRA
> Toolbox, which - like it or not - has become a well used tool for analysing
> genome-scale metabolic models. This has been written in Matlab by people
> who have no interest whatsoever in annotations. Their algorithms require
> access to formulae and charges and such like, and the writers of the
> software certainly wouldn't go to the effort of querying MIRIAM and ChEBI
> webservices in order to pick these up. So, if we relied on annotations
> alone, they simply wouldn't use the model, as it wouldn't (in their eyes)
> contain sufficient meta-data to allow them to run their analyses over.
>
> Although I can see that duplicating this info by specifying both a ChEBI
> id, and adding terms like formulae to the notes is a bit rubbish from a
> clean-and-proper sense, I think that we have to be realistic. Which is why
> (in this case) I support both crappy notes and semantic annotations.
>
> I believe, however, that there may be a middle-ground that would allow
> properties to be specified more formally without expecting developers of
> software packages to rely on querying web services to get these properties.
> Even if that is the better way of doing things, and what we're doing now is
> effectively warehousing some of the data from ChEBI. It's just a question
> of being realistic with where we are.
>
> Cheers,
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 17 Jan 2011, at 13:52, Nick Juty wrote:
>
>> Hi Neil,
>>
>> Couple of questions - I'm trying to figure out what you use this
>> information for...
>>
>> The example you have below contains much of the info that is held in a
>> ChEBI entry:
>> http://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:18090
>>
>> Are you, in effect, using the model file to store information in lieu of
>> that information being accessible through a MIRIAM identifier? Also, when
>> you find such entities (which have no associable database reference), do
>> you submit them to ChEBI for curation/incorporation? And if so, how long
>> do they take to appear, and do you subsequently remove them from your
>> files? Or alternatively, do you need this level of information for each
>> entity in your model?
>>
>> cheers
>>
>> Nick
>>
>>
>>
>>
>>
>>
>> Neil Swainston wrote:
>>> Hmm... interesting questions.
>>> I'm not sure that I know the answers, but I'll try.
>>> The reason that SMILES, InChIs, charges, etc. have come into my
>>> consciousness is that I'm currently wrestling with the human
>>> genome-scale model, in which we have a number of metabolites for which
>>> we *don't* have a KEGG or ChEBI identifier, but do know some properties
>>> of the molecule.
>>> We currently do this in a Palsson-friendly, COBRA-compatible way of
>>> specifying them in the notes:
>>> <species metaid="_meta_bamppald_c" id="_bamppald_c"
>>> name="beta-Aminopropion aldehyde" compartment="c" sboTerm="SBO:0000247">
>>> <notes>
>>> <body xmlns="http://www.w3.org/1999/xhtml">
>>> <p>NEUTRAL_FORMULA: C3H7NO</p>
>>> <p>FORMULA: C3H8NO</p>
>>> <p>CHARGE: 1</p>
>>> <p>INCHI: InChI=1/C3H7NO/c4-2-1-3-5/h3H,1-2,4H2</p>
>>> <p>ORIGIN: Recon 1</p>
>>> </body>
>>> </notes>
>>> Not ideal, but currently necessary, as we have no other means of
>>> specifying this. (Note that "charge" has been (correctly) dropped as an
>>> attribute of species, as it should be an annotation. An annotation that
>>> we currently can't express).
>>> This problem has also been encountered by Brett and Frank, and they
>>> propose a solution in their Flux package extension:
>>> http://precedings.nature.com/documents/4236/version/1/files/npre20104236-1.pdf
>>> To me at, least, it would be bad to have numerous ways of specifying a
>>> concept such as charge or formula in a number of package extensions.
>>> Also, for me, specifying the concept of SMILES in MIRIAM would not be
>>> the way to go. MIRIAM does an excellent job of collating and specifying
>>> identifiers, not properties. I would have thought that SMILES (or InChI
>>> or formula) would be a free text field, independent of MIRIAM
>>> identifiers, but with the semantic information that this free text
>>> actually represents a SMILES string (or whatever) being held in the
>>> predicate. To specify SMILES as a data type would mean that MIRIAM would
>>> have to enumerate all possible SMILES strings. It would make even less
>>> sense to enumerate all possible charges.
>>> Specifying...
>>> SPECIES has DESCRIPTION whose value is C6H6O6
>>> SPECIES has DESCRIPTION whose value is -1
>>> ...is ambiguous. What kind of description?
>>> Going back to what I wrote earlier about schema classes...
>>> http://www.w3.org/TR/rdf-primer/#schemaclasses
>>> ...this would give us the mechanism to describe the concept of a charge,
>>> and constrain it to be an integer, for example.
>>> By the way, I consider all this to be next generation stuff, so it
>>> shouldn't affect the first Annot package proposal, which I hope to send
>>> out to you all later in the week for more fireworks.
>>> Cheers,
>>> Neil.
>>> Neil Swainston
>>> Experimental Officer
>>> Manchester Centre for Integrative Systems Biology
>>> Manchester Interdisciplinary Biocentre
>>> University of Manchester
>>> Manchester M1 7DN
>>> United Kingdom
>>> On 17 Jan 2011, at 11:44, Nicolas Le novère wrote:
>>>> Indeed, we are adding qualifiers on a regular basis. Latest examples
>>>> are isDerivedFrom, hasProperty and isPropertyOf.
>>>>
>>>> I am worried about encoding particular qualities in qualifiers rather
>>>> than generic relationships though. A chemical isDescribedBy a SMILE. As
>>>> Nick pointed out, the SMILE itself would be a datatype if there was a
>>>> namespace associated. Alternatively, the SMILE can be stored in the
>>>> SBML file with a mechanism like the one proposed for InChIs. If we
>>>> create a qualifier SMILE, then we basically need to create a qualifier
>>>> for each entry of PATO as well.
>>>>
>>>> Regarding modification, I think we could think about it. Let's try to
>>>> encode them with the extended package first. Since we reify, would-it
>>>> be possible to create something like species X is entity Y modified by Z?
>>>>
>>>> On 17/01/11 11:32, Nick Juty wrote:
>>>>> Hi Neil,
>>>>>
>>>>> For the initial question, I would say we are more than happy to add
>>>>> qualifiers upon request. Thats not a problem at all.
>>>>> I do think, however, that we need to think carefully about what is an
>>>>> appropriate qualifer. They should be providing information on semantics /
>>>>> relationships. Specifically, I would have thought that SMILES would be
>>>>> more
>>>>> like a datatype, and so the subject of a MIRIAM Resources entry. Bear in
>>>>> mind also that we plan to have a second branch in MIRIAM Resources to
>>>>> handle those datatypes that are currently not able to be added for
>>>>> whatever
>>>>> reason. For modification, that sounds more like an SBO concept...
>>>>> If I am getting the wrong end of the stick though, please let me know.
>>>>>
>>>>> cheers
>>>>>
>>>>> Nick
>>>>>
>>>>> Neil Swainston wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> While we're at it, what are people's thoughts on adding new qualifiers?
>>>>>>
>>>>>> For example, I and others would like concepts like formula, charge,
>>>>>> SMILES, etc. and apply them to metabolites. "Modification" is another
>>>>>> that occasionally arises for proteins.
>>>>>> Thoughts?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Neil.
>>>>>> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...> wrote:
>>>>>>
>>>>>>> On 14/01/11 14:25, Neil Swainston wrote:
>>>>>>>
>>>>>>>> I think the goal is to recommend that the core annotations and "new"
>>>>>>>> Annot annotations are used mutually exclusively. So, the core will use
>>>>>>>> the old qualifiers and the Annot the new ones. In both cases, the
>>>>>>>> qualifiers will be perennial.
>>>>>>> Neil is correct. There won't be two schemes but only one scheme.
>>>>>>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two
>>>>>>> forms of the same qualifier. The definition on biomodels.net will just
>>>>>>> be amended as follow:
>>>>>>>
>>>>>>> hasPart, part
>>>>>>>
>>>>>>> The biological entity represented by the model component includes the
>>>>>>> subject of the referenced resource, either physically or logically. This
>>>>>>> relation might be used to link a complex to the description of its
>>>>>>> components.
>>>>>>>
>>>>>>>
>>>>>>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>>>>>>> in this I think that it would make sense to include a mapping from the
>>>>>>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>>>>>>> that was produced by Nick J recently).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Neil.
>>>>>>>>
>>>>>>>> Neil Swainston Experimental Officer
>>>>>>>>
>>>>>>>> Manchester Centre for Integrative Systems Biology Manchester
>>>>>>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>>>>>>> United Kingdom
>>>>>>>>
>>>>>>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>>>>>>
>>>>>>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>>>>>>> going to be added, so that when reading a given model, a consumer can
>>>>>>>>> figure out which qualifier scheme is being used? Or do you think it
>>>>>>>>> won't be required, because the new terms will map one-to-one to the
>>>>>>>>> old ones, and all a consumer would need to know is both terms for a
>>>>>>>>> given relationship?
>>>>>>>>>
>>>>>>>>> MH
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>>>> malware threats, the impact they can have on your business, and how
>>>>>>>>> you can protect your company and customers by using code signing.
>>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>>>> _______________________________________________ Sbml-annot mailing
>>>>>>>>> list Sbm...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>>>> can protect your company and customers by using code signing.
>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>>> _______________________________________________ Sbml-annot mailing list
>>>>>>>> Sbm...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>>> --
>>>>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>>> can protect your company and customers by using code signing.
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>> _______________________________________________
>>>>>>> Sbml-annot mailing list
>>>>>>> Sbm...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>> can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>> _______________________________________________
>>>>>> Sbml-annot mailing list
>>>>>> Sbm...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>
>>>> --
>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> BioModels.net Discussion Mailing List
>>>> Bio...@li...
>>>> Setting: https://lists.sourceforge.net/lists/listinfo/biomodels-net-discuss
>>>> Website: http://www.biomodels.net
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Neil S. <nei...@ma...>]

Hi Nick (and Nicolas - this covers your recent mail re: InChIs, too),

You're right with this example - we do actually have a ChEBI identifier. Where possible, we attempt to add "unknown" metabolites to ChEBI, who curate and publish them super-quickly. (We have no problems with the speed of response of the ChEBI guys).

The problem is a pragmatic one. These large models are analysed by software that lags behind what we're doing with annotations. An example is the COBRA Toolbox, which - like it or not - has become a well used tool for analysing genome-scale metabolic models. This has been written in Matlab by people who have no interest whatsoever in annotations. Their algorithms require access to formulae and charges and such like, and the writers of the software certainly wouldn't go to the effort of querying MIRIAM and ChEBI webservices in order to pick these up. So, if we relied on annotations alone, they simply wouldn't use the model, as it wouldn't (in their eyes) contain sufficient meta-data to allow them to run their analyses over.

Although I can see that duplicating this info by specifying both a ChEBI id, and adding terms like formulae to the notes is a bit rubbish from a clean-and-proper sense, I think that we have to be realistic. Which is why (in this case) I support both crappy notes and semantic annotations.

I believe, however, that there may be a middle-ground that would allow properties to be specified more formally without expecting developers of software packages to rely on querying web services to get these properties. Even if that is the better way of doing things, and what we're doing now is effectively warehousing some of the data from ChEBI. It's just a question of being realistic with where we are.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 13:52, Nick Juty wrote:

> Hi Neil,
> 
> Couple of questions - I'm trying to figure out what you use this information for...
> 
> The example you have below contains much of the info that is held in a ChEBI entry:
> http://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:18090
> 
> Are you, in effect, using the model file to store information in lieu of that information being accessible through a MIRIAM identifier? Also, when you find such entities (which have no associable database reference), do you submit them to ChEBI for curation/incorporation? And if so, how long do they take to appear, and do you subsequently remove them from your files? Or alternatively, do you need this level of information for each entity in your model?
> 
> cheers
> 
> Nick
> 
> 
> 
> 
> 
> 
> Neil Swainston wrote:
>> Hmm... interesting questions.
>> I'm not sure that I know the answers, but I'll try.
>> The reason that SMILES, InChIs, charges, etc. have come into my consciousness is that I'm currently wrestling with the human genome-scale model, in which we have a number of metabolites for which we *don't* have a KEGG or ChEBI identifier, but do know some properties of the molecule.
>> We currently do this in a Palsson-friendly, COBRA-compatible way of specifying them in the notes:
>>      <species metaid="_meta_bamppald_c" id="_bamppald_c" name="beta-Aminopropion aldehyde" compartment="c" sboTerm="SBO:0000247">
>>        <notes>
>>          <body xmlns="http://www.w3.org/1999/xhtml">
>>            <p>NEUTRAL_FORMULA: C3H7NO</p>
>>            <p>FORMULA: C3H8NO</p>
>>            <p>CHARGE: 1</p>
>>            <p>INCHI: InChI=1/C3H7NO/c4-2-1-3-5/h3H,1-2,4H2</p>
>>            <p>ORIGIN: Recon 1</p>
>>          </body>
>>        </notes>
>> Not ideal, but currently necessary, as we have no other means of specifying this. (Note that "charge" has been (correctly) dropped as an attribute of species, as it should be an annotation. An annotation that we currently can't express).
>> This problem has also been encountered by Brett and Frank, and they propose a solution in their Flux package extension:
>> http://precedings.nature.com/documents/4236/version/1/files/npre20104236-1.pdf
>> To me at, least, it would be bad to have numerous ways of specifying a concept such as charge or formula in a number of package extensions.
>> Also, for me, specifying the concept of SMILES in MIRIAM would not be the way to go. MIRIAM does an excellent job of collating and specifying identifiers, not properties. I would have thought that SMILES (or InChI or formula) would be a free text field, independent of MIRIAM identifiers, but with the semantic information that this free text actually represents a SMILES string (or whatever) being held in the predicate. To specify SMILES as a data type would mean that MIRIAM would have to enumerate all possible SMILES strings. It would make even less sense to enumerate all possible charges.
>> Specifying...
>> SPECIES has DESCRIPTION whose value is C6H6O6
>> SPECIES has DESCRIPTION whose value is -1
>> ...is ambiguous. What kind of description?
>> Going back to what I wrote earlier about schema classes...
>> http://www.w3.org/TR/rdf-primer/#schemaclasses
>> ...this would give us the mechanism to describe the concept of a charge, and constrain it to be an integer, for example.
>> By the way, I consider all this to be next generation stuff, so it shouldn't affect the first Annot package proposal, which I hope to send out to you all later in the week for more fireworks.
>> Cheers,
>> Neil.
>> Neil Swainston
>> Experimental Officer
>> Manchester Centre for Integrative Systems Biology
>> Manchester Interdisciplinary Biocentre
>> University of Manchester
>> Manchester M1 7DN
>> United Kingdom
>> On 17 Jan 2011, at 11:44, Nicolas Le novère wrote:
>>> Indeed, we are adding qualifiers on a regular basis. Latest examples are isDerivedFrom, hasProperty and isPropertyOf.
>>> 
>>> I am worried about encoding particular qualities in qualifiers rather than generic relationships though. A chemical isDescribedBy a SMILE. As Nick pointed out, the SMILE itself would be a datatype if there was a namespace associated. Alternatively, the SMILE can be stored in the SBML file with a mechanism like the one proposed for InChIs. If we create a qualifier SMILE, then we basically need to create a qualifier for each entry of PATO as well.
>>> 
>>> Regarding modification, I think we could think about it. Let's try to encode them with the extended package first. Since we reify, would-it be possible to create something like species X is entity Y modified by Z?
>>> 
>>> On 17/01/11 11:32, Nick Juty wrote:
>>>> Hi Neil,
>>>> 
>>>> For the initial question, I would say we are more than happy to add
>>>> qualifiers upon request. Thats not a problem at all.
>>>> I do think, however, that we need to think carefully about what is an
>>>> appropriate qualifer. They should be providing information on semantics /
>>>> relationships. Specifically, I would have thought that SMILES would be more
>>>> like a datatype, and so the subject of a MIRIAM Resources entry. Bear in
>>>> mind also that we plan to have a second branch in MIRIAM Resources to
>>>> handle those datatypes that are currently not able to be added for whatever
>>>> reason. For modification, that sounds more like an SBO concept...
>>>> If I am getting the wrong end of the stick though, please let me know.
>>>> 
>>>> cheers
>>>> 
>>>> Nick
>>>> 
>>>> Neil Swainston wrote:
>>>>> Hi all,
>>>>> 
>>>>> While we're at it, what are people's thoughts on adding new qualifiers?
>>>>> 
>>>>> For example, I and others would like concepts like formula, charge,
>>>>> SMILES, etc. and apply them to metabolites. "Modification" is another
>>>>> that occasionally arises for proteins.
>>>>> Thoughts?
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Neil.
>>>>> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...> wrote:
>>>>> 
>>>>>> On 14/01/11 14:25, Neil Swainston wrote:
>>>>>> 
>>>>>>> I think the goal is to recommend that the core annotations and "new"
>>>>>>> Annot annotations are used mutually exclusively. So, the core will use
>>>>>>> the old qualifiers and the Annot the new ones. In both cases, the
>>>>>>> qualifiers will be perennial.
>>>>>> Neil is correct. There won't be two schemes but only one scheme.
>>>>>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two
>>>>>> forms of the same qualifier. The definition on biomodels.net will just
>>>>>> be amended as follow:
>>>>>> 
>>>>>> hasPart, part
>>>>>> 
>>>>>> The biological entity represented by the model component includes the
>>>>>> subject of the referenced resource, either physically or logically. This
>>>>>> relation might be used to link a complex to the description of its
>>>>>> components.
>>>>>> 
>>>>>> 
>>>>>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>>>>>> in this I think that it would make sense to include a mapping from the
>>>>>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>>>>>> that was produced by Nick J recently).
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Neil.
>>>>>>> 
>>>>>>> Neil Swainston Experimental Officer
>>>>>>> 
>>>>>>> Manchester Centre for Integrative Systems Biology Manchester
>>>>>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>>>>>> United Kingdom
>>>>>>> 
>>>>>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>>>>> 
>>>>>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>>>>>> going to be added, so that when reading a given model, a consumer can
>>>>>>>> figure out which qualifier scheme is being used? Or do you think it
>>>>>>>> won't be required, because the new terms will map one-to-one to the
>>>>>>>> old ones, and all a consumer would need to know is both terms for a
>>>>>>>> given relationship?
>>>>>>>> 
>>>>>>>> MH
>>>>>>>> 
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>>> malware threats, the impact they can have on your business, and how
>>>>>>>> you can protect your company and customers by using code signing.
>>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>>> _______________________________________________ Sbml-annot mailing
>>>>>>>> list Sbm...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>>> can protect your company and customers by using code signing.
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>> _______________________________________________ Sbml-annot mailing list
>>>>>>> Sbm...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>> --
>>>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> 
>>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>> can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>> _______________________________________________
>>>>>> Sbml-annot mailing list
>>>>>> Sbm...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>> ------------------------------------------------------------------------------
>>>>> 
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> Sbml-annot mailing list
>>>>> Sbm...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>> 
>>> -- 
>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> BioModels.net Discussion Mailing List
>>> Bio...@li...
>>> Setting: https://lists.sourceforge.net/lists/listinfo/biomodels-net-discuss
>>> Website: http://www.biomodels.net
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Nicolas Le n. <le...@eb...>]

On 17/01/11 12:22, Neil Swainston wrote:
> Hmm... interesting questions.
>
> I'm not sure that I know the answers, but I'll try.
>
> The reason that SMILES, InChIs, charges, etc. have come into my
> consciousness is that I'm currently wrestling with the human genome-scale
> model, in which we have a number of metabolites for which we *don't* have a
> KEGG or ChEBI identifier, but do know some properties of the molecule.

Did-you consider using something like:
http://sbml.org/Community/Wiki/About_annotations_in_Level_2#How_do_I_put_InChI_strings_in_annotations.3F

?


PS: Did-you submit the request to include those metabolites in ChEBI? They 
also may be there already, but uncurated.

BTW, your example is in ChEBI, but is called 3-aminopropanal
CHEBI:18090
http://www.ebi.ac.uk/chebi/advancedSearchFT.do?searchString=1%2FC3H7NO%2Fc4-2-1-3-5%2Fh3H%2C1-2%2C4H2&queryBean.stars=3&queryBean.stars=-1


> We currently do this in a Palsson-friendly, COBRA-compatible way of
> specifying them in the notes:
>
> <species metaid="_meta_bamppald_c"id="_bamppald_c"name="beta-Aminopropion
> aldehyde"compartment="c"sboTerm="SBO:0000247">
> <notes>
> <body xmlns="http://www.w3.org/1999/xhtml">
> <p>NEUTRAL_FORMULA: C3H7NO</p>
> <p>FORMULA: C3H8NO</p>
> <p>CHARGE: 1</p>
> <p>INCHI: InChI=1/C3H7NO/c4-2-1-3-5/h3H,1-2,4H2</p>
> <p>ORIGIN: Recon 1</p>
> </body>
> </notes>
>
> Not ideal, but currently necessary, as we have no other means of specifying
> this. (Note that "charge" has been (correctly) dropped as an attribute of
> species, as it should be an annotation. An annotation that we currently
> can't express).
>
> This problem has also been encountered by Brett and Frank, and they propose
> a solution in their Flux package extension:
>
> http://precedings.nature.com/documents/4236/version/1/files/npre20104236-1.pdf
>
> To me at, least, it would be bad to have numerous ways of specifying a
> concept such as charge or formula in a number of package extensions.
>
> Also, for me, specifying the concept of SMILES in MIRIAM would not be the
> way to go. MIRIAM does an excellent job of collating and specifying
> identifiers, not properties. I would have thought that SMILES (or InChI or
> formula) would be a free text field, independent of MIRIAM identifiers, but
> with the semantic information that this free text actually represents a
> SMILES string (or whatever) being held in the predicate. To specify SMILES
> as a data type would mean that MIRIAM would have to enumerate all possible
> SMILES strings. It would make even less sense to enumerate all possible
> charges.
>
> Specifying...
>
> SPECIES has DESCRIPTION whose value is C6H6O6
> SPECIES has DESCRIPTION whose value is -1
>
> ...is ambiguous. What kind of description?
>
> Going back to what I wrote earlier about schema classes...
>
> http://www.w3.org/TR/rdf-primer/#schemaclasses
>
> <http://www.w3.org/TR/rdf-primer/#schemaclasses>...this would give us the
> mechanism to describe the concept of a charge, and constrain it to be an
> integer, for example.
>
> By the way, I consider all this to be next generation stuff, so it
> shouldn't affect the first Annot package proposal, which I hope to send out
> to you all later in the week for more fireworks.
>
> Cheers,
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 17 Jan 2011, at 11:44, Nicolas Le novère wrote:
>
>> Indeed, we are adding qualifiers on a regular basis. Latest examples are
>> isDerivedFrom, hasProperty and isPropertyOf.
>>
>> I am worried about encoding particular qualities in qualifiers rather than
>> generic relationships though. A chemical isDescribedBy a SMILE. As Nick
>> pointed out, the SMILE itself would be a datatype if there was a namespace
>> associated. Alternatively, the SMILE can be stored in the SBML file with a
>> mechanism like the one proposed for InChIs. If we create a qualifier SMILE,
>> then we basically need to create a qualifier for each entry of PATO as well.
>>
>> Regarding modification, I think we could think about it. Let's try to
>> encode them with the extended package first. Since we reify, would-it be
>> possible to create something like species X is entity Y modified by Z?
>>
>> On 17/01/11 11:32, Nick Juty wrote:
>>> Hi Neil,
>>>
>>> For the initial question, I would say we are more than happy to add
>>> qualifiers upon request. Thats not a problem at all.
>>> I do think, however, that we need to think carefully about what is an
>>> appropriate qualifer. They should be providing information on semantics /
>>> relationships. Specifically, I would have thought that SMILES would be more
>>> like a datatype, and so the subject of a MIRIAM Resources entry. Bear in
>>> mind also that we plan to have a second branch in MIRIAM Resources to
>>> handle those datatypes that are currently not able to be added for whatever
>>> reason. For modification, that sounds more like an SBO concept...
>>> If I am getting the wrong end of the stick though, please let me know.
>>>
>>> cheers
>>>
>>> Nick
>>>
>>> Neil Swainston wrote:
>>>> Hi all,
>>>>
>>>> While we're at it, what are people's thoughts on adding new qualifiers?
>>>>
>>>> For example, I and others would like concepts like formula, charge,
>>>> SMILES, etc. and apply them to metabolites. "Modification" is another
>>>> that occasionally arises for proteins.
>>>> Thoughts?
>>>>
>>>> Cheers,
>>>>
>>>> Neil.
>>>> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...
>>>> <mailto:le...@eb...>> wrote:
>>>>
>>>>> On 14/01/11 14:25, Neil Swainston wrote:
>>>>>
>>>>>> I think the goal is to recommend that the core annotations and "new"
>>>>>> Annot annotations are used mutually exclusively. So, the core will use
>>>>>> the old qualifiers and the Annot the new ones. In both cases, the
>>>>>> qualifiers will be perennial.
>>>>> Neil is correct. There won't be two schemes but only one scheme.
>>>>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two
>>>>> forms of the same qualifier. The definition on biomodels.net
>>>>> <http://biomodels.net> will just
>>>>> be amended as follow:
>>>>>
>>>>> hasPart, part
>>>>>
>>>>> The biological entity represented by the model component includes the
>>>>> subject of the referenced resource, either physically or logically. This
>>>>> relation might be used to link a complex to the description of its
>>>>> components.
>>>>>
>>>>>
>>>>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>>>>> in this I think that it would make sense to include a mapping from the
>>>>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>>>>> that was produced by Nick J recently).
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Neil.
>>>>>>
>>>>>> Neil Swainston Experimental Officer
>>>>>>
>>>>>> Manchester Centre for Integrative Systems Biology Manchester
>>>>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>>>>> United Kingdom
>>>>>>
>>>>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>>>>
>>>>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>>>>> going to be added, so that when reading a given model, a consumer can
>>>>>>> figure out which qualifier scheme is being used? Or do you think it
>>>>>>> won't be required, because the new terms will map one-to-one to the
>>>>>>> old ones, and all a consumer would need to know is both terms for a
>>>>>>> given relationship?
>>>>>>>
>>>>>>> MH
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>> malware threats, the impact they can have on your business, and how
>>>>>>> you can protect your company and customers by using code signing.
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>> _______________________________________________ Sbml-annot mailing
>>>>>>> list Sbm...@li...
>>>>>>> <mailto:Sbm...@li...>
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>> can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>> _______________________________________________ Sbml-annot mailing list
>>>>>> Sbm...@li...
>>>>>> <mailto:Sbm...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>
>>>>> --
>>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> Sbml-annot mailing list
>>>>> Sbm...@li... <mailto:Sbm...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li... <mailto:Sbm...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>
>>
>> --
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> BioModels.net Discussion Mailing List
>> Bio...@li...
>> Setting: https://lists.sourceforge.net/lists/listinfo/biomodels-net-discuss
>> Website: http://www.biomodels.net
>


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Nick J. <ju...@eb...>]

Hi Neil,

Couple of questions - I'm trying to figure out what you use this information for...

The example you have below contains much of the info that is held in a ChEBI entry:
http://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:18090

Are you, in effect, using the model file to store information in lieu of that information being accessible through a MIRIAM identifier? Also, when you 
find such entities (which have no associable database reference), do you submit them to ChEBI for curation/incorporation? And if so, how long do they 
take to appear, and do you subsequently remove them from your files? Or alternatively, do you need this level of information for each entity in your 
model?

cheers

Nick






Neil Swainston wrote:
> Hmm... interesting questions.
> 
> I'm not sure that I know the answers, but I'll try.
> 
> The reason that SMILES, InChIs, charges, etc. have come into my consciousness is that I'm currently wrestling with the human genome-scale model, in which we have a number of metabolites for which we *don't* have a KEGG or ChEBI identifier, but do know some properties of the molecule.
> 
> We currently do this in a Palsson-friendly, COBRA-compatible way of specifying them in the notes:
> 
>       <species metaid="_meta_bamppald_c" id="_bamppald_c" name="beta-Aminopropion aldehyde" compartment="c" sboTerm="SBO:0000247">
>         <notes>
>           <body xmlns="http://www.w3.org/1999/xhtml">
>             <p>NEUTRAL_FORMULA: C3H7NO</p>
>             <p>FORMULA: C3H8NO</p>
>             <p>CHARGE: 1</p>
>             <p>INCHI: InChI=1/C3H7NO/c4-2-1-3-5/h3H,1-2,4H2</p>
>             <p>ORIGIN: Recon 1</p>
>           </body>
>         </notes>
> 
> Not ideal, but currently necessary, as we have no other means of specifying this. (Note that "charge" has been (correctly) dropped as an attribute of species, as it should be an annotation. An annotation that we currently can't express).
> 
> This problem has also been encountered by Brett and Frank, and they propose a solution in their Flux package extension:
> 
> http://precedings.nature.com/documents/4236/version/1/files/npre20104236-1.pdf
> 
> To me at, least, it would be bad to have numerous ways of specifying a concept such as charge or formula in a number of package extensions.
> 
> Also, for me, specifying the concept of SMILES in MIRIAM would not be the way to go. MIRIAM does an excellent job of collating and specifying identifiers, not properties. I would have thought that SMILES (or InChI or formula) would be a free text field, independent of MIRIAM identifiers, but with the semantic information that this free text actually represents a SMILES string (or whatever) being held in the predicate. To specify SMILES as a data type would mean that MIRIAM would have to enumerate all possible SMILES strings. It would make even less sense to enumerate all possible charges.
> 
> Specifying...
> 
> SPECIES has DESCRIPTION whose value is C6H6O6
> SPECIES has DESCRIPTION whose value is -1
> 
> ...is ambiguous. What kind of description?
> 
> Going back to what I wrote earlier about schema classes...
> 
> http://www.w3.org/TR/rdf-primer/#schemaclasses
> 
> ...this would give us the mechanism to describe the concept of a charge, and constrain it to be an integer, for example.
> 
> By the way, I consider all this to be next generation stuff, so it shouldn't affect the first Annot package proposal, which I hope to send out to you all later in the week for more fireworks.
> 
> Cheers,
> 
> Neil.
> 
> Neil Swainston
> Experimental Officer
> 
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
> 
> On 17 Jan 2011, at 11:44, Nicolas Le novère wrote:
> 
>> Indeed, we are adding qualifiers on a regular basis. Latest examples are 
>> isDerivedFrom, hasProperty and isPropertyOf.
>>
>> I am worried about encoding particular qualities in qualifiers rather than 
>> generic relationships though. A chemical isDescribedBy a SMILE. As Nick 
>> pointed out, the SMILE itself would be a datatype if there was a namespace 
>> associated. Alternatively, the SMILE can be stored in the SBML file with a 
>> mechanism like the one proposed for InChIs. If we create a qualifier SMILE, 
>> then we basically need to create a qualifier for each entry of PATO as well.
>>
>> Regarding modification, I think we could think about it. Let's try to 
>> encode them with the extended package first. Since we reify, would-it be 
>> possible to create something like species X is entity Y modified by Z?
>>
>> On 17/01/11 11:32, Nick Juty wrote:
>>> Hi Neil,
>>>
>>> For the initial question, I would say we are more than happy to add
>>> qualifiers upon request. Thats not a problem at all.
>>> I do think, however, that we need to think carefully about what is an
>>> appropriate qualifer. They should be providing information on semantics /
>>> relationships. Specifically, I would have thought that SMILES would be more
>>> like a datatype, and so the subject of a MIRIAM Resources entry. Bear in
>>> mind also that we plan to have a second branch in MIRIAM Resources to
>>> handle those datatypes that are currently not able to be added for whatever
>>> reason. For modification, that sounds more like an SBO concept...
>>> If I am getting the wrong end of the stick though, please let me know.
>>>
>>> cheers
>>>
>>> Nick
>>>
>>> Neil Swainston wrote:
>>>> Hi all,
>>>>
>>>> While we're at it, what are people's thoughts on adding new qualifiers?
>>>>
>>>> For example, I and others would like concepts like formula, charge,
>>>> SMILES, etc. and apply them to metabolites. "Modification" is another
>>>> that occasionally arises for proteins.
>>>> Thoughts?
>>>>
>>>> Cheers,
>>>>
>>>> Neil.
>>>> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...> wrote:
>>>>
>>>>> On 14/01/11 14:25, Neil Swainston wrote:
>>>>>
>>>>>> I think the goal is to recommend that the core annotations and "new"
>>>>>> Annot annotations are used mutually exclusively. So, the core will use
>>>>>> the old qualifiers and the Annot the new ones. In both cases, the
>>>>>> qualifiers will be perennial.
>>>>> Neil is correct. There won't be two schemes but only one scheme.
>>>>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two
>>>>> forms of the same qualifier. The definition on biomodels.net will just
>>>>> be amended as follow:
>>>>>
>>>>> hasPart, part
>>>>>
>>>>> The biological entity represented by the model component includes the
>>>>> subject of the referenced resource, either physically or logically. This
>>>>> relation might be used to link a complex to the description of its
>>>>> components.
>>>>>
>>>>>
>>>>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>>>>> in this I think that it would make sense to include a mapping from the
>>>>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>>>>> that was produced by Nick J recently).
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Neil.
>>>>>>
>>>>>> Neil Swainston Experimental Officer
>>>>>>
>>>>>> Manchester Centre for Integrative Systems Biology Manchester
>>>>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>>>>> United Kingdom
>>>>>>
>>>>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>>>>
>>>>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>>>>> going to be added, so that when reading a given model, a consumer can
>>>>>>> figure out which qualifier scheme is being used? Or do you think it
>>>>>>> won't be required, because the new terms will map one-to-one to the
>>>>>>> old ones, and all a consumer would need to know is both terms for a
>>>>>>> given relationship?
>>>>>>>
>>>>>>> MH
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>>> malware threats, the impact they can have on your business, and how
>>>>>>> you can protect your company and customers by using code signing.
>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>>> _______________________________________________ Sbml-annot mailing
>>>>>>> list Sbm...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>> malware threats, the impact they can have on your business, and how you
>>>>>> can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>> _______________________________________________ Sbml-annot mailing list
>>>>>> Sbm...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>> --
>>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________
>>>>> Sbml-annot mailing list
>>>>> Sbm...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>
>> -- 
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> BioModels.net Discussion Mailing List
>> Bio...@li...
>> Setting: https://lists.sourceforge.net/lists/listinfo/biomodels-net-discuss
>> Website: http://www.biomodels.net
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] [Biomodels-net-discuss] BioModels.net qualifier discussion

[Neil S. <nei...@ma...>]

Hmm... interesting questions.

I'm not sure that I know the answers, but I'll try.

The reason that SMILES, InChIs, charges, etc. have come into my consciousness is that I'm currently wrestling with the human genome-scale model, in which we have a number of metabolites for which we *don't* have a KEGG or ChEBI identifier, but do know some properties of the molecule.

We currently do this in a Palsson-friendly, COBRA-compatible way of specifying them in the notes:

      <species metaid="_meta_bamppald_c" id="_bamppald_c" name="beta-Aminopropion aldehyde" compartment="c" sboTerm="SBO:0000247">
        <notes>
          <body xmlns="http://www.w3.org/1999/xhtml">
            <p>NEUTRAL_FORMULA: C3H7NO</p>
            <p>FORMULA: C3H8NO</p>
            <p>CHARGE: 1</p>
            <p>INCHI: InChI=1/C3H7NO/c4-2-1-3-5/h3H,1-2,4H2</p>
            <p>ORIGIN: Recon 1</p>
          </body>
        </notes>

Not ideal, but currently necessary, as we have no other means of specifying this. (Note that "charge" has been (correctly) dropped as an attribute of species, as it should be an annotation. An annotation that we currently can't express).

This problem has also been encountered by Brett and Frank, and they propose a solution in their Flux package extension:

http://precedings.nature.com/documents/4236/version/1/files/npre20104236-1.pdf

To me at, least, it would be bad to have numerous ways of specifying a concept such as charge or formula in a number of package extensions.

Also, for me, specifying the concept of SMILES in MIRIAM would not be the way to go. MIRIAM does an excellent job of collating and specifying identifiers, not properties. I would have thought that SMILES (or InChI or formula) would be a free text field, independent of MIRIAM identifiers, but with the semantic information that this free text actually represents a SMILES string (or whatever) being held in the predicate. To specify SMILES as a data type would mean that MIRIAM would have to enumerate all possible SMILES strings. It would make even less sense to enumerate all possible charges.

Specifying...

SPECIES has DESCRIPTION whose value is C6H6O6
SPECIES has DESCRIPTION whose value is -1

...is ambiguous. What kind of description?

Going back to what I wrote earlier about schema classes...

http://www.w3.org/TR/rdf-primer/#schemaclasses

...this would give us the mechanism to describe the concept of a charge, and constrain it to be an integer, for example.

By the way, I consider all this to be next generation stuff, so it shouldn't affect the first Annot package proposal, which I hope to send out to you all later in the week for more fireworks.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 11:44, Nicolas Le novère wrote:

> Indeed, we are adding qualifiers on a regular basis. Latest examples are 
> isDerivedFrom, hasProperty and isPropertyOf.
> 
> I am worried about encoding particular qualities in qualifiers rather than 
> generic relationships though. A chemical isDescribedBy a SMILE. As Nick 
> pointed out, the SMILE itself would be a datatype if there was a namespace 
> associated. Alternatively, the SMILE can be stored in the SBML file with a 
> mechanism like the one proposed for InChIs. If we create a qualifier SMILE, 
> then we basically need to create a qualifier for each entry of PATO as well.
> 
> Regarding modification, I think we could think about it. Let's try to 
> encode them with the extended package first. Since we reify, would-it be 
> possible to create something like species X is entity Y modified by Z?
> 
> On 17/01/11 11:32, Nick Juty wrote:
>> Hi Neil,
>> 
>> For the initial question, I would say we are more than happy to add
>> qualifiers upon request. Thats not a problem at all.
>> I do think, however, that we need to think carefully about what is an
>> appropriate qualifer. They should be providing information on semantics /
>> relationships. Specifically, I would have thought that SMILES would be more
>> like a datatype, and so the subject of a MIRIAM Resources entry. Bear in
>> mind also that we plan to have a second branch in MIRIAM Resources to
>> handle those datatypes that are currently not able to be added for whatever
>> reason. For modification, that sounds more like an SBO concept...
>> If I am getting the wrong end of the stick though, please let me know.
>> 
>> cheers
>> 
>> Nick
>> 
>> Neil Swainston wrote:
>>> Hi all,
>>> 
>>> While we're at it, what are people's thoughts on adding new qualifiers?
>>> 
>>> For example, I and others would like concepts like formula, charge,
>>> SMILES, etc. and apply them to metabolites. "Modification" is another
>>> that occasionally arises for proteins.
>>> Thoughts?
>>> 
>>> Cheers,
>>> 
>>> Neil.
>>> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...> wrote:
>>> 
>>>> On 14/01/11 14:25, Neil Swainston wrote:
>>>> 
>>>>> I think the goal is to recommend that the core annotations and "new"
>>>>> Annot annotations are used mutually exclusively. So, the core will use
>>>>> the old qualifiers and the Annot the new ones. In both cases, the
>>>>> qualifiers will be perennial.
>>>> Neil is correct. There won't be two schemes but only one scheme.
>>>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two
>>>> forms of the same qualifier. The definition on biomodels.net will just
>>>> be amended as follow:
>>>> 
>>>> hasPart, part
>>>> 
>>>> The biological entity represented by the model component includes the
>>>> subject of the referenced resource, either physically or logically. This
>>>> relation might be used to link a complex to the description of its
>>>> components.
>>>> 
>>>> 
>>>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>>>> in this I think that it would make sense to include a mapping from the
>>>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>>>> that was produced by Nick J recently).
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Neil.
>>>>> 
>>>>> Neil Swainston Experimental Officer
>>>>> 
>>>>> Manchester Centre for Integrative Systems Biology Manchester
>>>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>>>> United Kingdom
>>>>> 
>>>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>>> 
>>>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>>>> going to be added, so that when reading a given model, a consumer can
>>>>>> figure out which qualifier scheme is being used? Or do you think it
>>>>>> won't be required, because the new terms will map one-to-one to the
>>>>>> old ones, and all a consumer would need to know is both terms for a
>>>>>> given relationship?
>>>>>> 
>>>>>> MH
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> 
>>>>>> 
>>>>>> 
>>>> Protect Your Site and Customers from Malware Attacks
>>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>>> malware threats, the impact they can have on your business, and how
>>>>>> you can protect your company and customers by using code signing.
>>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>>> _______________________________________________ Sbml-annot mailing
>>>>>> list Sbm...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>>> ------------------------------------------------------------------------------
>>>>> 
>>>>> 
>>>>> 
>>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how you
>>>>> can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________ Sbml-annot mailing list
>>>>> Sbm...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>> 
>>>> --
>>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> 
>>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________
>>>> Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>> 
>>> ------------------------------------------------------------------------------
>>> 
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
> 
> 
> -- 
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
> 
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> BioModels.net Discussion Mailing List
> Bio...@li...
> Setting: https://lists.sourceforge.net/lists/listinfo/biomodels-net-discuss
> Website: http://www.biomodels.net

Re: [sbml-annot] BioModels.net qualifier discussion

[Nicolas Le n. <le...@eb...>]

Indeed, we are adding qualifiers on a regular basis. Latest examples are 
isDerivedFrom, hasProperty and isPropertyOf.

I am worried about encoding particular qualities in qualifiers rather than 
generic relationships though. A chemical isDescribedBy a SMILE. As Nick 
pointed out, the SMILE itself would be a datatype if there was a namespace 
associated. Alternatively, the SMILE can be stored in the SBML file with a 
mechanism like the one proposed for InChIs. If we create a qualifier SMILE, 
then we basically need to create a qualifier for each entry of PATO as well.

Regarding modification, I think we could think about it. Let's try to 
encode them with the extended package first. Since we reify, would-it be 
possible to create something like species X is entity Y modified by Z?

On 17/01/11 11:32, Nick Juty wrote:
> Hi Neil,
>
> For the initial question, I would say we are more than happy to add
> qualifiers upon request. Thats not a problem at all.
> I do think, however, that we need to think carefully about what is an
> appropriate qualifer. They should be providing information on semantics /
> relationships. Specifically, I would have thought that SMILES would be more
> like a datatype, and so the subject of a MIRIAM Resources entry. Bear in
> mind also that we plan to have a second branch in MIRIAM Resources to
> handle those datatypes that are currently not able to be added for whatever
> reason. For modification, that sounds more like an SBO concept...
> If I am getting the wrong end of the stick though, please let me know.
>
> cheers
>
> Nick
>
> Neil Swainston wrote:
>> Hi all,
>>
>> While we're at it, what are people's thoughts on adding new qualifiers?
>>
>> For example, I and others would like concepts like formula, charge,
>> SMILES, etc. and apply them to metabolites. "Modification" is another
>> that occasionally arises for proteins.
>> Thoughts?
>>
>> Cheers,
>>
>> Neil.
>> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...> wrote:
>>
>>> On 14/01/11 14:25, Neil Swainston wrote:
>>>
>>>> I think the goal is to recommend that the core annotations and "new"
>>>> Annot annotations are used mutually exclusively. So, the core will use
>>>> the old qualifiers and the Annot the new ones. In both cases, the
>>>> qualifiers will be perennial.
>>> Neil is correct. There won't be two schemes but only one scheme.
>>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two
>>> forms of the same qualifier. The definition on biomodels.net will just
>>> be amended as follow:
>>>
>>> hasPart, part
>>>
>>> The biological entity represented by the model component includes the
>>> subject of the referenced resource, either physically or logically. This
>>> relation might be used to link a complex to the description of its
>>> components.
>>>
>>>
>>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>>> in this I think that it would make sense to include a mapping from the
>>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>>> that was produced by Nick J recently).
>>>>
>>>> Cheers,
>>>>
>>>> Neil.
>>>>
>>>> Neil Swainston Experimental Officer
>>>>
>>>> Manchester Centre for Integrative Systems Biology Manchester
>>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>>> United Kingdom
>>>>
>>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>>
>>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>>> going to be added, so that when reading a given model, a consumer can
>>>>> figure out which qualifier scheme is being used? Or do you think it
>>>>> won't be required, because the new terms will map one-to-one to the
>>>>> old ones, and all a consumer would need to know is both terms for a
>>>>> given relationship?
>>>>>
>>>>> MH
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>> Protect Your Site and Customers from Malware Attacks
>>>>> Learn about various malware tactics and how to avoid them. Understand
>>>>> malware threats, the impact they can have on your business, and how
>>>>> you can protect your company and customers by using code signing.
>>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>> _______________________________________________ Sbml-annot mailing
>>>>> list Sbm...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how you
>>>> can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________ Sbml-annot mailing list
>>>> Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>>
>>> --
>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________
>>> Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>
>> ------------------------------------------------------------------------------
>>
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand
>> malware threats, the impact they can have on your business, and how you
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [sbml-annot] BioModels.net qualifier discussion

[Neil S. <nei...@ma...>]

Hi Christian,

Actually, this isn't the RDF way. The RDF way specifies the predicates as nouns (properties of the subject), allowing the possibility of generating a schema describing the relationships between predicates, hierarchies of predicates, and properties of predicates.

Take a look at: http://www.w3.org/TR/rdf-primer/#schemaclasses

Effectively, the approach is to apply an object-orientated approach to defining predicates, with the analogy that a predicate can be defined as a Java (or C++) class is, with properties, inheritance, encapsulation, etc.

If we stick to the verb way of doing things, we're both breaking the rules of RDF (which I don't care about) but also preventing ourselves from exploiting all of the richer features of defining schemas around our predicates (which I do care about, as they may come in handy some day).

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 17 Jan 2011, at 11:26, Christian Knuepfer wrote:

> On 13.01.2011 14:23, Nick Juty wrote:
>> I thought it would be worth opening up the discussion about BioModels.net qualifiers, in order to start moving forward more earnestly.
>> The premise is that we wish to have qualifiers that follow the "SUBJECT has PREDICATE whose value is OBJECT" statement, and thereby need to convert or
>> add additional qualifiers as nouns, rather than the existing situation where they are verbs.
>> 
> What is the reason for this wish? I'm totally fine with verbs as 
> qualifiers. In my view there are predicates and facts should be:
> 
> "SUBJECT PREDICATE OBJECT"
> 
> This is the RDF way and I always thought that the qualifiers are to be 
> used in this sense.
> 
> 
> Christian.
> 
> -- 
> Christian Knuepfer			
> Friedrich-Schiller-Universitaet Jena
> Institut fuer Informatik		
> Ernst-Abbe-Platz 1-4			
> D-07743 Jena, Germany
> 
> Office: Ernst-Abbe-Platz 2, Room 3237
> Phone: Intl.+49/3641/9-46353
> Fax: Intl.+49/3641/9-46302
> 
> e-mail: mailto:tr...@in...
> WWW: http://www.minet.uni-jena.de/~tral
> 
> PGP Key-ID: 0xC3329342
> PGP Public Key:
>   http://www.minet.uni-jena.de/~tral/data/christian_knuepfer_pub.asc
> Fingerprint: 5656 7F57 8E58 FC7B AC58  6714 3DA4 3181 C332 9342
> --
> 
> 
> 
> <javascript:void(0);>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot

Re: [sbml-annot] BioModels.net qualifier discussion

[Nick J. <ju...@eb...>]

Hi Neil,

For the initial question, I would say we are more than happy to add qualifiers upon request. Thats not a problem at all.
I do think, however, that we need to think carefully about what is an appropriate qualifer. They should be providing information on semantics / 
relationships. Specifically, I would have thought that SMILES would be more like a datatype, and so the subject of a MIRIAM Resources entry. Bear in 
mind also that we plan to have a second branch in MIRIAM Resources to handle those datatypes that are currently not able to be added for whatever 
reason. For modification, that sounds more like an SBO concept...
If I am getting the wrong end of the stick though, please let me know.

cheers

Nick

Neil Swainston wrote:
> Hi all,
> 
> While we're at it, what are people's thoughts on adding new qualifiers?
> 
> For example, I and others would like concepts like formula, charge, SMILES, etc. and apply them to metabolites. "Modification" is another that occasionally arises for proteins. 
> 
> Thoughts?
> 
> Cheers,
> 
> Neil. 
> 
> On 14 Jan 2011, at 23:00, Nicolas Le novère <le...@eb...> wrote:
> 
>> On 14/01/11 14:25, Neil Swainston wrote:
>>
>>> I think the goal is to recommend that the core annotations and "new"
>>> Annot annotations are used mutually exclusively. So, the core will use
>>> the old qualifiers and the Annot the new ones. In both cases, the
>>> qualifiers will be perennial.
>> Neil is correct. There won't be two schemes but only one scheme. 
>> "bqbiol:hasPart" and "bqbiol:part" are not two qualifiers. They are two 
>> forms of the same qualifier. The definition on biomodels.net will just be 
>> amended as follow:
>>
>> hasPart, part
>>
>> The biological entity represented by the model component includes the 
>> subject of the referenced resource, either physically or logically. This 
>> relation might be used to link a complex to the description of its components.
>>
>>
>>> I'm looking at the Annot specification now (sorry for the delay...) and
>>> in this I think that it would make sense to include a mapping from the
>>> core qualifiers to the new Annot ones (essentially, the finalised list
>>> that was produced by Nick J recently).
>>>
>>> Cheers,
>>>
>>> Neil.
>>>
>>> Neil Swainston Experimental Officer
>>>
>>> Manchester Centre for Integrative Systems Biology Manchester
>>> Interdisciplinary Biocentre University of Manchester Manchester M1 7DN
>>> United Kingdom
>>>
>>> On 14 Jan 2011, at 00:26, Mike Hucka wrote:
>>>
>>>> Maybe I missed it in the discussions so far, but is some versioning
>>>> going to be added, so that when reading a given model, a consumer can
>>>> figure out which qualifier scheme is being used?  Or do you think it
>>>> won't be required, because the new terms will map one-to-one to the
>>>> old ones, and all a consumer would need to know is both terms for a
>>>> given relationship?
>>>>
>>>> MH
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>> Protect Your Site and Customers from Malware Attacks
>>>> Learn about various malware tactics and how to avoid them. Understand
>>>> malware threats, the impact they can have on your business, and how
>>>> you can protect your company and customers by using code signing.
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>> _______________________________________________ Sbml-annot mailing
>>>> list Sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>> ------------------------------------------------------------------------------
>>>
>>>
>> Protect Your Site and Customers from Malware Attacks
>>> Learn about various malware tactics and how to avoid them. Understand
>>> malware threats, the impact they can have on your business, and how you
>>> can protect your company and customers by using code signing.
>>> http://p.sf.net/sfu/oracle-sfdevnl
>>> _______________________________________________ Sbml-annot mailing list
>>> Sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
>>
>> -- 
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>>
>> ------------------------------------------------------------------------------
>> Protect Your Site and Customers from Malware Attacks
>> Learn about various malware tactics and how to avoid them. Understand 
>> malware threats, the impact they can have on your business, and how you 
>> can protect your company and customers by using code signing.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Sbml-annot mailing list
>> Sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-annot
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Sbml-annot mailing list
> Sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-annot