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/ |