[MOBY-dev] non-compliant services

[Arnaud Kerhornou]

Hi Eddie,

See files attached,

Thanks for looking at it,
Arnaud

Edward Kawas wrote:

>Hi,
>
>Can you send me the workflow and example inputs? 
>
>BTW, the xml looks fine to me.
>
>Eddie
>
>  
>
>>-----Original Message-----
>>From: moby-dev-bounces at biomoby.org 
>>[mailto:moby-dev-bounces at biomoby.org] On Behalf Of Arnaud Kerhornou
>>Sent: Tuesday, February 14, 2006 9:28 AM
>>To: Core developer announcements
>>Subject: Re: [MOBY-dev] non-compliant services
>>
>>Hi everyone,
>>
>>On this note, I have a service that generates GFF objects, e.g.
>><moby:GFF namespace="" id="ENSBTAG00000014911">
>>    <String namespace="" id="" articleName="content">
>>    <![CDATA[
>>    ENSBTAG00000014911    MatScan    I$HSF_01    490    494   
>>  4.99    
>>-    .    # AGAAG
>>    ENSBTAG00000014911    MatScan    I$HSF_01    487    491   
>>  5.48    
>>-    .    # AGAAA
>>    ]]>
>>    </String>
>></moby:GFF>
>>
>>Is this object correct. If so would taverna (v1.3.1) be 
>>affected by the new object specifications ?
>>
>>I have a workflow that connects the output port of a service 
>>returning a collection of GFF objects, and feeds a 
>>parse_moby_data local processor with this list of simples and 
>>when i have GFF objects as above, i get a list of empty objects.
>>
>>Thanks
>>Arnaud
>>
>>Martin Senger wrote:
>>
>>    
>>
>>>I wonder (I forgot it) what was the decision, after the big change 
>>>regarding not inheriting from primitive types,  what to do and when 
>>>with services that do not comply with the new specification. I think 
>>>that the discussion was about what to do with old data 
>>>      
>>>
>>types, there was 
>>    
>>
>>>even a script to rectify them semi-automatically, but I do 
>>>      
>>>
>>not recall 
>>    
>>
>>>what we said about the services.
>>>  An example is a service getFASTAFromUniprot - a nice, 
>>>      
>>>
>>fast, possibly 
>>    
>>
>>>reliable and important service, but it returns something like this:
>>>
>>><?xml version='1.0' encoding='UTF-8'?><moby:MOBY 
>>>xmlns:moby='http://www.biomoby.org/moby'
>>>xmlns='http://www.biomoby.org/moby'><moby:mobyContent
>>>moby:authority='mmb.pcb.ub.es'>
>>>       <moby:mobyData moby:queryID='sip_1_'>
>>>           <moby:Simple moby:articleName=''><FASTA namespace=''
>>>id='Q7T7Q6'><![CDATA[&gt;Q7T7Q6_9REOV (Q7T7Q6) Sigma C (Fragment) 
>>>AGLNPSQRREVVSLILSLTSNVTISHGDLTPIYERLTNLEASTELLHRSISDISTTVSNI
>>>SASLQDMTHTLDDVTANLDGLRTTVTALQDSVSILSTNVTDLTNTSSAHAATLSSLQTTV
>>>DGNSTAISNLKSDVSSNGLAITDLQDRVKSLESTASHGLSFSPPLSVADGVVSLDMDPYF
>>>CSQRVSLTSYPAEAQLMQFRWMARGTNGSSDTIDMTVNAHCHGRRTDYMMSSTGNLTVTS
>>>NVVLLTFDLSDITHIPSDLARLVPSAGFQAASFPVDVSFTRDSATHAYQAYGVYSSSRVF
>>>TITFPTGGDGTA
>>>]]></FASTA></moby:Simple>
>>>       </moby:mobyData>
>>>       </moby:mobyContent></moby:MOBY>
>>>
>>>which is, according my limited knowledge wrong (the FASTA 
>>>      
>>>
>>should have a 
>>    
>>
>>>String with the value there).
>>>
>>>  Are we going to remove one day such services from a registry?
>>>
>>>  Cheers,
>>>  Martin
>>>
>>> 
>>>
>>>      
>>>
>>
>
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PromoterAnalysisWorkflow_coexpressedGenesMode_MEME_Mode_Fasta_Version.xml
Type: text/xml
Size: 15899 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20060214/975b10dc/attachment-0004.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ENSG00000174697.orthologs.500.fa.xml
Type: text/xml
Size: 6955 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/moby-dev/attachments/20060214/975b10dc/attachment-0005.xml>