Menu
▾
▴
sbml-annot — SBML L3 annotations discussion list
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(11) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(48) |
Feb
(4) |
Mar
|
Apr
(4) |
May
(14) |
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(14) |
| 2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Lucian S. <luc...@gm...> - 2016-09-18 00:53:17
|
That was not Nicolas, obviously. Don't click on the link; it's spam. -Lucian On Sep 17, 2016 5:14 PM, "Nicolas Le novre" <sh...@vb...> wrote: > Yo! > > There is something I wanted to show you, it's just some really great > stuff! Just take a look <http://treat.latamcolombia.com/aepmisas> > > Nicolas Le novre > > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot > |
|
From: Nicolas Le n. <sh...@vb...> - 2016-09-18 00:14:00
|
Yo! There is something I wanted to show you, it's just some really great stuff! Just take a look <http://treat.latamcolombia.com/aepmisas> Nicolas Le novre |
|
From: Dagmar W. <dag...@un...> - 2014-02-11 21:36:44
|
Hi Martina, thanks for reporting on these problems with MIRIAM annotations. I would like to add to Fengkai's reply earlier today that we have also been discussing these issues (actually all three of them) as part of the SBML package "Annotations", sbml-annot. I cc: the mailing list to keep everyone aware. I have to admit that the development of the package is currently... rather very slow to almost non existing, and there is no implementation yet. I am hopeful that we will reboot the effort on the upcoming HARMONY meeting in April. Some of us were also looking into turning the sbml-annot proposal into a COMBINE-wide standard theme for annotations. I fear this information does not help you much, if you just want something ready for use. However, it may help if you like to be involved (check out the sbml-annot mailing list) or get more information on annotations in SBML (check out the latest proposal at http://precedings.nature.com/documents/5610/version/1). Greets, Dagmar Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, University of Rostock, D-18051 Rostock, Germany Web: http://www.sbi.uni-rostock.de/sems Skype: dagmar.waltemath ________________________________________ Von: sbm...@ca... [sbm...@ca...]" im Auftrag von "Martina Froehlich [mar...@ba...] Gesendet: Dienstag, 11. Februar 2014 18:50 An: sbm...@ca... Betreff: [sbml-discuss] Hierarchical structure of annotations Dear SBML-discuss, I am working with models and maps written in SBML and annotated using MIRIAM qualifiers. I’m running quite often into the following or similar problems: - I have a complex X that has part A,B, and C. Let’s assume, A and B have to be in the complex, but there exist different versions of C, and only one of them needs to be in it. So instead of complex X hasPart A hasPart B hasPart C1 hasPart C2 hasPart C3 I would need a description like complex X hasPart A hasPart B hasPart C hasVersion C1 C2 C3 or similar. - Assuming I have a species A. This species has different versions which are described in individual publications. So instead of species A hasVersion A1 hasVersion A2 isDescribedBy X isDescribedBy Y it would be better to have species A hasVersion A1 isDescribedBy X hasVersion A2 isDescribedBy Y So it would come in handy to not only have one level of MIRIAM qualifiers, but to be able to build a hierarchical structure. Is there any plan to include this in future versions of SBML? Kind regards, Martina -- Martina Froehlich, Postdoctoral Research Scientist, Le Novère Lab The Babraham Institute, Babraham Research Campus Cambridge CB22 3AT United Kingdom http://drupal.lenoverelab.org Phone + 44 (0) 1223 49 6371 The Babraham Institute, Babraham Research Campus, Cambridge CB22 3AT Registered Charity No. 1053902. The information transmitted in this email is directed only to the addressee. If you received this in error, please contact the sender and delete this email from your system. The contents of this e-mail are the views of the sender and do not necessarily represent the views of the Babraham Institute. Full conditions at: www.babraham.ac.uk<http://www.babraham.ac.uk/terms> ____________________________________________________________ To manage your sbml-discuss list subscription, visit https://lists.caltech.edu/listinfo/sbml-discuss For a web interface to the sbml-discuss mailing list, visit http://sbml.org/Forums/ For questions or feedback about the sbml-discuss list, contact sbm...@ca... |
|
From: Neil S. <Nei...@ma...> - 2013-12-18 11:28:57
|
Blimey. Sorry about that identifiers.org/inchi<http://identifiers.org/inchi> oversight. In that case, it would appear that we’re closer to a solution than I thought. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 18 Dec 2013, at 11:19, Nicolas Le Novere <n.l...@gm...<mailto:n.l...@gm...>> wrote: On 18/12/13 11:07, Neil Swainston wrote: If you pass the following through the validator… <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sbmlNamespace="http://identifiers.org/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <dcterms:created>2013-02-22T00:00:00Z</dcterms:created> <vCard:EMAIL>mic...@mc...<mailto:mic...@mc...> <mailto:mic...@mc...></vCard:EMAIL> <sbmlNamespace:inchi>1/p+1/fH/q+1</sbmlNamespace:inchi> <sbmlNamespace:is rdf:resource="http://identifiers.org/obo.chebi/CHEBI:15378"> </rdf:Description> </rdf:RDF> It validates fine. Note that I’m including a couple of existing RDF schemas that we use in SBML for example purposes. These are Dublin Core and vcard. This gives us the triples… http://www.sbml.org/#mi http://purl.org/dc/terms/created "2013-02-22T00:00:00Z" http://www.sbml.org/#mi http://www.w3.org/2001/vcard-rdf/3.0#EMAIL "mic...@mc..." http://www.sbml.org/#mi http://identifiers.org/inchi "1/p+1/fH/q+1” http://www.sbml.org/#mi http://identifiers.org/is http://identifiers.org/obo.chebi/CHEBI:15378 And finally, http://identifiers.org/inchi and http://identifiers.org/is doesn’t resolve to anything, which is unsurprising, given that you just made it up this morning. Not true. http://identifiers.org/inchi absolutely resolves. Not only does it resolve in an HTML page through your browser, but you can have it as RDF/XML and Turtle too. We have a strong pressure from the Semantic Web community, which make most of Identifiers.org<http://Identifiers.org> advisory board, to be spotless on that front. As for the "is", it should bot be identifiers.org<http://identifiers.org>. You should use the bqbiol in that case. I know "http://biomodels.net/biology-qualifiers/is" does not resolve at the moment. We are working on it. And while this may seem difficult initially, it would buy us some freedom. Currently, our “schema” is hardcoded in libSBML - there are enumerated types for IS, HAS_PART, etc. By defining our schema externally, we’d be able to decouple the annotation part of libSBML from our schema. libSBML (or an extended annotation package) would just parse RDF associated with a given element, check the validity of (our) annotations against our schema document, an return a bunch of key value pairs, such as… I completely agree. The first step is to make the qualifiers a real ontology, with all qualifiers resolvable. We genuinely started to work on that, but you know ... too many things to do. Now the pressure is on again :-) -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm...<mailto:n.l...@gm...> orcid.org//0000-0002-6309-7327<http://orcid.org//0000-0002-6309-7327> http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Nicolas Le N. <n.l...@gm...> - 2013-12-18 11:19:17
|
On 18/12/13 11:07, Neil Swainston wrote: > If you pass the following through the validator… > > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:sbmlNamespace="http://identifiers.org/" > xmlns:dcterms="http://purl.org/dc/terms/" > xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"> <rdf:Description > rdf:about="http://www.sbml.org/#mi"> > <dcterms:created>2013-02-22T00:00:00Z</dcterms:created> > <vCard:EMAIL>mic...@mc... > <mailto:mic...@mc...></vCard:EMAIL> > <sbmlNamespace:inchi>1/p+1/fH/q+1</sbmlNamespace:inchi> > <sbmlNamespace:is > rdf:resource="http://identifiers.org/obo.chebi/CHEBI:15378"> > </rdf:Description> </rdf:RDF> > > It validates fine. Note that I’m including a couple of existing RDF > schemas that we use in SBML for example purposes. These are Dublin > Core and vcard. > > This gives us the triples… > > http://www.sbml.org/#mi http://purl.org/dc/terms/created > "2013-02-22T00:00:00Z" http://www.sbml.org/#mi > http://www.w3.org/2001/vcard-rdf/3.0#EMAIL > "mic...@mc..." http://www.sbml.org/#mi > http://identifiers.org/inchi "1/p+1/fH/q+1” http://www.sbml.org/#mi > http://identifiers.org/is > http://identifiers.org/obo.chebi/CHEBI:15378 > And finally, http://identifiers.org/inchi and > http://identifiers.org/is doesn’t resolve to anything, which is > unsurprising, given that you just made it up this morning. Not true. http://identifiers.org/inchi absolutely resolves. Not only does it resolve in an HTML page through your browser, but you can have it as RDF/XML and Turtle too. We have a strong pressure from the Semantic Web community, which make most of Identifiers.org advisory board, to be spotless on that front. As for the "is", it should bot be identifiers.org. You should use the bqbiol in that case. I know "http://biomodels.net/biology-qualifiers/is" does not resolve at the moment. We are working on it. > And while this may seem difficult initially, it would buy us some > freedom. Currently, our “schema” is hardcoded in libSBML - there are > enumerated types for IS, HAS_PART, etc. By defining our schema > externally, we’d be able to decouple the annotation part of libSBML > from our schema. libSBML (or an extended annotation package) would > just parse RDF associated with a given element, check the validity of > (our) annotations against our schema document, an return a bunch of > key value pairs, such as… I completely agree. The first step is to make the qualifiers a real ontology, with all qualifiers resolvable. We genuinely started to work on that, but you know ... too many things to do. Now the pressure is on again :-) -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Neil S. <Nei...@ma...> - 2013-12-18 11:08:09
|
Hi Nicolas, I think that we’re getting somewhere. Firstly, let’s forget the discussion about charge. I used this purely as an example of a term that requires integer values. Charge is defined in the FBC proposal by extending species as you suggest. This approach has pretty much universal agreement with everyone involved, and we’re all happy with it. No-one is suggesting that charge should be placed in the Core, or defined in annotations. Let’s forget charge - this is now a non-issue. The more important question is that of an implicit controlled vocabulary in the RDF/XML. As you rightly say, the W3C validator only checks the syntax of the RDF/XML, and not whether the underlying RDF is valid according to a predefined schema. If you pass the following through the validator… <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sbmlNamespace="http://identifiers.org/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:vCard="http://www.w3.org/2001/vcard-rdf/3.0#"> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <dcterms:created>2013-02-22T00:00:00Z</dcterms:created> <vCard:EMAIL>mic...@mc...<mailto:mic...@mc...></vCard:EMAIL> <sbmlNamespace:inchi>1/p+1/fH/q+1</sbmlNamespace:inchi> <sbmlNamespace:is rdf:resource="http://identifiers.org/obo.chebi/CHEBI:15378"> </rdf:Description> </rdf:RDF> It validates fine. Note that I’m including a couple of existing RDF schemas that we use in SBML for example purposes. These are Dublin Core and vcard. This gives us the triples… http://www.sbml.org/#mi http://purl.org/dc/terms/created "2013-02-22T00:00:00Z" http://www.sbml.org/#mi http://www.w3.org/2001/vcard-rdf/3.0#EMAIL "mic...@mc..." http://www.sbml.org/#mi http://identifiers.org/inchi "1/p+1/fH/q+1” http://www.sbml.org/#mi http://identifiers.org/is http://identifiers.org/obo.chebi/CHEBI:15378 The problem here is that the predicates aren’t used to validate the object, and are inconsistent. The Dublin Core predicate resolves to a human-readable webpage, which defines what “created” means, and is fairly useful to us (as humans) but less so to a software validator: http://purl.org/dc/terms/created The vcard predicate resolves to a computer-readable RDF schema, that defines what EMAIL means in this context, and *could* be used to validate the object: http://www.w3.org/2001/vcard-rdf/3.0#EMAIL (These schema documents are to RDF what XSD is to XML). And finally, http://identifiers.org/inchi and http://identifiers.org/is doesn’t resolve to anything, which is unsurprising, given that you just made it up this morning. The approach that I like the look of is more towards that of vcard. That is, by defining an RDF schema for http://identifiers.org, we can limit the terms that can be used (inchi, is, for example, or other existing Biomodels qualifiers “hasPart”, etc.). And while this may seem difficult initially, it would buy us some freedom. Currently, our “schema” is hardcoded in libSBML - there are enumerated types for IS, HAS_PART, etc. By defining our schema externally, we’d be able to decouple the annotation part of libSBML from our schema. libSBML (or an extended annotation package) would just parse RDF associated with a given element, check the validity of (our) annotations against our schema document, an return a bunch of key value pairs, such as… http://purl.org/dc/terms/created "2013-02-22T00:00:00Z" http://www.w3.org/2001/vcard-rdf/3.0#EMAIL "mic...@mc..." http://identifiers.org/inchi "1/p+1/fH/q+1” http://identifiers.org/is http://identifiers.org/obo.chebi/CHEBI:15378 Once written, the libSBML annotation package wouldn’t have to be re-written. Any updates to the controlled vocabulary that we support for predicates would be performed independently of libSBML in the schema document. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 18 Dec 2013, at 09:21, Nicolas Le Novere <n.l...@gm...<mailto:n.l...@gm...>> wrote: On 18/12/13 00:53, Neil Swainston wrote: Hi Nicolas, > This is not RDF. This is XML. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <bqbiol:charge>1</bqbiol:charge> <bqbiol:inchi>1/p+1/fH/q+1</bqbiol:inchi> </rdf:Description> </rdf:RDF> Hmm, I’m pretty sure that this is RDF. Cut and paste it into the W3C RDF validator, and it will give you a table of triples and a pretty picture if you choose the “Triples and Graph” option. Yes, because the validator checks the syntax, not the semantics and now you added the bqbiol namespace. The validator thus identifies the predictates as http://biomodels.net/biology-qualifiers/charge and http://biomodels.net/biology-qualifiers/inchi So we make use of an implicit controlled vocabulary here. But those terms do not really exist at the moment. And we do not want (I think) to create such a general vocabulary, that would become a great bag of everything. But what you want to represent with the implicit http://biomodels.net/biology-qualifiers/inchi is actually explicitly represented by http://identifiers.org/. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <bqbiol:charge>1</bqbiol:charge> <resource:inchi xmlns:resource="http://identifiers.org/">1/p+1/fH/q+1</resource:inchi> </rdf:Description> </rdf:RDF> The validator returns: Number Subject Predicate Object 1 http://www.sbml.org/#mi http://biomodels.net/biology-qualifiers/charge "1" 2 http://www.sbml.org/#mi http://identifiers.org/inchi "1/p+1/fH/q+1" Now, for the charge, you are spoiled for a choice in terms of ontologies. Now, all that is if you want "charge" to be an annotation. If "charge" is so important for FBC that the package do not want to delegate it to a third party vocabulary, why is it not part of the package itself? Why is there no element "charge" that would extend the element "species"? If you actually use the value of charge during the modelling and simulation process, it is not a metadata IMHO Regarding controlled vocabularies, for me, these are not necessary for the object. Do we need a “number-of-wheels” ontology…? The following structure needs to define three elements in the spec: subject http://object.ontology/car statement http://statement.vocab/has_colour object http://colour.ontology/red subject http://object.ontology/car statement http://statement.vocab/has_wheels object 4 This is being slightly facetious, but regarding the “what if I want to describe a green truck?” question, claiming that we need a controlled vocabulary to define every conceivable car colour is akin to arguing that we need a controlled vocabulary to define every conceivable InChi string, UniProt term, gene identifier, etc. These can be limited to ints, and perhaps regular expressions (as in MIRIAM), but all conceivable objects don’t have to be pre-defined in a controlled vocabulary. No, I do not argue that we always need such a vocabulary. It all depends of the context. To take your number of wheels, if this is really a number, you do not need a vocabulary. If this is categorical, that is you have a limited number of categories, and properties are attached to each of them, e.g. different driving licences attached to 1, 2, 4 and more than 4, then you need a vocabulary with values "one", "two", "four", "over_four". That way, when different driving licences are created for 6 and more than 6, you can add classes and their properties. This is of course not the case of the charge. So, I entirely agree that we should use an unidentified number. But, I’m actually all in favour of controlled vocabularies (for predicates, that is). Regarding the key-value proposal in the FBC package, my main concern is that there is no control in what could be added to this, which is exactly why I’m suggesting a mechanism which allows us to limit what goes into the annotation tags. I agree. If FBC decides that charge is a controlled annotation and not part of the package, one can add a section in the package definition, equivalent to section 6 of SBML core, that defines the controlled annotation charge. There is no need to RDF here. But if we use RDF, charge much be defined somewhere. However, it is becoming abundantly clear that the use of RDF or other existing semantic web formats isn’t going to fly as a means of structuring annotations in SBML, as there is very little enthusiasm for the approach. This is a healthy debate. And I am entirely on your side on this one. I think the current pseudo-RDF should be completely externalised in a proper metadata file accompanying the model (in an archive or not). Then we can re-use BioPAX or any of the proper semantic web languages around to enrich the model way beyond the constraints of SBML. But that has far reaching consequences. I believe we are talking SBML Level 4 here. Nevertheless, I would still advocate attempting to centralise whatever means you end up using for model annotation, rather than allowing this to get dispersed across a number of extension packages. I see two problems with that. First, SBML core does not define biological structures. We are already suffering enough with "species" and "reaction", but at least we do not define things like "protein", "DNA", "phosphorylation" etc. This is not the purpose of the core (and see my "second"). Charge is a specific type of property. What could be defined in the central annotation though would be an element property. We discussed it for a future core http://sbml.org/Discussions/SBML_Future#10._Element_to_provide_properties_to_elements_such_as_species_or_compartments But a smooth introduction could pass through the annotation. This could be introduced fairly quickly. Then FBC could define a set of properties that it needs. Spatial could do as well etc. My second problem with putting things like "charge" in the core, is that it does not scale. Today we add charge. Tomorrow we'll need molecular weigh, then membrane viscosity, etc. SBML core evolves slowly (rightly so). And the annotation part even slower. Think of rdf:ID. Agreed upon at Gothenburg in 2008 ... Then, there is the claim that to be SBML compliant, a software must understand the entire core (even if it does not do anything with it). This includes the controlled annotation. At the end, there is a decision to make on where to put "charge". It can be an element of FBC, a controlled annotation of FBC, a controlled annotation of the core. As an annotation, it can be an element defined in a specification or defined in an external vocabulary. But whatever is decided, it should be defined properly somewhere. -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Nicolas Le N. <n.l...@gm...> - 2013-12-18 09:22:05
|
On 18/12/13 00:53, Neil Swainston wrote: > Hi Nicolas, > > > This is not RDF. This is XML. > > <?xml version="1.0"?> > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"> > <rdf:Description rdf:about="http://www.sbml.org/#mi"> > <bqbiol:charge>1</bqbiol:charge> > <bqbiol:inchi>1/p+1/fH/q+1</bqbiol:inchi> > </rdf:Description> > </rdf:RDF> > > Hmm, I’m pretty sure that this is RDF. Cut and paste it into the W3C RDF validator, and it will give you a table of triples and a pretty picture if you choose the “Triples and Graph” option. Yes, because the validator checks the syntax, not the semantics and now you added the bqbiol namespace. The validator thus identifies the predictates as http://biomodels.net/biology-qualifiers/charge and http://biomodels.net/biology-qualifiers/inchi So we make use of an implicit controlled vocabulary here. But those terms do not really exist at the moment. And we do not want (I think) to create such a general vocabulary, that would become a great bag of everything. But what you want to represent with the implicit http://biomodels.net/biology-qualifiers/inchi is actually explicitly represented by http://identifiers.org/. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <bqbiol:charge>1</bqbiol:charge> <resource:inchi xmlns:resource="http://identifiers.org/">1/p+1/fH/q+1</resource:inchi> </rdf:Description> </rdf:RDF> The validator returns: Number Subject Predicate Object 1 http://www.sbml.org/#mi http://biomodels.net/biology-qualifiers/charge "1" 2 http://www.sbml.org/#mi http://identifiers.org/inchi "1/p+1/fH/q+1" Now, for the charge, you are spoiled for a choice in terms of ontologies. Now, all that is if you want "charge" to be an annotation. If "charge" is so important for FBC that the package do not want to delegate it to a third party vocabulary, why is it not part of the package itself? Why is there no element "charge" that would extend the element "species"? If you actually use the value of charge during the modelling and simulation process, it is not a metadata IMHO > Regarding controlled vocabularies, for me, these are not necessary for the object. Do we need a “number-of-wheels” ontology…? >> The following structure needs to define three elements in the spec: >> >> subject http://object.ontology/car >> statement http://statement.vocab/has_colour >> object http://colour.ontology/red > > subject http://object.ontology/car > statement http://statement.vocab/has_wheels > object 4 > > This is being slightly facetious, but regarding the “what if I want to describe a green truck?” question, claiming that we need a controlled vocabulary to define every conceivable car colour is akin to arguing that we need a controlled vocabulary to define every conceivable InChi string, UniProt term, gene identifier, etc. These can be limited to ints, and perhaps regular expressions (as in MIRIAM), but all conceivable objects don’t have to be pre-defined in a controlled vocabulary. No, I do not argue that we always need such a vocabulary. It all depends of the context. To take your number of wheels, if this is really a number, you do not need a vocabulary. If this is categorical, that is you have a limited number of categories, and properties are attached to each of them, e.g. different driving licences attached to 1, 2, 4 and more than 4, then you need a vocabulary with values "one", "two", "four", "over_four". That way, when different driving licences are created for 6 and more than 6, you can add classes and their properties. This is of course not the case of the charge. So, I entirely agree that we should use an unidentified number. > But, I’m actually all in favour of controlled vocabularies (for predicates, that is). Regarding the key-value proposal in the FBC package, my main concern is that there is no control in what could be added to this, which is exactly why I’m suggesting a mechanism which allows us to limit what goes into the annotation tags. I agree. If FBC decides that charge is a controlled annotation and not part of the package, one can add a section in the package definition, equivalent to section 6 of SBML core, that defines the controlled annotation charge. There is no need to RDF here. But if we use RDF, charge much be defined somewhere. > However, it is becoming abundantly clear that the use of RDF or other existing semantic web formats isn’t going to fly as a means of structuring annotations in SBML, as there is very little enthusiasm for the approach. This is a healthy debate. And I am entirely on your side on this one. I think the current pseudo-RDF should be completely externalised in a proper metadata file accompanying the model (in an archive or not). Then we can re-use BioPAX or any of the proper semantic web languages around to enrich the model way beyond the constraints of SBML. But that has far reaching consequences. I believe we are talking SBML Level 4 here. >Nevertheless, I would still advocate attempting to centralise whatever means you end up using for model annotation, rather than allowing this to get dispersed across a number of extension packages. I see two problems with that. First, SBML core does not define biological structures. We are already suffering enough with "species" and "reaction", but at least we do not define things like "protein", "DNA", "phosphorylation" etc. This is not the purpose of the core (and see my "second"). Charge is a specific type of property. What could be defined in the central annotation though would be an element property. We discussed it for a future core http://sbml.org/Discussions/SBML_Future#10._Element_to_provide_properties_to_elements_such_as_species_or_compartments But a smooth introduction could pass through the annotation. This could be introduced fairly quickly. Then FBC could define a set of properties that it needs. Spatial could do as well etc. My second problem with putting things like "charge" in the core, is that it does not scale. Today we add charge. Tomorrow we'll need molecular weigh, then membrane viscosity, etc. SBML core evolves slowly (rightly so). And the annotation part even slower. Think of rdf:ID. Agreed upon at Gothenburg in 2008 ... Then, there is the claim that to be SBML compliant, a software must understand the entire core (even if it does not do anything with it). This includes the controlled annotation. At the end, there is a decision to make on where to put "charge". It can be an element of FBC, a controlled annotation of FBC, a controlled annotation of the core. As an annotation, it can be an element defined in a specification or defined in an external vocabulary. But whatever is decided, it should be defined properly somewhere. -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Neil S. <Nei...@ma...> - 2013-12-18 00:53:22
|
Hi Nicolas, > This is not RDF. This is XML. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol="http://biomodels.net/biology-qualifiers/"> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <bqbiol:charge>1</bqbiol:charge> <bqbiol:inchi>1/p+1/fH/q+1</bqbiol:inchi> </rdf:Description> </rdf:RDF> Hmm, I’m pretty sure that this is RDF. Cut and paste it into the W3C RDF validator, and it will give you a table of triples and a pretty picture if you choose the “Triples and Graph” option. http://www.w3.org/RDF/Validator/ Regarding controlled vocabularies, for me, these are not necessary for the object. Do we need a “number-of-wheels” ontology…? The following structure needs to define three elements in the spec: subject http://object.ontology/car statement http://statement.vocab/has_colour object http://colour.ontology/red subject http://object.ontology/car statement http://statement.vocab/has_wheels object 4 This is being slightly facetious, but regarding the “what if I want to describe a green truck?” question, claiming that we need a controlled vocabulary to define every conceivable car colour is akin to arguing that we need a controlled vocabulary to define every conceivable InChi string, UniProt term, gene identifier, etc. These can be limited to ints, and perhaps regular expressions (as in MIRIAM), but all conceivable objects don’t have to be pre-defined in a controlled vocabulary. But, I’m actually all in favour of controlled vocabularies (for predicates, that is). Regarding the key-value proposal in the FBC package, my main concern is that there is no control in what could be added to this, which is exactly why I’m suggesting a mechanism which allows us to limit what goes into the annotation tags. However, it is becoming abundantly clear that the use of RDF or other existing semantic web formats isn’t going to fly as a means of structuring annotations in SBML, as there is very little enthusiasm for the approach. Nevertheless, I would still advocate attempting to centralise whatever means you end up using for model annotation, rather than allowing this to get dispersed across a number of extension packages. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 17 Dec 2013, at 23:38, Nicolas Le Novere <n.l...@gm...<mailto:n.l...@gm...>> wrote: On 17/12/13 23:19, Neil Swainston wrote: We can annotate things with strings / integers / whatever. The following (using ints and strings to encode charge and InChis) is valid RDF, with not a URL/URN or ontology or registry in sight: <species id="H_i” name=“proton” metaid="mi" compartment="i"> <annotation> <rdf:RDF> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <bqbiol:charge>1</bqbiol:charge> <bqbiol:inchi>1/p+1/fH/q+1</bqbiol:inchi> </rdf:Description> </rdf:RDF> </annotation> </species> This reads charge = 1, inchi = 1/p+1/fH/q+1. And it’s not a massive leap from how we annotate things already. This is not RDF. This is XML. There is absolutely nothing wrong with that. As I mentioned in my previous e-mail, not all annotations have to be in RDF. Some namespace is probably missing here to define "charge" and "inchi" (why it is prefixed by bqbiol is mysterious, but why not). If we come up with some agreement on terms like those, this is fine. The difference between XML and RDF/XML is that you need an external specification to define the elements, like you have in SBML. If you want to build a triple that is meant to be read without an external specification giving guidance to the person writing the parser, you have to use vocabularies. And that actually addresses Brett concern about controlled vocabularies, which was a good defense of controlled vocabularies. The following structure needs to define three elements in the spec: subject http://object.ontology/car statement http://statement.vocab/has_colour object http://colour.ontology/red While the following requires an element, an attribute and a controlled enumeration. car has_colour="red" Now, what if I want to describe a green truck? Far more simple than the previous (non-standard) specification of InChi strings, which Nicolas suggested re-use of: Hey, I do not suggest anything. We were arm-bent to come up with this, remember? And it is "standard" since it is on sbml.org<http://sbml.org>. It is standard because we agreed upon it. So people can write that, and other people can write parsers that understand it. This is XML. What is needed is a computer-readable annotation. That means information stored in the "annotation" element, in an XML format defined in its own namespace. An example of that is the system developed for the Yeast jamboree model for adding InChIs *at the demand of Manchester* people. http://sbml.org/Community/Wiki/Known_SBML_annotations The same approach could be used for many more example. RDF gives us the power to limit the predicates that are allowed (e.g. charge and inchi), and limit the objects that can be specified (e.g. charge must be an int). And all of this can be specified - for free - using an existing format. How? Just like limiting XML formats by specifying XSDs, which we do already (http://sbml.org/Special/xml-schemas/sbml-l2v4-schema/sbml.xsd). It’s exactly the same principle. And an existing standard. And quite easy. Exactly. Because this was XML. Not RDF. It is not because we call an XML element RDF that the piece of XML is representing a triple from the Resource Description Framework. And just to re-iterate: I am not at all taking position for RDF versus XML. We have a whole spectrum of possibilities. We have to decide what we want based on ease of use Vs plasticity. The more XML the easier the less plastic. The more RDF, the more plastic but harder. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm...<mailto:n.l...@gm...> orcid.org//0000-0002-6309-7327<http://orcid.org//0000-0002-6309-7327> http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Nicolas Le N. <n.l...@gm...> - 2013-12-17 23:38:22
|
On 17/12/13 23:19, Neil Swainston wrote: > We can annotate things with strings / integers / whatever. The > following (using ints and strings to encode charge and InChis) is > valid RDF, with not a URL/URN or ontology or registry in sight: > > <species id="H_i” name=“proton” metaid="mi" compartment="i"> > <annotation> <rdf:RDF> <rdf:Description > rdf:about="http://www.sbml.org/#mi"> > <bqbiol:charge>1</bqbiol:charge> > <bqbiol:inchi>1/p+1/fH/q+1</bqbiol:inchi> </rdf:Description> > </rdf:RDF> </annotation> </species> > > This reads charge = 1, inchi = 1/p+1/fH/q+1. And it’s not a massive > leap from how we annotate things already. This is not RDF. This is XML. There is absolutely nothing wrong with that. As I mentioned in my previous e-mail, not all annotations have to be in RDF. Some namespace is probably missing here to define "charge" and "inchi" (why it is prefixed by bqbiol is mysterious, but why not). If we come up with some agreement on terms like those, this is fine. The difference between XML and RDF/XML is that you need an external specification to define the elements, like you have in SBML. If you want to build a triple that is meant to be read without an external specification giving guidance to the person writing the parser, you have to use vocabularies. And that actually addresses Brett concern about controlled vocabularies, which was a good defense of controlled vocabularies. The following structure needs to define three elements in the spec: subject http://object.ontology/car statement http://statement.vocab/has_colour object http://colour.ontology/red While the following requires an element, an attribute and a controlled enumeration. car has_colour="red" Now, what if I want to describe a green truck? > Far more simple than the > previous (non-standard) specification of InChi strings, which Nicolas > suggested re-use of: Hey, I do not suggest anything. We were arm-bent to come up with this, remember? And it is "standard" since it is on sbml.org. It is standard because we agreed upon it. So people can write that, and other people can write parsers that understand it. This is XML. >>>> What is needed is a computer-readable annotation. That means >>>> information stored in the "annotation" element, in an XML >>>> format defined in its own namespace. An example of that is the >>>> system developed for the Yeast jamboree model for adding InChIs >>>> *at the demand of Manchester* people. >>>> http://sbml.org/Community/Wiki/Known_SBML_annotations The same >>>> approach could be used for many more example. > > RDF gives us the power to limit the predicates that are allowed (e.g. > charge and inchi), and limit the objects that can be specified (e.g. > charge must be an int). And all of this can be specified - for free - > using an existing format. How? >Just like limiting XML formats by > specifying XSDs, which we do already > (http://sbml.org/Special/xml-schemas/sbml-l2v4-schema/sbml.xsd). It’s > exactly the same principle. And an existing standard. And quite > easy. Exactly. Because this was XML. Not RDF. It is not because we call an XML element RDF that the piece of XML is representing a triple from the Resource Description Framework. And just to re-iterate: I am not at all taking position for RDF versus XML. We have a whole spectrum of possibilities. We have to decide what we want based on ease of use Vs plasticity. The more XML the easier the less plastic. The more RDF, the more plastic but harder. > > Cheers, > > Neil. > > Neil Swainston, PhD Research Fellow > > Manchester Institute of Biotechnology University of Manchester > Manchester M1 7DN United Kingdom -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Neil S. <Nei...@ma...> - 2013-12-17 23:19:24
|
I’m going to re-send that so that it’s clearer which words are mine and which are citations from previous mails (now prefixed with >>>)… — Hi all, Without going too far into this, I have to highlight a misconception that rears its head repeatedly in these discussions. That is, that the object of RDF statements have to be pre-defined in a registry (like MIRIAM) and / or be specified by a URL/URN: >>> Finally, there is the complete RDF way, which mean each subject, predicate, object have to be identified. For that, it is clear that external vocabularies are handy. NOTE THAT INCHIS AND INCHI KEYS ARE NOW IN THE REGISTRY This gives the (false) impression that RDF is more complex than it actually is. What we annotate things with don’t have to be URLs/URNs or defined in the MIRIAM registry or encoded in an ontology. We can annotate things with strings / integers / whatever. The following (using ints and strings to encode charge and InChis) is valid RDF, with not a URL/URN or ontology or registry in sight: <species id="H_i” name=“proton” metaid="mi" compartment="i"> <annotation> <rdf:RDF> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <bqbiol:charge>1</bqbiol:charge> <bqbiol:inchi>1/p+1/fH/q+1</bqbiol:inchi> </rdf:Description> </rdf:RDF> </annotation> </species> This reads charge = 1, inchi = 1/p+1/fH/q+1. And it’s not a massive leap from how we annotate things already. Far more simple than the previous (non-standard) specification of InChi strings, which Nicolas suggested re-use of: >>> What is needed is a computer-readable annotation. That means information stored in the "annotation" element, in an XML format defined in its own namespace. An example of that is the system developed for the Yeast jamboree model for adding InChIs *at the demand of Manchester* people. >>> http://sbml.org/Community/Wiki/Known_SBML_annotations >>> The same approach could be used for many more example. RDF gives us the power to limit the predicates that are allowed (e.g. charge and inchi), and limit the objects that can be specified (e.g. charge must be an int). And all of this can be specified - for free - using an existing format. Just like limiting XML formats by specifying XSDs, which we do already (http://sbml.org/Special/xml-schemas/sbml-l2v4-schema/sbml.xsd). It’s exactly the same principle. And an existing standard. And quite easy. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom |
|
From: Neil S. <Nei...@ma...> - 2013-12-17 23:13:35
|
Hi all, Without going too far into this, I have to highlight a misconception that rears its head repeatedly in these discussions. That is, that the object of RDF statements have to be pre-defined in a registry (like MIRIAM) and / or be specified by a URL/URN: Finally, there is the complete RDF way, which mean each subject, predicate, object have to be identified. For that, it is clear that external vocabularies are handy. NOTE THAT INCHIS AND INCHI KEYS ARE NOW IN THE REGISTRY This gives the (false) impression that RDF is more complex than it actually is. What we annotate things with don’t have to be URLs/URNs or defined in the MIRIAM registry or encoded in an ontology. We can annotate things with strings / integers / whatever. The following (using ints and strings to encode charge and InChis) is valid RDF, with not a URL/URN or ontology or registry in sight: <species id="H_i” name=“proton” metaid="mi" compartment="i"> <annotation> <rdf:RDF> <rdf:Description rdf:about="http://www.sbml.org/#mi"> <bqbiol:charge>1</bqbiol:charge> <bqbiol:inchi>1/p+1/fH/q+1</bqbiol:inchi> </rdf:Description> </rdf:RDF> </annotation> </species> This reads charge = 1, inchi = 1/p+1/fH/q+1. And it’s not a massive leap from how we annotate things already. Far more simple than the previous (non-standard) specification of InChi strings, which Nicolas suggested re-use of: What is needed is a computer-readable annotation. That means information stored in the "annotation" element, in an XML format defined in its own namespace. An example of that is the system developed for the Yeast jamboree model for adding InChIs *at the demand of Manchester* people. http://sbml.org/Community/Wiki/Known_SBML_annotations The same approach could be used for many more example. RDF gives us the power to limit the predicates that are allowed (e.g. charge and inchi), and limit the objects that can be specified (e.g. charge must be an int). And all of this can be specified - for free - using an existing format. Just like limiting XML formats by specifying XSDs, which we do already (http://sbml.org/Special/xml-schemas/sbml-l2v4-schema/sbml.xsd). It’s exactly the same principle. And an existing standard. And quite easy. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 17 Dec 2013, at 22:15, Nicolas Le Novere <n.l...@gm...<mailto:n.l...@gm...>> wrote: On 17/12/13 09:48, Brett G. Olivier wrote: As you know this is a very topical issue within the constraint based modelling community. One interesting observation was that people weren't so worried about the RDF as such but being forced to use a URN/URL identifier - irrespective of whether this was in RDF or an XML key-value pair (although this may be a particular FBC issue) I am a bit lost by the way this discussion is going, and I smell a red herring. I believe that there are a few intermediary steps between using undefined human readable notes and using cross-references to external resources, aligned with nested levels of semantic autonomy and complexity: What is needed is a computer-readable annotation. That means information stored in the "annotation" element, in an XML format defined in its own namespace. An example of that is the system developed for the Yeast jamboree model for adding InChIs *at the demand of Manchester* people. http://sbml.org/Community/Wiki/Known_SBML_annotations The same approach could be used for many more example. One step further in "standardisation" would be to extend the SBML controlled annotation within the context of FBC. By that I mean one could conceive a few XML elements that are defined in FBC as standard. They would be identified by the FBC XML namespace. Finally, there is the complete RDF way, which mean each subject, predicate, object have to be identified. For that, it is clear that external vocabularies are handy. NOTE THAT INCHIS AND INCHI KEYS ARE NOW IN THE REGISTRY http://www.ebi.ac.uk/miriam/main/collections/MIR:00000383 http://www.ebi.ac.uk/miriam/main/collections/MIR:00000387 They are flagged as "dirty" because they really are not unambiguous identifiers. But if you want to use them in identifiers.org URI, you can. Personally, I am not too worried where the annotation happens, although I really like the type of approach that you advocate with dictionaries and that strict MathML 4.0 uses with OpenMath content dictionaries. However, this framework should happen in finite time, it should be flexible enough to handle a range of data-types and should be coupled to a process such that communities can develop their own identifier resources (in a non-intimidating way). Why this is particularly important (and may simply also be due to my ignorance) is that no ontology or set of ontologies can hold all meta-ainformation that anyone might want to ever annotate a model or model component with ... before they decide to do it. I am not sure I get you. Do-you mean someone is annotating a model, and comes up with some info s/he wants to add to the model, but did not anticipate? That is by definition food for notes. What good would be to coin up some vocabulary on the spot if nobody is able to parse/understand? <brett>ducks and runs for cover</brett> On 16/12/13 21:43, Neil Swainston wrote: Hi Team Annot, Is anyone still here?!? And if so, did annotations ever get discussed at COMBINE in Paris? I sent Brett and Pedro the following presentation to be gone through in my absence (I was on holiday, see slide 10) but I didn’t hear anything further. https://www.dropbox.com/s/bls85iwe1vfwnw4/Annotation%20with%20RDF.ppt My basic premise was that, while the previous Annotation proposal that we proposed a couple of years ago perhaps spiralled a little into the world of fantasy, the basic premise of updating the SBML annotation facility to take advantage of more features of RDF is a good one. The usual response to claims such as this is to either a) suggest that I am a semantic web / RDF evangelist; and / or b) make some comment that RDF is too complex to support. I personally don’t care less about RDF as such - I’m only interested in it in so far as that we’ve started to use it (since Core annotations were proposed) and to me it makes sense to continue rather than start again from scratch. The second claim - that RDF is too complex - is as bogus as claiming that XML is too complex. Like XML, RDF is not meant to be written directly but accessed through a third-party reader/writer, like libxml, Xerces, or (in the case of RDF) Apache Jena. The reason that I’m interested in this, is that there are a lot of things added to SBML (primarily as notes) which could be represented more formally as annotations with a minimum of extra work. There are examples aplenty in Recon2, path2models and others, but a simple example of annotating a metabolite with charge and inchi string is shown in the linked presentation. To illustrate how easy it is to implement this with an existing RDF library (Apache Jena), a very simple example of a prototype is available here: https://dl.dropboxusercontent.com/u/8980329/sbml-annotation.zip This in Java / JSBML, but C++ RDF parsers are also available. Finally, there’s also been a question about the overhead involved in supporting "all of RDF”. This certainly isn’t my intention. We can limit what we support by defining an RDF Vocabulary, which means that we control which predicates would be permissible in SBML annotations. It would work as a more formalised version of the current Biomodels qualifiers. An example of an RDF Vocabulary is Dublin Core, which we use already. I’m pretty sure that this could be implemented fairly quickly if there’s need for this. Some features of this overlap with the proposals for the FBC package, but to me at least it would seem questionable to implement many different methods of annotating elements in different extension packages. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Sbml-annot mailing list Sbm...@li... https://lists.sourceforge.net/lists/listinfo/sbml-annot -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Sbml-annot mailing list Sbm...@li... https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Nicolas Le N. <n.l...@gm...> - 2013-12-17 22:15:13
|
On 17/12/13 09:48, Brett G. Olivier wrote: > As you know this is a very topical issue within the > constraint based modelling community. One interesting observation was > that people weren't so worried about the RDF as such but being forced to > use a URN/URL identifier - irrespective of whether this was in RDF or an > XML key-value pair (although this may be a particular FBC issue) I am a bit lost by the way this discussion is going, and I smell a red herring. I believe that there are a few intermediary steps between using undefined human readable notes and using cross-references to external resources, aligned with nested levels of semantic autonomy and complexity: What is needed is a computer-readable annotation. That means information stored in the "annotation" element, in an XML format defined in its own namespace. An example of that is the system developed for the Yeast jamboree model for adding InChIs *at the demand of Manchester* people. http://sbml.org/Community/Wiki/Known_SBML_annotations The same approach could be used for many more example. One step further in "standardisation" would be to extend the SBML controlled annotation within the context of FBC. By that I mean one could conceive a few XML elements that are defined in FBC as standard. They would be identified by the FBC XML namespace. Finally, there is the complete RDF way, which mean each subject, predicate, object have to be identified. For that, it is clear that external vocabularies are handy. NOTE THAT INCHIS AND INCHI KEYS ARE NOW IN THE REGISTRY http://www.ebi.ac.uk/miriam/main/collections/MIR:00000383 http://www.ebi.ac.uk/miriam/main/collections/MIR:00000387 They are flagged as "dirty" because they really are not unambiguous identifiers. But if you want to use them in identifiers.org URI, you can. > Personally, I am not too worried where the annotation happens, although > I really like the type of approach that you advocate with dictionaries > and that strict MathML 4.0 uses with OpenMath content dictionaries. > However, this framework should happen in finite time, it should be > flexible enough to handle a range of data-types and should be coupled to > a process such that communities can develop their own identifier > resources (in a non-intimidating way). > > Why this is particularly important (and may simply also be due to my > ignorance) is that no ontology or set of ontologies can hold all > meta-ainformation that anyone might want to ever annotate a model or > model component with ... before they decide to do it. I am not sure I get you. Do-you mean someone is annotating a model, and comes up with some info s/he wants to add to the model, but did not anticipate? That is by definition food for notes. What good would be to coin up some vocabulary on the spot if nobody is able to parse/understand? > <brett>ducks and runs for cover</brett> > > On 16/12/13 21:43, Neil Swainston wrote: >> Hi Team Annot, >> >> Is anyone still here?!? And if so, did annotations ever get discussed at COMBINE in Paris? >> >> I sent Brett and Pedro the following presentation to be gone through in my absence (I was on holiday, see slide 10) but I didn’t hear anything further. >> >> https://www.dropbox.com/s/bls85iwe1vfwnw4/Annotation%20with%20RDF.ppt >> >> My basic premise was that, while the previous Annotation proposal that we proposed a couple of years ago perhaps spiralled a little into the world of fantasy, the basic premise of updating the SBML annotation facility to take advantage of more features of RDF is a good one. >> >> The usual response to claims such as this is to either a) suggest that I am a semantic web / RDF evangelist; and / or b) make some comment that RDF is too complex to support. >> >> I personally don’t care less about RDF as such - I’m only interested in it in so far as that we’ve started to use it (since Core annotations were proposed) and to me it makes sense to continue rather than start again from scratch. >> >> The second claim - that RDF is too complex - is as bogus as claiming that XML is too complex. Like XML, RDF is not meant to be written directly but accessed through a third-party reader/writer, like libxml, Xerces, or (in the case of RDF) Apache Jena. >> >> The reason that I’m interested in this, is that there are a lot of things added to SBML (primarily as notes) which could be represented more formally as annotations with a minimum of extra work. There are examples aplenty in Recon2, path2models and others, but a simple example of annotating a metabolite with charge and inchi string is shown in the linked presentation. >> >> To illustrate how easy it is to implement this with an existing RDF library (Apache Jena), a very simple example of a prototype is available here: >> >> https://dl.dropboxusercontent.com/u/8980329/sbml-annotation.zip >> >> This in Java / JSBML, but C++ RDF parsers are also available. >> >> Finally, there’s also been a question about the overhead involved in supporting "all of RDF”. This certainly isn’t my intention. We can limit what we support by defining an RDF Vocabulary, which means that we control which predicates would be permissible in SBML annotations. It would work as a more formalised version of the current Biomodels qualifiers. An example of an RDF Vocabulary is Dublin Core, which we use already. >> >> I’m pretty sure that this could be implemented fairly quickly if there’s need for this. Some features of this overlap with the proposals for the FBC package, but to me at least it would seem questionable to implement many different methods of annotating elements in different extension packages. >> >> Cheers, >> >> Neil. >> >> Neil Swainston, PhD >> Research Fellow >> >> Manchester Institute of Biotechnology >> University of Manchester >> Manchester M1 7DN >> United Kingdom >> >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Sbml-annot mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-annot > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: Brett G. O. <b.g...@vu...> - 2013-12-17 09:48:31
|
Hi Neil Unfortunately, we didn't get to discuss your proposal at HARMONY with regards to the FBC package but there was some general discussion about annotation. As you know this is a very topical issue within the constraint based modelling community. One interesting observation was that people weren't so worried about the RDF as such but being forced to use a URN/URL identifier - irrespective of whether this was in RDF or an XML key-value pair (although this may be a particular FBC issue) Personally, I am not too worried where the annotation happens, although I really like the type of approach that you advocate with dictionaries and that strict MathML 4.0 uses with OpenMath content dictionaries. However, this framework should happen in finite time, it should be flexible enough to handle a range of data-types and should be coupled to a process such that communities can develop their own identifier resources (in a non-intimidating way). Why this is particularly important (and may simply also be due to my ignorance) is that no ontology or set of ontologies can hold all meta-ainformation that anyone might want to ever annotate a model or model component with ... before they decide to do it. <brett>ducks and runs for cover</brett> On 16/12/13 21:43, Neil Swainston wrote: > Hi Team Annot, > > Is anyone still here?!? And if so, did annotations ever get discussed at COMBINE in Paris? > > I sent Brett and Pedro the following presentation to be gone through in my absence (I was on holiday, see slide 10) but I didn’t hear anything further. > > https://www.dropbox.com/s/bls85iwe1vfwnw4/Annotation%20with%20RDF.ppt > > My basic premise was that, while the previous Annotation proposal that we proposed a couple of years ago perhaps spiralled a little into the world of fantasy, the basic premise of updating the SBML annotation facility to take advantage of more features of RDF is a good one. > > The usual response to claims such as this is to either a) suggest that I am a semantic web / RDF evangelist; and / or b) make some comment that RDF is too complex to support. > > I personally don’t care less about RDF as such - I’m only interested in it in so far as that we’ve started to use it (since Core annotations were proposed) and to me it makes sense to continue rather than start again from scratch. > > The second claim - that RDF is too complex - is as bogus as claiming that XML is too complex. Like XML, RDF is not meant to be written directly but accessed through a third-party reader/writer, like libxml, Xerces, or (in the case of RDF) Apache Jena. > > The reason that I’m interested in this, is that there are a lot of things added to SBML (primarily as notes) which could be represented more formally as annotations with a minimum of extra work. There are examples aplenty in Recon2, path2models and others, but a simple example of annotating a metabolite with charge and inchi string is shown in the linked presentation. > > To illustrate how easy it is to implement this with an existing RDF library (Apache Jena), a very simple example of a prototype is available here: > > https://dl.dropboxusercontent.com/u/8980329/sbml-annotation.zip > > This in Java / JSBML, but C++ RDF parsers are also available. > > Finally, there’s also been a question about the overhead involved in supporting "all of RDF”. This certainly isn’t my intention. We can limit what we support by defining an RDF Vocabulary, which means that we control which predicates would be permissible in SBML annotations. It would work as a more formalised version of the current Biomodels qualifiers. An example of an RDF Vocabulary is Dublin Core, which we use already. > > I’m pretty sure that this could be implemented fairly quickly if there’s need for this. Some features of this overlap with the proposals for the FBC package, but to me at least it would seem questionable to implement many different methods of annotating elements in different extension packages. > > Cheers, > > Neil. > > Neil Swainston, PhD > Research Fellow > > Manchester Institute of Biotechnology > University of Manchester > Manchester M1 7DN > United Kingdom > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot -- Brett G. Olivier PhD Systems Bioinformatics VU University Amsterdam Amsterdam, The Netherlands Email: b.g.olivier[AT]vu[dot]nl Tel (office) +31 20 5987248 |
|
From: Maxwell N. <mneal@u.washington.edu> - 2013-12-16 22:00:42
|
Hi Dagmar and Neil, Cheers to you both for keeping the annotation fire stoked. I am also glad to see the conversation is moving towards RDF-based annotation standards that work across modeling formats. Given this shift, I thought I'd give a brief update on the SemSim effort, which aims to provide a general framework for describing the computational and metadata aspects of biological models. I, along with members of the Virtual Physiological Rat (VPR) community, have been working out how to capture the biological meaning of a model's contents using knowledge representation formats such as RDF and OWL. We have made good progress over the past year and have developed a prototype tool that can be used to annotate the biological semantics of CellML models. I just wanted to make sure this effort is on your radar because the VPR community, which represents folks using CellML, SBML and JSim models, is very much interested in a general approach to model annotation. I'm sure they would want to coordinate their model annotation efforts with those of the greater COMBINE community. Happy annotating! I will be starting a new job in January that doesn't focus on model sharing/annotation/etc. so I won't have much time to participate in future discussions, but I hope that a shared annotation standard that scales across modeling formats eventually comes to fruition. Best, M --------------------------------- Maxwell Neal Post-doctoral researcher Department of Bioengineering University of Washington mn...@uw... --------------------------------- On Dec 16, 2013, at 4:05 PM, Dagmar Waltemath wrote: > Hi Neil, hi annot (?), > > thanks a lot for your mail. > ...and a very brief reply: > > Annotations have been discussed in one session at this year's COMBINE (in the meta-data session on Thursday morning: http://co.mbine.org/events/COMBINE_2013/agenda - specifically http://co.mbine.org/events/COMBINE_2013/agenda?q=system/files/COMBINE2013-Waltemath.pdf). > I advertised there that we should go for a "COMBINE-wide annotation scheme". There was pretty much agreement in the room that such a common scheme would make much more sense than maintaining all the different schemes we currently have (SBML, CellML, SBML packages, SBO scheme...). > But, I have been lazy, or: very busy since COMBINE, so I haven't yet started anything... like, thinking of a good name, creating a project somewhere, and a mailing list, gathering people and starting a discussion on the minimum rules for annotations... > > I see now that you have been very active, so maybe we should use this moment of motivation! Your prototype library could be a good starting point for discussions on the "AnnotII" format. > > The question that remains is: Do we start before or after Christmas (2013)? :) > Dagmar > > PS: I had a look at your slides, they say: COMBINE2013, Paris - I may be completely ignorant, but ... you haven't been there to present these slides, have you? > > > Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, > University of Rostock, D-18051 Rostock, Germany > Web: http://www.sbi.uni-rostock.de/sems > Skype: dagmar.waltemath > > ________________________________________ > Von: Neil Swainston [Nei...@ma...] > Gesendet: Montag, 16. Dezember 2013 21:43 > An: <sbm...@li...> > Betreff: [sbml-annot] Annotation > > Hi Team Annot, > > Is anyone still here?!? And if so, did annotations ever get discussed at COMBINE in Paris? > > I sent Brett and Pedro the following presentation to be gone through in my absence (I was on holiday, see slide 10) but I didn’t hear anything further. > > https://www.dropbox.com/s/bls85iwe1vfwnw4/Annotation%20with%20RDF.ppt > > My basic premise was that, while the previous Annotation proposal that we proposed a couple of years ago perhaps spiralled a little into the world of fantasy, the basic premise of updating the SBML annotation facility to take advantage of more features of RDF is a good one. > > The usual response to claims such as this is to either a) suggest that I am a semantic web / RDF evangelist; and / or b) make some comment that RDF is too complex to support. > > I personally don’t care less about RDF as such - I’m only interested in it in so far as that we’ve started to use it (since Core annotations were proposed) and to me it makes sense to continue rather than start again from scratch. > > The second claim - that RDF is too complex - is as bogus as claiming that XML is too complex. Like XML, RDF is not meant to be written directly but accessed through a third-party reader/writer, like libxml, Xerces, or (in the case of RDF) Apache Jena. > > The reason that I’m interested in this, is that there are a lot of things added to SBML (primarily as notes) which could be represented more formally as annotations with a minimum of extra work. There are examples aplenty in Recon2, path2models and others, but a simple example of annotating a metabolite with charge and inchi string is shown in the linked presentation. > > To illustrate how easy it is to implement this with an existing RDF library (Apache Jena), a very simple example of a prototype is available here: > > https://dl.dropboxusercontent.com/u/8980329/sbml-annotation.zip > > This in Java / JSBML, but C++ RDF parsers are also available. > > Finally, there’s also been a question about the overhead involved in supporting "all of RDF”. This certainly isn’t my intention. We can limit what we support by defining an RDF Vocabulary, which means that we control which predicates would be permissible in SBML annotations. It would work as a more formalised version of the current Biomodels qualifiers. An example of an RDF Vocabulary is Dublin Core, which we use already. > > I’m pretty sure that this could be implemented fairly quickly if there’s need for this. Some features of this overlap with the proposals for the FBC package, but to me at least it would seem questionable to implement many different methods of annotating elements in different extension packages. > > Cheers, > > Neil. > > Neil Swainston, PhD > Research Fellow > > Manchester Institute of Biotechnology > University of Manchester > Manchester M1 7DN > United Kingdom > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Neil S. <Nei...@ma...> - 2013-12-16 21:14:44
|
Hi Dagmar, Thanks for the mail and the links to the COMBINE videos and presentations. Without getting too far into the techie details of this, a big +1, thumbs-up, Facebook-like and Retweet for the following: > I advertised there that we should go for a "COMBINE-wide annotation scheme". There was pretty much agreement in the room that such a common scheme would make much more sense than maintaining all the different schemes we currently have (SBML, CellML, SBML packages, SBO scheme…). How exactly we do this, I’m less bothered about (until after Xmas, at least). Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 16 Dec 2013, at 21:05, Dagmar Waltemath <dag...@un...<mailto:dag...@un...>> wrote: Hi Neil, hi annot (?), thanks a lot for your mail. ...and a very brief reply: Annotations have been discussed in one session at this year's COMBINE (in the meta-data session on Thursday morning: http://co.mbine.org/events/COMBINE_2013/agenda - specifically http://co.mbine.org/events/COMBINE_2013/agenda?q=system/files/COMBINE2013-Waltemath.pdf). I advertised there that we should go for a "COMBINE-wide annotation scheme". There was pretty much agreement in the room that such a common scheme would make much more sense than maintaining all the different schemes we currently have (SBML, CellML, SBML packages, SBO scheme...). But, I have been lazy, or: very busy since COMBINE, so I haven't yet started anything... like, thinking of a good name, creating a project somewhere, and a mailing list, gathering people and starting a discussion on the minimum rules for annotations... I see now that you have been very active, so maybe we should use this moment of motivation! Your prototype library could be a good starting point for discussions on the "AnnotII" format. The question that remains is: Do we start before or after Christmas (2013)? :) Dagmar PS: I had a look at your slides, they say: COMBINE2013, Paris - I may be completely ignorant, but ... you haven't been there to present these slides, have you? Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, University of Rostock, D-18051 Rostock, Germany Web: http://www.sbi.uni-rostock.de/sems Skype: dagmar.waltemath ________________________________________ Von: Neil Swainston [Nei...@ma...<mailto:Nei...@ma...>] Gesendet: Montag, 16. Dezember 2013 21:43 An: <sbm...@li...<mailto:sbm...@li...>> Betreff: [sbml-annot] Annotation Hi Team Annot, Is anyone still here?!? And if so, did annotations ever get discussed at COMBINE in Paris? I sent Brett and Pedro the following presentation to be gone through in my absence (I was on holiday, see slide 10) but I didn’t hear anything further. https://www.dropbox.com/s/bls85iwe1vfwnw4/Annotation%20with%20RDF.ppt My basic premise was that, while the previous Annotation proposal that we proposed a couple of years ago perhaps spiralled a little into the world of fantasy, the basic premise of updating the SBML annotation facility to take advantage of more features of RDF is a good one. The usual response to claims such as this is to either a) suggest that I am a semantic web / RDF evangelist; and / or b) make some comment that RDF is too complex to support. I personally don’t care less about RDF as such - I’m only interested in it in so far as that we’ve started to use it (since Core annotations were proposed) and to me it makes sense to continue rather than start again from scratch. The second claim - that RDF is too complex - is as bogus as claiming that XML is too complex. Like XML, RDF is not meant to be written directly but accessed through a third-party reader/writer, like libxml, Xerces, or (in the case of RDF) Apache Jena. The reason that I’m interested in this, is that there are a lot of things added to SBML (primarily as notes) which could be represented more formally as annotations with a minimum of extra work. There are examples aplenty in Recon2, path2models and others, but a simple example of annotating a metabolite with charge and inchi string is shown in the linked presentation. To illustrate how easy it is to implement this with an existing RDF library (Apache Jena), a very simple example of a prototype is available here: https://dl.dropboxusercontent.com/u/8980329/sbml-annotation.zip This in Java / JSBML, but C++ RDF parsers are also available. Finally, there’s also been a question about the overhead involved in supporting "all of RDF”. This certainly isn’t my intention. We can limit what we support by defining an RDF Vocabulary, which means that we control which predicates would be permissible in SBML annotations. It would work as a more formalised version of the current Biomodels qualifiers. An example of an RDF Vocabulary is Dublin Core, which we use already. I’m pretty sure that this could be implemented fairly quickly if there’s need for this. Some features of this overlap with the proposals for the FBC package, but to me at least it would seem questionable to implement many different methods of annotating elements in different extension packages. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Sbml-annot mailing list Sbm...@li... https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Dagmar W. <dag...@un...> - 2013-12-16 21:05:53
|
Hi Neil, hi annot (?), thanks a lot for your mail. ...and a very brief reply: Annotations have been discussed in one session at this year's COMBINE (in the meta-data session on Thursday morning: http://co.mbine.org/events/COMBINE_2013/agenda - specifically http://co.mbine.org/events/COMBINE_2013/agenda?q=system/files/COMBINE2013-Waltemath.pdf). I advertised there that we should go for a "COMBINE-wide annotation scheme". There was pretty much agreement in the room that such a common scheme would make much more sense than maintaining all the different schemes we currently have (SBML, CellML, SBML packages, SBO scheme...). But, I have been lazy, or: very busy since COMBINE, so I haven't yet started anything... like, thinking of a good name, creating a project somewhere, and a mailing list, gathering people and starting a discussion on the minimum rules for annotations... I see now that you have been very active, so maybe we should use this moment of motivation! Your prototype library could be a good starting point for discussions on the "AnnotII" format. The question that remains is: Do we start before or after Christmas (2013)? :) Dagmar PS: I had a look at your slides, they say: COMBINE2013, Paris - I may be completely ignorant, but ... you haven't been there to present these slides, have you? Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, University of Rostock, D-18051 Rostock, Germany Web: http://www.sbi.uni-rostock.de/sems Skype: dagmar.waltemath ________________________________________ Von: Neil Swainston [Nei...@ma...] Gesendet: Montag, 16. Dezember 2013 21:43 An: <sbm...@li...> Betreff: [sbml-annot] Annotation Hi Team Annot, Is anyone still here?!? And if so, did annotations ever get discussed at COMBINE in Paris? I sent Brett and Pedro the following presentation to be gone through in my absence (I was on holiday, see slide 10) but I didn’t hear anything further. https://www.dropbox.com/s/bls85iwe1vfwnw4/Annotation%20with%20RDF.ppt My basic premise was that, while the previous Annotation proposal that we proposed a couple of years ago perhaps spiralled a little into the world of fantasy, the basic premise of updating the SBML annotation facility to take advantage of more features of RDF is a good one. The usual response to claims such as this is to either a) suggest that I am a semantic web / RDF evangelist; and / or b) make some comment that RDF is too complex to support. I personally don’t care less about RDF as such - I’m only interested in it in so far as that we’ve started to use it (since Core annotations were proposed) and to me it makes sense to continue rather than start again from scratch. The second claim - that RDF is too complex - is as bogus as claiming that XML is too complex. Like XML, RDF is not meant to be written directly but accessed through a third-party reader/writer, like libxml, Xerces, or (in the case of RDF) Apache Jena. The reason that I’m interested in this, is that there are a lot of things added to SBML (primarily as notes) which could be represented more formally as annotations with a minimum of extra work. There are examples aplenty in Recon2, path2models and others, but a simple example of annotating a metabolite with charge and inchi string is shown in the linked presentation. To illustrate how easy it is to implement this with an existing RDF library (Apache Jena), a very simple example of a prototype is available here: https://dl.dropboxusercontent.com/u/8980329/sbml-annotation.zip This in Java / JSBML, but C++ RDF parsers are also available. Finally, there’s also been a question about the overhead involved in supporting "all of RDF”. This certainly isn’t my intention. We can limit what we support by defining an RDF Vocabulary, which means that we control which predicates would be permissible in SBML annotations. It would work as a more formalised version of the current Biomodels qualifiers. An example of an RDF Vocabulary is Dublin Core, which we use already. I’m pretty sure that this could be implemented fairly quickly if there’s need for this. Some features of this overlap with the proposals for the FBC package, but to me at least it would seem questionable to implement many different methods of annotating elements in different extension packages. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Sbml-annot mailing list Sbm...@li... https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Neil S. <Nei...@ma...> - 2013-12-16 20:43:38
|
Hi Team Annot, Is anyone still here?!? And if so, did annotations ever get discussed at COMBINE in Paris? I sent Brett and Pedro the following presentation to be gone through in my absence (I was on holiday, see slide 10) but I didn’t hear anything further. https://www.dropbox.com/s/bls85iwe1vfwnw4/Annotation%20with%20RDF.ppt My basic premise was that, while the previous Annotation proposal that we proposed a couple of years ago perhaps spiralled a little into the world of fantasy, the basic premise of updating the SBML annotation facility to take advantage of more features of RDF is a good one. The usual response to claims such as this is to either a) suggest that I am a semantic web / RDF evangelist; and / or b) make some comment that RDF is too complex to support. I personally don’t care less about RDF as such - I’m only interested in it in so far as that we’ve started to use it (since Core annotations were proposed) and to me it makes sense to continue rather than start again from scratch. The second claim - that RDF is too complex - is as bogus as claiming that XML is too complex. Like XML, RDF is not meant to be written directly but accessed through a third-party reader/writer, like libxml, Xerces, or (in the case of RDF) Apache Jena. The reason that I’m interested in this, is that there are a lot of things added to SBML (primarily as notes) which could be represented more formally as annotations with a minimum of extra work. There are examples aplenty in Recon2, path2models and others, but a simple example of annotating a metabolite with charge and inchi string is shown in the linked presentation. To illustrate how easy it is to implement this with an existing RDF library (Apache Jena), a very simple example of a prototype is available here: https://dl.dropboxusercontent.com/u/8980329/sbml-annotation.zip This in Java / JSBML, but C++ RDF parsers are also available. Finally, there’s also been a question about the overhead involved in supporting "all of RDF”. This certainly isn’t my intention. We can limit what we support by defining an RDF Vocabulary, which means that we control which predicates would be permissible in SBML annotations. It would work as a more formalised version of the current Biomodels qualifiers. An example of an RDF Vocabulary is Dublin Core, which we use already. I’m pretty sure that this could be implemented fairly quickly if there’s need for this. Some features of this overlap with the proposals for the FBC package, but to me at least it would seem questionable to implement many different methods of annotating elements in different extension packages. Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom |
|
From: Neil S. <Nei...@ma...> - 2013-09-16 08:07:27
|
Hi Jeremy, Your approach looks entirely sensible and pragmatic. The major problem that we're facing at the moment is that the COBRA Toolbox has implemented its own representation of annotations through the notes field. As you know, though, the COBRA Toolbox is by far the most used software for constraint-based modelling, so we need to maintain support. However, many of these issues will be discussed at the COMBINE meeting in Paris this week. The goal is to decide upon a method for marking up all of the fields that are parsed by the COBRA Toolbox (and other software) in some sensible, sustainable, agreed-upon manner, and then provide the COBRA Toolbox team with updated parsers that implement these standards, while also maintaining backwards compatibility with the many existing models that are in circulation. So, in summary, I'd refrain from making any changes to your code until a decision is made as to what and how we are to represent annotations in the context of constraint-based models. If you have any opinions on this, then obviously we'd be very happy to hear them. Best wishes, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 12 Sep 2013, at 20:07, Jeremy Zucker <dji...@gm...<mailto:dji...@gm...>> wrote: Hi folks, As the author of the Neurospora SBML file that Ben Heavner cited, I would be happy to rewrite the annotations to fit whatever is decided upon by the community. The fields that I used to decorate the species and reactions were split amongst the notes and annotations fields because it wasn't clear to me what software would use what. Some software (such as COBRA Toolbox) only parses Notes fields. Other software packages ignore Notes fields (as they should), and concentrate on the RDF annotations instead. As a compromise, I try to give each software package what they want. For COBRAToolbox users the Species Notes I provided were as follows: species_notes = """<html xmlns='http://www.w3.org/1999/xhtml'> <p>FORMULA: %s</p> <p>BIOCYC: %s</p> <p>CHARGE: %d</p> <p>KEGG: %s</p> <p>SMILES: %s</p> </html>""" For folks who just want the database identifiers in RDF, the species annotation I provided are as follows: species_annotation = """ <rdf:RDF xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol=" http://biomodels.net/biology-qualifiers/" > <rdf:Description rdf:about="#%s"> <bqbiol:is> <rdf:Bag> <rdf:li rdf:resource="urn:miriam:biocyc:NC10:%s"/> <rdf:li rdf:resource="urn:miriam:pubchem:%s"/> <rdf:li rdf:resource="urn:miriam:chebi:%s"/> <rdf:li rdf:resource="urn:miriam:cas:%s"/> </rdf:Bag> </bqbiol:is> </rdf:Description> <rdf:Description rdf:about="#%s"> <in:inchi xmlns:in="http://biomodels.net/inchi" metaid="#%s">%s</in:inchi> </rdf:Description> </rdf:RDF>""" As an aside, I did not put SMILES in the species_annotation string because I could not find a MIRIAM URN for it. The reaction annotations I provided were as follows: rxn_annotation = """ <rdf:RDF xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol=" http://biomodels.net/biology-qualifiers/" > <rdf:Description rdf:about="#%s"> <bqbiol:is> <rdf:Bag> <rdf:li rdf:resource="urn:miriam:obo.chebi:biocyc:NC10:%s"/> </rdf:Bag> </bqbiol:is> %s </rdf:Description> """ If you have any recommendations as to how I should use identifiers.org<http://identifiers.org> or MIRIAM namespaces better, I am definitely open to modifying my code. Sincerely, Jeremy "Any sufficiently complex system is hackable" http://www.asofterworld.com/index.php?id=300 ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk _______________________________________________ Sbml-annot mailing list Sbm...@li... https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Jeremy Z. <dji...@gm...> - 2013-09-12 19:08:22
|
Hi folks,
As the author of the Neurospora SBML file that Ben Heavner cited, I would
be happy to rewrite the annotations to fit whatever is decided upon by the
community.
The fields that I used to decorate the species and reactions were split
amongst the notes and annotations fields because it wasn't clear to me what
software would use what.
Some software (such as COBRA Toolbox) only parses Notes fields. Other
software packages ignore Notes fields (as they should), and concentrate on
the RDF annotations instead.
As a compromise, I try to give each software package what they want.
For COBRAToolbox users the Species Notes I provided were as follows:
species_notes = """<html xmlns='http://www.w3.org/1999/xhtml'>
<p>FORMULA: %s</p>
<p>BIOCYC: %s</p>
<p>CHARGE: %d</p>
<p>KEGG: %s</p>
<p>SMILES: %s</p>
</html>"""
For folks who just want the database identifiers in RDF, the species
annotation I provided are as follows:
species_annotation = """ <rdf:RDF xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol="
http://biomodels.net/biology-qualifiers/" >
<rdf:Description rdf:about="#%s">
<bqbiol:is>
<rdf:Bag>
<rdf:li rdf:resource="urn:miriam:biocyc:NC10:%s"/>
<rdf:li rdf:resource="urn:miriam:pubchem:%s"/>
<rdf:li rdf:resource="urn:miriam:chebi:%s"/>
<rdf:li rdf:resource="urn:miriam:cas:%s"/>
</rdf:Bag>
</bqbiol:is>
</rdf:Description>
<rdf:Description rdf:about="#%s">
<in:inchi xmlns:in="http://biomodels.net/inchi"
metaid="#%s">%s</in:inchi>
</rdf:Description>
</rdf:RDF>"""
As an aside, I did not put SMILES in the species_annotation string because
I could not find a MIRIAM URN for it.
The reaction annotations I provided were as follows:
rxn_annotation = """ <rdf:RDF xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:bqbiol="
http://biomodels.net/biology-qualifiers/" >
<rdf:Description rdf:about="#%s">
<bqbiol:is>
<rdf:Bag>
<rdf:li rdf:resource="urn:miriam:obo.chebi:biocyc:NC10:%s"/>
</rdf:Bag>
</bqbiol:is>
%s
</rdf:Description>
"""
If you have any recommendations as to how I should use identifiers.org or
MIRIAM namespaces better, I am definitely open to modifying my code.
Sincerely,
Jeremy
"Any sufficiently complex system is hackable"
http://www.asofterworld.com/index.php?id=300
|
|
From: Kieran S. <Kie...@ma...> - 2013-07-25 10:47:28
|
As Nicolas pointed out, there are existing Miriam/identifiers.org methodologies for supporting controlled annotation of most of the keys in these notes fields already (BIOCYC, KEGG, REFERENCES). Some of the other keys are just notes and should remain that way (NOTES, WHAT_I_HAD_FOR_BREAKFAST) and there's a final set of keys dealt with specifically by the FBC package (GENE_ASSOCIATION, CHARGE). What are the other keys that we would like to annotate, but are unable to do with the current setup? k On 24 Jul 2013, at 17:32, Ben Heavner wrote: > Sorry, I didn't mean to suggest that the Neurospora model is how it should be done, or that any of the custom notes I've compiled on the google doc spreadsheet I built are good, should be directly supported by SBML standardization of custom notes fields, or are the right way to do things. Rather, as Brett pointed out, it's an example of how things are meandering in the absence of a good way to do it, and demonstration that people are putting custom key:value pairs in notes fields at the moment. > > I wholeheartedly agree that these annotations are better machine parsed than intended to be human readable, and so should be moved out of the notes field. My efforts to modify the COBRA Toolbox to deal with these fields better is part of instigated this round of discussion. > > And I do rather like the "what I had for breakfast: 2.5 eggs" example. :) > > -b > > > On Wed, Jul 24, 2013 at 7:44 AM, Nicolas Le Novere <n.l...@gm...> wrote: > Hello, > > Why not using the usual SBML controlled annotation for BIOCYC, KEGG and REFERENCES? They would then be available to all tools supporting MIRIAM annotations. If using the Identifiers.org versions, they would even become resolvable and provide direct access. > > If you want, in addition, to add notes so they are visible for instance in a webrowser, this is understandable. But there as well, you should use Identifiers.org forms instead of proprietary forms. That way, your notes will be resolvable. |
|
From: Nicolas Le N. <n.l...@gm...> - 2013-07-24 21:43:18
|
On 24/07/13 22:01, David Nickerson wrote: > Not sure I am a big fan of tying the annotation to the COMBINE > archive, which is just a convenient way to package up specific > revisions of a particular (sub-)set of data for a certain purpose. But > this is something we can discuss at COMBINE. Hi David, I do not think anybody is proposing to "tie" the metadata file to the archive. Once we have a mechanism to link metadata (i.e. statements) to description elements, they can live anywhere. -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
|
From: David N. <dav...@gm...> - 2013-07-24 21:01:41
|
just to add my +1 to discussing this at COMBINE, its certainly the way we have been moving with annotating CellML models (at least, the way we have been thinking about annotating models, not a lot of actual annotation going on). Not sure I am a big fan of tying the annotation to the COMBINE archive, which is just a convenient way to package up specific revisions of a particular (sub-)set of data for a certain purpose. But this is something we can discuss at COMBINE. Cheers, David. On Wed, Jul 24, 2013 at 10:47 PM, Nicolas Le Novere <n.l...@gm...> wrote: > Hello all, > > Thank-you to Dagmar for rebooting this effort. I think metadata are > becoming ever more important in computational systems biology. I have a > slightly different take on the approach though. When we started the > discussions about the annotation package, we had a few precise > requirements. More appeared during the discussions, as well as grand > ambitions. That led to the realisation that maybe we should go towards OWL2 > etc. and finally to an arrest of the development. > > Since the SBML annotation meeting, two things happened that IMHO change a > bit the context and the path we want to take. > > Firstly, there is a general movement to move metadata into the realm of > semantic web, and provide them in triple stores, or at least made them > available through SPARQL end points. This is for instance going full swing > at the EBI, and BioModels Db in involved in the process, meaning that its > SBML annotations will be externalised. > > Secondly, the COMBINE/OMEX archive has become a reality, with the > development of packages that encapsulate all the files necessary for > understanding and processing a model. It has been proposed that the > metadata related to the content of an archive be expressed in RDF in a > separate file. > > IMHO, this is the proper way to go. If we want all the COMBINE formats > (SBML, SED-ML, CellML and soon NeuroML) to share the same metadata, having > a format independent specification is much better than duplicating this > metadata specification in every language spec. It would also free this > metadata specification from the constraints of each particular model format > effort. Finally, it could be a proper RDF file (whatever flavour). For > instance, we would just have to define which vocabularies to use, rather > than defining the structure of the metadata at the XML level, as we do in SBML. > > The consequences is that we should not necessarily have an SBML Level 3 > package. Instead, we could "fix" the SBML controlled annotations to > facilitate its use. All the major developments, that would not go in the > Core controlled annotation, would rather be food for the COMBINE archive. > BUT, it is important to remember that anything can be included as an SBML > annotation. So such a metadata file could always be included in an SBML > file (e.g. in the annotation of the model element). > > I think we definitively need sessions in COMBINE to discuss that. > > Cheers > > -- > Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT > Tel: +441223496433 Mob:+447833147074 n.l...@gm... > orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ > Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ > > > > _______________________________________________ > Combine-discuss mailing list > Com...@eb... > http://listserver.ebi.ac.uk/mailman/listinfo/combine-discuss |
|
From: Michel D. <mic...@gm...> - 2013-07-24 17:24:24
|
Nicolas, > > Then there is the whole archive metadata. This requires a wider audience > agreement. On the other side, there are less structural constraints, which > may make the progress easier. as you are aware, we are currently working to generate a standardized description of datasets [1], which incorporates the needs of several communities (HCLS, BioDBCore, Bio2RDF, OpenPhacts, identifiers.org, integbio). Our work will extend that of openphacts's dataset description [2], along with their editor [3] and validator. We would be interested in hearing about the fields that you want to collect information on! m. [1] http://tinyurl.com/datasetdescription [2] http://www.openphacts.org/specs/datadesc/#dataset-decscription [3] http://openphacts.cs.man.ac.uk/Void-Editor/ -- Michel Dumontier Associate Professor of Bioinformatics, Carleton University Chair, W3C Semantic Web for Health Care and the Life Sciences Interest Group http://dumontierlab.com |
|
From: Ben H. <Ben...@sy...> - 2013-07-24 16:33:07
|
Sorry, I didn't mean to suggest that the Neurospora model is how it should be done, or that any of the custom notes I've compiled on the google doc spreadsheet I built are good, should be directly supported by SBML standardization of custom notes fields, or are the right way to do things. Rather, as Brett pointed out, it's an example of how things are meandering in the absence of a good way to do it, and demonstration that people are putting custom key:value pairs in notes fields at the moment. I wholeheartedly agree that these annotations are better machine parsed than intended to be human readable, and so should be moved out of the notes field. My efforts to modify the COBRA Toolbox to deal with these fields better is part of instigated this round of discussion. And I do rather like the "what I had for breakfast: 2.5 eggs" example. :) -b On Wed, Jul 24, 2013 at 7:44 AM, Nicolas Le Novere <n.l...@gm...>wrote: > Hello, > > Why not using the usual SBML controlled annotation for BIOCYC, KEGG and > REFERENCES? They would then be available to all tools supporting MIRIAM > annotations. If using the Identifiers.org versions, they would even become > resolvable and provide direct access. > > If you want, in addition, to add notes so they are visible for instance in > a webrowser, this is understandable. But there as well, you should use > Identifiers.org forms instead of proprietary forms. That way, your notes > will be resolvable. > > > On 22/07/13 17:55, Ben Heavner wrote: > >> FYI, a new model for the metabolic network of Neurospora was just >> published >> - >> http://www.ploscompbiol.org/**article/info%3Adoi%2F10.1371%** >> 2Fjournal.pcbi.1003126<http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fjournal.pcbi.1003126> >> >> It adds the following notes fields: BIOCYC, KEGG, REFERENCES. >> >> Additionally, it adds an extra layer of parsing of identifiers: "To avoid >> using characters disallowed in SBML identifiers, we implemented a >> substitution scheme. We substituted disallowed characters with their ASCII >> equivalent, demarcated on both sides by two underscores. For example, “[” >> has ASCII value 91, so it was substituted by “__91__”. Identifiers >> beginning with a number were given a prefix of underscore; e.g. “1diacyl” >> became “_1diacyl”. So that our SBML file can be reversed-transformed into >> its original character encoding, we wrote an extension to the COBRA >> toolbox >> in Matlab." >> >> -b >> >> >> On Mon, Jul 22, 2013 at 3:53 AM, Brett G. Olivier <b.g...@vu... >> <mailto:b.g...@vu...>> wrote: >> >> Hi Neil and friends >> >> >> On 22/07/13 11:15, Neil Swainston wrote: >> >>> >>> Good to hear from you and very timely, this. The future or otherwise >>> of the Annot package is being separately discussed privately with >>> Brett, Sarah, Frank, Kieran and Ben Heavner but under the umbrella of >>> looking at annotations relevant to the FBC package. >>> >>> I've been banging on about the applicability of using RDF/XML in this >>> context, but this approach was met with less enthusiasm by the >>> others, who proposed a proprietary approach. >>> >>> >> Just to put this in a bit more context , the discussion was started >> from within an FBC context where it was felt that including a generic >> RDF annotation mechanism in FBC just to encode the current COBRA >> annotations (the problem we have right now) was not particularly >> useful. A short summary of that (ongoing) discussion lives here: >> http://tinyurl.com/mcqlzsh >> >> >> My main concern, now, though, is that we fragment into some >>> semi-controlled anarchy, with the old L2 annotation, a new Annot >>> package, existing COBRA notes-based annotations and new FBC >>> annotations coexisting. I'm not sure how we'd be able to sell that to >>> newbies who are considering the use of SBML for the first time. >>> >>> >> This is an extremely valid point, however, while the question of the >> FBC/COBRA annotations would probably fit in an Annot package, while >> this does not exist we had to trade-off proliferation of the current >> COBRA solution with "what could be". >> >> >> Whether we go with RDF / something proprietary / OWL / a partridge in >>> a pear tree, I'm not really bothered. But I do think that we need to >>> work together to produce a single solution, otherwise the naysayers >>> that suggested that SBML will begin to fragment with the introduction >>> of extension packages may begin to feel that they were right. >>> >>> >> I also don't really mind what form it takes, we could of course put >> the FBC specific discussions on hold for now and dive into an Annot >> package reboot, especially, since we now have a very concrete use case >> for it ... >> >> Brett >> >> >> Cheers, >>> >>> Neil. >>> >>> Neil Swainston, PhD >>> Research Fellow >>> >>> Manchester Institute of Biotechnology >>> University of Manchester >>> Manchester M1 7DN >>> United Kingdom >>> >>> On 21 Jul 2013, at 08:24, Dagmar Waltemath >>> <dagmar.waltemath@uni-rostock.**de <dag...@un...> >>> <mailto:dagmar.waltemath@uni-**rostock.de<dag...@un...> >>> >> >>> wrote: >>> >>> Hi Nicolas, >>>> (cc: others: for your information) >>>> >>>> I am forwarding a mail regarding the annot package that I had sent >>>> to Neil, Allyson and Mike yesterday. Thought you may also be >>>> interested. (Sorry for not cc:ing you in the first place.) >>>> >>>> Dagmar >>>> >>>> >>>> Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, >>>> University of Rostock, D-18051 Rostock, Germany >>>> Web: http://www.sbi.uni-rostock.de >>>> Skype: dagmar.waltemath >>>> >>>> ______________________________**__________ >>>> Von: Dagmar Waltemath >>>> Gesendet: Freitag, 19. Juli 2013 21:04 >>>> An: a.l...@ne... <mailto:a.l.lister@newcastle.**ac.uk<a.l...@ne...> >>>> >; >>>> Neil Swainston [nei...@ma....**uk<nei...@ma...> >>>> <mailto:neil.swainston@**manchester.ac.uk<nei...@ma...> >>>> >] >>>> >>>> Cc: Michael Hucka >>>> Betreff: Annot package >>>> >>>> Hi Allyson, hi Neil, >>>> (cc: Mike) >>>> >>>> I am writing concerning the annot package today. I have repeatedly >>>> received questions about the state of both, SBML and CellML >>>> annotations and I keep on saying: We're working on improving it. But >>>> I realised: This is not quite true :) >>>> >>>> Recently I sat down with Robert Hoehndorf and my PhD student, >>>> Martin, to figure out how to put annotations in CellML. On the ICBO >>>> meeting I then spoke to John Gennari (independently of the above), >>>> who also has annotations for CellML models (but not in PMR...), and >>>> David Nickerson confirmed in a recent Skype call that all was a bit >>>> of a mess currently... >>>> >>>> Thus I think it is time to fix the annotation question and build a >>>> proper annotation package, ideally one that could be used with both >>>> SBML and CellML. I would like to push this during COMBINE in >>>> September this year. >>>> >>>> My mail now is to ask you how much you would like to be involved in >>>> this, and in what ways? >>>> >>>> @Mike, maybe you also have updates on annot from the SBML side? >>>> Also, do you know who should be involved when re-launching the work >>>> on annotations? And, maybe most importantly, do you support the idea >>>> of re-booting annot now? >>>> >>>> With kind regards, >>>> Dagmar >>>> >>>> PS: Anyone of you eventually at ISMB in Berlin this week? Then drop >>>> me a line and we could talk about this in person :) >>>> >>>> >>>> Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, >>>> University of Rostock, D-18051 Rostock, Germany >>>> Web: http://www.sbi.uni-rostock.de >>>> Skype: dagmar.waltemath >>>> >>> >>> >> -- >> Brett G. Olivier PhD >> >> Systems Bioinformatics >> VU University Amsterdam >> Amsterdam, The Netherlands >> >> Email: b.g.olivier[AT]vu[dot]nl >> Tel (office) +31 20 5987248 >> >> >> > > -- > Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT > Tel: +441223496433 Mob:+447833147074 n.l...@gm... > orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/**lenov/<http://lenoverelab.org/perso/lenov/> > Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ > > > > |
|
From: Nicolas Le N. <n.l...@gm...> - 2013-07-24 14:44:34
|
Hello, Why not using the usual SBML controlled annotation for BIOCYC, KEGG and REFERENCES? They would then be available to all tools supporting MIRIAM annotations. If using the Identifiers.org versions, they would even become resolvable and provide direct access. If you want, in addition, to add notes so they are visible for instance in a webrowser, this is understandable. But there as well, you should use Identifiers.org forms instead of proprietary forms. That way, your notes will be resolvable. On 22/07/13 17:55, Ben Heavner wrote: > FYI, a new model for the metabolic network of Neurospora was just published > - > http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fjournal.pcbi.1003126 > > It adds the following notes fields: BIOCYC, KEGG, REFERENCES. > > Additionally, it adds an extra layer of parsing of identifiers: "To avoid > using characters disallowed in SBML identifiers, we implemented a > substitution scheme. We substituted disallowed characters with their ASCII > equivalent, demarcated on both sides by two underscores. For example, “[” > has ASCII value 91, so it was substituted by “__91__”. Identifiers > beginning with a number were given a prefix of underscore; e.g. “1diacyl” > became “_1diacyl”. So that our SBML file can be reversed-transformed into > its original character encoding, we wrote an extension to the COBRA toolbox > in Matlab." > > -b > > > On Mon, Jul 22, 2013 at 3:53 AM, Brett G. Olivier <b.g...@vu... > <mailto:b.g...@vu...>> wrote: > > Hi Neil and friends > > > On 22/07/13 11:15, Neil Swainston wrote: >> >> Good to hear from you and very timely, this. The future or otherwise >> of the Annot package is being separately discussed privately with >> Brett, Sarah, Frank, Kieran and Ben Heavner but under the umbrella of >> looking at annotations relevant to the FBC package. >> >> I've been banging on about the applicability of using RDF/XML in this >> context, but this approach was met with less enthusiasm by the >> others, who proposed a proprietary approach. >> > > Just to put this in a bit more context , the discussion was started > from within an FBC context where it was felt that including a generic > RDF annotation mechanism in FBC just to encode the current COBRA > annotations (the problem we have right now) was not particularly > useful. A short summary of that (ongoing) discussion lives here: > http://tinyurl.com/mcqlzsh > > >> My main concern, now, though, is that we fragment into some >> semi-controlled anarchy, with the old L2 annotation, a new Annot >> package, existing COBRA notes-based annotations and new FBC >> annotations coexisting. I'm not sure how we'd be able to sell that to >> newbies who are considering the use of SBML for the first time. >> > > This is an extremely valid point, however, while the question of the > FBC/COBRA annotations would probably fit in an Annot package, while > this does not exist we had to trade-off proliferation of the current > COBRA solution with "what could be". > > >> Whether we go with RDF / something proprietary / OWL / a partridge in >> a pear tree, I'm not really bothered. But I do think that we need to >> work together to produce a single solution, otherwise the naysayers >> that suggested that SBML will begin to fragment with the introduction >> of extension packages may begin to feel that they were right. >> > > I also don't really mind what form it takes, we could of course put > the FBC specific discussions on hold for now and dive into an Annot > package reboot, especially, since we now have a very concrete use case > for it ... > > Brett > > >> Cheers, >> >> Neil. >> >> Neil Swainston, PhD >> Research Fellow >> >> Manchester Institute of Biotechnology >> University of Manchester >> Manchester M1 7DN >> United Kingdom >> >> On 21 Jul 2013, at 08:24, Dagmar Waltemath >> <dag...@un... >> <mailto:dag...@un...>> >> wrote: >> >>> Hi Nicolas, >>> (cc: others: for your information) >>> >>> I am forwarding a mail regarding the annot package that I had sent >>> to Neil, Allyson and Mike yesterday. Thought you may also be >>> interested. (Sorry for not cc:ing you in the first place.) >>> >>> Dagmar >>> >>> >>> Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, >>> University of Rostock, D-18051 Rostock, Germany >>> Web: http://www.sbi.uni-rostock.de >>> Skype: dagmar.waltemath >>> >>> ________________________________________ >>> Von: Dagmar Waltemath >>> Gesendet: Freitag, 19. Juli 2013 21:04 >>> An: a.l...@ne... <mailto:a.l...@ne...>; >>> Neil Swainston [nei...@ma... >>> <mailto:nei...@ma...>] >>> Cc: Michael Hucka >>> Betreff: Annot package >>> >>> Hi Allyson, hi Neil, >>> (cc: Mike) >>> >>> I am writing concerning the annot package today. I have repeatedly >>> received questions about the state of both, SBML and CellML >>> annotations and I keep on saying: We're working on improving it. But >>> I realised: This is not quite true :) >>> >>> Recently I sat down with Robert Hoehndorf and my PhD student, >>> Martin, to figure out how to put annotations in CellML. On the ICBO >>> meeting I then spoke to John Gennari (independently of the above), >>> who also has annotations for CellML models (but not in PMR...), and >>> David Nickerson confirmed in a recent Skype call that all was a bit >>> of a mess currently... >>> >>> Thus I think it is time to fix the annotation question and build a >>> proper annotation package, ideally one that could be used with both >>> SBML and CellML. I would like to push this during COMBINE in >>> September this year. >>> >>> My mail now is to ask you how much you would like to be involved in >>> this, and in what ways? >>> >>> @Mike, maybe you also have updates on annot from the SBML side? >>> Also, do you know who should be involved when re-launching the work >>> on annotations? And, maybe most importantly, do you support the idea >>> of re-booting annot now? >>> >>> With kind regards, >>> Dagmar >>> >>> PS: Anyone of you eventually at ISMB in Berlin this week? Then drop >>> me a line and we could talk about this in person :) >>> >>> >>> Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics, >>> University of Rostock, D-18051 Rostock, Germany >>> Web: http://www.sbi.uni-rostock.de >>> Skype: dagmar.waltemath >> > > -- > Brett G. Olivier PhD > > Systems Bioinformatics > VU University Amsterdam > Amsterdam, The Netherlands > > Email: b.g.olivier[AT]vu[dot]nl > Tel (office) +31 20 5987248 > > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 n.l...@gm... orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/ Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/ |
