[MOBY-dev] [moby] non-compliant services

[Mark Wilkinson]

I see this as the second question of a two-question set, where the first
question is "how do we FIND these non-compliant services in the first
place?"

You and I run across them somewhat randomly, but only because we happen
to know what the correct input data would be to get some output from the
service in question.  (this speaks to the discussion we had at the last
meeting about adding sample input/output to the service metadata, but
that's beside the point for this discusson). 

I am entirely in favour of removing these services from the registry,
since they only serve to confuse people.  I suspect, however, that these
services will naturally disappear when we switch on the RDF agent (the
delay now is in creating the MOBY Administrative interface that  know
you and he have been discussing.  It's almost done - I wrote it for him
yesterday :-) ). Anyone who has not downloaded their RDF is also
unlikely to have fixed their services, so they will get culled from the
registry.

Regardless, we are still left with the question of what to do when you
receive an illegally structured object.  I think the client should raise
a warning, including the service providers email address, but do its
best to render the data that it receives.  However, I don't think the
client should attempt to pass this invalid data on to another service.
A clever client might be able to re-format the data to make it right,
but that obviously shouldn't be a requirement.

It would be great if we could do a registry "purge" at some point in the
near future to get rid of the clutter... Certainly, I think we MUST do a
purge of "test" services/objects before we publish our respective
articles on gbrowse_moby and dashboard, or we will frustrate and confuse
the reviewers!

M




On Tue, 2006-02-14 at 15:57 +0000, 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
> 
-- 
--
...his last words were 'Hey guys!  Watch this!'
--
Mark Wilkinson
Asst. Professor
Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics
iCAPTURE Centre
St. Paul's Hospital
Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274

"For most of this century we have viewed communications as a conduit, 
       a pipe between physical locations on the planet. 
What's happened now is that the conduit has become so big and interesting 
      that communication has become more than a conduit, 
       it has become a destination in its own right..."

                Paul Saffo - Director, Institute for the Future