Re: magetab2magerdf

Hi Kei,
 > isa-tab (how does this differ from mage-tab?)
ISA-Tab is a superset of MAGE-Tab and serves to report multi-omics (and 
in general, multi-assays) studies. Please, see: http://isatab.sf.net and 
details in the ISA-Tab specification.
Regards,
Susanna

-- 
Susanna-Assunta Sansone, PhD

Project Coordinator

http://isatab.sf.net
http://biosharing.org
http://www.ebi.ac.uk/net-project     



Kei Cheung wrote:
> 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 Monday, 14 December 2009 10:17:31 UTC