[MOBY-dev] MOBY-dev Digest, Vol 44, Issue 3
Yan Wong
yan.wong at free.fr
Thu Aug 3 18:14:05 UTC 2006
Hello everybody,
I reply to the question about the licence of the bioMoby Python
code:
I didn't put any licence like GPL, LGPL or other BSD licences in it.
At the time, I was SO busy with the technical and functionalities
of the client interface that I totally forgot the licence...
It is a mistake so please apologize.
Can someone put the same licence as for the Perl interface? Thus
it would clear my mistake.
I am pretty busy at Accenture with SAP projects. However, if you
still have question on how the Python interface work, I would be
happy to answer questions (but don't expect quick answers).
I wrote documentation for the code but you'll agree that it need
to be rewritten and augmented.
Cheers,
Yan Wong
Le 3 août 06 à 18:31, moby-dev-request at lists.open-bio.org a écrit :
> Send MOBY-dev mailing list submissions to
> moby-dev at lists.open-bio.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.open-bio.org/mailman/listinfo/moby-dev
> or, via email, send a message with subject or body 'help' to
> moby-dev-request at lists.open-bio.org
>
> You can reach the person managing the list at
> moby-dev-owner at lists.open-bio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MOBY-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [moby] Moby services in Python (Javier de la Torre)
> 2. License of Python libraries in the MOBY CVS (Javier de la Torre)
> 3. Re: [moby] Moby services in Python (Mark Wilkinson)
> 4. MOBY License (Mark Wilkinson)
> 5. Re: MOBY License (Paul Gordon)
> 6. Re: [moby] Re: Remora (Sebastien Carrere)
> 7. Re: [moby] Re: Remora (Mark Wilkinson)
> 8. Re: [moby] Re: Remora (Mark Wilkinson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 2 Aug 2006 21:36:06 +0200
> From: "Javier de la Torre" <jatorre at gmail.com>
> Subject: Re: [MOBY-dev] [moby] Moby services in Python
> To: "Core developer announcements" <moby-dev at lists.open-bio.org>
> Cc: markw at illuminae.com
> Message-ID:
> <a0174d240608021236x6f0f22ecv6bb30a519a6127a4 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> No, ok, fine...
>
> Is just that the software I am working on handle this thing in a
> different way...
> Our software is a retrieval service, it is actually a database
> wrapper. With the protocol it works if you want to retrieve several
> "objects", records, you do it by defining a query.
>
> Still I think it will be ok to transform this. But I am gonna have to
> implement some limitations on the number of invocations. If a user
> send my service 10.000 records I will not handle all of them because
> my service can easily die.
>
> In theory if all the requested objects are of the same type, what they
> must be because is one single service, I can transform it into a
> single SQL statement to retrieve all of them at once. If I have to
> lunch a different database query per object then I will be into
> troubles...
>
> Best regards,
>
> Javier.
>
>
> On 8/2/06, Paul Gordon <gordonp at ucalgary.ca> wrote:
>> I have always been a champion of the multiple invocations
>> requirement,
>> and still am, for several reasons:
>>
>> 0. First we must acknowledge that people will want to run a bunch of
>> data against a service. I do already, and many Taverna workflows
>> do to
>> (implicit iterators).
>>
>> 1. Some services may use hardware accelerator, which can perform 100
>> jobs as quick as 1 if they are submitted together.
>>
>> 2. If you have a cluster running the service, it is much easier to
>> schedule 100 jobs efficiently than to receive 100 individual requests
>> over the course of a few seconds. i.e. division of labour is much
>> easier when you know in advance how much there is to do!
>>
>> 3. If your server is running 1 CPU, you can decide to run the 100
>> jobs
>> sequentially, at the pace you like (especially if you have many
>> requests
>> coming in from different users at the same time). If the 100 jobs
>> are
>> submitted separately, it is the client (e.g. Taverna) that decides
>> how
>> much breathing room you have. Encouraging
>> multiple-invocations-in-one-envelope may reduce inadvertent
>> denial-of-service attacks.
>>
>> 4. The network and computational overhead is much smaller for 1 large
>> request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet
>> invocation vs. 100, etc.
>>
>> 5. It's not hard to implement! All you really need to do is add a
>> for
>> loop to the service code... MobyServlet
>> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/
>> deployingServices.html)
>> supports multiple invocations implicitly, I don't even really tell
>> the
>> developer about it: their processRequest() method gets called for
>> each
>> mobyData block.
>>
>> My CAD 0.02,
>>
>> Paul
>>>> Is it mandatory for a service to implement the multiple invocations
>>>> funcionality?
>>>>
>>>
>>>
>>> well.... It *may* be that the people working on the error-
>>> handling and
>>> error-codes have reserved an error code for providers who do not
>>> WANT to
>>> handle multiple invocations in a single message, but I don't
>>> think so...
>>>
>>> I think it is mandatory at the moment.
>>>
>>> M
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 2 Aug 2006 19:48:05 +0200
> From: Javier de la Torre <jatorre at gmail.com>
> Subject: [MOBY-dev] License of Python libraries in the MOBY CVS
> To: Core developer announcements <moby-dev at lists.open-bio.org>
> Message-ID: <6ED49E9F-BEAE-49F3-9F1A-5D186F1E7ECC at gmail.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Hi,
>
> I am definitely going to use bioMoby-python. The part for interacting
> with moby-central works fine with me and I do not want to rewrite it
> myself.
>
> But, I would like to embed it into my software for distribution. I
> haven't seen a license together with the software, any idea on how is
> this software licensed?
> Would be ok to redistributed? With proper credits of course!
>
> Thanks.
>
> Javier.
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 02 Aug 2006 13:05:22 -0700
> From: "Mark Wilkinson" <markw at illuminae.com>
> Subject: Re: [MOBY-dev] [moby] Moby services in Python
> To: "Core developer announcements" <moby-dev at biomoby.org>
> Message-ID: <op.tdn928mfnbznux at personalpc.icapture.ubc.ca>
> Content-Type: text/plain; format=flowed; delsp=yes;
> charset=iso-8859-15
>
> On Wed, 02 Aug 2006 12:36:06 -0700, Javier de la Torre
> <jatorre at gmail.com>
> wrote:
>
>
>> In theory if all the requested objects are of the same type, what
>> they
>> must be because is one single service, I can transform it into a
>> single SQL statement to retrieve all of them at once.
>
> This is pretty much what Paul was saying - the optimization of
> answerig
> the request can be controlled by the service provider if all
> requests come
> in a single message.
>
> M
>
>
> --
> --
> Mark Wilkinson
> Assistant Professor, Dept. Medical Genetics
> University of British Columbia
> PI Bioinformatics
> iCAPTURE Centre, St. Paul's Hospital
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 02 Aug 2006 14:45:14 -0700
> From: "Mark Wilkinson" <markw at illuminae.com>
> Subject: [MOBY-dev] MOBY License
> To: "Core developer announcements" <moby-dev at lists.open-bio.org>
> Message-ID: <op.tdoepotdnbznux at personalpc.icapture.ubc.ca>
> Content-Type: text/plain; format=flowed; delsp=yes;
> charset=iso-8859-15
>
> I have only added a license to "my own" branch of the codebase -
> the Perl
> folder. The Perl code is released under the Perl Artistic License.
>
> I suspect that you wont get any objection from any of the other
> developers
> if you want to redistribute, but it would probably be a good idea
> to come
> to a unanimous decision on the license for the entire CVS.
>
> Do any developers object to applying the PAL to *all* parts of the
> MOBY
> CVS?
>
> M
>
>
>
>
>
> On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre
> <jatorre at gmail.com>
> wrote:
>
>> Hi,
>>
>> I am definitely going to use bioMoby-python. The part for interacting
>> with moby-central works fine with me and I do not want to rewrite it
>> myself.
>>
>> But, I would like to embed it into my software for distribution. I
>> haven't seen a license together with the software, any idea on how is
>> this software licensed?
>> Would be ok to redistributed? With proper credits of course!
>>
>> Thanks.
>>
>> Javier.
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
>
> --
> --
> Mark Wilkinson
> Assistant Professor, Dept. Medical Genetics
> University of British Columbia
> PI Bioinformatics
> iCAPTURE Centre, St. Paul's Hospital
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 03 Aug 2006 07:29:43 -0600
> From: Paul Gordon <gordonp at ucalgary.ca>
> Subject: Re: [MOBY-dev] MOBY License
> To: Core developer announcements <moby-dev at lists.open-bio.org>
> Message-ID: <44D1FA47.9020009 at ucalgary.ca>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I think the Perl Artistic License is a fine one. I had actually
> assumed
> that it applied to the whole CVS already :-)
>> I have only added a license to "my own" branch of the codebase -
>> the Perl
>> folder. The Perl code is released under the Perl Artistic License.
>>
>> I suspect that you wont get any objection from any of the other
>> developers
>> if you want to redistribute, but it would probably be a good idea
>> to come
>> to a unanimous decision on the license for the entire CVS.
>>
>> Do any developers object to applying the PAL to *all* parts of the
>> MOBY
>> CVS?
>>
>> M
>>
>>
>>
>>
>>
>> On Wed, 02 Aug 2006 10:48:05 -0700, Javier de la Torre
>> <jatorre at gmail.com>
>> wrote:
>>
>>
>>> Hi,
>>>
>>> I am definitely going to use bioMoby-python. The part for
>>> interacting
>>> with moby-central works fine with me and I do not want to rewrite it
>>> myself.
>>>
>>> But, I would like to embed it into my software for distribution. I
>>> haven't seen a license together with the software, any idea on
>>> how is
>>> this software licensed?
>>> Would be ok to redistributed? With proper credits of course!
>>>
>>> Thanks.
>>>
>>> Javier.
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>
>>
>>
>>
>>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 03 Aug 2006 18:12:24 +0200
> From: Sebastien Carrere <Sebastien.Carrere at toulouse.inra.fr>
> Subject: Re: [MOBY-dev] [moby] Re: Remora
> To: moby-dev at lists.open-bio.org
> Cc: Ed Kawas <ed.kawas at gmail.com>, markw at illuminae.com
> Message-ID: <44D22068.1010802 at toulouse.inra.fr>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Mark and Eddie,
>
> I flip this discussion onto the mailing list :-[
>
> The lack of XSCUFL specifications is a real problem for us.
> The only one I have been able to find is a 2 years old one
> (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html)
>
> Nevertheless, I can start to develop a Remora/XSCUFL adapter at this
> time, using the template sent by Eddie to deal with
> secondaryArticles.
>
> By this way, we could provide Remora user the possibility to
> download/upload their workflow in "current" XSCUFL format.
>
> Cordialement,
>
> Sebastien
>
> Ed Kawas a ?crit :
>> Hi,
>>
>> I represent secondarys like the following:
>> <s:Parameter s:name="parameterName">parameterValue</s:Parameter>
>>
>> Where 'parameterName' is the articlename for the secondary
>> parameter and the
>> 'parameterValue' is the value.
>>
>> For example:
>> <s:processor name="getUniprotIdentifierByGeneName" workers="10">
>> <s:description>some description</s:description>
>> <s:biomobywsdl>
>>
>> <s:mobyEndpoint>http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/
>> mobycentral.pl
>> </s:mobyEndpoint>
>> <s:serviceName>getUniprotIdentifierByGeneName</s:serviceName>
>> <s:authorityName>bioinfo.icapture.ubc.ca</s:authorityName>
>> <s:Parameter s:name="genome">human</s:Parameter>
>> </s:biomobywsdl>
>> </s:processor>
>>
>>
>> This is how it is done in Taverna.
>>
>> Eddie
>>
>>> -----Original Message-----
>>> From: Mark Wilkinson [mailto:markw at illuminae.com]
>>> Sent: Wednesday, August 02, 2006 3:36 PM
>>> To: Sebastien Carrere
>>> Cc: GOUZY J?rome; Eddie Kawas
>>> Subject: Re: [moby] Re: [MOBY-dev] Remora
>>>
>>> Hi Sebastien,
>>>
>>> I've spoken with Eddie and he is able to represent
>>> SecondaryArticles in SCUFL, at least for Taverna. By the
>>> sounds of it, SCUFL is relatively undefined (I can't find any
>>> documentation for the language anywhere) and in Taverna
>>> apparently you are allowed to specify your own SCUFL tags,
>>> and declare how they should be parsed, so it's more or less
>>> wide-open to be extended.
>>>
>>> So... we represent Secondary parameters in SCUFL, and they
>>> can be interpreted by Taverna; however since there is no
>>> definition of the SCUFL language anywhere that we can find,
>>> we are certain that (at the
>>> moment) only Taverna can handle these new secondary parameter
>>> tags. My feeling is that, from the perspective of Taverna,
>>> all inputs are identical, so they haven't created different
>>> port types for secondaries vs. primaries as we require for MOBY.
>>>
>>> Eddie will tell you more - I have c.c.'d him this message.
>>>
>>> It's probably a good idea to flip this conversation onto the
>>> mailing list, but I don't want to send your message to the
>>> list without your permission :-) If you want to c.c. the
>>> list with your response that would be great!
>>>
>>> Cheers!
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote:
>>>
>>>> Bonjour Mark,
>>>>
>>>> Remora is not yet SCUFLized.
>>>> When we started our project, the problem with SCUFL is that
>>>>
>>> it did not
>>>
>>>> deal with SecondaryArticles ...
>>>> For us it was a critic.
>>>>
>>>> So, my question is : " is SCUFL deals with
>>>>
>>> moby:SecondaryArticles now ?".
>>>
>>>> If th answer is yes, I can write a parser SCUFL <->
>>>> RemoraWorkflowsDescription.
>>>> If no, maybe I can also write it but with loss of information ...
>>>>
>>>> Sincerely,
>>>>
>>>> Sebastien.
>>>>
>>>> mark wilkinson a ?crit :
>>>>
>>>>> Hi Remora developers!
>>>>>
>>>>> I have a quick question for you - before I say this in my
>>>>>
>>> manuscript can you confirm that you are using SCUFL "under
>>> the hood" in Remora? I'm guessing, but I don't know...
>>>
>>>>> The next iteration of gbrowse-moby (available tomorrow!)
>>>>>
>>> generates a SCUFL document while you browse, and I want to
>>> say that this document can then be loaded to Taverna AND
>>> Remora... But I'm not certain of that.
>>>
>>>>> Are any of the other clients using XSCUFL?
>>>>>
>>>>> Cheers!
>>>>>
>>>>> M
>>>>>
>>>>>
>>>>> --
>>>>> Mark Wilkinson
>>>>> ...on the road!
>>>>> _______________________________________________
>>>>> MOBY-dev mailing list
>>>>> MOBY-dev at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>
>>>>>
>>>>>
>>> --
>>> 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
>>>
>>> "Since the point of a definition is to explain the meaning of
>>> a term to
>>> someone who is unfamiliar with its proper application, the
>>> use of language that doesn't help such a person learn how to
>>> apply the term is pointless. Thus, "happiness is a warm
>>> puppy" may be a lovely thought,
>>> but it is a lousy definition."
>>>
>>> K?hler et al, 2006
>>>
>>>
>>
>>
>>
>
> --
> __________________________________________________________
>
> Sebastien CARRERE LIPM (INRA-CNRS)
> B.P.52627 -- 31326 CASTANET TOLOSAN
> tel:(33) 5-61-28-53-29
> fax:(33) 5-61-28-50-61
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 03 Aug 2006 09:28:58 -0700
> From: Mark Wilkinson <markw at illuminae.com>
> Subject: Re: [MOBY-dev] [moby] Re: Remora
> To: Core developer announcements <moby-dev at lists.open-bio.org>
> Message-ID: <1154622538.15856.0.camel at bioinfo.icapture.ubc.ca>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote:
>> http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html)
>
> wow! I searched for ages and couldn't find that!
>
> Well... it's a start :-)
>
> M
>
>
>
>
> --
> 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
>
> "Since the point of a definition is to explain the meaning of a
> term to
> someone who is unfamiliar with its proper application, the use of
> language that doesn't help such a person learn how to apply the
> term is
> pointless. Thus, "happiness is a warm puppy" may be a lovely thought,
> but it is a lousy definition."
> K?
> hler et al, 2006
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 03 Aug 2006 09:31:44 -0700
> From: Mark Wilkinson <markw at illuminae.com>
> Subject: Re: [MOBY-dev] [moby] Re: Remora
> To: Core developer announcements <moby-dev at lists.open-bio.org>
> Message-ID: <1154622704.15856.2.camel at bioinfo.icapture.ubc.ca>
> Content-Type: text/plain; charset=utf-8
>
> "The language itself should be considered volatile, any users of it
> should join the taverna developers list and monitor it, we do not
> support this language for use outside of Taverna."
>
> LOL! Well, Tom, when you build something this useful, you can't
> expect
> people not to use it!
>
> M
>
>
>
>
> On Thu, 2006-08-03 at 18:12 +0200, Sebastien Carrere wrote:
>> Hi Mark and Eddie,
>>
>> I flip this discussion onto the mailing list :-[
>>
>> The lack of XSCUFL specifications is a real problem for us.
>> The only one I have been able to find is a 2 years old one
>> (http://www.ebi.ac.uk/~tmo/mygrid/XScuflSpecification.html)
>>
>> Nevertheless, I can start to develop a Remora/XSCUFL adapter at this
>> time, using the template sent by Eddie to deal with
>> secondaryArticles.
>>
>> By this way, we could provide Remora user the possibility to
>> download/upload their workflow in "current" XSCUFL format.
>>
>> Cordialement,
>>
>> Sebastien
>>
>> Ed Kawas a ?crit :
>>> Hi,
>>>
>>> I represent secondarys like the following:
>>> <s:Parameter s:name="parameterName">parameterValue</s:Parameter>
>>>
>>> Where 'parameterName' is the articlename for the secondary
>>> parameter and the
>>> 'parameterValue' is the value.
>>>
>>> For example:
>>> <s:processor name="getUniprotIdentifierByGeneName" workers="10">
>>> <s:description>some description</s:description>
>>> <s:biomobywsdl>
>>>
>>> <s:mobyEndpoint>http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/
>>> mobycentral.pl
>>> </s:mobyEndpoint>
>>> <s:serviceName>getUniprotIdentifierByGeneName</s:serviceName>
>>> <s:authorityName>bioinfo.icapture.ubc.ca</s:authorityName>
>>> <s:Parameter s:name="genome">human</s:Parameter>
>>> </s:biomobywsdl>
>>> </s:processor>
>>>
>>>
>>> This is how it is done in Taverna.
>>>
>>> Eddie
>>>
>>>> -----Original Message-----
>>>> From: Mark Wilkinson [mailto:markw at illuminae.com]
>>>> Sent: Wednesday, August 02, 2006 3:36 PM
>>>> To: Sebastien Carrere
>>>> Cc: GOUZY J?rome; Eddie Kawas
>>>> Subject: Re: [moby] Re: [MOBY-dev] Remora
>>>>
>>>> Hi Sebastien,
>>>>
>>>> I've spoken with Eddie and he is able to represent
>>>> SecondaryArticles in SCUFL, at least for Taverna. By the
>>>> sounds of it, SCUFL is relatively undefined (I can't find any
>>>> documentation for the language anywhere) and in Taverna
>>>> apparently you are allowed to specify your own SCUFL tags,
>>>> and declare how they should be parsed, so it's more or less
>>>> wide-open to be extended.
>>>>
>>>> So... we represent Secondary parameters in SCUFL, and they
>>>> can be interpreted by Taverna; however since there is no
>>>> definition of the SCUFL language anywhere that we can find,
>>>> we are certain that (at the
>>>> moment) only Taverna can handle these new secondary parameter
>>>> tags. My feeling is that, from the perspective of Taverna,
>>>> all inputs are identical, so they haven't created different
>>>> port types for secondaries vs. primaries as we require for MOBY.
>>>>
>>>> Eddie will tell you more - I have c.c.'d him this message.
>>>>
>>>> It's probably a good idea to flip this conversation onto the
>>>> mailing list, but I don't want to send your message to the
>>>> list without your permission :-) If you want to c.c. the
>>>> list with your response that would be great!
>>>>
>>>> Cheers!
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 2006-08-02 at 10:21 +0200, Sebastien Carrere wrote:
>>>>
>>>>> Bonjour Mark,
>>>>>
>>>>> Remora is not yet SCUFLized.
>>>>> When we started our project, the problem with SCUFL is that
>>>>>
>>>> it did not
>>>>
>>>>> deal with SecondaryArticles ...
>>>>> For us it was a critic.
>>>>>
>>>>> So, my question is : " is SCUFL deals with
>>>>>
>>>> moby:SecondaryArticles now ?".
>>>>
>>>>> If th answer is yes, I can write a parser SCUFL <->
>>>>> RemoraWorkflowsDescription.
>>>>> If no, maybe I can also write it but with loss of information ...
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> Sebastien.
>>>>>
>>>>> mark wilkinson a ?crit :
>>>>>
>>>>>> Hi Remora developers!
>>>>>>
>>>>>> I have a quick question for you - before I say this in my
>>>>>>
>>>> manuscript can you confirm that you are using SCUFL "under
>>>> the hood" in Remora? I'm guessing, but I don't know...
>>>>
>>>>>> The next iteration of gbrowse-moby (available tomorrow!)
>>>>>>
>>>> generates a SCUFL document while you browse, and I want to
>>>> say that this document can then be loaded to Taverna AND
>>>> Remora... But I'm not certain of that.
>>>>
>>>>>> Are any of the other clients using XSCUFL?
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> M
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mark Wilkinson
>>>>>> ...on the road!
>>>>>> _______________________________________________
>>>>>> MOBY-dev mailing list
>>>>>> MOBY-dev at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> 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
>>>>
>>>> "Since the point of a definition is to explain the meaning of
>>>> a term to
>>>> someone who is unfamiliar with its proper application, the
>>>> use of language that doesn't help such a person learn how to
>>>> apply the term is pointless. Thus, "happiness is a warm
>>>> puppy" may be a lovely thought,
>>>> but it is a lousy definition."
>>>>
>>>> K?hler et al, 2006
>>>>
>>>>
>>>
>>>
>>>
>>
> --
> 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
>
> "Since the point of a definition is to explain the meaning of a
> term to
> someone who is unfamiliar with its proper application, the use of
> language that doesn't help such a person learn how to apply the
> term is
> pointless. Thus, "happiness is a warm puppy" may be a lovely thought,
> but it is a lousy definition."
> K?
> hler et al, 2006
>
>
>
> ------------------------------
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
>
> End of MOBY-dev Digest, Vol 44, Issue 3
> ***************************************
>
More information about the MOBY-dev
mailing list