W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > January 2010

Re: magetab2magerdf

From: Kei Cheung <kei.cheung@yale.edu>
Date: Sat, 02 Jan 2010 22:50:34 -0500
Message-ID: <4B40140A.5000909@yale.edu>
To: mdmiller <mdmiller53@comcast.net>
CC: Jim McCusker <james.mccusker@yale.edu>, w3c semweb HCLS <public-semweb-lifesci@w3.org>
Hi Michael et al,

The question is what is the appropriate structure of the DAG for 
answering the semantic queries for our microarray use case.

 mdmiller wrote:

> hi kei,
>
> mage-tab and its extension isa-tab is designed from the principal of a 
> DAG, in essence it is a flattening of the dag into a spreadsheet which 
> is describe in the MAGE-TAB 1.0 spec [1] in great detail.  i believe 
> the MAGE-TAB parser stores the nodes as a DAG [2].  EBI has also 
> developed a suite of tools around the MAGE standard [3] including a 
> DAG visualization. ArrayExpress for each experiment also has a 
> visualized view of the experiment as a DAG that can be downloaded.  in 
> MAGE-ML the '_ref' elements are used to describe the DAG in a MAGE 
> document.
>
> is the one mentioned below editable?  that's the one thing about the 
> EBI visualization, it is not editable.


I don't think the one mentioned in the paper below is editable.

Cheers,

-Kei

>
> by the by, MAGE-TAB is also being used to report next-gen sequencing 
> experiments in ArrayExpress.
>
> cheers,
> michael
>
> [1] www.mged.org
> [2] https://sourceforge.net/projects/limpopo/
> [3] http://bioinformatics.oxfordjournals.org/cgi/content/full/25/2/279
>
> ----- Original Message ----- From: "Kei Cheung" <kei.cheung@yale.edu>
> To: "mdmiller" <mdmiller53@comcast.net>
> Cc: "Jim McCusker" <james.mccusker@yale.edu>; "w3c semweb HCLS" 
> <public-semweb-lifesci@w3.org>
> Sent: Sunday, December 13, 2009 6:34 PM
> Subject: Re: magetab2magerdf
>
>
>> Hi Jim, Michael,
>>
>> The following paper describes how to convert mage-tab and isa-tab 
>> (how does this differ from mage-tab?) into DAG for visualization 
>> purposes.
>>
>> http://www.biomedcentral.com/1471-2105/10/133
>>
>> Why not DAG for machine readability as well?
>>
>> Cheers,
>>
>> -Kei
>>
>> mdmiller wrote:
>>
>>> hi jim,
>>>
>>> looks like you're making great progress.  i have a few comments 
>>> in-line below.
>>>
>>> cheers,
>>> michael
>>>
>>> ----- Original Message ----- From: "Jim McCusker" 
>>> <james.mccusker@yale.edu>
>>> To: "w3c semweb HCLS" <public-semweb-lifesci@w3.org>
>>> Sent: Tuesday, December 08, 2009 6:05 AM
>>> Subject: magetab2magerdf
>>>
>>>
>>>> I'm distinguishing between magetab2rdf (raw conversion of magetab into
>>>> an RDF structure) and magetab2magerdf (conversion of magetab into an
>>>> RDF-based MAGE-OM structure) here. My purposes and goals require a
>>>> magetab2magerdf approach, so that's what I've been working on.
>>>>
>>>> I have checked in code for magetab2magerdf at the googlecode project
>>>> http://magetab2rdf.googlecode.com. The code can be checked out from:
>>>>
>>>> http://magetab2rdf.googlecode.com/svn/trunk/magetab2magerdf/
>>>>
>>>> and example RDF is in:
>>>>
>>>> http://magetab2rdf.googlecode.com/svn/trunk/magetab2magerdf/examples/E-MEXP-986/ 
>>>>
>>>>
>>>> I currently load the IDF-related entities into the RDF. I'm beginning
>>>> work on SDRF next.
>>>>
>>>> http://magetab2rdf.googlecode.com/svn/trunk/ontologies/mage-om.owl
>>>> contains the additional properties and classes needed to support an
>>>> RDF-based MAGE-OM on top of the MGED Ontology.
>>>>
>>>> A few notes on E-MEXP-986:
>>>>
>>>> The URI for the MGED Ontology is
>>>> http://mged.sourceforge.net/ontologies/MGEDontology.owl, but has been
>>>> set to http://mged.sourceforge.net/ontologies/MGEDontology.php in the
>>>> IDF. The actual Term Source name is "The MGED Ontology".
>>>> A common practice seems to be to refer to "MGED Ontology" without
>>>> reference to its URI.
>>>
>>>
>>>
>>> as you probably noticed, 
>>> http://mged.sourceforge.net/ontologies/MGEDontology.php allows 
>>> appending "#{class name}" to go directly to the definition of the 
>>> term, so in a sense it is indeed a valid URI, that is a URL.  it 
>>> also came before the owl format.  can th epowl format be reached 
>>> into over he net to extract simply the class definition or does it 
>>> need to be downloaded and processed locally? my understanding is 
>>> that a site would have to have some sort of query, hopefully sparql, 
>>> mechanism on top to enable this.
>>>
>>>>
>>>> Since I have to import the MGED ontology already for it's classes and
>>>> properties, I have already imported it under the correct URI. I have
>>>> added a kludge where if the term source name contains the string "MGED
>>>> Ontology", the code assumes you mean the MGED Ontology, and sets the
>>>> URI appropriately. However, this is a one-off solution.
>>>
>>>
>>>
>>> think of it as same as
>>>
>>>>
>>>> I went back and forth about importing the Term Source ontologies.
>>>> However, this particular experiment has used the "ArrayExpress" term
>>>> source using the URI "http://www.ebi.ac.uk/arrayexpress/" which
>>>> doesn't correspond to an available ontology, but is technically a term
>>>> source.
>>>
>>>
>>>
>>> yes, and it does support a query mechinism, albeit a one off for 
>>> that site. i believe they plan on adding support for a sparql 
>>> endpoint but aren't sure if or when.
>>>
>>>>
>>>> I'm considering attempting to import the ontology if it's available
>>>> and validate if it is, but if it fails to resolve to a document the
>>>> validation will not happen against that term source.
>>>>
>>>> A note on Limpopo:
>>>>
>>>> The IDF Comment didn't seem to import on this experiment. I'm not sure
>>>> if it's a format problem or something else.
>>>
>>>
>>>
>>> i ran into this also, the implementation assumes 
>>> "Comment[type]\ttext\ttext..." to coresspond to the format of the 
>>> other fields in the IDF.  the MAGE-TAB 1.0 spec doesn't address, my 
>>> assumption was that it was simply "Comment[type]text" but that's not 
>>> what the parser expects.  we'll be discussing this for the MAGE-TAB 
>>> 1.1 spec to clarify it one way or another, possibly updating the 
>>> parser before that.
>>>
>>>>
>>>> Thoughts and feedback are greatly appreciated.
>>>>
>>>> Jim
>>>> -- 
>>>> Jim McCusker
>>>> Programmer Analyst
>>>> Krauthammer Lab, Pathology Informatics
>>>> Yale School of Medicine
>>>> james.mccusker@yale.edu | (203) 785-6330
>>>> http://krauthammerlab.med.yale.edu
>>>>
>>>> PhD Student
>>>> Tetherless World Constellation
>>>> Rensselaer Polytechnic Institute
>>>> mccusj@cs.rpi.edu
>>>> http://tw.rpi.edu
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
Received on Sunday, 3 January 2010 03:51:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:42 UTC