From harttig at mail.dife.de Tue Aug 2 11:42:38 2005 From: harttig at mail.dife.de (Ulrich Harttig) Date: Tue Aug 2 11:31:45 2005 Subject: [MOBY-l] parameter handling problems Message-ID: <42EF946E.4090708@mail.dife.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have some problems with handling a message to a service asking for an input object and a secondary parameter using the Perl API (and XML::LibXML version 1.58, libxml2 version 2.6.16) After parsing the message with 'complexServiceInputParser()' extraction of the the simple article is no problem but accessing the content of the secondary article with ($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); does not find any content although the $input node contains xml Is there any reason why this shouldn't work ? Could someone point me to examples where accessing parameters works ? Thanks for your help Best regards Ulrich - -- Ulrich Harttig German Institute of Human Nutrition Potsdam-Rehbruecke Dept. of Epidemiology Arthur-Scheunert-Allee 114-116, 14558 Nuthetal, Germany phone: +49 (0)33200 88-729, fax: +49 (0)33200 88-721 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC75RueYdmlKJoHzkRAuKeAJ9QkwlecCYbquhW6W1u1y9arXzPAwCg0pjG 64tQh4osNp61zpuCQYo5VcI= =AOm+ -----END PGP SIGNATURE----- From harttig at mail.dife.de Tue Aug 2 11:42:38 2005 From: harttig at mail.dife.de (Ulrich Harttig) Date: Tue Aug 2 11:40:25 2005 Subject: [MOBY-l] parameter handling problems Message-ID: <42EF946E.4090708@mail.dife.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have some problems with handling a message to a service asking for an input object and a secondary parameter using the Perl API (and XML::LibXML version 1.58, libxml2 version 2.6.16) After parsing the message with 'complexServiceInputParser()' extraction of the the simple article is no problem but accessing the content of the secondary article with ($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); does not find any content although the $input node contains xml Is there any reason why this shouldn't work ? Could someone point me to examples where accessing parameters works ? Thanks for your help Best regards Ulrich - -- Ulrich Harttig German Institute of Human Nutrition Potsdam-Rehbruecke Dept. of Epidemiology Arthur-Scheunert-Allee 114-116, 14558 Nuthetal, Germany phone: +49 (0)33200 88-729, fax: +49 (0)33200 88-721 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC75RueYdmlKJoHzkRAuKeAJ9QkwlecCYbquhW6W1u1y9arXzPAwCg0pjG 64tQh4osNp61zpuCQYo5VcI= =AOm+ -----END PGP SIGNATURE----- From d.haase at gsf.de Wed Aug 3 02:25:20 2005 From: d.haase at gsf.de (Dirk Haase) Date: Wed Aug 3 02:16:18 2005 Subject: [MOBY-l] parameter handling problems In-Reply-To: <42EF946E.4090708@mail.dife.de> References: <42EF946E.4090708@mail.dife.de> Message-ID: <200508030825.20164.d.haase@gsf.de> On Tuesday 02 August 2005 17:42, Ulrich Harttig wrote: > ($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); > > does not find any content although the $input node contains > > > xml > > > Is there any reason why this shouldn't work ? If I remember correctly, I tried the same and didn't work for me neither... > Could someone point me to examples where accessing parameters works ? Here is what works for me: the service takes several secondaries, so it puts all parameter values into a %paramHash: if ( $articleType == SECONDARY ) { my $param = $input->getAttribute('articleName'); my @valueNodes = $input->getChildrenByTagName('moby:Value'); my $value = $valueNodes[0]->textContent(); # there should be only one value $paramHash{$param} = $value; } Hope this helps. Regards, dirk From harttig at mail.dife.de Wed Aug 3 03:48:34 2005 From: harttig at mail.dife.de (Ulrich Harttig) Date: Wed Aug 3 03:34:52 2005 Subject: [MOBY-l] parameter handling problems In-Reply-To: <200508030825.20164.d.haase@gsf.de> References: <42EF946E.4090708@mail.dife.de> <200508030825.20164.d.haase@gsf.de> Message-ID: <42F076D2.8060806@mail.dife.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dirk Haase wrote: > On Tuesday 02 August 2005 17:42, Ulrich Harttig wrote: > > >>($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); >> >>does not find any content although the $input node contains >> >> >> xml >> >> >>Is there any reason why this shouldn't work ? > > > If I remember correctly, I tried the same and didn't work for me neither... > > >>Could someone point me to examples where accessing parameters works ? > > > Here is what works for me: the service takes several secondaries, so it puts > all parameter values into a %paramHash: > > if ( $articleType == SECONDARY ) { > my $param = $input->getAttribute('articleName'); > my @valueNodes = $input->getChildrenByTagName('moby:Value'); > my $value = $valueNodes[0]->textContent(); # there should be only one value > $paramHash{$param} = $value; > } > > Hope this helps. > > Regards, > dirk Thanks a lot for the help, your example did work. But I still wondered why $input->getChildrenByTagName('moby:Value') worked but $input->getElementByTagName('moby:Parameter') would not. I was guessing that this had something to do with the structure/content of the node from the secondary article. getElementsByTagName is supposed to return a named descendant of the node. According to the DOM spec: "A descendant node of any node A is any node below A in a tree model, where "below" means "away from the root." But to me it seems that is actually the root of the node , judging by the content of the $input parameter, so one would not be able to find a descendant of the same name. So if I pass instead the original message using the $input->parentNode to the CommonSub function 'getNodeContentWithArticle' it then returns the desired parameter value ($secondary) = getNodeContentWithArticle($input->parentNode, "Parameter", "VarType"); best regards Ulrich - -- Ulrich Harttig German Institute of Human Nutrition Potsdam-Rehbruecke Dept. of Epidemiology Arthur-Scheunert-Allee 114-116, 14558 Nuthetal, Germany phone: +49 (0)33200 88-729, fax: +49 (0)33200 88-721 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC8HbSeYdmlKJoHzkRAp6ZAJ98gonlRj76yBlZEf8feQYd+fx9QACgtVqI qDx3gY2ljO29ZcdGqy9QZ14= =OuRI -----END PGP SIGNATURE----- From rebecca.ernst at gsf.de Thu Aug 4 03:11:25 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu Aug 4 03:02:16 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 Message-ID: <42F1BF9D.6040401@gsf.de> Hi there! It might be boring for you that I start this topic again but the problem still exists and within Planet we are getting in serious problems now and I guess other people will also run into them! Fact is, that old workflows don't work in Taverna 1.2 . According to Tom this is not how it should be, software should always be downwards compatible and that's how I see it, too. Now, due to the fact that it doesn't work but people want to make use of the new, cool features of 1.2 they start developing services which run on 1.2. as you can guess they don't work in 1.1. anymore. It can't be a solution to develop biomoby workflows for every Taverna version so could we please try to solve this problem now before lots of people will have to change their services back and forth ?? If noone (except of Heiko Dirk and me) want the collections to be changed in the BioMoby API we will have to change the default behaviour of Taverna back to the old one! Cheers, Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From senger at ebi.ac.uk Thu Aug 4 03:21:48 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Aug 4 03:12:15 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1BF9D.6040401@gsf.de> Message-ID: Rebecca, I have talked about it with Eddie when I met him in Malaga about two/three weeks ago. And he promised (!) that he was going to put back the old CreateMoby... and ParseMoby... classes. And I have never heard from him since. So it is very good that you started this topic again - perhaps he is listening :-) Cheers, Martin -- Martin Senger martin.senger@gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From edward.kawas at gmail.com Thu Aug 4 03:24:25 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Aug 4 03:15:23 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: Message-ID: <42f1c2c1.6263d1d9.1fa1.67e4@mx.gmail.com> Hi, I have put the old functionality back into Taverna. If you build a fresh copy from the cvs, you will notice (hopefully) that all is well again. Eddie > -----Original Message----- > From: moby-l-bounces@portal.open-bio.org [mailto:moby-l- > bounces@portal.open-bio.org] On Behalf Of Martin Senger > Sent: Thursday, August 04, 2005 12:22 AM > To: Rebecca Ernst > Cc: taverna-users@lists.sourceforge.net; mobyl > Subject: Re: [MOBY-l] Biomoby and Taverna 1.2 > > Rebecca, > I have talked about it with Eddie when I met him in > Malaga about > two/three weeks ago. And he promised (!) that he was going > to put back the > old CreateMoby... and ParseMoby... classes. And I have > never heard from > him since. So it is very good that you started this topic > again - perhaps > he is listening :-) > > Cheers, > Martin > > -- > Martin Senger martin.senger@gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l From markw at illuminae.com Thu Aug 4 03:48:35 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 03:39:00 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1BF9D.6040401@gsf.de> References: <42F1BF9D.6040401@gsf.de> Message-ID: <1123141715.42f1c853bd83f@webmail.illuminae.com> > If noone (except of Heiko Dirk and me) want the collections to be > changed in the BioMoby API we will have to change the default behaviour > of Taverna back to the old one! I think your use-case for wanting the behaviour of collections to change is unfounded, since it overloads the intended meaning of the Collection element by putting WAAAAAAY too much semantics in it. The use case of having sets of multiple alignments represented as Collections of Collections means that the inner-most Collection now not only represents a "bag" of things, but a "bag" of things that **DO** have a close semantic relationship to each other - these are a set of related sequences, and a set of related sequences **is a useful Object** in the context of MOBY, could easily trigger the discovery of a particular set of services that can specifically operate on sets of closely related sequences (versus sets of unrelated sequences), and therefore should be given a class of its own (IMO). Moreover, if we allow collections of collections, we then have a problem of recursion - collections of collections of collections of collections of collections.... What a nightmare! The API change is not a significant one, I agree... and in fact, since people are already mis-using the messaging format in this way much of the software out there can already handle the situation... but given that particular use-case, I think you are losing more semantics than you need to be by refusing to create a new Object Class. M From tmo at ebi.ac.uk Thu Aug 4 04:06:45 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu Aug 4 03:56:07 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123141715.42f1c853bd83f@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> Message-ID: <42F1CC95.9040803@ebi.ac.uk> markw@illuminae.com wrote: >>If noone (except of Heiko Dirk and me) want the collections to be >>changed in the BioMoby API we will have to change the default behaviour >>of Taverna back to the old one! > > > I think your use-case for wanting the behaviour of collections to change is > unfounded, since it overloads the intended meaning of the Collection element by > putting WAAAAAAY too much semantics in it. The use case of having sets of > multiple alignments represented as Collections of Collections means that the > inner-most Collection now not only represents a "bag" of things, but a "bag" of > things that **DO** have a close semantic relationship to each other - these are > a set of related sequences, and a set of related sequences **is a useful > Object** in the context of MOBY, could easily trigger the discovery of a > particular set of services that can specifically operate on sets of closely > related sequences (versus sets of unrelated sequences), and therefore should be > given a class of its own (IMO). True, but you probably also want to allow, for example, a GC percentage service to run over that set of sets and produce a set of sets of scores - if the set of sequences becomes some opaque type without this information then you can't do this. Strikes me that you need a more sophisticated typing scheme to do this, perhaps extending the Collection concept to allow the imposition of semantics to the group of child objects? I think you do need nested collections though, it's not impossible to deal with (we have some slightly twisted code in Taverna to do it but it works well enough) Tom From rebecca.ernst at gsf.de Thu Aug 4 04:16:35 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu Aug 4 04:07:00 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123141715.42f1c853bd83f@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> Message-ID: <42F1CEE3.6020901@gsf.de> Hi Mark! I already understood that noone agrees with us ;-) Funny thing is that everyone keeps talking about collections of collections which Dirk never wanted. snip from Dirk: Correct. That's why we did not ask for nested collections. We suggest to allow for multiple Simple output as default - which I think is very appropriate because especially query services will usually return more than one result. This way we would save the collection concept for semantically related entities. I am still not sure if anyone has really understood why we have problems with the collections as they are used now but we are happy to leave them as they are . Although if I think about it I have to ask one more provoking question ( ;-) ) : Why do we have Simples in BioMoby then? I only have VERY few services that give back simples according to the API. From my point of view we could also leave Simples away as they make no sense to me. It is of no valuable information to me if a service gives back exactly three or an unknown number of AGI codes.... But as I said already - if everyone is happy with the current use of collections I will be quiet from now on :-) The problem is then only shiftet to the clients (As seen in Taverna it leaves a much bigger job for the clients as they will have to split the collections) Cheers, Rebecca And you guys in Vancouver would rather go to bed now :-) markw@illuminae.com wrote: >>If noone (except of Heiko Dirk and me) want the collections to be >>changed in the BioMoby API we will have to change the default behaviour >>of Taverna back to the old one! >> >> > >I think your use-case for wanting the behaviour of collections to change is >unfounded, since it overloads the intended meaning of the Collection element by >putting WAAAAAAY too much semantics in it. The use case of having sets of >multiple alignments represented as Collections of Collections means that the >inner-most Collection now not only represents a "bag" of things, but a "bag" of >things that **DO** have a close semantic relationship to each other - these are >a set of related sequences, and a set of related sequences **is a useful >Object** in the context of MOBY, could easily trigger the discovery of a >particular set of services that can specifically operate on sets of closely >related sequences (versus sets of unrelated sequences), and therefore should be >given a class of its own (IMO). > >Moreover, if we allow collections of collections, we then have a problem of >recursion - collections of collections of collections of collections of >collections.... What a nightmare! > >The API change is not a significant one, I agree... and in fact, since people >are already mis-using the messaging format in this way much of the software out >there can already handle the situation... but given that particular use-case, I >think you are losing more semantics than you need to be by refusing to create a >new Object Class. > >M > >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Thu Aug 4 04:26:14 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 04:21:37 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1CEE3.6020901@gsf.de> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> Message-ID: <1123143974.42f1d1268d031@webmail.illuminae.com> Quoting Rebecca Ernst : > And you guys in Vancouver would rather go to bed now :-) Granted, I would rather be in bed, but neither Eddie nor I are in Vancouver so it would be inappropriate :-) we're both just a bit north of you in Manchester! M From markw at illuminae.com Thu Aug 4 04:32:30 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 04:23:19 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1CC95.9040803@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> Message-ID: <1123144350.42f1d29e7978b@webmail.illuminae.com> Quoting Tom Oinn : > - if the set of sequences becomes some opaque type without this > information then you can't do this. Nothing becomes opaque by putting it in the MOBY data-typing system - it can only get richer and more meaningful by assigning it a specific class :-) Generic services that operate on lower ontological classes will still be discovered and executed, so this use case still fails the test of need. > Strikes me that you need a more > sophisticated typing scheme to do this, perhaps extending the Collection > concept to allow the imposition of semantics to the group of child > objects? Creating a new type of element - limitedCollection or something like that - would be an alternative... or changing the definition of Collection to "zero or more" rather than "one or moe" would also allow us to terminate the recursion. > I think you do need nested collections though, it's not > impossible to deal with (we have some slightly twisted code in Taverna > to do it but it works well enough) Probably we do... but I find it hard to believe that we will have sets of sets of sets of sets where there is no implicit semantic meaning at any level! As soon as there is semantic meaning, it should be a fully qualified MOBY Object rather than an arbitrary collection.... IMO :-) M > > Tom > From markw at illuminae.com Thu Aug 4 04:41:19 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 04:31:40 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123143974.42f1d1268d031@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> <1123143974.42f1d1268d031@webmail.illuminae.com> Message-ID: <1123144879.42f1d4af9ab8e@webmail.illuminae.com> Quoting markw@illuminae.com: > Granted, I would rather be in bed, but neither Eddie nor I are in Vancouver > so > it would be inappropriate :-) Gosh... I *am* tired! I didn't mean to imply that.... :-/ M From rebecca.ernst at gsf.de Thu Aug 4 04:50:34 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu Aug 4 05:00:58 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123144879.42f1d4af9ab8e@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> <1123143974.42f1d1268d031@webmail.illuminae.com> <1123144879.42f1d4af9ab8e@webmail.illuminae.com> Message-ID: <42F1D6DA.2060200@gsf.de> Mark wrote: > Gosh... I *am* tired! > I didn't mean to imply that.... > :-/ Hehe - it took me a while to get the meaning 'between the lines' ;-) As you are in Manchestser we have the whole european day to discuss about collections ;-) With Tom you can even chat sitting together if you are so close ... I was thinking about a way to tell you what my problem with this simple and collection thing is and I'll give it a very last try with a trivial example: My favourite example to explain BioMoby services to non- informatics people is that I am a service provider running a laundry. Incoming objects are dirty laundry, out go clean clothes. In your way of interpreting services the man in the laundry gets the information that you are either always bringing exactly 3 shirts to wash or you are bringing a not known number of shirts (one time you bring 2, the next time 15 shirts but it's *always* only shirts) What I am saying is that it *can't* be of any use to this guy to know how many shirts you'll bring - he will have to wash all of them, one by one. But if someone is bringing three complete outfits belonging together (a jacket, a trouser, a shirt and socks ) I need to take care about this relationship and put them back together before giving it back. Does this make sense to you?? Rebecca markw@illuminae.com wrote: >Quoting markw@illuminae.com: > > > >>Granted, I would rather be in bed, but neither Eddie nor I are in Vancouver >>so >>it would be inappropriate :-) >> >> > >Gosh... I *am* tired! > >I didn't mean to imply that.... > >:-/ > >M > > > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From tmo at ebi.ac.uk Thu Aug 4 05:11:51 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu Aug 4 05:01:11 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123144350.42f1d29e7978b@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> Message-ID: <42F1DBD7.4000700@ebi.ac.uk> markw@illuminae.com wrote: > Quoting Tom Oinn : > > >>- if the set of sequences becomes some opaque type without this >>information then you can't do this. > > > Nothing becomes opaque by putting it in the MOBY data-typing system - it can > only get richer and more meaningful by assigning it a specific class :-) > Generic services that operate on lower ontological classes will still be > discovered and executed, so this use case still fails the test of need. Okay, so I might be failing to entirely understand the moby typing system. In the case I describe I need to define a type such that : 1) It can be discovered as 'set of aligned sequences' as a single entity. 2) It can also be discovered as a collection of 'sequence' As I understood it the collection / simple wasn't part of the ontology so this isn't possible? Effectively I believe that 'set of aligned sequences' cannot be made a restriction of 'collection of 'sequence'' as the collection concept isn't part of the ontology - is this wrong? Tom From rebecca.ernst at gsf.de Thu Aug 4 04:58:00 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu Aug 4 05:10:47 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42f1c2c1.6263d1d9.1fa1.67e4@mx.gmail.com> References: <42f1c2c1.6263d1d9.1fa1.67e4@mx.gmail.com> Message-ID: <42F1D898.7040006@gsf.de> Hi Eddie! that's good news! Thanks a lot for this! Is it possible to update the packaged one also? I don't have a cvs checkout and I guess most of the other people also use the packages. Cheers, Rebecca Edward Kawas wrote: >Hi, > >I have put the old functionality back into Taverna. > >If you build a fresh copy from the cvs, you will notice >(hopefully) that all is well again. > >Eddie > > > >>-----Original Message----- >>From: moby-l-bounces@portal.open-bio.org [mailto:moby-l- >>bounces@portal.open-bio.org] On Behalf Of Martin Senger >>Sent: Thursday, August 04, 2005 12:22 AM >>To: Rebecca Ernst >>Cc: taverna-users@lists.sourceforge.net; mobyl >>Subject: Re: [MOBY-l] Biomoby and Taverna 1.2 >> >>Rebecca, >> I have talked about it with Eddie when I met him in >>Malaga about >>two/three weeks ago. And he promised (!) that he was going >>to put back the >>old CreateMoby... and ParseMoby... classes. And I have >>never heard from >>him since. So it is very good that you started this topic >>again - perhaps >>he is listening :-) >> >> Cheers, >> Martin >> >>-- >>Martin Senger martin.senger@gmail.com >> >>International Rice Research Institute >>Biometrics and Bioinformatics Unit >>DAPO BOX 7777, Metro Manila >>Philippines, phone: +63-580-5600 (ext.2324) >> >>_______________________________________________ >>moby-l mailing list >>moby-l@biomoby.org >>http://biomoby.org/mailman/listinfo/moby-l >> >> > >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Thu Aug 4 05:24:08 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 05:14:42 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1DBD7.4000700@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> Message-ID: <1123147448.42f1deb87303f@webmail.illuminae.com> Quoting Tom Oinn : > 1) It can be discovered as 'set of aligned sequences' as a single entity. > > 2) It can also be discovered as a collection of 'sequence' > > As I understood it the collection / simple wasn't part of the ontology > so this isn't possible? You're correct, and that is a good point! I think that the semantics you lose by making them a simple bag of sequences is more important than the flexibility of service-discovery that you gain. This is why we (Eddie) is working on MOBY Object degradation widgets for Taverna, such that you strip away the outer "semantic" tag and are left with a collection of sequences that could then trigger the latter discovery that you mention above. I don't think we can achieve both situations in one step, unless we defined a parent class "genericSequenceCollection"... but then we would have to do that for all Object classes and our bicycles would explode! M From markw at illuminae.com Thu Aug 4 05:25:38 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu Aug 4 05:16:04 2005 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1D6DA.2060200@gsf.de> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> <1123143974.42f1d1268d031@webmail.illuminae.com> <1123144879.42f1d4af9ab8e@webmail.illuminae.com> <42F1D6DA.2060200@gsf.de> Message-ID: <1123147538.42f1df121b200@webmail.illuminae.com> > With Tom you can even chat sitting together if you > are so close ... > England is small... but not THAT small :-) I'll think about your dirty laundry later - must get some other things done! M From tmo at ebi.ac.uk Thu Aug 4 06:03:19 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu Aug 4 05:52:01 2005 Subject: [Taverna-users] Re: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123147448.42f1deb87303f@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> <1123147448.42f1deb87303f@webmail.illuminae.com> Message-ID: <42F1E7E7.3060109@ebi.ac.uk> markw@illuminae.com wrote: > Quoting Tom Oinn : > > >>1) It can be discovered as 'set of aligned sequences' as a single entity. >> >>2) It can also be discovered as a collection of 'sequence' >> >>As I understood it the collection / simple wasn't part of the ontology >>so this isn't possible? > > You're correct, and that is a good point! Nice to know my brain's working again :) I don't think a decomposition widget is the right way to go - the data in question _is_ a group of sequences, however that's described. If you're using RDF to describe the types can't you express the above? I think there's a misconception that semantic types are the same as classical object types in e.g. Java. In the latter case an entity has exactly one type (ignoring things like interfaces!) and that type then has inheritance and restriction relationships. This causes issues when you want to use that entity in a different way - an example of this is in Taverna's code where we have a type that represents a user interface widget that can bind to a workflow model but we also know that all such widgets are instances of one of the core Java ui classes. Because Java doesn't have multiple inheritance or mixins we can't express this in the Java type system - I believe this is exactly analogous to the case I described above. In the case of a semantic description you can make statements describing the entity, in the current Moby implementation these statements are pretty much hardcoded as 'entity has type foo', which makes them directly equivalent to the types used in languages such as Java, with all the same issues. There's no fundamental reason you need to do this though, with an extension into generalised descriptions you should be able to say 'entity is represented by collection of sequences which are related by...'. The key is to stop thinking of semantic types as being a lazy way of growing an object heirarchy and actually take advantage of their full expressive power. I can appreciate a desire to keep things simple but we have a clear case here where we need something a bit smarter. Could someone, for example Phil, who actually knows what they're talking about on these lists perhaps give an example of how this would look in RDF? I know it's possible to do but a concrete example might be helpful and I don't have the required knowledge. Tom From tmo at ebi.ac.uk Thu Aug 4 06:07:28 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu Aug 4 05:56:04 2005 Subject: [Taverna-users] Re: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1E7E7.3060109@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> <1123147448.42f1deb87303f@webmail.illuminae.com> <42F1E7E7.3060109@ebi.ac.uk> Message-ID: <42F1E8E0.6050102@ebi.ac.uk> Tom Oinn wrote: > Could someone, for example Phil, who actually knows what they're talking > about on these lists perhaps give an example of how this would look in > RDF? Um, that wasn't meant to imply that anyone doesn't know what they're talking about - sounded a bit harsh on re-reading! It would be good to have some input from the mygrid semantics folks though especially as this issue is directly related to the description of services and therefore the mygrid registry activities. Tom From p.lord at cs.man.ac.uk Thu Aug 4 12:17:28 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Thu Aug 4 12:07:39 2005 Subject: [Taverna-users] Re: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1E7E7.3060109@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> <1123147448.42f1deb87303f@webmail.illuminae.com> <42F1E7E7.3060109@ebi.ac.uk> Message-ID: >>>>> "Tom" == Tom Oinn writes: Tom> Could someone, for example Phil, who actually knows what Tom> they're talking about on these lists perhaps give an example of Tom> how this would look in RDF? I know it's possible to do but a Tom> concrete example might be helpful and I don't have the required Tom> knowledge. I'm not sure that I would make any claims to be the worlds greatest expert on RDF. Actually, I would make claims to not be any kind of expert on RDF. You can certainly express the notion of a collection in RDF. You can put semantic types onto any of the nodes underneath this, and there is very little restriction as to what the types of these things can be. You can state that for a rdf:bag that the first is a dna sequence, the next a protein or whatever. The rdf looks something like a ---- has type ---> bag a ---- li ----> b a ---- li ----> c b ---- hastype -----> dna sequence b ---- hasvalue -----> "GATC" c ---- hastype ---> protein sequence c ---- hasvalue ---> "MAGSYDJ" If you want this level of complexity in moby-s messages then there is no particular problem within representing it in the XML, at least as far as I can see. The problem comes from querying, because people are likely to want to query for services which consume, for example, "DNASequence, or some collection which recursively contains a DNA sequence". Neither moby-central nor feta are going to be terribly happy with performing this sort of query. Phil From bgulden at purdue.edu Thu Aug 4 14:08:12 2005 From: bgulden at purdue.edu (bgulden@purdue.edu) Date: Thu Aug 4 13:58:15 2005 Subject: [MOBY-l] Submitting Parameters Message-ID: <1123178892.42f2598c4e9bf@webmail.purdue.edu> First, I just wanted to thank you all for helping with my previous problems with parameters (The ->secondary function worked perfectly). Now on to my current dilemma. Is there a special way to include parameters in the execution of Moby services? According to the perl API services with parameters should be called in this format where input1 is a primary input and param1 is a secondary input: $Service->execute(XMLinputlist => [ [ 'input1', '', 'param1', '0.001', ] ]); However, when I check the actual inputted data to my service I end up with one tag around both input1 and param1. Thanks, Brian From d.haase at gsf.de Fri Aug 5 04:18:41 2005 From: d.haase at gsf.de (Dirk Haase) Date: Fri Aug 5 04:12:11 2005 Subject: [MOBY-l] Submitting Parameters In-Reply-To: <1123178892.42f2598c4e9bf@webmail.purdue.edu> References: <1123178892.42f2598c4e9bf@webmail.purdue.edu> Message-ID: <200508051018.41494.d.haase@gsf.de> On Thursday 04 August 2005 20:08, bgulden@purdue.edu wrote: > First, I just wanted to thank you all for helping with my previous problems > with parameters (The ->secondary function worked perfectly). Now on to my > current dilemma. > > Is there a special way to include parameters in the execution of Moby > services? According to the perl API services with parameters should be > called in this format where input1 is a primary input and param1 is a > secondary input: $Service->execute(XMLinputlist => [ > [ > 'input1', '', > 'param1', '0.001', > ] > ]); > > However, when I check the actual inputted data to my service I end up with > one tag around both input1 and param1. Hmm, your code seems correct, should actually work... Are you sure the service is correctly registered? Regards, dirk -- ---------------------------------------------------------- Dirk Haase phone +49 89 3187 3583 http://mips.gsf.de/~haase email d.haase@gsf.de From markw at illuminae.com Fri Aug 5 04:28:18 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Fri Aug 5 04:19:15 2005 Subject: [MOBY-l] Submitting Parameters In-Reply-To: <200508051018.41494.d.haase@gsf.de> References: <1123178892.42f2598c4e9bf@webmail.purdue.edu> <200508051018.41494.d.haase@gsf.de> Message-ID: <1123230498.42f323223100a@webmail.illuminae.com> There is a known bug in the current production code relating to the registration of parameters - if any of them have a default, a min, or a max of "0", the registration of that parameter will fail, but the service registration will succeed. This might be what he is seeing. :-/ It is fixed in the new codebase, but we wont be updating the production server for a week or two. M Quoting Dirk Haase : > On Thursday 04 August 2005 20:08, bgulden@purdue.edu wrote: > > First, I just wanted to thank you all for helping with my previous problems > > with parameters (The ->secondary function worked perfectly). Now on to my > > current dilemma. > > > > Is there a special way to include parameters in the execution of Moby > > services? According to the perl API services with parameters should be > > called in this format where input1 is a primary input and param1 is a > > secondary input: $Service->execute(XMLinputlist => [ > > [ > > 'input1', ' id="123"/>', > > 'param1', '0.001', > > ] > > ]); > > > > However, when I check the actual inputted data to my service I end up with > > one tag around both input1 and param1. > > Hmm, your code seems correct, should actually work... Are you sure the > service is correctly registered? > > Regards, > dirk > > -- > > ---------------------------------------------------------- > Dirk Haase phone +49 89 3187 3583 > http://mips.gsf.de/~haase email d.haase@gsf.de > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From edward.kawas at gmail.com Mon Aug 8 09:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon Aug 8 09:33:30 2005 Subject: [MOBY-l] RE: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users@lists.sourceforge.net; moby- > l@biomoby.org; mobydev; taverna- > hackers@lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: > jmfernandez@cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 > 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of > Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) From fgibbons at hms.harvard.edu Wed Aug 10 11:37:14 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Aug 10 11:21:30 2005 Subject: [MOBY-l] Trouble-ticketing for MOBY; unwanted side effect of MOBY::Client::Service->execute Message-ID: <5.2.1.1.2.20050810112754.011101f8@email.med.harvard.edu> Hi, Two related items: I think MOBY::Client::Service->execute has an unwanted side-effect in that the XMLinputlist argument appears to be modified upon returning from this function. The code does some editing on it. I don't think that would have been a problem had XMLinputlist been passed in as a scalar, but it's passed as an ARRAY ref, and so modifications to it are propagated back to the calling code. This is a problem if, like me, you want to iterate over services calling each one with the same XMLinputlist. (At least, I think that's what's happening - correct me.) How do we fix something like this? Are there regression tests to make sure nothing gets broken when this issue is tackled? Who fixes it? (I'll volunteer) The issue of how to fix this raises the other item: while MOBY is under CVS control, there's no ticketing system (that I'm aware of). As a long-time lurker on this list, I know that most issues just get posted to the list, and then fixed. I think there are a lot advantages to having a centralized, non-email-based record of what needs to be fixed in the future, but also of what was fixed in the past. I'm wondering partly why MOBY isn't on SourceForge (which has a ticketing system for bugs and feature requests, so that potential users can not only see what issues have been fixed, but also what features are likely to appear in the future) - if this has been discussed in the past and resolved, I'd appreciate a pointer. Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Aug 11 12:37:03 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed Aug 10 11:27:20 2005 Subject: [MOBY-l] Trouble-ticketing for MOBY; unwanted side effect ofMOBY::Client::Service->execute Message-ID: <969787678-1123688248-cardhu_blackberry.rim.net-5970-@engine13-cell01> Hi Frank, Two quick responses (I'm on the blackberry and it isn't very efficient :-) ) 1). The execute method will shortly be significantly changed in light of the upcoming API changes (esp. Insistence on named parameters allows me to use a more sensible "hash" structure in place of the list structure). I don't know if it is worth spending time fixing it. 2). I didn't realize that my code modified the input list. You're right, this is bad. I could post a fix for the such that the input listref is cloned to avoid this (if that is the root of the problem), or you are of course always welcome to fix it yourself and commit. 3). We do have a ticketing system, but nobody ever uses it :-). Click the "bugs" link on the left side of the homepage... I haven't tested it for a while, but it worked last time I tried... Cheers! M -----Original Message----- From: Frank Gibbons Date: Wed, 10 Aug 2005 11:37:14 To:moby-l@biomoby.org Subject: [MOBY-l] Trouble-ticketing for MOBY; unwanted side effect of MOBY::Client::Service->execute Hi, Two related items: I think MOBY::Client::Service->execute has an unwanted side-effect in that the XMLinputlist argument appears to be modified upon returning from this function. The code does some editing on it. I don't think that would have been a problem had XMLinputlist been passed in as a scalar, but it's passed as an ARRAY ref, and so modifications to it are propagated back to the calling code. This is a problem if, like me, you want to iterate over services calling each one with the same XMLinputlist. (At least, I think that's what's happening - correct me.) How do we fix something like this? Are there regression tests to make sure nothing gets broken when this issue is tackled? Who fixes it? (I'll volunteer) The issue of how to fix this raises the other item: while MOBY is under CVS control, there's no ticketing system (that I'm aware of). As a long-time lurker on this list, I know that most issues just get posted to the list, and then fixed. I think there are a lot advantages to having a centralized, non-email-based record of what needs to be fixed in the future, but also of what was fixed in the past. I'm wondering partly why MOBY isn't on SourceForge (which has a ticketing system for bugs and feature requests, so that potential users can not only see what issues have been fixed, but also what features are likely to appear in the future) - if this has been discussed in the past and resolved, I'd appreciate a pointer. Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson ...on the road! From p.lord at cs.man.ac.uk Mon Aug 15 05:35:58 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Mon Aug 15 05:27:35 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <87y873v8xt.fsf@rpc71.cs.man.ac.uk> >>>>> "Boris" == Boris Steipe writes: Boris> Why not put the burden of the lease on the agent to combine Boris> the advantages of both models? I.e. if service is down for Boris> less then a specific time, it might not get deregistered but Boris> only flagged as temporarily unavailable ... then un-flagged Boris> as it comes up again, except if it's down for, say > 1week, Boris> then it gets deregistered. Boris> $0.02 Actually, this is just a modification of the agent idea, and not a lease at all. The idea of a lease is not just a burden on the service provide, but it also has a positive advantage. It give the service provide the ability to control how long they want the service advertised for in the registry. Of course, they can do the same thing with the agent, more or less; they just remove the RDF document after a certain time, although, they don't know exactly when the agent will remove them. At the end of the day, I am not sure that the two mechanisms are hugely different in terms of their functionality. It seems to me that the lease puts slightly more weight on the service provider, but will provide better garbage collection (just become someone leaves an RDF document on the web, does not mean that their service is actually still up). Phil From p.lord at cs.man.ac.uk Mon Aug 15 05:38:32 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Mon Aug 15 05:28:48 2005 Subject: [MOBY-l] Re: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> >>>>> "Mark" == Mark Wilkinson writes: Mark> We're certainly of like-mind at this end, though certain Mark> people ;-) at myGrid think that the agent is the wrong way to Mark> go... I just don't see it. IMO a leasing model would be akin Mark> to leasing space in Google! The lease is the more common idiom, I think. I don't think that there is a huge difference. My main criticism of the agent is that there does not seem to be a different connection between the agent poll and the service being available. Phil From tmo at ebi.ac.uk Mon Aug 15 05:51:26 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon Aug 15 05:38:44 2005 Subject: [MOBY-l] Re: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> Message-ID: <4300659E.3050808@ebi.ac.uk> Phillip Lord wrote: >>>>>>"Mark" == Mark Wilkinson writes: > > > Mark> We're certainly of like-mind at this end, though certain > Mark> people ;-) at myGrid think that the agent is the wrong way to > Mark> go... I just don't see it. IMO a leasing model would be akin > Mark> to leasing space in Google! > > The lease is the more common idiom, I think. I don't think that there > is a huge difference. My main criticism of the agent is that there > does not seem to be a different connection between the agent poll and > the service being available. Much as I hate* to agree with Phil I, um, do :) Seems to me that the agent approach is more part of a monitoring framework than a registry, I don't know offhand whether we're planning to include metrics such as service liveness and response times as transient metadata in the registry but that's where I'd see agents fitting in rather than in the initial registration. Tom * it's all an act but hey... From p.lord at cs.man.ac.uk Mon Aug 15 06:00:53 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Mon Aug 15 05:50:35 2005 Subject: [MOBY-l] Re: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4300659E.3050808@ebi.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> <4300659E.3050808@ebi.ac.uk> Message-ID: <87k6inv7sa.fsf@rpc71.cs.man.ac.uk> >>>>> "Tom" == Tom Oinn writes: Tom> Phillip Lord wrote: >>>>>>> "Mark" == Mark Wilkinson writes: Mark> We're certainly of like-mind at this end, though certain Mark> people ;-) at myGrid think that the agent is the wrong way to Mark> go... I just don't see it. IMO a leasing model would be akin Mark> to leasing space in Google! >> The lease is the more common idiom, I think. I don't think that >> there is a huge difference. My main criticism of the agent is >> that there does not seem to be a different connection between the >> agent poll and the service being available. Tom> Much as I hate* to agree with Phil I, um, do :) Seems to me Tom> that the agent approach is more part of a monitoring framework It might be if it monitored the service rather than something else! Tom> than a registry, I don't know offhand whether we're planning to Tom> include metrics such as service liveness and response times as Tom> transient metadata in the registry but that's where I'd see Tom> agents fitting in rather than in the initial registration. The current approach that feta takes to the "registry" is that it is a very dumb thing. It really only uses it for storing files (which is why it uses a webdav backend by default). It would be lovely to replace or augment this with something richer, which understood liveness and response. Or, alternatively, have a modular search system which could combine responses from feta and some arbitrary service search system based on information about liveness. It's all very feasible. Even a simple minded response time data model would help a lot. Phil From gordonp at ucalgary.ca Mon Aug 15 10:32:26 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon Aug 15 10:23:51 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87y873v8xt.fsf@rpc71.cs.man.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> Message-ID: <4300A77A.8030806@ucalgary.ca> A few advantages of the lease are not really advantages in practice: 1. No one will manually update their lease, they will put it in a cron job. Therefore you either need to edit your crontab, or remove from the RDF file in the agent case. Both are just as likely to be ignored by an administrator when a service stops working. 2. Specifiying that the service is valid for a certain amount of time is mostly useful for testing purposes. You should really be using a test registry in that case, not posting dubious services to the production server. The chief advantages of the agent are: 1. You can trace the registration and deregistration of a service to a particular domain name. It's not great security, but at the very least people require some serious work to pose as the NCBI on purpose (by hacking their Web domain), and cannot by mistake (e.g. "I registered my service using the NCBI authority ID because I'm using gi's"). 2. The RDF for the services does not have a single point of failure (i.e. the central registry). The one agent feature I would l;ike though is that I can call MOBY Central to tell it that I've changed my RDF, i.e. pushing a refresh. It's not critical though. If the agent runs once a day, you may get some latency on bad services, but it's not the end of the world. Tim Berners-Lee got a lot of flack for his Web idea because it didn't enforce that what people linked to existed. "People won't use it, they may end up at dead links!" they said... >>>>>>"Boris" == Boris Steipe writes: >>>>>> >>>>>> > > Boris> Why not put the burden of the lease on the agent to combine > Boris> the advantages of both models? I.e. if service is down for > Boris> less then a specific time, it might not get deregistered but > Boris> only flagged as temporarily unavailable ... then un-flagged > Boris> as it comes up again, except if it's down for, say > 1week, > Boris> then it gets deregistered. > > Boris> $0.02 > > >Actually, this is just a modification of the agent idea, and not a >lease at all. > >The idea of a lease is not just a burden on the service provide, but >it also has a positive advantage. It give the service provide the >ability to control how long they want the service advertised for in >the registry. Of course, they can do the same thing with the agent, >more or less; they just remove the RDF document after a certain time, >although, they don't know exactly when the agent will remove them. > >At the end of the day, I am not sure that the two mechanisms are >hugely different in terms of their functionality. It seems to me that >the lease puts slightly more weight on the service provider, but will >provide better garbage collection (just become someone leaves an RDF >document on the web, does not mean that their service is actually >still up). > >Phil > >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From jmfernandez at cnb.uam.es Fri Aug 5 15:10:00 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon Aug 15 11:29:29 2005 Subject: [MOBY-l] A bug in Taverna 1.2 perhaps related to BioMOBY Message-ID: <42F3B988.7020506@cnb.uam.es> Hi everybody, I don't like crossposting, but I don't know if the bug I have found today is from the Taverna 1.2 core or the MOBY plugin. The bug is pretty simple: if you create/load a workflow which has a service whose name in the workflow is different from the service name, Taverna does not use the official service name when it is invoked. Instead, it uses the name given to the service in the workflow! The same workflow works flawlessly when it is loaded and run in Taverna 1.1. I have discovered the bug with a MOBY service (see the sample workflow ja5.xml, and the reports taverna-1.1-report.xml and taverna-1.2-report.xml), so I don't know which has the blame... This bug should arise when one service is used more than once, which is very common in real workflows! Best Regards, Jos? Mar?a Fern?ndez -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From p.lord at cs.man.ac.uk Tue Aug 16 06:02:52 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Tue Aug 16 05:52:33 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4300A77A.8030806@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> Message-ID: <87mzni8aib.fsf@rpc71.cs.man.ac.uk> >>>>> "Paul" == Paul Gordon writes: Paul> A few advantages of the lease are not really advantages in Paul> practice: Paul> 1. No one will manually update their lease, they will put it Paul> in a cron Paul> job. Therefore you either need to edit your crontab, or Paul> remove from the RDF file in the agent case. Both are just as Paul> likely to be ignored by an administrator when a service stops Paul> working. This is a necessary problem with neither the agent nor the lease. It is a current problem with the implementation of the agent. All you do is add a call back to the service. Paul> 2. Specifiying that the service is valid for a certain amount Paul> of time Paul> is mostly useful for testing purposes. You should really be Paul> using a test registry in that case, not posting dubious Paul> services to the production server. Not really. Take, for example, the SOAPLAB services Martin developed as part of mygrid. When the toolkit was first produced, it was deployed on our own servers; now it is supported by EBI's external services. Clearly, the latter is likely to produce a better uptime than the former. Hence, EBI might use a month long lease. Neither of these services were testing. But they did come with different levels of support. Paul> The chief advantages of the agent are: Paul> 1. You can trace the registration and deregistration of a Paul> service to Paul> a particular domain name. It's not great security, but at the Paul> very least people require some serious work to pose as the Paul> NCBI on purpose (by hacking their Web domain), and cannot by Paul> mistake (e.g. "I registered my service using the NCBI Paul> authority ID because I'm using gi's"). Likewise with a lease call back system. Anyway, can you really not determine the start point of a web services call? Paul> 2. The RDF for the services does not have a single point of Paul> failure Paul> (i.e. the central registry). This is also untrue. There is nothing to stop a lease percolating through a set of federated registries. With the agent, you have to percolate the registered URL's (or the RDF) in the same way. Ultimately, as two systems are doing similar things. It's just that one is push and the other pull. Paul> The one agent feature I would l;ike though is that I can call Paul> MOBY Central to tell it that I've changed my RDF, i.e. pushing Paul> a refresh. It's not critical though. If the agent runs once a Paul> day, you may get some latency on bad services, but it's not Paul> the end of the world. Tim Berners-Lee got a lot of flack for Paul> his Web idea because it didn't enforce that what people linked Paul> to existed. "People won't use it, they may end up at dead Paul> links!" they said... You still want people to be able to search on the freshness of information though. With a lease, you can add queries to moby-central to say "give me only services with a current lease"--after all the registry is not required to deregister a service when it's lease runs out. Cheers Phil From gordonp at ucalgary.ca Tue Aug 16 09:51:08 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue Aug 16 09:53:12 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87mzni8aib.fsf@rpc71.cs.man.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> Message-ID: <4301EF4C.5020506@ucalgary.ca> My CAN$0.02 :-) > > Paul> A few advantages of the lease are not really advantages in > Paul> practice: > > Paul> 1. No one will manually update their lease, they will put it > Paul> in a cron > Paul> job. Therefore you either need to edit your crontab, or > Paul> remove from the RDF file in the agent case. Both are just as > Paul> likely to be ignored by an administrator when a service stops > Paul> working. > > >This is a necessary problem with neither the agent nor the lease. It >is a current problem with the implementation of the agent. All you do >is add a call back to the service. > > This turns into an issue with the protocol, we would need to require (when you register a service) test cases that return predictable, non-null value. This was discussed at the last MOBY meeting, but I don't think anything came of it. Or am I wrong? > Paul> The chief advantages of the agent are: > > Paul> 1. You can trace the registration and deregistration of a > Paul> service to > Paul> a particular domain name. It's not great security, but at the > Paul> very least people require some serious work to pose as the > Paul> NCBI on purpose (by hacking their Web domain), and cannot by > Paul> mistake (e.g. "I registered my service using the NCBI > Paul> authority ID because I'm using gi's"). > >Likewise with a lease call back system. > Like you said, the two approches aren't so different, because fetching the RDF from the server is a callback of sorts. >Anyway, can you really not >determine the start point of a web services call? > > If there are proxies, multiple host names for a machine (e.g. the host I'm on right now is www.visualgenomics.ca, moby.ucalgary.ca, www.gcbioinformatics.ca, and about 6 other names), it can get complicated. > Paul> 2. The RDF for the services does not have a single point of > Paul> failure > Paul> (i.e. the central registry). > >This is also untrue. There is nothing to stop a lease percolating >through a set of federated registries. With the agent, you have to >percolate the registered URL's (or the RDF) in the same way. > > True, but the mechanism to exchange a URL list could be simpler than mirroring the entire registry, and is less subject to error propagation (e.g. don't blindly copy a goof in the main mirror's database system because it had network connectivity issues, fetch the RDF yourself) . If we're lucky, people will try to outcompete each other creating the most robust registry :-) >Ultimately, as two systems are doing similar things. It's just that >one is push and the other pull. > > > Paul> The one agent feature I would l;ike though is that I can call > Paul> MOBY Central to tell it that I've changed my RDF, i.e. pushing > Paul> a refresh. It's not critical though. If the agent runs once a > Paul> day, you may get some latency on bad services, but it's not > Paul> the end of the world. Tim Berners-Lee got a lot of flack for > Paul> his Web idea because it didn't enforce that what people linked > Paul> to existed. "People won't use it, they may end up at dead > Paul> links!" they said... > > >You still want people to be able to search on the freshness of >information though. With a lease, you can add queries to moby-central >to say "give me only services with a current lease"--after all the >registry is not required to deregister a service when it's lease runs >out. > > Would we set a maximum lease? I'd probably give myself a 1 year lease so that I wouldn't be bothered again. That doesn't make me check that the service works throughout the year though. IMHO, having a test case checked regularly is what really helps here, not the lease. A lease is someone's word, a test case is action, and actions speak louder than words :-) >Cheers > >Phil > >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From edward.kawas at gmail.com Tue Aug 16 12:26:42 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue Aug 16 12:16:35 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4301EF4C.5020506@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> Message-ID: I just wanted to say that I agree with Paul. I think that when a provider registers a service, the provider enters a url that causes the service to return something that is commonly returned by all services that states that the service is running. If this return value is infact returned, then the service signature is processed. Otherwise, the offending service is recorded and the service is not shown to the public until the test passes. If after x times the test fails, then it is permanently removed. Eddie On 8/16/05, Paul Gordon wrote: > My CAN$0.02 :-) > > > > > Paul> A few advantages of the lease are not really advantages in > > Paul> practice: > > > > Paul> 1. No one will manually update their lease, they will put it > > Paul> in a cron > > Paul> job. Therefore you either need to edit your crontab, or > > Paul> remove from the RDF file in the agent case. Both are just as > > Paul> likely to be ignored by an administrator when a service stops > > Paul> working. > > > > > >This is a necessary problem with neither the agent nor the lease. It > >is a current problem with the implementation of the agent. All you do > >is add a call back to the service. > > > > > This turns into an issue with the protocol, we would need to require > (when you register a service) test cases that return predictable, > non-null value. This was discussed at the last MOBY meeting, but I > don't think anything came of it. Or am I wrong? > > > Paul> The chief advantages of the agent are: > > > > Paul> 1. You can trace the registration and deregistration of a > > Paul> service to > > Paul> a particular domain name. It's not great security, but at the > > Paul> very least people require some serious work to pose as the > > Paul> NCBI on purpose (by hacking their Web domain), and cannot by > > Paul> mistake (e.g. "I registered my service using the NCBI > > Paul> authority ID because I'm using gi's"). > > > >Likewise with a lease call back system. > > > Like you said, the two approches aren't so different, because fetching > the RDF from the server is a callback of sorts. > > >Anyway, can you really not > >determine the start point of a web services call? > > > > > If there are proxies, multiple host names for a machine (e.g. the host > I'm on right now is www.visualgenomics.ca, moby.ucalgary.ca, > www.gcbioinformatics.ca, and about 6 other names), it can get complicated. > > > Paul> 2. The RDF for the services does not have a single point of > > Paul> failure > > Paul> (i.e. the central registry). > > > >This is also untrue. There is nothing to stop a lease percolating > >through a set of federated registries. With the agent, you have to > >percolate the registered URL's (or the RDF) in the same way. > > > > > True, but the mechanism to exchange a URL list could be simpler than > mirroring the entire registry, and is less subject to error propagation > (e.g. don't blindly copy a goof in the main mirror's database system > because it had network connectivity issues, fetch the RDF yourself) . > If we're lucky, people will try to outcompete each other creating the > most robust registry :-) > > >Ultimately, as two systems are doing similar things. It's just that > >one is push and the other pull. > > > > > > Paul> The one agent feature I would l;ike though is that I can call > > Paul> MOBY Central to tell it that I've changed my RDF, i.e. pushing > > Paul> a refresh. It's not critical though. If the agent runs once a > > Paul> day, you may get some latency on bad services, but it's not > > Paul> the end of the world. Tim Berners-Lee got a lot of flack for > > Paul> his Web idea because it didn't enforce that what people linked > > Paul> to existed. "People won't use it, they may end up at dead > > Paul> links!" they said... > > > > > >You still want people to be able to search on the freshness of > >information though. With a lease, you can add queries to moby-central > >to say "give me only services with a current lease"--after all the > >registry is not required to deregister a service when it's lease runs > >out. > > > > > Would we set a maximum lease? I'd probably give myself a 1 year lease > so that I wouldn't be bothered again. That doesn't make me check that > the service works throughout the year though. IMHO, having a test case > checked regularly is what really helps here, not the lease. A lease is > someone's word, a test case is action, and actions speak louder than > words :-) > > >Cheers > > > >Phil > > > >_______________________________________________ > >moby-l mailing list > >moby-l@biomoby.org > >http://biomoby.org/mailman/listinfo/moby-l > > > > > > > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From p.lord at cs.man.ac.uk Tue Aug 16 13:15:29 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Tue Aug 16 13:06:36 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4301EF4C.5020506@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> Message-ID: <87ek8tpzv2.fsf@rpc71.cs.man.ac.uk> >>>>> "Paul" == Paul Gordon writes: >> This is a necessary problem with neither the agent nor the >> lease. It is a current problem with the implementation of the >> agent. All you do is add a call back to the service. Paul> This turns into an issue with the protocol, we would need to Paul> require (when you register a service) test cases that return Paul> predictable, non-null value. This was discussed at the last Paul> MOBY meeting, but I don't think anything came of it. Or am I Paul> wrong? I can't comment on this really, because I wasn't there! Paul> 1. You can trace the registration and deregistration of a Paul> service to a particular domain name. It's not great security, Paul> but at the very least people require some serious work to pose Paul> as the NCBI on purpose (by hacking their Web domain), and Paul> cannot by mistake (e.g. "I registered my service using the Paul> NCBI authority ID because I'm using gi's"). >> >> Likewise with a lease call back system. Paul> Like you said, the two approches aren't so different, because Paul> fetching the RDF from the server is a callback of sorts. In a sense. It's just that you don't know when it is going to happen. This is the point with a lease. The client requests from the server a time limited registration. Is it possible for the client to query MOBY-Central and ask how often the RDF agent will call? Is it possible to request that it happens more frequently or less? >> Anyway, can you really not determine the start point of a web >> services call? Paul> If there are proxies, multiple host names for a machine Paul> (e.g. the host I'm on right now is www.visualgenomics.ca, Paul> moby.ucalgary.ca, www.gcbioinformatics.ca, and about 6 other Paul> names), it can get complicated. Or 136.159.169.6 or h6.net169.ucalgary.ca. The IP number is unique though. Paul> 2. The RDF for the services does not have a single point of Paul> failure (i.e. the central registry). >> >> This is also untrue. There is nothing to stop a lease percolating >> through a set of federated registries. With the agent, you have >> to percolate the registered URL's (or the RDF) in the same way. Paul> True, but the mechanism to exchange a URL list could be Paul> simpler than mirroring the entire registry, and is less Paul> subject to error propagation (e.g. don't blindly copy a goof Paul> in the main mirror's database system because it had network Paul> connectivity issues, fetch the RDF yourself) . If we're Paul> lucky, people will try to outcompete each other creating the Paul> most robust registry :-) Who says that the lease is not encoded as a URL? Besides which, the lease mechanism might federate by passing around data. Or the client might explicitly register in more than one registry. Again, I don't think that this is a necessary advantage of either a lease or the agent. >> You still want people to be able to search on the freshness of >> information though. With a lease, you can add queries to >> moby-central to say "give me only services with a current >> lease"--after all the registry is not required to deregister a >> service when it's lease runs out. Paul> Would we set a maximum lease? I'd probably give myself a 1 Paul> year lease so that I wouldn't be bothered again. Yes, this is part of the basic idea behind a lease. The registry overs a specific contract which describes what it is prepared to do for you. Paul> That doesn't make me check that the service works throughout Paul> the year though. IMHO, having a test case checked regularly is Paul> what really helps here, not the lease. A lease is someone's Paul> word, a test case is action, and actions speak louder than Paul> words :-) As Tom says, service liveness or quality data is not the same thing as registration, but an orthogonal issue to it. Having service quality data would be a nice addition to moby-central. Phil From goodb at interchange.ubc.ca Tue Aug 16 13:18:47 2005 From: goodb at interchange.ubc.ca (Benjamin Good) Date: Tue Aug 16 13:16:51 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> Message-ID: <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> Just to add my 2c. The idea of adding a test case to the registration phase did come up at the meeting, but I'm not sure how far its gotten? I would suggest that this test actually be an instance of the moby datatype registered as the input of the service - instead of a URL. This would let any moby-capable client test the service whenever necessary using exactly the same protocol required to run the service in the usual case. Having this possibility makes it feasible for client providers to filter out inconsistent services without relying entirely on the registry to do so. This enables a runtime check on the service that seems impossible using only the registry. The agent could then use this same check to make its decision about whether to keep the service listed or not.. - Ben On Aug 16, 2005, at 9:26 AM, Eddie Kawas wrote: > I just wanted to say that I agree with Paul. > > I think that when a provider registers a service, the provider enters > a url that causes the service to return something that is commonly > returned by all services that states that the service is running. If > this return value is infact returned, then the service signature is > processed. Otherwise, the offending service is recorded and the > service is not shown to the public until the test passes. If after x > times the test fails, then it is permanently removed. > > Eddie > > > On 8/16/05, Paul Gordon wrote: > >> My CAN$0.02 :-) >> >> >>> >>> Paul> A few advantages of the lease are not really advantages in >>> Paul> practice: >>> >>> Paul> 1. No one will manually update their lease, they will put it >>> Paul> in a cron >>> Paul> job. Therefore you either need to edit your crontab, or >>> Paul> remove from the RDF file in the agent case. Both are just as >>> Paul> likely to be ignored by an administrator when a service stops >>> Paul> working. >>> >>> >>> This is a necessary problem with neither the agent nor the lease. It >>> is a current problem with the implementation of the agent. All >>> you do >>> is add a call back to the service. >>> >>> >>> >> This turns into an issue with the protocol, we would need to require >> (when you register a service) test cases that return predictable, >> non-null value. This was discussed at the last MOBY meeting, but I >> don't think anything came of it. Or am I wrong? >> >> >>> Paul> The chief advantages of the agent are: >>> >>> Paul> 1. You can trace the registration and deregistration of a >>> Paul> service to >>> Paul> a particular domain name. It's not great security, but at >>> the >>> Paul> very least people require some serious work to pose as the >>> Paul> NCBI on purpose (by hacking their Web domain), and cannot by >>> Paul> mistake (e.g. "I registered my service using the NCBI >>> Paul> authority ID because I'm using gi's"). >>> >>> Likewise with a lease call back system. >>> >>> >> Like you said, the two approches aren't so different, because >> fetching >> the RDF from the server is a callback of sorts. >> >> >>> Anyway, can you really not >>> determine the start point of a web services call? >>> >>> >>> >> If there are proxies, multiple host names for a machine (e.g. the >> host >> I'm on right now is www.visualgenomics.ca, moby.ucalgary.ca, >> www.gcbioinformatics.ca, and about 6 other names), it can get >> complicated. >> >> >>> Paul> 2. The RDF for the services does not have a single point of >>> Paul> failure >>> Paul> (i.e. the central registry). >>> >>> This is also untrue. There is nothing to stop a lease percolating >>> through a set of federated registries. With the agent, you have to >>> percolate the registered URL's (or the RDF) in the same way. >>> >>> >>> >> True, but the mechanism to exchange a URL list could be simpler than >> mirroring the entire registry, and is less subject to error >> propagation >> (e.g. don't blindly copy a goof in the main mirror's database system >> because it had network connectivity issues, fetch the RDF yourself) . >> If we're lucky, people will try to outcompete each other creating the >> most robust registry :-) >> >> >>> Ultimately, as two systems are doing similar things. It's just that >>> one is push and the other pull. >>> >>> >>> Paul> The one agent feature I would l;ike though is that I can call >>> Paul> MOBY Central to tell it that I've changed my RDF, i.e. >>> pushing >>> Paul> a refresh. It's not critical though. If the agent runs once a >>> Paul> day, you may get some latency on bad services, but it's not >>> Paul> the end of the world. Tim Berners-Lee got a lot of flack for >>> Paul> his Web idea because it didn't enforce that what people >>> linked >>> Paul> to existed. "People won't use it, they may end up at dead >>> Paul> links!" they said... >>> >>> >>> You still want people to be able to search on the freshness of >>> information though. With a lease, you can add queries to moby- >>> central >>> to say "give me only services with a current lease"--after all the >>> registry is not required to deregister a service when it's lease >>> runs >>> out. >>> >>> >>> >> Would we set a maximum lease? I'd probably give myself a 1 year >> lease >> so that I wouldn't be bothered again. That doesn't make me check >> that >> the service works throughout the year though. IMHO, having a test >> case >> checked regularly is what really helps here, not the lease. A >> lease is >> someone's word, a test case is action, and actions speak louder than >> words :-) >> >> >>> Cheers >>> >>> Phil >>> >>> _______________________________________________ >>> moby-l mailing list >>> moby-l@biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-l >>> >>> >>> >>> >> >> _______________________________________________ >> moby-l mailing list >> moby-l@biomoby.org >> http://biomoby.org/mailman/listinfo/moby-l >> >> > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > > From markw at illuminae.com Tue Aug 16 13:36:25 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Aug 16 13:45:38 2005 Subject: [moby] Re: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> Message-ID: <1124213785.18621.138.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-08-16 at 10:18 -0700, Benjamin Good wrote: > Just to add my 2c. The idea of adding a test case to the > registration phase did come up at the meeting, but I'm not sure how > far its gotten? It was decided that test cases would be provided as optional additional metadata attached to the RDF Service Signature on the service-providers site, identified by a set of (yet to be defined) RDF predicates. Test cases would *not* be part of the data stored in the registry, but would be discoverable through e.g. LSID resolution. Since we are currently in the process of adapting our Service Signature data model to mimic that of myGrid (and v.v. :-) ) we have not yet implemented this particular decision. Hopefully this data model will be firmed-up in the next couple of weeks (that was why Eddie and I were in Manchester last week), and then we will be able to generate a "canonical" Service Signature for everyone's existing services, as well as generate the signature on-the-fly for new registrations. M -- "Ontologists do it with the edges!" 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 From senger at ebi.ac.uk Tue Aug 16 20:10:24 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Aug 16 20:01:13 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> Message-ID: Hi all, Everybody is talking about lease and agents so if I do not join I would feel like a pariah... What was the original problem that started this discussion? I remember two: a) How to make a deregistration secure (so nobody can easily remove my service from a registry), and b) How I can remove my service registration at any time when I *want* to do it. Am I right - is this (at least) the problems we are trying to solve? (I understand that during this discussion a new problem was born - how to test that a service is reliable; but I consider it as a separate issue.) Obviously problem b) requires an action on my side. In case of agent it is a removal of an RDF document - and hopefully supported by a new method in the registry API calling an agent to come to me *now*. This new API call was mentioned and I hope it will happen. Without it the agent solution is weak (IMHO) - having the similar weakness as Google has with non existing links/documents (oh, wow, now I really feel like a pariah by saying that Google has a weakness!) In case of lease - is there a concept of making a lease to expire before its planned end? If so, how is it done that nobody else can do it except me (problem a))? Can you, Phill perhaps, explain me if the lease can solve my two problems above? So far I understand that an agent can - assuming tghat there will be that new API call (Mark, Eddie, will this be - in case the agent idea is accepted?) Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From p.lord at cs.man.ac.uk Wed Aug 17 06:23:18 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Wed Aug 17 06:18:31 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: References: Message-ID: <87vf246ew9.fsf@rpc71.cs.man.ac.uk> >>>>> "Martin" == Martin Senger writes: Martin> Hi all, Martin> Everybody is talking about lease and agents so if I do Martin> not join I would Martin> feel like a pariah... Martin> What was the original problem that started this Martin> discussion? I remember Martin> two: Martin> a) How to make a deregistration secure (so nobody can easily Martin> remove my Martin> service from a registry), and Martin> b) How I can remove my service registration at any time when Martin> I *want* Martin> to do it. Martin> Am I right - is this (at least) the problems we are Martin> trying to solve? (I Martin> understand that during this discussion a new problem was Martin> born - how to test that a service is reliable; but I Martin> consider it as a separate issue.) Martin> Obviously problem b) requires an action on my side. In Martin> case of agent it is a removal of an RDF document - and Martin> hopefully Martin> supported by a new method in the registry API calling an Martin> agent to come to me *now*. This new API call was mentioned Martin> and I hope it will happen. Actually, there is a minor security problem here. If I call this method repeatedly and it really happens *now*, then I can use moby-central as a proxy to launch a denial of service attack on a third party. If I did this on NCBI, for example, it might have interesting repercussions for who ever is hosting the moby-central. Martin> Without it the agent solution is weak (IMHO) - having the Martin> similar weakness as Google has with non existing Martin> links/documents (oh, wow, now I really feel like a pariah by Martin> saying that Google has a weakness!) Martin> In case of lease - is there a concept of making a lease Martin> to expire Martin> before its planned end? If so, how is it done that nobody Martin> else can do it except me (problem a))? Not really sure on this one, to be honest. Clearly, you can just set up a short lease in the first place. Alternatively, you pass back some magic cookie when the lease is taken out in the first place, that is required for deregistration. This enables deregistration to be done from anywhere, rather than through direct control of the RDF URL, but still only by the originator. The ideal would, of course, to have some off the shelf library for doing leases. Martin> Can you, Phill perhaps, explain me if the lease can solve Martin> my two Martin> problems above? So far I understand that an agent can - Martin> assuming tghat there will be that new API call (Mark, Eddie, Martin> will this be - in case the agent idea is accepted?) Does this make sense? Phil From senger at ebi.ac.uk Wed Aug 17 10:57:47 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Aug 17 10:49:15 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87vf246ew9.fsf@rpc71.cs.man.ac.uk> Message-ID: > Actually, there is a minor security problem here. If I call this > method repeatedly and it really happens *now* > You are exaggerating (how to spell this word?). The agent can be clever enough not to go really *now" but only in a reasonably but short intervals (once a minute maximum, for example). > Not really sure on this one, to be honest. Clearly, you can just set > up a short lease in the first place. > Yes, that make sense. Or perhaps, I could re-register again with a different lease, right? > Alternatively, you pass back some magic cookie when the lease is taken > out in the first place, that is required for deregistration. > Well, this is exactly what biomoby has now - and nobody seems to like it. That's why we are talking how to change it. Thanks, Phill, for claryfying the issue (at least in my mind). I feel now that a lease gives me more control (if and only if I can re-register with a different lease anytime). And an agent plays a role of an independent observer that can stop my registration if it finds that there is something wrong with it (not running, not found RDF etc.). But the problem is still with the "if and only if" in the previous paragraph I think. If I can re-register and change the lease, probably anybody can do it - and to remove/hijack my registration. And we are back where we started.... So the above would work only if I can prove who I am. And the only way how to do it (if we do not want to introduce passwords etc.) is to let somebody come back to my place (because only I can control such a place). That means an agent... So: if I use a lease I am in charge of registering my services. If it is a new registration (such service does not exist yet), everything is fine and nobody needs to go to me (but can, and probably will, but there is no hurry). If I try to re-register (because I wish to change the lease period), then an agent must come to me to see that my RDF document is still there (with a new lease perion inside) - and it must come soon, because it cannot confirm my re-registration. This could work... (not only lease, not only agent, but both) Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From gordonp at ucalgary.ca Wed Aug 17 12:16:45 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed Aug 17 12:06:35 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: References: Message-ID: <430362ED.1090804@ucalgary.ca> >>Alternatively, you pass back some magic cookie when the lease is taken >>out in the first place, that is required for deregistration. >> >> >> > Well, this is exactly what biomoby has now - and nobody seems to like >it. That's why we are talking how to change it. > > Absolutely. Keeping a cookie around somewhere for a month, then manually using it to renew the lease (remember, automating the lease renewal is just as bad as having an RDF file that you need to change) is bad. If I lose my cookie, or it is intercepted, I'm toast. > So the above would work only if I can prove who I am. And the only way >how to do it (if we do not want to introduce passwords etc.) is to let >somebody come back to my place (because only I can control such a >place). That means an agent... > > Exactly my point from before about multiple host names/machine. You should only be able to advertise a service available in MOBY from the ucalgary.ca domain if you are able to put an RDF document on a web server in that domain. It's a security check of sorts. I don't see how a lease-only system could easily acheive this without some signing certificates, and in fact I could prevent the NCBI from registering services by doing it first and getting the cookie they need to fix the registry. If we can add a "push" like method to the registry saying "check my RDF ASAP", and maybe an optional expiry for people who like leases (the default would be turf the service if the test case fails repeatedly) we should have the best of both worlds... > So: if I use a lease I am in charge of registering my services. If it >is a new registration (such service does not exist yet), everything is >fine and nobody needs to go to me (but can, and probably will, but there >is no hurry). If I try to re-register (because I wish to change the lease >period), then an agent must come to me to see that my RDF document is >still there (with a new lease perion inside) - and it must come soon, >because it cannot confirm my re-registration. > > This could work... (not only lease, not only agent, but both) > > Cheers, > Martin > >-- >Martin Senger > email: martin.senger@gmail.com > skype: martinsenger >International Rice Research Institute >Biometrics and Bioinformatics Unit >DAPO BOX 7777, Metro Manila >Philippines, phone: +63-2-580-5600 (ext.2324) > >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From markw at illuminae.com Wed Aug 17 12:23:50 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Aug 17 12:14:39 2005 Subject: [moby] Re: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <430362ED.1090804@ucalgary.ca> References: <430362ED.1090804@ucalgary.ca> Message-ID: <1124295830.21293.24.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-17 at 10:16 -0600, Paul Gordon wrote: > Keeping a cookie around somewhere for a month, then > manually using it to renew the lease (remember, automating the lease > renewal is just as bad as having an RDF file that you need to change) is > bad. If I lose my cookie, or it is intercepted, I'm toast. Yes... in fact, that solution makes me lose my cookies! ;-) > If we can add a "push" like method to the registry saying > "check my RDF ASAP", and maybe an optional expiry for people who like > leases (the default would be turf the service if the test case fails > repeatedly) we should have the best of both worlds... This is easy enough to do given that we are moving to RDF as our Service Signature - it just becomes another metadata tag. However, we would then have to add some code to the registry that stores lease times, and this then makes some assumptions about what the underling registry has to know about. Given that we are now trying to support both a MOBY Central and a myGrid/Feta underlying store we cannot make "arbitrary" decisions like this anymore... A non-lease mechanism does not require the registry to "think", only to store the data that it needs and respond to "come hither agent" calls. M -- "Ontologists do it with the edges!" 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 From fgibbons at hms.harvard.edu Thu Aug 18 18:13:02 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu Aug 18 18:03:11 2005 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? Message-ID: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> Hi, I'm having trouble understanding where articleName belongs. I thought I understood it before, but now that I'm trying to use jMoby to access services that I'm providing from Perl, I'm confused again..... (But I note from the MOBY digest that just landed in my mailbox that that's OK, since articleName has several uses/meanings, and may perhaps soon acquire some more, so perhaps I'm not the only one ;) My (Perl) services expect input that looks like this: In jMoby, from reading TestRequest.java, I can see that it's easy to build an object to contain a message like, using one of the constructors (it takes two String arguments: namespace and id). But how do I set the articleName for the enclosing tag? Calling setName() on the service input MobyDataObject that wraps it, results in that articleName being handed down to the child element (Object), when it should remain with the Simple. Maybe I've got it all wrong. This has worked for me with the Perl API for over a year, but when trying to interact with those services using jMoby, it barfs because the response (which looks not unlike the input above) contains Simples with children, which "is NOT expected" [sic]. But I though Simples could contain fundamental datatypes like String & friends. Perhaps this relates to the discussion over the last weeks about what a Collection is for. Hopefully, I've overlooked something in the javadocs - if so, I'd appreciate a pointer to the right class. Thanks in advance. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Thu Aug 18 18:59:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Aug 18 18:49:04 2005 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> Message-ID: Frank, I guess you will get an reply from Paul explaining your answer. I want just make a small note: Bear with me for another week (probably less, just until Monday or Tuesday) when I am going to release a completly new support/additions to jMoby that surely deals with article names in both their incarnations (article names in Simples and article names in members objects (HAS/HASA objects). Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From gordonp at ucalgary.ca Fri Aug 19 11:21:38 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri Aug 19 11:11:41 2005 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> References: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> Message-ID: <4305F902.7060506@ucalgary.ca> > Hi, > > I'm having trouble understanding where articleName belongs. I thought > I understood it before, but now that I'm trying to use jMoby to access > services that I'm providing from Perl, I'm confused again..... (But I > note from the MOBY digest that just landed in my mailbox that that's > OK, since articleName has several uses/meanings, and may perhaps soon > acquire some more, so perhaps I'm not the only one ;) > > My (Perl) services expect input that looks like this: > > > > > > In jMoby, from reading TestRequest.java, I can see that it's easy to > build an object to contain a message like, using one of the > constructors (it takes two String arguments: namespace and id). But > how do I set the articleName for the enclosing tag? Calling > setName() on the service input MobyDataObject that wraps it, results > in that articleName being handed down to the child element (Object), > when it should remain with the Simple. To me it makes sense: calling object.setName() sets the article name in the Object tag, not the Simple. The Simple is not a data object of any sort, it is just a wrapper used to name parameters in calls to services. I can reuse the Object in another service, with a completely different parameter name, or even use it as part of a collection. I should not have to modify the Object name itself to make these calls, as it is exactly the same Object tag as before. In fact, I never use object.setName(), it's there because there are other parts of the code that call it, when you are building composite objects and the articleName is needed to identify the data member. I'll add a message to the javadoc stating this. Because most people are just using one parameter inputs, it's easy to falsely make the connection object name == simple name. Was there not some dicussion on the list of changing articleName to paramName for Simples? If not, we should defiunitely do this! In any case, the jMOBY code right now doesn't deal nicely with named parameters. I was striuggling before with how to deal with XML that both named and unnamed parameters, very confusing. But now that all parameters have to be named (since API 0.86) its much easier. I'll fix the code on the weekend. Thanks for pointiung this out. > Maybe I've got it all wrong. This has worked for me with the Perl API > for over a year, but when trying to interact with those services using > jMoby, it barfs because the response (which looks not unlike the input > above) contains Simples with children, which "is NOT expected" [sic]. > But I though Simples could contain fundamental datatypes like String & > friends. Perhaps this relates to the discussion over the last weeks > about what a Collection is for. Can you send me your exact XML? > Hopefully, I've overlooked something in the javadocs - if so, I'd > appreciate a pointer to the right class. > > Thanks in advance. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gordonp at ucalgary.ca Fri Aug 19 12:06:11 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri Aug 19 11:55:44 2005 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <4305F902.7060506@ucalgary.ca> References: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> <4305F902.7060506@ucalgary.ca> Message-ID: <43060373.1080304@ucalgary.ca> Replying to my own :-) > > In any case, the jMOBY code right now doesn't deal nicely with named > parameters. I was striuggling before with how to deal with XML that > both named and unnamed parameters, very confusing. But now that all > parameters have to be named (since API 0.86) its much easier. I'll > fix the code on the weekend. Thanks for pointiung this out. > Hmm. A corrolary of requiring all parameters to be named is that there the returned data should be named too, as MOBY input and output messages are essentially symmetric. We could get around this by saying that if you have only one parameter, it does not need to be named. In that way, the response simple or collection does not need to be named either. This also makes the vast majority of currently registered services valid again according to API v.0.86 , as most have one parameter, and it is not named. From senger at ebi.ac.uk Fri Aug 19 12:46:07 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 19 12:43:53 2005 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <43060373.1080304@ucalgary.ca> Message-ID: Regarding the mandatorness of article name, I have heard the same rumour as you did, Paul. What I got confirmed is that article name must be usede for included objects in other objects. What was not yet confirmed is that also Simples and Collections (the wrapper objects) must have article name. Obviously not having article names mandatory is a pain in the neck - I am struggling with it the whole last week... Also API documentation is very unnerving (is this a right English word to use if you wish to say a four-letter word but you are too polite or too afraid to say it?). In one place it says "Articles are required to be named using the articleName attribute." and a bit further it says: "The articleName attribute of the Simple and/or Collection elements is optional...". Mark, could you say loundly and soonish: 1) How it is really? 2) What to do with currently registered services that do not comply with the rule from 1) ? Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 19 14:42:21 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Aug 19 14:31:57 2005 Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: References: Message-ID: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> On Fri, 2005-08-19 at 17:46 +0100, Martin Senger wrote: > What was not yet confirmed is that > also Simples and Collections (the wrapper objects) must have article > name. Obviously not having article names mandatory is a pain in the neck - > I am struggling with it the whole last week... It was confirmed a while ago - see below... > Also API documentation is very unnerving (is this a right English word to > use if you wish to say a four-letter word but you are too polite or too > afraid to say it?). In one place it says "Articles are required to be > named using the articleName attribute." and a bit further it says: "The > articleName attribute of the Simple and/or Collection elements is > optional...". I'll look for this error. I really need someone to take over the task of documentation, however... > Mark, could you say loundly and soonish: > 1) How it is really? I reported loudly and previously: : From: markw@illuminae.com : Reply-To: Core developer announcements 2) What to do with currently registered services that do not comply with > the rule from 1) ? I think we can add an arbitratry articleName to their inputs, since they will no doubt ignore it anyway... Must run! M -- "Ontologists do it with the edges!" 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 From gordonp at ucalgary.ca Fri Aug 19 19:13:47 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri Aug 19 19:04:18 2005 Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> References: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> Message-ID: <430667AB.1070906@ucalgary.ca> The way I dealt with this was to allow a zero-length string as a name. There's nothing in the API that forbids this. Anything without an articleName gets a zero-length name, and if there is more than one, I raise an exception. This handles currently registered one-parameters jobs fine without resorting to random names, and enforces uniqueness of the articleName going forward. Actually, the API doesn't say they need to be unique, just that they need to be there. >: 1) *all* parameters going into a service must now be named currently using the >: articleName attribute of the Simple/Collection/Parameter tag > > > > >>2) What to do with currently registered services that do not comply with >>the rule from 1) ? >> >> > >I think we can add an arbitratry articleName to their inputs, since they >will no doubt ignore it anyway... > >Must run! > >M > > > > From senger at ebi.ac.uk Fri Aug 19 20:11:13 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 19 20:01:22 2005 Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> Message-ID: > It was confirmed a while ago - see below... > Thank for confirmation. It is a good news. (I knew about the email you quoted - but I was not sure if it was a definitive announcement or just your contribution to the discussion of the API changes. Now it's clear. My confusion just confirms that Biomoby still does not have in place a formal procedure how and when to do API changes.) Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From paolo at ist.unige.it Mon Aug 22 07:26:40 2005 From: paolo at ist.unige.it (Paolo Romano) Date: Mon Aug 22 06:15:21 2005 Subject: [MOBY-l] NETTAB 2005 - Deadlines approaching: early registration and call for posters Message-ID: <200508221126.j7MBQeqR019972@ibm43p.biotech.ist.unige.it> Dear all, this is a reminder for next deadlines of the NETTAB 2005 Workshop on "Workflows management: new abilities for the biological information overflow" that will be held on next October 5-7, 2005, in Naples, Italy. The Scientific Programme is now available on-line at http://www.nettab.org/2005/progr.html . The Opening Lecture will be given by Francis Ouellette. Francis Ouellette is the Director of the UBiC, the Bioinformatics Centre of the University of British Columbia, Canada. He is Associate Professor of the Michael Smith Laboratories and of the Department of Medical Genetics of UBC. He is also a core faculty member in the new UBC graduate Training Program in Bioinformatics for Health Research, associate director of Bioinformatics at Genome British Columbia and director of the Canadian Genetic Diseases Network (CGDN) bioinformatics core facility where he helps coordinate the Canadian Bioinformatics Workshops. Francis has an exceptional curriculum and his recent research, training and coordination activities make him one of the most known and appreciated bioinformaticians. The title of his opening talk will be "Workflow management in bioinformatics: the possibilities and the challenges". ---------------------------------------------------------------------- The Call for posters and position papers is closing on next friday August 26, 2005. You are all warmly invited to present your recent activity related to the workshops' topics by submitting a poster abstract (1-2 A4 pages, font size 12 pt, MS Word format) by email to posters2005@nettab.org . Topics are the following: Technologies and technological platforms of interest, with emphasis on: - Web Services (SOAP, WSDL, WSFL, UDDI, ....) - Web Services Choreography and Orchestration - Semantic Web (RDF, LSID, OWL, ...) - comparison of available technologies, limitations, pros and cons - knowledge representation - biological data and knowledge modeling tools - Ontologies, Databases and Applications of Semantics in Bioinformatics Workflow management systems in bioinformatics - implementations of web services - implementations of registries - reuse and versioning of web services and workflows - workflow management systems - web interfaces for accessing and executing workflows - interactive systems to support work flows Applications of workflow management systems in bioinformatics - Methodologies for life sciences analysis, such as: - gene expression, - genome annotation, - mass spec peptide fragment identification, - Encoding of the above in workflows - Case studies - Scenarios and use cases Check all details at: http://www.nettab.org/2005/call.html . -------------------------------------------------------------------------------- The early registration deadline is also next Friday August 26, 2005. The registration form is available on-line at: http://www.nettab.org/2005/rform.html . The payment of the fee can either be done on-line, through the Online Payment Form of the Bioinformatics Italian Society (BITS), or by direct money transfer. Participation fees are as follows: Until August 26, 2005: - Students: 70,00 Euro - Academic: 130,00 Euro (reduced fee: 117,00 Euro) - Non-academic: 270,00 Euro (reduced fee: 243,00 Euro) After August 26, 2005: - Students: 70,00 Euro - Academic: 180,00 Euro (reduced fee: 162,00 Euro) - Non-academic: 370,00 Euro (reduced fee: 333,00 Euro) The 10% reduction on fees is applied for members of: - ISCB (International Society for Computational Biology), http://www.iscb.org/ - BITS (Bioinformatics Italian Society), http://www.bioinformatics.it/ - Hormone Responsive Breast Cancer (HRBC) Genomics Network, http://www.hrbc-genomics.net/ - Oncology over Internet (O2I) project, http://www.o2i.it/ - Interdisciplinary Laboratory for Technologies in Bioinformatics (LITBIO) -------------------------------------------------------------------------------- I'm looking forward to meeting many of you in Naples quite soon. Ciao. Paolo -- Paolo Romano (paolo.romano@istge.it) Bioinformatics and Structural Proteomics National Cancer Research Institute (IST) Largo Rosanna Benzi, 10, I-16132, Genova, Italy Tel: +39-010-5737-288 Fax: +39-010-5737-295 Web: http://www.nettab.org/promano/ From p.lord at cs.man.ac.uk Mon Aug 22 08:21:48 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: Mon Aug 22 08:11:34 2005 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <430362ED.1090804@ucalgary.ca> References: <430362ED.1090804@ucalgary.ca> Message-ID: <87fyt2duw3.fsf@rpc71.cs.man.ac.uk> >>>>> "Paul" == Paul Gordon writes: >>> Alternatively, you pass back some magic cookie when the lease is >>> taken out in the first place, that is required for >>> deregistration. >>> >>> >> Well, this is exactly what biomoby has now - and nobody seems to >> like it. That's why we are talking how to change it. >> Paul> Absolutely. Keeping a cookie around somewhere for a month, Paul> then manually using it to renew the lease (remember, Paul> automating the lease renewal is just as bad as having an RDF Paul> file that you need to change) is bad. If I lose my cookie, or Paul> it is intercepted, I'm toast. I don't think that you'd need the cookie to renew your lease, just to remove it before hand. If you lose it, then you just have to wait for it to run out naturally. Of course, if it's built into the service provider libraries, there is no real reason that you should lose it. >> So the above would work only if I can prove who I am. And the >> only way how to do it (if we do not want to introduce passwords >> etc.) is to let somebody come back to my place (because only I >> can control such a place). That means an agent... >> Paul> Exactly my point from before about multiple host Paul> names/machine. You should only be able to advertise a service Paul> available in MOBY from the ucalgary.ca domain if you are able Paul> to put an RDF document on a web server in that domain. It's a Paul> security check of sorts. I don't see how a lease-only system Paul> could easily acheive this without some signing certificates, Paul> and in fact I could prevent the NCBI from registering services Paul> by doing it first and getting the cookie they need to fix the Paul> registry. I think that the lease is a property of the registration, not of the service. So, if you register a service, it won't prevent anyone else from registering the same service again. Again, if you put some sort of call back into the leasing system, you could prevent anyone from registering a service that they do not own. Although, personally, I don't see any major problem with third party registration. Feta effectively works on third party registration, as most of the semantic descriptions do not come from the service provider. Phil From markw at illuminae.com Mon Aug 22 11:34:49 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Aug 22 11:24:33 2005 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <4309A53B.8080701@cnb.uam.es> References: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> <4309A53B.8080701@cnb.uam.es> Message-ID: <1124724889.3068.103.camel@bioinfo.icapture.ubc.ca> On Mon, 2005-08-22 at 12:13 +0200, David Gonz?lez Pisano wrote: > Umm, does this mean that also Simples into Collections *must* have an > articlename too, even an arbitrary one? I was wondering if the lack of > an articleName in the "Simple inside a Collection" example (see the > API documentation, section INPUT) means that a Simple has to have > articleName when is the only input No, Simples inside a collection do not have an articleName, and at most they would all have the same articleName (I'm actually not sure how the registry code handles this at the moment... I suspect that it does record the articleName of a Simple within a Collection if an articleName has been provided at registration, but I know for certain that none of my client libraries pay attention to it even if it is there, since it was not *intended* to be used, nor meaningful). > Also, probably the twiki needs an update, because as today still says "The articleName attribute of the Simple and/or Collection elements is > optional (it may or may not be there, and if there, it may or may not have a non-null value)". Note that the last part of the phrase contradicts Paul's solution. I'll try to find this and fix it. again... we really need someone to volunteer to take over the task of re-writing and maintaining the documentation :-) M -- "Ontologists do it with the edges!" 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 From dgpisano at cnb.uam.es Mon Aug 22 06:13:15 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Mon Aug 22 11:25:22 2005 Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> References: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> Message-ID: <4309A53B.8080701@cnb.uam.es> Mark Wilkinson escribi?: >On Fri, 2005-08-19 at 17:46 +0100, Martin Senger wrote: > > >>What was not yet confirmed is that >>also Simples and Collections (the wrapper objects) must have article >>name. Obviously not having article names mandatory is a pain in the neck - >>I am struggling with it the whole last week... >> >> >It was confirmed a while ago - see below... > > > >: >: A few changes to announce for the 0.86 API (this is not yet running on the >: production server): >: >: 1) *all* parameters going into a service must now be named currently using the >: articleName attribute of the Simple/Collection/Parameter tag > > Umm, does this mean that also Simples into Collections *must* have an articlename too, even an arbitrary one? I was wondering if the lack of an articleName in the "Simple inside a Collection" example (see the API documentation, section INPUT) means that a Simple has to have articleName when is the only input <------- articleName here! but does not need it when is inside a Collection? <------- no articleName here? Also, probably the twiki needs an update, because as today still says "The articleName attribute of the Simple and/or Collection elements is optional (it may or may not be there, and if there, it may or may not have a non-null value)". Note that the last part of the phrase contradicts Paul's solution. David (working on the Errors proposal, which heavily depends on the answer to this mail) ;-) From fgibbons at hms.harvard.edu Mon Aug 22 11:54:11 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Mon Aug 22 11:43:36 2005 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <1124724889.3068.103.camel@bioinfo.icapture.ubc.ca> References: <4309A53B.8080701@cnb.uam.es> <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> <4309A53B.8080701@cnb.uam.es> Message-ID: <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> Mark, At 11:34 AM 8/22/2005, you wrote: > > Also, probably the twiki needs an update, because as today still says > "The articleName attribute of the Simple and/or Collection elements is > > optional (it may or may not be there, and if there, it may or may not > have a non-null value)". Note that the last part of the phrase > contradicts Paul's solution. > >I'll try to find this and fix it. > >again... we really need someone to volunteer to take over the task of >re-writing and maintaining the documentation :-) I'll volunteer for that. You're referring to the Wiki API page, I assume, or are there other docs (besides the POD and javadoc)? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Mon Aug 22 12:08:13 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Aug 22 11:57:45 2005 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> Message-ID: > I'll volunteer for that. You're referring to the Wiki API page, I assume, > or are there other docs (besides the POD and javadoc)? > That's goooood! But please be merciless, as much as you can. :-) The main problem I had with these pages from/at the beginning is that only the initiated easily understand that the page actually contain two APIs - one for registry and one for services. The current page mix them too much (IMHO). I also volunteer for proof-reading (just send me your draft) - and I promise I will be chasing Mark with every smallest ambiguity that I could find. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 22 12:14:49 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Aug 22 12:04:29 2005 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: References: Message-ID: <1124727289.3068.131.camel@bioinfo.icapture.ubc.ca> > and I > promise I will be chasing Mark with every smallest ambiguity that I could > find. OOOooohhh yeah... he sure will! I know that from experience ;-) M -- "Ontologists do it with the edges!" 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 From markw at illuminae.com Mon Aug 22 12:16:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Aug 22 12:05:34 2005 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> References: <4309A53B.8080701@cnb.uam.es> <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> <4309A53B.8080701@cnb.uam.es> <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> Message-ID: <1124727364.3068.134.camel@bioinfo.icapture.ubc.ca> that's fantastic! Thanks Frank! I need to set you up with a developers account on the TWiki machine so that you can edit the main page I think... let's coordinate this off- list. Speaking of the Twiki machine... Simon - how's the new website plan coming? M On Mon, 2005-08-22 at 11:54 -0400, Frank Gibbons wrote: > Mark, > > At 11:34 AM 8/22/2005, you wrote: > > > Also, probably the twiki needs an update, because as today still says > > "The articleName attribute of the Simple and/or Collection elements is > > > optional (it may or may not be there, and if there, it may or may not > > have a non-null value)". Note that the last part of the phrase > > contradicts Paul's solution. > > > >I'll try to find this and fix it. > > > >again... we really need someone to volunteer to take over the task of > >re-writing and maintaining the documentation :-) > > > I'll volunteer for that. You're referring to the Wiki API page, I assume, > or are there other docs (besides the POD and javadoc)? > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- "Ontologists do it with the edges!" 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 From silvia77 at dist.unige.it Thu Aug 25 06:12:09 2005 From: silvia77 at dist.unige.it (scaglione) Date: Thu Aug 25 06:10:47 2005 Subject: [MOBY-l] sth_collection_ins Message-ID: <1124964729.430d9979a03e9@webmail.unige.it> hello, I have followed instructions to install a moby central in my machine.I have tried the testMOBYClientCentral_v05.pl script on my mobycentral and an error appeared: >perl testMOBYCentral_v05.pl Useless use of hash element in void context at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. Global symbol "$sth_collection_ins" requires explicit package name at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. Compilation failed in require at testMOBYCentral_v05.pl line 4. BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. what does it mean? The overall configuration of the moby central seemed to be ok, since the test of the same script on the main mobycentral works... many thanks silvia -- PhD. Silvia Scaglione DIST University of Genoa Viale Causa,13 16145 Genoa phone +39 010 353 2789 phone CBA +39 010 5737 505 fax +39 010 353 2948 From markw at illuminae.com Thu Aug 25 12:27:21 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Aug 25 12:17:16 2005 Subject: [moby] [MOBY-l] sth_collection_ins In-Reply-To: <1124964729.430d9979a03e9@webmail.unige.it> References: <1124964729.430d9979a03e9@webmail.unige.it> Message-ID: <1124987241.11350.50.camel@bioinfo.icapture.ubc.ca> Can you first confirm where you got your mobycentral code from? Is it one of the newer releases? I'm certain that the latest release is functional (though there are a few small bugs in it that are now fixed in the CVS, but the CVS code isn't supported yet...) make/make install this code and see if it solves your problems. You probably wont need to modify any of your configuration after this installation. http://biomoby.org/releases/biomoby.0.8.2a.tar.gz M On Thu, 2005-08-25 at 12:12 +0200, scaglione wrote: > hello, > I have followed instructions to install a moby central in my machine.I have > tried the testMOBYClientCentral_v05.pl script on my mobycentral and an error > appeared: > > >perl testMOBYCentral_v05.pl > > Useless use of hash element in void context > at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. > Global symbol "$sth_collection_ins" requires explicit package name > at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. > Compilation failed in require at testMOBYCentral_v05.pl line 4. > BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. > > what does it mean? > The overall configuration of the moby central seemed to be ok, since the test > of the same script on the main mobycentral works... > many thanks > silvia > > > -- "Ontologists do it with the edges!" 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 From jmfernandez at cnb.uam.es Fri Aug 26 12:37:31 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri Aug 26 12:26:58 2005 Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? Message-ID: <430F454B.7020603@cnb.uam.es> Hi people! Is there any problem with Tomcat server in MOBY Central? Since Tuesday (or so) I'm playing with latest Taverna CVS, and BioMOBY related stuff doesn't work because there is a HTTP 500 code related to http://www.biomoby.org/RESOURCES/MOBY-S/Objects (RDF Object definitions). As Taverna 1.2 also depends on this URL, MOBY services tree is not either working. Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From edward.kawas at gmail.com Fri Aug 26 13:20:17 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri Aug 26 13:10:55 2005 Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? In-Reply-To: <430F454B.7020603@cnb.uam.es> References: <430F454B.7020603@cnb.uam.es> Message-ID: Hi, I will look into this asap (saturday or sunday). It looks like the server works because the other RDF documents are being generated so something must be wrong with either the configuration. Actually, I just noticed that the types script for objects is returning stuff that it shouldnt (http://mobycentral.icapture.ubc.ca:8090/types/Objects) and this script is utilized by the RESOURCES script. As soon as I am able to check this out, I will and l will fix it. The problem seems to lie with the object 'Regex' and its description (no longer limited to one line per object). Eddie On 8/26/05, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi people! > Is there any problem with Tomcat server in MOBY Central? Since Tuesday > (or so) I'm playing with latest Taverna CVS, and BioMOBY related stuff > doesn't work because there is a HTTP 500 code related to > http://www.biomoby.org/RESOURCES/MOBY-S/Objects (RDF Object > definitions). As Taverna 1.2 also depends on this URL, MOBY services > tree is not either working. > > Best Regards, > Jos? Mar?a > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From senger at ebi.ac.uk Fri Aug 26 20:28:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Aug 26 20:25:30 2005 Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? In-Reply-To: Message-ID: > The problem seems to lie with the object 'Regex' and its description > (no longer limited to one line per object). > Regex is my object! I am always happy to shoot down all servers around :-) But seriusly, anything wrong with longer description? Does API preclude it? Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Sat Aug 27 09:55:31 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Sat Aug 27 09:45:34 2005 Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? In-Reply-To: References: Message-ID: I think the description is fine, Mark will need to verify this. I will just have to update my logic (already done in my head and when i get home today i will update the codebase). Eddie On 8/26/05, Martin Senger wrote: > > The problem seems to lie with the object 'Regex' and its description > > (no longer limited to one line per object). > > > Regex is my object! I am always happy to shoot down all servers around > :-) > But seriusly, anything wrong with longer description? Does API preclude > it? > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > From senger at ebi.ac.uk Mon Aug 29 10:32:30 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Aug 29 10:25:08 2005 Subject: [MOBY-l] Moses - Moby Services Support In-Reply-To: <1476.82.66.216.27.1118945157.squirrel@82.66.216.27> Message-ID: Hi all, My first month at Philippines, at IRRI, is almost finished. So it's time to announce some progress :-) I have commited code and a lot of documentation helping to write Biomoby services in Java. The idea is to generate classes for all registered data types and then generate skeleton for a new service. Its developer can extend such skeleton , put there the business logic without worries about the Biomoby XML and about the SOAP itself. These things should be hidden. It is similar what Paul Gordon provides for the clients, but here you can use strongly-type approach (having all data types generated). Or, you can say, that we can have more ways to do the same, like in Perl :-) As (almost) a side-effect, the generated code, because it has rich API/javadoc comments, can be used as a primitive browser of the biomoby registry. Here you can see the API for all data types and for all services as they are today (when I find a place where I can run a cronjob, we can have this API up-to-date anytime you look): http://www.ebi.ac.uk/~senger/jMoby/APIservices/index.html The documentation is in jMoby and can be viewed at: http://biomoby.org/moby-live/Java/docs/Moses.html. I hope you'll enjoy it and I am happy to hear your suggestions, bug reports (remember there is also a bugzilla open now, but feel free to send emails direcly to me) and anything bout Moses. With regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From silvia77 at dist.unige.it Thu Aug 25 05:52:50 2005 From: silvia77 at dist.unige.it (scaglione) Date: Tue Aug 30 18:56:09 2005 Subject: [MOBY-l] sth_collection_ins Message-ID: <1124963570.430d94f212a32@webmail.unige.it> hello, I have followed instructions to install a moby central in my machine.I have tried the testMOBYClientCentral_v05.pl script on my mobycentral and an error appeared: >perl testMOBYCentral_v05.pl Useless use of hash element in void context at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. Global symbol "$sth_collection_ins" requires explicit package name at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. Compilation failed in require at testMOBYCentral_v05.pl line 4. BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. what does it mean? The overall configuration of the moby central seemed to be ok, since the test of the same script on the main mobycentral works... many thanks silvia -- PhD. Silvia Scaglione DIST University of Genoa Viale Causa,13 16145 Genoa phone +39 010 353 2789 phone CBA +39 010 5737 505 fax +39 010 353 2948 From silvia77 at dist.unige.it Wed Aug 31 09:32:20 2005 From: silvia77 at dist.unige.it (Silvia Scaglione) Date: Wed Aug 31 09:47:21 2005 Subject: [moby] [MOBY-l] test In-Reply-To: <1124987241.11350.50.camel@bioinfo.icapture.ubc.ca> References: <1124964729.430d9979a03e9@webmail.unige.it> <1124987241.11350.50.camel@bioinfo.icapture.ubc.ca> Message-ID: <6.2.0.14.0.20050831152820.01cc1998@mail.unige.it> I have used the newer releases suggested below, but new errors appears after testing testMOBYClientCentral_v05.pl script on the mobycentral: ... test 19 [PASS] test 20 [FAIL] malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_] test 21 [FAIL] Expected to find service; didn't find service test 22 [FAIL] Expected to find service; didn't find service test 23 [PASS] test 24 [PASS] Use of uninitialized value in print at testMOBYClientCentral_v05.pl line 250. test 25 [FAIL] WSDL was not retrieved test 26 [FAIL] The service specified by authority=www.illuminae.com servicename=myfirstservice2 does not exist in the registry test 27 [PASS] ... Moreover, when I tried the testMOBYClientCentral_v05.pl script on my mobycentral, the error message changes a little bit: >[www@ml370 scripts]$ perl testMOBYClientCentral_v05.pl >TESTING MOBY CLIENT with > URL: http://ml370.biotech.ist.unige.it/cgi-bin/MOBY-Central.pl > URI: http://ml370.biotech.ist.unige.it/MOBY/Central > Proxy: No Proxy Server > >test 1a [PASS] >test 1b [PASS] >test 1 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system > >test 2 [PASS] >test 3 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system >test 4 [FAIL] Relationship type ISA does not exist in the >relationship ontology >test 5 [PASS] >test 6 [FAIL] Object type $term cannot be resolved to an LSID >test 7 [PASS] >test 8 [FAIL] Object type $term cannot be resolved to an LSID >test 9 [FAIL] Service Type HypotheticalService1 does not exist in >the ontology >test 10 [PASS] >test 11 [PASS] >test 12 [PASS] >test 13 [PASS] >test 14 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 15 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 16 [PASS] >test 17 [PASS] >test 18 [PASS] >test 19 [PASS] >test 20 [PASS] >500 Internal Server Error > ERROR ERROR ERROR ...any suggestions? At 18.27 25/08/2005, Mark Wilkinson wrote: >Can you first confirm where you got your mobycentral code from? Is it >one of the newer releases? I'm certain that the latest release is >functional (though there are a few small bugs in it that are now fixed >in the CVS, but the CVS code isn't supported yet...) > >make/make install this code and see if it solves your problems. You >probably wont need to modify any of your configuration after this >installation. > >http://biomoby.org/releases/biomoby.0.8.2a.tar.gz > > >M > > > >On Thu, 2005-08-25 at 12:12 +0200, scaglione wrote: > > hello, > > I have followed instructions to install a moby central in my machine.I > have > > tried the testMOBYClientCentral_v05.pl script on my mobycentral and an > error > > appeared: > > > > >perl testMOBYCentral_v05.pl > > > > Useless use of hash element in void context > > at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. > > Global symbol "$sth_collection_ins" requires explicit package name > > at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. > > Compilation failed in require at testMOBYCentral_v05.pl line 4. > > BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. > > > > what does it mean? > > The overall configuration of the moby central seemed to be ok, since > the test > > of the same script on the main mobycentral works... > > many thanks > > silvia > > > > > > >-- >"Ontologists do it with the edges!" > >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 PhD. Silvia Scaglione Universita`degli Studi di Genova Facolta' di Ingegneria, D.I.S.T. BioLab Viale Causa, 13 16145 GENOVA - Italy Tel Bio-lab +39 010 353 2789 Tel Centro Biotecnologie Avanzate +39 010 5737 505 Fax +39 010 353 2948 E-mail silvia77@dist.unige.it From markw at illuminae.com Wed Aug 31 10:03:16 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed Aug 31 09:59:05 2005 Subject: [moby] [MOBY-l] test Message-ID: <1390300886-1125497047-cardhu_blackberry.rim.net-15323-@engine08-cell01> Use "make test" instead - it is up to date and far far far more comprehensive. M -----Original Message----- From: Silvia Scaglione Date: Wed, 31 Aug 2005 15:32:20 To:moby-l@biomoby.org Subject: Re: [moby] [MOBY-l] test I have used the newer releases suggested below, but new errors appears after testing testMOBYClientCentral_v05.pl script on the mobycentral: ... test 19 [PASS] test 20 [FAIL] malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_] test 21 [FAIL] Expected to find service; didn't find service test 22 [FAIL] Expected to find service; didn't find service test 23 [PASS] test 24 [PASS] Use of uninitialized value in print at testMOBYClientCentral_v05.pl line 250. test 25 [FAIL] WSDL was not retrieved test 26 [FAIL] The service specified by authority=www.illuminae.com servicename=myfirstservice2 does not exist in the registry test 27 [PASS] ... Moreover, when I tried the testMOBYClientCentral_v05.pl script on my mobycentral, the error message changes a little bit: >[www@ml370 scripts]$ perl testMOBYClientCentral_v05.pl >TESTING MOBY CLIENT with > URL: http://ml370.biotech.ist.unige.it/cgi-bin/MOBY-Central.pl > URI: http://ml370.biotech.ist.unige.it/MOBY/Central > Proxy: No Proxy Server > >test 1a [PASS] >test 1b [PASS] >test 1 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system > >test 2 [PASS] >test 3 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system >test 4 [FAIL] Relationship type ISA does not exist in the >relationship ontology >test 5 [PASS] >test 6 [FAIL] Object type $term cannot be resolved to an LSID >test 7 [PASS] >test 8 [FAIL] Object type $term cannot be resolved to an LSID >test 9 [FAIL] Service Type HypotheticalService1 does not exist in >the ontology >test 10 [PASS] >test 11 [PASS] >test 12 [PASS] >test 13 [PASS] >test 14 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 15 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 16 [PASS] >test 17 [PASS] >test 18 [PASS] >test 19 [PASS] >test 20 [PASS] >500 Internal Server Error > ERROR ERROR ERROR ...any suggestions? At 18.27 25/08/2005, Mark Wilkinson wrote: >Can you first confirm where you got your mobycentral code from? Is it >one of the newer releases? I'm certain that the latest release is >functional (though there are a few small bugs in it that are now fixed >in the CVS, but the CVS code isn't supported yet...) > >make/make install this code and see if it solves your problems. You >probably wont need to modify any of your configuration after this >installation. > >http://biomoby.org/releases/biomoby.0.8.2a.tar.gz > > >M > > > >On Thu, 2005-08-25 at 12:12 +0200, scaglione wrote: > > hello, > > I have followed instructions to install a moby central in my machine.I > have > > tried the testMOBYClientCentral_v05.pl script on my mobycentral and an > error > > appeared: > > > > >perl testMOBYCentral_v05.pl > > > > Useless use of hash element in void context > > at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. > > Global symbol "$sth_collection_ins" requires explicit package name > > at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. > > Compilation failed in require at testMOBYCentral_v05.pl line 4. > > BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. > > > > what does it mean? > > The overall configuration of the moby central seemed to be ok, since > the test > > of the same script on the main mobycentral works... > > many thanks > > silvia > > > > > > >-- >"Ontologists do it with the edges!" > >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 PhD. Silvia Scaglione Universita`degli Studi di Genova Facolta' di Ingegneria, D.I.S.T. BioLab Viale Causa, 13 16145 GENOVA - Italy Tel Bio-lab +39 010 353 2789 Tel Centro Biotecnologie Avanzate +39 010 5737 505 Fax +39 010 353 2948 E-mail silvia77@dist.unige.it _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson ...on the road! From harttig at mail.dife.de Tue Aug 2 11:42:38 2005 From: harttig at mail.dife.de (Ulrich Harttig) Date: Tue, 02 Aug 2005 17:42:38 +0200 Subject: [MOBY-l] parameter handling problems Message-ID: <42EF946E.4090708@mail.dife.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have some problems with handling a message to a service asking for an input object and a secondary parameter using the Perl API (and XML::LibXML version 1.58, libxml2 version 2.6.16) After parsing the message with 'complexServiceInputParser()' extraction of the the simple article is no problem but accessing the content of the secondary article with ($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); does not find any content although the $input node contains xml Is there any reason why this shouldn't work ? Could someone point me to examples where accessing parameters works ? Thanks for your help Best regards Ulrich - -- Ulrich Harttig German Institute of Human Nutrition Potsdam-Rehbruecke Dept. of Epidemiology Arthur-Scheunert-Allee 114-116, 14558 Nuthetal, Germany phone: +49 (0)33200 88-729, fax: +49 (0)33200 88-721 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC75RueYdmlKJoHzkRAuKeAJ9QkwlecCYbquhW6W1u1y9arXzPAwCg0pjG 64tQh4osNp61zpuCQYo5VcI= =AOm+ -----END PGP SIGNATURE----- From harttig at mail.dife.de Tue Aug 2 11:42:38 2005 From: harttig at mail.dife.de (Ulrich Harttig) Date: Tue, 02 Aug 2005 17:42:38 +0200 Subject: [MOBY-l] parameter handling problems Message-ID: <42EF946E.4090708@mail.dife.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have some problems with handling a message to a service asking for an input object and a secondary parameter using the Perl API (and XML::LibXML version 1.58, libxml2 version 2.6.16) After parsing the message with 'complexServiceInputParser()' extraction of the the simple article is no problem but accessing the content of the secondary article with ($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); does not find any content although the $input node contains xml Is there any reason why this shouldn't work ? Could someone point me to examples where accessing parameters works ? Thanks for your help Best regards Ulrich - -- Ulrich Harttig German Institute of Human Nutrition Potsdam-Rehbruecke Dept. of Epidemiology Arthur-Scheunert-Allee 114-116, 14558 Nuthetal, Germany phone: +49 (0)33200 88-729, fax: +49 (0)33200 88-721 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC75RueYdmlKJoHzkRAuKeAJ9QkwlecCYbquhW6W1u1y9arXzPAwCg0pjG 64tQh4osNp61zpuCQYo5VcI= =AOm+ -----END PGP SIGNATURE----- From d.haase at gsf.de Wed Aug 3 02:25:20 2005 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 3 Aug 2005 08:25:20 +0200 Subject: [MOBY-l] parameter handling problems In-Reply-To: <42EF946E.4090708@mail.dife.de> References: <42EF946E.4090708@mail.dife.de> Message-ID: <200508030825.20164.d.haase@gsf.de> On Tuesday 02 August 2005 17:42, Ulrich Harttig wrote: > ($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); > > does not find any content although the $input node contains > > > xml > > > Is there any reason why this shouldn't work ? If I remember correctly, I tried the same and didn't work for me neither... > Could someone point me to examples where accessing parameters works ? Here is what works for me: the service takes several secondaries, so it puts all parameter values into a %paramHash: if ( $articleType == SECONDARY ) { my $param = $input->getAttribute('articleName'); my @valueNodes = $input->getChildrenByTagName('moby:Value'); my $value = $valueNodes[0]->textContent(); # there should be only one value $paramHash{$param} = $value; } Hope this helps. Regards, dirk From harttig at mail.dife.de Wed Aug 3 03:48:34 2005 From: harttig at mail.dife.de (Ulrich Harttig) Date: Wed, 03 Aug 2005 09:48:34 +0200 Subject: [MOBY-l] parameter handling problems In-Reply-To: <200508030825.20164.d.haase@gsf.de> References: <42EF946E.4090708@mail.dife.de> <200508030825.20164.d.haase@gsf.de> Message-ID: <42F076D2.8060806@mail.dife.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dirk Haase wrote: > On Tuesday 02 August 2005 17:42, Ulrich Harttig wrote: > > >>($secondary) = getNodeContentWithArticle($input, "Parameter", "VarType"); >> >>does not find any content although the $input node contains >> >> >> xml >> >> >>Is there any reason why this shouldn't work ? > > > If I remember correctly, I tried the same and didn't work for me neither... > > >>Could someone point me to examples where accessing parameters works ? > > > Here is what works for me: the service takes several secondaries, so it puts > all parameter values into a %paramHash: > > if ( $articleType == SECONDARY ) { > my $param = $input->getAttribute('articleName'); > my @valueNodes = $input->getChildrenByTagName('moby:Value'); > my $value = $valueNodes[0]->textContent(); # there should be only one value > $paramHash{$param} = $value; > } > > Hope this helps. > > Regards, > dirk Thanks a lot for the help, your example did work. But I still wondered why $input->getChildrenByTagName('moby:Value') worked but $input->getElementByTagName('moby:Parameter') would not. I was guessing that this had something to do with the structure/content of the node from the secondary article. getElementsByTagName is supposed to return a named descendant of the node. According to the DOM spec: "A descendant node of any node A is any node below A in a tree model, where "below" means "away from the root." But to me it seems that is actually the root of the node , judging by the content of the $input parameter, so one would not be able to find a descendant of the same name. So if I pass instead the original message using the $input->parentNode to the CommonSub function 'getNodeContentWithArticle' it then returns the desired parameter value ($secondary) = getNodeContentWithArticle($input->parentNode, "Parameter", "VarType"); best regards Ulrich - -- Ulrich Harttig German Institute of Human Nutrition Potsdam-Rehbruecke Dept. of Epidemiology Arthur-Scheunert-Allee 114-116, 14558 Nuthetal, Germany phone: +49 (0)33200 88-729, fax: +49 (0)33200 88-721 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFC8HbSeYdmlKJoHzkRAp6ZAJ98gonlRj76yBlZEf8feQYd+fx9QACgtVqI qDx3gY2ljO29ZcdGqy9QZ14= =OuRI -----END PGP SIGNATURE----- From rebecca.ernst at gsf.de Thu Aug 4 03:11:25 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 04 Aug 2005 09:11:25 +0200 Subject: [MOBY-l] Biomoby and Taverna 1.2 Message-ID: <42F1BF9D.6040401@gsf.de> Hi there! It might be boring for you that I start this topic again but the problem still exists and within Planet we are getting in serious problems now and I guess other people will also run into them! Fact is, that old workflows don't work in Taverna 1.2 . According to Tom this is not how it should be, software should always be downwards compatible and that's how I see it, too. Now, due to the fact that it doesn't work but people want to make use of the new, cool features of 1.2 they start developing services which run on 1.2. as you can guess they don't work in 1.1. anymore. It can't be a solution to develop biomoby workflows for every Taverna version so could we please try to solve this problem now before lots of people will have to change their services back and forth ?? If noone (except of Heiko Dirk and me) want the collections to be changed in the BioMoby API we will have to change the default behaviour of Taverna back to the old one! Cheers, Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From senger at ebi.ac.uk Thu Aug 4 03:21:48 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 4 Aug 2005 08:21:48 +0100 (BST) Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1BF9D.6040401@gsf.de> Message-ID: Rebecca, I have talked about it with Eddie when I met him in Malaga about two/three weeks ago. And he promised (!) that he was going to put back the old CreateMoby... and ParseMoby... classes. And I have never heard from him since. So it is very good that you started this topic again - perhaps he is listening :-) Cheers, Martin -- Martin Senger martin.senger at gmail.com International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-580-5600 (ext.2324) From edward.kawas at gmail.com Thu Aug 4 03:24:25 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 4 Aug 2005 00:24:25 -0700 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: Message-ID: <42f1c2c1.6263d1d9.1fa1.67e4@mx.gmail.com> Hi, I have put the old functionality back into Taverna. If you build a fresh copy from the cvs, you will notice (hopefully) that all is well again. Eddie > -----Original Message----- > From: moby-l-bounces at portal.open-bio.org [mailto:moby-l- > bounces at portal.open-bio.org] On Behalf Of Martin Senger > Sent: Thursday, August 04, 2005 12:22 AM > To: Rebecca Ernst > Cc: taverna-users at lists.sourceforge.net; mobyl > Subject: Re: [MOBY-l] Biomoby and Taverna 1.2 > > Rebecca, > I have talked about it with Eddie when I met him in > Malaga about > two/three weeks ago. And he promised (!) that he was going > to put back the > old CreateMoby... and ParseMoby... classes. And I have > never heard from > him since. So it is very good that you started this topic > again - perhaps > he is listening :-) > > Cheers, > Martin > > -- > Martin Senger martin.senger at gmail.com > > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-580-5600 (ext.2324) > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l From markw at illuminae.com Thu Aug 4 03:48:35 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 03:48:35 -0400 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1BF9D.6040401@gsf.de> References: <42F1BF9D.6040401@gsf.de> Message-ID: <1123141715.42f1c853bd83f@webmail.illuminae.com> > If noone (except of Heiko Dirk and me) want the collections to be > changed in the BioMoby API we will have to change the default behaviour > of Taverna back to the old one! I think your use-case for wanting the behaviour of collections to change is unfounded, since it overloads the intended meaning of the Collection element by putting WAAAAAAY too much semantics in it. The use case of having sets of multiple alignments represented as Collections of Collections means that the inner-most Collection now not only represents a "bag" of things, but a "bag" of things that **DO** have a close semantic relationship to each other - these are a set of related sequences, and a set of related sequences **is a useful Object** in the context of MOBY, could easily trigger the discovery of a particular set of services that can specifically operate on sets of closely related sequences (versus sets of unrelated sequences), and therefore should be given a class of its own (IMO). Moreover, if we allow collections of collections, we then have a problem of recursion - collections of collections of collections of collections of collections.... What a nightmare! The API change is not a significant one, I agree... and in fact, since people are already mis-using the messaging format in this way much of the software out there can already handle the situation... but given that particular use-case, I think you are losing more semantics than you need to be by refusing to create a new Object Class. M From tmo at ebi.ac.uk Thu Aug 4 04:06:45 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu, 04 Aug 2005 09:06:45 +0100 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123141715.42f1c853bd83f@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> Message-ID: <42F1CC95.9040803@ebi.ac.uk> markw at illuminae.com wrote: >>If noone (except of Heiko Dirk and me) want the collections to be >>changed in the BioMoby API we will have to change the default behaviour >>of Taverna back to the old one! > > > I think your use-case for wanting the behaviour of collections to change is > unfounded, since it overloads the intended meaning of the Collection element by > putting WAAAAAAY too much semantics in it. The use case of having sets of > multiple alignments represented as Collections of Collections means that the > inner-most Collection now not only represents a "bag" of things, but a "bag" of > things that **DO** have a close semantic relationship to each other - these are > a set of related sequences, and a set of related sequences **is a useful > Object** in the context of MOBY, could easily trigger the discovery of a > particular set of services that can specifically operate on sets of closely > related sequences (versus sets of unrelated sequences), and therefore should be > given a class of its own (IMO). True, but you probably also want to allow, for example, a GC percentage service to run over that set of sets and produce a set of sets of scores - if the set of sequences becomes some opaque type without this information then you can't do this. Strikes me that you need a more sophisticated typing scheme to do this, perhaps extending the Collection concept to allow the imposition of semantics to the group of child objects? I think you do need nested collections though, it's not impossible to deal with (we have some slightly twisted code in Taverna to do it but it works well enough) Tom From rebecca.ernst at gsf.de Thu Aug 4 04:16:35 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 04 Aug 2005 10:16:35 +0200 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123141715.42f1c853bd83f@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> Message-ID: <42F1CEE3.6020901@gsf.de> Hi Mark! I already understood that noone agrees with us ;-) Funny thing is that everyone keeps talking about collections of collections which Dirk never wanted. snip from Dirk: Correct. That's why we did not ask for nested collections. We suggest to allow for multiple Simple output as default - which I think is very appropriate because especially query services will usually return more than one result. This way we would save the collection concept for semantically related entities. I am still not sure if anyone has really understood why we have problems with the collections as they are used now but we are happy to leave them as they are . Although if I think about it I have to ask one more provoking question ( ;-) ) : Why do we have Simples in BioMoby then? I only have VERY few services that give back simples according to the API. From my point of view we could also leave Simples away as they make no sense to me. It is of no valuable information to me if a service gives back exactly three or an unknown number of AGI codes.... But as I said already - if everyone is happy with the current use of collections I will be quiet from now on :-) The problem is then only shiftet to the clients (As seen in Taverna it leaves a much bigger job for the clients as they will have to split the collections) Cheers, Rebecca And you guys in Vancouver would rather go to bed now :-) markw at illuminae.com wrote: >>If noone (except of Heiko Dirk and me) want the collections to be >>changed in the BioMoby API we will have to change the default behaviour >>of Taverna back to the old one! >> >> > >I think your use-case for wanting the behaviour of collections to change is >unfounded, since it overloads the intended meaning of the Collection element by >putting WAAAAAAY too much semantics in it. The use case of having sets of >multiple alignments represented as Collections of Collections means that the >inner-most Collection now not only represents a "bag" of things, but a "bag" of >things that **DO** have a close semantic relationship to each other - these are >a set of related sequences, and a set of related sequences **is a useful >Object** in the context of MOBY, could easily trigger the discovery of a >particular set of services that can specifically operate on sets of closely >related sequences (versus sets of unrelated sequences), and therefore should be >given a class of its own (IMO). > >Moreover, if we allow collections of collections, we then have a problem of >recursion - collections of collections of collections of collections of >collections.... What a nightmare! > >The API change is not a significant one, I agree... and in fact, since people >are already mis-using the messaging format in this way much of the software out >there can already handle the situation... but given that particular use-case, I >think you are losing more semantics than you need to be by refusing to create a >new Object Class. > >M > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Aug 4 04:26:14 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 04:26:14 -0400 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1CEE3.6020901@gsf.de> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> Message-ID: <1123143974.42f1d1268d031@webmail.illuminae.com> Quoting Rebecca Ernst : > And you guys in Vancouver would rather go to bed now :-) Granted, I would rather be in bed, but neither Eddie nor I are in Vancouver so it would be inappropriate :-) we're both just a bit north of you in Manchester! M From markw at illuminae.com Thu Aug 4 04:32:30 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 04:32:30 -0400 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1CC95.9040803@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> Message-ID: <1123144350.42f1d29e7978b@webmail.illuminae.com> Quoting Tom Oinn : > - if the set of sequences becomes some opaque type without this > information then you can't do this. Nothing becomes opaque by putting it in the MOBY data-typing system - it can only get richer and more meaningful by assigning it a specific class :-) Generic services that operate on lower ontological classes will still be discovered and executed, so this use case still fails the test of need. > Strikes me that you need a more > sophisticated typing scheme to do this, perhaps extending the Collection > concept to allow the imposition of semantics to the group of child > objects? Creating a new type of element - limitedCollection or something like that - would be an alternative... or changing the definition of Collection to "zero or more" rather than "one or moe" would also allow us to terminate the recursion. > I think you do need nested collections though, it's not > impossible to deal with (we have some slightly twisted code in Taverna > to do it but it works well enough) Probably we do... but I find it hard to believe that we will have sets of sets of sets of sets where there is no implicit semantic meaning at any level! As soon as there is semantic meaning, it should be a fully qualified MOBY Object rather than an arbitrary collection.... IMO :-) M > > Tom > From markw at illuminae.com Thu Aug 4 04:41:19 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 04:41:19 -0400 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123143974.42f1d1268d031@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> <1123143974.42f1d1268d031@webmail.illuminae.com> Message-ID: <1123144879.42f1d4af9ab8e@webmail.illuminae.com> Quoting markw at illuminae.com: > Granted, I would rather be in bed, but neither Eddie nor I are in Vancouver > so > it would be inappropriate :-) Gosh... I *am* tired! I didn't mean to imply that.... :-/ M From rebecca.ernst at gsf.de Thu Aug 4 04:50:34 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 04 Aug 2005 10:50:34 +0200 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123144879.42f1d4af9ab8e@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> <1123143974.42f1d1268d031@webmail.illuminae.com> <1123144879.42f1d4af9ab8e@webmail.illuminae.com> Message-ID: <42F1D6DA.2060200@gsf.de> Mark wrote: > Gosh... I *am* tired! > I didn't mean to imply that.... > :-/ Hehe - it took me a while to get the meaning 'between the lines' ;-) As you are in Manchestser we have the whole european day to discuss about collections ;-) With Tom you can even chat sitting together if you are so close ... I was thinking about a way to tell you what my problem with this simple and collection thing is and I'll give it a very last try with a trivial example: My favourite example to explain BioMoby services to non- informatics people is that I am a service provider running a laundry. Incoming objects are dirty laundry, out go clean clothes. In your way of interpreting services the man in the laundry gets the information that you are either always bringing exactly 3 shirts to wash or you are bringing a not known number of shirts (one time you bring 2, the next time 15 shirts but it's *always* only shirts) What I am saying is that it *can't* be of any use to this guy to know how many shirts you'll bring - he will have to wash all of them, one by one. But if someone is bringing three complete outfits belonging together (a jacket, a trouser, a shirt and socks ) I need to take care about this relationship and put them back together before giving it back. Does this make sense to you?? Rebecca markw at illuminae.com wrote: >Quoting markw at illuminae.com: > > > >>Granted, I would rather be in bed, but neither Eddie nor I are in Vancouver >>so >>it would be inappropriate :-) >> >> > >Gosh... I *am* tired! > >I didn't mean to imply that.... > >:-/ > >M > > > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From tmo at ebi.ac.uk Thu Aug 4 05:11:51 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu, 04 Aug 2005 10:11:51 +0100 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123144350.42f1d29e7978b@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> Message-ID: <42F1DBD7.4000700@ebi.ac.uk> markw at illuminae.com wrote: > Quoting Tom Oinn : > > >>- if the set of sequences becomes some opaque type without this >>information then you can't do this. > > > Nothing becomes opaque by putting it in the MOBY data-typing system - it can > only get richer and more meaningful by assigning it a specific class :-) > Generic services that operate on lower ontological classes will still be > discovered and executed, so this use case still fails the test of need. Okay, so I might be failing to entirely understand the moby typing system. In the case I describe I need to define a type such that : 1) It can be discovered as 'set of aligned sequences' as a single entity. 2) It can also be discovered as a collection of 'sequence' As I understood it the collection / simple wasn't part of the ontology so this isn't possible? Effectively I believe that 'set of aligned sequences' cannot be made a restriction of 'collection of 'sequence'' as the collection concept isn't part of the ontology - is this wrong? Tom From rebecca.ernst at gsf.de Thu Aug 4 04:58:00 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 04 Aug 2005 10:58:00 +0200 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42f1c2c1.6263d1d9.1fa1.67e4@mx.gmail.com> References: <42f1c2c1.6263d1d9.1fa1.67e4@mx.gmail.com> Message-ID: <42F1D898.7040006@gsf.de> Hi Eddie! that's good news! Thanks a lot for this! Is it possible to update the packaged one also? I don't have a cvs checkout and I guess most of the other people also use the packages. Cheers, Rebecca Edward Kawas wrote: >Hi, > >I have put the old functionality back into Taverna. > >If you build a fresh copy from the cvs, you will notice >(hopefully) that all is well again. > >Eddie > > > >>-----Original Message----- >>From: moby-l-bounces at portal.open-bio.org [mailto:moby-l- >>bounces at portal.open-bio.org] On Behalf Of Martin Senger >>Sent: Thursday, August 04, 2005 12:22 AM >>To: Rebecca Ernst >>Cc: taverna-users at lists.sourceforge.net; mobyl >>Subject: Re: [MOBY-l] Biomoby and Taverna 1.2 >> >>Rebecca, >> I have talked about it with Eddie when I met him in >>Malaga about >>two/three weeks ago. And he promised (!) that he was going >>to put back the >>old CreateMoby... and ParseMoby... classes. And I have >>never heard from >>him since. So it is very good that you started this topic >>again - perhaps >>he is listening :-) >> >> Cheers, >> Martin >> >>-- >>Martin Senger martin.senger at gmail.com >> >>International Rice Research Institute >>Biometrics and Bioinformatics Unit >>DAPO BOX 7777, Metro Manila >>Philippines, phone: +63-580-5600 (ext.2324) >> >>_______________________________________________ >>moby-l mailing list >>moby-l at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-l >> >> > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Aug 4 05:24:08 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 05:24:08 -0400 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1DBD7.4000700@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> Message-ID: <1123147448.42f1deb87303f@webmail.illuminae.com> Quoting Tom Oinn : > 1) It can be discovered as 'set of aligned sequences' as a single entity. > > 2) It can also be discovered as a collection of 'sequence' > > As I understood it the collection / simple wasn't part of the ontology > so this isn't possible? You're correct, and that is a good point! I think that the semantics you lose by making them a simple bag of sequences is more important than the flexibility of service-discovery that you gain. This is why we (Eddie) is working on MOBY Object degradation widgets for Taverna, such that you strip away the outer "semantic" tag and are left with a collection of sequences that could then trigger the latter discovery that you mention above. I don't think we can achieve both situations in one step, unless we defined a parent class "genericSequenceCollection"... but then we would have to do that for all Object classes and our bicycles would explode! M From markw at illuminae.com Thu Aug 4 05:25:38 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Thu, 4 Aug 2005 05:25:38 -0400 Subject: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1D6DA.2060200@gsf.de> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CEE3.6020901@gsf.de> <1123143974.42f1d1268d031@webmail.illuminae.com> <1123144879.42f1d4af9ab8e@webmail.illuminae.com> <42F1D6DA.2060200@gsf.de> Message-ID: <1123147538.42f1df121b200@webmail.illuminae.com> > With Tom you can even chat sitting together if you > are so close ... > England is small... but not THAT small :-) I'll think about your dirty laundry later - must get some other things done! M From tmo at ebi.ac.uk Thu Aug 4 06:03:19 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu, 04 Aug 2005 11:03:19 +0100 Subject: [Taverna-users] Re: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <1123147448.42f1deb87303f@webmail.illuminae.com> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> <1123147448.42f1deb87303f@webmail.illuminae.com> Message-ID: <42F1E7E7.3060109@ebi.ac.uk> markw at illuminae.com wrote: > Quoting Tom Oinn : > > >>1) It can be discovered as 'set of aligned sequences' as a single entity. >> >>2) It can also be discovered as a collection of 'sequence' >> >>As I understood it the collection / simple wasn't part of the ontology >>so this isn't possible? > > You're correct, and that is a good point! Nice to know my brain's working again :) I don't think a decomposition widget is the right way to go - the data in question _is_ a group of sequences, however that's described. If you're using RDF to describe the types can't you express the above? I think there's a misconception that semantic types are the same as classical object types in e.g. Java. In the latter case an entity has exactly one type (ignoring things like interfaces!) and that type then has inheritance and restriction relationships. This causes issues when you want to use that entity in a different way - an example of this is in Taverna's code where we have a type that represents a user interface widget that can bind to a workflow model but we also know that all such widgets are instances of one of the core Java ui classes. Because Java doesn't have multiple inheritance or mixins we can't express this in the Java type system - I believe this is exactly analogous to the case I described above. In the case of a semantic description you can make statements describing the entity, in the current Moby implementation these statements are pretty much hardcoded as 'entity has type foo', which makes them directly equivalent to the types used in languages such as Java, with all the same issues. There's no fundamental reason you need to do this though, with an extension into generalised descriptions you should be able to say 'entity is represented by collection of sequences which are related by...'. The key is to stop thinking of semantic types as being a lazy way of growing an object heirarchy and actually take advantage of their full expressive power. I can appreciate a desire to keep things simple but we have a clear case here where we need something a bit smarter. Could someone, for example Phil, who actually knows what they're talking about on these lists perhaps give an example of how this would look in RDF? I know it's possible to do but a concrete example might be helpful and I don't have the required knowledge. Tom From tmo at ebi.ac.uk Thu Aug 4 06:07:28 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu, 04 Aug 2005 11:07:28 +0100 Subject: [Taverna-users] Re: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1E7E7.3060109@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> <1123147448.42f1deb87303f@webmail.illuminae.com> <42F1E7E7.3060109@ebi.ac.uk> Message-ID: <42F1E8E0.6050102@ebi.ac.uk> Tom Oinn wrote: > Could someone, for example Phil, who actually knows what they're talking > about on these lists perhaps give an example of how this would look in > RDF? Um, that wasn't meant to imply that anyone doesn't know what they're talking about - sounded a bit harsh on re-reading! It would be good to have some input from the mygrid semantics folks though especially as this issue is directly related to the description of services and therefore the mygrid registry activities. Tom From p.lord at cs.man.ac.uk Thu Aug 4 12:17:28 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 04 Aug 2005 17:17:28 +0100 Subject: [Taverna-users] Re: [MOBY-l] Biomoby and Taverna 1.2 In-Reply-To: <42F1E7E7.3060109@ebi.ac.uk> References: <42F1BF9D.6040401@gsf.de> <1123141715.42f1c853bd83f@webmail.illuminae.com> <42F1CC95.9040803@ebi.ac.uk> <1123144350.42f1d29e7978b@webmail.illuminae.com> <42F1DBD7.4000700@ebi.ac.uk> <1123147448.42f1deb87303f@webmail.illuminae.com> <42F1E7E7.3060109@ebi.ac.uk> Message-ID: >>>>> "Tom" == Tom Oinn writes: Tom> Could someone, for example Phil, who actually knows what Tom> they're talking about on these lists perhaps give an example of Tom> how this would look in RDF? I know it's possible to do but a Tom> concrete example might be helpful and I don't have the required Tom> knowledge. I'm not sure that I would make any claims to be the worlds greatest expert on RDF. Actually, I would make claims to not be any kind of expert on RDF. You can certainly express the notion of a collection in RDF. You can put semantic types onto any of the nodes underneath this, and there is very little restriction as to what the types of these things can be. You can state that for a rdf:bag that the first is a dna sequence, the next a protein or whatever. The rdf looks something like a ---- has type ---> bag a ---- li ----> b a ---- li ----> c b ---- hastype -----> dna sequence b ---- hasvalue -----> "GATC" c ---- hastype ---> protein sequence c ---- hasvalue ---> "MAGSYDJ" If you want this level of complexity in moby-s messages then there is no particular problem within representing it in the XML, at least as far as I can see. The problem comes from querying, because people are likely to want to query for services which consume, for example, "DNASequence, or some collection which recursively contains a DNA sequence". Neither moby-central nor feta are going to be terribly happy with performing this sort of query. Phil From bgulden at purdue.edu Thu Aug 4 14:08:12 2005 From: bgulden at purdue.edu (bgulden@purdue.edu) Date: Thu, 4 Aug 2005 13:08:12 -0500 Subject: [MOBY-l] Submitting Parameters Message-ID: <1123178892.42f2598c4e9bf@webmail.purdue.edu> First, I just wanted to thank you all for helping with my previous problems with parameters (The ->secondary function worked perfectly). Now on to my current dilemma. Is there a special way to include parameters in the execution of Moby services? According to the perl API services with parameters should be called in this format where input1 is a primary input and param1 is a secondary input: $Service->execute(XMLinputlist => [ [ 'input1', '', 'param1', '0.001', ] ]); However, when I check the actual inputted data to my service I end up with one tag around both input1 and param1. Thanks, Brian From d.haase at gsf.de Fri Aug 5 04:18:41 2005 From: d.haase at gsf.de (Dirk Haase) Date: Fri, 5 Aug 2005 10:18:41 +0200 Subject: [MOBY-l] Submitting Parameters In-Reply-To: <1123178892.42f2598c4e9bf@webmail.purdue.edu> References: <1123178892.42f2598c4e9bf@webmail.purdue.edu> Message-ID: <200508051018.41494.d.haase@gsf.de> On Thursday 04 August 2005 20:08, bgulden at purdue.edu wrote: > First, I just wanted to thank you all for helping with my previous problems > with parameters (The ->secondary function worked perfectly). Now on to my > current dilemma. > > Is there a special way to include parameters in the execution of Moby > services? According to the perl API services with parameters should be > called in this format where input1 is a primary input and param1 is a > secondary input: $Service->execute(XMLinputlist => [ > [ > 'input1', '', > 'param1', '0.001', > ] > ]); > > However, when I check the actual inputted data to my service I end up with > one tag around both input1 and param1. Hmm, your code seems correct, should actually work... Are you sure the service is correctly registered? Regards, dirk -- ---------------------------------------------------------- Dirk Haase phone +49 89 3187 3583 http://mips.gsf.de/~haase email d.haase at gsf.de From markw at illuminae.com Fri Aug 5 04:28:18 2005 From: markw at illuminae.com (markw@illuminae.com) Date: Fri, 5 Aug 2005 04:28:18 -0400 Subject: [MOBY-l] Submitting Parameters In-Reply-To: <200508051018.41494.d.haase@gsf.de> References: <1123178892.42f2598c4e9bf@webmail.purdue.edu> <200508051018.41494.d.haase@gsf.de> Message-ID: <1123230498.42f323223100a@webmail.illuminae.com> There is a known bug in the current production code relating to the registration of parameters - if any of them have a default, a min, or a max of "0", the registration of that parameter will fail, but the service registration will succeed. This might be what he is seeing. :-/ It is fixed in the new codebase, but we wont be updating the production server for a week or two. M Quoting Dirk Haase : > On Thursday 04 August 2005 20:08, bgulden at purdue.edu wrote: > > First, I just wanted to thank you all for helping with my previous problems > > with parameters (The ->secondary function worked perfectly). Now on to my > > current dilemma. > > > > Is there a special way to include parameters in the execution of Moby > > services? According to the perl API services with parameters should be > > called in this format where input1 is a primary input and param1 is a > > secondary input: $Service->execute(XMLinputlist => [ > > [ > > 'input1', ' id="123"/>', > > 'param1', '0.001', > > ] > > ]); > > > > However, when I check the actual inputted data to my service I end up with > > one tag around both input1 and param1. > > Hmm, your code seems correct, should actually work... Are you sure the > service is correctly registered? > > Regards, > dirk > > -- > > ---------------------------------------------------------- > Dirk Haase phone +49 89 3187 3583 > http://mips.gsf.de/~haase email d.haase at gsf.de > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From edward.kawas at gmail.com Mon Aug 8 09:42:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 8 Aug 2005 06:42:55 -0700 Subject: [MOBY-l] RE: [MOBY-dev] A bug in Taverna 1.2 perhaps related to BioMOBY In-Reply-To: <42F3B988.7020506@cnb.uam.es> Message-ID: <42f76179.195ac951.0c6c.100f@mx.gmail.com> Hi, I think that that has been fixed. I actually noticed that bug when using the Planet workflows. So, like I said, it should be fixed. Out of curiosity, did you cvs build or download a prepackaged Taverna? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Jos? Mar?a > Fern?ndez Gonz?lez > Sent: Friday, August 05, 2005 12:10 PM > To: taverna-users at lists.sourceforge.net; moby- > l at biomoby.org; mobydev; taverna- > hackers at lists.sourceforge.net > Subject: [MOBY-dev] A bug in Taverna 1.2 perhaps related > to BioMOBY > > Hi everybody, > I don't like crossposting, but I don't know if the > bug I have found > today is from the Taverna 1.2 core or the MOBY plugin. > > The bug is pretty simple: if you create/load a > workflow which has a > service whose name in the workflow is different from the > service name, > Taverna does not use the official service name when it is > invoked. > Instead, it uses the name given to the service in the > workflow! The same > workflow works flawlessly when it is loaded and run in > Taverna 1.1. > > I have discovered the bug with a MOBY service (see > the sample workflow > ja5.xml, and the reports taverna-1.1-report.xml and > taverna-1.2-report.xml), so I don't know which has the > blame... > > This bug should arise when one service is used more > than once, which is > very common in real workflows! > > Best Regards, > Jos? Mar?a Fern?ndez > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: > jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 > 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of > Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) From fgibbons at hms.harvard.edu Wed Aug 10 11:37:14 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 10 Aug 2005 11:37:14 -0400 Subject: [MOBY-l] Trouble-ticketing for MOBY; unwanted side effect of MOBY::Client::Service->execute Message-ID: <5.2.1.1.2.20050810112754.011101f8@email.med.harvard.edu> Hi, Two related items: I think MOBY::Client::Service->execute has an unwanted side-effect in that the XMLinputlist argument appears to be modified upon returning from this function. The code does some editing on it. I don't think that would have been a problem had XMLinputlist been passed in as a scalar, but it's passed as an ARRAY ref, and so modifications to it are propagated back to the calling code. This is a problem if, like me, you want to iterate over services calling each one with the same XMLinputlist. (At least, I think that's what's happening - correct me.) How do we fix something like this? Are there regression tests to make sure nothing gets broken when this issue is tackled? Who fixes it? (I'll volunteer) The issue of how to fix this raises the other item: while MOBY is under CVS control, there's no ticketing system (that I'm aware of). As a long-time lurker on this list, I know that most issues just get posted to the list, and then fixed. I think there are a lot advantages to having a centralized, non-email-based record of what needs to be fixed in the future, but also of what was fixed in the past. I'm wondering partly why MOBY isn't on SourceForge (which has a ticketing system for bugs and feature requests, so that potential users can not only see what issues have been fixed, but also what features are likely to appear in the future) - if this has been discussed in the past and resolved, I'd appreciate a pointer. Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Aug 11 12:37:03 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 11 Aug 2005 16:37:03 +0000 GMT Subject: [MOBY-l] Trouble-ticketing for MOBY; unwanted side effect ofMOBY::Client::Service->execute Message-ID: <969787678-1123688248-cardhu_blackberry.rim.net-5970-@engine13-cell01> Hi Frank, Two quick responses (I'm on the blackberry and it isn't very efficient :-) ) 1). The execute method will shortly be significantly changed in light of the upcoming API changes (esp. Insistence on named parameters allows me to use a more sensible "hash" structure in place of the list structure). I don't know if it is worth spending time fixing it. 2). I didn't realize that my code modified the input list. You're right, this is bad. I could post a fix for the such that the input listref is cloned to avoid this (if that is the root of the problem), or you are of course always welcome to fix it yourself and commit. 3). We do have a ticketing system, but nobody ever uses it :-). Click the "bugs" link on the left side of the homepage... I haven't tested it for a while, but it worked last time I tried... Cheers! M -----Original Message----- From: Frank Gibbons Date: Wed, 10 Aug 2005 11:37:14 To:moby-l at biomoby.org Subject: [MOBY-l] Trouble-ticketing for MOBY; unwanted side effect of MOBY::Client::Service->execute Hi, Two related items: I think MOBY::Client::Service->execute has an unwanted side-effect in that the XMLinputlist argument appears to be modified upon returning from this function. The code does some editing on it. I don't think that would have been a problem had XMLinputlist been passed in as a scalar, but it's passed as an ARRAY ref, and so modifications to it are propagated back to the calling code. This is a problem if, like me, you want to iterate over services calling each one with the same XMLinputlist. (At least, I think that's what's happening - correct me.) How do we fix something like this? Are there regression tests to make sure nothing gets broken when this issue is tackled? Who fixes it? (I'll volunteer) The issue of how to fix this raises the other item: while MOBY is under CVS control, there's no ticketing system (that I'm aware of). As a long-time lurker on this list, I know that most issues just get posted to the list, and then fixed. I think there are a lot advantages to having a centralized, non-email-based record of what needs to be fixed in the future, but also of what was fixed in the past. I'm wondering partly why MOBY isn't on SourceForge (which has a ticketing system for bugs and feature requests, so that potential users can not only see what issues have been fixed, but also what features are likely to appear in the future) - if this has been discussed in the past and resolved, I'd appreciate a pointer. Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson ...on the road! From p.lord at cs.man.ac.uk Mon Aug 15 05:35:58 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 15 Aug 2005 10:35:58 +0100 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> Message-ID: <87y873v8xt.fsf@rpc71.cs.man.ac.uk> >>>>> "Boris" == Boris Steipe writes: Boris> Why not put the burden of the lease on the agent to combine Boris> the advantages of both models? I.e. if service is down for Boris> less then a specific time, it might not get deregistered but Boris> only flagged as temporarily unavailable ... then un-flagged Boris> as it comes up again, except if it's down for, say > 1week, Boris> then it gets deregistered. Boris> $0.02 Actually, this is just a modification of the agent idea, and not a lease at all. The idea of a lease is not just a burden on the service provide, but it also has a positive advantage. It give the service provide the ability to control how long they want the service advertised for in the registry. Of course, they can do the same thing with the agent, more or less; they just remove the RDF document after a certain time, although, they don't know exactly when the agent will remove them. At the end of the day, I am not sure that the two mechanisms are hugely different in terms of their functionality. It seems to me that the lease puts slightly more weight on the service provider, but will provide better garbage collection (just become someone leaves an RDF document on the web, does not mean that their service is actually still up). Phil From p.lord at cs.man.ac.uk Mon Aug 15 05:38:32 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 15 Aug 2005 10:38:32 +0100 Subject: [MOBY-l] Re: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> Message-ID: <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> >>>>> "Mark" == Mark Wilkinson writes: Mark> We're certainly of like-mind at this end, though certain Mark> people ;-) at myGrid think that the agent is the wrong way to Mark> go... I just don't see it. IMO a leasing model would be akin Mark> to leasing space in Google! The lease is the more common idiom, I think. I don't think that there is a huge difference. My main criticism of the agent is that there does not seem to be a different connection between the agent poll and the service being available. Phil From tmo at ebi.ac.uk Mon Aug 15 05:51:26 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 15 Aug 2005 10:51:26 +0100 Subject: [MOBY-l] Re: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> Message-ID: <4300659E.3050808@ebi.ac.uk> Phillip Lord wrote: >>>>>>"Mark" == Mark Wilkinson writes: > > > Mark> We're certainly of like-mind at this end, though certain > Mark> people ;-) at myGrid think that the agent is the wrong way to > Mark> go... I just don't see it. IMO a leasing model would be akin > Mark> to leasing space in Google! > > The lease is the more common idiom, I think. I don't think that there > is a huge difference. My main criticism of the agent is that there > does not seem to be a different connection between the agent poll and > the service being available. Much as I hate* to agree with Phil I, um, do :) Seems to me that the agent approach is more part of a monitoring framework than a registry, I don't know offhand whether we're planning to include metrics such as service liveness and response times as transient metadata in the registry but that's where I'd see agents fitting in rather than in the initial registration. Tom * it's all an act but hey... From p.lord at cs.man.ac.uk Mon Aug 15 06:00:53 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 15 Aug 2005 11:00:53 +0100 Subject: [MOBY-l] Re: [moby] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4300659E.3050808@ebi.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <1123879295.15335.30.camel@bioinfo.icapture.ubc.ca> <42FD1362.8000107@ucalgary.ca> <1123885110.15335.52.camel@bioinfo.icapture.ubc.ca> <87slxbv8tj.fsf@rpc71.cs.man.ac.uk> <4300659E.3050808@ebi.ac.uk> Message-ID: <87k6inv7sa.fsf@rpc71.cs.man.ac.uk> >>>>> "Tom" == Tom Oinn writes: Tom> Phillip Lord wrote: >>>>>>> "Mark" == Mark Wilkinson writes: Mark> We're certainly of like-mind at this end, though certain Mark> people ;-) at myGrid think that the agent is the wrong way to Mark> go... I just don't see it. IMO a leasing model would be akin Mark> to leasing space in Google! >> The lease is the more common idiom, I think. I don't think that >> there is a huge difference. My main criticism of the agent is >> that there does not seem to be a different connection between the >> agent poll and the service being available. Tom> Much as I hate* to agree with Phil I, um, do :) Seems to me Tom> that the agent approach is more part of a monitoring framework It might be if it monitored the service rather than something else! Tom> than a registry, I don't know offhand whether we're planning to Tom> include metrics such as service liveness and response times as Tom> transient metadata in the registry but that's where I'd see Tom> agents fitting in rather than in the initial registration. The current approach that feta takes to the "registry" is that it is a very dumb thing. It really only uses it for storing files (which is why it uses a webdav backend by default). It would be lovely to replace or augment this with something richer, which understood liveness and response. Or, alternatively, have a modular search system which could combine responses from feta and some arbitrary service search system based on information about liveness. It's all very feasible. Even a simple minded response time data model would help a lot. Phil From gordonp at ucalgary.ca Mon Aug 15 10:32:26 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 15 Aug 2005 08:32:26 -0600 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87y873v8xt.fsf@rpc71.cs.man.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> Message-ID: <4300A77A.8030806@ucalgary.ca> A few advantages of the lease are not really advantages in practice: 1. No one will manually update their lease, they will put it in a cron job. Therefore you either need to edit your crontab, or remove from the RDF file in the agent case. Both are just as likely to be ignored by an administrator when a service stops working. 2. Specifiying that the service is valid for a certain amount of time is mostly useful for testing purposes. You should really be using a test registry in that case, not posting dubious services to the production server. The chief advantages of the agent are: 1. You can trace the registration and deregistration of a service to a particular domain name. It's not great security, but at the very least people require some serious work to pose as the NCBI on purpose (by hacking their Web domain), and cannot by mistake (e.g. "I registered my service using the NCBI authority ID because I'm using gi's"). 2. The RDF for the services does not have a single point of failure (i.e. the central registry). The one agent feature I would l;ike though is that I can call MOBY Central to tell it that I've changed my RDF, i.e. pushing a refresh. It's not critical though. If the agent runs once a day, you may get some latency on bad services, but it's not the end of the world. Tim Berners-Lee got a lot of flack for his Web idea because it didn't enforce that what people linked to existed. "People won't use it, they may end up at dead links!" they said... >>>>>>"Boris" == Boris Steipe writes: >>>>>> >>>>>> > > Boris> Why not put the burden of the lease on the agent to combine > Boris> the advantages of both models? I.e. if service is down for > Boris> less then a specific time, it might not get deregistered but > Boris> only flagged as temporarily unavailable ... then un-flagged > Boris> as it comes up again, except if it's down for, say > 1week, > Boris> then it gets deregistered. > > Boris> $0.02 > > >Actually, this is just a modification of the agent idea, and not a >lease at all. > >The idea of a lease is not just a burden on the service provide, but >it also has a positive advantage. It give the service provide the >ability to control how long they want the service advertised for in >the registry. Of course, they can do the same thing with the agent, >more or less; they just remove the RDF document after a certain time, >although, they don't know exactly when the agent will remove them. > >At the end of the day, I am not sure that the two mechanisms are >hugely different in terms of their functionality. It seems to me that >the lease puts slightly more weight on the service provider, but will >provide better garbage collection (just become someone leaves an RDF >document on the web, does not mean that their service is actually >still up). > >Phil > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From jmfernandez at cnb.uam.es Fri Aug 5 15:10:00 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 05 Aug 2005 21:10:00 +0200 Subject: [MOBY-l] A bug in Taverna 1.2 perhaps related to BioMOBY Message-ID: <42F3B988.7020506@cnb.uam.es> Hi everybody, I don't like crossposting, but I don't know if the bug I have found today is from the Taverna 1.2 core or the MOBY plugin. The bug is pretty simple: if you create/load a workflow which has a service whose name in the workflow is different from the service name, Taverna does not use the official service name when it is invoked. Instead, it uses the name given to the service in the workflow! The same workflow works flawlessly when it is loaded and run in Taverna 1.1. I have discovered the bug with a MOBY service (see the sample workflow ja5.xml, and the reports taverna-1.1-report.xml and taverna-1.2-report.xml), so I don't know which has the blame... This bug should arise when one service is used more than once, which is very common in real workflows! Best Regards, Jos? Mar?a Fern?ndez -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From p.lord at cs.man.ac.uk Tue Aug 16 06:02:52 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 16 Aug 2005 11:02:52 +0100 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4300A77A.8030806@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> Message-ID: <87mzni8aib.fsf@rpc71.cs.man.ac.uk> >>>>> "Paul" == Paul Gordon writes: Paul> A few advantages of the lease are not really advantages in Paul> practice: Paul> 1. No one will manually update their lease, they will put it Paul> in a cron Paul> job. Therefore you either need to edit your crontab, or Paul> remove from the RDF file in the agent case. Both are just as Paul> likely to be ignored by an administrator when a service stops Paul> working. This is a necessary problem with neither the agent nor the lease. It is a current problem with the implementation of the agent. All you do is add a call back to the service. Paul> 2. Specifiying that the service is valid for a certain amount Paul> of time Paul> is mostly useful for testing purposes. You should really be Paul> using a test registry in that case, not posting dubious Paul> services to the production server. Not really. Take, for example, the SOAPLAB services Martin developed as part of mygrid. When the toolkit was first produced, it was deployed on our own servers; now it is supported by EBI's external services. Clearly, the latter is likely to produce a better uptime than the former. Hence, EBI might use a month long lease. Neither of these services were testing. But they did come with different levels of support. Paul> The chief advantages of the agent are: Paul> 1. You can trace the registration and deregistration of a Paul> service to Paul> a particular domain name. It's not great security, but at the Paul> very least people require some serious work to pose as the Paul> NCBI on purpose (by hacking their Web domain), and cannot by Paul> mistake (e.g. "I registered my service using the NCBI Paul> authority ID because I'm using gi's"). Likewise with a lease call back system. Anyway, can you really not determine the start point of a web services call? Paul> 2. The RDF for the services does not have a single point of Paul> failure Paul> (i.e. the central registry). This is also untrue. There is nothing to stop a lease percolating through a set of federated registries. With the agent, you have to percolate the registered URL's (or the RDF) in the same way. Ultimately, as two systems are doing similar things. It's just that one is push and the other pull. Paul> The one agent feature I would l;ike though is that I can call Paul> MOBY Central to tell it that I've changed my RDF, i.e. pushing Paul> a refresh. It's not critical though. If the agent runs once a Paul> day, you may get some latency on bad services, but it's not Paul> the end of the world. Tim Berners-Lee got a lot of flack for Paul> his Web idea because it didn't enforce that what people linked Paul> to existed. "People won't use it, they may end up at dead Paul> links!" they said... You still want people to be able to search on the freshness of information though. With a lease, you can add queries to moby-central to say "give me only services with a current lease"--after all the registry is not required to deregister a service when it's lease runs out. Cheers Phil From gordonp at ucalgary.ca Tue Aug 16 09:51:08 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 16 Aug 2005 07:51:08 -0600 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87mzni8aib.fsf@rpc71.cs.man.ac.uk> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> Message-ID: <4301EF4C.5020506@ucalgary.ca> My CAN$0.02 :-) > > Paul> A few advantages of the lease are not really advantages in > Paul> practice: > > Paul> 1. No one will manually update their lease, they will put it > Paul> in a cron > Paul> job. Therefore you either need to edit your crontab, or > Paul> remove from the RDF file in the agent case. Both are just as > Paul> likely to be ignored by an administrator when a service stops > Paul> working. > > >This is a necessary problem with neither the agent nor the lease. It >is a current problem with the implementation of the agent. All you do >is add a call back to the service. > > This turns into an issue with the protocol, we would need to require (when you register a service) test cases that return predictable, non-null value. This was discussed at the last MOBY meeting, but I don't think anything came of it. Or am I wrong? > Paul> The chief advantages of the agent are: > > Paul> 1. You can trace the registration and deregistration of a > Paul> service to > Paul> a particular domain name. It's not great security, but at the > Paul> very least people require some serious work to pose as the > Paul> NCBI on purpose (by hacking their Web domain), and cannot by > Paul> mistake (e.g. "I registered my service using the NCBI > Paul> authority ID because I'm using gi's"). > >Likewise with a lease call back system. > Like you said, the two approches aren't so different, because fetching the RDF from the server is a callback of sorts. >Anyway, can you really not >determine the start point of a web services call? > > If there are proxies, multiple host names for a machine (e.g. the host I'm on right now is www.visualgenomics.ca, moby.ucalgary.ca, www.gcbioinformatics.ca, and about 6 other names), it can get complicated. > Paul> 2. The RDF for the services does not have a single point of > Paul> failure > Paul> (i.e. the central registry). > >This is also untrue. There is nothing to stop a lease percolating >through a set of federated registries. With the agent, you have to >percolate the registered URL's (or the RDF) in the same way. > > True, but the mechanism to exchange a URL list could be simpler than mirroring the entire registry, and is less subject to error propagation (e.g. don't blindly copy a goof in the main mirror's database system because it had network connectivity issues, fetch the RDF yourself) . If we're lucky, people will try to outcompete each other creating the most robust registry :-) >Ultimately, as two systems are doing similar things. It's just that >one is push and the other pull. > > > Paul> The one agent feature I would l;ike though is that I can call > Paul> MOBY Central to tell it that I've changed my RDF, i.e. pushing > Paul> a refresh. It's not critical though. If the agent runs once a > Paul> day, you may get some latency on bad services, but it's not > Paul> the end of the world. Tim Berners-Lee got a lot of flack for > Paul> his Web idea because it didn't enforce that what people linked > Paul> to existed. "People won't use it, they may end up at dead > Paul> links!" they said... > > >You still want people to be able to search on the freshness of >information though. With a lease, you can add queries to moby-central >to say "give me only services with a current lease"--after all the >registry is not required to deregister a service when it's lease runs >out. > > Would we set a maximum lease? I'd probably give myself a 1 year lease so that I wouldn't be bothered again. That doesn't make me check that the service works throughout the year though. IMHO, having a test case checked regularly is what really helps here, not the lease. A lease is someone's word, a test case is action, and actions speak louder than words :-) >Cheers > >Phil > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From edward.kawas at gmail.com Tue Aug 16 12:26:42 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Tue, 16 Aug 2005 11:26:42 -0500 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4301EF4C.5020506@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> Message-ID: I just wanted to say that I agree with Paul. I think that when a provider registers a service, the provider enters a url that causes the service to return something that is commonly returned by all services that states that the service is running. If this return value is infact returned, then the service signature is processed. Otherwise, the offending service is recorded and the service is not shown to the public until the test passes. If after x times the test fails, then it is permanently removed. Eddie On 8/16/05, Paul Gordon wrote: > My CAN$0.02 :-) > > > > > Paul> A few advantages of the lease are not really advantages in > > Paul> practice: > > > > Paul> 1. No one will manually update their lease, they will put it > > Paul> in a cron > > Paul> job. Therefore you either need to edit your crontab, or > > Paul> remove from the RDF file in the agent case. Both are just as > > Paul> likely to be ignored by an administrator when a service stops > > Paul> working. > > > > > >This is a necessary problem with neither the agent nor the lease. It > >is a current problem with the implementation of the agent. All you do > >is add a call back to the service. > > > > > This turns into an issue with the protocol, we would need to require > (when you register a service) test cases that return predictable, > non-null value. This was discussed at the last MOBY meeting, but I > don't think anything came of it. Or am I wrong? > > > Paul> The chief advantages of the agent are: > > > > Paul> 1. You can trace the registration and deregistration of a > > Paul> service to > > Paul> a particular domain name. It's not great security, but at the > > Paul> very least people require some serious work to pose as the > > Paul> NCBI on purpose (by hacking their Web domain), and cannot by > > Paul> mistake (e.g. "I registered my service using the NCBI > > Paul> authority ID because I'm using gi's"). > > > >Likewise with a lease call back system. > > > Like you said, the two approches aren't so different, because fetching > the RDF from the server is a callback of sorts. > > >Anyway, can you really not > >determine the start point of a web services call? > > > > > If there are proxies, multiple host names for a machine (e.g. the host > I'm on right now is www.visualgenomics.ca, moby.ucalgary.ca, > www.gcbioinformatics.ca, and about 6 other names), it can get complicated. > > > Paul> 2. The RDF for the services does not have a single point of > > Paul> failure > > Paul> (i.e. the central registry). > > > >This is also untrue. There is nothing to stop a lease percolating > >through a set of federated registries. With the agent, you have to > >percolate the registered URL's (or the RDF) in the same way. > > > > > True, but the mechanism to exchange a URL list could be simpler than > mirroring the entire registry, and is less subject to error propagation > (e.g. don't blindly copy a goof in the main mirror's database system > because it had network connectivity issues, fetch the RDF yourself) . > If we're lucky, people will try to outcompete each other creating the > most robust registry :-) > > >Ultimately, as two systems are doing similar things. It's just that > >one is push and the other pull. > > > > > > Paul> The one agent feature I would l;ike though is that I can call > > Paul> MOBY Central to tell it that I've changed my RDF, i.e. pushing > > Paul> a refresh. It's not critical though. If the agent runs once a > > Paul> day, you may get some latency on bad services, but it's not > > Paul> the end of the world. Tim Berners-Lee got a lot of flack for > > Paul> his Web idea because it didn't enforce that what people linked > > Paul> to existed. "People won't use it, they may end up at dead > > Paul> links!" they said... > > > > > >You still want people to be able to search on the freshness of > >information though. With a lease, you can add queries to moby-central > >to say "give me only services with a current lease"--after all the > >registry is not required to deregister a service when it's lease runs > >out. > > > > > Would we set a maximum lease? I'd probably give myself a 1 year lease > so that I wouldn't be bothered again. That doesn't make me check that > the service works throughout the year though. IMHO, having a test case > checked regularly is what really helps here, not the lease. A lease is > someone's word, a test case is action, and actions speak louder than > words :-) > > >Cheers > > > >Phil > > > >_______________________________________________ > >moby-l mailing list > >moby-l at biomoby.org > >http://biomoby.org/mailman/listinfo/moby-l > > > > > > > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From p.lord at cs.man.ac.uk Tue Aug 16 13:15:29 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 16 Aug 2005 18:15:29 +0100 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4301EF4C.5020506@ucalgary.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> Message-ID: <87ek8tpzv2.fsf@rpc71.cs.man.ac.uk> >>>>> "Paul" == Paul Gordon writes: >> This is a necessary problem with neither the agent nor the >> lease. It is a current problem with the implementation of the >> agent. All you do is add a call back to the service. Paul> This turns into an issue with the protocol, we would need to Paul> require (when you register a service) test cases that return Paul> predictable, non-null value. This was discussed at the last Paul> MOBY meeting, but I don't think anything came of it. Or am I Paul> wrong? I can't comment on this really, because I wasn't there! Paul> 1. You can trace the registration and deregistration of a Paul> service to a particular domain name. It's not great security, Paul> but at the very least people require some serious work to pose Paul> as the NCBI on purpose (by hacking their Web domain), and Paul> cannot by mistake (e.g. "I registered my service using the Paul> NCBI authority ID because I'm using gi's"). >> >> Likewise with a lease call back system. Paul> Like you said, the two approches aren't so different, because Paul> fetching the RDF from the server is a callback of sorts. In a sense. It's just that you don't know when it is going to happen. This is the point with a lease. The client requests from the server a time limited registration. Is it possible for the client to query MOBY-Central and ask how often the RDF agent will call? Is it possible to request that it happens more frequently or less? >> Anyway, can you really not determine the start point of a web >> services call? Paul> If there are proxies, multiple host names for a machine Paul> (e.g. the host I'm on right now is www.visualgenomics.ca, Paul> moby.ucalgary.ca, www.gcbioinformatics.ca, and about 6 other Paul> names), it can get complicated. Or 136.159.169.6 or h6.net169.ucalgary.ca. The IP number is unique though. Paul> 2. The RDF for the services does not have a single point of Paul> failure (i.e. the central registry). >> >> This is also untrue. There is nothing to stop a lease percolating >> through a set of federated registries. With the agent, you have >> to percolate the registered URL's (or the RDF) in the same way. Paul> True, but the mechanism to exchange a URL list could be Paul> simpler than mirroring the entire registry, and is less Paul> subject to error propagation (e.g. don't blindly copy a goof Paul> in the main mirror's database system because it had network Paul> connectivity issues, fetch the RDF yourself) . If we're Paul> lucky, people will try to outcompete each other creating the Paul> most robust registry :-) Who says that the lease is not encoded as a URL? Besides which, the lease mechanism might federate by passing around data. Or the client might explicitly register in more than one registry. Again, I don't think that this is a necessary advantage of either a lease or the agent. >> You still want people to be able to search on the freshness of >> information though. With a lease, you can add queries to >> moby-central to say "give me only services with a current >> lease"--after all the registry is not required to deregister a >> service when it's lease runs out. Paul> Would we set a maximum lease? I'd probably give myself a 1 Paul> year lease so that I wouldn't be bothered again. Yes, this is part of the basic idea behind a lease. The registry overs a specific contract which describes what it is prepared to do for you. Paul> That doesn't make me check that the service works throughout Paul> the year though. IMHO, having a test case checked regularly is Paul> what really helps here, not the lease. A lease is someone's Paul> word, a test case is action, and actions speak louder than Paul> words :-) As Tom says, service liveness or quality data is not the same thing as registration, but an orthogonal issue to it. Having service quality data would be a nice addition to moby-central. Phil From goodb at interchange.ubc.ca Tue Aug 16 13:18:47 2005 From: goodb at interchange.ubc.ca (Benjamin Good) Date: Tue, 16 Aug 2005 10:18:47 -0700 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> Message-ID: <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> Just to add my 2c. The idea of adding a test case to the registration phase did come up at the meeting, but I'm not sure how far its gotten? I would suggest that this test actually be an instance of the moby datatype registered as the input of the service - instead of a URL. This would let any moby-capable client test the service whenever necessary using exactly the same protocol required to run the service in the usual case. Having this possibility makes it feasible for client providers to filter out inconsistent services without relying entirely on the registry to do so. This enables a runtime check on the service that seems impossible using only the registry. The agent could then use this same check to make its decision about whether to keep the service listed or not.. - Ben On Aug 16, 2005, at 9:26 AM, Eddie Kawas wrote: > I just wanted to say that I agree with Paul. > > I think that when a provider registers a service, the provider enters > a url that causes the service to return something that is commonly > returned by all services that states that the service is running. If > this return value is infact returned, then the service signature is > processed. Otherwise, the offending service is recorded and the > service is not shown to the public until the test passes. If after x > times the test fails, then it is permanently removed. > > Eddie > > > On 8/16/05, Paul Gordon wrote: > >> My CAN$0.02 :-) >> >> >>> >>> Paul> A few advantages of the lease are not really advantages in >>> Paul> practice: >>> >>> Paul> 1. No one will manually update their lease, they will put it >>> Paul> in a cron >>> Paul> job. Therefore you either need to edit your crontab, or >>> Paul> remove from the RDF file in the agent case. Both are just as >>> Paul> likely to be ignored by an administrator when a service stops >>> Paul> working. >>> >>> >>> This is a necessary problem with neither the agent nor the lease. It >>> is a current problem with the implementation of the agent. All >>> you do >>> is add a call back to the service. >>> >>> >>> >> This turns into an issue with the protocol, we would need to require >> (when you register a service) test cases that return predictable, >> non-null value. This was discussed at the last MOBY meeting, but I >> don't think anything came of it. Or am I wrong? >> >> >>> Paul> The chief advantages of the agent are: >>> >>> Paul> 1. You can trace the registration and deregistration of a >>> Paul> service to >>> Paul> a particular domain name. It's not great security, but at >>> the >>> Paul> very least people require some serious work to pose as the >>> Paul> NCBI on purpose (by hacking their Web domain), and cannot by >>> Paul> mistake (e.g. "I registered my service using the NCBI >>> Paul> authority ID because I'm using gi's"). >>> >>> Likewise with a lease call back system. >>> >>> >> Like you said, the two approches aren't so different, because >> fetching >> the RDF from the server is a callback of sorts. >> >> >>> Anyway, can you really not >>> determine the start point of a web services call? >>> >>> >>> >> If there are proxies, multiple host names for a machine (e.g. the >> host >> I'm on right now is www.visualgenomics.ca, moby.ucalgary.ca, >> www.gcbioinformatics.ca, and about 6 other names), it can get >> complicated. >> >> >>> Paul> 2. The RDF for the services does not have a single point of >>> Paul> failure >>> Paul> (i.e. the central registry). >>> >>> This is also untrue. There is nothing to stop a lease percolating >>> through a set of federated registries. With the agent, you have to >>> percolate the registered URL's (or the RDF) in the same way. >>> >>> >>> >> True, but the mechanism to exchange a URL list could be simpler than >> mirroring the entire registry, and is less subject to error >> propagation >> (e.g. don't blindly copy a goof in the main mirror's database system >> because it had network connectivity issues, fetch the RDF yourself) . >> If we're lucky, people will try to outcompete each other creating the >> most robust registry :-) >> >> >>> Ultimately, as two systems are doing similar things. It's just that >>> one is push and the other pull. >>> >>> >>> Paul> The one agent feature I would l;ike though is that I can call >>> Paul> MOBY Central to tell it that I've changed my RDF, i.e. >>> pushing >>> Paul> a refresh. It's not critical though. If the agent runs once a >>> Paul> day, you may get some latency on bad services, but it's not >>> Paul> the end of the world. Tim Berners-Lee got a lot of flack for >>> Paul> his Web idea because it didn't enforce that what people >>> linked >>> Paul> to existed. "People won't use it, they may end up at dead >>> Paul> links!" they said... >>> >>> >>> You still want people to be able to search on the freshness of >>> information though. With a lease, you can add queries to moby- >>> central >>> to say "give me only services with a current lease"--after all the >>> registry is not required to deregister a service when it's lease >>> runs >>> out. >>> >>> >>> >> Would we set a maximum lease? I'd probably give myself a 1 year >> lease >> so that I wouldn't be bothered again. That doesn't make me check >> that >> the service works throughout the year though. IMHO, having a test >> case >> checked regularly is what really helps here, not the lease. A >> lease is >> someone's word, a test case is action, and actions speak louder than >> words :-) >> >> >>> Cheers >>> >>> Phil >>> >>> _______________________________________________ >>> moby-l mailing list >>> moby-l at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-l >>> >>> >>> >>> >> >> _______________________________________________ >> moby-l mailing list >> moby-l at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-l >> >> > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > > From markw at illuminae.com Tue Aug 16 13:36:25 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 16 Aug 2005 10:36:25 -0700 Subject: [moby] Re: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> References: <6241454D-0B6A-11DA-A8DF-000A9577512E@utoronto.ca> <87y873v8xt.fsf@rpc71.cs.man.ac.uk> <4300A77A.8030806@ucalgary.ca> <87mzni8aib.fsf@rpc71.cs.man.ac.uk> <4301EF4C.5020506@ucalgary.ca> <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> Message-ID: <1124213785.18621.138.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-08-16 at 10:18 -0700, Benjamin Good wrote: > Just to add my 2c. The idea of adding a test case to the > registration phase did come up at the meeting, but I'm not sure how > far its gotten? It was decided that test cases would be provided as optional additional metadata attached to the RDF Service Signature on the service-providers site, identified by a set of (yet to be defined) RDF predicates. Test cases would *not* be part of the data stored in the registry, but would be discoverable through e.g. LSID resolution. Since we are currently in the process of adapting our Service Signature data model to mimic that of myGrid (and v.v. :-) ) we have not yet implemented this particular decision. Hopefully this data model will be firmed-up in the next couple of weeks (that was why Eddie and I were in Manchester last week), and then we will be able to generate a "canonical" Service Signature for everyone's existing services, as well as generate the signature on-the-fly for new registrations. M -- "Ontologists do it with the edges!" 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 From senger at ebi.ac.uk Tue Aug 16 20:10:24 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 17 Aug 2005 01:10:24 +0100 (BST) Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <4784EB52-25CB-4260-A779-72918248ECB4@interchange.ubc.ca> Message-ID: Hi all, Everybody is talking about lease and agents so if I do not join I would feel like a pariah... What was the original problem that started this discussion? I remember two: a) How to make a deregistration secure (so nobody can easily remove my service from a registry), and b) How I can remove my service registration at any time when I *want* to do it. Am I right - is this (at least) the problems we are trying to solve? (I understand that during this discussion a new problem was born - how to test that a service is reliable; but I consider it as a separate issue.) Obviously problem b) requires an action on my side. In case of agent it is a removal of an RDF document - and hopefully supported by a new method in the registry API calling an agent to come to me *now*. This new API call was mentioned and I hope it will happen. Without it the agent solution is weak (IMHO) - having the similar weakness as Google has with non existing links/documents (oh, wow, now I really feel like a pariah by saying that Google has a weakness!) In case of lease - is there a concept of making a lease to expire before its planned end? If so, how is it done that nobody else can do it except me (problem a))? Can you, Phill perhaps, explain me if the lease can solve my two problems above? So far I understand that an agent can - assuming tghat there will be that new API call (Mark, Eddie, will this be - in case the agent idea is accepted?) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From p.lord at cs.man.ac.uk Wed Aug 17 06:23:18 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 17 Aug 2005 11:23:18 +0100 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: References: Message-ID: <87vf246ew9.fsf@rpc71.cs.man.ac.uk> >>>>> "Martin" == Martin Senger writes: Martin> Hi all, Martin> Everybody is talking about lease and agents so if I do Martin> not join I would Martin> feel like a pariah... Martin> What was the original problem that started this Martin> discussion? I remember Martin> two: Martin> a) How to make a deregistration secure (so nobody can easily Martin> remove my Martin> service from a registry), and Martin> b) How I can remove my service registration at any time when Martin> I *want* Martin> to do it. Martin> Am I right - is this (at least) the problems we are Martin> trying to solve? (I Martin> understand that during this discussion a new problem was Martin> born - how to test that a service is reliable; but I Martin> consider it as a separate issue.) Martin> Obviously problem b) requires an action on my side. In Martin> case of agent it is a removal of an RDF document - and Martin> hopefully Martin> supported by a new method in the registry API calling an Martin> agent to come to me *now*. This new API call was mentioned Martin> and I hope it will happen. Actually, there is a minor security problem here. If I call this method repeatedly and it really happens *now*, then I can use moby-central as a proxy to launch a denial of service attack on a third party. If I did this on NCBI, for example, it might have interesting repercussions for who ever is hosting the moby-central. Martin> Without it the agent solution is weak (IMHO) - having the Martin> similar weakness as Google has with non existing Martin> links/documents (oh, wow, now I really feel like a pariah by Martin> saying that Google has a weakness!) Martin> In case of lease - is there a concept of making a lease Martin> to expire Martin> before its planned end? If so, how is it done that nobody Martin> else can do it except me (problem a))? Not really sure on this one, to be honest. Clearly, you can just set up a short lease in the first place. Alternatively, you pass back some magic cookie when the lease is taken out in the first place, that is required for deregistration. This enables deregistration to be done from anywhere, rather than through direct control of the RDF URL, but still only by the originator. The ideal would, of course, to have some off the shelf library for doing leases. Martin> Can you, Phill perhaps, explain me if the lease can solve Martin> my two Martin> problems above? So far I understand that an agent can - Martin> assuming tghat there will be that new API call (Mark, Eddie, Martin> will this be - in case the agent idea is accepted?) Does this make sense? Phil From senger at ebi.ac.uk Wed Aug 17 10:57:47 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 17 Aug 2005 15:57:47 +0100 (BST) Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <87vf246ew9.fsf@rpc71.cs.man.ac.uk> Message-ID: > Actually, there is a minor security problem here. If I call this > method repeatedly and it really happens *now* > You are exaggerating (how to spell this word?). The agent can be clever enough not to go really *now" but only in a reasonably but short intervals (once a minute maximum, for example). > Not really sure on this one, to be honest. Clearly, you can just set > up a short lease in the first place. > Yes, that make sense. Or perhaps, I could re-register again with a different lease, right? > Alternatively, you pass back some magic cookie when the lease is taken > out in the first place, that is required for deregistration. > Well, this is exactly what biomoby has now - and nobody seems to like it. That's why we are talking how to change it. Thanks, Phill, for claryfying the issue (at least in my mind). I feel now that a lease gives me more control (if and only if I can re-register with a different lease anytime). And an agent plays a role of an independent observer that can stop my registration if it finds that there is something wrong with it (not running, not found RDF etc.). But the problem is still with the "if and only if" in the previous paragraph I think. If I can re-register and change the lease, probably anybody can do it - and to remove/hijack my registration. And we are back where we started.... So the above would work only if I can prove who I am. And the only way how to do it (if we do not want to introduce passwords etc.) is to let somebody come back to my place (because only I can control such a place). That means an agent... So: if I use a lease I am in charge of registering my services. If it is a new registration (such service does not exist yet), everything is fine and nobody needs to go to me (but can, and probably will, but there is no hurry). If I try to re-register (because I wish to change the lease period), then an agent must come to me to see that my RDF document is still there (with a new lease perion inside) - and it must come soon, because it cannot confirm my re-registration. This could work... (not only lease, not only agent, but both) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From gordonp at ucalgary.ca Wed Aug 17 12:16:45 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 17 Aug 2005 10:16:45 -0600 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: References: Message-ID: <430362ED.1090804@ucalgary.ca> >>Alternatively, you pass back some magic cookie when the lease is taken >>out in the first place, that is required for deregistration. >> >> >> > Well, this is exactly what biomoby has now - and nobody seems to like >it. That's why we are talking how to change it. > > Absolutely. Keeping a cookie around somewhere for a month, then manually using it to renew the lease (remember, automating the lease renewal is just as bad as having an RDF file that you need to change) is bad. If I lose my cookie, or it is intercepted, I'm toast. > So the above would work only if I can prove who I am. And the only way >how to do it (if we do not want to introduce passwords etc.) is to let >somebody come back to my place (because only I can control such a >place). That means an agent... > > Exactly my point from before about multiple host names/machine. You should only be able to advertise a service available in MOBY from the ucalgary.ca domain if you are able to put an RDF document on a web server in that domain. It's a security check of sorts. I don't see how a lease-only system could easily acheive this without some signing certificates, and in fact I could prevent the NCBI from registering services by doing it first and getting the cookie they need to fix the registry. If we can add a "push" like method to the registry saying "check my RDF ASAP", and maybe an optional expiry for people who like leases (the default would be turf the service if the test case fails repeatedly) we should have the best of both worlds... > So: if I use a lease I am in charge of registering my services. If it >is a new registration (such service does not exist yet), everything is >fine and nobody needs to go to me (but can, and probably will, but there >is no hurry). If I try to re-register (because I wish to change the lease >period), then an agent must come to me to see that my RDF document is >still there (with a new lease perion inside) - and it must come soon, >because it cannot confirm my re-registration. > > This could work... (not only lease, not only agent, but both) > > Cheers, > Martin > >-- >Martin Senger > email: martin.senger at gmail.com > skype: martinsenger >International Rice Research Institute >Biometrics and Bioinformatics Unit >DAPO BOX 7777, Metro Manila >Philippines, phone: +63-2-580-5600 (ext.2324) > >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l > > > From markw at illuminae.com Wed Aug 17 12:23:50 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 17 Aug 2005 09:23:50 -0700 Subject: [moby] Re: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <430362ED.1090804@ucalgary.ca> References: <430362ED.1090804@ucalgary.ca> Message-ID: <1124295830.21293.24.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-08-17 at 10:16 -0600, Paul Gordon wrote: > Keeping a cookie around somewhere for a month, then > manually using it to renew the lease (remember, automating the lease > renewal is just as bad as having an RDF file that you need to change) is > bad. If I lose my cookie, or it is intercepted, I'm toast. Yes... in fact, that solution makes me lose my cookies! ;-) > If we can add a "push" like method to the registry saying > "check my RDF ASAP", and maybe an optional expiry for people who like > leases (the default would be turf the service if the test case fails > repeatedly) we should have the best of both worlds... This is easy enough to do given that we are moving to RDF as our Service Signature - it just becomes another metadata tag. However, we would then have to add some code to the registry that stores lease times, and this then makes some assumptions about what the underling registry has to know about. Given that we are now trying to support both a MOBY Central and a myGrid/Feta underlying store we cannot make "arbitrary" decisions like this anymore... A non-lease mechanism does not require the registry to "think", only to store the data that it needs and respond to "come hither agent" calls. M -- "Ontologists do it with the edges!" 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 From fgibbons at hms.harvard.edu Thu Aug 18 18:13:02 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 18 Aug 2005 18:13:02 -0400 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? Message-ID: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> Hi, I'm having trouble understanding where articleName belongs. I thought I understood it before, but now that I'm trying to use jMoby to access services that I'm providing from Perl, I'm confused again..... (But I note from the MOBY digest that just landed in my mailbox that that's OK, since articleName has several uses/meanings, and may perhaps soon acquire some more, so perhaps I'm not the only one ;) My (Perl) services expect input that looks like this: In jMoby, from reading TestRequest.java, I can see that it's easy to build an object to contain a message like, using one of the constructors (it takes two String arguments: namespace and id). But how do I set the articleName for the enclosing tag? Calling setName() on the service input MobyDataObject that wraps it, results in that articleName being handed down to the child element (Object), when it should remain with the Simple. Maybe I've got it all wrong. This has worked for me with the Perl API for over a year, but when trying to interact with those services using jMoby, it barfs because the response (which looks not unlike the input above) contains Simples with children, which "is NOT expected" [sic]. But I though Simples could contain fundamental datatypes like String & friends. Perhaps this relates to the discussion over the last weeks about what a Collection is for. Hopefully, I've overlooked something in the javadocs - if so, I'd appreciate a pointer to the right class. Thanks in advance. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Thu Aug 18 18:59:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 18 Aug 2005 23:59:09 +0100 (BST) Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> Message-ID: Frank, I guess you will get an reply from Paul explaining your answer. I want just make a small note: Bear with me for another week (probably less, just until Monday or Tuesday) when I am going to release a completly new support/additions to jMoby that surely deals with article names in both their incarnations (article names in Simples and article names in members objects (HAS/HASA objects). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From gordonp at ucalgary.ca Fri Aug 19 11:21:38 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 19 Aug 2005 09:21:38 -0600 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> References: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> Message-ID: <4305F902.7060506@ucalgary.ca> > Hi, > > I'm having trouble understanding where articleName belongs. I thought > I understood it before, but now that I'm trying to use jMoby to access > services that I'm providing from Perl, I'm confused again..... (But I > note from the MOBY digest that just landed in my mailbox that that's > OK, since articleName has several uses/meanings, and may perhaps soon > acquire some more, so perhaps I'm not the only one ;) > > My (Perl) services expect input that looks like this: > > > > > > In jMoby, from reading TestRequest.java, I can see that it's easy to > build an object to contain a message like, using one of the > constructors (it takes two String arguments: namespace and id). But > how do I set the articleName for the enclosing tag? Calling > setName() on the service input MobyDataObject that wraps it, results > in that articleName being handed down to the child element (Object), > when it should remain with the Simple. To me it makes sense: calling object.setName() sets the article name in the Object tag, not the Simple. The Simple is not a data object of any sort, it is just a wrapper used to name parameters in calls to services. I can reuse the Object in another service, with a completely different parameter name, or even use it as part of a collection. I should not have to modify the Object name itself to make these calls, as it is exactly the same Object tag as before. In fact, I never use object.setName(), it's there because there are other parts of the code that call it, when you are building composite objects and the articleName is needed to identify the data member. I'll add a message to the javadoc stating this. Because most people are just using one parameter inputs, it's easy to falsely make the connection object name == simple name. Was there not some dicussion on the list of changing articleName to paramName for Simples? If not, we should defiunitely do this! In any case, the jMOBY code right now doesn't deal nicely with named parameters. I was striuggling before with how to deal with XML that both named and unnamed parameters, very confusing. But now that all parameters have to be named (since API 0.86) its much easier. I'll fix the code on the weekend. Thanks for pointiung this out. > Maybe I've got it all wrong. This has worked for me with the Perl API > for over a year, but when trying to interact with those services using > jMoby, it barfs because the response (which looks not unlike the input > above) contains Simples with children, which "is NOT expected" [sic]. > But I though Simples could contain fundamental datatypes like String & > friends. Perhaps this relates to the discussion over the last weeks > about what a Collection is for. Can you send me your exact XML? > Hopefully, I've overlooked something in the javadocs - if so, I'd > appreciate a pointer to the right class. > > Thanks in advance. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From gordonp at ucalgary.ca Fri Aug 19 12:06:11 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 19 Aug 2005 10:06:11 -0600 Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <4305F902.7060506@ucalgary.ca> References: <5.2.1.1.2.20050818172744.011d8e00@email.med.harvard.edu> <4305F902.7060506@ucalgary.ca> Message-ID: <43060373.1080304@ucalgary.ca> Replying to my own :-) > > In any case, the jMOBY code right now doesn't deal nicely with named > parameters. I was striuggling before with how to deal with XML that > both named and unnamed parameters, very confusing. But now that all > parameters have to be named (since API 0.86) its much easier. I'll > fix the code on the weekend. Thanks for pointiung this out. > Hmm. A corrolary of requiring all parameters to be named is that there the returned data should be named too, as MOBY input and output messages are essentially symmetric. We could get around this by saying that if you have only one parameter, it does not need to be named. In that way, the response simple or collection does not need to be named either. This also makes the vast majority of currently registered services valid again according to API v.0.86 , as most have one parameter, and it is not named. From senger at ebi.ac.uk Fri Aug 19 12:46:07 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 19 Aug 2005 17:46:07 +0100 (BST) Subject: [MOBY-l] Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <43060373.1080304@ucalgary.ca> Message-ID: Regarding the mandatorness of article name, I have heard the same rumour as you did, Paul. What I got confirmed is that article name must be usede for included objects in other objects. What was not yet confirmed is that also Simples and Collections (the wrapper objects) must have article name. Obviously not having article names mandatory is a pain in the neck - I am struggling with it the whole last week... Also API documentation is very unnerving (is this a right English word to use if you wish to say a four-letter word but you are too polite or too afraid to say it?). In one place it says "Articles are required to be named using the articleName attribute." and a bit further it says: "The articleName attribute of the Simple and/or Collection elements is optional...". Mark, could you say loundly and soonish: 1) How it is really? 2) What to do with currently registered services that do not comply with the rule from 1) ? Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Aug 19 14:42:21 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 19 Aug 2005 11:42:21 -0700 Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: References: Message-ID: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> On Fri, 2005-08-19 at 17:46 +0100, Martin Senger wrote: > What was not yet confirmed is that > also Simples and Collections (the wrapper objects) must have article > name. Obviously not having article names mandatory is a pain in the neck - > I am struggling with it the whole last week... It was confirmed a while ago - see below... > Also API documentation is very unnerving (is this a right English word to > use if you wish to say a four-letter word but you are too polite or too > afraid to say it?). In one place it says "Articles are required to be > named using the articleName attribute." and a bit further it says: "The > articleName attribute of the Simple and/or Collection elements is > optional...". I'll look for this error. I really need someone to take over the task of documentation, however... > Mark, could you say loundly and soonish: > 1) How it is really? I reported loudly and previously: : From: markw at illuminae.com : Reply-To: Core developer announcements 2) What to do with currently registered services that do not comply with > the rule from 1) ? I think we can add an arbitratry articleName to their inputs, since they will no doubt ignore it anyway... Must run! M -- "Ontologists do it with the edges!" 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 From gordonp at ucalgary.ca Fri Aug 19 19:13:47 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 19 Aug 2005 17:13:47 -0600 Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> References: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> Message-ID: <430667AB.1070906@ucalgary.ca> The way I dealt with this was to allow a zero-length string as a name. There's nothing in the API that forbids this. Anything without an articleName gets a zero-length name, and if there is more than one, I raise an exception. This handles currently registered one-parameters jobs fine without resorting to random names, and enforces uniqueness of the articleName going forward. Actually, the API doesn't say they need to be unique, just that they need to be there. >: 1) *all* parameters going into a service must now be named currently using the >: articleName attribute of the Simple/Collection/Parameter tag > > > > >>2) What to do with currently registered services that do not comply with >>the rule from 1) ? >> >> > >I think we can add an arbitratry articleName to their inputs, since they >will no doubt ignore it anyway... > >Must run! > >M > > > > From senger at ebi.ac.uk Fri Aug 19 20:11:13 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 20 Aug 2005 01:11:13 +0100 (BST) Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in a Simple, using jMoby? In-Reply-To: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> Message-ID: > It was confirmed a while ago - see below... > Thank for confirmation. It is a good news. (I knew about the email you quoted - but I was not sure if it was a definitive announcement or just your contribution to the discussion of the API changes. Now it's clear. My confusion just confirms that Biomoby still does not have in place a formal procedure how and when to do API changes.) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From paolo at ist.unige.it Mon Aug 22 07:26:40 2005 From: paolo at ist.unige.it (Paolo Romano) Date: Mon, 22 Aug 2005 13:26:40 +0200 (DFT) Subject: [MOBY-l] NETTAB 2005 - Deadlines approaching: early registration and call for posters Message-ID: <200508221126.j7MBQeqR019972@ibm43p.biotech.ist.unige.it> Dear all, this is a reminder for next deadlines of the NETTAB 2005 Workshop on "Workflows management: new abilities for the biological information overflow" that will be held on next October 5-7, 2005, in Naples, Italy. The Scientific Programme is now available on-line at http://www.nettab.org/2005/progr.html . The Opening Lecture will be given by Francis Ouellette. Francis Ouellette is the Director of the UBiC, the Bioinformatics Centre of the University of British Columbia, Canada. He is Associate Professor of the Michael Smith Laboratories and of the Department of Medical Genetics of UBC. He is also a core faculty member in the new UBC graduate Training Program in Bioinformatics for Health Research, associate director of Bioinformatics at Genome British Columbia and director of the Canadian Genetic Diseases Network (CGDN) bioinformatics core facility where he helps coordinate the Canadian Bioinformatics Workshops. Francis has an exceptional curriculum and his recent research, training and coordination activities make him one of the most known and appreciated bioinformaticians. The title of his opening talk will be "Workflow management in bioinformatics: the possibilities and the challenges". ---------------------------------------------------------------------- The Call for posters and position papers is closing on next friday August 26, 2005. You are all warmly invited to present your recent activity related to the workshops' topics by submitting a poster abstract (1-2 A4 pages, font size 12 pt, MS Word format) by email to posters2005 at nettab.org . Topics are the following: Technologies and technological platforms of interest, with emphasis on: - Web Services (SOAP, WSDL, WSFL, UDDI, ....) - Web Services Choreography and Orchestration - Semantic Web (RDF, LSID, OWL, ...) - comparison of available technologies, limitations, pros and cons - knowledge representation - biological data and knowledge modeling tools - Ontologies, Databases and Applications of Semantics in Bioinformatics Workflow management systems in bioinformatics - implementations of web services - implementations of registries - reuse and versioning of web services and workflows - workflow management systems - web interfaces for accessing and executing workflows - interactive systems to support work flows Applications of workflow management systems in bioinformatics - Methodologies for life sciences analysis, such as: - gene expression, - genome annotation, - mass spec peptide fragment identification, - Encoding of the above in workflows - Case studies - Scenarios and use cases Check all details at: http://www.nettab.org/2005/call.html . -------------------------------------------------------------------------------- The early registration deadline is also next Friday August 26, 2005. The registration form is available on-line at: http://www.nettab.org/2005/rform.html . The payment of the fee can either be done on-line, through the Online Payment Form of the Bioinformatics Italian Society (BITS), or by direct money transfer. Participation fees are as follows: Until August 26, 2005: - Students: 70,00 Euro - Academic: 130,00 Euro (reduced fee: 117,00 Euro) - Non-academic: 270,00 Euro (reduced fee: 243,00 Euro) After August 26, 2005: - Students: 70,00 Euro - Academic: 180,00 Euro (reduced fee: 162,00 Euro) - Non-academic: 370,00 Euro (reduced fee: 333,00 Euro) The 10% reduction on fees is applied for members of: - ISCB (International Society for Computational Biology), http://www.iscb.org/ - BITS (Bioinformatics Italian Society), http://www.bioinformatics.it/ - Hormone Responsive Breast Cancer (HRBC) Genomics Network, http://www.hrbc-genomics.net/ - Oncology over Internet (O2I) project, http://www.o2i.it/ - Interdisciplinary Laboratory for Technologies in Bioinformatics (LITBIO) -------------------------------------------------------------------------------- I'm looking forward to meeting many of you in Naples quite soon. Ciao. Paolo -- Paolo Romano (paolo.romano at istge.it) Bioinformatics and Structural Proteomics National Cancer Research Institute (IST) Largo Rosanna Benzi, 10, I-16132, Genova, Italy Tel: +39-010-5737-288 Fax: +39-010-5737-295 Web: http://www.nettab.org/promano/ From p.lord at cs.man.ac.uk Mon Aug 22 08:21:48 2005 From: p.lord at cs.man.ac.uk (Phillip Lord) Date: 22 Aug 2005 13:21:48 +0100 Subject: [MOBY-l] Re: [MOBY-dev] lease versus agent for registry updating In-Reply-To: <430362ED.1090804@ucalgary.ca> References: <430362ED.1090804@ucalgary.ca> Message-ID: <87fyt2duw3.fsf@rpc71.cs.man.ac.uk> >>>>> "Paul" == Paul Gordon writes: >>> Alternatively, you pass back some magic cookie when the lease is >>> taken out in the first place, that is required for >>> deregistration. >>> >>> >> Well, this is exactly what biomoby has now - and nobody seems to >> like it. That's why we are talking how to change it. >> Paul> Absolutely. Keeping a cookie around somewhere for a month, Paul> then manually using it to renew the lease (remember, Paul> automating the lease renewal is just as bad as having an RDF Paul> file that you need to change) is bad. If I lose my cookie, or Paul> it is intercepted, I'm toast. I don't think that you'd need the cookie to renew your lease, just to remove it before hand. If you lose it, then you just have to wait for it to run out naturally. Of course, if it's built into the service provider libraries, there is no real reason that you should lose it. >> So the above would work only if I can prove who I am. And the >> only way how to do it (if we do not want to introduce passwords >> etc.) is to let somebody come back to my place (because only I >> can control such a place). That means an agent... >> Paul> Exactly my point from before about multiple host Paul> names/machine. You should only be able to advertise a service Paul> available in MOBY from the ucalgary.ca domain if you are able Paul> to put an RDF document on a web server in that domain. It's a Paul> security check of sorts. I don't see how a lease-only system Paul> could easily acheive this without some signing certificates, Paul> and in fact I could prevent the NCBI from registering services Paul> by doing it first and getting the cookie they need to fix the Paul> registry. I think that the lease is a property of the registration, not of the service. So, if you register a service, it won't prevent anyone else from registering the same service again. Again, if you put some sort of call back into the leasing system, you could prevent anyone from registering a service that they do not own. Although, personally, I don't see any major problem with third party registration. Feta effectively works on third party registration, as most of the semantic descriptions do not come from the service provider. Phil From markw at illuminae.com Mon Aug 22 11:34:49 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 22 Aug 2005 08:34:49 -0700 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <4309A53B.8080701@cnb.uam.es> References: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> <4309A53B.8080701@cnb.uam.es> Message-ID: <1124724889.3068.103.camel@bioinfo.icapture.ubc.ca> On Mon, 2005-08-22 at 12:13 +0200, David Gonz?lez Pisano wrote: > Umm, does this mean that also Simples into Collections *must* have an > articlename too, even an arbitrary one? I was wondering if the lack of > an articleName in the "Simple inside a Collection" example (see the > API documentation, section INPUT) means that a Simple has to have > articleName when is the only input No, Simples inside a collection do not have an articleName, and at most they would all have the same articleName (I'm actually not sure how the registry code handles this at the moment... I suspect that it does record the articleName of a Simple within a Collection if an articleName has been provided at registration, but I know for certain that none of my client libraries pay attention to it even if it is there, since it was not *intended* to be used, nor meaningful). > Also, probably the twiki needs an update, because as today still says "The articleName attribute of the Simple and/or Collection elements is > optional (it may or may not be there, and if there, it may or may not have a non-null value)". Note that the last part of the phrase contradicts Paul's solution. I'll try to find this and fix it. again... we really need someone to volunteer to take over the task of re-writing and maintaining the documentation :-) M -- "Ontologists do it with the edges!" 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 From dgpisano at cnb.uam.es Mon Aug 22 06:13:15 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Mon, 22 Aug 2005 12:13:15 +0200 Subject: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> References: <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> Message-ID: <4309A53B.8080701@cnb.uam.es> Mark Wilkinson escribi?: >On Fri, 2005-08-19 at 17:46 +0100, Martin Senger wrote: > > >>What was not yet confirmed is that >>also Simples and Collections (the wrapper objects) must have article >>name. Obviously not having article names mandatory is a pain in the neck - >>I am struggling with it the whole last week... >> >> >It was confirmed a while ago - see below... > > > >: >: A few changes to announce for the 0.86 API (this is not yet running on the >: production server): >: >: 1) *all* parameters going into a service must now be named currently using the >: articleName attribute of the Simple/Collection/Parameter tag > > Umm, does this mean that also Simples into Collections *must* have an articlename too, even an arbitrary one? I was wondering if the lack of an articleName in the "Simple inside a Collection" example (see the API documentation, section INPUT) means that a Simple has to have articleName when is the only input <------- articleName here! but does not need it when is inside a Collection? <------- no articleName here? Also, probably the twiki needs an update, because as today still says "The articleName attribute of the Simple and/or Collection elements is optional (it may or may not be there, and if there, it may or may not have a non-null value)". Note that the last part of the phrase contradicts Paul's solution. David (working on the Errors proposal, which heavily depends on the answer to this mail) ;-) From fgibbons at hms.harvard.edu Mon Aug 22 11:54:11 2005 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Mon, 22 Aug 2005 11:54:11 -0400 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <1124724889.3068.103.camel@bioinfo.icapture.ubc.ca> References: <4309A53B.8080701@cnb.uam.es> <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> <4309A53B.8080701@cnb.uam.es> Message-ID: <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> Mark, At 11:34 AM 8/22/2005, you wrote: > > Also, probably the twiki needs an update, because as today still says > "The articleName attribute of the Simple and/or Collection elements is > > optional (it may or may not be there, and if there, it may or may not > have a non-null value)". Note that the last part of the phrase > contradicts Paul's solution. > >I'll try to find this and fix it. > >again... we really need someone to volunteer to take over the task of >re-writing and maintaining the documentation :-) I'll volunteer for that. You're referring to the Wiki API page, I assume, or are there other docs (besides the POD and javadoc)? -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Mon Aug 22 12:08:13 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 22 Aug 2005 17:08:13 +0100 (BST) Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> Message-ID: > I'll volunteer for that. You're referring to the Wiki API page, I assume, > or are there other docs (besides the POD and javadoc)? > That's goooood! But please be merciless, as much as you can. :-) The main problem I had with these pages from/at the beginning is that only the initiated easily understand that the page actually contain two APIs - one for registry and one for services. The current page mix them too much (IMHO). I also volunteer for proof-reading (just send me your draft) - and I promise I will be chasing Mark with every smallest ambiguity that I could find. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Mon Aug 22 12:14:49 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 22 Aug 2005 09:14:49 -0700 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: References: Message-ID: <1124727289.3068.131.camel@bioinfo.icapture.ubc.ca> > and I > promise I will be chasing Mark with every smallest ambiguity that I could > find. OOOooohhh yeah... he sure will! I know that from experience ;-) M -- "Ontologists do it with the edges!" 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 From markw at illuminae.com Mon Aug 22 12:16:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 22 Aug 2005 09:16:04 -0700 Subject: [moby] Re: [MOBY-l] Re: Where does articleName belong? How can I set it in aSimple, using jMoby? In-Reply-To: <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> References: <4309A53B.8080701@cnb.uam.es> <1124476941.26245.39.camel@bioinfo.icapture.ubc.ca> <4309A53B.8080701@cnb.uam.es> <5.2.1.1.2.20050822115221.010ccf88@email.med.harvard.edu> Message-ID: <1124727364.3068.134.camel@bioinfo.icapture.ubc.ca> that's fantastic! Thanks Frank! I need to set you up with a developers account on the TWiki machine so that you can edit the main page I think... let's coordinate this off- list. Speaking of the Twiki machine... Simon - how's the new website plan coming? M On Mon, 2005-08-22 at 11:54 -0400, Frank Gibbons wrote: > Mark, > > At 11:34 AM 8/22/2005, you wrote: > > > Also, probably the twiki needs an update, because as today still says > > "The articleName attribute of the Simple and/or Collection elements is > > > optional (it may or may not be there, and if there, it may or may not > > have a non-null value)". Note that the last part of the phrase > > contradicts Paul's solution. > > > >I'll try to find this and fix it. > > > >again... we really need someone to volunteer to take over the task of > >re-writing and maintaining the documentation :-) > > > I'll volunteer for that. You're referring to the Wiki API page, I assume, > or are there other docs (besides the POD and javadoc)? > > -Frank > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- "Ontologists do it with the edges!" 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 From silvia77 at dist.unige.it Thu Aug 25 06:12:09 2005 From: silvia77 at dist.unige.it (scaglione) Date: Thu, 25 Aug 2005 12:12:09 +0200 Subject: [MOBY-l] sth_collection_ins Message-ID: <1124964729.430d9979a03e9@webmail.unige.it> hello, I have followed instructions to install a moby central in my machine.I have tried the testMOBYClientCentral_v05.pl script on my mobycentral and an error appeared: >perl testMOBYCentral_v05.pl Useless use of hash element in void context at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. Global symbol "$sth_collection_ins" requires explicit package name at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. Compilation failed in require at testMOBYCentral_v05.pl line 4. BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. what does it mean? The overall configuration of the moby central seemed to be ok, since the test of the same script on the main mobycentral works... many thanks silvia -- PhD. Silvia Scaglione DIST University of Genoa Viale Causa,13 16145 Genoa phone +39 010 353 2789 phone CBA +39 010 5737 505 fax +39 010 353 2948 From markw at illuminae.com Thu Aug 25 12:27:21 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 25 Aug 2005 09:27:21 -0700 Subject: [moby] [MOBY-l] sth_collection_ins In-Reply-To: <1124964729.430d9979a03e9@webmail.unige.it> References: <1124964729.430d9979a03e9@webmail.unige.it> Message-ID: <1124987241.11350.50.camel@bioinfo.icapture.ubc.ca> Can you first confirm where you got your mobycentral code from? Is it one of the newer releases? I'm certain that the latest release is functional (though there are a few small bugs in it that are now fixed in the CVS, but the CVS code isn't supported yet...) make/make install this code and see if it solves your problems. You probably wont need to modify any of your configuration after this installation. http://biomoby.org/releases/biomoby.0.8.2a.tar.gz M On Thu, 2005-08-25 at 12:12 +0200, scaglione wrote: > hello, > I have followed instructions to install a moby central in my machine.I have > tried the testMOBYClientCentral_v05.pl script on my mobycentral and an error > appeared: > > >perl testMOBYCentral_v05.pl > > Useless use of hash element in void context > at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. > Global symbol "$sth_collection_ins" requires explicit package name > at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. > Compilation failed in require at testMOBYCentral_v05.pl line 4. > BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. > > what does it mean? > The overall configuration of the moby central seemed to be ok, since the test > of the same script on the main mobycentral works... > many thanks > silvia > > > -- "Ontologists do it with the edges!" 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 From jmfernandez at cnb.uam.es Fri Aug 26 12:37:31 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 26 Aug 2005 18:37:31 +0200 Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? Message-ID: <430F454B.7020603@cnb.uam.es> Hi people! Is there any problem with Tomcat server in MOBY Central? Since Tuesday (or so) I'm playing with latest Taverna CVS, and BioMOBY related stuff doesn't work because there is a HTTP 500 code related to http://www.biomoby.org/RESOURCES/MOBY-S/Objects (RDF Object definitions). As Taverna 1.2 also depends on this URL, MOBY services tree is not either working. Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From edward.kawas at gmail.com Fri Aug 26 13:20:17 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 26 Aug 2005 12:20:17 -0500 Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? In-Reply-To: <430F454B.7020603@cnb.uam.es> References: <430F454B.7020603@cnb.uam.es> Message-ID: Hi, I will look into this asap (saturday or sunday). It looks like the server works because the other RDF documents are being generated so something must be wrong with either the configuration. Actually, I just noticed that the types script for objects is returning stuff that it shouldnt (http://mobycentral.icapture.ubc.ca:8090/types/Objects) and this script is utilized by the RESOURCES script. As soon as I am able to check this out, I will and l will fix it. The problem seems to lie with the object 'Regex' and its description (no longer limited to one line per object). Eddie On 8/26/05, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi people! > Is there any problem with Tomcat server in MOBY Central? Since Tuesday > (or so) I'm playing with latest Taverna CVS, and BioMOBY related stuff > doesn't work because there is a HTTP 500 code related to > http://www.biomoby.org/RESOURCES/MOBY-S/Objects (RDF Object > definitions). As Taverna 1.2 also depends on this URL, MOBY services > tree is not either working. > > Best Regards, > Jos? Mar?a > > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From senger at ebi.ac.uk Fri Aug 26 20:28:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 27 Aug 2005 01:28:31 +0100 (BST) Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? In-Reply-To: Message-ID: > The problem seems to lie with the object 'Regex' and its description > (no longer limited to one line per object). > Regex is my object! I am always happy to shoot down all servers around :-) But seriusly, anything wrong with longer description? Does API preclude it? Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Sat Aug 27 09:55:31 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Sat, 27 Aug 2005 08:55:31 -0500 Subject: [MOBY-l] RESOURCES/MOBY-S/Objects not working? In-Reply-To: References: Message-ID: I think the description is fine, Mark will need to verify this. I will just have to update my logic (already done in my head and when i get home today i will update the codebase). Eddie On 8/26/05, Martin Senger wrote: > > The problem seems to lie with the object 'Regex' and its description > > (no longer limited to one line per object). > > > Regex is my object! I am always happy to shoot down all servers around > :-) > But seriusly, anything wrong with longer description? Does API preclude > it? > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > From senger at ebi.ac.uk Mon Aug 29 10:32:30 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 29 Aug 2005 15:32:30 +0100 (BST) Subject: [MOBY-l] Moses - Moby Services Support In-Reply-To: <1476.82.66.216.27.1118945157.squirrel@82.66.216.27> Message-ID: Hi all, My first month at Philippines, at IRRI, is almost finished. So it's time to announce some progress :-) I have commited code and a lot of documentation helping to write Biomoby services in Java. The idea is to generate classes for all registered data types and then generate skeleton for a new service. Its developer can extend such skeleton , put there the business logic without worries about the Biomoby XML and about the SOAP itself. These things should be hidden. It is similar what Paul Gordon provides for the clients, but here you can use strongly-type approach (having all data types generated). Or, you can say, that we can have more ways to do the same, like in Perl :-) As (almost) a side-effect, the generated code, because it has rich API/javadoc comments, can be used as a primitive browser of the biomoby registry. Here you can see the API for all data types and for all services as they are today (when I find a place where I can run a cronjob, we can have this API up-to-date anytime you look): http://www.ebi.ac.uk/~senger/jMoby/APIservices/index.html The documentation is in jMoby and can be viewed at: http://biomoby.org/moby-live/Java/docs/Moses.html. I hope you'll enjoy it and I am happy to hear your suggestions, bug reports (remember there is also a bugzilla open now, but feel free to send emails direcly to me) and anything bout Moses. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From silvia77 at dist.unige.it Thu Aug 25 05:52:50 2005 From: silvia77 at dist.unige.it (scaglione) Date: Thu, 25 Aug 2005 11:52:50 +0200 Subject: [MOBY-l] sth_collection_ins Message-ID: <1124963570.430d94f212a32@webmail.unige.it> hello, I have followed instructions to install a moby central in my machine.I have tried the testMOBYClientCentral_v05.pl script on my mobycentral and an error appeared: >perl testMOBYCentral_v05.pl Useless use of hash element in void context at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. Global symbol "$sth_collection_ins" requires explicit package name at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. Compilation failed in require at testMOBYCentral_v05.pl line 4. BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. what does it mean? The overall configuration of the moby central seemed to be ok, since the test of the same script on the main mobycentral works... many thanks silvia -- PhD. Silvia Scaglione DIST University of Genoa Viale Causa,13 16145 Genoa phone +39 010 353 2789 phone CBA +39 010 5737 505 fax +39 010 353 2948 From silvia77 at dist.unige.it Wed Aug 31 09:32:20 2005 From: silvia77 at dist.unige.it (Silvia Scaglione) Date: Wed, 31 Aug 2005 15:32:20 +0200 Subject: [moby] [MOBY-l] test In-Reply-To: <1124987241.11350.50.camel@bioinfo.icapture.ubc.ca> References: <1124964729.430d9979a03e9@webmail.unige.it> <1124987241.11350.50.camel@bioinfo.icapture.ubc.ca> Message-ID: <6.2.0.14.0.20050831152820.01cc1998@mail.unige.it> I have used the newer releases suggested below, but new errors appears after testing testMOBYClientCentral_v05.pl script on the mobycentral: ... test 19 [PASS] test 20 [FAIL] malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_] test 21 [FAIL] Expected to find service; didn't find service test 22 [FAIL] Expected to find service; didn't find service test 23 [PASS] test 24 [PASS] Use of uninitialized value in print at testMOBYClientCentral_v05.pl line 250. test 25 [FAIL] WSDL was not retrieved test 26 [FAIL] The service specified by authority=www.illuminae.com servicename=myfirstservice2 does not exist in the registry test 27 [PASS] ... Moreover, when I tried the testMOBYClientCentral_v05.pl script on my mobycentral, the error message changes a little bit: >[www at ml370 scripts]$ perl testMOBYClientCentral_v05.pl >TESTING MOBY CLIENT with > URL: http://ml370.biotech.ist.unige.it/cgi-bin/MOBY-Central.pl > URI: http://ml370.biotech.ist.unige.it/MOBY/Central > Proxy: No Proxy Server > >test 1a [PASS] >test 1b [PASS] >test 1 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system > >test 2 [PASS] >test 3 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system >test 4 [FAIL] Relationship type ISA does not exist in the >relationship ontology >test 5 [PASS] >test 6 [FAIL] Object type $term cannot be resolved to an LSID >test 7 [PASS] >test 8 [FAIL] Object type $term cannot be resolved to an LSID >test 9 [FAIL] Service Type HypotheticalService1 does not exist in >the ontology >test 10 [PASS] >test 11 [PASS] >test 12 [PASS] >test 13 [PASS] >test 14 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 15 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 16 [PASS] >test 17 [PASS] >test 18 [PASS] >test 19 [PASS] >test 20 [PASS] >500 Internal Server Error > ERROR ERROR ERROR ...any suggestions? At 18.27 25/08/2005, Mark Wilkinson wrote: >Can you first confirm where you got your mobycentral code from? Is it >one of the newer releases? I'm certain that the latest release is >functional (though there are a few small bugs in it that are now fixed >in the CVS, but the CVS code isn't supported yet...) > >make/make install this code and see if it solves your problems. You >probably wont need to modify any of your configuration after this >installation. > >http://biomoby.org/releases/biomoby.0.8.2a.tar.gz > > >M > > > >On Thu, 2005-08-25 at 12:12 +0200, scaglione wrote: > > hello, > > I have followed instructions to install a moby central in my machine.I > have > > tried the testMOBYClientCentral_v05.pl script on my mobycentral and an > error > > appeared: > > > > >perl testMOBYCentral_v05.pl > > > > Useless use of hash element in void context > > at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. > > Global symbol "$sth_collection_ins" requires explicit package name > > at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. > > Compilation failed in require at testMOBYCentral_v05.pl line 4. > > BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. > > > > what does it mean? > > The overall configuration of the moby central seemed to be ok, since > the test > > of the same script on the main mobycentral works... > > many thanks > > silvia > > > > > > >-- >"Ontologists do it with the edges!" > >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 PhD. Silvia Scaglione Universita`degli Studi di Genova Facolta' di Ingegneria, D.I.S.T. BioLab Viale Causa, 13 16145 GENOVA - Italy Tel Bio-lab +39 010 353 2789 Tel Centro Biotecnologie Avanzate +39 010 5737 505 Fax +39 010 353 2948 E-mail silvia77 at dist.unige.it From markw at illuminae.com Wed Aug 31 10:03:16 2005 From: markw at illuminae.com (mark wilkinson) Date: Wed, 31 Aug 2005 14:03:16 +0000 GMT Subject: [moby] [MOBY-l] test Message-ID: <1390300886-1125497047-cardhu_blackberry.rim.net-15323-@engine08-cell01> Use "make test" instead - it is up to date and far far far more comprehensive. M -----Original Message----- From: Silvia Scaglione Date: Wed, 31 Aug 2005 15:32:20 To:moby-l at biomoby.org Subject: Re: [moby] [MOBY-l] test I have used the newer releases suggested below, but new errors appears after testing testMOBYClientCentral_v05.pl script on the mobycentral: ... test 19 [PASS] test 20 [FAIL] malformed payload invalid character string for serviceName. Must start with a letter followed by [A-Za-z0-9_] test 21 [FAIL] Expected to find service; didn't find service test 22 [FAIL] Expected to find service; didn't find service test 23 [PASS] test 24 [PASS] Use of uninitialized value in print at testMOBYClientCentral_v05.pl line 250. test 25 [FAIL] WSDL was not retrieved test 26 [FAIL] The service specified by authority=www.illuminae.com servicename=myfirstservice2 does not exist in the registry test 27 [PASS] ... Moreover, when I tried the testMOBYClientCentral_v05.pl script on my mobycentral, the error message changes a little bit: >[www at ml370 scripts]$ perl testMOBYClientCentral_v05.pl >TESTING MOBY CLIENT with > URL: http://ml370.biotech.ist.unige.it/cgi-bin/MOBY-Central.pl > URI: http://ml370.biotech.ist.unige.it/MOBY/Central > Proxy: No Proxy Server > >test 1a [PASS] >test 1b [PASS] >test 1 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system > >test 2 [PASS] >test 3 [FAIL] Relationship Type hasa does not exist in the >biomoby.org Relationship Type system >test 4 [FAIL] Relationship type ISA does not exist in the >relationship ontology >test 5 [PASS] >test 6 [FAIL] Object type $term cannot be resolved to an LSID >test 7 [PASS] >test 8 [FAIL] Object type $term cannot be resolved to an LSID >test 9 [FAIL] Service Type HypotheticalService1 does not exist in >the ontology >test 10 [PASS] >test 11 [PASS] >test 12 [PASS] >test 13 [PASS] >test 14 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 15 [FAIL] Relationship Type isa does not exist in the >biomoby.org Relationship Type system >test 16 [PASS] >test 17 [PASS] >test 18 [PASS] >test 19 [PASS] >test 20 [PASS] >500 Internal Server Error > ERROR ERROR ERROR ...any suggestions? At 18.27 25/08/2005, Mark Wilkinson wrote: >Can you first confirm where you got your mobycentral code from? Is it >one of the newer releases? I'm certain that the latest release is >functional (though there are a few small bugs in it that are now fixed >in the CVS, but the CVS code isn't supported yet...) > >make/make install this code and see if it solves your problems. You >probably wont need to modify any of your configuration after this >installation. > >http://biomoby.org/releases/biomoby.0.8.2a.tar.gz > > >M > > > >On Thu, 2005-08-25 at 12:12 +0200, scaglione wrote: > > hello, > > I have followed instructions to install a moby central in my machine.I > have > > tried the testMOBYClientCentral_v05.pl script on my mobycentral and an > error > > appeared: > > > > >perl testMOBYCentral_v05.pl > > > > Useless use of hash element in void context > > at /usr/lib/perl5/site_perl/5.8.5/RDF/Core/Serializer.pm line 52. > > Global symbol "$sth_collection_ins" requires explicit package name > > at /usr/lib/perl5/site_perl/5.8.5/MOBY/Central.pm line 3426. > > Compilation failed in require at testMOBYCentral_v05.pl line 4. > > BEGIN failed--compilation aborted at testMOBYCentral_v05.pl line 4. > > > > what does it mean? > > The overall configuration of the moby central seemed to be ok, since > the test > > of the same script on the main mobycentral works... > > many thanks > > silvia > > > > > > >-- >"Ontologists do it with the edges!" > >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 PhD. Silvia Scaglione Universita`degli Studi di Genova Facolta' di Ingegneria, D.I.S.T. BioLab Viale Causa, 13 16145 GENOVA - Italy Tel Bio-lab +39 010 353 2789 Tel Centro Biotecnologie Avanzate +39 010 5737 505 Fax +39 010 353 2948 E-mail silvia77 at dist.unige.it _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson ...on the road!