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: Nicolas Le N. <n.l...@gm...> - 2013-07-24 13:52:03
|
On 24/07/13 12:30, Dagmar Waltemath wrote: > Neil, the way I understood Nicolas we would have a specification for metadata in general, and this specification would include guidelines on which CV to use for all different kinds of metadata, including the ones for the model itself (e.g., dcterms) and the model entities (e.g., EC terms)... and probably more ;) Absolutely. The other thing is that the page on the website was meant to be a collection of ideas rather than a bona fide spec. And also, the metadata was a bit peripheral. But I see it is not anymore. I discovered another implementation today that took the examples provided as God's words. So we need to improve the page in order to be good disciples. -- 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-07-24 13:40:15
|
On 24/07/13 14:06, Neil Swainston wrote: > Hi all, > > This discussion seems to deal with perhaps a longer time frame than the > immediate requirement to add structured annotations to FBC models. I'm > aware that Brett and Frank, with help from Ben, are quickly iterating > towards a solution for this, and I'm conscious that looking at longer term > goals may delay this. > > Maybe these two discussions can carry on running in parallel? Absolutely. We are talking about two, and even three different activities. FBC specific annotations are FBC business. I would suggest to expand the FBC specification to add the specific annotation layer. It could be for instance added another RDF Description element in the annotation elements. Alternatively, it could be another top level element in the Annotation element. I personaly think using the notes element for that is not a very good or sustainable idea. But that is to the FBC PWG to discuss. In any case, within any of those, I would strongly advise to re-use existing vocabularies rather than making up FBC-specific terminology. E.g., rather than using "REFERENCES", use "dc:references" (defined as http://purl.org/dc/terms/references, or at least dc being defined as http://dublincore.org/documents/dcmi-terms/) followed by the relevant Identifiers.org (PubMed, DOI, ISSN, URL etc.) This does not require changing the SBML Core or interacting with other efforts. Then there is the work on the SBML Core annotation. This involve agreement at the level of SBML. 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. > Cheers, > > Neil. > > Neil Swainston, PhD > Research Fellow > > Manchester Institute of Biotechnology > University of Manchester > Manchester M1 7DN > United Kingdom > > On 24 Jul 2013, at 12:30, Dagmar Waltemath <dag...@un... > <mailto:dag...@un...>> wrote: > >> Hi all, >> >> thanks, Nicolas, for the nice and structured summary of the current >> situation. >> >> I +1 the suggestion to extend the "sbml annot" project to become a >> "COMBINE metadata" effort. >> >> Neil, the way I understood Nicolas we would have a specification for >> metadata in general, and this specification would include guidelines on >> which CV to use for all different kinds of metadata, including the ones >> for the model itself (e.g., dcterms) and the model entities (e.g., EC >> terms)... and probably more ;) >> >> +1 also for COMBINE2013 session(s). >> >> Greetings, >> 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: Neil Swainston [nei...@ma... >> <mailto:nei...@ma...>] >> Gesendet: Mittwoch, 24. Juli 2013 12:58 >> An: Nicolas Le Novere >> Cc: sbm...@li... >> <mailto:sbm...@li...>; ge...@uw... >> <mailto:ge...@uw...>; Kieran Smallbone; com...@mb... >> <mailto:com...@mb...>; Ben...@sy... >> <mailto:Ben...@sy...> >> Betreff: Re: [sbml-annot] On metadata attached to COMBINE standards >> >> Hi Nicolas, >> >> After going through this, I get the impression that much of this refers >> to annotation of the model itself (author, date, organism, system, etc., >> i.e. metadata of the model) and not so much the content of the model (EC >> terms, gene ids, etc.). Would this be right? >> >> Cheers, >> >> Neil. >> >> Neil Swainston, PhD >> Research Fellow >> >> Manchester Institute of Biotechnology >> University of Manchester >> Manchester M1 7DN >> United Kingdom >> >> On 24 Jul 2013, at 11:47, Nicolas Le Novere <n.l...@gm... >> <mailto: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... >>> <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/ >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> See everything from the browser to the database with AppDynamics >>> Get end-to-end visibility with application monitoring from AppDynamics >>> Isolate bottlenecks and diagnose root cause in seconds. >>> Start your free trial of AppDynamics Pro today! >>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Sbml-annot mailing list >>> Sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-annot >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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: Neil S. <nei...@ma...> - 2013-07-24 13:07:09
|
Hi all, This discussion seems to deal with perhaps a longer time frame than the immediate requirement to add structured annotations to FBC models. I'm aware that Brett and Frank, with help from Ben, are quickly iterating towards a solution for this, and I'm conscious that looking at longer term goals may delay this. Maybe these two discussions can carry on running in parallel? Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 24 Jul 2013, at 12:30, Dagmar Waltemath <dag...@un...> wrote: > Hi all, > > thanks, Nicolas, for the nice and structured summary of the current situation. > > I +1 the suggestion to extend the "sbml annot" project to become a "COMBINE metadata" effort. > > Neil, the way I understood Nicolas we would have a specification for metadata in general, and this specification would include guidelines on which CV to use for all different kinds of metadata, including the ones for the model itself (e.g., dcterms) and the model entities (e.g., EC terms)... and probably more ;) > > +1 also for COMBINE2013 session(s). > > Greetings, > 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: Neil Swainston [nei...@ma...] > Gesendet: Mittwoch, 24. Juli 2013 12:58 > An: Nicolas Le Novere > Cc: sbm...@li...; ge...@uw...; Kieran Smallbone; com...@mb...; Ben...@sy... > Betreff: Re: [sbml-annot] On metadata attached to COMBINE standards > > Hi Nicolas, > > After going through this, I get the impression that much of this refers to annotation of the model itself (author, date, organism, system, etc., i.e. metadata of the model) and not so much the content of the model (EC terms, gene ids, etc.). Would this be right? > > Cheers, > > Neil. > > Neil Swainston, PhD > Research Fellow > > Manchester Institute of Biotechnology > University of Manchester > Manchester M1 7DN > United Kingdom > > On 24 Jul 2013, at 11:47, 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/ >> >> >> >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Sbml-annot mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-annot > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Dagmar W. <dag...@un...> - 2013-07-24 11:30:29
|
Hi all, thanks, Nicolas, for the nice and structured summary of the current situation. I +1 the suggestion to extend the "sbml annot" project to become a "COMBINE metadata" effort. Neil, the way I understood Nicolas we would have a specification for metadata in general, and this specification would include guidelines on which CV to use for all different kinds of metadata, including the ones for the model itself (e.g., dcterms) and the model entities (e.g., EC terms)... and probably more ;) +1 also for COMBINE2013 session(s). Greetings, 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: Neil Swainston [nei...@ma...] Gesendet: Mittwoch, 24. Juli 2013 12:58 An: Nicolas Le Novere Cc: sbm...@li...; ge...@uw...; Kieran Smallbone; com...@mb...; Ben...@sy... Betreff: Re: [sbml-annot] On metadata attached to COMBINE standards Hi Nicolas, After going through this, I get the impression that much of this refers to annotation of the model itself (author, date, organism, system, etc., i.e. metadata of the model) and not so much the content of the model (EC terms, gene ids, etc.). Would this be right? Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 24 Jul 2013, at 11:47, 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/ > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Sbml-annot mailing list Sbm...@li... https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Neil S. <nei...@ma...> - 2013-07-24 10:58:46
|
Hi Nicolas, After going through this, I get the impression that much of this refers to annotation of the model itself (author, date, organism, system, etc., i.e. metadata of the model) and not so much the content of the model (EC terms, gene ids, etc.). Would this be right? Cheers, Neil. Neil Swainston, PhD Research Fellow Manchester Institute of Biotechnology University of Manchester Manchester M1 7DN United Kingdom On 24 Jul 2013, at 11:47, 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/ > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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-07-24 10:48:06
|
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/ |
|
From: Stefan H. <sh...@vb...> - 2011-06-23 09:24:50
|
Hello Michel, On 6/21/11 3:15 PM, Michel Dumontier wrote: > Hi Allyson! > I understand the dilemma! > > At harmony I indicated that we could go one of two routes: > > 1a - simplify the rdf triple representation (no bags), and tighten up the > predicates (so they are clearer) - that way they can be published as RDF > linked data. > 1b - adopt/develop the formal approach so that we can always transform (1) > into OWL axioms for more advanced reasoning / validation > > or > > 2 - adopt/develop the formal approach so that every SBML file already > contains reasoning-ready knowledge > > honestly, my preference is for option 1, but the 1b is critical to the long > term success of that strategy. > I also favor staying with 1, i.e., with RDF/XML. I also agree with you that the rdf construct bag should be avoided and that is for 2 reasons 1) There is no described semantics, i.e., nothing is achieved except possibly abbreviation. 2) RDF requires the bag structure to be preserved just in case that semantics might be attached, which makes handling them very complicated. An additional point why I think we should stay with RDF/XML is that the focus of the annotation package is to decribe/identify individual model components which can be achieved within the RDF/XML framework utilizing MIRIAM resources. Thanks, Stefan -- Stefan Hoops, Ph.D. Senior Project Associate Virginia Bioinformatics Institute - 0477 Virginia Tech Bioinformatics Facility II Blacksburg, Va 24061, USA Phone: (540) 231-1799 Fax: (540) 231-2606 Email: sh...@vb... |
|
From: Michel D. <mic...@gm...> - 2011-06-22 11:45:22
|
On Wed, Jun 22, 2011 at 5:47 AM, Allyson Lister <a.l...@ne...>wrote: > Hi Robert, > > On 21 June 2011 21:15, Robert Hoehndorf <lee...@le...> wrote: > >> >> Dear Michel, Allyson, and list, >> >> MD> 1a - simplify the rdf triple representation (no bags), and >> MD> tighten up the predicates (so they are clearer) - that way they >> MD> can be published as RDF linked data. 1b - adopt/develop the >> MD> formal approach so that we can always transform (1) into OWL >> MD> axioms for more advanced reasoning / validation >> MD> or >> MD> 2 - adopt/develop the formal approach so that every SBML file >> MD> already contains reasoning-ready knowledge >> >> MD> honestly, my preference is for option 1, but the 1b is critical >> MD> to the long term success of that strategy. >> >> I believe it is important to keep the XML-based representation and at >> the same time make its semantics clearer, where appropriate. >> > > I should say that I am not advocating throwing away the XML, as much as I > like ontologies. I'm just trying to get a clear picture of exactly how much > we should be modelling in OWL for use within the annotation elements. > >> >> In my opinion (and I am new to modelling and SBML, so I apologize if I >> say something stupid), the best strategy would be to come up with a part >> of SBML that is formalized sufficiently to allow for a translation into >> OWL, and to build an infrastructure that can verify models according to >> these constraints. >> > > While I like this idea - and both MFO and SBML Harvester are already doing > this to variable extents - I'm not sure it's part of the sbml-annot > package's remit, especially as it seems a number of groups are tackling this > independently. I'm happy to be proved wrong, however.... The sbml-annot > package is about providing biological (and other types) annotation in a way > that is less rigid than the confines of the SBML XSD. It is about describing > the accepted structure of that annotation. This may include OWL or plain > RDF, and may include a helper OWL ontology referenced in the annotation > within an element, but I'm not sure the package development would need to > include verification apps - perhaps just pointers to ones that are > available. > Since I've never asked this question - why is it that SBML's xsd was not extended to include a sequence of annotation elements with simple attributes e.g. predicate, object? > >> >> I would be glad if we could have discussion about the best strategy at >> COMBINE. >> > > Agreed - would love to be there if I am able to attend. > > Though I agree that Michel's two choices are the ones I see as well, I > would be wary of part 1b in the option list above (the conversion of some > simpler format into OWL), as that would mean yet another library to be > maintained in order to get any use out of the annotation element, though I > like the simplicity of 1a. I do think that, just as the annotation element > currently accepts any rdf (basically), but adds rules to how MIRIAM > annotation is added, we could continue with that but replace the MIRIAM RDF > with OWL saved as RDF/XML. Existing RDF parsers wouldn't break, and the OWL > would be ready to use without modification. I guess that's option #2. > However, if 1b were easy and feasible, I would be happy with that too. > :) thanks, > > -- > Allyson Lister > > So the SBML harvester does just this - it reads the RDF content in the annotation element and converts it to OWL. You're right that it's another library to maintain (especially since i think Rob's code lacks documentation - ahem) although I daresay it's completely worth it :) m. > Please note the new email address of all...@ne..., > although the old email address will still work. > > Newcastle University, http://www.ncl.ac.uk > http://themindwobbles.wordpress.com > > > -- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com |
|
From: Allyson L. <a.l...@ne...> - 2011-06-22 09:47:41
|
Hi Robert, On 21 June 2011 21:15, Robert Hoehndorf <lee...@le...> wrote: > > Dear Michel, Allyson, and list, > > MD> 1a - simplify the rdf triple representation (no bags), and > MD> tighten up the predicates (so they are clearer) - that way they > MD> can be published as RDF linked data. 1b - adopt/develop the > MD> formal approach so that we can always transform (1) into OWL > MD> axioms for more advanced reasoning / validation > MD> or > MD> 2 - adopt/develop the formal approach so that every SBML file > MD> already contains reasoning-ready knowledge > > MD> honestly, my preference is for option 1, but the 1b is critical > MD> to the long term success of that strategy. > > I believe it is important to keep the XML-based representation and at > the same time make its semantics clearer, where appropriate. > I should say that I am not advocating throwing away the XML, as much as I like ontologies. I'm just trying to get a clear picture of exactly how much we should be modelling in OWL for use within the annotation elements. > > In my opinion (and I am new to modelling and SBML, so I apologize if I > say something stupid), the best strategy would be to come up with a part > of SBML that is formalized sufficiently to allow for a translation into > OWL, and to build an infrastructure that can verify models according to > these constraints. > While I like this idea - and both MFO and SBML Harvester are already doing this to variable extents - I'm not sure it's part of the sbml-annot package's remit, especially as it seems a number of groups are tackling this independently. I'm happy to be proved wrong, however.... The sbml-annot package is about providing biological (and other types) annotation in a way that is less rigid than the confines of the SBML XSD. It is about describing the accepted structure of that annotation. This may include OWL or plain RDF, and may include a helper OWL ontology referenced in the annotation within an element, but I'm not sure the package development would need to include verification apps - perhaps just pointers to ones that are available. > > > I would be glad if we could have discussion about the best strategy at > COMBINE. > Agreed - would love to be there if I am able to attend. Though I agree that Michel's two choices are the ones I see as well, I would be wary of part 1b in the option list above (the conversion of some simpler format into OWL), as that would mean yet another library to be maintained in order to get any use out of the annotation element, though I like the simplicity of 1a. I do think that, just as the annotation element currently accepts any rdf (basically), but adds rules to how MIRIAM annotation is added, we could continue with that but replace the MIRIAM RDF with OWL saved as RDF/XML. Existing RDF parsers wouldn't break, and the OWL would be ready to use without modification. I guess that's option #2. However, if 1b were easy and feasible, I would be happy with that too. :) thanks, -- Allyson Lister Please note the new email address of all...@ne..., although the old email address will still work. Newcastle University, http://www.ncl.ac.uk http://themindwobbles.wordpress.com |
|
From: Robert H. <lee...@le...> - 2011-06-21 20:16:02
|
Dear Michel, Allyson, and list,
MD> 1a - simplify the rdf triple representation (no bags), and
MD> tighten up the predicates (so they are clearer) - that way they
MD> can be published as RDF linked data. 1b - adopt/develop the
MD> formal approach so that we can always transform (1) into OWL
MD> axioms for more advanced reasoning / validation
MD> or
MD> 2 - adopt/develop the formal approach so that every SBML file
MD> already contains reasoning-ready knowledge
MD> honestly, my preference is for option 1, but the 1b is critical
MD> to the long term success of that strategy.
I believe it is important to keep the XML-based representation and at
the same time make its semantics clearer, where appropriate.
Doing modelling entirely in OWL seems not the best idea to me. Not
mentioning the tool support for current XML that would have to be
changed, OWL is quite expressive and OWL tools (especially OWL API) are
extremely heavy on memory comsumption and generally very slow (in
contrast to the very well implemented libSBML, which is really fast).
Also, OWL expressivity will not suffice to express everything in SBML
models (especially math, but also closed-world assertions, places where
we would need ternary relations, relational closures). It may be
possible to come up with extensions and best practices to compensate for
this, but if we would have to rely on best practices (use of new
annotation properties, MathML expressions as annotations, etc.), the
benefit of using OWL is rather unclear to me.
In my opinion (and I am new to modelling and SBML, so I apologize if I
say something stupid), the best strategy would be to come up with a part
of SBML that is formalized sufficiently to allow for a translation into
OWL, and to build an infrastructure that can verify models according to
these constraints.
Such an infrastucture could, for example, verify the models deposited in
BioModels, and either reject models that do not comply with whatever
formal constraints the community has put in place both for the use of
SBML and the annotation of SBML elements, or give them a special tag,
together with some suggestions for fixing whatever violation has been
detected. A crucial component here is to fix the meaning of the
Biomodels biology qualifiers, and allow the verification through
reasoning in OWL.
The MFO does a very good job in checking the syntactic constraints of
models. Michel's group, the group of Dan Cook/John Gennari, a group at
the EBI and Cambridge have been working in this direction, with a
rough prototype available at http://bioonto.gen.cam.ac.uk/sbmlharvester/
The software translates some aspects of SBML annotations into OWL and
verifies some constraints that we put in place. However, I think it
should really be a community decision what the "correct" translation of
an annotation for a model entity should be, and we hope to have a
discussion about this at the COMBINE meeting in September.
Also, such a system allows for a graceful adoption of new constraints,
since at least syntactically, nothing about SBML or its annotations has
to be changed.
Adding complex OWL statements to SBML would be a really good plan,
independent of the concrete syntax used, I think (since SBML models are
rarely accessed through a text editor). However, I understand that
annotation, as it currently stands, is a rather complex process, and I
am not sure how much complexity can be added to it, since allowing OWL
annotations would require new tools and probably some training for
annotators. One option would be to add more complex biology qualifiers
for annotations that unfold into complex OWL statement (without the need
to write the OWL directly, either by the annotator or the
modeller). Another option would be to use parts of the infrastructure
developed by the RICORDO project (http://www.ricordo.eu/), which aims to
provide complex OWL-based annotations for physiology-related models.
I would be glad if we could have discussion about the best strategy at
COMBINE.
Rob.
|
|
From: Michel D. <mic...@gm...> - 2011-06-21 19:15:56
|
Hi Allyson! I understand the dilemma! At harmony I indicated that we could go one of two routes: 1a - simplify the rdf triple representation (no bags), and tighten up the predicates (so they are clearer) - that way they can be published as RDF linked data. 1b - adopt/develop the formal approach so that we can always transform (1) into OWL axioms for more advanced reasoning / validation or 2 - adopt/develop the formal approach so that every SBML file already contains reasoning-ready knowledge honestly, my preference is for option 1, but the 1b is critical to the long term success of that strategy. m. On Tue, Jun 21, 2011 at 3:06 PM, Allyson Lister <a.l...@ne...>wrote: > Hi all, > > Thanks Michel - I knew you'd come up with some good ideas :) My comments > are inline: > > On 20 June 2011 18:38, Michel Dumontier <mic...@gm...>wrote: > >> Hi Allyson, >> Good job on having a "first bash" at it :) >> >> I have some comments and suggestions: >> >> 1. OWL and axiom rendering >> While there exists a mapping to RDF/XML or turtle, the "triple" view of >> OWL axioms is unfortunately rather unappealing. I would instead suggest that >> in discussing OWL axioms, we use some other of the other syntaxes ( >> http://www.w3.org/TR/owl2-overview/#Syntaxes) such as the manchester >> syntax >> >> http://www.w3.org/TR/2009/NOTE-owl2-manchester-syntax-20091027/ >> or simpler: http://www.co-ode.org/resources/reference/manchester_syntax/ >> > > Definitely easier to look at. I thought I would use RDF/XML to highlight > the similarities that exist between that way of saving OWL and the way that > was already expressed in the annot package proposal document - to show how > little had to change, if we so wished. However, for our discussions, > Manchester OWL syntax is much nicer. > >> >> The best SDK to manage OWL ontologies is the OWLAPI >> http://owlapi.sourceforge.net/ >> > > Agreed again. I use this a lot, and it is very nice. Obviously we can't > force people to use it - they may not want to have to include a whole other > library if they just want to, for example, display the annotation in an app > without doing anything with it. That's why I said the RDF/XML version would > at least be parseable by someone's existing RDF libs. > >> >> in this way, one could write >> SBMLmodel >> SubClassOf: represents some BiologicalProcess >> DisjointWith: SBMLspecies, SBMLreaction, ... >> > > yep indeed - though I'm not sure how much modelling in OWL we'd want to do > at this stage (more on that later). > >> >> >> 2. formalization of SBML models and their components. >> One aspect of the work that Rob and I and our colleagues undertook was to >> differentiate between models, their components and what they refer to >> >> >> http://www.slideshare.net/micheldumontier/harmony-2011-formalization-of-sbml-models-as-owl-ontologies >> >> the formalization into appropriate bits of OWL was also necessary in order >> to do the automated reasoning (check consistency, generate entailments, >> answer questions). Given that we were able to accomplish these tasks with >> the approach taken, I'd like to suggest that this form the basis for the >> discussion into generating OWL. >> >> > Yes, it's very interesting to read that presentation - wish I could have > been there! It's definitely taking what I did a while ago with MFO further - > I've had no time over the past year for anything, and it's amazing to see > how things have progressed :) > > >> 3. OWL stuff >> a. we would want an ontology for SBML - that defined the components of an >> SBML model - and it would stay and be published in a new namespace. Things >> that are generated by biomodels (the biomodel ID) could be created in a >> biomodel namespace. Entity identifiers should *not* be indexed against the >> version of the ontology - keep these separate. Ontology identifiers, >> however, can hold both a version independent IRI and a version dependent IRI >> using OWL. >> > > Yep definitely wrt the namespaces - the examples I sent were just simple > ones. As for an ontology for all of SBML: not sure the sbml-annot package > people should be pushing that without a wider remit? As much as I want it > (and have been harping on about the modelling of SBML using only OWL since I > got started with SBML meetings years ago), would we be doing too much *at > the moment* introducing a full SBML ontology for use in the annotation > section? If we just want to say species A has uniprot AC P12345, we could 1) > just model in OWL the MIRIAM qualifiers and an SBase object (for example, > see my original mail) or 2) make available the full modelling of the entire > SBML model containing species A just to ensure a full description of the > species and its annotation, or 3) anywhere in between. > > Of course, having a full OWL version of SBML like MFO or the work you've > done above more recently doesn't mean anyone has to use all of its > components - they could pick and choose. I just want to be sure that we > would really want to have what could end up being quite a large OWL model of > (part of) an SBML entry sitting behind each annotation element (even if most > of it was hidden in the OWL file referenced by an xmlns). We might start > just saying uniprot -> species, but then add info on species -> species type > and species -> compartment and species -> model -> document etc. etc. even > if it wasn't necessary for that single annotation element? Or maybe I'm > misunderstanding what you're suggesting? > > >> >> b. negation >> if we follow the class axiom pattern, then we can assert >> >> mysbmlModel >> SubClassOf: SBMLModel and represents some (MaterialEntity that not(hasPart >> some GO:0031595)) >> > > Using this example of negation, we're making a particular SBML entry a > class? So all of these are classes (mysbmlModel and the GO term) rather than > instances (e.g. of SBMLModel)? Just want to be sure what you're saying... It > seems to me as if something like mysbmlModel would be more suited to an > individual - or is that more of an esoteric discussion? > > In short, I like what you've said and generally agree with it. In summary, > MFO is a structural conversion of SBML in XML to SBML in OWL with a few more > semantically meaningful additions, and what you've presented above does look > richer. I don't mind what we use in the examples, and it looks like your > recent work is very suitable! However, not sure we want to have an entire > model of SBML in OWL backing the annotation elements: while I agree in > principle (mainly because I feel the XML format is outdated and we should > all just be using ontologies!), I am not sure that level of complexity is > required? Would just like to examine the ideas a little further, I guess. > > thanks! Allyson :) > > >> (the model represents some material entity (e.g. a cell) that does not >> have a nuclear proteosome complex) >> >> Cheers, >> >> m. >> >> On Thu, Jun 16, 2011 at 6:14 AM, Allyson Lister < >> a.l...@ne...> wrote: >> >>> Hi all, >>> >>> I've been asked to make up a basic example of how we might do things in >>> the >>> annot package if we allowed OWL rather than just RDF. As OWL can be saved >>> as >>> RDF/XML, people who aren't interested in the annotation, or who are just >>> interested in using a plain RDF parser can manage. We could still say in >>> the >>> proposal that any RDF is allowed, but then further specify (if we so >>> decide) >>> that MIRIAM annotations and other SBML-backed annotations are described >>> using OWL, thus allowing things like negation. >>> >>> I'm not saying that we have to use OWL, or that we have to use these >>> structures (and I have deliberately left the example minimalist, without >>> much reference to the higher functions of OWL), but it would leave the >>> door >>> open for more complex statements in future, without losing the RDF >>> structure >>> many are familiar with. >>> >>> Happy to go with the general consensus, of course. Just thought I'd put >>> this >>> out there. By the way, I am sure there are other ways to do the examples, >>> and there might be other ways to do the negation. Please feel free to put >>> your own examples out, and definitely please comment on these. >>> >>> Attachments can be viewed in a normal text editor (they're very simple) >>> or >>> opened in Protege, where you get more of an idea of the shape of an OWL >>> file. >>> miriam-test.owl is the first example, and miriam-test-negation.owl is >>> that >>> example converted into a negation. >>> >>> Here are the examples. First, a simple bqb "is" qualifier. In SBML it >>> looks >>> like this (this entry is BIOMD0000000001): >>> >>> <rdf:RDF xmlns:rdf=" >>> http://www.w3.org/1999/02/22-rdf-syntax-ns#" >>> xmlns:dc="http://purl.org/dc/elements/1.1/" >>> xmlns:dcterms="http://purl.org/dc/terms/" >>> xmlns:vCard=" >>> http://www.w3.org/2001/vcard-rdf/3.0#" >>> xmlns:bqbiol=" >>> http://biomodels.net/biology-qualifiers/" >>> xmlns:bqmodel=" >>> http://biomodels.net/model-qualifiers/"> >>> <rdf:Description rdf:about="#_000002"> >>> <bqbiol:is> >>> <rdf:Bag> >>> <rdf:li >>> rdf:resource="urn:miriam:obo.go:GO%3A0031594"/> >>> </rdf:Bag> >>> </bqbiol:is> >>> </rdf:Description> >>> </rdf:RDF> >>> >>> In the above example, we have the standard rdf:RDF element, which uses >>> the >>> bqbiol namespace and the bqmodel namespace. >>> >>> For a simple example (and based on how it's done in MFO to make life >>> easier >>> for me - http://cisban-silico.cs.ncl.ac.uk/MFO/), the OWL equivalent of >>> the >>> above annotation is below. In *bold* is the only major change to the >>> internals of the rdf:RDF element - the rest of the changes are "xmlns" >>> changes in the rdf:RDF tag: >>> <rdf:RDF xmlns="http://www.sbml.org/sbml/level2/sbmll2v4/" >>> xml:base="http://www.sbml.org/sbml/level2/sbmll2v4/" >>> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" >>> xmlns:owl="http://www.w3.org/2002/07/owl#" >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema#" >>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >>> xmlns:sbmll2v4="http://www.sbml.org/sbml/level2/sbmll2v4/"> >>> <owl:Ontology rdf:about="http://www.sbml.org/sbml/level2/sbmll2v4/"/> >>> *<owl:NamedIndividual rdf:about="#_000002"> >>> <rdf:type rdf:resource="&sbmll2v4;MiriamAnnotation"/> >>> <bqbIs >>> rdf:datatype="&xsd;string">urn:miriam:obo.go:GO%3A0031594</bqbIs> >>> </owl:NamedIndividual>* >>> </rdf:RDF> >>> >>> >>> Some notes on this example: >>> >>> 1. Not sure we'd need to name the ontology or not, so may not need the >>> >>> <owl:Ontology> element each time - certainly don't need it for simple >>> RDF >>> parsing. >>> 2. In this example, we are treating the sbml element as an >>> >>> individual/instance of the class MiriamAnnotation. This may or may not >>> be >>> the right decision - it could be an anonymous individual or could be a >>> class, for example. >>> 3. Also, I'm ot sure *just* the metaid could go in the rdf:about field, >>> >>> though we do it in the SBML rdf annotation itself right now. Would need >>> more >>> experienced people for RDF or OWL to answer that. Otherwise, the >>> rdf:about >>> could point to a URI based on the model number and the metaid (e.g. >>> http://www.sbml.org/sbml/level2/sbmll2v4/BIOMD0000000001_000002") >>> >>> >>> The above OWL example isn't quite the full story: the xmlns that I have >>> labelled sbmll2v4 would need to have, at a minimum, the following >>> declarations in it, as they are used in the example: >>> >>> <!-- Definition of the datatype property bqb Is --> >>> <owl:DatatypeProperty rdf:about="&sbmll2v4;bqbIs"> >>> <rdfs:range rdf:resource="&xsd;string"/> >>> </owl:DatatypeProperty> >>> >>> <!-- The class for which the example above is an instance of --> >>> <owl:Class rdf:about="&sbmll2v4;MiriamAnnotation"/> >>> >>> As an aside, in MFO everything is converted to OWL, so the Species class >>> is >>> linked to the MiriamAnnotation class, which links through to the various >>> bq >>> qualifiers. We wouldn't need to do all of that here, as we only want the >>> annotation in OWL. >>> >>> As negation seems such a hot topic, below is the extra lines required for >>> the original example in order to add a second go term as a bqb is *not*. >>> These lines would be added within the same rdf:RDF element in the >>> annotation >>> section: >>> *<rdf:Description> >>> <rdf:type rdf:resource="&owl;NegativePropertyAssertion"/> >>> <owl:targetValue>urn:miriam:obo.go:GO%3A0031595</owl:targetValue> >>> <owl:sourceIndividual rdf:resource="&sbmll2v4;_000002"/> >>> <owl:assertionProperty rdf:resource="&sbmll2v4;bqbIs"/> >>> </rdf:Description>* >>> >>> >>> Remember, the examples are also attached to be viewed in their >>> completeness >>> either in an editor or in Protege. >>> >>> It's a first bash, anyway. Enjoy! >>> >>> -- >>> Allyson Lister >>> >>> Please note the new email address of all...@ne..., >>> although the old email address will still work. >>> >>> Newcastle University, http://www.ncl.ac.uk >>> http://themindwobbles.wordpress.com >>> >>> >>> ------------------------------------------------------------------------------ >>> EditLive Enterprise is the world's most technically advanced content >>> authoring tool. Experience the power of Track Changes, Inline Image >>> Editing and ensure content is compliant with Accessibility Checking. >>> http://p.sf.net/sfu/ephox-dev2dev >>> _______________________________________________ >>> Sbml-annot mailing list >>> Sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-annot >>> >>> >> >> >> -- >> Michel Dumontier >> Associate Professor of Bioinformatics >> Carleton University >> http://dumontierlab.com >> > > > > -- > Allyson Lister > > Please note the new email address of all...@ne..., > although the old email address will still work. > > Newcastle University, http://www.ncl.ac.uk > http://themindwobbles.wordpress.com > > > -- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com |
|
From: Allyson L. <a.l...@ne...> - 2011-06-21 19:06:23
|
Hi all, Thanks Michel - I knew you'd come up with some good ideas :) My comments are inline: On 20 June 2011 18:38, Michel Dumontier <mic...@gm...> wrote: > Hi Allyson, > Good job on having a "first bash" at it :) > > I have some comments and suggestions: > > 1. OWL and axiom rendering > While there exists a mapping to RDF/XML or turtle, the "triple" view of OWL > axioms is unfortunately rather unappealing. I would instead suggest that in > discussing OWL axioms, we use some other of the other syntaxes ( > http://www.w3.org/TR/owl2-overview/#Syntaxes) such as the manchester > syntax > > http://www.w3.org/TR/2009/NOTE-owl2-manchester-syntax-20091027/ > or simpler: http://www.co-ode.org/resources/reference/manchester_syntax/ > Definitely easier to look at. I thought I would use RDF/XML to highlight the similarities that exist between that way of saving OWL and the way that was already expressed in the annot package proposal document - to show how little had to change, if we so wished. However, for our discussions, Manchester OWL syntax is much nicer. > > The best SDK to manage OWL ontologies is the OWLAPI > http://owlapi.sourceforge.net/ > Agreed again. I use this a lot, and it is very nice. Obviously we can't force people to use it - they may not want to have to include a whole other library if they just want to, for example, display the annotation in an app without doing anything with it. That's why I said the RDF/XML version would at least be parseable by someone's existing RDF libs. > > in this way, one could write > SBMLmodel > SubClassOf: represents some BiologicalProcess > DisjointWith: SBMLspecies, SBMLreaction, ... > yep indeed - though I'm not sure how much modelling in OWL we'd want to do at this stage (more on that later). > > > 2. formalization of SBML models and their components. > One aspect of the work that Rob and I and our colleagues undertook was to > differentiate between models, their components and what they refer to > > > http://www.slideshare.net/micheldumontier/harmony-2011-formalization-of-sbml-models-as-owl-ontologies > > the formalization into appropriate bits of OWL was also necessary in order > to do the automated reasoning (check consistency, generate entailments, > answer questions). Given that we were able to accomplish these tasks with > the approach taken, I'd like to suggest that this form the basis for the > discussion into generating OWL. > > Yes, it's very interesting to read that presentation - wish I could have been there! It's definitely taking what I did a while ago with MFO further - I've had no time over the past year for anything, and it's amazing to see how things have progressed :) > 3. OWL stuff > a. we would want an ontology for SBML - that defined the components of an > SBML model - and it would stay and be published in a new namespace. Things > that are generated by biomodels (the biomodel ID) could be created in a > biomodel namespace. Entity identifiers should *not* be indexed against the > version of the ontology - keep these separate. Ontology identifiers, > however, can hold both a version independent IRI and a version dependent IRI > using OWL. > Yep definitely wrt the namespaces - the examples I sent were just simple ones. As for an ontology for all of SBML: not sure the sbml-annot package people should be pushing that without a wider remit? As much as I want it (and have been harping on about the modelling of SBML using only OWL since I got started with SBML meetings years ago), would we be doing too much *at the moment* introducing a full SBML ontology for use in the annotation section? If we just want to say species A has uniprot AC P12345, we could 1) just model in OWL the MIRIAM qualifiers and an SBase object (for example, see my original mail) or 2) make available the full modelling of the entire SBML model containing species A just to ensure a full description of the species and its annotation, or 3) anywhere in between. Of course, having a full OWL version of SBML like MFO or the work you've done above more recently doesn't mean anyone has to use all of its components - they could pick and choose. I just want to be sure that we would really want to have what could end up being quite a large OWL model of (part of) an SBML entry sitting behind each annotation element (even if most of it was hidden in the OWL file referenced by an xmlns). We might start just saying uniprot -> species, but then add info on species -> species type and species -> compartment and species -> model -> document etc. etc. even if it wasn't necessary for that single annotation element? Or maybe I'm misunderstanding what you're suggesting? > > b. negation > if we follow the class axiom pattern, then we can assert > > mysbmlModel > SubClassOf: SBMLModel and represents some (MaterialEntity that not(hasPart > some GO:0031595)) > Using this example of negation, we're making a particular SBML entry a class? So all of these are classes (mysbmlModel and the GO term) rather than instances (e.g. of SBMLModel)? Just want to be sure what you're saying... It seems to me as if something like mysbmlModel would be more suited to an individual - or is that more of an esoteric discussion? In short, I like what you've said and generally agree with it. In summary, MFO is a structural conversion of SBML in XML to SBML in OWL with a few more semantically meaningful additions, and what you've presented above does look richer. I don't mind what we use in the examples, and it looks like your recent work is very suitable! However, not sure we want to have an entire model of SBML in OWL backing the annotation elements: while I agree in principle (mainly because I feel the XML format is outdated and we should all just be using ontologies!), I am not sure that level of complexity is required? Would just like to examine the ideas a little further, I guess. thanks! Allyson :) > (the model represents some material entity (e.g. a cell) that does not have > a nuclear proteosome complex) > > Cheers, > > m. > > On Thu, Jun 16, 2011 at 6:14 AM, Allyson Lister < > a.l...@ne...> wrote: > >> Hi all, >> >> I've been asked to make up a basic example of how we might do things in >> the >> annot package if we allowed OWL rather than just RDF. As OWL can be saved >> as >> RDF/XML, people who aren't interested in the annotation, or who are just >> interested in using a plain RDF parser can manage. We could still say in >> the >> proposal that any RDF is allowed, but then further specify (if we so >> decide) >> that MIRIAM annotations and other SBML-backed annotations are described >> using OWL, thus allowing things like negation. >> >> I'm not saying that we have to use OWL, or that we have to use these >> structures (and I have deliberately left the example minimalist, without >> much reference to the higher functions of OWL), but it would leave the >> door >> open for more complex statements in future, without losing the RDF >> structure >> many are familiar with. >> >> Happy to go with the general consensus, of course. Just thought I'd put >> this >> out there. By the way, I am sure there are other ways to do the examples, >> and there might be other ways to do the negation. Please feel free to put >> your own examples out, and definitely please comment on these. >> >> Attachments can be viewed in a normal text editor (they're very simple) or >> opened in Protege, where you get more of an idea of the shape of an OWL >> file. >> miriam-test.owl is the first example, and miriam-test-negation.owl is that >> example converted into a negation. >> >> Here are the examples. First, a simple bqb "is" qualifier. In SBML it >> looks >> like this (this entry is BIOMD0000000001): >> >> <rdf:RDF xmlns:rdf=" >> http://www.w3.org/1999/02/22-rdf-syntax-ns#" >> xmlns:dc="http://purl.org/dc/elements/1.1/" >> xmlns:dcterms="http://purl.org/dc/terms/" >> xmlns:vCard=" >> http://www.w3.org/2001/vcard-rdf/3.0#" >> xmlns:bqbiol=" >> http://biomodels.net/biology-qualifiers/" >> xmlns:bqmodel=" >> http://biomodels.net/model-qualifiers/"> >> <rdf:Description rdf:about="#_000002"> >> <bqbiol:is> >> <rdf:Bag> >> <rdf:li >> rdf:resource="urn:miriam:obo.go:GO%3A0031594"/> >> </rdf:Bag> >> </bqbiol:is> >> </rdf:Description> >> </rdf:RDF> >> >> In the above example, we have the standard rdf:RDF element, which uses the >> bqbiol namespace and the bqmodel namespace. >> >> For a simple example (and based on how it's done in MFO to make life >> easier >> for me - http://cisban-silico.cs.ncl.ac.uk/MFO/), the OWL equivalent of >> the >> above annotation is below. In *bold* is the only major change to the >> internals of the rdf:RDF element - the rest of the changes are "xmlns" >> changes in the rdf:RDF tag: >> <rdf:RDF xmlns="http://www.sbml.org/sbml/level2/sbmll2v4/" >> xml:base="http://www.sbml.org/sbml/level2/sbmll2v4/" >> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" >> xmlns:owl="http://www.w3.org/2002/07/owl#" >> xmlns:xsd="http://www.w3.org/2001/XMLSchema#" >> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >> xmlns:sbmll2v4="http://www.sbml.org/sbml/level2/sbmll2v4/"> >> <owl:Ontology rdf:about="http://www.sbml.org/sbml/level2/sbmll2v4/"/> >> *<owl:NamedIndividual rdf:about="#_000002"> >> <rdf:type rdf:resource="&sbmll2v4;MiriamAnnotation"/> >> <bqbIs >> rdf:datatype="&xsd;string">urn:miriam:obo.go:GO%3A0031594</bqbIs> >> </owl:NamedIndividual>* >> </rdf:RDF> >> >> >> Some notes on this example: >> >> 1. Not sure we'd need to name the ontology or not, so may not need the >> >> <owl:Ontology> element each time - certainly don't need it for simple >> RDF >> parsing. >> 2. In this example, we are treating the sbml element as an >> >> individual/instance of the class MiriamAnnotation. This may or may not >> be >> the right decision - it could be an anonymous individual or could be a >> class, for example. >> 3. Also, I'm ot sure *just* the metaid could go in the rdf:about field, >> >> though we do it in the SBML rdf annotation itself right now. Would need >> more >> experienced people for RDF or OWL to answer that. Otherwise, the >> rdf:about >> could point to a URI based on the model number and the metaid (e.g. >> http://www.sbml.org/sbml/level2/sbmll2v4/BIOMD0000000001_000002") >> >> >> The above OWL example isn't quite the full story: the xmlns that I have >> labelled sbmll2v4 would need to have, at a minimum, the following >> declarations in it, as they are used in the example: >> >> <!-- Definition of the datatype property bqb Is --> >> <owl:DatatypeProperty rdf:about="&sbmll2v4;bqbIs"> >> <rdfs:range rdf:resource="&xsd;string"/> >> </owl:DatatypeProperty> >> >> <!-- The class for which the example above is an instance of --> >> <owl:Class rdf:about="&sbmll2v4;MiriamAnnotation"/> >> >> As an aside, in MFO everything is converted to OWL, so the Species class >> is >> linked to the MiriamAnnotation class, which links through to the various >> bq >> qualifiers. We wouldn't need to do all of that here, as we only want the >> annotation in OWL. >> >> As negation seems such a hot topic, below is the extra lines required for >> the original example in order to add a second go term as a bqb is *not*. >> These lines would be added within the same rdf:RDF element in the >> annotation >> section: >> *<rdf:Description> >> <rdf:type rdf:resource="&owl;NegativePropertyAssertion"/> >> <owl:targetValue>urn:miriam:obo.go:GO%3A0031595</owl:targetValue> >> <owl:sourceIndividual rdf:resource="&sbmll2v4;_000002"/> >> <owl:assertionProperty rdf:resource="&sbmll2v4;bqbIs"/> >> </rdf:Description>* >> >> >> Remember, the examples are also attached to be viewed in their >> completeness >> either in an editor or in Protege. >> >> It's a first bash, anyway. Enjoy! >> >> -- >> Allyson Lister >> >> Please note the new email address of all...@ne..., >> although the old email address will still work. >> >> Newcastle University, http://www.ncl.ac.uk >> http://themindwobbles.wordpress.com >> >> >> ------------------------------------------------------------------------------ >> EditLive Enterprise is the world's most technically advanced content >> authoring tool. Experience the power of Track Changes, Inline Image >> Editing and ensure content is compliant with Accessibility Checking. >> http://p.sf.net/sfu/ephox-dev2dev >> _______________________________________________ >> Sbml-annot mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-annot >> >> > > > -- > Michel Dumontier > Associate Professor of Bioinformatics > Carleton University > http://dumontierlab.com > -- Allyson Lister Please note the new email address of all...@ne..., although the old email address will still work. Newcastle University, http://www.ncl.ac.uk http://themindwobbles.wordpress.com |
|
From: Michel D. <mic...@gm...> - 2011-06-20 17:38:32
|
Hi Allyson, Good job on having a "first bash" at it :) I have some comments and suggestions: 1. OWL and axiom rendering While there exists a mapping to RDF/XML or turtle, the "triple" view of OWL axioms is unfortunately rather unappealing. I would instead suggest that in discussing OWL axioms, we use some other of the other syntaxes ( http://www.w3.org/TR/owl2-overview/#Syntaxes) such as the manchester syntax http://www.w3.org/TR/2009/NOTE-owl2-manchester-syntax-20091027/ or simpler: http://www.co-ode.org/resources/reference/manchester_syntax/ The best SDK to manage OWL ontologies is the OWLAPI http://owlapi.sourceforge.net/ in this way, one could write SBMLmodel SubClassOf: represents some BiologicalProcess DisjointWith: SBMLspecies, SBMLreaction, ... 2. formalization of SBML models and their components. One aspect of the work that Rob and I and our colleagues undertook was to differentiate between models, their components and what they refer to http://www.slideshare.net/micheldumontier/harmony-2011-formalization-of-sbml-models-as-owl-ontologies the formalization into appropriate bits of OWL was also necessary in order to do the automated reasoning (check consistency, generate entailments, answer questions). Given that we were able to accomplish these tasks with the approach taken, I'd like to suggest that this form the basis for the discussion into generating OWL. 3. OWL stuff a. we would want an ontology for SBML - that defined the components of an SBML model - and it would stay and be published in a new namespace. Things that are generated by biomodels (the biomodel ID) could be created in a biomodel namespace. Entity identifiers should *not* be indexed against the version of the ontology - keep these separate. Ontology identifiers, however, can hold both a version independent IRI and a version dependent IRI using OWL. b. negation if we follow the class axiom pattern, then we can assert mysbmlModel SubClassOf: SBMLModel and represents some (MaterialEntity that not(hasPart some GO:0031595)) (the model represents some material entity (e.g. a cell) that does not have a nuclear proteosome complex) Cheers, m. On Thu, Jun 16, 2011 at 6:14 AM, Allyson Lister <a.l...@ne...>wrote: > Hi all, > > I've been asked to make up a basic example of how we might do things in the > annot package if we allowed OWL rather than just RDF. As OWL can be saved > as > RDF/XML, people who aren't interested in the annotation, or who are just > interested in using a plain RDF parser can manage. We could still say in > the > proposal that any RDF is allowed, but then further specify (if we so > decide) > that MIRIAM annotations and other SBML-backed annotations are described > using OWL, thus allowing things like negation. > > I'm not saying that we have to use OWL, or that we have to use these > structures (and I have deliberately left the example minimalist, without > much reference to the higher functions of OWL), but it would leave the door > open for more complex statements in future, without losing the RDF > structure > many are familiar with. > > Happy to go with the general consensus, of course. Just thought I'd put > this > out there. By the way, I am sure there are other ways to do the examples, > and there might be other ways to do the negation. Please feel free to put > your own examples out, and definitely please comment on these. > > Attachments can be viewed in a normal text editor (they're very simple) or > opened in Protege, where you get more of an idea of the shape of an OWL > file. > miriam-test.owl is the first example, and miriam-test-negation.owl is that > example converted into a negation. > > Here are the examples. First, a simple bqb "is" qualifier. In SBML it looks > like this (this entry is BIOMD0000000001): > > <rdf:RDF xmlns:rdf=" > http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:dc="http://purl.org/dc/elements/1.1/" > xmlns:dcterms="http://purl.org/dc/terms/" > xmlns:vCard=" > http://www.w3.org/2001/vcard-rdf/3.0#" > xmlns:bqbiol=" > http://biomodels.net/biology-qualifiers/" > xmlns:bqmodel=" > http://biomodels.net/model-qualifiers/"> > <rdf:Description rdf:about="#_000002"> > <bqbiol:is> > <rdf:Bag> > <rdf:li > rdf:resource="urn:miriam:obo.go:GO%3A0031594"/> > </rdf:Bag> > </bqbiol:is> > </rdf:Description> > </rdf:RDF> > > In the above example, we have the standard rdf:RDF element, which uses the > bqbiol namespace and the bqmodel namespace. > > For a simple example (and based on how it's done in MFO to make life easier > for me - http://cisban-silico.cs.ncl.ac.uk/MFO/), the OWL equivalent of > the > above annotation is below. In *bold* is the only major change to the > internals of the rdf:RDF element - the rest of the changes are "xmlns" > changes in the rdf:RDF tag: > <rdf:RDF xmlns="http://www.sbml.org/sbml/level2/sbmll2v4/" > xml:base="http://www.sbml.org/sbml/level2/sbmll2v4/" > xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" > xmlns:owl="http://www.w3.org/2002/07/owl#" > xmlns:xsd="http://www.w3.org/2001/XMLSchema#" > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:sbmll2v4="http://www.sbml.org/sbml/level2/sbmll2v4/"> > <owl:Ontology rdf:about="http://www.sbml.org/sbml/level2/sbmll2v4/"/> > *<owl:NamedIndividual rdf:about="#_000002"> > <rdf:type rdf:resource="&sbmll2v4;MiriamAnnotation"/> > <bqbIs > rdf:datatype="&xsd;string">urn:miriam:obo.go:GO%3A0031594</bqbIs> > </owl:NamedIndividual>* > </rdf:RDF> > > > Some notes on this example: > > 1. Not sure we'd need to name the ontology or not, so may not need the > <owl:Ontology> element each time - certainly don't need it for simple RDF > parsing. > 2. In this example, we are treating the sbml element as an > individual/instance of the class MiriamAnnotation. This may or may not be > the right decision - it could be an anonymous individual or could be a > class, for example. > 3. Also, I'm ot sure *just* the metaid could go in the rdf:about field, > though we do it in the SBML rdf annotation itself right now. Would need > more > experienced people for RDF or OWL to answer that. Otherwise, the > rdf:about > could point to a URI based on the model number and the metaid (e.g. > http://www.sbml.org/sbml/level2/sbmll2v4/BIOMD0000000001_000002") > > > The above OWL example isn't quite the full story: the xmlns that I have > labelled sbmll2v4 would need to have, at a minimum, the following > declarations in it, as they are used in the example: > > <!-- Definition of the datatype property bqb Is --> > <owl:DatatypeProperty rdf:about="&sbmll2v4;bqbIs"> > <rdfs:range rdf:resource="&xsd;string"/> > </owl:DatatypeProperty> > > <!-- The class for which the example above is an instance of --> > <owl:Class rdf:about="&sbmll2v4;MiriamAnnotation"/> > > As an aside, in MFO everything is converted to OWL, so the Species class is > linked to the MiriamAnnotation class, which links through to the various bq > qualifiers. We wouldn't need to do all of that here, as we only want the > annotation in OWL. > > As negation seems such a hot topic, below is the extra lines required for > the original example in order to add a second go term as a bqb is *not*. > These lines would be added within the same rdf:RDF element in the > annotation > section: > *<rdf:Description> > <rdf:type rdf:resource="&owl;NegativePropertyAssertion"/> > <owl:targetValue>urn:miriam:obo.go:GO%3A0031595</owl:targetValue> > <owl:sourceIndividual rdf:resource="&sbmll2v4;_000002"/> > <owl:assertionProperty rdf:resource="&sbmll2v4;bqbIs"/> > </rdf:Description>* > > > Remember, the examples are also attached to be viewed in their completeness > either in an editor or in Protege. > > It's a first bash, anyway. Enjoy! > > -- > Allyson Lister > > Please note the new email address of all...@ne..., > although the old email address will still work. > > Newcastle University, http://www.ncl.ac.uk > http://themindwobbles.wordpress.com > > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot > > -- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com |
|
From: Allyson L. <a.l...@ne...> - 2011-06-16 10:15:05
|
Hi all,
I've been asked to make up a basic example of how we might do things in the
annot package if we allowed OWL rather than just RDF. As OWL can be saved as
RDF/XML, people who aren't interested in the annotation, or who are just
interested in using a plain RDF parser can manage. We could still say in the
proposal that any RDF is allowed, but then further specify (if we so decide)
that MIRIAM annotations and other SBML-backed annotations are described
using OWL, thus allowing things like negation.
I'm not saying that we have to use OWL, or that we have to use these
structures (and I have deliberately left the example minimalist, without
much reference to the higher functions of OWL), but it would leave the door
open for more complex statements in future, without losing the RDF structure
many are familiar with.
Happy to go with the general consensus, of course. Just thought I'd put this
out there. By the way, I am sure there are other ways to do the examples,
and there might be other ways to do the negation. Please feel free to put
your own examples out, and definitely please comment on these.
Attachments can be viewed in a normal text editor (they're very simple) or
opened in Protege, where you get more of an idea of the shape of an OWL
file.
miriam-test.owl is the first example, and miriam-test-negation.owl is that
example converted into a negation.
Here are the examples. First, a simple bqb "is" qualifier. In SBML it looks
like this (this entry is BIOMD0000000001):
<rdf:RDF xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:vCard="
http://www.w3.org/2001/vcard-rdf/3.0#"
xmlns:bqbiol="
http://biomodels.net/biology-qualifiers/"
xmlns:bqmodel="
http://biomodels.net/model-qualifiers/">
<rdf:Description rdf:about="#_000002">
<bqbiol:is>
<rdf:Bag>
<rdf:li
rdf:resource="urn:miriam:obo.go:GO%3A0031594"/>
</rdf:Bag>
</bqbiol:is>
</rdf:Description>
</rdf:RDF>
In the above example, we have the standard rdf:RDF element, which uses the
bqbiol namespace and the bqmodel namespace.
For a simple example (and based on how it's done in MFO to make life easier
for me - http://cisban-silico.cs.ncl.ac.uk/MFO/), the OWL equivalent of the
above annotation is below. In *bold* is the only major change to the
internals of the rdf:RDF element - the rest of the changes are "xmlns"
changes in the rdf:RDF tag:
<rdf:RDF xmlns="http://www.sbml.org/sbml/level2/sbmll2v4/"
xml:base="http://www.sbml.org/sbml/level2/sbmll2v4/"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:sbmll2v4="http://www.sbml.org/sbml/level2/sbmll2v4/">
<owl:Ontology rdf:about="http://www.sbml.org/sbml/level2/sbmll2v4/"/>
*<owl:NamedIndividual rdf:about="#_000002">
<rdf:type rdf:resource="&sbmll2v4;MiriamAnnotation"/>
<bqbIs
rdf:datatype="&xsd;string">urn:miriam:obo.go:GO%3A0031594</bqbIs>
</owl:NamedIndividual>*
</rdf:RDF>
Some notes on this example:
1. Not sure we'd need to name the ontology or not, so may not need the
<owl:Ontology> element each time - certainly don't need it for simple RDF
parsing.
2. In this example, we are treating the sbml element as an
individual/instance of the class MiriamAnnotation. This may or may not be
the right decision - it could be an anonymous individual or could be a
class, for example.
3. Also, I'm ot sure *just* the metaid could go in the rdf:about field,
though we do it in the SBML rdf annotation itself right now. Would need more
experienced people for RDF or OWL to answer that. Otherwise, the rdf:about
could point to a URI based on the model number and the metaid (e.g.
http://www.sbml.org/sbml/level2/sbmll2v4/BIOMD0000000001_000002")
The above OWL example isn't quite the full story: the xmlns that I have
labelled sbmll2v4 would need to have, at a minimum, the following
declarations in it, as they are used in the example:
<!-- Definition of the datatype property bqb Is -->
<owl:DatatypeProperty rdf:about="&sbmll2v4;bqbIs">
<rdfs:range rdf:resource="&xsd;string"/>
</owl:DatatypeProperty>
<!-- The class for which the example above is an instance of -->
<owl:Class rdf:about="&sbmll2v4;MiriamAnnotation"/>
As an aside, in MFO everything is converted to OWL, so the Species class is
linked to the MiriamAnnotation class, which links through to the various bq
qualifiers. We wouldn't need to do all of that here, as we only want the
annotation in OWL.
As negation seems such a hot topic, below is the extra lines required for
the original example in order to add a second go term as a bqb is *not*.
These lines would be added within the same rdf:RDF element in the annotation
section:
*<rdf:Description>
<rdf:type rdf:resource="&owl;NegativePropertyAssertion"/>
<owl:targetValue>urn:miriam:obo.go:GO%3A0031595</owl:targetValue>
<owl:sourceIndividual rdf:resource="&sbmll2v4;_000002"/>
<owl:assertionProperty rdf:resource="&sbmll2v4;bqbIs"/>
</rdf:Description>*
Remember, the examples are also attached to be viewed in their completeness
either in an editor or in Protege.
It's a first bash, anyway. Enjoy!
--
Allyson Lister
Please note the new email address of all...@ne...,
although the old email address will still work.
Newcastle University, http://www.ncl.ac.uk
http://themindwobbles.wordpress.com
|
|
From: Nicolas Le N. <le...@eb...> - 2011-05-10 21:21:13
|
SBMLeditor http://www.ebi.ac.uk/compneur-srv/SBMLeditor.html On 10/05/11 18:39, Michel Dumontier wrote: > Hi, > What software that can be currently used to create/edit/save *SBO* > annotations (in the XML elements)? > > m. > -- Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468, Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ |
|
From: Neil S. <nei...@ma...> - 2011-05-10 18:11:45
|
Hi Michel, You could try libAnnotationSBML. Works with any data type that is supported by MIRIAM resources. I haven't got my computer at home but I can get you more details tomorrow. Cheers, Neil. On 10 May 2011, at 18:39, Michel Dumontier <mic...@gm...> wrote: > Hi, > What software that can be currently used to create/edit/save *SBO* > annotations (in the XML elements)? > > m. > > -- > Michel Dumontier > Associate Professor of Bioinformatics > Carleton University > http://dumontierlab.com > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Michel D. <mic...@gm...> - 2011-05-10 17:39:23
|
Hi, What software that can be currently used to create/edit/save *SBO* annotations (in the XML elements)? m. -- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com |
|
From: Michel D. <mic...@gm...> - 2011-05-10 14:05:52
|
On Tue, May 10, 2011 at 8:39 AM, Stefan Hoops <sh...@vb...> wrote: > Hello All, > > I think the discussion should not be about OWL, OWL2 or RDF. We need to > understand what we want to do. > > We started with the need to identify or relate modeling objects with > biological well defined entities through MIRIAM resources. This > information should be easily augmented by other people. The added > information may even contradict the initial statement without > invalidating it. If we go the ontology route I see problems with this > use case because only one statement can be true. I envisioned annotation > to work like WWW where more and more relationships are created and thus > the modeling entities become better comparable and new relationships can > be discovered or errors can be found. Michel showed impressively at > HARMONY that we can achieve this with RDF even the restricted set used > in SBML L2. > > to clarify: We provided "ontological commitment" by committing the relations to a particular meaning, which we could subsequently check through automated reasoning. There were plenty of cases where the relations were "misused" because one could assert anything, and it wasn't necessarily clear what the referent was meant to be. In our work, we would have to check the miriam uri in order to determine what kind of annotation was meant - for instance, go terms fall into one of 3 categories, so we first had to determine which category, and then create the appropriate expression. None of this would have been required, if the relations constrained the values to a particular type (e.g. physical entity, function, process, quality, etc) irregardless of the vocabulary used. In my opinion one large problem remained which was the inability to > capture who made an statement and why the person made a statement. Both > these issues have been addressed by allowing reiffication a standard RDF > construct which was prohibited in SBML core. > > An alternative is to use rdf graphs along with some provenance vocabulary: * rdf:graph http://www.w3.org/TR/rdf-mt/#graphdefs * nanopublications: http://www.slideshare.net/paolociccarese/alzswan-hyque-and-nanopublications * nanopublications: http://www.w3.org/wiki/images/4/4a/HCLS$$ISWC2009$$Workshop$Mons.pdf * rdf molecules: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.74.7085&rep=rep1&type=pdf > The last not addressed issue are negative statements like: > Species a has not been found. > > This can easily be addressed by adding the proper qualifiers to the > MIRIAM resources. > > In the absence of a construct for negation, you'll unnecessarily proliferate the number of relations. If you're going to reify anyways, you can add a "is_negated" attribute. We did this for our HyQue database: http://dumontierlab.com/pdf/2010_BIOONT_hyque.pdf > I may however have completely missed the intend of the L3 annotation > package in that it is really meant to describe unambiguously any > modeling entity. If we want to do this we should look at existing > solution which are ontology based. Nothing prevents us in SBML L3 to > insert BioPAX fragments into the document. > > for the record, the BioPAX ontology will not do what we did for the SBML validation work. m. > Thanks, > Stefan > > On 5/9/11 6:05 AM, Nicolas Le Novère wrote: > > On 22/04/11 15:58, Neil Swainston wrote: > > > >> A.d. This troubles me a little. By going down the RDF route (rather than > >> OWL/OWL2) are we preventing ourselves from making negative statements in > >> future? I personally don't fancy introducing a second annotation method > >> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team > >> Annot? > > > > This is IMHO one of the most important discussions we need to have. There > > are pros and cons on both sides: > > > > RDF > > === > > > > Cons: limited expressiveness. It does not seems this is likely to change. > > Pros: large support in the semantic web, coherent with SBML core, support > > by the SBML community, and in development by the CellML and NeuroML > communities > > > > OWL2 > > ==== > > > > Cons: Not widely supported yet, different from what we do in SBML core. > We > > may scare off developers. > > Pros: More expressive. BioPAX is in OWL2. > > > > We can also "port" some of OWL's structures into SBML's RDF. > > > > I do not think we are talking about a year's time as Neil wrote. Whatever > > we choose is a commitment for a few years. This is not necessarily a bad > > thing. The whole linked data is evolving fast at the moment. > > > > > -- > Stefan Hoops, Ph.D. > Senior Project Associate > Virginia Bioinformatics Institute - 0477 > Virginia Tech > Bioinformatics Facility II > Blacksburg, Va 24061, USA > > Phone: (540) 231-1799 > Fax: (540) 231-2606 > Email: sh...@vb... > > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot > -- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com |
|
From: Stefan H. <sh...@vb...> - 2011-05-10 12:39:35
|
Hello All, I think the discussion should not be about OWL, OWL2 or RDF. We need to understand what we want to do. We started with the need to identify or relate modeling objects with biological well defined entities through MIRIAM resources. This information should be easily augmented by other people. The added information may even contradict the initial statement without invalidating it. If we go the ontology route I see problems with this use case because only one statement can be true. I envisioned annotation to work like WWW where more and more relationships are created and thus the modeling entities become better comparable and new relationships can be discovered or errors can be found. Michel showed impressively at HARMONY that we can achieve this with RDF even the restricted set used in SBML L2. In my opinion one large problem remained which was the inability to capture who made an statement and why the person made a statement. Both these issues have been addressed by allowing reiffication a standard RDF construct which was prohibited in SBML core. The last not addressed issue are negative statements like: Species a has not been found. This can easily be addressed by adding the proper qualifiers to the MIRIAM resources. I may however have completely missed the intend of the L3 annotation package in that it is really meant to describe unambiguously any modeling entity. If we want to do this we should look at existing solution which are ontology based. Nothing prevents us in SBML L3 to insert BioPAX fragments into the document. Thanks, Stefan On 5/9/11 6:05 AM, Nicolas Le Novère wrote: > On 22/04/11 15:58, Neil Swainston wrote: > >> A.d. This troubles me a little. By going down the RDF route (rather than >> OWL/OWL2) are we preventing ourselves from making negative statements in >> future? I personally don't fancy introducing a second annotation method >> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team >> Annot? > > This is IMHO one of the most important discussions we need to have. There > are pros and cons on both sides: > > RDF > === > > Cons: limited expressiveness. It does not seems this is likely to change. > Pros: large support in the semantic web, coherent with SBML core, support > by the SBML community, and in development by the CellML and NeuroML communities > > OWL2 > ==== > > Cons: Not widely supported yet, different from what we do in SBML core. We > may scare off developers. > Pros: More expressive. BioPAX is in OWL2. > > We can also "port" some of OWL's structures into SBML's RDF. > > I do not think we are talking about a year's time as Neil wrote. Whatever > we choose is a commitment for a few years. This is not necessarily a bad > thing. The whole linked data is evolving fast at the moment. > -- Stefan Hoops, Ph.D. Senior Project Associate Virginia Bioinformatics Institute - 0477 Virginia Tech Bioinformatics Facility II Blacksburg, Va 24061, USA Phone: (540) 231-1799 Fax: (540) 231-2606 Email: sh...@vb... |
|
From: Dagmar W. <dag...@un...> - 2011-05-09 19:25:15
|
Hello, it seems arguments for OWL are pretty reasonable. If we start our unbiased vote, I'd agree with Nick and address a bigger audience than sbml-annot. Dagmar On 05/09/2011 12:27 PM, Nick Juty wrote: > I think it would be wise to hold off on API support for the current proposal. > My inclination, based on developments all around us, would be to move to OWL2. > But to be honest, since this would more largely impact SBML/developers, we should put that question to a wider audience... > > cheers > > Nick > > Neil Swainston wrote: >> Hi all, >> >> I agree with all of Nicolas's points bar one: >> >>>> OWL2 >>>> ==== >>>> >>>> Cons: We may scare off developers. >> >> While we should be very careful not to scare off developers, I think that if we are sensible about how we generate a libSBML extension for annot, we can "hide" much of the OWL2 (or RDF) complexity behind a simple API. In either case (OWL2 or RDF) we are essentially generating triples, so at the very basic level, adding some methods to SBase along the lines of... >> >> addStatement( String predicate, String object ) >> >> ...should hide much of the complexity from the developer, whether we go with OWL2 or RDF. This could be extended to support Reification, perhaps hook into MIRIAM resources, etc. >> >> Also, we would like to provide a more expressive interface for those who know what they are doing, such that they can just get/set a block of annotation if they'd like. >> >> My main question is, what do we do now? At Harmony, myself, Sarah and Frank were taking about generating an API to support our current proposal. While I'm happy and interested to do this, I don't want to until we've nailed down more fundamental questions like OWL2 vs RDF. >> >> Cheers, >> >> Neil. >> >> Neil Swainston >> Experimental Officer >> >> Manchester Centre for Integrative Systems Biology >> Manchester Interdisciplinary Biocentre >> University of Manchester >> Manchester M1 7DN >> United Kingdom >> >> On 9 May 2011, at 11:05, Nicolas Le Novère wrote: >> >>> On 22/04/11 15:58, Neil Swainston wrote: >>> >>>> A.d. This troubles me a little. By going down the RDF route (rather than >>>> OWL/OWL2) are we preventing ourselves from making negative statements in >>>> future? I personally don't fancy introducing a second annotation method >>>> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team >>>> Annot? >>> This is IMHO one of the most important discussions we need to have. There >>> are pros and cons on both sides: >>> >>> RDF >>> === >>> >>> Cons: limited expressiveness. It does not seems this is likely to change. >>> Pros: large support in the semantic web, coherent with SBML core, support >>> by the SBML community, and in development by the CellML and NeuroML communities >>> >>> OWL2 >>> ==== >>> >>> Cons: Not widely supported yet, different from what we do in SBML core. We >>> may scare off developers. >>> Pros: More expressive. BioPAX is in OWL2. >>> >>> We can also "port" some of OWL's structures into SBML's RDF. >>> >>> I do not think we are talking about a year's time as Neil wrote. Whatever >>> we choose is a commitment for a few years. This is not necessarily a bad >>> thing. The whole linked data is evolving fast at the moment. >>> >>> -- >>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC, >>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468, >>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere >>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ >>> >>> >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network >>> management toolset available today. Delivers lowest initial >>> acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> Sbml-annot mailing list >>> Sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-annot >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Sbml-annot mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-annot |
|
From: Michel D. <mic...@gm...> - 2011-05-09 14:18:15
|
Hi all, The solution to this problem is to develop an SBML annotation API that hides the specifics of the representation from the user. In this way, users would use the API to create specific annotations (e.g. specifying the nature of physical entity, indicating which functions are being realized or the process is being modelled, etc), but the API creates OWL representation using the OWLAPI (as we have done). Thus, this will immediately integrate the annotations as an OWL ontology from which an application can also check consistency, compute subsumption, etc, towards a more comprehensive annotation system. In this way your development benefits from all the tools and support around OWL, and new requirements beyond those currently in play can be brought through a future round of the OWL specification. Cheers, m. On Mon, May 9, 2011 at 6:05 AM, Nicolas Le Novère <le...@eb...> wrote: > On 22/04/11 15:58, Neil Swainston wrote: > > > A.d. This troubles me a little. By going down the RDF route (rather than > > OWL/OWL2) are we preventing ourselves from making negative statements in > > future? I personally don't fancy introducing a second annotation method > > based on RDF only to ditch it for OWL in a year's time. Thoughts, Team > > Annot? > > This is IMHO one of the most important discussions we need to have. There > are pros and cons on both sides: > > RDF > === > > Cons: limited expressiveness. It does not seems this is likely to change. > Pros: large support in the semantic web, coherent with SBML core, support > by the SBML community, and in development by the CellML and NeuroML > communities > > OWL2 > ==== > > Cons: Not widely supported yet, different from what we do in SBML core. We > may scare off developers. > Pros: More expressive. BioPAX is in OWL2. > > We can also "port" some of OWL's structures into SBML's RDF. > > I do not think we are talking about a year's time as Neil wrote. Whatever > we choose is a commitment for a few years. This is not necessarily a bad > thing. The whole linked data is evolving fast at the moment. > > -- > Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC, > Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468, > Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere > http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot > -- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com |
|
From: Michel D. <mic...@gm...> - 2011-05-09 14:09:15
|
Hi Nicolas, On Mon, May 9, 2011 at 5:51 AM, Nicolas Le Novère <le...@eb...> wrote: > On 22/04/11 14:48, Michel Dumontier wrote: > > A. syntax and semantics of containers and collections >> > > a. Figure 6 shows two annotations linked through the "is" property to a >> glucose species. Given the intended semantics of "is" and that ChEBI and >> KEGG are two different resources, it seems to be that what is actually >> meant >> is that this species corresponds to (represents) the physical entities >> denoted by the ChEBI and KEGG identifiers, and that these should not be >> disjoint types. I really see two distinct statements (in turtle format). >> :meta_glc bqbiol:is<urn:miriam:obo.chebi:CHEBI%3417234> >> :meta_glc bqbiol:is<urn:miriam:kegg.compound:C00234> >> > > Yes, that's correct. The point here is that SBML Level 2 annotations put > meaning on the bags. In particular, sibbling bags where related to their > bearer by "hasVersion" relationships. This example is actually wrong, it > should present two bags, each containing one annotation. I agree this is a > bit nuts. That is what we are trying to fix. > > just to reiterate - i do not believe you want a bag at all here -> instead we want the biological statements as they would be queried. > > b. Figure 7 shows the annotation of a calcium-calmodulin complex, in which >> the intent is to state that the complex is composed of calcium and that >> the >> complex is composed of calmodulin. the mereological nature of this >> statement >> basically doesn't require one to state either a conjunction (which would >> imply that the value is a member of both types) or disjunction (which >> would >> imply that the value is a member of one or the other types), but rather >> should be treated as a set of separate statements >> >> :cacam bqbiol:hasPart<urn:miriam:uniprot:P62158> >> :cacam bqbiol:hasPart<urn:miriam:kegg.compound:C00076> >> > > But the bag here would become very important if we were to put attributes > on it, such as "disjoint=true/false". This is one of the missing bit in the > framework at the moment. > heh - you will reinvent a language (principly OWL) -> just look at GFF/OBO file format for ever expanding semantics that it was not designed to accommodate. > > On the other side the annotation package is for ... annotation. So maybe we > just want the triples indeed, and not a fully blown description of the > biology behind. yes and no. Yes, you should be able to semantically annotate parts of the SBML model. We can check the consistency (accuracy) of the annotations if they are formally represented, and integrated with the ontologies from which they are drawn. > Do-we care that P62158 and C00076 are disjoint of not? > > While an ontology should tell you this, it's plausable that users may want to contribute such statements about the annotations themselves. > It may be useful if we derive SBGN maps from the SBML file though. > > i don't know enough about SBGN to comment. m. > > -- > Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC, > Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468, > Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere > http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ > > -- Michel Dumontier Associate Professor of Bioinformatics Carleton University http://dumontierlab.com |
|
From: Nick J. <ju...@eb...> - 2011-05-09 10:45:00
|
I love it - but I think you are biasing the vote in favor of OWL, since the RDF is not connected to a computer. You should be a bit more impartial ;p Neil Swainston wrote: > Hi all, > > I think that we should put it to a vote. But, as Nicolas pointed out, > most people only vote on simple things like preferred logos. > > I have therefore generated the following ballot paper to increase voter > turnout: > > http://dl.dropbox.com/u/8980329/vote.jpg > > Should do the trick. > > Cheers, > > Neil. > > Neil Swainston > Experimental Officer > > Manchester Centre for Integrative Systems Biology > Manchester Interdisciplinary Biocentre > University of Manchester > Manchester M1 7DN > United Kingdom > > On 9 May 2011, at 11:27, Nick Juty wrote: > >> I think it would be wise to hold off on API support for the current >> proposal. >> My inclination, based on developments all around us, would be to move >> to OWL2. >> But to be honest, since this would more largely impact >> SBML/developers, we should put that question to a wider audience... >> >> cheers >> >> Nick >> >> Neil Swainston wrote: >>> Hi all, >>> I agree with all of Nicolas's points bar one: >>>>> OWL2 >>>>> ==== >>>>> >>>>> Cons: We may scare off developers. >>> While we should be very careful not to scare off developers, I think >>> that if we are sensible about how we generate a libSBML extension for >>> annot, we can "hide" much of the OWL2 (or RDF) complexity behind a >>> simple API. In either case (OWL2 or RDF) we are essentially >>> generating triples, so at the very basic level, adding some methods >>> to SBase along the lines of... >>> addStatement( String predicate, String object ) >>> ...should hide much of the complexity from the developer, whether we >>> go with OWL2 or RDF. This could be extended to support Reification, >>> perhaps hook into MIRIAM resources, etc. >>> Also, we would like to provide a more expressive interface for those >>> who know what they are doing, such that they can just get/set a block >>> of annotation if they'd like. >>> My main question is, what do we do now? At Harmony, myself, Sarah and >>> Frank were taking about generating an API to support our current >>> proposal. While I'm happy and interested to do this, I don't want to >>> until we've nailed down more fundamental questions like OWL2 vs RDF. >>> Cheers, >>> Neil. >>> Neil Swainston >>> Experimental Officer >>> Manchester Centre for Integrative Systems Biology >>> Manchester Interdisciplinary Biocentre >>> University of Manchester >>> Manchester M1 7DN >>> United Kingdom >>> On 9 May 2011, at 11:05, Nicolas Le Novère wrote: >>>> On 22/04/11 15:58, Neil Swainston wrote: >>>> >>>>> A.d. This troubles me a little. By going down the RDF route (rather >>>>> than >>>>> OWL/OWL2) are we preventing ourselves from making negative >>>>> statements in >>>>> future? I personally don't fancy introducing a second annotation method >>>>> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team >>>>> Annot? >>>> This is IMHO one of the most important discussions we need to have. >>>> There are pros and cons on both sides: >>>> >>>> RDF >>>> === >>>> >>>> Cons: limited expressiveness. It does not seems this is likely to >>>> change. >>>> Pros: large support in the semantic web, coherent with SBML core, >>>> support by the SBML community, and in development by the CellML and >>>> NeuroML communities >>>> >>>> OWL2 >>>> ==== >>>> >>>> Cons: Not widely supported yet, different from what we do in SBML >>>> core. We may scare off developers. >>>> Pros: More expressive. BioPAX is in OWL2. >>>> >>>> We can also "port" some of OWL's structures into SBML's RDF. >>>> >>>> I do not think we are talking about a year's time as Neil wrote. >>>> Whatever we choose is a commitment for a few years. This is not >>>> necessarily a bad thing. The whole linked data is evolving fast at >>>> the moment. >>>> >>>> -- >>>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC, >>>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468, >>>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere >>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> WhatsUp Gold - Download Free Network Management Software >>>> The most intuitive, comprehensive, and cost-effective network >>>> management toolset available today. Delivers lowest initial >>>> acquisition cost and overall TCO of any competing solution. >>>> http://p.sf.net/sfu/whatsupgold-sd >>>> _______________________________________________ >>>> Sbml-annot mailing list >>>> Sbm...@li... >>>> <mailto:Sbm...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/sbml-annot >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network >>> management toolset available today. Delivers lowest initial >>> acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> Sbml-annot mailing list >>> Sbm...@li... >>> <mailto:Sbm...@li...> >>> https://lists.sourceforge.net/lists/listinfo/sbml-annot >> >> -- >> -------------------------------------------------------- >> Nick Juty >> Database Curator >> European Bioinformatics Institute >> Cambridge, United Kingdom >> -------------------------------------------------------- > -- -------------------------------------------------------- Nick Juty Database Curator European Bioinformatics Institute Cambridge, United Kingdom -------------------------------------------------------- |
|
From: Neil S. <nei...@ma...> - 2011-05-09 10:40:11
|
Hi all, I think that we should put it to a vote. But, as Nicolas pointed out, most people only vote on simple things like preferred logos. I have therefore generated the following ballot paper to increase voter turnout: http://dl.dropbox.com/u/8980329/vote.jpg Should do the trick. Cheers, Neil. Neil Swainston Experimental Officer Manchester Centre for Integrative Systems Biology Manchester Interdisciplinary Biocentre University of Manchester Manchester M1 7DN United Kingdom On 9 May 2011, at 11:27, Nick Juty wrote: > I think it would be wise to hold off on API support for the current proposal. > My inclination, based on developments all around us, would be to move to OWL2. > But to be honest, since this would more largely impact SBML/developers, we should put that question to a wider audience... > > cheers > > Nick > > Neil Swainston wrote: >> Hi all, >> I agree with all of Nicolas's points bar one: >>>> OWL2 >>>> ==== >>>> >>>> Cons: We may scare off developers. >> While we should be very careful not to scare off developers, I think that if we are sensible about how we generate a libSBML extension for annot, we can "hide" much of the OWL2 (or RDF) complexity behind a simple API. In either case (OWL2 or RDF) we are essentially generating triples, so at the very basic level, adding some methods to SBase along the lines of... >> addStatement( String predicate, String object ) >> ...should hide much of the complexity from the developer, whether we go with OWL2 or RDF. This could be extended to support Reification, perhaps hook into MIRIAM resources, etc. >> Also, we would like to provide a more expressive interface for those who know what they are doing, such that they can just get/set a block of annotation if they'd like. >> My main question is, what do we do now? At Harmony, myself, Sarah and Frank were taking about generating an API to support our current proposal. While I'm happy and interested to do this, I don't want to until we've nailed down more fundamental questions like OWL2 vs RDF. >> Cheers, >> Neil. >> Neil Swainston >> Experimental Officer >> Manchester Centre for Integrative Systems Biology >> Manchester Interdisciplinary Biocentre >> University of Manchester >> Manchester M1 7DN >> United Kingdom >> On 9 May 2011, at 11:05, Nicolas Le Novère wrote: >>> On 22/04/11 15:58, Neil Swainston wrote: >>> >>>> A.d. This troubles me a little. By going down the RDF route (rather than >>>> OWL/OWL2) are we preventing ourselves from making negative statements in >>>> future? I personally don't fancy introducing a second annotation method >>>> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team >>>> Annot? >>> This is IMHO one of the most important discussions we need to have. There are pros and cons on both sides: >>> >>> RDF >>> === >>> >>> Cons: limited expressiveness. It does not seems this is likely to change. >>> Pros: large support in the semantic web, coherent with SBML core, support by the SBML community, and in development by the CellML and NeuroML communities >>> >>> OWL2 >>> ==== >>> >>> Cons: Not widely supported yet, different from what we do in SBML core. We may scare off developers. >>> Pros: More expressive. BioPAX is in OWL2. >>> >>> We can also "port" some of OWL's structures into SBML's RDF. >>> >>> I do not think we are talking about a year's time as Neil wrote. Whatever we choose is a commitment for a few years. This is not necessarily a bad thing. The whole linked data is evolving fast at the moment. >>> >>> -- >>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC, >>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468, >>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere >>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ >>> >>> >>> ------------------------------------------------------------------------------ >>> WhatsUp Gold - Download Free Network Management Software >>> The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. >>> http://p.sf.net/sfu/whatsupgold-sd >>> _______________________________________________ >>> Sbml-annot mailing list >>> Sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-annot >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Sbml-annot mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-annot > > -- > -------------------------------------------------------- > Nick Juty > Database Curator > European Bioinformatics Institute > Cambridge, United Kingdom > -------------------------------------------------------- |
|
From: Nick J. <ju...@eb...> - 2011-05-09 10:27:20
|
I think it would be wise to hold off on API support for the current proposal. My inclination, based on developments all around us, would be to move to OWL2. But to be honest, since this would more largely impact SBML/developers, we should put that question to a wider audience... cheers Nick Neil Swainston wrote: > Hi all, > > I agree with all of Nicolas's points bar one: > >>> OWL2 >>> ==== >>> >>> Cons: We may scare off developers. > > > While we should be very careful not to scare off developers, I think that if we are sensible about how we generate a libSBML extension for annot, we can "hide" much of the OWL2 (or RDF) complexity behind a simple API. In either case (OWL2 or RDF) we are essentially generating triples, so at the very basic level, adding some methods to SBase along the lines of... > > addStatement( String predicate, String object ) > > ...should hide much of the complexity from the developer, whether we go with OWL2 or RDF. This could be extended to support Reification, perhaps hook into MIRIAM resources, etc. > > Also, we would like to provide a more expressive interface for those who know what they are doing, such that they can just get/set a block of annotation if they'd like. > > My main question is, what do we do now? At Harmony, myself, Sarah and Frank were taking about generating an API to support our current proposal. While I'm happy and interested to do this, I don't want to until we've nailed down more fundamental questions like OWL2 vs RDF. > > Cheers, > > Neil. > > Neil Swainston > Experimental Officer > > Manchester Centre for Integrative Systems Biology > Manchester Interdisciplinary Biocentre > University of Manchester > Manchester M1 7DN > United Kingdom > > On 9 May 2011, at 11:05, Nicolas Le Novère wrote: > >> On 22/04/11 15:58, Neil Swainston wrote: >> >>> A.d. This troubles me a little. By going down the RDF route (rather than >>> OWL/OWL2) are we preventing ourselves from making negative statements in >>> future? I personally don't fancy introducing a second annotation method >>> based on RDF only to ditch it for OWL in a year's time. Thoughts, Team >>> Annot? >> This is IMHO one of the most important discussions we need to have. There >> are pros and cons on both sides: >> >> RDF >> === >> >> Cons: limited expressiveness. It does not seems this is likely to change. >> Pros: large support in the semantic web, coherent with SBML core, support >> by the SBML community, and in development by the CellML and NeuroML communities >> >> OWL2 >> ==== >> >> Cons: Not widely supported yet, different from what we do in SBML core. We >> may scare off developers. >> Pros: More expressive. BioPAX is in OWL2. >> >> We can also "port" some of OWL's structures into SBML's RDF. >> >> I do not think we are talking about a year's time as Neil wrote. Whatever >> we choose is a commitment for a few years. This is not necessarily a bad >> thing. The whole linked data is evolving fast at the moment. >> >> -- >> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC, >> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468, >> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere >> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ >> >> >> ------------------------------------------------------------------------------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Sbml-annot mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-annot > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Sbml-annot mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-annot -- -------------------------------------------------------- Nick Juty Database Curator European Bioinformatics Institute Cambridge, United Kingdom -------------------------------------------------------- |
