You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(43) |
Nov
(31) |
Dec
(113) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(63) |
Feb
(82) |
Mar
(71) |
Apr
(92) |
May
(94) |
Jun
(39) |
Jul
(75) |
Aug
(148) |
Sep
(202) |
Oct
(229) |
Nov
(179) |
Dec
(87) |
2003 |
Jan
(34) |
Feb
(29) |
Mar
(71) |
Apr
(37) |
May
(11) |
Jun
(41) |
Jul
(34) |
Aug
(30) |
Sep
(26) |
Oct
(32) |
Nov
(42) |
Dec
(35) |
2004 |
Jan
(42) |
Feb
(46) |
Mar
(14) |
Apr
(7) |
May
(14) |
Jun
(8) |
Jul
(15) |
Aug
(19) |
Sep
(20) |
Oct
(6) |
Nov
(8) |
Dec
(30) |
2005 |
Jan
(9) |
Feb
(13) |
Mar
(17) |
Apr
(4) |
May
(7) |
Jun
(26) |
Jul
(9) |
Aug
(8) |
Sep
(12) |
Oct
|
Nov
(2) |
Dec
(15) |
2006 |
Jan
(17) |
Feb
|
Mar
(4) |
Apr
|
May
(14) |
Jun
(20) |
Jul
(14) |
Aug
(9) |
Sep
(37) |
Oct
(4) |
Nov
(3) |
Dec
(2) |
2007 |
Jan
(23) |
Feb
(8) |
Mar
(35) |
Apr
(4) |
May
(1) |
Jun
(3) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
2008 |
Jan
(4) |
Feb
(3) |
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Jason S. <jas...@gm...> - 2006-06-28 08:38:40
|
Hey, On 6/28/06, Helen Parkinson <par...@eb...> wrote: > We have installed the Perl API, but we were > unable to run the example scripts available at http:// > mged.sourceforge.net/software/examples.php. It looks like the > examples here may have been intended for an earlier version of the STK. > For example, the examples refer to Bio::MAGE::XMLReader, but it looks > like this should be Bio::MAGE::XML::Reader as best we can > tell. By making modifications like this we are able to run some of the > example scripts, but not all of them (eg. it looks like mageml- > report-simple.pl refers to a constructor that isn't defined in > SimpleReportReader.pm). Is there a newer version of some examples using > the MAGE perl stk that we can refer to? Ouch! That looks like an old version. Looking at the versions available: http://sourceforge.net/project/showfiles.php?group_id=16076&package_id=33764 it appears that there were 5 releases of the MAGE API for 2002-09-02 Model, but the examples files were never re-packaged for the later releases, only the first release - that would explain why the package name was wrong for XML::Reader. You can check out the lib files from CVS directly, or I can make a new snapshot available on SF for you, if you prefer. You can browse CVS at: http://mged.cvs.sourceforge.net/mged/lib/Perl/ the instructions for downloading a module from CVS is at: http://sourceforge.net/cvs/?group_id=16076 the module you want is called 'lib/Perl'. > Also, we're having a little > trouble understanding what capabilities the stk has from the POD > documentation. Is there another source of documentation that describes > the larger scope of the stk that could point us towards which > classes/methods fit our needs? We would really appreciate any advice or > guidance you can give us in this regard. > Hrrmm grumble grumble.... No, I don't think so... Sorry. I'm actually just back on the MGED payroll to do exactly this. If you can bear with me - over the next couple of weeks I can get you what you need. I need to overhaul both the Perl and Java MAGEstk modules, and as you point out give them some decent documentation. Let me just get some clearance from Cathy Ball that this is how I should be spending my time and I will move ahead on this and help you guys out, cool? Cathy - does this seem like a good idea for me to focus my time? It's pretty much what we discussed, but the higher-level documentation also seems like a pretty good idea. Cheers, jas. |
From: Jason S. <jas...@gm...> - 2006-06-28 08:22:08
|
Hey, On 6/28/06, Kjell Petersen <Kje...@bc...> wrote: > >We also made a first pass at using the Java API, but we were unable to > >load in the MAGE-ML files available through EBI. We get the error > >message: "Hey. startElement is starting an element with no identifier > >attribute. Returning now." when trying to instantiate a new > >MageReader object. > > > The error message stems from the parsing process that MAGEReader starts > when using the constructor with a filename as parameter. > This is really an embarassing error message... It should list the line number of the file, the name of the element that was being parsed, and probably print out the list of attributes (if any). This would have at least let someone look at the MAGE-ML file and figure out why it was broken. I can have a go at modifying the reader to give nicer messages. Cheers, jas. |
From: Kjell P. <Kje...@bc...> - 2006-06-28 06:34:59
|
Hi Helen and Matthew, See comments inline on Java MAGEstk : Helen Parkinson wrote: >Hello mage people, > >can anyone assist Matthew <mh...@cs...> with his questions >about perl and java MAGEstk? > >thanks > >Helen > > > >We're really starting to try and work in earnest with the microarray >data available through EBI. In general we're basically trying to >extract the data values for each gene, for each experimental condition >in a dataset in order to >calculate pairwise distances between genes. > >Several of us here have tried to use the MAGEstk available at http:// >www.mged.org/Workgroups/MAGE/magestk.html to parse out the data with >varying levels of success. > <snip> >We also made a first pass at using the Java API, but we were unable to >load in the MAGE-ML files available through EBI. We get the error >message: "Hey. startElement is starting an element with no identifier >attribute. Returning now." when trying to instantiate a new >MageReader object. > The error message stems from the parsing process that MAGEReader starts when using the constructor with a filename as parameter. Are you giving MAGEReader the filename of a MAGE-ML file downloaded from ArrayExpress ? If you would send me the code snippet where you instantiate MAGEReader and the input MAGE-ML file (or the AE accession number), I'll see if I can spot what's making trouble. >But we haven't done much beyond that initial test. >Are there any examples of code that use the Java API to >manipulate MAGE-ML data? > > > Yes there is, I can send you some updated code with examples later. Cheers, Kjell |
From: Helen P. <par...@eb...> - 2006-06-27 20:46:07
|
Hello mage people, can anyone assist Matthew <mh...@cs...> with his questions about perl and java MAGEstk? thanks Helen We're really starting to try and work in earnest with the microarray data available through EBI. In general we're basically trying to extract the data values for each gene, for each experimental condition in a dataset in order to calculate pairwise distances between genes. Several of us here have tried to use the MAGEstk available at http:// www.mged.org/Workgroups/MAGE/magestk.html to parse out the data with varying levels of success. We have installed the Perl API, but we were unable to run the example scripts available at http:// mged.sourceforge.net/software/examples.php. It looks like the examples here may have been intended for an earlier version of the STK. For example, the examples refer to Bio::MAGE::XMLReader, but it looks like this should be Bio::MAGE::XML::Reader as best we can tell. By making modifications like this we are able to run some of the example scripts, but not all of them (eg. it looks like mageml- report-simple.pl refers to a constructor that isn't defined in SimpleReportReader.pm). Is there a newer version of some examples using the MAGE perl stk that we can refer to? Also, we're having a little trouble understanding what capabilities the stk has from the POD documentation. Is there another source of documentation that describes the larger scope of the stk that could point us towards which classes/methods fit our needs? We would really appreciate any advice or guidance you can give us in this regard. We also made a first pass at using the Java API, but we were unable to load in the MAGE-ML files available through EBI. We get the error message: "Hey. startElement is starting an element with no identifier attribute. Returning now." when trying to instantiate a new MageReader object. But we haven't done much beyond that initial test. Are there any examples of code that use the Java API to manipulate MAGE-ML data? Thank you very much for any pointers you can give us, Matt Hibbs -- Helen Parkinson, PhD Microarray Informatics Team EBI and Seconded Scientific Programme Manager NCRI Informatics Initiative www.cancerinformatics.org.uk EBI: 01223 494672 Skype: helen.parkinson.ebi |
From: Gavin S. <she...@ge...> - 2006-06-07 16:46:50
|
Dear Colleagues, Apologies if you receive this more than once. It is the pleasure of the Microarray Gene Expression Data (MGED) society to announce its 9th International meeting, MGED9, to be held in Seattle, Washington, Thursday September 7th -> Saturday September 9th, 2006. In addition, there will be a day of tutorials and workshops preceding the meeting on Wednesday September 6th. Further information is available at http://mgedmeeting.org/ and registration is now open. The scientific focus of the meeting will be high throughput screening methods - in particular microarrays - and associated data handling issues and analysis techniques. With the continued maturation of microarray annotation standards and tools, this year's meeting will offer more 'hands-on' tutorials and workshops to tackle specific practical applications of these concepts. Tutorials will cover in depth data analysis and how to use Bioconductor. We have lined up some outstanding speakers, who are leaders in their respective fields. The Keynote speakers include Leroy Hood, Michael Snyder, Mathias Uhlen, Daphne Koller and Janet Thornton. In addition, this year we will again be selecting half of the plenary speakers from submitted abstracts, to encourage greater participation in the MGED community. Continuing from last year, we will again be running a poster competition, with prizes for the best three posters presented by graduate and postdoctoral students. Immediately following MGED 9 will be a Gene Ontology users meeting, and an MGED programming Jamboree, to be held on September 10th through 12th. The Programming Jamboree is an opportunity for programmers to come together to work on problems relating to MAGE, MIAME, and the MGED Ontology in an interactive environment with leading experts in these areas. The jamboree is be limited to programmers willing to work on MGED-related problems. We look forward to seeing you all in Seattle, Sincerely, The Microarray Gene Expression Data (MGED) Society ---------------------------------------------------------------------- Preliminary Program: WEDNESDAY, SEPTEMBER 6th: "PRE-MEETING DAY" | Extended Tutorials, Hands-On Data Analysis, and the MO Workshop 09:30 - 12:30 | MeV Workshop by John Quackenbush This workshop will focus on microarray data analysis methods and techniques using the popular Multi-Experiment Viewer (MeV) open source Java based software package developed by John Quakenbush's group. MeV provides a wealth of data analysis tools via a user friendly point and click interface. if there is sufficient interest, an additional session may be added in the afternoon. 10:00 - 12:00 | MGED Ontology Working Group MGED Ontology and RSBI joint workshop on Applications for the MGED Ontology. Organized by Chis Stoeckert, Susanna Sansone and Helen Parkinson. Details to follow. 12:30 - 14:00 | Lunch 14:00 - 17:00 | Bioconductor Workshop This workshop will focus on using the R/Bioconductor package for microarray data analysis. Bioconductor is an open source R package consisting of a large number of programs that have been developed by researchers worldwide. The combination of R and Bioconductor provides end users with not only an inexpensive solution for data analysis but also a powerful scripting/programming language to create and perform customized methods and analyses. THURSDAY, SEPTEMBER 7th: 08:00 - 08:30 | Open registration, continental breakfast 08:30 - 09:00 | Welcome and organization details - Roger Bumgarner, Cathy Ball 09:00 - 10:30 | TUTORIAL 1: Making efficient use of the ArrayExpress Database 10:30 - 11:00 | Break 11:00 - 12:00 | Janet Thornton - Keynote Talk 12:00 - 13:30 | Lunch 13:30 - 15:00 | Session I - Talks from Submitted abstracts 15:00 - 15:20 | Break 15:20 - 17:30 | Session II - Michael Snyder - Keynote Talk and Talks from Submitted abstracts 17:30 - 19:30 | Poster Session I - Wine and cheese reception plus local microbrew beers FRIDAY, SEPTEMBER 8th: 08:30 - 09:45 | Public sharing of complex data types: Where do we go from here? Bob Robbins - Sharing Digital Biological Data - A historical perspective Alvis Brazma - On MGED's efforts, successes and challenges Eric Deutsch - MISFISHIE 09:40 - 10:00 | Panel discussion 10:00 - 10:20 | Break 10:20 - 12:00 | Session III - Leroy Hood - Keynote Talk and Talks from Submitted abstracts 12:30 - 13:30 | Lunch 13:30 - 15:00 | Session IV - Systems Biology Trey Ideker Eric Schadt Talks from Submitted abstracts 15:00 - 15:20 | Break 15:20 - 17:30 | Session V [Bioinformatics] - Daphne Koller - Keynote Talk and Talks from Submitted abstracts 17:30 - 19:30 | Poster Session II SATURDAY, SEPTEMBER 9th: 08:30 - 10:00 | Tutorial II 10:00 - 10:30 | Break 10:30 - 12:00 | Session VI - Mathias Uhlen - Keynote Talk and Talks from Submitted abstracts 12:00 - 13:30 | Lunch 13:30 - 15:00 | Session VII - Technologies that might replace arrays Michael Egholm - 454 Lifesciences Perry Fell - Nanostring Technologies Technology Talks from Submitted abstracts 15:00 - 15:20 | Break 15:20 - 17:00 | Session VIII - The future of expression technologies from an industrial, environmental and regulatory perspective. Opening talk by Dr. David Schwartz, Director of the Nation Institute of Environmental Health and Safety, NIH There will be other invited talks here but probably not any from submitted abstracts 17:00 - 18:00 | Transport to cruise 18:00 - 21:00 | Evening cruise on Puget Sound SUNDAY, SEPTEMBER 10th: Gene Ontology Users Meeting for details see geneontology.org Programming Jamboree - Day 1 MONDAY, SEPTEMBER 11th: Programming Jamboree - Day 2 TUESDAY, SEPTEMBER 12th: Programming Jamboree - Day 3 |
From: Ugis S. <ug...@eb...> - 2006-06-06 02:42:14
|
Michael, No, we haven't tried that - mostly because of the lack of LSID resolving-enabled clients. If and when they start to appear, we would consider that. Cheers, Ugis Miller, Michael D (Rosetta) wrote: >Hi All, > >We've been promoting using LSID style URIs for identifier attributes, >but has there been any work on building a true LSID resolver service at >ArrayExpress or SMD, i.e. using the standard interfaces exposed to the >web that are defined in the OMG LSID specification? > >cheers, >Michael > >-----Original Message----- >From: pub...@w3... >[mailto:pub...@w3...] On Behalf Of Kevin >Richards >Sent: Friday, June 02, 2006 6:48 AM >To: ma...@il...; pub...@w3... >Subject: Re: Use of LSID's "in the wild" > > > >We (TDWG - Taxonomic Databases Working Group - www.tdwg.org) are >currently investigating them for use with our taxonomic/biodiversity >informatics data located in many databases around the world. >We are having a meeting on GUIDs/LSIDs in Edinburgh next week. > >Kevin Richards >Landcare Research >New Zealand > > > >>>>Mark Wilkinson <ma...@il...> 06/02/06 5:10 AM >>> >>>> >>>> > >Hi all, > >I'm writing a manuscript at the moment where I discuss LSIDs, and I'm >trying to get a sense of how many people are using them "in the wild". >I know that biopathways has set up a lot of "proxy" LSID resolvers, but >that's kinda cheating :-) I'm wondering who is actually using the LSID >standard in a production environment. I know that BioMOBY and >myGrid/Tverna both use LSIDs, but who else? > >Any takers? > >Cheers! > >Mark > > > |
From: Miller, M. D (Rosetta) <Michael_Miller@Rosettabio.com> - 2006-06-06 02:32:02
|
Hi All, thanks for the updates--it looks like with the semantic web activity in life sciences at W3C that LSIDs will play a strong role. I agree with Ugis that the need to develop "official" LSID resolvers will come when there are clients trying to use LSID as their primary access to the semantic web. Steve Chervitz replied to Mark with a good summation of Affymetrix support and some other good points and links which I've forwarded to the mged list. cheers, Michael > -----Original Message----- > From: Ugis Sarkans [mailto:ug...@eb...]=20 > Sent: Monday, June 05, 2006 5:41 AM > To: Miller, Michael D (Rosetta) > Cc: Helen Parkinson; Cathy Ball; mge...@li... > Subject: Re: FW: Use of LSID's "in the wild" >=20 >=20 >=20 > Michael, >=20 > No, we haven't tried that - mostly because of the lack of LSID=20 > resolving-enabled clients. If and when they start > to appear, we would consider that. >=20 > Cheers, > Ugis >=20 > Miller, Michael D (Rosetta) wrote: >=20 > >Hi All, > > > >We've been promoting using LSID style URIs for identifier attributes, > >but has there been any work on building a true LSID resolver=20 > service at > >ArrayExpress or SMD, i.e. using the standard interfaces=20 > exposed to the > >web that are defined in the OMG LSID specification? > > > >cheers, > >Michael > > > >-----Original Message----- > >From: pub...@w3... > >[mailto:pub...@w3...] On Behalf Of Kevin > >Richards > >Sent: Friday, June 02, 2006 6:48 AM > >To: ma...@il...; pub...@w3... > >Subject: Re: Use of LSID's "in the wild" > > > > > > > >We (TDWG - Taxonomic Databases Working Group - www.tdwg.org) are > >currently investigating them for use with our taxonomic/biodiversity > >informatics data located in many databases around the world. > >We are having a meeting on GUIDs/LSIDs in Edinburgh next week. > > > >Kevin Richards > >Landcare Research > >New Zealand > > > > =20 > > > >>>>Mark Wilkinson <ma...@il...> 06/02/06 5:10 AM >>> > >>>> =20 > >>>> > > > >Hi all,=20 > > > >I'm writing a manuscript at the moment where I discuss LSIDs, and I'm > >trying to get a sense of how many people are using them "in=20 > the wild". > >I know that biopathways has set up a lot of "proxy" LSID=20 > resolvers, but > >that's kinda cheating :-) I'm wondering who is actually=20 > using the LSID > >standard in a production environment. I know that BioMOBY and > >myGrid/Tverna both use LSIDs, but who else? > > > >Any takers? > > > >Cheers! > > > >Mark > > > > =20 > > >=20 >=20 |
From: Miller, M. D (Rosetta) <Michael_Miller@Rosettabio.com> - 2006-06-06 02:20:46
|
Hi All, here's Steve's response to Mark's inquiry, some nice links. cheers, Michael -----Original Message----- From: pub...@w3... [mailto:pub...@w3...] On Behalf Of Steve Chervitz Sent: Friday, June 02, 2006 6:34 PM To: ma...@il...; pub...@w3... Subject: Re: Use of LSID's "in the wild" Hi Mark: =20 > I'm writing a manuscript at the moment where I discuss LSIDs, and I'm > trying to get a sense of how many people are using them "in the wild". > I know that biopathways has set up a lot of "proxy" LSID resolvers, but > that's kinda cheating :-) I'm wondering who is actually using the LSID > standard in a production environment. I know that BioMOBY and > myGrid/Tverna both use LSIDs, but who else? Here's a paper that describes the use of LSIDs by three other early adopters besides myGrid and BioMoby. It's co-authored by one of the authors of the LSID spec (Sean Martin): The impact of Life Science Identifiers on Informatics data http://www.broad.mit.edu/cgi-bin/cancer/publications/pub_paper.cgi?mode=3D= view &paper_id=3D126 When you ask, "who is using the LSID standard?" you might want to differentiate between organizations who have adopted LSID syntax vs those who are also hosting and maintaining LSID resolution services. The latter is a much bigger cookie to swallow, but the former is still a step forward. If the only thing that comes from the LSID spec is a notion of an identifier syntax that becomes widely adopted by bioinformatics data providers, it would be a huge success, which was also noted in the conclusion of an IBM article you may have seen: http://www-128.ibm.com/developerworks/webservices/library/os-lsid2/ Another useful distinction to make when considering who is using LSIDs is whether they are data providers or application providers (or both). Ideally, you'd like to see the application providers using LSIDs that are created and managed by the data providers, rather than used only internally within the application. Here are some LSID users that would fall into the data provider category: * The HapMap project. I don't know if they provide a resolution service. Search for 'LSID' on this page: http://www.hapmap.org/downloads/index.html.en * Affymetrix uses an LSID-like syntax in its MAGE-ML formatted files containing NetAffx annotations of the sequences used in array designs. Here's a snippet from one such file: <BioSequence_package> <BioSequence_assnlist> <BioSequence identifier=3D"Affymetrix.com:Transcript:HG-U133A.1007_s_at" .... It's not a true LSID since it doesn't begin with 'urn:lsid'. Affy doesn't host an LSID resolver or provide any sort of lookup service using these ids. I summarized some of the issues we ran into here (see the section titled 'LSIDs and Content Negotiation' in particular): http://lists.w3.org/Archives/Public/public-swls-ws/2004Nov/att-0000/Affy _Sem Web-LifeSci_position_paper.pdf * Pseudogene.org. Don't know if they offer a resolution service: http://www.pseudogene.org/cgi-bin/set-results.cgi?tax_id=3D9606&all=3DVie= w+A ll+S ets&criterion0=3D&operator0=3D&searchValue0=3D&sort=3D0&output=3Dhtml The following would fall in the application provider category of LSID users. While these may not fully qualify as "in the wild", one could ask: How widely are these apps being used by other parties, either in an R&D or production setting? * BioPathways Consortium (as you mention above). http://lsid.biopathways.org/authorities.shtml * Intellidimensions's RDF Gateway and Eric Jain's UniProt RDF project: http://labs.intellidimension.com/uniprot/query.rsp?q=3D10 http://expasy3.isb-sib.ch/~ejain//rdf/migration.html * KIM. See Sean Martin's presentation from the W3C meeting. It describes a system that makes extensive use of LSIDs: http://www.w3.org/2004/10/swls/w3c_slrp_presentation_Sean_Martin_IBM.pdf * GBIF. Looks like they are still at an early stage of development. http://wiki.gbif.org/dadiwiki/wikka.php?wakka=3Dcol2005lsid There may be others out there. This is not necessarily an exhaustive listing. Cheers, Steve |
From: Mark M. <mm...@sd...> - 2006-06-06 01:43:25
|
Pretty sure UBIO is. http://wiki.gbif.org/guidwiki/wikka.php?wakka=3DLSIDResolverForTaxonNames= U Bio -----Original Message----- From: mge...@li... [mailto:mge...@li...] On Behalf Of Trish Whetzel Sent: Friday, June 02, 2006 12:06 PM To: mge...@li... Subject: Re: [Mged-mage] Mged-mage Digest, Vol 1, Issue 706 >>>> Mark Wilkinson <ma...@il...> 06/02/06 5:10 AM >>> > > Hi all, > > I'm writing a manuscript at the moment where I discuss LSIDs, and I'm > trying to get a sense of how many people are using them "in the wild". > I know that biopathways has set up a lot of "proxy" LSID resolvers, but > that's kinda cheating :-) I'm wondering who is actually using the LSID > standard in a production environment. I know that BioMOBY and > myGrid/Tverna both use LSIDs, but who else? > > Any takers? I met Forbes Dewey at ISM/BioOntologies SIG last year and I think=20 he might have been using LSIDs. Also, you might want to check with the=20 BioPAX group: bio...@cb... Trish _______________________________________________ Mged-mage mailing list Mge...@li... https://lists.sourceforge.net/lists/listinfo/mged-mage |
From: Trish W. <wh...@pc...> - 2006-06-02 19:06:06
|
>>>> Mark Wilkinson <ma...@il...> 06/02/06 5:10 AM >>> > > Hi all, > > I'm writing a manuscript at the moment where I discuss LSIDs, and I'm > trying to get a sense of how many people are using them "in the wild". > I know that biopathways has set up a lot of "proxy" LSID resolvers, but > that's kinda cheating :-) I'm wondering who is actually using the LSID > standard in a production environment. I know that BioMOBY and > myGrid/Tverna both use LSIDs, but who else? > > Any takers? I met Forbes Dewey at ISM/BioOntologies SIG last year and I think he might have been using LSIDs. Also, you might want to check with the BioPAX group: bio...@cb... Trish |
From: John C. M. <jcm...@ge...> - 2006-06-02 18:04:09
|
Not in the wild, unfortunately... In SMD's developmental CVS (against emergent biosequence schema), I wrote some code to load reference sequences from a Saccharomyces cerevisiae GFF (from SGD) using my interpretation of the LSID specification (example: urn:lsid:www.yeastgenome.org:SGDID:S000001855). No application/ public-web-service currently uses it, however... -john On Jun 2, 2006, at 12:40 PM, Catherine Ball wrote: > Not at SMD. > > On Jun 2, 2006, at 8:46 AM, Miller, Michael D (Rosetta) wrote: > >> Hi All, >> >> We've been promoting using LSID style URIs for identifier attributes, >> but has there been any work on building a true LSID resolver >> service at >> ArrayExpress or SMD, i.e. using the standard interfaces exposed to >> the >> web that are defined in the OMG LSID specification? >> >> cheers, >> Michael >> >> -----Original Message----- >> From: pub...@w3... >> [mailto:pub...@w3...] On Behalf Of Kevin >> Richards >> Sent: Friday, June 02, 2006 6:48 AM >> To: ma...@il...; pub...@w3... >> Subject: Re: Use of LSID's "in the wild" >> >> >> >> We (TDWG - Taxonomic Databases Working Group - www.tdwg.org) are >> currently investigating them for use with our taxonomic/biodiversity >> informatics data located in many databases around the world. >> We are having a meeting on GUIDs/LSIDs in Edinburgh next week. >> >> Kevin Richards >> Landcare Research >> New Zealand >> >>>>> Mark Wilkinson <ma...@il...> 06/02/06 5:10 AM >>> >> >> Hi all, >> >> I'm writing a manuscript at the moment where I discuss LSIDs, and I'm >> trying to get a sense of how many people are using them "in the >> wild". >> I know that biopathways has set up a lot of "proxy" LSID resolvers, >> but >> that's kinda cheating :-) I'm wondering who is actually using the >> LSID >> standard in a production environment. I know that BioMOBY and >> myGrid/Tverna both use LSIDs, but who else? >> >> Any takers? >> >> Cheers! >> >> Mark >> >> -- >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> ++++ >> ++++ >> WARNING: This email and any attachments may be confidential and/or >> privileged. They are intended for the addressee only and are not >> to be >> read, >> used, copied or disseminated by anyone receiving them in error. If >> you >> are >> not the intended recipient, please notify the sender by return >> email and >> delete this message and any attachments. >> >> The views expressed in this email are those of the sender and do not >> necessarily reflect the official views of Landcare Research. >> >> Landcare Research >> http://www.landcareresearch.co.nz >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> ++++ >> ++++ >> >> >> >> >> > > > > _______________________________________________ > Mged-mage mailing list > Mge...@li... > https://lists.sourceforge.net/lists/listinfo/mged-mage |
From: Catherine B. <ba...@ge...> - 2006-06-02 16:41:16
|
Not at SMD. On Jun 2, 2006, at 8:46 AM, Miller, Michael D (Rosetta) wrote: > Hi All, > > We've been promoting using LSID style URIs for identifier attributes, > but has there been any work on building a true LSID resolver > service at > ArrayExpress or SMD, i.e. using the standard interfaces exposed to the > web that are defined in the OMG LSID specification? > > cheers, > Michael > > -----Original Message----- > From: pub...@w3... > [mailto:pub...@w3...] On Behalf Of Kevin > Richards > Sent: Friday, June 02, 2006 6:48 AM > To: ma...@il...; pub...@w3... > Subject: Re: Use of LSID's "in the wild" > > > > We (TDWG - Taxonomic Databases Working Group - www.tdwg.org) are > currently investigating them for use with our taxonomic/biodiversity > informatics data located in many databases around the world. > We are having a meeting on GUIDs/LSIDs in Edinburgh next week. > > Kevin Richards > Landcare Research > New Zealand > >>>> Mark Wilkinson <ma...@il...> 06/02/06 5:10 AM >>> > > Hi all, > > I'm writing a manuscript at the moment where I discuss LSIDs, and I'm > trying to get a sense of how many people are using them "in the wild". > I know that biopathways has set up a lot of "proxy" LSID resolvers, > but > that's kinda cheating :-) I'm wondering who is actually using the > LSID > standard in a production environment. I know that BioMOBY and > myGrid/Tverna both use LSIDs, but who else? > > Any takers? > > Cheers! > > Mark > > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++ > ++++ > WARNING: This email and any attachments may be confidential and/or > privileged. They are intended for the addressee only and are not to be > read, > used, copied or disseminated by anyone receiving them in error. If > you > are > not the intended recipient, please notify the sender by return > email and > delete this message and any attachments. > > The views expressed in this email are those of the sender and do not > necessarily reflect the official views of Landcare Research. > > Landcare Research > http://www.landcareresearch.co.nz > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++ > ++++ > > > > > |
From: Miller, M. D (Rosetta) <Michael_Miller@Rosettabio.com> - 2006-06-02 15:47:19
|
Hi All, We've been promoting using LSID style URIs for identifier attributes, but has there been any work on building a true LSID resolver service at ArrayExpress or SMD, i.e. using the standard interfaces exposed to the web that are defined in the OMG LSID specification? cheers, Michael -----Original Message----- From: pub...@w3... [mailto:pub...@w3...] On Behalf Of Kevin Richards Sent: Friday, June 02, 2006 6:48 AM To: ma...@il...; pub...@w3... Subject: Re: Use of LSID's "in the wild" We (TDWG - Taxonomic Databases Working Group - www.tdwg.org) are currently investigating them for use with our taxonomic/biodiversity informatics data located in many databases around the world. We are having a meeting on GUIDs/LSIDs in Edinburgh next week. Kevin Richards Landcare Research New Zealand >>> Mark Wilkinson <ma...@il...> 06/02/06 5:10 AM >>> Hi all,=20 I'm writing a manuscript at the moment where I discuss LSIDs, and I'm trying to get a sense of how many people are using them "in the wild". I know that biopathways has set up a lot of "proxy" LSID resolvers, but that's kinda cheating :-) I'm wondering who is actually using the LSID standard in a production environment. I know that BioMOBY and myGrid/Tverna both use LSIDs, but who else? Any takers? Cheers! Mark --=20 -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit,=20 a pipe between physical locations on the planet.=20 What's happened now is that the conduit has become so big and interesting=20 that communication has become more than a conduit,=20 it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. =20 Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ |
From: Jason S. <jas...@gm...> - 2006-05-17 04:11:39
|
Hey Joe, On 5/17/06, Joseph White <jw...@ji...> wrote: > Hi Adam and Jason, > > Since I'm a new svn user and need to learn it anyway, switching to svn > is fine with me. An overlap period might be in order. I already have > Tortoise running on my windos machines; this is a java app that runs on > linux, right? If not, I"m sure linux has something else that will do. > There are a number of frontends for linux, but there is also the standard command line interface that CVS has used for years - the SVN commands are a superset of CVS commands. Cheers, jas. |
From: Angel P. <an...@ma...> - 2006-05-16 19:04:35
|
On Tuesday 16 May 2006 12:16 pm, Trish Whetzel wrote: > > > > Another question on the table is what will be the standardizations > > process for the official release. Since PSI is implementing a totally > > open and formal review process, I put forward that we leverage this for > > formalization of FuGE. This is mainly a convenience for Andy and myself, > > since we already attend most of the PSI meetings and are going to be > > putting our tech-specific standards through that process, hence will be > > very familiar with it. I can provide anyone whom is interested with the > > documents that outline the PSI process, but suffice to say, it involves > > documentation of the standard, a public review and comment period, and > > final review and approval by the PSI steering committee, with feedback > > loops throughout the work flow. > > > > Comments? > > Do you mean that the FuGE project also adopt the doc approval process that > PSI uses, but implement within the context of the FuGE project and have > MGED and PSI as the external reviewers of the doc OR that FuGE be approved > within the context of PSI? > I meant that the FuGE project use PSI as a standardization body, much like MGED used the OMG in the first version of MAGE. You make a good suggestion that since this is a broad scope specification, the review board should be larger than the PSI steering group, hence MGED and PSI participants will need to sign off on this process. The published home of the specification (e.g. schema location) should still be outside of the psi namespace and will point back to the approval process that this went through via the PSI. Part of that approval process is a posting of user comments and review board decisions. All of the documents for the PSI process are available from the website: http://psidev.sourceforge.net/docstore You can use the anonymous login to view the repository of process Documents under the PSI Working Drafts (PWD) folder. URL for the process overview here: http://psidev.sourceforge.net/docstore/download.php?sess=29838946ca632d0cee5951a7aefb270e&parent=16&expand=1&order=name&sortname=ASC&binary=1&id=57 angel |
From: Trish W. <wh...@pc...> - 2006-05-16 16:16:20
|
Hi Angel and others - comments in-line. > A topic from the last FuGE conference call between the various groups > with vested interest in the FuGE model was who actually should retain > ownership of the model. This is a slightly touchy subject , so I will > try to outline the situation fully. > > First, a bit of context. > > The MGED Society developed the MAGE version 1 UML model and DTD, which > were subsequently submitted to the standardization process of the OMG > biological standards division. It is worthy to note that the person > responsible for this great amount of documentation and work was Michael > Miller, from Rosetta. It is also worthy to note, that as far as the OMG > relied heavily on the submitters to be self-regulated, meaning that the > submission was largely accepted as is, as long as all the vested parties > that are part of the submission are happy with the result. This > essentially equates to a rubber stamp, but provides commercial vendors > an easy mechanism to justify development costs to support the standard. > A weakness of the OMG process is that proposals are only provided to > members of the OMG while they are in development. I do not know if MGED > will continue to use the OMG as the standardization mechanism for its > specifications. My understanding in talking to others at the Jam was that MAGEv2 would not go through the OMG proposal system, but that the MGED Society would adopt a document approval process similar (if not the same) as to that of PSI. This would be the modified version of the PSI doc approval as I hear that the first proposal from PSI was presented to MGED but seemed very lengthy. I have not seen this first proposal in detail, but have seen the modified doc approval process and this seems like a useful thing for MGED to adopt. > Other groups are paying very close attention to these efforts and will > base their adoption of the FuGE model and development methodology on two > results. First and foremost is the successful implementation of the > technology-specific standards using FuGE. I think the GelML and spML > (sample processing for proteomics separation assays) project illustrate > that you can efficiently create the specific models in UML, but have a > little bit of work left to prove with respect to providing sensible XML > schema and other platform specific implementations. I don't know the > status of MAGE2. Second, they will base their decision on how nice the > various vested groups play with each other. Thus we get to the point of > this email. Does someone at the Jam recall the proposed timeline for MAGEv2? > A question on the table now who will be official body that ultimately > has final say on the FuGE standard. The choices are MGED, PSI or some > other independent entity. Currently, the FuGE project is an independent > open-source entity and that has worked well for all parties involved. I > see no reason to change this administrative structure. I agree that the FuGE standard is best owned by the FuGE project. Is there a need to slightly more formalize the FuGE project in order to do this? Describe the admin structure that is needed for the doc approval process? > I do see a real need, however, to acknowledge the fact that the main > contributors are MGED and PSI. We will also need to do a bit of > marketing and public relations to be inclusive as possible to all > contributors (such as the metabolomics community that continually > provides us with advanced use-cases), as well as promote adoption by > other entities, whether they be other open-source projects, commercial > products, or other technology specific standards processes. > > Another question on the table is what will be the standardizations > process for the official release. Since PSI is implementing a totally > open and formal review process, I put forward that we leverage this for > formalization of FuGE. This is mainly a convenience for Andy and myself, > since we already attend most of the PSI meetings and are going to be > putting our tech-specific standards through that process, hence will be > very familiar with it. I can provide anyone whom is interested with the > documents that outline the PSI process, but suffice to say, it involves > documentation of the standard, a public review and comment period, and > final review and approval by the PSI steering committee, with feedback > loops throughout the work flow. > > Comments? Do you mean that the FuGE project also adopt the doc approval process that PSI uses, but implement within the context of the FuGE project and have MGED and PSI as the external reviewers of the doc OR that FuGE be approved within the context of PSI? Trish PS - if the PSI doc approval process could be posted/emailed that would be useful. |
From: Angel P. <an...@ma...> - 2006-05-16 14:26:19
|
To persons with vested interest in the FuGE project, A topic from the last FuGE conference call between the various groups with vested interest in the FuGE model was who actually should retain ownership of the model. This is a slightly touchy subject , so I will try to outline the situation fully. First, a bit of context. The MGED Society developed the MAGE version 1 UML model and DTD, which were subsequently submitted to the standardization process of the OMG biological standards division. It is worthy to note that the person responsible for this great amount of documentation and work was Michael Miller, from Rosetta. It is also worthy to note, that as far as the OMG relied heavily on the submitters to be self-regulated, meaning that the submission was largely accepted as is, as long as all the vested parties that are part of the submission are happy with the result. This essentially equates to a rubber stamp, but provides commercial vendors an easy mechanism to justify development costs to support the standard. A weakness of the OMG process is that proposals are only provided to members of the OMG while they are in development. I do not know if MGED will continue to use the OMG as the standardization mechanism for its specifications. The PSI followed a similar development path for modeling general proteomics procedure (e.g. base model as UML, which generated XML schema, database DDL, etc.) but did not get submitted to any external standards body, in effect acting as an ad-hoc standardization organization. The other main difference between PSI and MGED standards was the reliance on XML schema as the development platform for the technologically detailed specifications, such as mzData and PSI-MI. The MGED standards intermixed generally applicable and technology specific data structures in the same specification. Again, the PSI-MI and mzData specifications where put through a rigorous community development process, but the process can be considered to be ad-hoc as compared to other standardization processes. Recognizing that this is a weakness of theirs, PSI has adopted and is currently implementing a formal review process for all of it's specifications. The process is completely open, unlike OMG, but must be in some way related to their mission of providing proteomics standards. Lastly, independent attempts where made to merge the two models, since the various technological platforms share quite a bit of data structures in the upstream processes. The FuGE project was initiated after these attempts were published, as a means to abstract out common data structures for use by technology specific standards, emulating "real" software development methodology. The bulk of this work was done by Andy Jones and myself, with significant contributions from PSI/MGED/others along the way at various meetings, and as issues were raised on the development lists. Milestones were released and development began in earnest on the technology specific models based on FuGE, such as the GelML and MAGE2. Other groups are paying very close attention to these efforts and will base their adoption of the FuGE model and development methodology on two results. First and foremost is the successful implementation of the technology-specific standards using FuGE. I think the GelML and spML (sample processing for proteomics separation assays) project illustrate that you can efficiently create the specific models in UML, but have a little bit of work left to prove with respect to providing sensible XML schema and other platform specific implementations. I don't know the status of MAGE2. Second, they will base their decision on how nice the various vested groups play with each other. Thus we get to the point of this email. A question on the table now who will be official body that ultimately has final say on the FuGE standard. The choices are MGED, PSI or some other independent entity. Currently, the FuGE project is an independent open-source entity and that has worked well for all parties involved. I see no reason to change this administrative structure. I do see a real need, however, to acknowledge the fact that the main contributors are MGED and PSI. We will also need to do a bit of marketing and public relations to be inclusive as possible to all contributors (such as the metabolomics community that continually provides us with advanced use-cases), as well as promote adoption by other entities, whether they be other open-source projects, commercial products, or other technology specific standards processes. Another question on the table is what will be the standardizations process for the official release. Since PSI is implementing a totally open and formal review process, I put forward that we leverage this for formalization of FuGE. This is mainly a convenience for Andy and myself, since we already attend most of the PSI meetings and are going to be putting our tech-specific standards through that process, hence will be very familiar with it. I can provide anyone whom is interested with the documents that outline the PSI process, but suffice to say, it involves documentation of the standard, a public review and comment period, and final review and approval by the PSI steering committee, with feedback loops throughout the work flow. Comments? Angel -- Angel Pizarro Director, Bioinformatics Facility Institute for Translational Medicine and Therapeutics University of Pennsylvania 806 BRB II/III 421 Curie Blvd. Philadelphia, PA 19104-6160 P: 215-573-3736 F: 215-573-9004 E: an...@ma... |
From: Alvis B. <br...@eb...> - 2006-05-15 19:12:18
|
On Mon, 15 May 2006, Paul Spellman wrote: > Alvis, > > what are the best dates for you to host a MAGEv2 meeting in Hinxton? > I'm finding this out - I'll send an e-mail round in a couple of days asking about the options to everybody, but is should be one of the first 3 weeks of July > We will presumably get some work done in Seattle. Then we will need one more > in 2006 I think. Perhaps it should be with the FuGE folks somewhere warmish > in December? > Caribbean? - alvis |
From: Paul S. <PTS...@lb...> - 2006-05-15 18:43:12
|
Alvis, what are the best dates for you to host a MAGEv2 meeting in Hinxton? We will presumably get some work done in Seattle. Then we will need one more in 2006 I think. Perhaps it should be with the FuGE folks somewhere warmish in December? Paul |
From: Adam W. <aw...@sg...> - 2006-05-15 13:03:08
|
Hi, Sorry for the cross-posting, but sourceforge has moved the location of its CVS system. In the email they sent they recommend re-checking out any modules. In particular we probably need to delete/move the current web site files and check them out again from the new CVS location. So i was wondering, who is actively editing the sourceforge website, and if so do you have any files there that are not currently located in CVS? thanks adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
From: Mohammad S. <sh...@eb...> - 2006-05-03 10:02:52
|
Hi Joe,All I only need to indicate that 50% of submissions to ArrayExpress is not from any TAB format at all. 50% of submissions to ArrayExpress is from MIAMExpress which as you all know is an online tool which takes submitter through a series of web pages from experimental design to samples ,extracts, labels and hybridizations. Then after submission is completed it produces the (MIAME to MAGE best practice compliant) MAGE-ML file, using Magestk. as of now the number of hybz in Arrayexpress is: 40524 from which 19910 are comming from MIAMExpress online submission tool. I also would like to let you know that we are in the process of releasing the Beta version of the MIAMExpress Batch upload tool which is a Java Application with easy to use User interface that makes submission of large experiment to ArrayExpress even easier, and generally it obeys the MAGE-TAB format. Cheers Mohammad Joe White wrote: > Hi Don and Jason, > > Having written hundreds of MAGE-ML files, I can tell you that it is > not so beastly to read or write MAGE-ML. I did have to make some > compromises, but was able to write it nonetheless. I've also learned > to read these files rather efficiently. When I started working with > MGED I was a complete XML neuby; with help from people like Angel and > Jason I got up to speed in reasonably short order. Frankly, if I can > learn this, others can as well; it only took some effort. > That being said, the ArrayExpress has devised a tab-delimited format > for submissions of data to ArrayExpress--in part because they already > have tab-delimited submission formats that account for 50% of their > submissions. Bench biologists want nothing to do with XML, and the > shouldn't have to have anything to do with it. The reason that they > get stuck dealing with it is that there may not be any bioinformatics > support personnel to do it for them. So I think Jason is right; we > need to be writing more applications that use MAGE-ML. > MGED is not going to shelve the MAGE-TAB format; in fact it is planned > that it should cover 80-90 % of array experiments, i.e. simple cases. > The remaining 10 - 20 % of array experiments (that are more > complicated in nature) will have to be encoded in MAGE-ML for > submission. (I'm not going to quibble about whether array experiment > data are 'simple' or not; it is clear that many experiments can be > described in a simple tabular format--it already exists.) > Whether or not an end user adopts MAGE-TAB, parsers must still be > written that transform these formats into MAGE-ML so that databases > can be loaded. MAGE-TAB is a subset of MAGE-OM precisely for this > reason, i.e. it must be converted to MAGE-ML. > Lastly, MAGEv1 does have flaws; these are being addressed by the > MAGEv2 working group. The plan has been to make the model a little > simpler, to correct problems perceived in the first version, and to > remove some of the flexibility that people have noted as one of its > flaws, i.e. too many ways to encode the same information. The latter > should make interoperability more likely to happen. > So, we already have tabular formats for MAGE-ML: tab2mage from Tim > Rayner, MIAMExpress and ADF from Philippe Rocca-Serra. MAGE-TAB was > devised to adopt a common format for these items. MAGE-OM is being > redesigned and will be available sometime in the next year. I would > suggest that people get ready to use both. > Cheers, > > Joe White > DFCI > > > Don Maier wrote: > >> Hi Jason, >> >> Thank you for your thoughts on this! >> >> Your argument hinges on the unsupported premise that "any of the >> weaknesses of XML mostly apply to tab-delimited as well". I think >> that's not true (as briefly argued below). And the choice of >> format is significant -- because it influences the amount, >> difficulty, and usability of the software that's needed. That may >> justify a reluctance to "stop discussing it and start writing >> software". >> >> I won't here provide a complete analysis of the strengths and >> weaknesses of each of the format choices. But to support the claim >> that one's mileage varies with format: Consider, for example, >> weakness 2) in my previous message -- the size of MAGE-ML documents >> that causes a great many difficulties for the exporting/importing >> programs (your step 3)) that attempt to consume them. A delimited >> flat file -- or each of the flat files in a collection -- would be >> far smaller and more tractable. >> >> Also, I would argue, your step 3) isn't really the only "step" worth >> considering. To the extent that a flat file format (for example) >> can perform other useful and needed functions -- such as easy >> viewing and editing, and easier-to-understand mapping to tables in >> relational databases -- I think that it has significant benefits. >> >> I'm not ready to issue a verdict for or against any of the >> alternatives. But I think that this really is something worth >> discussing. >> >> There is one respect in which I completely agree with you: Insofar >> as MAGE-OM is an over-complex and hard-to-understand model of >> microarray data, it makes all embodiments of it over-complex and >> hard- to-understand. This, rather than the XML format of MAGE-ML >> may be what is responsible for the current problem that a MAGE-ML >> document produced from one relational database often cannot be >> properly imported into another (without some prior modification). >> But it's also possible that difficulties of dealing with XML have >> made MAGE-ML so far unsuccessful as the lingua franca of microarray >> experiments. >> >> Thanks again for your comments! >> >> Regards, >> Don Maier >> >> >> On Apr 28, 2006, at 12:48 AM, Jason Stewart wrote: >> >>> Hi Don, >>> >>> I obviously have too much time on my hands - I'm writing more emails >>> being philosophical about MAGE-ML... I have a lot of confusion after >>> reading your letter. You said a lot of valid and useful things, but I >>> need to be more clear. >>> >>> The cautionary note that angel gave and I seconded was creating a new >>> format - a tab-delimited format - instead of XML. >>> >>> The points that you raise about strengths and weaknesses of XML are >>> fine, but where is the comparison of a tab-delimited format? Any of >>> the weaknesses of XML mostly apply to tab-delimited as well. >>> >>> We have three choices: >>> 1) delimited text (spreadsheet) >>> 2) structured text (XML) >>> 3) binary (NetCDF) >>> >>> No matter which format we pick we have to: >>> 1) get it into a DB for querying >>> 2) modify it >>> 3) export it to other people >>> >>> MAGE-ML (in my mind) was written to fulfill step three and only step >>> three. If other people want a different format that they use so they >>> don't have to use a DB - fine. That way they query and edit without a >>> DB - fine. Then I am all for it. >>> >>> But if what we are discussing is what format is best for step 3) - it >>> is a waste of time. We have MAGE-ML it is as bad as anything else >>> would be, let's stop discussing it and start writing software. >>> >>> Let me make my views clear. I think XML *sucks*. I hate it. The >>> problem is - everything else sucks *worse*. So what to do? My >>> suggestion is that we stop talking about the format - and start >>> writing really good tools to help people do things with their data. >>> Really. >>> >>> Cheers, jas. >> >> >> >> Don Maier >> Sr. Software Designer/Research >> Dept. of Biochemistry >> Stanford University School of Medicine >> >> >> >> >> Begin forwarded message: >> >>> From: Don Maier <dM...@ge...> >>> Date: April 27, 2006 5:23:19 PM PDT >>> To: ju...@pc..., an...@ma... >>> Cc: mge...@li... >>> Subject: Re: Re: Re: MAGE-simple >>> >>> >>> Good day, Junmin, Angel, >>> >>> There are, of course, two separate issues. The first is about >>> whether or not the MAGE-OM object model is a reasonably effective >>> and comprehensive representation of microarray experiments. The >>> second is about whether or not the MAGE-ML representation, or XML >>> representations in general, are good ones for microarray experiment >>> data -- independent on the data's object model or schema. >>> >>> To take the second issue first: I would think that the "to XML or >>> not to XML" debate has been ongoing in the MAGE community, well >>> before my recent arrival. But perhaps it's worth sharing a >>> newcomer's thoughts: >>> >>> XML's strengths are well known. They include: >>> >>> 1) High level of expressive power for many, though not all data >>> structures -- particularly trees (hierarchies), lists, and records. >>> 2) Self-documenting -- for both structure as well as data values. >>> 3) A strictly defined Standard syntax that facilities the >>> building of parsers. >>> 4) A Standard for XML schemas that enforce strict, type-aware >>> descriptions, including (as Angel mentions), constraints. Though, >>> it should be mentioned that some spreadsheet programs are also >>> (simple) type-aware. >>> 5) Occupies standard text files, which eliminates file format >>> problems. >>> 6) Has the world's most powerful (and complex) query engine -- >>> XQuery. XQuery is Turing-complete and makes SQL (which is not >>> Turing-complete) look like child's play. This is something that >>> I've not seen mentioned in this group. I'll come back to it. >>> 7) The previous point is a special, important case of the >>> existence of myriad XML tools (again, mentioned by Angel) have have >>> evolved since XML's emergence from SGML in the mid-1980's. >>> >>> But it has a bunch of weaknesses, too -- especially in the context >>> the MGED community's needs: >>> >>> 1) Cannot easily express graphs other than trees. Directed graphs >>> are an even tougher fit -- though, there are proposals (such as >>> GXL) on how to do this. I mention this in light of the MAGE-TAB >>> proposal, which talks a lot about representing DAGs. >>> 2) Huge document size. Its self-documenting feature, which is >>> verbose and redundant, has a high cost in the size of the >>> documentation which can dwarf the data. Even simple XML documents >>> are typically around three times larger than equivalent non-self >>> describing representations. >>> 3) Not friendly for human viewing and editing. As Angel >>> mentions, there are XML editors that can the data a more >>> presentable face. But there are serious limits when the data are >>> attribute values in widely dispersed elements. Even when not, >>> people seem to feel more comfortable with more general-purpose and >>> familiar tools, such as Excel. XQuery could help. But we probably >>> don't want to require biologists to be XQuery experts. And some >>> editing/viewing tools fail with the not uncommonly large MAGE-ML >>> documents. >>> 4) No good way to directly query data stored as XML -- if you rule >>> out the use of XQuery (which can operate on multiple XML documents >>> with a single query). >>> 5) There are limited options for persistent storage of XML. There >>> are XML databases -- even one or two open-source free ones. >>> However, the technology is still relatively untested for robust >>> use. And I've not seen any sentiment in the MGED community for >>> using XML databases. >>> 6) If you can't easily view or edit it, you can't easily query it, >>> and you can't easily persist it (by just smashing it into an XML >>> database) -- in short, if you can't do much with it as it is -- >>> then for any important use, you have to transform it into something >>> else. Unfortunately, XML transformations are inefficient and time- >>> consuming -- especially for the large MAGE-ML documents. >>> >>> On the first issue, concerning the object model, let me risk >>> retreading ground perhaps already too well trodden with a few >>> observations: The MAGE community seems committed to persisting >>> MAGE objects in relational databases. This is relatively easy to >>> do by following one of several available recipes for object >>> relational storage. For example, in the world of Java, SDO might >>> be used in conjunction with JDO, where JDO is one data source that >>> SDO can access, applying the Data Transfer Object (DTO) design >>> pattern. Or one can turn to something like Hibernate (which seems >>> to be popular in the MAGE community) and POJO (Plain Old Java >>> Object) persistence as defined by EJB 3.0, which avoids DTOs. >>> >>> There are, I think, these cautionary considerations for any of >>> these approaches: >>> >>> 1) In either approach, the underlying SQL schema cannot take >>> advantage of the power of SQL engines in efficiently performing >>> large, multi-table query transactions. Access to multiple objects >>> will come from iterators and other kinds of object navigation that >>> result in huge numbers of small database accesses. Also, I fear >>> that because of object isolation, important computational context >>> will not in the SQL. So many computations will have to be done >>> very inefficiently in the program rather than very efficiently in SQL. >>> 2) The programming model, which requires traversing the object >>> graph, is tedious and error-prone -- even with a tool like >>> Hibernate at one's disposal. >>> >>> Please forgive me if I am, in fact, beating down well-worn paths. >>> In my defense, I've not yet seen a lot of these points made >>> anywhere else -- in writing and in one discussion. If there is >>> such a discussion, please direct my attention to it! >>> >>> Regards, >>> Don Maier >>> Sr. Software Designer/Research >>> Dept. of Biochemistry >>> Stanford University School of Medicine >>> >>>> Date: Wed, 26 Apr 2006 14:14:04 -0400 (EDT) >>>> From: Junmin Liu <ju...@pc...> >>>> To: Angel Pizarro <an...@ma...> >>>> cc: mged-mage2 <mge...@li...> >>>> Subject: Re: [Mged-mage2] Re: MAGE-simple >>>> >>>> Hi, Angel >>>> From what I understand about the MAGE-simple, it is not about the >>>> model >>>> itself, but the XML presentation. The MAGE-simple or MAGE-tab is an >>>> alternative to MAGE-XML, for there are certain amount of >>>> microarray data >>>> which have some sorts of patterns in the biomaterial description, >>>> and are >>>> easily represented in tab file or in tables. And people just want >>>> to go >>>> directly to simple text format. >>>> >>>> ---junmin >>>> >>>> >>>> On Tue, 25 Apr 2006, Angel Pizarro wrote: >>>> >>>>> Catherine Ball wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> Attached is an Excel-based form that will help get appropriate >>>>>> investigation-wide answers about someone's study (look Ma, no >>>>>> XML!). It's >>>>>> not terribly complicated, but it'll get the job done. The idea >>>>>> would be >>>>>> that the form could be sent/downloaded by an experimenter, the >>>>>> sections >>>>>> filled out and then the file saved as tab-delimited text for >>>>>> parsing. >>>>> >>>>> >>>>> Dear MAGE community: >>>>> >>>>> OK, I realize that I left this group a while ago and I may have >>>>> no weight at >>>>> this point, but that never stopped me from stating my opinion ;) >>>>> >>>>> I see these tab-delimited proposals as a reactionary movement to >>>>> MAGE v1's >>>>> overly complex schema. I get it, the model was too complex for >>>>> 80% of the use >>>>> cases and 99% of the practical usage scenarios. >>>>> >>>>> If this is the case, then push for a simpler model, not an >>>>> alternative. At >>>>> the very least stay with XML as the format. It is easily >>>>> validated and there >>>>> exists a rich set of standard API's, tools and editors (including >>>>> Excel). A >>>>> simple xsl style sheet can provide the user's tabular view (and >>>>> more). They >>>>> can produce templates for editors, such as Excel, to use. XML can >>>>> encode >>>>> types and constraints for values, unlike tab-delimited formats. >>>>> With so many >>>>> advantages, I can't see a good reason to switch to using tab or >>>>> csv files. >>>>> >>>>> Thanks very much for your time. >>>>> -angel >>>> >>>> >>> >>> >> > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Mged-MAGE2 mailing list > Mge...@li... > https://lists.sourceforge.net/lists/listinfo/mged-mage2 |
From: Joe W. <jw...@ji...> - 2006-05-02 20:33:14
|
Hi Don and Jason, Having written hundreds of MAGE-ML files, I can tell you that it is not so beastly to read or write MAGE-ML. I did have to make some compromises, but was able to write it nonetheless. I've also learned to read these files rather efficiently. When I started working with MGED I was a complete XML neuby; with help from people like Angel and Jason I got up to speed in reasonably short order. Frankly, if I can learn this, others can as well; it only took some effort. That being said, the ArrayExpress has devised a tab-delimited format for submissions of data to ArrayExpress--in part because they already have tab-delimited submission formats that account for 50% of their submissions. Bench biologists want nothing to do with XML, and the shouldn't have to have anything to do with it. The reason that they get stuck dealing with it is that there may not be any bioinformatics support personnel to do it for them. So I think Jason is right; we need to be writing more applications that use MAGE-ML. MGED is not going to shelve the MAGE-TAB format; in fact it is planned that it should cover 80-90 % of array experiments, i.e. simple cases. The remaining 10 - 20 % of array experiments (that are more complicated in nature) will have to be encoded in MAGE-ML for submission. (I'm not going to quibble about whether array experiment data are 'simple' or not; it is clear that many experiments can be described in a simple tabular format--it already exists.) Whether or not an end user adopts MAGE-TAB, parsers must still be written that transform these formats into MAGE-ML so that databases can be loaded. MAGE-TAB is a subset of MAGE-OM precisely for this reason, i.e. it must be converted to MAGE-ML. Lastly, MAGEv1 does have flaws; these are being addressed by the MAGEv2 working group. The plan has been to make the model a little simpler, to correct problems perceived in the first version, and to remove some of the flexibility that people have noted as one of its flaws, i.e. too many ways to encode the same information. The latter should make interoperability more likely to happen. So, we already have tabular formats for MAGE-ML: tab2mage from Tim Rayner, MIAMExpress and ADF from Philippe Rocca-Serra. MAGE-TAB was devised to adopt a common format for these items. MAGE-OM is being redesigned and will be available sometime in the next year. I would suggest that people get ready to use both. Cheers, Joe White DFCI Don Maier wrote: > Hi Jason, > > Thank you for your thoughts on this! > > Your argument hinges on the unsupported premise that "any of the > weaknesses of XML mostly apply to tab-delimited as well". I think > that's not true (as briefly argued below). And the choice of format > is significant -- because it influences the amount, difficulty, and > usability of the software that's needed. That may justify a > reluctance to "stop discussing it and start writing software". > > I won't here provide a complete analysis of the strengths and > weaknesses of each of the format choices. But to support the claim > that one's mileage varies with format: Consider, for example, > weakness 2) in my previous message -- the size of MAGE-ML documents > that causes a great many difficulties for the exporting/importing > programs (your step 3)) that attempt to consume them. A delimited > flat file -- or each of the flat files in a collection -- would be > far smaller and more tractable. > > Also, I would argue, your step 3) isn't really the only "step" worth > considering. To the extent that a flat file format (for example) can > perform other useful and needed functions -- such as easy viewing and > editing, and easier-to-understand mapping to tables in relational > databases -- I think that it has significant benefits. > > I'm not ready to issue a verdict for or against any of the > alternatives. But I think that this really is something worth > discussing. > > There is one respect in which I completely agree with you: Insofar > as MAGE-OM is an over-complex and hard-to-understand model of > microarray data, it makes all embodiments of it over-complex and hard- > to-understand. This, rather than the XML format of MAGE-ML may be > what is responsible for the current problem that a MAGE-ML document > produced from one relational database often cannot be properly > imported into another (without some prior modification). But it's > also possible that difficulties of dealing with XML have made MAGE-ML > so far unsuccessful as the lingua franca of microarray experiments. > > Thanks again for your comments! > > Regards, > Don Maier > > > On Apr 28, 2006, at 12:48 AM, Jason Stewart wrote: > >> Hi Don, >> >> I obviously have too much time on my hands - I'm writing more emails >> being philosophical about MAGE-ML... I have a lot of confusion after >> reading your letter. You said a lot of valid and useful things, but I >> need to be more clear. >> >> The cautionary note that angel gave and I seconded was creating a new >> format - a tab-delimited format - instead of XML. >> >> The points that you raise about strengths and weaknesses of XML are >> fine, but where is the comparison of a tab-delimited format? Any of >> the weaknesses of XML mostly apply to tab-delimited as well. >> >> We have three choices: >> 1) delimited text (spreadsheet) >> 2) structured text (XML) >> 3) binary (NetCDF) >> >> No matter which format we pick we have to: >> 1) get it into a DB for querying >> 2) modify it >> 3) export it to other people >> >> MAGE-ML (in my mind) was written to fulfill step three and only step >> three. If other people want a different format that they use so they >> don't have to use a DB - fine. That way they query and edit without a >> DB - fine. Then I am all for it. >> >> But if what we are discussing is what format is best for step 3) - it >> is a waste of time. We have MAGE-ML it is as bad as anything else >> would be, let's stop discussing it and start writing software. >> >> Let me make my views clear. I think XML *sucks*. I hate it. The >> problem is - everything else sucks *worse*. So what to do? My >> suggestion is that we stop talking about the format - and start >> writing really good tools to help people do things with their data. >> Really. >> >> Cheers, jas. > > > Don Maier > Sr. Software Designer/Research > Dept. of Biochemistry > Stanford University School of Medicine > > > > > Begin forwarded message: > >> From: Don Maier <dM...@ge...> >> Date: April 27, 2006 5:23:19 PM PDT >> To: ju...@pc..., an...@ma... >> Cc: mge...@li... >> Subject: Re: Re: Re: MAGE-simple >> >> >> Good day, Junmin, Angel, >> >> There are, of course, two separate issues. The first is about >> whether or not the MAGE-OM object model is a reasonably effective >> and comprehensive representation of microarray experiments. The >> second is about whether or not the MAGE-ML representation, or XML >> representations in general, are good ones for microarray experiment >> data -- independent on the data's object model or schema. >> >> To take the second issue first: I would think that the "to XML or >> not to XML" debate has been ongoing in the MAGE community, well >> before my recent arrival. But perhaps it's worth sharing a >> newcomer's thoughts: >> >> XML's strengths are well known. They include: >> >> 1) High level of expressive power for many, though not all data >> structures -- particularly trees (hierarchies), lists, and records. >> 2) Self-documenting -- for both structure as well as data values. >> 3) A strictly defined Standard syntax that facilities the building >> of parsers. >> 4) A Standard for XML schemas that enforce strict, type-aware >> descriptions, including (as Angel mentions), constraints. Though, >> it should be mentioned that some spreadsheet programs are also >> (simple) type-aware. >> 5) Occupies standard text files, which eliminates file format >> problems. >> 6) Has the world's most powerful (and complex) query engine -- >> XQuery. XQuery is Turing-complete and makes SQL (which is not >> Turing-complete) look like child's play. This is something that >> I've not seen mentioned in this group. I'll come back to it. >> 7) The previous point is a special, important case of the existence >> of myriad XML tools (again, mentioned by Angel) have have evolved >> since XML's emergence from SGML in the mid-1980's. >> >> But it has a bunch of weaknesses, too -- especially in the context >> the MGED community's needs: >> >> 1) Cannot easily express graphs other than trees. Directed graphs >> are an even tougher fit -- though, there are proposals (such as >> GXL) on how to do this. I mention this in light of the MAGE-TAB >> proposal, which talks a lot about representing DAGs. >> 2) Huge document size. Its self-documenting feature, which is >> verbose and redundant, has a high cost in the size of the >> documentation which can dwarf the data. Even simple XML documents >> are typically around three times larger than equivalent non-self >> describing representations. >> 3) Not friendly for human viewing and editing. As Angel mentions, >> there are XML editors that can the data a more presentable face. >> But there are serious limits when the data are attribute values in >> widely dispersed elements. Even when not, people seem to feel more >> comfortable with more general-purpose and familiar tools, such as >> Excel. XQuery could help. But we probably don't want to require >> biologists to be XQuery experts. And some editing/viewing tools >> fail with the not uncommonly large MAGE-ML documents. >> 4) No good way to directly query data stored as XML -- if you rule >> out the use of XQuery (which can operate on multiple XML documents >> with a single query). >> 5) There are limited options for persistent storage of XML. There >> are XML databases -- even one or two open-source free ones. >> However, the technology is still relatively untested for robust >> use. And I've not seen any sentiment in the MGED community for >> using XML databases. >> 6) If you can't easily view or edit it, you can't easily query it, >> and you can't easily persist it (by just smashing it into an XML >> database) -- in short, if you can't do much with it as it is -- then >> for any important use, you have to transform it into something >> else. Unfortunately, XML transformations are inefficient and time- >> consuming -- especially for the large MAGE-ML documents. >> >> On the first issue, concerning the object model, let me risk >> retreading ground perhaps already too well trodden with a few >> observations: The MAGE community seems committed to persisting MAGE >> objects in relational databases. This is relatively easy to do by >> following one of several available recipes for object relational >> storage. For example, in the world of Java, SDO might be used in >> conjunction with JDO, where JDO is one data source that SDO can >> access, applying the Data Transfer Object (DTO) design pattern. Or >> one can turn to something like Hibernate (which seems to be popular >> in the MAGE community) and POJO (Plain Old Java Object) persistence >> as defined by EJB 3.0, which avoids DTOs. >> >> There are, I think, these cautionary considerations for any of these >> approaches: >> >> 1) In either approach, the underlying SQL schema cannot take >> advantage of the power of SQL engines in efficiently performing >> large, multi-table query transactions. Access to multiple objects >> will come from iterators and other kinds of object navigation that >> result in huge numbers of small database accesses. Also, I fear >> that because of object isolation, important computational context >> will not in the SQL. So many computations will have to be done very >> inefficiently in the program rather than very efficiently in SQL. >> 2) The programming model, which requires traversing the object >> graph, is tedious and error-prone -- even with a tool like Hibernate >> at one's disposal. >> >> Please forgive me if I am, in fact, beating down well-worn paths. >> In my defense, I've not yet seen a lot of these points made anywhere >> else -- in writing and in one discussion. If there is such a >> discussion, please direct my attention to it! >> >> Regards, >> Don Maier >> Sr. Software Designer/Research >> Dept. of Biochemistry >> Stanford University School of Medicine >> >>> Date: Wed, 26 Apr 2006 14:14:04 -0400 (EDT) >>> From: Junmin Liu <ju...@pc...> >>> To: Angel Pizarro <an...@ma...> >>> cc: mged-mage2 <mge...@li...> >>> Subject: Re: [Mged-mage2] Re: MAGE-simple >>> >>> Hi, Angel >>> From what I understand about the MAGE-simple, it is not about the >>> model >>> itself, but the XML presentation. The MAGE-simple or MAGE-tab is an >>> alternative to MAGE-XML, for there are certain amount of microarray >>> data >>> which have some sorts of patterns in the biomaterial description, >>> and are >>> easily represented in tab file or in tables. And people just want >>> to go >>> directly to simple text format. >>> >>> ---junmin >>> >>> >>> On Tue, 25 Apr 2006, Angel Pizarro wrote: >>> >>>> Catherine Ball wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> Attached is an Excel-based form that will help get appropriate >>>>> investigation-wide answers about someone's study (look Ma, no >>>>> XML!). It's >>>>> not terribly complicated, but it'll get the job done. The idea >>>>> would be >>>>> that the form could be sent/downloaded by an experimenter, the >>>>> sections >>>>> filled out and then the file saved as tab-delimited text for >>>>> parsing. >>>> >>>> Dear MAGE community: >>>> >>>> OK, I realize that I left this group a while ago and I may have no >>>> weight at >>>> this point, but that never stopped me from stating my opinion ;) >>>> >>>> I see these tab-delimited proposals as a reactionary movement to >>>> MAGE v1's >>>> overly complex schema. I get it, the model was too complex for 80% >>>> of the use >>>> cases and 99% of the practical usage scenarios. >>>> >>>> If this is the case, then push for a simpler model, not an >>>> alternative. At >>>> the very least stay with XML as the format. It is easily validated >>>> and there >>>> exists a rich set of standard API's, tools and editors (including >>>> Excel). A >>>> simple xsl style sheet can provide the user's tabular view (and >>>> more). They >>>> can produce templates for editors, such as Excel, to use. XML can >>>> encode >>>> types and constraints for values, unlike tab-delimited formats. >>>> With so many >>>> advantages, I can't see a good reason to switch to using tab or >>>> csv files. >>>> >>>> Thanks very much for your time. >>>> -angel >>> >> >> > |
From: Alvis B. <br...@eb...> - 2006-03-24 14:49:01
|
Dear Mervi, Thanks very much for organizing this. As Michael suggested, we would like to spend a couple of days in discussing and hopefully finalizing MAGE-simple (or as we call in now MAGE-TAB). We just send out a new draft, which is in the attachment. I suggest that we have a break-out meeting for this on May 9-10. I also suggest that we make a pool rather sooner than later who would like to participate in that, as this may affect the timing of other break-out groups. Also, if you'd like to present this proposal on May 8 to the general audience, I'd be happy to do this. Looking forward to seeing you in May, - Alvis On Thu, 23 Mar 2006, Heiskanen, Mervi (NIH/NCI) [E] wrote: > The Microarray Gene Expression Data (MGED) Society Programming > Jamboree will be hosted by the NCI Center for Bioinformatics in > Rockville, MD, May 8-12. Please visit > <http://caarray.nci.nih.gov/caARRAY/mgedJamboree> > http://caarray.nci.nih.gov/caARRAY/mgedJamboree<?xml:namespace prefix > = o ns = "urn:schemas-microsoft-com:office:office" /> > > for meeting agenda and registration. > > We will set up an online meeting (Centra) for May 8th to make the > talks and tutorials available for those who cannot attend in person. > If you are interested in participating via Centra please register, and > we will e-mail you the instructions. One of the goals for this > jamboree is to increase interaction with the MGED society and the > Cancer Biomedical Informatics Grid (caBIG) program, thus we have > included presentations from both of these communities in the agenda. > We look forward to your visit to Maryland! > > - Mervi Heiskanen > > > > Mervi Heiskanen, Ph.D. > National Cancer Institute > Center for Bioinformatics > 6116 Executive Blvd. Suite 403 > Rockville, MD 20852 > phone: 301-451 6369 > fax: 301-480 4222 > > > |
From: Miller, M. D (Rosetta) <Michael_Miller@Rosettabio.com> - 2006-03-23 19:59:17
|
Hi Mervi, =20 Thank you for the update. =20 One question, I'm assuming the jamboree will be more than just work on the ontologies? I believe there is interest in working on MAGE-simple and on MAGEV2. =20 cheers, Michael =20 Michael Miller=20 Lead Software Developer=20 Rosetta Biosoftware Business Unit=20 www.rosettabio.com=20 -----Original Message----- From: mge...@li... [mailto:mge...@li...] On Behalf Of Heiskanen, Mervi (NIH/NCI) [E] Sent: Thursday, March 23, 2006 11:42 AM To: mge...@eb...; mge...@li...; mge...@li... Subject: [Mged-ontologies] MGED Programming Jamboree May 8-12 =09 =09 The Microarray Gene Expression Data (MGED) Society Programming Jamboree will be hosted by the NCI Center for Bioinformatics in Rockville, MD, May 8-12. Please visit http://caarray.nci.nih.gov/caARRAY/mgedJamboree <http://caarray.nci.nih.gov/caARRAY/mgedJamboree>=20 for meeting agenda and registration. We will set up an online meeting (Centra) for May 8th to make the talks and tutorials available for those who cannot attend in person. If you are interested in participating via Centra please register, and we will e-mail you the instructions. One of the goals for this jamboree is to increase interaction with the MGED society and the Cancer Biomedical Informatics Grid (caBIG) program, thus we have included presentations from both of these communities in the agenda. We look forward to your visit to Maryland! - Mervi Heiskanen =20 Mervi Heiskanen, Ph.D.=20 National Cancer Institute=20 Center for Bioinformatics=20 6116 Executive Blvd. Suite 403=20 Rockville, MD 20852=20 phone: 301-451 6369=20 fax: 301-480 4222=20 =20 |
From: Heiskanen, M. \(NIH/NCI\) [E] <hei...@ma...> - 2006-03-23 19:42:05
|
The Microarray Gene Expression Data (MGED) Society Programming Jamboree = will be hosted by the NCI Center for Bioinformatics in Rockville, MD, = May 8-12. Please visit = <http://caarray.nci.nih.gov/caARRAY/mgedJamboree> = http://caarray.nci.nih.gov/caARRAY/mgedJamboree<?xml:namespace prefix = =3D o ns =3D "urn:schemas-microsoft-com:office:office" /> for meeting agenda and registration. We will set up an online meeting (Centra) for May 8th to make the talks = and tutorials available for those who cannot attend in person. If you = are interested in participating via Centra please register, and we will = e-mail you the instructions. One of the goals for this jamboree is to = increase interaction with the MGED society and the Cancer Biomedical = Informatics Grid (caBIG) program, thus we have included presentations = from both of these communities in the agenda. We look forward to your = visit to Maryland! - Mervi Heiskanen =20 Mervi Heiskanen, Ph.D.=20 National Cancer Institute=20 Center for Bioinformatics=20 6116 Executive Blvd. Suite 403=20 Rockville, MD 20852=20 phone: 301-451 6369=20 fax: 301-480 4222=20 =20 |