[unclassified] Re: [MOBY-dev] more on graphs

[Mark Wilkinson]

Likely a problem with Collection/Simple...

We'll see what Martin comes up with in the next version :-)

M


Rebecca Ernst wrote:

> Hi Martin and Mark!
>
> If I understand it right the graphic should connect two services if 
> one service uses as input the output of another service. I just had a 
> look at the cgi-client (sorry mark but there it's easy to see !).  I 
> executed get AGICodeByKeyword and then getSequenceByAGI. That gives me 
> a ProteinSequence. With this in hand the cgi-client offers me the 
> services that can deal with this (e.g. Blast it). So I expect a 
> connection between getSequenceByAGI and that Blast-Service.
>
> There is no such connection in the graphic. Why? does it have to do 
> with missing namespaces or with collection/simple (the problems you 
> discussed before) ?
>
> Rebecca.
>
> Martin Senger wrote:
>
>> Mark,
>>   I have the second version of graphs.
>>
>>   The data types graph got better arrow symbols (those used in the UML,
>> at least I hope I got it right):
>>   http://industry.ebi.ac.uk/~senger/jMoby/images/data-types-newer.png
>>
>>   The services graph looks worse. That's why I am asking if it is
>> correct, or not. The main problem is with services getGoTermAssociations
>> and PBI_Cluster_Blast because they do not specify any namespaces for 
>> their
>> input and output. Therefore they are connected with many services that
>> have just 'Object'.
>>   This is the question I am asking:
>>   * if a service claims that it has an input of type "X" but does not
>> define any namespace for it, then any service with output of type "X",
>> even if specified with some namespaces, can connect to it?
>>   * or the true is rather that services with a missing namespace in 
>> their
>> input/output data can matched again only with services with missing
>> namespaces (with the corresponding data types, of course)?
>>
>>   Please let me know, I will continue to work on it asap.
>>
>>   BTW, it's a pity that the API does not support yet the retrieving of
>> the full ServiceType object. If you add it there (as mentioned for the
>> future in the API documentation) I can easily add yet another graph
>> displaying the tree of service types.
>>
>>   Regards,
>>   Martin
>>
>