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 Monday, 14 December 2009 02:34:52 UTC