Re: magetab2magerdf

For what it's worth, I'm generating a DAG using ProtocolApplications as
edges.

Related to that, I have a limpopo question:

In a case where there are 2 channel microarrays, different protocols are
used to create labeled extracts. If there is a technical dye swap replicate
(where the same extract is split and labeled differently), how does the list
of ProtocolNodes (where one is a Cy5 labeling and the other is a Cy3
labeling) relate each LabeledExtract to the source Extract? From what I can
tell, this information is currently lost, as the Extract (say ext1) would
have 2 protocol nodes (Cy5 and Cy3), and then two child nodes (labext1 and
labext2). I need to be able to relate which is which.

Thanks,
Jim

On Sat, Jan 2, 2010 at 10:50 PM, Kei Cheung <kei.cheung@yale.edu> wrote:

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


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