From markw at illuminae.com Mon Oct 3 13:16:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Oct 3 13:17:48 2005 Subject: [MOBY-dev] TWiki taken offline Message-ID: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> Hi all, I've decided to take the TWiki down after several recent serious security alerts that would require installation of a newer version (and installation of TWiki is not something I can do with my left hand, unfortunately... it's a bit ugly!) Since we're moving to the new website anyway, I don't see the point in the investment of time on the old one. I will continue to move documents over to the new site as I get the chance. Others are welcome to help :-) If there is anything on the TWiki that you need urgently, let me know and I'll make the document available some other way. 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 Pieter.Neerincx at wur.nl Tue Oct 4 08:43:47 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Oct 4 08:55:40 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects Message-ID: <060DD7A8-411D-4F92-A5F3-A8EC7E33D536@wur.nl> Hi Eddie et al. Now that I have my local BioMOBY Central up and running I'd love to run some worksflows, but I think I ran into a bug. When I select BioMOBY objects and add them to a workflow all necessary processors for the child elements/objects are added as well. So far so good. But when I run a workflow, some of the child elements for the objects are missing from the object that is send to a service. Here's an example: If I have a nested structure like this: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Root_Moby_Object moby:My_Child_Level_1A moby:My_Child_Level_1B moby:My_Child_Level_2A moby:My_Child_Level_2B moby:My_Child_Level_1C moby:My_Child_Level_1D moby:My_Child_Level_2A moby:My_Child_Level_3A moby:My_Child_Level_1E * The MyRootMobyObject can have many ChildLevel1 elements. That's fine. * However if the ChildLevel1 elements have childs, they might be missing from the object that is send to a service. Some will be there, others will be missing. I tried to find a pattern, but I couldn't. So whether there is 1 or more elements added at level 2, whether they have an articleName or not, whether they have a namespace or not, etc. doesn't seem to make a difference. I also tried the official BioMOBY central: same result. I also tried the freshly released Taverna 1.3 today: same result again. So when I look in Taverna at the intermediate inputs and outputs for the different processors I see the following structures: The input for the service = the intermediate output of the processor that created MyRootMobyObject contains: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Root_Moby_Object moby:My_Child_Level_1A moby:My_Child_Level_1B moby:My_Child_Level_1C moby:My_Child_Level_1D moby:My_Child_Level_1E The intermediate input for the processor that created MyRootMobyObject = the intermediate output of the processor that created MyChildLevel1B contains: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Child_Level_1B moby:My_Child_Level_2A moby:My_Child_Level_2B So that one looks fine, but when My_Child_Level_1B is appended to My_Root_Moby_Object, the children of My_Child_Level_1B are lost :(. I do not get any errors or scary log lines apart from my service complaining that some elements are missing from the input. Any idea what is messing up the fun? Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From jpsanchez at isciii.es Tue Oct 4 09:00:59 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 09:36:37 2005 Subject: Autoreply: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From edward.kawas at gmail.com Tue Oct 4 09:44:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 10:44:46 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: <060DD7A8-411D-4F92-A5F3-A8EC7E33D536@wur.nl> Message-ID: <000c01c5c8e9$cffac320$6500a8c0@notebook> > moby:MOBY > moby:Content > moby:Data > moby:Simple > moby:My_Child_Level_1B > moby:My_Child_Level_2A > moby:My_Child_Level_2B > Do you have an example of an object that has this type of structure? Thanks, Eddie From jpsanchez at isciii.es Tue Oct 4 10:49:22 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 10:49:02 2005 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 11:06:37 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Oct 4 11:06:37 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: <000c01c5c8e9$cffac320$6500a8c0@notebook> References: <000c01c5c8e9$cffac320$6500a8c0@notebook> Message-ID: On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >> moby:MOBY >> moby:Content >> moby:Data >> moby:Simple >> moby:My_Child_Level_1B >> moby:My_Child_Level_2A >> moby:My_Child_Level_2B >> >> > > Do you have an example of an object that has this type of > structure? Yes, try for example DnaSequenceHolder from the BioMOBY Central. I have been running some other tests in the mean time and so far almost every object I tried lacks child elements at level 2 or further down. The only one that does have an element at level 2 is the BlastJob object I have in my local Central. This one has Strings, Objects and a DataTime at level 2 or further down. Everything is missing except the DataTime primitive... I noticed that hardly anyone is using the DataTime primitive if I'm not the only one using. It is also hardly documented. Maybe it's just random noise in my testing or maybe I'm onto something.... If you want to try the BlastJob object my local registry should still be accessible from outside at: http://137.224.52.237/phenolink/biomoby/central/cgi-bin/MOBY-Central.pl Hope this helps, Pi > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From jpsanchez at isciii.es Tue Oct 4 11:13:02 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 11:12:46 2005 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From edward.kawas at gmail.com Tue Oct 4 11:12:29 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 11:41:30 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: Message-ID: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> No you are on to something! When I first created the plugin, I used a certain xml parser based on w3c dom. I had to switch to another parser and it seems that I was unaware of its limitations (getChildren only gets the direct children of an element). I will have this fixed fairly soon. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:07 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > > >> moby:MOBY > >> moby:Content > >> moby:Data > >> moby:Simple > >> moby:My_Child_Level_1B > >> moby:My_Child_Level_2A > >> moby:My_Child_Level_2B > >> > >> > > > > Do you have an example of an object that has this type > of > > structure? > > Yes, try for example DnaSequenceHolder from the BioMOBY > Central. > > I have been running some other tests in the mean time and > so far > almost every object I tried lacks child elements at level > 2 or > further down. The only one that does have an element at > level 2 is > the BlastJob object I have in my local Central. This one > has Strings, > Objects and a DataTime at level 2 or further down. > Everything is > missing except the DataTime primitive... I noticed that > hardly anyone > is using the DataTime primitive if I'm not the only one > using. It is > also hardly documented. Maybe it's just random noise in my > testing or > maybe I'm onto something.... > > If you want to try the BlastJob object my local registry > should still > be accessible from outside at: > http://137.224.52.237/phenolink/biomoby/central/cgi- > bin/MOBY-Central.pl > > Hope this helps, > > Pi > > > Thanks, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From simont at mcw.edu Tue Oct 4 11:17:20 2005 From: simont at mcw.edu (Twigger Simon) Date: Tue Oct 4 11:43:52 2005 Subject: [MOBY-dev] TWiki taken offline In-Reply-To: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> References: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, There do appear to be some Wiki plugins for wordpress so in theory we could implement something similar over there. I could install it and we could play with it for a while... S. On Oct 3, 2005, at 12:16 PM, Mark Wilkinson wrote: > Hi all, > > I've decided to take the TWiki down after several recent serious > security alerts that would require installation of a newer version > (and > installation of TWiki is not something I can do with my left hand, > unfortunately... it's a bit ugly!) Since we're moving to the new > website anyway, I don't see the point in the investment of time on the > old one. > > I will continue to move documents over to the new site as I get the > chance. Others are welcome to help :-) > > If there is anything on the TWiki that you need urgently, let me know > and I'll make the document available some other way. > > 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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From jpsanchez at isciii.es Tue Oct 4 11:51:22 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 11:52:35 2005 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 11:46:59 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Oct 4 11:53:53 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: References: <000c01c5c8e9$cffac320$6500a8c0@notebook> Message-ID: <0C17CCE2-4EC0-42BE-926A-89B14004BAF3@wur.nl> Hi Eddie, I found another interesting example. In this case I didn't loose any child elements, but they got appended to the wrong parent element ??? TropGENE_ACESSION TropGENE_LOCUS TropGENE_ALLELE TropGENE_LINKAGE_GROUP TropGENE_MAP_POSITION If I use the object above I get as input for a service: TropGENE_ACESSION TropGENE_LOCUS TropGENE_ALLELE TropGENE_MAP_POSITION TropGENE_LINKAGE_GROUP Hence, the TropGENE_MAP_POSITION is appended to the wrong child. The intermediate output of the processor that creates TropGENE_LINKAGE_GROUP seems to be fine, but when TropGENE_LINKAGE_GROUP is appended to TropGENE_LOCUS, the TropGENE_MAP_POSITION element jumps from the TropGENE_LINKAGE_GROUP to the TropGENE_ALLELE element... Regards, Pieter From jpsanchez at isciii.es Tue Oct 4 11:58:03 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 11:57:48 2005 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 12:03:59 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Oct 4 12:05:48 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> References: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> Message-ID: <71484B4E-298B-4423-BF74-D968B86E644B@wur.nl> On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: > No you are on to something! When I first created the plugin, > I used a certain xml parser based on w3c dom. I had to > switch to another parser and it seems that I was unaware of > its limitations (getChildren only gets the direct children > of an element). > > I will have this fixed fairly soon. I'm looking forward to "testdrive" it :) Thanks, Pieter > > Thanks, > > Eddie > >> -----Original Message----- >> From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter >> Neerincx >> Sent: Tuesday, October 04, 2005 8:07 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> >> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >> >> >>>> moby:MOBY >>>> moby:Content >>>> moby:Data >>>> moby:Simple >>>> moby:My_Child_Level_1B >>>> moby:My_Child_Level_2A >>>> moby:My_Child_Level_2B >>>> >>>> >>>> >>> >>> Do you have an example of an object that has this type >>> >> of >> >>> structure? >>> >> >> Yes, try for example DnaSequenceHolder from the BioMOBY >> Central. >> >> I have been running some other tests in the mean time and >> so far >> almost every object I tried lacks child elements at level >> 2 or >> further down. The only one that does have an element at >> level 2 is >> the BlastJob object I have in my local Central. This one >> has Strings, >> Objects and a DataTime at level 2 or further down. >> Everything is >> missing except the DataTime primitive... I noticed that >> hardly anyone >> is using the DataTime primitive if I'm not the only one >> using. It is >> also hardly documented. Maybe it's just random noise in my >> testing or >> maybe I'm onto something.... >> >> If you want to try the BlastJob object my local registry >> should still >> be accessible from outside at: >> http://137.224.52.237/phenolink/biomoby/central/cgi- >> bin/MOBY-Central.pl >> >> Hope this helps, >> >> Pi >> >> >>> Thanks, >>> >>> Eddie >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx@wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From jpsanchez at isciii.es Tue Oct 4 12:04:48 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 12:05:51 2005 Subject: Autoreply: Re: [MOBY-dev] TWiki taken offline Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From jpsanchez at isciii.es Tue Oct 4 12:13:00 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 12:14:40 2005 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From edward.kawas at gmail.com Tue Oct 4 13:00:50 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 13:27:13 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <0C17CCE2-4EC0-42BE-926A-89B14004BAF3@wur.nl> Message-ID: <000e01c5c905$2eb83210$6500a8c0@notebook> Hi Pieter, I was wondering if you had a workflow that you use to build the object and run it with a Moby service. If you have one, do you think that you could email it to me? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > I found another interesting example. In this case I didn't > loose any > child elements, but they got appended to the wrong parent > element ??? > > TropGENE_ACESSION > TropGENE_LOCUS > TropGENE_ALLELE > TropGENE_LINKAGE_GROUP > TropGENE_MAP_POSITION > > If I use the object above I get as input for a service: > > TropGENE_ACESSION > TropGENE_LOCUS > TropGENE_ALLELE > TropGENE_MAP_POSITION > TropGENE_LINKAGE_GROUP > > Hence, the TropGENE_MAP_POSITION is appended to the wrong > child. The > intermediate output of the processor that creates > TropGENE_LINKAGE_GROUP seems to be fine, but when > TropGENE_LINKAGE_GROUP is appended to TropGENE_LOCUS, the > TropGENE_MAP_POSITION element jumps from the > TropGENE_LINKAGE_GROUP > to the TropGENE_ALLELE element... > > Regards, > > Pieter > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 13:32:39 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 13:32:11 2005 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From edward.kawas at gmail.com Tue Oct 4 11:12:29 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 13:44:26 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: Message-ID: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> No you are on to something! When I first created the plugin, I used a certain xml parser based on w3c dom. I had to switch to another parser and it seems that I was unaware of its limitations (getChildren only gets the direct children of an element). I will have this fixed fairly soon. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:07 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > > >> moby:MOBY > >> moby:Content > >> moby:Data > >> moby:Simple > >> moby:My_Child_Level_1B > >> moby:My_Child_Level_2A > >> moby:My_Child_Level_2B > >> > >> > > > > Do you have an example of an object that has this type > of > > structure? > > Yes, try for example DnaSequenceHolder from the BioMOBY > Central. > > I have been running some other tests in the mean time and > so far > almost every object I tried lacks child elements at level > 2 or > further down. The only one that does have an element at > level 2 is > the BlastJob object I have in my local Central. This one > has Strings, > Objects and a DataTime at level 2 or further down. > Everything is > missing except the DataTime primitive... I noticed that > hardly anyone > is using the DataTime primitive if I'm not the only one > using. It is > also hardly documented. Maybe it's just random noise in my > testing or > maybe I'm onto something.... > > If you want to try the BlastJob object my local registry > should still > be accessible from outside at: > http://137.224.52.237/phenolink/biomoby/central/cgi- > bin/MOBY-Central.pl > > Hope this helps, > > Pi > > > Thanks, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 13:48:22 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 13:47:50 2005 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From francis_gibbons at hms.harvard.edu Tue Oct 4 14:38:29 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue Oct 4 14:37:55 2005 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Message-ID: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Hi, I'm trying to deregister some services originally created about a year ago. At the time I used the MOBY-S Perl API to do the job. Then Mark told us to go to a page which would generate RDF for us, which I dutifully did. But then the agent never really seemed to go into use. I threw away the RDF file, but my services remain registered; problem is, I can't deregister them using the API either. So they're currently immortal zombie services: they just won't die. That's a problem because I initially put up a number of services which were limited. Now that I'm older and wiser ;-), I'd like to rework them, but can't. I really don't want to create more services, since they more or less duplicate, but not exactly, the function of the existing ones. I simply want to revamp the existing ones. Can anyone tell me how I can do it? -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 jpsanchez at isciii.es Tue Oct 4 14:42:21 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 14:41:51 2005 Subject: Autoreply: [MOBY-dev] Can't deregister services originally registered throughmethods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From edward.kawas at gmail.com Tue Oct 4 15:12:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 15:12:14 2005 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <000001c5c917$85a34df0$6500a8c0@notebook> Hi Frank, You can't remove a service if you specified a signature url. With that being said, if you give me the servicenames and authority of the services that you would like to remove, I can 'erase' the signature url and then you can remove them. Does this sound good to you? And to confirm, you are talking about services registered in the default Mobycentral registry? Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Frank > Gibbons > Sent: Tuesday, October 04, 2005 11:38 AM > To: MOBY-dev@biomoby.org > Subject: [MOBY-dev] Can't deregister services originally > registered through methods, then converted to RDF > > Hi, > > I'm trying to deregister some services originally created > about a year ago. > At the time I used the MOBY-S Perl API to do the job. Then > Mark told us to > go to a page which would generate RDF for us, which I > dutifully did. But > then the agent never really seemed to go into use. I threw > away the RDF > file, but my services remain registered; problem is, I > can't deregister > them using the API either. So they're currently immortal > zombie services: > they just won't die. > > That's a problem because I initially put up a number of > services which were > limited. Now that I'm older and wiser ;-), I'd like to > rework them, but > can't. I really don't want to create more services, since > they more or less > duplicate, but not exactly, the function of the existing > ones. I simply > want to revamp the existing ones. > > Can anyone tell me how I can do it? > > -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-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 15:17:28 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 15:17:17 2005 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From markw at illuminae.com Tue Oct 4 15:15:02 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue Oct 4 15:21:09 2005 Subject: [MOBY-dev] Can't deregister services originally registered throughmethods, then converted to RDF Message-ID: <281305509-1128453358-cardhu_blackberry.rim.net-7785-@engine10-cell01> Hi Frank - give me a minute and I'll delete your signatureRDF's. The delay in the agent is due to our decision to synchronize our data models with myGrid, but that's takint longer than expected. I'll do it now, M -----Original Message----- From: Frank Gibbons Date: Tue, 04 Oct 2005 14:38:29 To:MOBY-dev@biomoby.org Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Hi, I'm trying to deregister some services originally created about a year ago. At the time I used the MOBY-S Perl API to do the job. Then Mark told us to go to a page which would generate RDF for us, which I dutifully did. But then the agent never really seemed to go into use. I threw away the RDF file, but my services remain registered; problem is, I can't deregister them using the API either. So they're currently immortal zombie services: they just won't die. That's a problem because I initially put up a number of services which were limited. Now that I'm older and wiser ;-), I'd like to rework them, but can't. I really don't want to create more services, since they more or less duplicate, but not exactly, the function of the existing ones. I simply want to revamp the existing ones. Can anyone tell me how I can do it? -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-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Tue Oct 4 15:16:08 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue Oct 4 15:22:00 2005 Subject: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: <1190951208-1128453424-cardhu_blackberry.rim.net-5001-@engine13-cell01> Eddie please do this. It will be easier for you to do it than for me to do it by ssh on my blackberry :-) Hello from the Biomoby scientific defense/review! Wish me luck!!! M -----Original Message----- From: "Edward Kawas" Date: Tue, 4 Oct 2005 12:12:09 To:"'Core developer announcements'" Subject: RE: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Hi Frank, You can't remove a service if you specified a signature url. With that being said, if you give me the servicenames and authority of the services that you would like to remove, I can 'erase' the signature url and then you can remove them. Does this sound good to you? And to confirm, you are talking about services registered in the default Mobycentral registry? Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Frank > Gibbons > Sent: Tuesday, October 04, 2005 11:38 AM > To: MOBY-dev@biomoby.org > Subject: [MOBY-dev] Can't deregister services originally > registered through methods, then converted to RDF > > Hi, > > I'm trying to deregister some services originally created > about a year ago. > At the time I used the MOBY-S Perl API to do the job. Then > Mark told us to > go to a page which would generate RDF for us, which I > dutifully did. But > then the agent never really seemed to go into use. I threw > away the RDF > file, but my services remain registered; problem is, I > can't deregister > them using the API either. So they're currently immortal > zombie services: > they just won't die. > > That's a problem because I initially put up a number of > services which were > limited. Now that I'm older and wiser ;-), I'd like to > rework them, but > can't. I really don't want to create more services, since > they more or less > duplicate, but not exactly, the function of the existing > ones. I simply > want to revamp the existing ones. > > Can anyone tell me how I can do it? > > -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-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Tue Oct 4 15:25:11 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 15:32:18 2005 Subject: [MOBY-dev] Can't deregister services originally registeredthroughmethods, then converted to RDF In-Reply-To: <1190951208-1128453424-cardhu_blackberry.rim.net-5001-@engine13-cell01> Message-ID: <000101c5c919$57a73b30$6500a8c0@notebook> Good luck Mark!!! I will do it right away! Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of mark > wilkinson > Sent: Tuesday, October 04, 2005 12:16 PM > To: Core developer announcements > Subject: Re: [MOBY-dev] Can't deregister services > originally registeredthroughmethods, then converted to RDF > > Eddie please do this. It will be easier for you to do it > than for me to do it by ssh on my blackberry :-) > > Hello from the Biomoby scientific defense/review! Wish me > luck!!! > > M > > > -----Original Message----- > From: "Edward Kawas" > Date: Tue, 4 Oct 2005 12:12:09 > To:"'Core developer announcements'" bio.org> > Subject: RE: [MOBY-dev] Can't deregister services > originally registered > through methods, then converted to RDF > > Hi Frank, > > You can't remove a service if you specified a signature > url. > With that being said, if you give me the servicenames and > authority of the services that you would like to remove, I > can 'erase' the signature url and then you can remove them. > > Does this sound good to you? And to confirm, you are > talking > about services registered in the default Mobycentral > registry? > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > > dev-bounces@portal.open-bio.org] On Behalf Of Frank > > Gibbons > > Sent: Tuesday, October 04, 2005 11:38 AM > > To: MOBY-dev@biomoby.org > > Subject: [MOBY-dev] Can't deregister services originally > > registered through methods, then converted to RDF > > > > Hi, > > > > I'm trying to deregister some services originally > created > > about a year ago. > > At the time I used the MOBY-S Perl API to do the job. > Then > > Mark told us to > > go to a page which would generate RDF for us, which I > > dutifully did. But > > then the agent never really seemed to go into use. I > threw > > away the RDF > > file, but my services remain registered; problem is, I > > can't deregister > > them using the API either. So they're currently immortal > > zombie services: > > they just won't die. > > > > That's a problem because I initially put up a number of > > services which were > > limited. Now that I'm older and wiser ;-), I'd like to > > rework them, but > > can't. I really don't want to create more services, > since > > they more or less > > duplicate, but not exactly, the function of the existing > > ones. I simply > > want to revamp the existing ones. > > > > Can anyone tell me how I can do it? > > > > -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-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Tue Oct 4 15:35:19 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 15:34:51 2005 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <000201c5c91a$c1f99860$6500a8c0@notebook> Hi Frank, I set your signature URLS, with contact email fgibbons @ hms.harvard.edu, to NULL. You should now be able to remove your services. Eddie From jpsanchez at isciii.es Tue Oct 4 15:36:19 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 15:35:50 2005 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originallyregisteredthroughmethods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From jpsanchez at isciii.es Tue Oct 4 15:39:54 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 15:39:24 2005 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From francis_gibbons at hms.harvard.edu Tue Oct 4 15:42:35 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue Oct 4 15:40:36 2005 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <000001c5c917$85a34df0$6500a8c0@notebook> References: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051004153438.01190d18@email.med.harvard.edu> Hi Eddie. Yeah, I know that I'm not supposed to be able to remove a service through the API if I have a signature URL. But that sort of assumes that there's an agent looking for RDF at the signature URL, and continuously updating the service registry. It's not meant to be that you can *never* remove a service that has a signature URL, right? I guess you meant that if it has a signature URL in the database, then it's not supposed to be deletable - well, it's still the same situation for me, since I don't think I can change the signature URL in the database, once the service is registered. Anyway, as per Mark's recent message, I'd really appreciate it if you could remove the signature URL for the following services: ASimpleService YAService DBI_CSV The authority is llama.med.harvard.edu They're all in the default registry. If I understand correctly, once you delete the signature URL from the database, then I should be able to delete them using the Perl API function call - correct? That would be awsome. Thanks a lot, -Frank At 03:12 PM 10/4/2005, you wrote: >Hi Frank, > >You can't remove a service if you specified a signature url. >With that being said, if you give me the servicenames and >authority of the services that you would like to remove, I >can 'erase' the signature url and then you can remove them. > >Does this sound good to you? And to confirm, you are talking >about services registered in the default Mobycentral >registry? > >Eddie > > > -----Original Message----- > > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > > dev-bounces@portal.open-bio.org] On Behalf Of Frank > > Gibbons > > Sent: Tuesday, October 04, 2005 11:38 AM > > To: MOBY-dev@biomoby.org > > Subject: [MOBY-dev] Can't deregister services originally > > registered through methods, then converted to RDF > > > > Hi, > > > > I'm trying to deregister some services originally created > > about a year ago. > > At the time I used the MOBY-S Perl API to do the job. Then > > Mark told us to > > go to a page which would generate RDF for us, which I > > dutifully did. But > > then the agent never really seemed to go into use. I threw > > away the RDF > > file, but my services remain registered; problem is, I > > can't deregister > > them using the API either. So they're currently immortal > > zombie services: > > they just won't die. > > > > That's a problem because I initially put up a number of > > services which were > > limited. Now that I'm older and wiser ;-), I'd like to > > rework them, but > > can't. I really don't want to create more services, since > > they more or less > > duplicate, but not exactly, the function of the existing > > ones. I simply > > want to revamp the existing ones. > > > > Can anyone tell me how I can do it? > > > > -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-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 jpsanchez at isciii.es Tue Oct 4 15:44:33 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue Oct 4 15:44:01 2005 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. From gordonp at ucalgary.ca Tue Oct 4 16:03:52 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue Oct 4 16:03:50 2005 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: References: Message-ID: <4342E028.2040806@ucalgary.ca> Next time we have a MOBY meeting, Juan is buying us all a round of beer as punishment for setting autoreplies on mailing list messages... >Hola, >He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. >Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo@gmail.com. > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From edward.kawas at gmail.com Tue Oct 4 20:52:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 4 21:17:42 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <71484B4E-298B-4423-BF74-D968B86E644B@wur.nl> Message-ID: <001101c5c947$04dfbd40$6500a8c0@notebook> Hi Pieter! I tracked down the bug and I fixed it (*fingers crossed*). I am placing 2 jar files at the following links that need to replace the ones in your /taverna-workbench-1.3/lib/ directory: http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar Be sure to backup the 2 files you are about to replace, just in case! Then try out your workflows and let me know what happens. Also, if all is well, do you think that you could send me one of those workflows so I can use it as an example? Thanks a lot, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Tuesday, October 04, 2005 9:04 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: > > > No you are on to something! When I first created the > plugin, > > I used a certain xml parser based on w3c dom. I had to > > switch to another parser and it seems that I was unaware > of > > its limitations (getChildren only gets the direct > children > > of an element). > > > > I will have this fixed fairly soon. > > I'm looking forward to "testdrive" it :) > > Thanks, > > Pieter > > > > > Thanks, > > > > Eddie > > > >> -----Original Message----- > >> From: moby-dev-bounces@portal.open-bio.org > [mailto:moby- > >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter > >> Neerincx > >> Sent: Tuesday, October 04, 2005 8:07 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > >> missing in BioMOBYobjects > >> > >> > >> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > >> > >> > >>>> moby:MOBY > >>>> moby:Content > >>>> moby:Data > >>>> moby:Simple > >>>> moby:My_Child_Level_1B > >>>> moby:My_Child_Level_2A > >>>> moby:My_Child_Level_2B > >>>> > >>>> > >>>> > >>> > >>> Do you have an example of an object that has this type > >>> > >> of > >> > >>> structure? > >>> > >> > >> Yes, try for example DnaSequenceHolder from the BioMOBY > >> Central. > >> > >> I have been running some other tests in the mean time > and > >> so far > >> almost every object I tried lacks child elements at > level > >> 2 or > >> further down. The only one that does have an element at > >> level 2 is > >> the BlastJob object I have in my local Central. This > one > >> has Strings, > >> Objects and a DataTime at level 2 or further down. > >> Everything is > >> missing except the DataTime primitive... I noticed that > >> hardly anyone > >> is using the DataTime primitive if I'm not the only one > >> using. It is > >> also hardly documented. Maybe it's just random noise in > my > >> testing or > >> maybe I'm onto something.... > >> > >> If you want to try the BlastJob object my local > registry > >> should still > >> be accessible from outside at: > >> http://137.224.52.237/phenolink/biomoby/central/cgi- > >> bin/MOBY-Central.pl > >> > >> Hope this helps, > >> > >> Pi > >> > >> > >>> Thanks, > >>> > >>> Eddie > >>> > >>> _______________________________________________ > >>> MOBY-dev mailing list > >>> MOBY-dev@biomoby.org > >>> http://www.biomoby.org/mailman/listinfo/moby-dev > >>> > >>> > >> > >> > >> Wageningen University and Research centre (WUR) > >> Laboratory of Bioinformatics > >> Transitorium (building 312) room 1034 > >> Dreijenlaan 3 > >> 6703 HA Wageningen > >> The Netherlands > >> phone: 0317-483 060 > >> fax: 0317-483 584 > >> mobile: 06-143 66 783 > >> pieter.neerincx@wur.nl > >> > >> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev@biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Thu Oct 6 11:32:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu Oct 6 11:41:50 2005 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > Hi all, > > As we move toward deploying the new API, there are some serious > consequences on the underlying databases. > > Let me first re-cap the new API features that I am discussing and what > effects they have on the databases: > > 1) Inheritence from primitives through ISA relationships is no longer > allowed. e.g. plain-text ISA String is no longer allowed. To > achieve > the same result, you now create an object that inherits from Object > and > contains the primitive. e.g. plain-text ISA Object; plain-text HASA > String. Hi Mark et al., Any idea when this change will happen? If I look in the Central that is running the latest and greatest codebase, the forbidden ISA [some primitive] relationships are still in place :(. What is even worse is that the primitive DateTime ISA String. As a result I can not get one of my Objects (that plays by the rules of the latest specs) registered. At least I suspect this to be the problem. I don't get an error message when register my object, but it has amongst others a HASA DataTime and that relationship is not getting registered... Cheers, Pi Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From markw at illuminae.com Thu Oct 6 12:08:10 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Oct 6 12:34:29 2005 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> As you have noticed, the change has already happened at the code level just to prevent any more registrations of what will soon be illegal objects. I have a script that will update the database records of the ontologies and deprecate the old nodes, but we haven't yet run it on the public registry. Eddie is going to make a couple of changes to it over the next day or two, and then will send out a heads-up that the ontologies are changing forever, and a tutorial on how to do the update for service providers. We'll give a reasonable amount of time for people to update their services (say, 6 weeks) and then we will delete the old nodes from the ontology completely. The script is in the CVS so anyone running a registry can do the same thing. When I went to update my own services it took me less than 5 minutes to do so, so 6 weeks should be more than enough time for anyone who is actively concerned about their service :-) Cheers! M On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > Hi all, > > > > As we move toward deploying the new API, there are some serious > > consequences on the underlying databases. > > > > Let me first re-cap the new API features that I am discussing and what > > effects they have on the databases: > > > > 1) Inheritence from primitives through ISA relationships is no longer > > allowed. e.g. plain-text ISA String is no longer allowed. To > > achieve > > the same result, you now create an object that inherits from Object > > and > > contains the primitive. e.g. plain-text ISA Object; plain-text HASA > > String. > > Hi Mark et al., > > Any idea when this change will happen? If I look in the Central that > is running the latest and greatest codebase, the forbidden ISA [some > primitive] relationships are still in place :(. What is even worse is > that the primitive DateTime ISA String. As a result I can not get one > of my Objects (that plays by the rules of the latest specs) > registered. At least I suspect this to be the problem. I don't get an > error message when register my object, but it has amongst others a > HASA DataTime and that relationship is not getting registered... > > Cheers, > > Pi > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "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 Thu Oct 6 17:39:45 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Oct 6 17:40:03 2005 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <000101c5cab8$549b3c20$6500a8c0@notebook> References: <000101c5cab8$549b3c20$6500a8c0@notebook> Message-ID: <1128634785.1179.111.camel@bioinfo.icapture.ubc.ca> It's not just that, it's also the "spirit" of the matter. e.g. our LSID's are based on the name of the object. Granted, we currently only return metadata, so we could in principle re-define the object without breaking the LSID standard, but it does break the "spirit" of the identifier. But having said that, I don't particularly care one way or the other. It's painful no matter what we do. 1) If we change to _2, deprecate the old ones, and after 6 weeks delete the old, leaving the _2's in their place then: a) people who are affected will have to update their servces b) people will have to re-register their services 2) If we change to _2 temporarily, deprecate, delete, and then rename the _2's back again after 6 weeks: a) people affected will have to either i) update their services, re-register, then ii) update their services again and re-register OR i) update their services and NOT re-register, and ii) their services will be "illegal" for 6 weeks, There's no painless way to do this, so whatever the community feels is best... M On Thu, 2005-10-06 at 13:55 -0700, Edward Kawas wrote: > Hi, > > I am working on this script right now as we speak, but I > just wanted to get feedback (for a second time). > > >From what I understand, I am going to go through the > ontology, and deprecate any data type that inherits from a > primitive. Any object that I deprecate will be duplicated > and have an _2 appended to its name as well as having its > ISA relationship set to object and adding a HASA primitive > relationship. So far so good. > > In six weeks, I am going to go through the ontology and > remove all objects that inherit from a primitive, leaving > those that were duplicated with an _2 alone. Therefore, in 6 > weeks, we will have objects like text-plain_2, text-xml_2, > etc. > > I know that some people are fine with this and others are > not. Some might not even care. However, what I want to know > is what MOBYers think and if anyone has any other > comments/suggestions. So please let me know. > > Just to get this started, I am still pretty iffy about > leaving x_2 data types in the ontology. I do see Marks point > on how services that are not updated choking since they > expect the data type to inherit from a primitive. Any ideas? > > Thanks, > > Eddie > > > -----Original Message----- > > From: Mark Wilkinson [mailto:markw@illuminae.com] > > Sent: Thursday, October 06, 2005 9:08 AM > > To: Core developer announcements > > Cc: Eddie Kawas > > Subject: Re: [moby] Re: [MOBY-dev] Migration of database > > to new API > > > > As you have noticed, the change has already happened at > > the code level > > just to prevent any more registrations of what will soon > > be illegal > > objects. I have a script that will update the database > > records of the > > ontologies and deprecate the old nodes, but we haven't yet > > run it on the > > public registry. Eddie is going to make a couple of > > changes to it over > > the next day or two, and then will send out a heads-up > > that the > > ontologies are changing forever, and a tutorial on how to > > do the update > > for service providers. We'll give a reasonable amount of > > time for > > people to update their services (say, 6 weeks) and then we > > will delete > > the old nodes from the ontology completely. The script is > > in the CVS so > > anyone running a registry can do the same thing. > > > > When I went to update my own services it took me less than > > 5 minutes to > > do so, so 6 weeks should be more than enough time for > > anyone who is > > actively concerned about their service :-) > > > > Cheers! > > > > M > > > > > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > > > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > > > > > Hi all, > > > > > > > > As we move toward deploying the new API, there are > > some serious > > > > consequences on the underlying databases. > > > > > > > > Let me first re-cap the new API features that I am > > discussing and what > > > > effects they have on the databases: > > > > > > > > 1) Inheritence from primitives through ISA > > relationships is no longer > > > > allowed. e.g. plain-text ISA String is no longer > > allowed. To > > > > achieve > > > > the same result, you now create an object that > > inherits from Object > > > > and > > > > contains the primitive. e.g. plain-text ISA Object; > > plain-text HASA > > > > String. > > > > > > Hi Mark et al., > > > > > > Any idea when this change will happen? If I look in the > > Central that > > > is running the latest and greatest codebase, the > > forbidden ISA [some > > > primitive] relationships are still in place :(. What is > > even worse is > > > that the primitive DateTime ISA String. As a result I > > can not get one > > > of my Objects (that plays by the rules of the latest > > specs) > > > registered. At least I suspect this to be the problem. I > > don't get an > > > error message when register my object, but it has > > amongst others a > > > HASA DataTime and that relationship is not getting > > registered... > > > > > > Cheers, > > > > > > Pi > > > > > > > > > > > > > > > Wageningen University and Research centre (WUR) > > > Laboratory of Bioinformatics > > > Transitorium (building 312) room 1034 > > > Dreijenlaan 3 > > > 6703 HA Wageningen > > > The Netherlands > > > phone: 0317-483 060 > > > fax: 0317-483 584 > > > mobile: 06-143 66 783 > > > pieter.neerincx@wur.nl > > > > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev@biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > > "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 > -- "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 edward.kawas at gmail.com Thu Oct 6 16:55:47 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Oct 6 18:36:48 2005 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: <000101c5cab8$549b3c20$6500a8c0@notebook> Hi, I am working on this script right now as we speak, but I just wanted to get feedback (for a second time). >From what I understand, I am going to go through the ontology, and deprecate any data type that inherits from a primitive. Any object that I deprecate will be duplicated and have an _2 appended to its name as well as having its ISA relationship set to object and adding a HASA primitive relationship. So far so good. In six weeks, I am going to go through the ontology and remove all objects that inherit from a primitive, leaving those that were duplicated with an _2 alone. Therefore, in 6 weeks, we will have objects like text-plain_2, text-xml_2, etc. I know that some people are fine with this and others are not. Some might not even care. However, what I want to know is what MOBYers think and if anyone has any other comments/suggestions. So please let me know. Just to get this started, I am still pretty iffy about leaving x_2 data types in the ontology. I do see Marks point on how services that are not updated choking since they expect the data type to inherit from a primitive. Any ideas? Thanks, Eddie > -----Original Message----- > From: Mark Wilkinson [mailto:markw@illuminae.com] > Sent: Thursday, October 06, 2005 9:08 AM > To: Core developer announcements > Cc: Eddie Kawas > Subject: Re: [moby] Re: [MOBY-dev] Migration of database > to new API > > As you have noticed, the change has already happened at > the code level > just to prevent any more registrations of what will soon > be illegal > objects. I have a script that will update the database > records of the > ontologies and deprecate the old nodes, but we haven't yet > run it on the > public registry. Eddie is going to make a couple of > changes to it over > the next day or two, and then will send out a heads-up > that the > ontologies are changing forever, and a tutorial on how to > do the update > for service providers. We'll give a reasonable amount of > time for > people to update their services (say, 6 weeks) and then we > will delete > the old nodes from the ontology completely. The script is > in the CVS so > anyone running a registry can do the same thing. > > When I went to update my own services it took me less than > 5 minutes to > do so, so 6 weeks should be more than enough time for > anyone who is > actively concerned about their service :-) > > Cheers! > > M > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > > > Hi all, > > > > > > As we move toward deploying the new API, there are > some serious > > > consequences on the underlying databases. > > > > > > Let me first re-cap the new API features that I am > discussing and what > > > effects they have on the databases: > > > > > > 1) Inheritence from primitives through ISA > relationships is no longer > > > allowed. e.g. plain-text ISA String is no longer > allowed. To > > > achieve > > > the same result, you now create an object that > inherits from Object > > > and > > > contains the primitive. e.g. plain-text ISA Object; > plain-text HASA > > > String. > > > > Hi Mark et al., > > > > Any idea when this change will happen? If I look in the > Central that > > is running the latest and greatest codebase, the > forbidden ISA [some > > primitive] relationships are still in place :(. What is > even worse is > > that the primitive DateTime ISA String. As a result I > can not get one > > of my Objects (that plays by the rules of the latest > specs) > > registered. At least I suspect this to be the problem. I > don't get an > > error message when register my object, but it has > amongst others a > > HASA DataTime and that relationship is not getting > registered... > > > > Cheers, > > > > Pi > > > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx@wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "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 Pieter.Neerincx at wur.nl Fri Oct 7 05:16:23 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Oct 7 05:17:11 2005 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: On 6-Oct-2005, at 6:08 PM, Mark Wilkinson wrote: > As you have noticed, the change has already happened at the code level > just to prevent any more registrations of what will soon be illegal > objects. That would be fine, but I have upgraded my service and objects to conform to the new standard and can not register legal stuff :(. > I have a script that will update the database records of the > ontologies and deprecate the old nodes, but we haven't yet run it > on the > public registry. Eddie is going to make a couple of changes to it > over > the next day or two, and then will send out a heads-up that the > ontologies are changing forever, and a tutorial on how to do the > update > for service providers. We'll give a reasonable amount of time for > people to update their services (say, 6 weeks) and then we will delete > the old nodes from the ontology completely. The script is in the > CVS so > anyone running a registry can do the same thing. I'll run that script on my local central to see if I can register after the change. > > When I went to update my own services it took me less than 5 > minutes to > do so, so 6 weeks should be more than enough time for anyone who is > actively concerned about their service :-) IMHO it might be even a bit too much. Personally I opt for 2) If we change to _2 temporarily, deprecate, delete, and then rename the _2's back again after 6 weeks: with: i) update their services and NOT re-register, and ii) their services will be "illegal" for 6 weeks, This keeps the ontology clean. This change was announced long enough ago to give people a chance to update their services. For me it took even less time. I didn't have to update my services at all. When I extract for example text from a CustomObject ISA String object I was already assuming it would not have any HASA relations, because it is a primitive. So I was getting the text from that node and any childs it might have. After the change, if my service fetches text from CustomObject I get the text from it's HASA String. No recoding needed; painless change :). I did spend the 5 minutes though on the scripts I use to register my services at a central. Anyway, for the DateTime primitive things are still a bit strange. Currently DateTime ISA String ISA Object. All other primitives are simply ISA Object. This will change to DateTime ISA Object and HASA String. According to the spec DateTime shouldn't have a String, because it is by itself already a primitive... In the current situation DateTime is not a primitive, but just yet another type of String. just my 2c, Pi > > Cheers! > > M > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > >> On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> As we move toward deploying the new API, there are some serious >>> consequences on the underlying databases. >>> >>> Let me first re-cap the new API features that I am discussing and >>> what >>> effects they have on the databases: >>> >>> 1) Inheritence from primitives through ISA relationships is no >>> longer >>> allowed. e.g. plain-text ISA String is no longer allowed. To >>> achieve >>> the same result, you now create an object that inherits from Object >>> and >>> contains the primitive. e.g. plain-text ISA Object; plain-text HASA >>> String. >>> >> >> Hi Mark et al., >> >> Any idea when this change will happen? If I look in the Central that >> is running the latest and greatest codebase, the forbidden ISA [some >> primitive] relationships are still in place :(. What is even worse is >> that the primitive DateTime ISA String. As a result I can not get one >> of my Objects (that plays by the rules of the latest specs) >> registered. At least I suspect this to be the problem. I don't get an >> error message when register my object, but it has amongst others a >> HASA DataTime and that relationship is not getting registered... >> >> Cheers, >> >> Pi >> >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx@wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From Pieter.Neerincx at wur.nl Fri Oct 7 05:30:14 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Oct 7 05:30:58 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <001101c5c947$04dfbd40$6500a8c0@notebook> References: <001101c5c947$04dfbd40$6500a8c0@notebook> Message-ID: <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> Hi Eddie, On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > Hi Pieter! > > I tracked down the bug and I fixed it (*fingers crossed*). > > I am placing 2 jar files at the following links that need to > replace the ones in your /taverna-workbench-1.3/lib/ > directory: > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > Be sure to backup the 2 files you are about to replace, just > in case! > > Then try out your workflows and let me know what happens. I did some simple tests with the objects that failed previously and so far so good :) Thanks for the quick fix! > > Also, if all is well, do you think that you could send me > one of those workflows so I can use it as an example? After a lot of trail and error playing with a local central I think it's about time I register my services and objects at the central Central as well. Will do so once the central Central databases are migrated to the new API... Cheers, Pi > Thanks a lot, > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter >> Neerincx >> Sent: Tuesday, October 04, 2005 9:04 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> >> On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: >> >> >>> No you are on to something! When I first created the >>> >> plugin, >> >>> I used a certain xml parser based on w3c dom. I had to >>> switch to another parser and it seems that I was unaware >>> >> of >> >>> its limitations (getChildren only gets the direct >>> >> children >> >>> of an element). >>> >>> I will have this fixed fairly soon. >>> >> >> I'm looking forward to "testdrive" it :) >> >> Thanks, >> >> Pieter >> >> >>> >>> Thanks, >>> >>> Eddie >>> >>> >>>> -----Original Message----- >>>> From: moby-dev-bounces@portal.open-bio.org >>>> >> [mailto:moby- >> >>>> dev-bounces@portal.open-bio.org] On Behalf Of Pieter >>>> Neerincx >>>> Sent: Tuesday, October 04, 2005 8:07 AM >>>> To: Core developer announcements >>>> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >>>> missing in BioMOBYobjects >>>> >>>> >>>> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >>>> >>>> >>>> >>>>>> moby:MOBY >>>>>> moby:Content >>>>>> moby:Data >>>>>> moby:Simple >>>>>> moby:My_Child_Level_1B >>>>>> moby:My_Child_Level_2A >>>>>> moby:My_Child_Level_2B >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Do you have an example of an object that has this type >>>>> >>>>> >>>> of >>>> >>>> >>>>> structure? >>>>> >>>>> >>>> >>>> Yes, try for example DnaSequenceHolder from the BioMOBY >>>> Central. >>>> >>>> I have been running some other tests in the mean time >>>> >> and >> >>>> so far >>>> almost every object I tried lacks child elements at >>>> >> level >> >>>> 2 or >>>> further down. The only one that does have an element at >>>> level 2 is >>>> the BlastJob object I have in my local Central. This >>>> >> one >> >>>> has Strings, >>>> Objects and a DataTime at level 2 or further down. >>>> Everything is >>>> missing except the DataTime primitive... I noticed that >>>> hardly anyone >>>> is using the DataTime primitive if I'm not the only one >>>> using. It is >>>> also hardly documented. Maybe it's just random noise in >>>> >> my >> >>>> testing or >>>> maybe I'm onto something.... >>>> >>>> If you want to try the BlastJob object my local >>>> >> registry >> >>>> should still >>>> be accessible from outside at: >>>> http://137.224.52.237/phenolink/biomoby/central/cgi- >>>> bin/MOBY-Central.pl >>>> >>>> Hope this helps, >>>> >>>> Pi >>>> >>>> >>>> >>>>> Thanks, >>>>> >>>>> Eddie >>>>> >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev@biomoby.org >>>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>>> >>>>> >>>>> >>>> >>>> >>>> Wageningen University and Research centre (WUR) >>>> Laboratory of Bioinformatics >>>> Transitorium (building 312) room 1034 >>>> Dreijenlaan 3 >>>> 6703 HA Wageningen >>>> The Netherlands >>>> phone: 0317-483 060 >>>> fax: 0317-483 584 >>>> mobile: 06-143 66 783 >>>> pieter.neerincx@wur.nl >>>> >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev@biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx@wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From markw at illuminae.com Fri Oct 7 10:47:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Oct 7 10:46:57 2005 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: <1128696449.3111.5.camel@bioinfo.icapture.ubc.ca> On Fri, 2005-10-07 at 11:16 +0200, Pieter Neerincx wrote: > Anyway, for the DateTime primitive things are still a bit strange. > Currently DateTime ISA String ISA Object. All other primitives are > simply ISA Object. This will change to DateTime ISA Object and HASA > String. According to the spec DateTime shouldn't have a String, > because it is by itself already a primitive... In the current > situation DateTime is not a primitive, but just yet another type of > String. Okay, I'll have a look at this today. Might be "just a bug" rather than a systemic error :-) M From Pieter.Neerincx at wur.nl Fri Oct 7 13:25:28 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Oct 7 13:38:29 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> References: <001101c5c947$04dfbd40$6500a8c0@notebook> <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> Message-ID: <0DCBF3DF-D564-47ED-9E85-9B669BA49ADA@wur.nl> Hi Eddie, Sorry, I cheered premature :(. For one of my services I use the articleName attribute of two String objects to know which one contains which data. Hence I have something like: Bla bla Alb alb The Object my service receives in Taverna lacks the articleName attributes for it's String childs :(. Hence it becomes this: Bla bla Alb alb Looks like the fix introduced a new bug as well... Pieter On 07Oct2005, at 11:30, Pieter Neerincx wrote: > Hi Eddie, > > On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > > >> Hi Pieter! >> >> I tracked down the bug and I fixed it (*fingers crossed*). >> >> I am placing 2 jar files at the following links that need to >> replace the ones in your /taverna-workbench-1.3/lib/ >> directory: >> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar >> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar >> >> Be sure to backup the 2 files you are about to replace, just >> in case! >> >> Then try out your workflows and let me know what happens. >> > > I did some simple tests with the objects that failed previously and > so far so good :) > > Thanks for the quick fix! > > >> >> Also, if all is well, do you think that you could send me >> one of those workflows so I can use it as an example? >> > > After a lot of trail and error playing with a local central I think > it's about time I register my services and objects at the central > Central as well. Will do so once the central Central databases are > migrated to the new API... > > Cheers, > > Pi > > >> Thanks a lot, >> >> Eddie >> From senger at ebi.ac.uk Sun Oct 9 17:18:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun Oct 9 17:27:18 2005 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <433D0742.4050708@cnb.uam.es> Message-ID: Hi all, Last week, I have met David and he explained to me all what was happenning with the error handling (because I was off-line most of the last week). I agree with the various voices that serviceNotes is better than PIB, and I am happy to hear that Mark has not problem with an additional 'Notes' in 'serviceNotes' (he is probably the only one who is filling serviceNotes now). Could someone summarize the result of voting and publish somewhere the latest version of the API regarding the error handling please? When this is out I will immediately add it to the Moses-based generated services. Thanks and regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: 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 Sun Oct 9 17:48:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun Oct 9 17:48:03 2005 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <000101c5cab8$549b3c20$6500a8c0@notebook> Message-ID: > Just to get this started, I am still pretty iffy about > leaving x_2 data types in the ontology. I do see Marks point > on how services that are not updated choking since they > expect the data type to inherit from a primitive. Any ideas? > As I said before I would suggest: - do not use any automatic script - tell people that after 6 weeks the deprecented data objects will be deleted (together with the services that still use them) - optionally: write a document to advise what people with affected data types types should do (e.g. help them by removing Signature URLs from such services so they can re-register them again) Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: 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 Sun Oct 9 21:35:42 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun Oct 9 21:34:45 2005 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: References: Message-ID: <4349C56E.8000308@illuminae.com> We should also call for a new vote, and perhaps this time simply use the mailing list since the last call for votes only got one response... Let's say October 24th as the final word on this? M Martin Senger wrote: >Hi all, > Last week, I have met David and he explained to me all what was >happenning with the error handling (because I was off-line most of the >last week). I agree with the various voices that serviceNotes is better >than PIB, and I am happy to hear that Mark has not problem with an >additional 'Notes' in 'serviceNotes' (he is probably the only one who is >filling serviceNotes now). > Could someone summarize the result of voting and publish somewhere the >latest version of the API regarding the error handling please? When this >is out I will immediately add it to the Moses-based generated services. > > Thanks and regards, > Martin > > > From senger at ebi.ac.uk Mon Oct 10 04:57:43 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Oct 10 04:57:09 2005 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <4349C56E.8000308@illuminae.com> Message-ID: > We should also call for a new vote, and perhaps this time simply use the > mailing list since the last call for votes only got one response... > > Let's say October 24th as the final word on this? > Where can I can the latest, official, document describing the latest consensus? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From dgpisano at cnb.uam.es Mon Oct 10 06:45:33 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Mon Oct 10 06:51:03 2005 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: References: Message-ID: <434A464D.7070203@cnb.uam.es> The latest version is in the bugzilla http://bugzilla.open-bio.org/attachment.cgi?id=233 David Martin Senger escribi?: >>We should also call for a new vote, and perhaps this time simply use the >>mailing list since the last call for votes only got one response... >> >>Let's say October 24th as the final word on this? >> >> >> > Where can I can the latest, official, document describing the latest >consensus? > > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20051010/deaecc61/dgpisano.vcf From edward.kawas at gmail.com Tue Oct 11 00:58:27 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 11 01:58:22 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <0DCBF3DF-D564-47ED-9E85-9B669BA49ADA@wur.nl> Message-ID: <000401c5ce20$6bcf7300$6900a8c0@notebook> Hi Pieter, I uploaded 2 new files. I am not sure if your bug is fixed, but I thought that I would let you know. I have made new additions and I modified some of the xml parsing, so while I haven't worked on your bug, it may be fixed (or made worse ;-). By the way, do you think that you could send me a workflow whenever you notice something fishy? Thanks, Eddie http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Friday, October 07, 2005 10:25 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > Sorry, I cheered premature :(. For one of my services I > use the > articleName attribute of two String objects to know which > one > contains which data. Hence I have something like: > > > articleName="this.one"> > Bla bla > > articleName="the.other.one"> > Alb alb > > > > The Object my service receives in Taverna lacks the > articleName > attributes for it's String childs :(. Hence it becomes > this: > > > > Bla bla > > > Alb alb > > > > Looks like the fix introduced a new bug as well... > > Pieter > > On 07Oct2005, at 11:30, Pieter Neerincx wrote: > > > Hi Eddie, > > > > On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > > > > > >> Hi Pieter! > >> > >> I tracked down the bug and I fixed it (*fingers > crossed*). > >> > >> I am placing 2 jar files at the following links that > need to > >> replace the ones in your /taverna-workbench-1.3/lib/ > >> directory: > >> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > 1.3.jar > >> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > >> > >> Be sure to backup the 2 files you are about to replace, > just > >> in case! > >> > >> Then try out your workflows and let me know what > happens. > >> > > > > I did some simple tests with the objects that failed > previously and > > so far so good :) > > > > Thanks for the quick fix! > > > > > >> > >> Also, if all is well, do you think that you could send > me > >> one of those workflows so I can use it as an example? > >> > > > > After a lot of trail and error playing with a local > central I think > > it's about time I register my services and objects at > the central > > Central as well. Will do so once the central Central > databases are > > migrated to the new API... > > > > Cheers, > > > > Pi > > > > > >> Thanks a lot, > >> > >> Eddie > >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From carrere at toulouse.inra.fr Thu Oct 13 03:17:34 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu Oct 13 03:22:00 2005 Subject: [MOBY-dev] Hardware upgrade: services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <434E0A0E.50006@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Friday (October 14th) 9.00 a.m. (GMT+1) till monday (October 17th) 11.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Next week, services interruptions should happen... Sorry for inconvenience, Sebastien Carrere From carrere at toulouse.inra.fr Thu Oct 13 03:17:34 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu Oct 13 03:22:03 2005 Subject: [MOBY-dev] Hardware upgrade: services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <434E0A0E.50006@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Friday (October 14th) 9.00 a.m. (GMT+1) till monday (October 17th) 11.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Next week, services interruptions should happen... Sorry for inconvenience, Sebastien Carrere From Pieter.Neerincx at wur.nl Thu Oct 13 11:46:39 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu Oct 13 11:46:03 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <000401c5ce20$6bcf7300$6900a8c0@notebook> References: <000401c5ce20$6bcf7300$6900a8c0@notebook> Message-ID: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Hi Eddie, On 11-Oct-2005, at 6:58 AM, Edward Kawas wrote: > Hi Pieter, > > I uploaded 2 new files. I am not sure if your bug is fixed, > but I thought that I would let you know. I have made new > additions and I modified some of the xml parsing, so while I > haven't worked on your bug, it may be fixed (or made worse > ;-). Well just tested the new versions and to be honest it kind of made it really bad :( I can not get any output anymore from any BioMOBY service. So I switched back to the previous versions of the *.jar files you had uploaded and apart from the missing articleName attribute things work again :). > > By the way, do you think that you could send me a workflow > whenever you notice something fishy? Sure. You mean the workflow saved as a scufl xml file I assume. Will do that in the future, but, in this case just try any BioMOBY service. Maybe some other files got updated as well in your development version apart from the 2 uploaded files... Cheers, Pieter > > Thanks, > > Eddie > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > >> -----Original Message----- >> From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter >> Neerincx >> Sent: Friday, October 07, 2005 10:25 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> Hi Eddie, >> >> Sorry, I cheered premature :(. For one of my services I >> use the >> articleName attribute of two String objects to know which >> one >> contains which data. Hence I have something like: >> >> >> > articleName="this.one"> >> Bla bla >> >> > articleName="the.other.one"> >> Alb alb >> >> >> >> The Object my service receives in Taverna lacks the >> articleName >> attributes for it's String childs :(. Hence it becomes >> this: >> >> >> >> Bla bla >> >> >> Alb alb >> >> >> >> Looks like the fix introduced a new bug as well... >> >> Pieter >> >> On 07Oct2005, at 11:30, Pieter Neerincx wrote: >> >> >>> Hi Eddie, >>> >>> On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: >>> >>> >>> >>>> Hi Pieter! >>>> >>>> I tracked down the bug and I fixed it (*fingers >>>> >> crossed*). >> >>>> >>>> I am placing 2 jar files at the following links that >>>> >> need to >> >>>> replace the ones in your /taverna-workbench-1.3/lib/ >>>> directory: >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- >>>> >> 1.3.jar >> >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar >>>> >>>> Be sure to backup the 2 files you are about to replace, >>>> >> just >> >>>> in case! >>>> >>>> Then try out your workflows and let me know what >>>> >> happens. >> >>>> >>>> >>> >>> I did some simple tests with the objects that failed >>> >> previously and >> >>> so far so good :) >>> >>> Thanks for the quick fix! >>> >>> >>> >>>> >>>> Also, if all is well, do you think that you could send >>>> >> me >> >>>> one of those workflows so I can use it as an example? >>>> >>>> >>> >>> After a lot of trail and error playing with a local >>> >> central I think >> >>> it's about time I register my services and objects at >>> >> the central >> >>> Central as well. Will do so once the central Central >>> >> databases are >> >>> migrated to the new API... >>> >>> Cheers, >>> >>> Pi >>> >>> >>> >>>> Thanks a lot, >>>> >>>> Eddie >>>> >>>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From edward.kawas at gmail.com Thu Oct 13 11:52:02 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Oct 13 11:51:18 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Message-ID: <000601c5d00e$0fca4180$6900a8c0@notebook> Sorry Pieter, I am still looking into it. Since the last time you tested, I fixed numerous logic errors. I think that ultimately you will notice that the article name issue will be fixed. I will let you know when a new test version is out. I thought I just had one, but a workflow that executes every branch of a service found an error. Thanks for your patience! Ed > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Thursday, October 13, 2005 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > On 11-Oct-2005, at 6:58 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I uploaded 2 new files. I am not sure if your bug is > fixed, > > but I thought that I would let you know. I have made new > > additions and I modified some of the xml parsing, so > while I > > haven't worked on your bug, it may be fixed (or made > worse > > ;-). > > Well just tested the new versions and to be honest it kind > of made it > really bad :( I can not get any output anymore from any > BioMOBY > service. So I switched back to the previous versions of > the *.jar > files you had uploaded and apart from the missing > articleName > attribute things work again :). > > > > > By the way, do you think that you could send me a > workflow > > whenever you notice something fishy? > > Sure. You mean the workflow saved as a scufl xml file I > assume. Will > do that in the future, but, in this case just try any > BioMOBY > service. Maybe some other files got updated as well in > your > development version apart from the 2 uploaded files... > > Cheers, > > Pieter > > > > > Thanks, > > > > Eddie > > > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > 1.3.jar > > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > > > > >> -----Original Message----- > >> From: moby-dev-bounces@portal.open-bio.org > [mailto:moby- > >> dev-bounces@portal.open-bio.org] On Behalf Of Pieter > >> Neerincx > >> Sent: Friday, October 07, 2005 10:25 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > >> missing in BioMOBYobjects > >> > >> Hi Eddie, > >> > >> Sorry, I cheered premature :(. For one of my services I > >> use the > >> articleName attribute of two String objects to know > which > >> one > >> contains which data. Hence I have something like: > >> > >> > >> >> articleName="this.one"> > >> Bla bla > >> > >> >> articleName="the.other.one"> > >> Alb alb > >> > >> > >> > >> The Object my service receives in Taverna lacks the > >> articleName > >> attributes for it's String childs :(. Hence it becomes > >> this: > >> > >> > >> > >> Bla bla > >> > >> > >> Alb alb > >> > >> > >> > >> Looks like the fix introduced a new bug as well... > >> > >> Pieter > >> > >> On 07Oct2005, at 11:30, Pieter Neerincx wrote: > >> > >> > >>> Hi Eddie, > >>> > >>> On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > >>> > >>> > >>> > >>>> Hi Pieter! > >>>> > >>>> I tracked down the bug and I fixed it (*fingers > >>>> > >> crossed*). > >> > >>>> > >>>> I am placing 2 jar files at the following links that > >>>> > >> need to > >> > >>>> replace the ones in your /taverna-workbench-1.3/lib/ > >>>> directory: > >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > >>>> > >> 1.3.jar > >> > >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > >>>> > >>>> Be sure to backup the 2 files you are about to > replace, > >>>> > >> just > >> > >>>> in case! > >>>> > >>>> Then try out your workflows and let me know what > >>>> > >> happens. > >> > >>>> > >>>> > >>> > >>> I did some simple tests with the objects that failed > >>> > >> previously and > >> > >>> so far so good :) > >>> > >>> Thanks for the quick fix! > >>> > >>> > >>> > >>>> > >>>> Also, if all is well, do you think that you could > send > >>>> > >> me > >> > >>>> one of those workflows so I can use it as an example? > >>>> > >>>> > >>> > >>> After a lot of trail and error playing with a local > >>> > >> central I think > >> > >>> it's about time I register my services and objects at > >>> > >> the central > >> > >>> Central as well. Will do so once the central Central > >>> > >> databases are > >> > >>> migrated to the new API... > >>> > >>> Cheers, > >>> > >>> Pi > >>> > >>> > >>> > >>>> Thanks a lot, > >>>> > >>>> Eddie > >>>> > >>>> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev@biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Thu Oct 13 19:43:14 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Oct 13 19:42:36 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Message-ID: <001201c5d04f$e2e15860$6900a8c0@notebook> Hi Pieter, I have uploaded the 2 jar files to http://bioinfo.icapture.ubc.ca/ekawas/jars/ There are 2 of them. Moreover, I have uploaded some workflows: http://bioinfo.icapture.ubc.ca/ekawas/workflows/ Test this version out. I believe that I fixed the article name bug. I have also fixed various other anomalies. Let me know how it goes. I am going to keep trying to create workflows that utilize complex Moby datatypes (GeneInfo comes to mind) to ensure that all is well. Thanks a lot, Eddie From aperezp at uma.es Fri Oct 14 06:03:56 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Fri Oct 14 06:25:40 2005 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: <20051014100352.0A065C0015@correo2.uma.es> Hi, do you know if is there any easy Perl function for obtaining the dataType and serviceType ontology in a tree way? Thanks in advance, Antonio. From edward.kawas at gmail.com Fri Oct 14 10:56:02 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Sat Oct 15 05:04:51 2005 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <20051014100352.0A065C0015@correo2.uma.es> Message-ID: <000001c5d0cf$66552170$6900a8c0@notebook> Take a look at the following project http://bioinformatics.org/project/?group_id=190 I believe that it produces a tree using wxPerl. Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Antonio J. > P?rez > Sent: Friday, October 14, 2005 3:04 AM > To: 'Core developer announcements' > Cc: Inb-tecnico@everest.cnb.uam.es > Subject: [MOBY-dev] Perl function for object tree > > Hi, do you know if is there any easy Perl function > for obtaining the > dataType and serviceType ontology in a tree way? > Thanks in advance, > > Antonio. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Sat Oct 15 12:29:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat Oct 15 12:27:58 2005 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <000001c5d0cf$66552170$6900a8c0@notebook> References: <000001c5d0cf$66552170$6900a8c0@notebook> Message-ID: <43512E55.3050505@illuminae.com> yeah.. but no guarantees that it works - I haven't looked at that code in almost two years! I abandoned wxPerl because it was desperately under-documented at the time (yes, I know... people in glass houses...) If anyone needs it, I could update my GO_Browser.pm widget (part of BioPerl) so that it presents the ISA part of the Moby object/service hierarchy. It uses Tk Perl, and would only take a couple of minutes to modify... it also allows programmable call-backs on mouse events that take place on the tree nodes (clicks, double-clicks, mouseovers, etc). If there is a need for this, please say so. M Edward Kawas wrote: >Take a look at the following project >http://bioinformatics.org/project/?group_id=190 I believe >that it produces a tree using wxPerl. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >>dev-bounces@portal.open-bio.org] On Behalf Of Antonio J. >>P?rez >>Sent: Friday, October 14, 2005 3:04 AM >>To: 'Core developer announcements' >>Cc: Inb-tecnico@everest.cnb.uam.es >>Subject: [MOBY-dev] Perl function for object tree >> >> Hi, do you know if is there any easy Perl function >>for obtaining the >>dataType and serviceType ontology in a tree way? >> Thanks in advance, >> >> Antonio. >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > From aperezp at uma.es Sat Oct 15 15:38:58 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Sat Oct 15 15:38:15 2005 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <43512E55.3050505@illuminae.com> Message-ID: <20051015193902.9A108C0008@correo2.uma.es> Hi Mark and Edward, and thank you to both, If it is not too work and bother, it would be very useful for showing the Biomoby ontology. We are now building CGIs showing object and service ontology and if there are modules which help in this subject, it is always good not repeat previously-done and as I can see good work. Regards and thanks again, Antonio. -----Mensaje original----- De: moby-dev-bounces@portal.open-bio.org [mailto:moby-dev-bounces@portal.open-bio.org] En nombre de Mark Wilkinson Enviado el: s?bado, 15 de octubre de 2005 18:29 Para: Core developer announcements Asunto: Re: [MOBY-dev] Perl function for object tree yeah.. but no guarantees that it works - I haven't looked at that code in almost two years! I abandoned wxPerl because it was desperately under-documented at the time (yes, I know... people in glass houses...) If anyone needs it, I could update my GO_Browser.pm widget (part of BioPerl) so that it presents the ISA part of the Moby object/service hierarchy. It uses Tk Perl, and would only take a couple of minutes to modify... it also allows programmable call-backs on mouse events that take place on the tree nodes (clicks, double-clicks, mouseovers, etc). If there is a need for this, please say so. M Edward Kawas wrote: >Take a look at the following project >http://bioinformatics.org/project/?group_id=190 I believe >that it produces a tree using wxPerl. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >>dev-bounces@portal.open-bio.org] On Behalf Of Antonio J. >>P?rez >>Sent: Friday, October 14, 2005 3:04 AM >>To: 'Core developer announcements' >>Cc: Inb-tecnico@everest.cnb.uam.es >>Subject: [MOBY-dev] Perl function for object tree >> >> Hi, do you know if is there any easy Perl function >>for obtaining the >>dataType and serviceType ontology in a tree way? >> Thanks in advance, >> >> Antonio. >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Mon Oct 17 12:25:36 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon Oct 17 13:00:09 2005 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <434A464D.7070203@cnb.uam.es> References: <434A464D.7070203@cnb.uam.es> Message-ID: <4353D080.50701@ucalgary.ca> I have only a couple of suggestions, but I think they may be important: 1. I have a problem with callling all of this Error Handling and having the tag called mobyException, when this mechanism includes not only errors, but also non-fatal warnings and simple information blocks. Perhaps we should call it Execution Status Reporting or something like that? 2. Under "Service Intrinsic Errors", the footnote for 701 states that Blast reporting "No hits found" is a SERVICE_INTERNAL_ERROR. Why is getting no hits an error? Isn't it just a blank response? If I'm designing a sequencing oligo and am checking my oligo against my cloning vector sequence, I want no hits! A MOBY-aware program may see it as an error instead of a response to report... 3. Could we add a few codes to the 700 series "700 OK" (pretty obvious: everything was okay, but we want to provide a formatted info block in the response) "703 Data no longer valid" (once upon a time the data was valid, but no longer: a sequence identifier that has been retracted, a job ticket that is stale, etc.) "704 input invalid" (somehow you escaped the 200 series errors because it is MOBY-correct input, but biologically the input doesn't make sense e.g. an EC number is an object with a String, and that's what you gave us, but the string is HelloWorld, which is not of the form #.#.#.#) "705 data transformed" (e.g. warning: non-DNA chars ignored in DNA search) My CAN$0.02, Paul > The latest version is in the bugzilla > > http://bugzilla.open-bio.org/attachment.cgi?id=233 > > David > > Martin Senger escribi?: > >>> We should also call for a new vote, and perhaps this time simply use >>> the mailing list since the last call for votes only got one response... >>> >>> Let's say October 24th as the final word on this? >>> >>> >> >> Where can I can the latest, official, document describing the latest >> consensus? >> >> Martin >> >> >> >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From carrere at toulouse.inra.fr Tue Oct 18 02:47:24 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue Oct 18 02:46:35 2005 Subject: [MOBY-dev] Hardware upgrade: last programmed interruption - services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <43549A7C.102@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Today evening 8.00 p.m. (GMT+1) till Thursday (October 20th) 9.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Hope this should be the last interruption ... Sorry for inconvenience, Sebastien Carrere _______________________________________________ From senger at ebi.ac.uk Tue Oct 18 13:12:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Oct 18 13:23:59 2005 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <4353D080.50701@ucalgary.ca> Message-ID: > 1. I have a problem with callling all of this Error Handling and having > the tag called mobyException, when this mechanism includes not only > errors, but also non-fatal warnings and simple information blocks. > I think this was caused by me: I have asked the authors to have there also simple information blocks. I see now that having two places for the same informations (a mobyException tag with a simple information, and the Notes tag) may be confusing. So I am fine with not having the type 'information' there). On the other hand, I think that having warnings in the mobyException is correct (I consider a warning as an exceptional condition). > 2. Under "Service Intrinsic Errors", the footnote for 701 states that > Blast reporting "No hits found" is a SERVICE_INTERNAL_ERROR. Why is > getting no hits an error? > I think that this is an example. Simply it refers to a service that *consider* this situation as exceptionla and errorneus. Your service may feel differently. But if you think that such example is confusing, it is simple to remove it (or to replace is by an another one). > "700 OK" (pretty obvious: everything was okay, but we want to > provide a formatted info block in the response) > But you can always use Notes to fo that withoutr having any exceptionMoby block at all. I am not sure what you want to achiev by this 700 code I must admit. > "703 Data no longer valid" (once upon a time the data was valid, but > no longer: a sequence identifier that has been retracted, a job ticket > that is stale, etc.) > "704 input invalid" (somehow you escaped the 200 series errors > because it is MOBY-correct input, but biologically the input doesn't > make sense e.g. an EC number is an object with a String, and that's what > you gave us, but the string is HelloWorld, which is not of the form #.#.#.#) > "705 data transformed" (e.g. warning: non-DNA chars ignored in DNA > search) > We surely can make more service-specific codes. But I feel that having them is not anyway rich enough - the service providers may specify more details (e.g. yout 704 woulod by better to say why it is invalid; and if not then the code 201 should be used). So I would keep the pre-defined 700 codes at minimum (anyway, what a client can do with them? it simply reports it - there is probably no general way how to send the same request again with the error corrected). I would even remove 701 and rename 702. See below. My additional comments to the latest draft are: * Make sure that upper/lower cases are consistent in attribute names. I notices that refqueryId is spelled both ways as: refQueryId and refqueryId. * I think that we do not need Error code 701. The general failure is reported by 600, and nayhinf more specific can have a concrete service specific code (documented in the service description). * Code 702 is either too generic (so some of 200 codes should be used instead ) or a service provider should be more specific and agin design its specific code and document it. But The example for this code is quite useful - even so useful that I would suggest to add a code for "not-matching namespace" condition (either as a 70x code, or perhaps as a 227 "INPUT_INCORRECT_NAMESPACE". Regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: 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 Tue Oct 18 16:49:13 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Oct 18 17:20:19 2005 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th Message-ID: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Hi all, Eddie and I have been discussing the object ontology migration now that we are not allowing inheritance from primitives. No matter what we do this will break some services, and though I was originally hoping to soften the blow by having a deprecation period, the amount of pain this causes (i.e. everyone having to edit and re-register their services TWICE!) is just inhumane :-) So... I am sure that some of you will cheer this decision, and others will loathe it... we're going to simply migrate the object ontology (in the public MOBY Central here at iCAPTURE) with **no deprecation period at all**. The object names will remain exactly as they are, but will (in some cases) now have different definitions. As such, for those of you running services that are affected by this change, you will only need to update your service code, but NOT need to de/re-register your service. We plan to do this Monday October 24th, so you have a few days to update your services now to reduce the down-time. The way to go about updating your services is as follows: Any XML node that currently has content, but is not a nominal primitive, will now be modified such that it CONTAINS a node that is a primitive, and that primitive will have data content. It's articleName is "content" in every case. e.g. name ACGTGTAGTGCTAGTC ]]> will become name ACGTGTGCTGATGAC ]]> And similarly for Integers, Floats, DateTime, etc. The definition of DateTime will also change, such that it is a primitive, rather than inheriting from String, as it currently does. Eddie has a migration script that will update your mySQL databases automatically. He will make this available on his website (details to follow). Any objections? (don't all yell at once ;-) ) Cheers! Mark -- "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 Pieter.Neerincx at wur.nl Tue Oct 18 17:53:16 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Oct 18 17:52:34 2005 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> References: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: <68AE2417-6156-451C-BC4F-27E409EEFDD3@wur.nl> On 18Oct2005, at 22:49, Mark Wilkinson wrote: > Hi all, > > Eddie and I have been discussing the object ontology migration now > that > we are not allowing inheritance from primitives. No matter what we do > this will break some services, and though I was originally hoping to > soften the blow by having a deprecation period, the amount of pain > this > causes (i.e. everyone having to edit and re-register their services > TWICE!) is just inhumane :-) > > So... I am sure that some of you will cheer this decision, Well usually we have drinks on friday afternoon after work, but it looks we'll have to start next week with a small party :). Changing my services was easy, but starting up my brain on tuesday might be a tough one... > and others > will loathe it... we're going to simply migrate the object ontology > (in > the public MOBY Central here at iCAPTURE) with **no deprecation period > at all**. > > .... > > Any objections? (don't all yell at once ;-) ) NO! > Cheers! > > Mark > Cheers, Pieter > > > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From senger at ebi.ac.uk Tue Oct 18 18:02:28 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Oct 18 18:19:38 2005 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: > So... I am sure that some of you will cheer this decision > I am the one who cheers this decision :-) ...but I do not understand what to change/do... :-( For example, there is a chain: text-formatted inherits from text-plain inherits from String Which object definition are you going to change? I guess the 'text-plain', correct? So now text-plain will contain a String under an article-name 'contents'. And the rest of the hierarchy tree will not be changed. Correct? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: 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 Tue Oct 18 18:32:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Oct 18 18:31:57 2005 Subject: [personal] Re: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: References: Message-ID: <1129674764.7012.4.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-10-18 at 23:02 +0100, Martin Senger wrote: > > So... I am sure that some of you will cheer this decision > > > I am the one who cheers this decision :-) I knew you would :-) > For example, there is a chain: > text-formatted inherits from text-plain inherits from String > Which object definition are you going to change? I guess the > 'text-plain', correct? So now text-plain will contain a String under an > article-name 'contents'. And the rest of the hierarchy tree will > not be changed. Correct? Correct. We are only modifying the first level of objects that formerly inherited from primitives. Any deeper children's definitions will be "updated" by virtue of inheritance, but not by any modification we make to the ontology (similarly for hasa and has relationships). 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 Oct 18 18:32:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Oct 18 18:42:02 2005 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: Eddie wrote a new article/guide about biomoby in Taverna. You can read it in usual place http://biomoby.org/moby-live/java/docs. The link is named "How to use BioMoby plugin in Taverna". Thanks, Eddie! Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Wed Oct 19 04:50:06 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed Oct 19 04:49:17 2005 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: References: Message-ID: On 19-Oct-2005, at 12:32 AM, Martin Senger wrote: > Eddie wrote a new article/guide about biomoby in Taverna. You can > read it > in usual place http://biomoby.org/moby-live/java/docs. Ooops, that link fails. Looks like it's running on a *n*x machine where Capitals make a difference. Try http://biomoby.org/moby-live/Java/docs instead :). > The link is named > "How to use BioMoby plugin in Taverna". Thanks, Eddie! One small comment. The info in that document on how to add a scavanger for a BioMOBY Central is outdated. Furthermore if you want to use a custom / local BioMOBY Central you'll have to install some additional servlets that Eddie created. I wrote a doc on how to get a local Taverna-1.3-compatible BioMOBY Central up and running. It's in ~moby-live/Docs/Central/ , but as far as I know this hasn't made it onto the old nor onto the new website yet... moby-live at biomoby.org is all about moby, but it isn't that live :) Cheers, Pieter > > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From senger at ebi.ac.uk Wed Oct 19 05:04:17 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Oct 19 05:03:19 2005 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: Message-ID: > Ooops, that link fails. Looks like it's running on a *n*x machine > where Capitals make a difference. Try > http://biomoby.org/moby-live/Java/docs > instead :). > My typo; thanks for correcting my email. > One small comment. The info in that document on how to add a > scavanger for a BioMOBY Central is outdated. Furthermore if you want > to use a custom / local BioMOBY Central you'll have to install some > additional servlets that Eddie created. > Well, this is not a small comment. I hoped that this docs covered everything needed. I must admit that Tom (Oinn) had warned me (the last time as I have spoken with him) that the moby-taverna docs is not fully "in the shape" - but I thought that this nice Eddie's guide solved it. Perhaps, Eddie will update his guide by the missing pieces. I think that important is that we have now a place (a page) that is visible for the jMoby developers (and users) and that can be easily updated. > I wrote a doc on how to get a local Taverna-1.3-compatible BioMOBY > Central up and running. It's in ~moby-live/Docs/Central/ , but as far > as I know this hasn't made it onto the old nor onto the new website > yet... moby-live at biomoby.org is all about moby, but it isn't that > live :) > The jMoby pages are quite active/live (even though not too many authors there - just four of us: Paul, Eddie, Ben and me). If you have a jMoby (Java) related piece of documentation you may consider to add it to moby-live/Java/docs, and to link it from index.html there. It would be great to have more contributors. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: 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 Wed Oct 19 08:52:42 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed Oct 19 09:19:15 2005 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: Message-ID: <000001c5d4ac$0038e800$6500a8c0@notebook> > > One small comment. The info in that document on how to > add a > > scavanger for a BioMOBY Central is outdated. Furthermore > if you want > > to use a custom / local BioMOBY Central you'll have to > install some > > additional servlets that Eddie created. I don't think that this belongs in the how to use Taverna documentation. I guess that it should be mentioned in passing. Eddie > Well, this is not a small comment. I hoped that this > docs covered > everything needed. I must admit that Tom (Oinn) had warned > me (the last > time as I have spoken with him) that the moby-taverna docs > is not fully > "in the shape" - but I thought that this nice Eddie's > guide solved it. > Perhaps, Eddie will update his guide by the missing pieces. > I think that > important is that we have now a place (a page) that is > visible for the > jMoby developers (and users) and that can be easily > updated. > > > > I wrote a doc on how to get a local Taverna-1.3- > compatible BioMOBY > > Central up and running. It's in ~moby- > live/Docs/Central/ , but as far > > as I know this hasn't made it onto the old nor onto the > new website > > yet... moby-live at biomoby.org is all about moby, but > it isn't that > > live :) > > > The jMoby pages are quite active/live (even though not > too many authors > there - just four of us: Paul, Eddie, Ben and me). If you > have a jMoby > (Java) related piece of documentation you may consider to > add it to > moby-live/Java/docs, and to link it from index.html there. > It would be > great to have more contributors. > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Wed Oct 19 19:39:06 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed Oct 19 19:38:10 2005 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAYOCT 24th In-Reply-To: Message-ID: <001401c5d506$4dccbab0$6500a8c0@notebook> Hi, I have a script that is downloadable from the following address: http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz It goes through your local central and updates the ontology according to the API. Uncompress the contents and take a look at the readme file as it outlines what it does and what it needs from you. If you have any questions, let me know, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Martin > Senger > Sent: Tuesday, October 18, 2005 3:02 PM > To: markw@illuminae.com; Core developer announcements > Subject: Re: [MOBY-dev] Migrating MOBY Central to the new > object API - MONDAYOCT 24th > > > So... I am sure that some of you will cheer this > decision > > > I am the one who cheers this decision :-) > ...but I do not understand what to change/do... :-( > > For example, there is a chain: > text-formatted inherits from text-plain inherits from > String > > Which object definition are you going to change? I > guess the > 'text-plain', correct? So now text-plain will contain a > String under an > article-name 'contents'. And the rest of the hierarchy > tree will > not be changed. Correct? > > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Oct 21 05:28:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Oct 21 05:27:55 2005 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <001201c5d04f$e2e15860$6900a8c0@notebook> References: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: Hi Eddie, On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > Hi Pieter, > > I have uploaded the 2 jar files to > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > There are 2 of them. > > Moreover, I have uploaded some workflows: > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > Test this version out. I believe that I fixed the article > name bug. I have also fixed various other anomalies. > > Let me know how it goes. You're the man! I have been testing for a few days now and so far I haven't been able to spot any anomalies :). Thanks! Pieter > I am going to keep trying to create > workflows that utilize complex Moby datatypes (GeneInfo > comes to mind) to ensure that all is well. > > Thanks a lot, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From aperezp at uma.es Fri Oct 21 07:32:45 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Fri Oct 21 07:32:00 2005 Subject: [MOBY-dev] Parsing Big XML Objects In-Reply-To: Message-ID: <20051021113249.67C0CC0008@correo2.uma.es> Hi, I have parsing moby objects with the getMobySimples function from MobyXmlObject.pm, but when the object is big (>1-2 Mb) the parsing is desperately slow. Do you know if there is a faster way to do this? Thanks in advance, Antonio. From duncan.hull at cs.man.ac.uk Fri Oct 21 07:17:59 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri Oct 21 07:46:08 2005 Subject: [MOBY-dev] new article in jMoby docs: wish list In-Reply-To: References: Message-ID: <4358CE67.9020307@cs.man.ac.uk> Hello Martin Senger wrote: >If you have a jMoby >(Java) related piece of documentation you may consider to add it to >moby-live/Java/docs, and to link it from index.html there. It would be >great to have more contributors. > > > Talking of jMoby documentation, it would be useful* to have some documentation on the graphs client(s): http://biomoby.org/moby-live/Java/docs/CmdLineClients.html#MobyGraphs http://www.ebi.ac.uk/collab/mygrid/service2/jmoby/graphs *maybe only useful for for me though :) Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From rebecca.ernst at gsf.de Fri Oct 21 08:17:41 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri Oct 21 08:41:46 2005 Subject: [MOBY-dev] Migration to new API Message-ID: <4358DC65.3070103@gsf.de> Hi Mark and others! just wanted to let you know that all MIPS services are migrated already. Unfortunately it took us much longer than 5 Minutes because many of our services used objects which inherited indirectly from string (second and more level in the hierarchy) therefore we had to change a lot of services (the part taking most of the time was to find out which services had to be changed!) And we are certainly happy that we don't have to re-register all of them again (*cheering*) !!! 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 carrere at toulouse.inra.fr Fri Oct 21 10:15:08 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Fri Oct 21 10:14:25 2005 Subject: [MOBY-dev] Parsing Big XML Objects In-Reply-To: <20051021113249.67C0CC0008@correo2.uma.es> References: <20051021113249.67C0CC0008@correo2.uma.es> Message-ID: <4358F7EC.6040005@toulouse.inra.fr> Hi, I added the Perl Module (i) we develloped in Toulouse and the mandatory XSLT style-sheet (ii) in the CVS repository to avoid the problem of huge XML messages. i. moby-live/Perl/MOBY/MOBYXSLT.pm ii. moby-live/Perl/MOBY/xsl/parseMobyMessage.xsl This module uses xsltproc to parse XML and builds Perl structures. If you want more information (services examples using this module), do not hesitate. Sebastien Antonio J. P?rez wrote: > Hi, I have parsing moby objects with the getMobySimples function >from MobyXmlObject.pm, but when the object is big (>1-2 Mb) the parsing is >desperately slow. Do you know if there is a faster way to do this? > Thanks in advance, > > Antonio. > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Fri Oct 21 11:53:24 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Oct 21 11:52:24 2005 Subject: [moby] Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: References: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: <1129910004.14938.29.camel@bioinfo.icapture.ubc.ca> This is great news - I think we should pass this on to Tom and request a sub-version-release of Taverna now that this is fixed. M On Fri, 2005-10-21 at 11:28 +0200, Pieter Neerincx wrote: > Hi Eddie, > > On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I have uploaded the 2 jar files to > > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > > > There are 2 of them. > > > > Moreover, I have uploaded some workflows: > > > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > > > Test this version out. I believe that I fixed the article > > name bug. I have also fixed various other anomalies. > > > > Let me know how it goes. > > You're the man! I have been testing for a few days now and so far I > haven't been able to spot any anomalies :). > > Thanks! > > Pieter > > > I am going to keep trying to create > > workflows that utilize complex Moby datatypes (GeneInfo > > comes to mind) to ensure that all is well. > > > > Thanks a lot, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "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 edward.kawas at gmail.com Fri Oct 21 11:55:23 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri Oct 21 11:54:24 2005 Subject: [moby] Re: [MOBY-dev] Taverna plugin bug?: elements missing inBioMOBYobjects In-Reply-To: <1129910004.14938.29.camel@bioinfo.icapture.ubc.ca> Message-ID: <002b01c5d657$d9d6a9b0$6500a8c0@notebook> Last time Pieter said that, within hours he replied that he spoke too soon. Let's wait a little longer ;-) Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Friday, October 21, 2005 8:53 AM > To: Core developer announcements > Subject: Re: [moby] Re: [MOBY-dev] Taverna plugin bug?: > elements missing inBioMOBYobjects > > This is great news - I think we should pass this on to Tom > and request a > sub-version-release of Taverna now that this is fixed. > > M > > > > On Fri, 2005-10-21 at 11:28 +0200, Pieter Neerincx wrote: > > Hi Eddie, > > > > On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > > > > > Hi Pieter, > > > > > > I have uploaded the 2 jar files to > > > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > > > > > There are 2 of them. > > > > > > Moreover, I have uploaded some workflows: > > > > > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > > > > > Test this version out. I believe that I fixed the > article > > > name bug. I have also fixed various other anomalies. > > > > > > Let me know how it goes. > > > > You're the man! I have been testing for a few days now > and so far I > > haven't been able to spot any anomalies :). > > > > Thanks! > > > > Pieter > > > > > I am going to keep trying to create > > > workflows that utilize complex Moby datatypes > (GeneInfo > > > comes to mind) to ensure that all is well. > > > > > > Thanks a lot, > > > > > > Eddie > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev@biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx@wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Sun Oct 23 14:11:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun Oct 23 14:10:36 2005 Subject: [MOBY-dev] new article in jMoby docs: wish list In-Reply-To: <4358CE67.9020307@cs.man.ac.uk> Message-ID: > Talking of jMoby documentation, it would be useful* to have some > documentation on the graphs client(s): > > http://biomoby.org/moby-live/Java/docs/CmdLineClients.html#MobyGraphs > http://www.ebi.ac.uk/collab/mygrid/service2/jmoby/graphs > Good point. I have, still in my TODO list, a bug reported by Ben about this graphs client. I will look at it when I finish my current "project" (a Biomoby dashboard client for service providers). And it that time I will fix also the docs. Promise. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From ed.kawas at gmail.com Tue Oct 25 17:23:35 2005 From: ed.kawas at gmail.com (Eddie Kawas) Date: Tue Oct 25 17:28:39 2005 Subject: [MOBY-dev] Mobycentral has been updated Message-ID: <001e01c5d9aa$5d062a40$6600a8c0@notebook> Hi, Mobycentral has had its object ontology updated, i.e. there no longer exists data types that inherit from primitives. Moreover, if you are interested in updating your ontology, download the migration 'script' from http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz and follow the directions inside the archive. Thanks, Eddie From edward.kawas at gmail.com Tue Oct 25 17:24:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue Oct 25 17:51:58 2005 Subject: [MOBY-dev] Mobycentral has been updated Message-ID: <001f01c5d9aa$7109c2e0$6600a8c0@notebook> Hi, Mobycentral has had its object ontology updated, i.e. there no longer exists data types that inherit from primitives. Moreover, if you are interested in updating your ontology, download the migration 'script' from http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz and follow the directions inside the archive. Thanks, Eddie From senger at ebi.ac.uk Wed Oct 26 20:38:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Oct 26 20:56:50 2005 Subject: [MOBY-dev] bad LSIDs produced by biomoby registry Message-ID: Eddie & Mark, Could you please fix the LSID creation: the entity name must be 'escaped' if it has characters that are not allowed in the LSID parts, especially colons. An example is a namespace named GOA:hamap that gets LSID: urn:lsid:biomoby.org:namespacetype:GOA:hamap which is, IMHO, wrong. It should be something like: urn:lsid:biomoby.org:namespacetype:GOA_hamap (but obviousy you need to do it in a way that allows you to map back the escaped lsid to the original entity). Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: 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 Wed Oct 26 18:18:57 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed Oct 26 21:10:05 2005 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting Message-ID: <002801c5da7b$42e36ac0$6600a8c0@notebook> Hi, I am calling a vote on the RFC that discusses error reporting. Please refer to the following link: http://bugzilla.open-bio.org/show_bug.cgi?id=1863 Thanks. From senger at ebi.ac.uk Wed Oct 26 21:26:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Oct 26 21:25:00 2005 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > I believe that the casual consensus was that we will carry on votes by email and not in the bugzilla obscure pages. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Thu Oct 27 09:56:28 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu Oct 27 10:05:54 2005 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> I vote in favour of RFC 1863 (I've added my vote in bugzilla too). Martin, I agree that bugzilla is currently fairly obscure, mostly because nobody has had a reason to go there until recently. However, I think if you hang out there a little, you'll find it's not so inhospitable. It has the advantage of making it much easier to track the history of our decisions. It is also quite a bit easier to associate documents with those decisions, especially as they are revised over time. -Frank At 09:26 PM 10/26/2005, you wrote: > > I am calling a vote on the RFC that discusses error > > reporting. > > > > Please refer to the following link: > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > > I believe that the casual consensus was that we will carry on votes by >email and not in the bugzilla obscure pages. > > Martin > >-- >Martin Senger > email: martin.senger@gmail.com > skype: martinsenger >consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 gordonp at ucalgary.ca Thu Oct 27 10:32:29 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu Oct 27 10:59:53 2005 Subject: [MOBY-dev] bad LSIDs produced by biomoby registry In-Reply-To: References: Message-ID: <4360E4FD.6090202@ucalgary.ca> As this is a URN, you must use the percent sign hex character encoding for such cases e.g. urn:lsid:biomoby.org:namespacetype:GOA%3Ahamap The implication of course is that a URN resolver should always decode such strings properly. >Eddie & Mark, > Could you please fix the LSID creation: the entity name must be >'escaped' if it has characters that are not allowed in the LSID parts, >especially colons. An example is a namespace named GOA:hamap that gets >LSID: > urn:lsid:biomoby.org:namespacetype:GOA:hamap >which is, IMHO, wrong. It should be something like: > urn:lsid:biomoby.org:namespacetype:GOA_hamap >(but obviousy you need to do it in a way that allows you to map >back the escaped lsid to the original entity). > > Cheers, > Martin > > > From gordonp at ucalgary.ca Thu Oct 27 10:32:29 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu Oct 27 10:59:56 2005 Subject: [MOBY-dev] bad LSIDs produced by biomoby registry In-Reply-To: References: Message-ID: <4360E4FD.6090202@ucalgary.ca> As this is a URN, you must use the percent sign hex character encoding for such cases e.g. urn:lsid:biomoby.org:namespacetype:GOA%3Ahamap The implication of course is that a URN resolver should always decode such strings properly. >Eddie & Mark, > Could you please fix the LSID creation: the entity name must be >'escaped' if it has characters that are not allowed in the LSID parts, >especially colons. An example is a namespace named GOA:hamap that gets >LSID: > urn:lsid:biomoby.org:namespacetype:GOA:hamap >which is, IMHO, wrong. It should be something like: > urn:lsid:biomoby.org:namespacetype:GOA_hamap >(but obviousy you need to do it in a way that allows you to map >back the escaped lsid to the original entity). > > Cheers, > Martin > > > From markw at illuminae.com Mon Oct 3 13:16:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Oct 2005 10:16:09 -0700 Subject: [MOBY-dev] TWiki taken offline Message-ID: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> Hi all, I've decided to take the TWiki down after several recent serious security alerts that would require installation of a newer version (and installation of TWiki is not something I can do with my left hand, unfortunately... it's a bit ugly!) Since we're moving to the new website anyway, I don't see the point in the investment of time on the old one. I will continue to move documents over to the new site as I get the chance. Others are welcome to help :-) If there is anything on the TWiki that you need urgently, let me know and I'll make the document available some other way. 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 Pieter.Neerincx at wur.nl Tue Oct 4 08:43:47 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 14:43:47 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects Message-ID: <060DD7A8-411D-4F92-A5F3-A8EC7E33D536@wur.nl> Hi Eddie et al. Now that I have my local BioMOBY Central up and running I'd love to run some worksflows, but I think I ran into a bug. When I select BioMOBY objects and add them to a workflow all necessary processors for the child elements/objects are added as well. So far so good. But when I run a workflow, some of the child elements for the objects are missing from the object that is send to a service. Here's an example: If I have a nested structure like this: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Root_Moby_Object moby:My_Child_Level_1A moby:My_Child_Level_1B moby:My_Child_Level_2A moby:My_Child_Level_2B moby:My_Child_Level_1C moby:My_Child_Level_1D moby:My_Child_Level_2A moby:My_Child_Level_3A moby:My_Child_Level_1E * The MyRootMobyObject can have many ChildLevel1 elements. That's fine. * However if the ChildLevel1 elements have childs, they might be missing from the object that is send to a service. Some will be there, others will be missing. I tried to find a pattern, but I couldn't. So whether there is 1 or more elements added at level 2, whether they have an articleName or not, whether they have a namespace or not, etc. doesn't seem to make a difference. I also tried the official BioMOBY central: same result. I also tried the freshly released Taverna 1.3 today: same result again. So when I look in Taverna at the intermediate inputs and outputs for the different processors I see the following structures: The input for the service = the intermediate output of the processor that created MyRootMobyObject contains: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Root_Moby_Object moby:My_Child_Level_1A moby:My_Child_Level_1B moby:My_Child_Level_1C moby:My_Child_Level_1D moby:My_Child_Level_1E The intermediate input for the processor that created MyRootMobyObject = the intermediate output of the processor that created MyChildLevel1B contains: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Child_Level_1B moby:My_Child_Level_2A moby:My_Child_Level_2B So that one looks fine, but when My_Child_Level_1B is appended to My_Root_Moby_Object, the children of My_Child_Level_1B are lost :(. I do not get any errors or scary log lines apart from my service complaining that some elements are missing from the input. Any idea what is messing up the fun? Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jpsanchez at isciii.es Tue Oct 4 09:00:59 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 15:00:59 +0200 Subject: Autoreply: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 09:44:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 06:44:55 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: <060DD7A8-411D-4F92-A5F3-A8EC7E33D536@wur.nl> Message-ID: <000c01c5c8e9$cffac320$6500a8c0@notebook> > moby:MOBY > moby:Content > moby:Data > moby:Simple > moby:My_Child_Level_1B > moby:My_Child_Level_2A > moby:My_Child_Level_2B > Do you have an example of an object that has this type of structure? Thanks, Eddie From jpsanchez at isciii.es Tue Oct 4 10:49:22 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 16:49:22 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 11:06:37 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 17:06:37 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: <000c01c5c8e9$cffac320$6500a8c0@notebook> References: <000c01c5c8e9$cffac320$6500a8c0@notebook> Message-ID: On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >> moby:MOBY >> moby:Content >> moby:Data >> moby:Simple >> moby:My_Child_Level_1B >> moby:My_Child_Level_2A >> moby:My_Child_Level_2B >> >> > > Do you have an example of an object that has this type of > structure? Yes, try for example DnaSequenceHolder from the BioMOBY Central. I have been running some other tests in the mean time and so far almost every object I tried lacks child elements at level 2 or further down. The only one that does have an element at level 2 is the BlastJob object I have in my local Central. This one has Strings, Objects and a DataTime at level 2 or further down. Everything is missing except the DataTime primitive... I noticed that hardly anyone is using the DataTime primitive if I'm not the only one using. It is also hardly documented. Maybe it's just random noise in my testing or maybe I'm onto something.... If you want to try the BlastJob object my local registry should still be accessible from outside at: http://137.224.52.237/phenolink/biomoby/central/cgi-bin/MOBY-Central.pl Hope this helps, Pi > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jpsanchez at isciii.es Tue Oct 4 11:13:02 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 17:13:02 +0200 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 11:12:29 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 08:12:29 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: Message-ID: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> No you are on to something! When I first created the plugin, I used a certain xml parser based on w3c dom. I had to switch to another parser and it seems that I was unaware of its limitations (getChildren only gets the direct children of an element). I will have this fixed fairly soon. 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 Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:07 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > > >> moby:MOBY > >> moby:Content > >> moby:Data > >> moby:Simple > >> moby:My_Child_Level_1B > >> moby:My_Child_Level_2A > >> moby:My_Child_Level_2B > >> > >> > > > > Do you have an example of an object that has this type > of > > structure? > > Yes, try for example DnaSequenceHolder from the BioMOBY > Central. > > I have been running some other tests in the mean time and > so far > almost every object I tried lacks child elements at level > 2 or > further down. The only one that does have an element at > level 2 is > the BlastJob object I have in my local Central. This one > has Strings, > Objects and a DataTime at level 2 or further down. > Everything is > missing except the DataTime primitive... I noticed that > hardly anyone > is using the DataTime primitive if I'm not the only one > using. It is > also hardly documented. Maybe it's just random noise in my > testing or > maybe I'm onto something.... > > If you want to try the BlastJob object my local registry > should still > be accessible from outside at: > http://137.224.52.237/phenolink/biomoby/central/cgi- > bin/MOBY-Central.pl > > Hope this helps, > > Pi > > > Thanks, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From simont at mcw.edu Tue Oct 4 11:17:20 2005 From: simont at mcw.edu (Twigger Simon) Date: Tue, 4 Oct 2005 10:17:20 -0500 Subject: [MOBY-dev] TWiki taken offline In-Reply-To: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> References: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, There do appear to be some Wiki plugins for wordpress so in theory we could implement something similar over there. I could install it and we could play with it for a while... S. On Oct 3, 2005, at 12:16 PM, Mark Wilkinson wrote: > Hi all, > > I've decided to take the TWiki down after several recent serious > security alerts that would require installation of a newer version > (and > installation of TWiki is not something I can do with my left hand, > unfortunately... it's a bit ugly!) Since we're moving to the new > website anyway, I don't see the point in the investment of time on the > old one. > > I will continue to move documents over to the new site as I get the > chance. Others are welcome to help :-) > > If there is anything on the TWiki that you need urgently, let me know > and I'll make the document available some other way. > > 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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From jpsanchez at isciii.es Tue Oct 4 11:51:22 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 17:51:22 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 11:46:59 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 17:46:59 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: References: <000c01c5c8e9$cffac320$6500a8c0@notebook> Message-ID: <0C17CCE2-4EC0-42BE-926A-89B14004BAF3@wur.nl> Hi Eddie, I found another interesting example. In this case I didn't loose any child elements, but they got appended to the wrong parent element ??? TropGENE_ACESSION TropGENE_LOCUS TropGENE_ALLELE TropGENE_LINKAGE_GROUP TropGENE_MAP_POSITION If I use the object above I get as input for a service: TropGENE_ACESSION TropGENE_LOCUS TropGENE_ALLELE TropGENE_MAP_POSITION TropGENE_LINKAGE_GROUP Hence, the TropGENE_MAP_POSITION is appended to the wrong child. The intermediate output of the processor that creates TropGENE_LINKAGE_GROUP seems to be fine, but when TropGENE_LINKAGE_GROUP is appended to TropGENE_LOCUS, the TropGENE_MAP_POSITION element jumps from the TropGENE_LINKAGE_GROUP to the TropGENE_ALLELE element... Regards, Pieter From jpsanchez at isciii.es Tue Oct 4 11:58:03 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 17:58:03 +0200 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 12:03:59 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 18:03:59 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> References: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> Message-ID: <71484B4E-298B-4423-BF74-D968B86E644B@wur.nl> On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: > No you are on to something! When I first created the plugin, > I used a certain xml parser based on w3c dom. I had to > switch to another parser and it seems that I was unaware of > its limitations (getChildren only gets the direct children > of an element). > > I will have this fixed fairly soon. I'm looking forward to "testdrive" it :) Thanks, Pieter > > 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 Pieter >> Neerincx >> Sent: Tuesday, October 04, 2005 8:07 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> >> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >> >> >>>> moby:MOBY >>>> moby:Content >>>> moby:Data >>>> moby:Simple >>>> moby:My_Child_Level_1B >>>> moby:My_Child_Level_2A >>>> moby:My_Child_Level_2B >>>> >>>> >>>> >>> >>> Do you have an example of an object that has this type >>> >> of >> >>> structure? >>> >> >> Yes, try for example DnaSequenceHolder from the BioMOBY >> Central. >> >> I have been running some other tests in the mean time and >> so far >> almost every object I tried lacks child elements at level >> 2 or >> further down. The only one that does have an element at >> level 2 is >> the BlastJob object I have in my local Central. This one >> has Strings, >> Objects and a DataTime at level 2 or further down. >> Everything is >> missing except the DataTime primitive... I noticed that >> hardly anyone >> is using the DataTime primitive if I'm not the only one >> using. It is >> also hardly documented. Maybe it's just random noise in my >> testing or >> maybe I'm onto something.... >> >> If you want to try the BlastJob object my local registry >> should still >> be accessible from outside at: >> http://137.224.52.237/phenolink/biomoby/central/cgi- >> bin/MOBY-Central.pl >> >> Hope this helps, >> >> Pi >> >> >>> Thanks, >>> >>> Eddie >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jpsanchez at isciii.es Tue Oct 4 12:04:48 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 18:04:48 +0200 Subject: Autoreply: Re: [MOBY-dev] TWiki taken offline Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From jpsanchez at isciii.es Tue Oct 4 12:13:00 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 18:13:00 +0200 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 13:00:50 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 10:00:50 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <0C17CCE2-4EC0-42BE-926A-89B14004BAF3@wur.nl> Message-ID: <000e01c5c905$2eb83210$6500a8c0@notebook> Hi Pieter, I was wondering if you had a workflow that you use to build the object and run it with a Moby service. If you have one, do you think that you could email it to me? 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 Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > I found another interesting example. In this case I didn't > loose any > child elements, but they got appended to the wrong parent > element ??? > > TropGENE_ACESSION > TropGENE_LOCUS > TropGENE_ALLELE > TropGENE_LINKAGE_GROUP > TropGENE_MAP_POSITION > > If I use the object above I get as input for a service: > > TropGENE_ACESSION > TropGENE_LOCUS > TropGENE_ALLELE > TropGENE_MAP_POSITION > TropGENE_LINKAGE_GROUP > > Hence, the TropGENE_MAP_POSITION is appended to the wrong > child. The > intermediate output of the processor that creates > TropGENE_LINKAGE_GROUP seems to be fine, but when > TropGENE_LINKAGE_GROUP is appended to TropGENE_LOCUS, the > TropGENE_MAP_POSITION element jumps from the > TropGENE_LINKAGE_GROUP > to the TropGENE_ALLELE element... > > Regards, > > Pieter > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 13:32:39 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 19:32:39 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 11:12:29 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 08:12:29 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: Message-ID: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> No you are on to something! When I first created the plugin, I used a certain xml parser based on w3c dom. I had to switch to another parser and it seems that I was unaware of its limitations (getChildren only gets the direct children of an element). I will have this fixed fairly soon. 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 Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:07 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > > >> moby:MOBY > >> moby:Content > >> moby:Data > >> moby:Simple > >> moby:My_Child_Level_1B > >> moby:My_Child_Level_2A > >> moby:My_Child_Level_2B > >> > >> > > > > Do you have an example of an object that has this type > of > > structure? > > Yes, try for example DnaSequenceHolder from the BioMOBY > Central. > > I have been running some other tests in the mean time and > so far > almost every object I tried lacks child elements at level > 2 or > further down. The only one that does have an element at > level 2 is > the BlastJob object I have in my local Central. This one > has Strings, > Objects and a DataTime at level 2 or further down. > Everything is > missing except the DataTime primitive... I noticed that > hardly anyone > is using the DataTime primitive if I'm not the only one > using. It is > also hardly documented. Maybe it's just random noise in my > testing or > maybe I'm onto something.... > > If you want to try the BlastJob object my local registry > should still > be accessible from outside at: > http://137.224.52.237/phenolink/biomoby/central/cgi- > bin/MOBY-Central.pl > > Hope this helps, > > Pi > > > Thanks, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 13:48:22 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 19:48:22 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From francis_gibbons at hms.harvard.edu Tue Oct 4 14:38:29 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 04 Oct 2005 14:38:29 -0400 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Message-ID: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Hi, I'm trying to deregister some services originally created about a year ago. At the time I used the MOBY-S Perl API to do the job. Then Mark told us to go to a page which would generate RDF for us, which I dutifully did. But then the agent never really seemed to go into use. I threw away the RDF file, but my services remain registered; problem is, I can't deregister them using the API either. So they're currently immortal zombie services: they just won't die. That's a problem because I initially put up a number of services which were limited. Now that I'm older and wiser ;-), I'd like to rework them, but can't. I really don't want to create more services, since they more or less duplicate, but not exactly, the function of the existing ones. I simply want to revamp the existing ones. Can anyone tell me how I can do it? -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 jpsanchez at isciii.es Tue Oct 4 14:42:21 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 20:42:21 +0200 Subject: Autoreply: [MOBY-dev] Can't deregister services originally registered throughmethods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 15:12:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 12:12:09 -0700 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <000001c5c917$85a34df0$6500a8c0@notebook> Hi Frank, You can't remove a service if you specified a signature url. With that being said, if you give me the servicenames and authority of the services that you would like to remove, I can 'erase' the signature url and then you can remove them. Does this sound good to you? And to confirm, you are talking about services registered in the default Mobycentral registry? Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Frank > Gibbons > Sent: Tuesday, October 04, 2005 11:38 AM > To: MOBY-dev at biomoby.org > Subject: [MOBY-dev] Can't deregister services originally > registered through methods, then converted to RDF > > Hi, > > I'm trying to deregister some services originally created > about a year ago. > At the time I used the MOBY-S Perl API to do the job. Then > Mark told us to > go to a page which would generate RDF for us, which I > dutifully did. But > then the agent never really seemed to go into use. I threw > away the RDF > file, but my services remain registered; problem is, I > can't deregister > them using the API either. So they're currently immortal > zombie services: > they just won't die. > > That's a problem because I initially put up a number of > services which were > limited. Now that I'm older and wiser ;-), I'd like to > rework them, but > can't. I really don't want to create more services, since > they more or less > duplicate, but not exactly, the function of the existing > ones. I simply > want to revamp the existing ones. > > Can anyone tell me how I can do it? > > -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-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 15:17:28 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 21:17:28 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From markw at illuminae.com Tue Oct 4 15:15:02 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 4 Oct 2005 19:15:02 +0000 GMT Subject: [MOBY-dev] Can't deregister services originally registered throughmethods, then converted to RDF Message-ID: <281305509-1128453358-cardhu_blackberry.rim.net-7785-@engine10-cell01> Hi Frank - give me a minute and I'll delete your signatureRDF's. The delay in the agent is due to our decision to synchronize our data models with myGrid, but that's takint longer than expected. I'll do it now, M -----Original Message----- From: Frank Gibbons Date: Tue, 04 Oct 2005 14:38:29 To:MOBY-dev at biomoby.org Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Hi, I'm trying to deregister some services originally created about a year ago. At the time I used the MOBY-S Perl API to do the job. Then Mark told us to go to a page which would generate RDF for us, which I dutifully did. But then the agent never really seemed to go into use. I threw away the RDF file, but my services remain registered; problem is, I can't deregister them using the API either. So they're currently immortal zombie services: they just won't die. That's a problem because I initially put up a number of services which were limited. Now that I'm older and wiser ;-), I'd like to rework them, but can't. I really don't want to create more services, since they more or less duplicate, but not exactly, the function of the existing ones. I simply want to revamp the existing ones. Can anyone tell me how I can do it? -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-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Tue Oct 4 15:16:08 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 4 Oct 2005 19:16:08 +0000 GMT Subject: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: <1190951208-1128453424-cardhu_blackberry.rim.net-5001-@engine13-cell01> Eddie please do this. It will be easier for you to do it than for me to do it by ssh on my blackberry :-) Hello from the Biomoby scientific defense/review! Wish me luck!!! M -----Original Message----- From: "Edward Kawas" Date: Tue, 4 Oct 2005 12:12:09 To:"'Core developer announcements'" Subject: RE: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Hi Frank, You can't remove a service if you specified a signature url. With that being said, if you give me the servicenames and authority of the services that you would like to remove, I can 'erase' the signature url and then you can remove them. Does this sound good to you? And to confirm, you are talking about services registered in the default Mobycentral registry? Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Frank > Gibbons > Sent: Tuesday, October 04, 2005 11:38 AM > To: MOBY-dev at biomoby.org > Subject: [MOBY-dev] Can't deregister services originally > registered through methods, then converted to RDF > > Hi, > > I'm trying to deregister some services originally created > about a year ago. > At the time I used the MOBY-S Perl API to do the job. Then > Mark told us to > go to a page which would generate RDF for us, which I > dutifully did. But > then the agent never really seemed to go into use. I threw > away the RDF > file, but my services remain registered; problem is, I > can't deregister > them using the API either. So they're currently immortal > zombie services: > they just won't die. > > That's a problem because I initially put up a number of > services which were > limited. Now that I'm older and wiser ;-), I'd like to > rework them, but > can't. I really don't want to create more services, since > they more or less > duplicate, but not exactly, the function of the existing > ones. I simply > want to revamp the existing ones. > > Can anyone tell me how I can do it? > > -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-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Tue Oct 4 15:25:11 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 12:25:11 -0700 Subject: [MOBY-dev] Can't deregister services originally registeredthroughmethods, then converted to RDF In-Reply-To: <1190951208-1128453424-cardhu_blackberry.rim.net-5001-@engine13-cell01> Message-ID: <000101c5c919$57a73b30$6500a8c0@notebook> Good luck Mark!!! I will do it right away! Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of mark > wilkinson > Sent: Tuesday, October 04, 2005 12:16 PM > To: Core developer announcements > Subject: Re: [MOBY-dev] Can't deregister services > originally registeredthroughmethods, then converted to RDF > > Eddie please do this. It will be easier for you to do it > than for me to do it by ssh on my blackberry :-) > > Hello from the Biomoby scientific defense/review! Wish me > luck!!! > > M > > > -----Original Message----- > From: "Edward Kawas" > Date: Tue, 4 Oct 2005 12:12:09 > To:"'Core developer announcements'" bio.org> > Subject: RE: [MOBY-dev] Can't deregister services > originally registered > through methods, then converted to RDF > > Hi Frank, > > You can't remove a service if you specified a signature > url. > With that being said, if you give me the servicenames and > authority of the services that you would like to remove, I > can 'erase' the signature url and then you can remove them. > > Does this sound good to you? And to confirm, you are > talking > about services registered in the default Mobycentral > registry? > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of Frank > > Gibbons > > Sent: Tuesday, October 04, 2005 11:38 AM > > To: MOBY-dev at biomoby.org > > Subject: [MOBY-dev] Can't deregister services originally > > registered through methods, then converted to RDF > > > > Hi, > > > > I'm trying to deregister some services originally > created > > about a year ago. > > At the time I used the MOBY-S Perl API to do the job. > Then > > Mark told us to > > go to a page which would generate RDF for us, which I > > dutifully did. But > > then the agent never really seemed to go into use. I > threw > > away the RDF > > file, but my services remain registered; problem is, I > > can't deregister > > them using the API either. So they're currently immortal > > zombie services: > > they just won't die. > > > > That's a problem because I initially put up a number of > > services which were > > limited. Now that I'm older and wiser ;-), I'd like to > > rework them, but > > can't. I really don't want to create more services, > since > > they more or less > > duplicate, but not exactly, the function of the existing > > ones. I simply > > want to revamp the existing ones. > > > > Can anyone tell me how I can do it? > > > > -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-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Tue Oct 4 15:35:19 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 12:35:19 -0700 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <000201c5c91a$c1f99860$6500a8c0@notebook> Hi Frank, I set your signature URLS, with contact email fgibbons @ hms.harvard.edu, to NULL. You should now be able to remove your services. Eddie From jpsanchez at isciii.es Tue Oct 4 15:36:19 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 21:36:19 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originallyregisteredthroughmethods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From jpsanchez at isciii.es Tue Oct 4 15:39:54 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 21:39:54 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From francis_gibbons at hms.harvard.edu Tue Oct 4 15:42:35 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 04 Oct 2005 15:42:35 -0400 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <000001c5c917$85a34df0$6500a8c0@notebook> References: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051004153438.01190d18@email.med.harvard.edu> Hi Eddie. Yeah, I know that I'm not supposed to be able to remove a service through the API if I have a signature URL. But that sort of assumes that there's an agent looking for RDF at the signature URL, and continuously updating the service registry. It's not meant to be that you can *never* remove a service that has a signature URL, right? I guess you meant that if it has a signature URL in the database, then it's not supposed to be deletable - well, it's still the same situation for me, since I don't think I can change the signature URL in the database, once the service is registered. Anyway, as per Mark's recent message, I'd really appreciate it if you could remove the signature URL for the following services: ASimpleService YAService DBI_CSV The authority is llama.med.harvard.edu They're all in the default registry. If I understand correctly, once you delete the signature URL from the database, then I should be able to delete them using the Perl API function call - correct? That would be awsome. Thanks a lot, -Frank At 03:12 PM 10/4/2005, you wrote: >Hi Frank, > >You can't remove a service if you specified a signature url. >With that being said, if you give me the servicenames and >authority of the services that you would like to remove, I >can 'erase' the signature url and then you can remove them. > >Does this sound good to you? And to confirm, you are talking >about services registered in the default Mobycentral >registry? > >Eddie > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of Frank > > Gibbons > > Sent: Tuesday, October 04, 2005 11:38 AM > > To: MOBY-dev at biomoby.org > > Subject: [MOBY-dev] Can't deregister services originally > > registered through methods, then converted to RDF > > > > Hi, > > > > I'm trying to deregister some services originally created > > about a year ago. > > At the time I used the MOBY-S Perl API to do the job. Then > > Mark told us to > > go to a page which would generate RDF for us, which I > > dutifully did. But > > then the agent never really seemed to go into use. I threw > > away the RDF > > file, but my services remain registered; problem is, I > > can't deregister > > them using the API either. So they're currently immortal > > zombie services: > > they just won't die. > > > > That's a problem because I initially put up a number of > > services which were > > limited. Now that I'm older and wiser ;-), I'd like to > > rework them, but > > can't. I really don't want to create more services, since > > they more or less > > duplicate, but not exactly, the function of the existing > > ones. I simply > > want to revamp the existing ones. > > > > Can anyone tell me how I can do it? > > > > -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-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 jpsanchez at isciii.es Tue Oct 4 15:44:33 2005 From: jpsanchez at isciii.es (jpsanchez@isciii.es) Date: Tue, 4 Oct 2005 21:44:33 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta dirección será dada de baja próximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From gordonp at ucalgary.ca Tue Oct 4 16:03:52 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 04 Oct 2005 14:03:52 -0600 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: References: Message-ID: <4342E028.2040806@ucalgary.ca> Next time we have a MOBY meeting, Juan is buying us all a round of beer as punishment for setting autoreplies on mailing list messages... >Hola, >He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. >Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From edward.kawas at gmail.com Tue Oct 4 20:52:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 17:52:09 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <71484B4E-298B-4423-BF74-D968B86E644B@wur.nl> Message-ID: <001101c5c947$04dfbd40$6500a8c0@notebook> Hi Pieter! I tracked down the bug and I fixed it (*fingers crossed*). I am placing 2 jar files at the following links that need to replace the ones in your /taverna-workbench-1.3/lib/ directory: http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar Be sure to backup the 2 files you are about to replace, just in case! Then try out your workflows and let me know what happens. Also, if all is well, do you think that you could send me one of those workflows so I can use it as an example? Thanks a lot, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Tuesday, October 04, 2005 9:04 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: > > > No you are on to something! When I first created the > plugin, > > I used a certain xml parser based on w3c dom. I had to > > switch to another parser and it seems that I was unaware > of > > its limitations (getChildren only gets the direct > children > > of an element). > > > > I will have this fixed fairly soon. > > I'm looking forward to "testdrive" it :) > > Thanks, > > Pieter > > > > > 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 Pieter > >> Neerincx > >> Sent: Tuesday, October 04, 2005 8:07 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > >> missing in BioMOBYobjects > >> > >> > >> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > >> > >> > >>>> moby:MOBY > >>>> moby:Content > >>>> moby:Data > >>>> moby:Simple > >>>> moby:My_Child_Level_1B > >>>> moby:My_Child_Level_2A > >>>> moby:My_Child_Level_2B > >>>> > >>>> > >>>> > >>> > >>> Do you have an example of an object that has this type > >>> > >> of > >> > >>> structure? > >>> > >> > >> Yes, try for example DnaSequenceHolder from the BioMOBY > >> Central. > >> > >> I have been running some other tests in the mean time > and > >> so far > >> almost every object I tried lacks child elements at > level > >> 2 or > >> further down. The only one that does have an element at > >> level 2 is > >> the BlastJob object I have in my local Central. This > one > >> has Strings, > >> Objects and a DataTime at level 2 or further down. > >> Everything is > >> missing except the DataTime primitive... I noticed that > >> hardly anyone > >> is using the DataTime primitive if I'm not the only one > >> using. It is > >> also hardly documented. Maybe it's just random noise in > my > >> testing or > >> maybe I'm onto something.... > >> > >> If you want to try the BlastJob object my local > registry > >> should still > >> be accessible from outside at: > >> http://137.224.52.237/phenolink/biomoby/central/cgi- > >> bin/MOBY-Central.pl > >> > >> Hope this helps, > >> > >> Pi > >> > >> > >>> Thanks, > >>> > >>> Eddie > >>> > >>> _______________________________________________ > >>> MOBY-dev mailing list > >>> MOBY-dev at biomoby.org > >>> http://www.biomoby.org/mailman/listinfo/moby-dev > >>> > >>> > >> > >> > >> Wageningen University and Research centre (WUR) > >> Laboratory of Bioinformatics > >> Transitorium (building 312) room 1034 > >> Dreijenlaan 3 > >> 6703 HA Wageningen > >> The Netherlands > >> phone: 0317-483 060 > >> fax: 0317-483 584 > >> mobile: 06-143 66 783 > >> pieter.neerincx at wur.nl > >> > >> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Thu Oct 6 11:32:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 6 Oct 2005 17:32:41 +0200 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > Hi all, > > As we move toward deploying the new API, there are some serious > consequences on the underlying databases. > > Let me first re-cap the new API features that I am discussing and what > effects they have on the databases: > > 1) Inheritence from primitives through ISA relationships is no longer > allowed. e.g. plain-text ISA String is no longer allowed. To > achieve > the same result, you now create an object that inherits from Object > and > contains the primitive. e.g. plain-text ISA Object; plain-text HASA > String. Hi Mark et al., Any idea when this change will happen? If I look in the Central that is running the latest and greatest codebase, the forbidden ISA [some primitive] relationships are still in place :(. What is even worse is that the primitive DateTime ISA String. As a result I can not get one of my Objects (that plays by the rules of the latest specs) registered. At least I suspect this to be the problem. I don't get an error message when register my object, but it has amongst others a HASA DataTime and that relationship is not getting registered... Cheers, Pi Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Thu Oct 6 12:08:10 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Oct 2005 09:08:10 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> As you have noticed, the change has already happened at the code level just to prevent any more registrations of what will soon be illegal objects. I have a script that will update the database records of the ontologies and deprecate the old nodes, but we haven't yet run it on the public registry. Eddie is going to make a couple of changes to it over the next day or two, and then will send out a heads-up that the ontologies are changing forever, and a tutorial on how to do the update for service providers. We'll give a reasonable amount of time for people to update their services (say, 6 weeks) and then we will delete the old nodes from the ontology completely. The script is in the CVS so anyone running a registry can do the same thing. When I went to update my own services it took me less than 5 minutes to do so, so 6 weeks should be more than enough time for anyone who is actively concerned about their service :-) Cheers! M On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > Hi all, > > > > As we move toward deploying the new API, there are some serious > > consequences on the underlying databases. > > > > Let me first re-cap the new API features that I am discussing and what > > effects they have on the databases: > > > > 1) Inheritence from primitives through ISA relationships is no longer > > allowed. e.g. plain-text ISA String is no longer allowed. To > > achieve > > the same result, you now create an object that inherits from Object > > and > > contains the primitive. e.g. plain-text ISA Object; plain-text HASA > > String. > > Hi Mark et al., > > Any idea when this change will happen? If I look in the Central that > is running the latest and greatest codebase, the forbidden ISA [some > primitive] relationships are still in place :(. What is even worse is > that the primitive DateTime ISA String. As a result I can not get one > of my Objects (that plays by the rules of the latest specs) > registered. At least I suspect this to be the problem. I don't get an > error message when register my object, but it has amongst others a > HASA DataTime and that relationship is not getting registered... > > Cheers, > > Pi > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "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 Thu Oct 6 17:39:45 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Oct 2005 14:39:45 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <000101c5cab8$549b3c20$6500a8c0@notebook> References: <000101c5cab8$549b3c20$6500a8c0@notebook> Message-ID: <1128634785.1179.111.camel@bioinfo.icapture.ubc.ca> It's not just that, it's also the "spirit" of the matter. e.g. our LSID's are based on the name of the object. Granted, we currently only return metadata, so we could in principle re-define the object without breaking the LSID standard, but it does break the "spirit" of the identifier. But having said that, I don't particularly care one way or the other. It's painful no matter what we do. 1) If we change to _2, deprecate the old ones, and after 6 weeks delete the old, leaving the _2's in their place then: a) people who are affected will have to update their servces b) people will have to re-register their services 2) If we change to _2 temporarily, deprecate, delete, and then rename the _2's back again after 6 weeks: a) people affected will have to either i) update their services, re-register, then ii) update their services again and re-register OR i) update their services and NOT re-register, and ii) their services will be "illegal" for 6 weeks, There's no painless way to do this, so whatever the community feels is best... M On Thu, 2005-10-06 at 13:55 -0700, Edward Kawas wrote: > Hi, > > I am working on this script right now as we speak, but I > just wanted to get feedback (for a second time). > > >From what I understand, I am going to go through the > ontology, and deprecate any data type that inherits from a > primitive. Any object that I deprecate will be duplicated > and have an _2 appended to its name as well as having its > ISA relationship set to object and adding a HASA primitive > relationship. So far so good. > > In six weeks, I am going to go through the ontology and > remove all objects that inherit from a primitive, leaving > those that were duplicated with an _2 alone. Therefore, in 6 > weeks, we will have objects like text-plain_2, text-xml_2, > etc. > > I know that some people are fine with this and others are > not. Some might not even care. However, what I want to know > is what MOBYers think and if anyone has any other > comments/suggestions. So please let me know. > > Just to get this started, I am still pretty iffy about > leaving x_2 data types in the ontology. I do see Marks point > on how services that are not updated choking since they > expect the data type to inherit from a primitive. Any ideas? > > Thanks, > > Eddie > > > -----Original Message----- > > From: Mark Wilkinson [mailto:markw at illuminae.com] > > Sent: Thursday, October 06, 2005 9:08 AM > > To: Core developer announcements > > Cc: Eddie Kawas > > Subject: Re: [moby] Re: [MOBY-dev] Migration of database > > to new API > > > > As you have noticed, the change has already happened at > > the code level > > just to prevent any more registrations of what will soon > > be illegal > > objects. I have a script that will update the database > > records of the > > ontologies and deprecate the old nodes, but we haven't yet > > run it on the > > public registry. Eddie is going to make a couple of > > changes to it over > > the next day or two, and then will send out a heads-up > > that the > > ontologies are changing forever, and a tutorial on how to > > do the update > > for service providers. We'll give a reasonable amount of > > time for > > people to update their services (say, 6 weeks) and then we > > will delete > > the old nodes from the ontology completely. The script is > > in the CVS so > > anyone running a registry can do the same thing. > > > > When I went to update my own services it took me less than > > 5 minutes to > > do so, so 6 weeks should be more than enough time for > > anyone who is > > actively concerned about their service :-) > > > > Cheers! > > > > M > > > > > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > > > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > > > > > Hi all, > > > > > > > > As we move toward deploying the new API, there are > > some serious > > > > consequences on the underlying databases. > > > > > > > > Let me first re-cap the new API features that I am > > discussing and what > > > > effects they have on the databases: > > > > > > > > 1) Inheritence from primitives through ISA > > relationships is no longer > > > > allowed. e.g. plain-text ISA String is no longer > > allowed. To > > > > achieve > > > > the same result, you now create an object that > > inherits from Object > > > > and > > > > contains the primitive. e.g. plain-text ISA Object; > > plain-text HASA > > > > String. > > > > > > Hi Mark et al., > > > > > > Any idea when this change will happen? If I look in the > > Central that > > > is running the latest and greatest codebase, the > > forbidden ISA [some > > > primitive] relationships are still in place :(. What is > > even worse is > > > that the primitive DateTime ISA String. As a result I > > can not get one > > > of my Objects (that plays by the rules of the latest > > specs) > > > registered. At least I suspect this to be the problem. I > > don't get an > > > error message when register my object, but it has > > amongst others a > > > HASA DataTime and that relationship is not getting > > registered... > > > > > > Cheers, > > > > > > Pi > > > > > > > > > > > > > > > Wageningen University and Research centre (WUR) > > > Laboratory of Bioinformatics > > > Transitorium (building 312) room 1034 > > > Dreijenlaan 3 > > > 6703 HA Wageningen > > > The Netherlands > > > phone: 0317-483 060 > > > fax: 0317-483 584 > > > mobile: 06-143 66 783 > > > pieter.neerincx at wur.nl > > > > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > > "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 > -- "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 edward.kawas at gmail.com Thu Oct 6 16:55:47 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 6 Oct 2005 13:55:47 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: <000101c5cab8$549b3c20$6500a8c0@notebook> Hi, I am working on this script right now as we speak, but I just wanted to get feedback (for a second time). >From what I understand, I am going to go through the ontology, and deprecate any data type that inherits from a primitive. Any object that I deprecate will be duplicated and have an _2 appended to its name as well as having its ISA relationship set to object and adding a HASA primitive relationship. So far so good. In six weeks, I am going to go through the ontology and remove all objects that inherit from a primitive, leaving those that were duplicated with an _2 alone. Therefore, in 6 weeks, we will have objects like text-plain_2, text-xml_2, etc. I know that some people are fine with this and others are not. Some might not even care. However, what I want to know is what MOBYers think and if anyone has any other comments/suggestions. So please let me know. Just to get this started, I am still pretty iffy about leaving x_2 data types in the ontology. I do see Marks point on how services that are not updated choking since they expect the data type to inherit from a primitive. Any ideas? Thanks, Eddie > -----Original Message----- > From: Mark Wilkinson [mailto:markw at illuminae.com] > Sent: Thursday, October 06, 2005 9:08 AM > To: Core developer announcements > Cc: Eddie Kawas > Subject: Re: [moby] Re: [MOBY-dev] Migration of database > to new API > > As you have noticed, the change has already happened at > the code level > just to prevent any more registrations of what will soon > be illegal > objects. I have a script that will update the database > records of the > ontologies and deprecate the old nodes, but we haven't yet > run it on the > public registry. Eddie is going to make a couple of > changes to it over > the next day or two, and then will send out a heads-up > that the > ontologies are changing forever, and a tutorial on how to > do the update > for service providers. We'll give a reasonable amount of > time for > people to update their services (say, 6 weeks) and then we > will delete > the old nodes from the ontology completely. The script is > in the CVS so > anyone running a registry can do the same thing. > > When I went to update my own services it took me less than > 5 minutes to > do so, so 6 weeks should be more than enough time for > anyone who is > actively concerned about their service :-) > > Cheers! > > M > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > > > Hi all, > > > > > > As we move toward deploying the new API, there are > some serious > > > consequences on the underlying databases. > > > > > > Let me first re-cap the new API features that I am > discussing and what > > > effects they have on the databases: > > > > > > 1) Inheritence from primitives through ISA > relationships is no longer > > > allowed. e.g. plain-text ISA String is no longer > allowed. To > > > achieve > > > the same result, you now create an object that > inherits from Object > > > and > > > contains the primitive. e.g. plain-text ISA Object; > plain-text HASA > > > String. > > > > Hi Mark et al., > > > > Any idea when this change will happen? If I look in the > Central that > > is running the latest and greatest codebase, the > forbidden ISA [some > > primitive] relationships are still in place :(. What is > even worse is > > that the primitive DateTime ISA String. As a result I > can not get one > > of my Objects (that plays by the rules of the latest > specs) > > registered. At least I suspect this to be the problem. I > don't get an > > error message when register my object, but it has > amongst others a > > HASA DataTime and that relationship is not getting > registered... > > > > Cheers, > > > > Pi > > > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "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 Pieter.Neerincx at wur.nl Fri Oct 7 05:16:23 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 7 Oct 2005 11:16:23 +0200 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: On 6-Oct-2005, at 6:08 PM, Mark Wilkinson wrote: > As you have noticed, the change has already happened at the code level > just to prevent any more registrations of what will soon be illegal > objects. That would be fine, but I have upgraded my service and objects to conform to the new standard and can not register legal stuff :(. > I have a script that will update the database records of the > ontologies and deprecate the old nodes, but we haven't yet run it > on the > public registry. Eddie is going to make a couple of changes to it > over > the next day or two, and then will send out a heads-up that the > ontologies are changing forever, and a tutorial on how to do the > update > for service providers. We'll give a reasonable amount of time for > people to update their services (say, 6 weeks) and then we will delete > the old nodes from the ontology completely. The script is in the > CVS so > anyone running a registry can do the same thing. I'll run that script on my local central to see if I can register after the change. > > When I went to update my own services it took me less than 5 > minutes to > do so, so 6 weeks should be more than enough time for anyone who is > actively concerned about their service :-) IMHO it might be even a bit too much. Personally I opt for 2) If we change to _2 temporarily, deprecate, delete, and then rename the _2's back again after 6 weeks: with: i) update their services and NOT re-register, and ii) their services will be "illegal" for 6 weeks, This keeps the ontology clean. This change was announced long enough ago to give people a chance to update their services. For me it took even less time. I didn't have to update my services at all. When I extract for example text from a CustomObject ISA String object I was already assuming it would not have any HASA relations, because it is a primitive. So I was getting the text from that node and any childs it might have. After the change, if my service fetches text from CustomObject I get the text from it's HASA String. No recoding needed; painless change :). I did spend the 5 minutes though on the scripts I use to register my services at a central. Anyway, for the DateTime primitive things are still a bit strange. Currently DateTime ISA String ISA Object. All other primitives are simply ISA Object. This will change to DateTime ISA Object and HASA String. According to the spec DateTime shouldn't have a String, because it is by itself already a primitive... In the current situation DateTime is not a primitive, but just yet another type of String. just my 2c, Pi > > Cheers! > > M > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > >> On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> As we move toward deploying the new API, there are some serious >>> consequences on the underlying databases. >>> >>> Let me first re-cap the new API features that I am discussing and >>> what >>> effects they have on the databases: >>> >>> 1) Inheritence from primitives through ISA relationships is no >>> longer >>> allowed. e.g. plain-text ISA String is no longer allowed. To >>> achieve >>> the same result, you now create an object that inherits from Object >>> and >>> contains the primitive. e.g. plain-text ISA Object; plain-text HASA >>> String. >>> >> >> Hi Mark et al., >> >> Any idea when this change will happen? If I look in the Central that >> is running the latest and greatest codebase, the forbidden ISA [some >> primitive] relationships are still in place :(. What is even worse is >> that the primitive DateTime ISA String. As a result I can not get one >> of my Objects (that plays by the rules of the latest specs) >> registered. At least I suspect this to be the problem. I don't get an >> error message when register my object, but it has amongst others a >> HASA DataTime and that relationship is not getting registered... >> >> Cheers, >> >> Pi >> >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Oct 7 05:30:14 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 7 Oct 2005 11:30:14 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <001101c5c947$04dfbd40$6500a8c0@notebook> References: <001101c5c947$04dfbd40$6500a8c0@notebook> Message-ID: <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> Hi Eddie, On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > Hi Pieter! > > I tracked down the bug and I fixed it (*fingers crossed*). > > I am placing 2 jar files at the following links that need to > replace the ones in your /taverna-workbench-1.3/lib/ > directory: > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > Be sure to backup the 2 files you are about to replace, just > in case! > > Then try out your workflows and let me know what happens. I did some simple tests with the objects that failed previously and so far so good :) Thanks for the quick fix! > > Also, if all is well, do you think that you could send me > one of those workflows so I can use it as an example? After a lot of trail and error playing with a local central I think it's about time I register my services and objects at the central Central as well. Will do so once the central Central databases are migrated to the new API... Cheers, Pi > Thanks a lot, > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter >> Neerincx >> Sent: Tuesday, October 04, 2005 9:04 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> >> On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: >> >> >>> No you are on to something! When I first created the >>> >> plugin, >> >>> I used a certain xml parser based on w3c dom. I had to >>> switch to another parser and it seems that I was unaware >>> >> of >> >>> its limitations (getChildren only gets the direct >>> >> children >> >>> of an element). >>> >>> I will have this fixed fairly soon. >>> >> >> I'm looking forward to "testdrive" it :) >> >> Thanks, >> >> Pieter >> >> >>> >>> 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 Pieter >>>> Neerincx >>>> Sent: Tuesday, October 04, 2005 8:07 AM >>>> To: Core developer announcements >>>> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >>>> missing in BioMOBYobjects >>>> >>>> >>>> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >>>> >>>> >>>> >>>>>> moby:MOBY >>>>>> moby:Content >>>>>> moby:Data >>>>>> moby:Simple >>>>>> moby:My_Child_Level_1B >>>>>> moby:My_Child_Level_2A >>>>>> moby:My_Child_Level_2B >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Do you have an example of an object that has this type >>>>> >>>>> >>>> of >>>> >>>> >>>>> structure? >>>>> >>>>> >>>> >>>> Yes, try for example DnaSequenceHolder from the BioMOBY >>>> Central. >>>> >>>> I have been running some other tests in the mean time >>>> >> and >> >>>> so far >>>> almost every object I tried lacks child elements at >>>> >> level >> >>>> 2 or >>>> further down. The only one that does have an element at >>>> level 2 is >>>> the BlastJob object I have in my local Central. This >>>> >> one >> >>>> has Strings, >>>> Objects and a DataTime at level 2 or further down. >>>> Everything is >>>> missing except the DataTime primitive... I noticed that >>>> hardly anyone >>>> is using the DataTime primitive if I'm not the only one >>>> using. It is >>>> also hardly documented. Maybe it's just random noise in >>>> >> my >> >>>> testing or >>>> maybe I'm onto something.... >>>> >>>> If you want to try the BlastJob object my local >>>> >> registry >> >>>> should still >>>> be accessible from outside at: >>>> http://137.224.52.237/phenolink/biomoby/central/cgi- >>>> bin/MOBY-Central.pl >>>> >>>> Hope this helps, >>>> >>>> Pi >>>> >>>> >>>> >>>>> Thanks, >>>>> >>>>> Eddie >>>>> >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at biomoby.org >>>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>>> >>>>> >>>>> >>>> >>>> >>>> Wageningen University and Research centre (WUR) >>>> Laboratory of Bioinformatics >>>> Transitorium (building 312) room 1034 >>>> Dreijenlaan 3 >>>> 6703 HA Wageningen >>>> The Netherlands >>>> phone: 0317-483 060 >>>> fax: 0317-483 584 >>>> mobile: 06-143 66 783 >>>> pieter.neerincx at wur.nl >>>> >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Oct 7 10:47:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Oct 2005 07:47:29 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: <1128696449.3111.5.camel@bioinfo.icapture.ubc.ca> On Fri, 2005-10-07 at 11:16 +0200, Pieter Neerincx wrote: > Anyway, for the DateTime primitive things are still a bit strange. > Currently DateTime ISA String ISA Object. All other primitives are > simply ISA Object. This will change to DateTime ISA Object and HASA > String. According to the spec DateTime shouldn't have a String, > because it is by itself already a primitive... In the current > situation DateTime is not a primitive, but just yet another type of > String. Okay, I'll have a look at this today. Might be "just a bug" rather than a systemic error :-) M From Pieter.Neerincx at wur.nl Fri Oct 7 13:25:28 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 7 Oct 2005 19:25:28 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> References: <001101c5c947$04dfbd40$6500a8c0@notebook> <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> Message-ID: <0DCBF3DF-D564-47ED-9E85-9B669BA49ADA@wur.nl> Hi Eddie, Sorry, I cheered premature :(. For one of my services I use the articleName attribute of two String objects to know which one contains which data. Hence I have something like: Bla bla Alb alb The Object my service receives in Taverna lacks the articleName attributes for it's String childs :(. Hence it becomes this: Bla bla Alb alb Looks like the fix introduced a new bug as well... Pieter On 07Oct2005, at 11:30, Pieter Neerincx wrote: > Hi Eddie, > > On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > > >> Hi Pieter! >> >> I tracked down the bug and I fixed it (*fingers crossed*). >> >> I am placing 2 jar files at the following links that need to >> replace the ones in your /taverna-workbench-1.3/lib/ >> directory: >> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar >> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar >> >> Be sure to backup the 2 files you are about to replace, just >> in case! >> >> Then try out your workflows and let me know what happens. >> > > I did some simple tests with the objects that failed previously and > so far so good :) > > Thanks for the quick fix! > > >> >> Also, if all is well, do you think that you could send me >> one of those workflows so I can use it as an example? >> > > After a lot of trail and error playing with a local central I think > it's about time I register my services and objects at the central > Central as well. Will do so once the central Central databases are > migrated to the new API... > > Cheers, > > Pi > > >> Thanks a lot, >> >> Eddie >> From senger at ebi.ac.uk Sun Oct 9 17:18:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 9 Oct 2005 22:18:58 +0100 (BST) Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <433D0742.4050708@cnb.uam.es> Message-ID: Hi all, Last week, I have met David and he explained to me all what was happenning with the error handling (because I was off-line most of the last week). I agree with the various voices that serviceNotes is better than PIB, and I am happy to hear that Mark has not problem with an additional 'Notes' in 'serviceNotes' (he is probably the only one who is filling serviceNotes now). Could someone summarize the result of voting and publish somewhere the latest version of the API regarding the error handling please? When this is out I will immediately add it to the Moses-based generated services. Thanks and regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Sun Oct 9 17:48:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 9 Oct 2005 22:48:44 +0100 (BST) Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <000101c5cab8$549b3c20$6500a8c0@notebook> Message-ID: > Just to get this started, I am still pretty iffy about > leaving x_2 data types in the ontology. I do see Marks point > on how services that are not updated choking since they > expect the data type to inherit from a primitive. Any ideas? > As I said before I would suggest: - do not use any automatic script - tell people that after 6 weeks the deprecented data objects will be deleted (together with the services that still use them) - optionally: write a document to advise what people with affected data types types should do (e.g. help them by removing Signature URLs from such services so they can re-register them again) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Sun Oct 9 21:35:42 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 09 Oct 2005 18:35:42 -0700 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: References: Message-ID: <4349C56E.8000308@illuminae.com> We should also call for a new vote, and perhaps this time simply use the mailing list since the last call for votes only got one response... Let's say October 24th as the final word on this? M Martin Senger wrote: >Hi all, > Last week, I have met David and he explained to me all what was >happenning with the error handling (because I was off-line most of the >last week). I agree with the various voices that serviceNotes is better >than PIB, and I am happy to hear that Mark has not problem with an >additional 'Notes' in 'serviceNotes' (he is probably the only one who is >filling serviceNotes now). > Could someone summarize the result of voting and publish somewhere the >latest version of the API regarding the error handling please? When this >is out I will immediately add it to the Moses-based generated services. > > Thanks and regards, > Martin > > > From senger at ebi.ac.uk Mon Oct 10 04:57:43 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 10 Oct 2005 09:57:43 +0100 (BST) Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <4349C56E.8000308@illuminae.com> Message-ID: > We should also call for a new vote, and perhaps this time simply use the > mailing list since the last call for votes only got one response... > > Let's say October 24th as the final word on this? > Where can I can the latest, official, document describing the latest consensus? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From dgpisano at cnb.uam.es Mon Oct 10 06:45:33 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Mon, 10 Oct 2005 12:45:33 +0200 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: References: Message-ID: <434A464D.7070203@cnb.uam.es> The latest version is in the bugzilla http://bugzilla.open-bio.org/attachment.cgi?id=233 David Martin Senger escribi?: >>We should also call for a new vote, and perhaps this time simply use the >>mailing list since the last call for votes only got one response... >> >>Let's say October 24th as the final word on this? >> >> >> > Where can I can the latest, official, document describing the latest >consensus? > > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20051010/deaecc61/dgpisano-0002.vcf From edward.kawas at gmail.com Tue Oct 11 00:58:27 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 10 Oct 2005 21:58:27 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <0DCBF3DF-D564-47ED-9E85-9B669BA49ADA@wur.nl> Message-ID: <000401c5ce20$6bcf7300$6900a8c0@notebook> Hi Pieter, I uploaded 2 new files. I am not sure if your bug is fixed, but I thought that I would let you know. I have made new additions and I modified some of the xml parsing, so while I haven't worked on your bug, it may be fixed (or made worse ;-). By the way, do you think that you could send me a workflow whenever you notice something fishy? Thanks, Eddie http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Friday, October 07, 2005 10:25 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > Sorry, I cheered premature :(. For one of my services I > use the > articleName attribute of two String objects to know which > one > contains which data. Hence I have something like: > > > articleName="this.one"> > Bla bla > > articleName="the.other.one"> > Alb alb > > > > The Object my service receives in Taverna lacks the > articleName > attributes for it's String childs :(. Hence it becomes > this: > > > > Bla bla > > > Alb alb > > > > Looks like the fix introduced a new bug as well... > > Pieter > > On 07Oct2005, at 11:30, Pieter Neerincx wrote: > > > Hi Eddie, > > > > On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > > > > > >> Hi Pieter! > >> > >> I tracked down the bug and I fixed it (*fingers > crossed*). > >> > >> I am placing 2 jar files at the following links that > need to > >> replace the ones in your /taverna-workbench-1.3/lib/ > >> directory: > >> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > 1.3.jar > >> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > >> > >> Be sure to backup the 2 files you are about to replace, > just > >> in case! > >> > >> Then try out your workflows and let me know what > happens. > >> > > > > I did some simple tests with the objects that failed > previously and > > so far so good :) > > > > Thanks for the quick fix! > > > > > >> > >> Also, if all is well, do you think that you could send > me > >> one of those workflows so I can use it as an example? > >> > > > > After a lot of trail and error playing with a local > central I think > > it's about time I register my services and objects at > the central > > Central as well. Will do so once the central Central > databases are > > migrated to the new API... > > > > Cheers, > > > > Pi > > > > > >> Thanks a lot, > >> > >> Eddie > >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From carrere at toulouse.inra.fr Thu Oct 13 03:17:34 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu, 13 Oct 2005 09:17:34 +0200 Subject: [MOBY-dev] Hardware upgrade: services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <434E0A0E.50006@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Friday (October 14th) 9.00 a.m. (GMT+1) till monday (October 17th) 11.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Next week, services interruptions should happen... Sorry for inconvenience, Sebastien Carrere From carrere at toulouse.inra.fr Thu Oct 13 03:17:34 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu, 13 Oct 2005 09:17:34 +0200 Subject: [MOBY-dev] Hardware upgrade: services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <434E0A0E.50006@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Friday (October 14th) 9.00 a.m. (GMT+1) till monday (October 17th) 11.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Next week, services interruptions should happen... Sorry for inconvenience, Sebastien Carrere From Pieter.Neerincx at wur.nl Thu Oct 13 11:46:39 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 13 Oct 2005 17:46:39 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <000401c5ce20$6bcf7300$6900a8c0@notebook> References: <000401c5ce20$6bcf7300$6900a8c0@notebook> Message-ID: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Hi Eddie, On 11-Oct-2005, at 6:58 AM, Edward Kawas wrote: > Hi Pieter, > > I uploaded 2 new files. I am not sure if your bug is fixed, > but I thought that I would let you know. I have made new > additions and I modified some of the xml parsing, so while I > haven't worked on your bug, it may be fixed (or made worse > ;-). Well just tested the new versions and to be honest it kind of made it really bad :( I can not get any output anymore from any BioMOBY service. So I switched back to the previous versions of the *.jar files you had uploaded and apart from the missing articleName attribute things work again :). > > By the way, do you think that you could send me a workflow > whenever you notice something fishy? Sure. You mean the workflow saved as a scufl xml file I assume. Will do that in the future, but, in this case just try any BioMOBY service. Maybe some other files got updated as well in your development version apart from the 2 uploaded files... Cheers, Pieter > > Thanks, > > Eddie > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > >> -----Original Message----- >> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter >> Neerincx >> Sent: Friday, October 07, 2005 10:25 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> Hi Eddie, >> >> Sorry, I cheered premature :(. For one of my services I >> use the >> articleName attribute of two String objects to know which >> one >> contains which data. Hence I have something like: >> >> >> > articleName="this.one"> >> Bla bla >> >> > articleName="the.other.one"> >> Alb alb >> >> >> >> The Object my service receives in Taverna lacks the >> articleName >> attributes for it's String childs :(. Hence it becomes >> this: >> >> >> >> Bla bla >> >> >> Alb alb >> >> >> >> Looks like the fix introduced a new bug as well... >> >> Pieter >> >> On 07Oct2005, at 11:30, Pieter Neerincx wrote: >> >> >>> Hi Eddie, >>> >>> On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: >>> >>> >>> >>>> Hi Pieter! >>>> >>>> I tracked down the bug and I fixed it (*fingers >>>> >> crossed*). >> >>>> >>>> I am placing 2 jar files at the following links that >>>> >> need to >> >>>> replace the ones in your /taverna-workbench-1.3/lib/ >>>> directory: >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- >>>> >> 1.3.jar >> >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar >>>> >>>> Be sure to backup the 2 files you are about to replace, >>>> >> just >> >>>> in case! >>>> >>>> Then try out your workflows and let me know what >>>> >> happens. >> >>>> >>>> >>> >>> I did some simple tests with the objects that failed >>> >> previously and >> >>> so far so good :) >>> >>> Thanks for the quick fix! >>> >>> >>> >>>> >>>> Also, if all is well, do you think that you could send >>>> >> me >> >>>> one of those workflows so I can use it as an example? >>>> >>>> >>> >>> After a lot of trail and error playing with a local >>> >> central I think >> >>> it's about time I register my services and objects at >>> >> the central >> >>> Central as well. Will do so once the central Central >>> >> databases are >> >>> migrated to the new API... >>> >>> Cheers, >>> >>> Pi >>> >>> >>> >>>> Thanks a lot, >>>> >>>> Eddie >>>> >>>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Thu Oct 13 11:52:02 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 13 Oct 2005 08:52:02 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Message-ID: <000601c5d00e$0fca4180$6900a8c0@notebook> Sorry Pieter, I am still looking into it. Since the last time you tested, I fixed numerous logic errors. I think that ultimately you will notice that the article name issue will be fixed. I will let you know when a new test version is out. I thought I just had one, but a workflow that executes every branch of a service found an error. Thanks for your patience! Ed > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Thursday, October 13, 2005 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > On 11-Oct-2005, at 6:58 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I uploaded 2 new files. I am not sure if your bug is > fixed, > > but I thought that I would let you know. I have made new > > additions and I modified some of the xml parsing, so > while I > > haven't worked on your bug, it may be fixed (or made > worse > > ;-). > > Well just tested the new versions and to be honest it kind > of made it > really bad :( I can not get any output anymore from any > BioMOBY > service. So I switched back to the previous versions of > the *.jar > files you had uploaded and apart from the missing > articleName > attribute things work again :). > > > > > By the way, do you think that you could send me a > workflow > > whenever you notice something fishy? > > Sure. You mean the workflow saved as a scufl xml file I > assume. Will > do that in the future, but, in this case just try any > BioMOBY > service. Maybe some other files got updated as well in > your > development version apart from the 2 uploaded files... > > Cheers, > > Pieter > > > > > Thanks, > > > > Eddie > > > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > 1.3.jar > > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > > > > >> -----Original Message----- > >> From: moby-dev-bounces at portal.open-bio.org > [mailto:moby- > >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter > >> Neerincx > >> Sent: Friday, October 07, 2005 10:25 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > >> missing in BioMOBYobjects > >> > >> Hi Eddie, > >> > >> Sorry, I cheered premature :(. For one of my services I > >> use the > >> articleName attribute of two String objects to know > which > >> one > >> contains which data. Hence I have something like: > >> > >> > >> >> articleName="this.one"> > >> Bla bla > >> > >> >> articleName="the.other.one"> > >> Alb alb > >> > >> > >> > >> The Object my service receives in Taverna lacks the > >> articleName > >> attributes for it's String childs :(. Hence it becomes > >> this: > >> > >> > >> > >> Bla bla > >> > >> > >> Alb alb > >> > >> > >> > >> Looks like the fix introduced a new bug as well... > >> > >> Pieter > >> > >> On 07Oct2005, at 11:30, Pieter Neerincx wrote: > >> > >> > >>> Hi Eddie, > >>> > >>> On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > >>> > >>> > >>> > >>>> Hi Pieter! > >>>> > >>>> I tracked down the bug and I fixed it (*fingers > >>>> > >> crossed*). > >> > >>>> > >>>> I am placing 2 jar files at the following links that > >>>> > >> need to > >> > >>>> replace the ones in your /taverna-workbench-1.3/lib/ > >>>> directory: > >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > >>>> > >> 1.3.jar > >> > >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > >>>> > >>>> Be sure to backup the 2 files you are about to > replace, > >>>> > >> just > >> > >>>> in case! > >>>> > >>>> Then try out your workflows and let me know what > >>>> > >> happens. > >> > >>>> > >>>> > >>> > >>> I did some simple tests with the objects that failed > >>> > >> previously and > >> > >>> so far so good :) > >>> > >>> Thanks for the quick fix! > >>> > >>> > >>> > >>>> > >>>> Also, if all is well, do you think that you could > send > >>>> > >> me > >> > >>>> one of those workflows so I can use it as an example? > >>>> > >>>> > >>> > >>> After a lot of trail and error playing with a local > >>> > >> central I think > >> > >>> it's about time I register my services and objects at > >>> > >> the central > >> > >>> Central as well. Will do so once the central Central > >>> > >> databases are > >> > >>> migrated to the new API... > >>> > >>> Cheers, > >>> > >>> Pi > >>> > >>> > >>> > >>>> Thanks a lot, > >>>> > >>>> Eddie > >>>> > >>>> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Thu Oct 13 19:43:14 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 13 Oct 2005 16:43:14 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Message-ID: <001201c5d04f$e2e15860$6900a8c0@notebook> Hi Pieter, I have uploaded the 2 jar files to http://bioinfo.icapture.ubc.ca/ekawas/jars/ There are 2 of them. Moreover, I have uploaded some workflows: http://bioinfo.icapture.ubc.ca/ekawas/workflows/ Test this version out. I believe that I fixed the article name bug. I have also fixed various other anomalies. Let me know how it goes. I am going to keep trying to create workflows that utilize complex Moby datatypes (GeneInfo comes to mind) to ensure that all is well. Thanks a lot, Eddie From aperezp at uma.es Fri Oct 14 06:03:56 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Fri, 14 Oct 2005 12:03:56 +0200 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: <20051014100352.0A065C0015@correo2.uma.es> Hi, do you know if is there any easy Perl function for obtaining the dataType and serviceType ontology in a tree way? Thanks in advance, Antonio. From edward.kawas at gmail.com Fri Oct 14 10:56:02 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 14 Oct 2005 07:56:02 -0700 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <20051014100352.0A065C0015@correo2.uma.es> Message-ID: <000001c5d0cf$66552170$6900a8c0@notebook> Take a look at the following project http://bioinformatics.org/project/?group_id=190 I believe that it produces a tree using wxPerl. Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Antonio J. > P?rez > Sent: Friday, October 14, 2005 3:04 AM > To: 'Core developer announcements' > Cc: Inb-tecnico at everest.cnb.uam.es > Subject: [MOBY-dev] Perl function for object tree > > Hi, do you know if is there any easy Perl function > for obtaining the > dataType and serviceType ontology in a tree way? > Thanks in advance, > > Antonio. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Sat Oct 15 12:29:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 15 Oct 2005 09:29:09 -0700 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <000001c5d0cf$66552170$6900a8c0@notebook> References: <000001c5d0cf$66552170$6900a8c0@notebook> Message-ID: <43512E55.3050505@illuminae.com> yeah.. but no guarantees that it works - I haven't looked at that code in almost two years! I abandoned wxPerl because it was desperately under-documented at the time (yes, I know... people in glass houses...) If anyone needs it, I could update my GO_Browser.pm widget (part of BioPerl) so that it presents the ISA part of the Moby object/service hierarchy. It uses Tk Perl, and would only take a couple of minutes to modify... it also allows programmable call-backs on mouse events that take place on the tree nodes (clicks, double-clicks, mouseovers, etc). If there is a need for this, please say so. M Edward Kawas wrote: >Take a look at the following project >http://bioinformatics.org/project/?group_id=190 I believe >that it produces a tree using wxPerl. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>dev-bounces at portal.open-bio.org] On Behalf Of Antonio J. >>P?rez >>Sent: Friday, October 14, 2005 3:04 AM >>To: 'Core developer announcements' >>Cc: Inb-tecnico at everest.cnb.uam.es >>Subject: [MOBY-dev] Perl function for object tree >> >> Hi, do you know if is there any easy Perl function >>for obtaining the >>dataType and serviceType ontology in a tree way? >> Thanks in advance, >> >> Antonio. >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > From aperezp at uma.es Sat Oct 15 15:38:58 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Sat, 15 Oct 2005 21:38:58 +0200 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <43512E55.3050505@illuminae.com> Message-ID: <20051015193902.9A108C0008@correo2.uma.es> Hi Mark and Edward, and thank you to both, If it is not too work and bother, it would be very useful for showing the Biomoby ontology. We are now building CGIs showing object and service ontology and if there are modules which help in this subject, it is always good not repeat previously-done and as I can see good work. Regards and thanks again, Antonio. -----Mensaje original----- De: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] En nombre de Mark Wilkinson Enviado el: s?bado, 15 de octubre de 2005 18:29 Para: Core developer announcements Asunto: Re: [MOBY-dev] Perl function for object tree yeah.. but no guarantees that it works - I haven't looked at that code in almost two years! I abandoned wxPerl because it was desperately under-documented at the time (yes, I know... people in glass houses...) If anyone needs it, I could update my GO_Browser.pm widget (part of BioPerl) so that it presents the ISA part of the Moby object/service hierarchy. It uses Tk Perl, and would only take a couple of minutes to modify... it also allows programmable call-backs on mouse events that take place on the tree nodes (clicks, double-clicks, mouseovers, etc). If there is a need for this, please say so. M Edward Kawas wrote: >Take a look at the following project >http://bioinformatics.org/project/?group_id=190 I believe >that it produces a tree using wxPerl. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>dev-bounces at portal.open-bio.org] On Behalf Of Antonio J. >>P?rez >>Sent: Friday, October 14, 2005 3:04 AM >>To: 'Core developer announcements' >>Cc: Inb-tecnico at everest.cnb.uam.es >>Subject: [MOBY-dev] Perl function for object tree >> >> Hi, do you know if is there any easy Perl function >>for obtaining the >>dataType and serviceType ontology in a tree way? >> Thanks in advance, >> >> Antonio. >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Mon Oct 17 12:25:36 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 17 Oct 2005 10:25:36 -0600 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <434A464D.7070203@cnb.uam.es> References: <434A464D.7070203@cnb.uam.es> Message-ID: <4353D080.50701@ucalgary.ca> I have only a couple of suggestions, but I think they may be important: 1. I have a problem with callling all of this Error Handling and having the tag called mobyException, when this mechanism includes not only errors, but also non-fatal warnings and simple information blocks. Perhaps we should call it Execution Status Reporting or something like that? 2. Under "Service Intrinsic Errors", the footnote for 701 states that Blast reporting "No hits found" is a SERVICE_INTERNAL_ERROR. Why is getting no hits an error? Isn't it just a blank response? If I'm designing a sequencing oligo and am checking my oligo against my cloning vector sequence, I want no hits! A MOBY-aware program may see it as an error instead of a response to report... 3. Could we add a few codes to the 700 series "700 OK" (pretty obvious: everything was okay, but we want to provide a formatted info block in the response) "703 Data no longer valid" (once upon a time the data was valid, but no longer: a sequence identifier that has been retracted, a job ticket that is stale, etc.) "704 input invalid" (somehow you escaped the 200 series errors because it is MOBY-correct input, but biologically the input doesn't make sense e.g. an EC number is an object with a String, and that's what you gave us, but the string is HelloWorld, which is not of the form #.#.#.#) "705 data transformed" (e.g. warning: non-DNA chars ignored in DNA search) My CAN$0.02, Paul > The latest version is in the bugzilla > > http://bugzilla.open-bio.org/attachment.cgi?id=233 > > David > > Martin Senger escribi?: > >>> We should also call for a new vote, and perhaps this time simply use >>> the mailing list since the last call for votes only got one response... >>> >>> Let's say October 24th as the final word on this? >>> >>> >> >> Where can I can the latest, official, document describing the latest >> consensus? >> >> Martin >> >> >> >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From carrere at toulouse.inra.fr Tue Oct 18 02:47:24 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue, 18 Oct 2005 08:47:24 +0200 Subject: [MOBY-dev] Hardware upgrade: last programmed interruption - services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <43549A7C.102@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Today evening 8.00 p.m. (GMT+1) till Thursday (October 20th) 9.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Hope this should be the last interruption ... Sorry for inconvenience, Sebastien Carrere _______________________________________________ From senger at ebi.ac.uk Tue Oct 18 13:12:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 18 Oct 2005 18:12:58 +0100 (BST) Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <4353D080.50701@ucalgary.ca> Message-ID: > 1. I have a problem with callling all of this Error Handling and having > the tag called mobyException, when this mechanism includes not only > errors, but also non-fatal warnings and simple information blocks. > I think this was caused by me: I have asked the authors to have there also simple information blocks. I see now that having two places for the same informations (a mobyException tag with a simple information, and the Notes tag) may be confusing. So I am fine with not having the type 'information' there). On the other hand, I think that having warnings in the mobyException is correct (I consider a warning as an exceptional condition). > 2. Under "Service Intrinsic Errors", the footnote for 701 states that > Blast reporting "No hits found" is a SERVICE_INTERNAL_ERROR. Why is > getting no hits an error? > I think that this is an example. Simply it refers to a service that *consider* this situation as exceptionla and errorneus. Your service may feel differently. But if you think that such example is confusing, it is simple to remove it (or to replace is by an another one). > "700 OK" (pretty obvious: everything was okay, but we want to > provide a formatted info block in the response) > But you can always use Notes to fo that withoutr having any exceptionMoby block at all. I am not sure what you want to achiev by this 700 code I must admit. > "703 Data no longer valid" (once upon a time the data was valid, but > no longer: a sequence identifier that has been retracted, a job ticket > that is stale, etc.) > "704 input invalid" (somehow you escaped the 200 series errors > because it is MOBY-correct input, but biologically the input doesn't > make sense e.g. an EC number is an object with a String, and that's what > you gave us, but the string is HelloWorld, which is not of the form #.#.#.#) > "705 data transformed" (e.g. warning: non-DNA chars ignored in DNA > search) > We surely can make more service-specific codes. But I feel that having them is not anyway rich enough - the service providers may specify more details (e.g. yout 704 woulod by better to say why it is invalid; and if not then the code 201 should be used). So I would keep the pre-defined 700 codes at minimum (anyway, what a client can do with them? it simply reports it - there is probably no general way how to send the same request again with the error corrected). I would even remove 701 and rename 702. See below. My additional comments to the latest draft are: * Make sure that upper/lower cases are consistent in attribute names. I notices that refqueryId is spelled both ways as: refQueryId and refqueryId. * I think that we do not need Error code 701. The general failure is reported by 600, and nayhinf more specific can have a concrete service specific code (documented in the service description). * Code 702 is either too generic (so some of 200 codes should be used instead ) or a service provider should be more specific and agin design its specific code and document it. But The example for this code is quite useful - even so useful that I would suggest to add a code for "not-matching namespace" condition (either as a 70x code, or perhaps as a 227 "INPUT_INCORRECT_NAMESPACE". Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Tue Oct 18 16:49:13 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 18 Oct 2005 13:49:13 -0700 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th Message-ID: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Hi all, Eddie and I have been discussing the object ontology migration now that we are not allowing inheritance from primitives. No matter what we do this will break some services, and though I was originally hoping to soften the blow by having a deprecation period, the amount of pain this causes (i.e. everyone having to edit and re-register their services TWICE!) is just inhumane :-) So... I am sure that some of you will cheer this decision, and others will loathe it... we're going to simply migrate the object ontology (in the public MOBY Central here at iCAPTURE) with **no deprecation period at all**. The object names will remain exactly as they are, but will (in some cases) now have different definitions. As such, for those of you running services that are affected by this change, you will only need to update your service code, but NOT need to de/re-register your service. We plan to do this Monday October 24th, so you have a few days to update your services now to reduce the down-time. The way to go about updating your services is as follows: Any XML node that currently has content, but is not a nominal primitive, will now be modified such that it CONTAINS a node that is a primitive, and that primitive will have data content. It's articleName is "content" in every case. e.g. name ACGTGTAGTGCTAGTC ]]> will become name ACGTGTGCTGATGAC ]]> And similarly for Integers, Floats, DateTime, etc. The definition of DateTime will also change, such that it is a primitive, rather than inheriting from String, as it currently does. Eddie has a migration script that will update your mySQL databases automatically. He will make this available on his website (details to follow). Any objections? (don't all yell at once ;-) ) Cheers! Mark -- "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 Pieter.Neerincx at wur.nl Tue Oct 18 17:53:16 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 18 Oct 2005 23:53:16 +0200 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> References: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: <68AE2417-6156-451C-BC4F-27E409EEFDD3@wur.nl> On 18Oct2005, at 22:49, Mark Wilkinson wrote: > Hi all, > > Eddie and I have been discussing the object ontology migration now > that > we are not allowing inheritance from primitives. No matter what we do > this will break some services, and though I was originally hoping to > soften the blow by having a deprecation period, the amount of pain > this > causes (i.e. everyone having to edit and re-register their services > TWICE!) is just inhumane :-) > > So... I am sure that some of you will cheer this decision, Well usually we have drinks on friday afternoon after work, but it looks we'll have to start next week with a small party :). Changing my services was easy, but starting up my brain on tuesday might be a tough one... > and others > will loathe it... we're going to simply migrate the object ontology > (in > the public MOBY Central here at iCAPTURE) with **no deprecation period > at all**. > > .... > > Any objections? (don't all yell at once ;-) ) NO! > Cheers! > > Mark > Cheers, Pieter > > > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Tue Oct 18 18:02:28 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 18 Oct 2005 23:02:28 +0100 (BST) Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: > So... I am sure that some of you will cheer this decision > I am the one who cheers this decision :-) ...but I do not understand what to change/do... :-( For example, there is a chain: text-formatted inherits from text-plain inherits from String Which object definition are you going to change? I guess the 'text-plain', correct? So now text-plain will contain a String under an article-name 'contents'. And the rest of the hierarchy tree will not be changed. Correct? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Tue Oct 18 18:32:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 18 Oct 2005 15:32:44 -0700 Subject: [personal] Re: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: References: Message-ID: <1129674764.7012.4.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-10-18 at 23:02 +0100, Martin Senger wrote: > > So... I am sure that some of you will cheer this decision > > > I am the one who cheers this decision :-) I knew you would :-) > For example, there is a chain: > text-formatted inherits from text-plain inherits from String > Which object definition are you going to change? I guess the > 'text-plain', correct? So now text-plain will contain a String under an > article-name 'contents'. And the rest of the hierarchy tree will > not be changed. Correct? Correct. We are only modifying the first level of objects that formerly inherited from primitives. Any deeper children's definitions will be "updated" by virtue of inheritance, but not by any modification we make to the ontology (similarly for hasa and has relationships). 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 Oct 18 18:32:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 18 Oct 2005 23:32:59 +0100 (BST) Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: Eddie wrote a new article/guide about biomoby in Taverna. You can read it in usual place http://biomoby.org/moby-live/java/docs. The link is named "How to use BioMoby plugin in Taverna". Thanks, Eddie! Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Wed Oct 19 04:50:06 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 19 Oct 2005 10:50:06 +0200 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: References: Message-ID: On 19-Oct-2005, at 12:32 AM, Martin Senger wrote: > Eddie wrote a new article/guide about biomoby in Taverna. You can > read it > in usual place http://biomoby.org/moby-live/java/docs. Ooops, that link fails. Looks like it's running on a *n*x machine where Capitals make a difference. Try http://biomoby.org/moby-live/Java/docs instead :). > The link is named > "How to use BioMoby plugin in Taverna". Thanks, Eddie! One small comment. The info in that document on how to add a scavanger for a BioMOBY Central is outdated. Furthermore if you want to use a custom / local BioMOBY Central you'll have to install some additional servlets that Eddie created. I wrote a doc on how to get a local Taverna-1.3-compatible BioMOBY Central up and running. It's in ~moby-live/Docs/Central/ , but as far as I know this hasn't made it onto the old nor onto the new website yet... moby-live at biomoby.org is all about moby, but it isn't that live :) Cheers, Pieter > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Wed Oct 19 05:04:17 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 19 Oct 2005 10:04:17 +0100 (BST) Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: Message-ID: > Ooops, that link fails. Looks like it's running on a *n*x machine > where Capitals make a difference. Try > http://biomoby.org/moby-live/Java/docs > instead :). > My typo; thanks for correcting my email. > One small comment. The info in that document on how to add a > scavanger for a BioMOBY Central is outdated. Furthermore if you want > to use a custom / local BioMOBY Central you'll have to install some > additional servlets that Eddie created. > Well, this is not a small comment. I hoped that this docs covered everything needed. I must admit that Tom (Oinn) had warned me (the last time as I have spoken with him) that the moby-taverna docs is not fully "in the shape" - but I thought that this nice Eddie's guide solved it. Perhaps, Eddie will update his guide by the missing pieces. I think that important is that we have now a place (a page) that is visible for the jMoby developers (and users) and that can be easily updated. > I wrote a doc on how to get a local Taverna-1.3-compatible BioMOBY > Central up and running. It's in ~moby-live/Docs/Central/ , but as far > as I know this hasn't made it onto the old nor onto the new website > yet... moby-live at biomoby.org is all about moby, but it isn't that > live :) > The jMoby pages are quite active/live (even though not too many authors there - just four of us: Paul, Eddie, Ben and me). If you have a jMoby (Java) related piece of documentation you may consider to add it to moby-live/Java/docs, and to link it from index.html there. It would be great to have more contributors. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Wed Oct 19 08:52:42 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 19 Oct 2005 05:52:42 -0700 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: Message-ID: <000001c5d4ac$0038e800$6500a8c0@notebook> > > One small comment. The info in that document on how to > add a > > scavanger for a BioMOBY Central is outdated. Furthermore > if you want > > to use a custom / local BioMOBY Central you'll have to > install some > > additional servlets that Eddie created. I don't think that this belongs in the how to use Taverna documentation. I guess that it should be mentioned in passing. Eddie > Well, this is not a small comment. I hoped that this > docs covered > everything needed. I must admit that Tom (Oinn) had warned > me (the last > time as I have spoken with him) that the moby-taverna docs > is not fully > "in the shape" - but I thought that this nice Eddie's > guide solved it. > Perhaps, Eddie will update his guide by the missing pieces. > I think that > important is that we have now a place (a page) that is > visible for the > jMoby developers (and users) and that can be easily > updated. > > > > I wrote a doc on how to get a local Taverna-1.3- > compatible BioMOBY > > Central up and running. It's in ~moby- > live/Docs/Central/ , but as far > > as I know this hasn't made it onto the old nor onto the > new website > > yet... moby-live at biomoby.org is all about moby, but > it isn't that > > live :) > > > The jMoby pages are quite active/live (even though not > too many authors > there - just four of us: Paul, Eddie, Ben and me). If you > have a jMoby > (Java) related piece of documentation you may consider to > add it to > moby-live/Java/docs, and to link it from index.html there. > It would be > great to have more contributors. > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Wed Oct 19 19:39:06 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 19 Oct 2005 16:39:06 -0700 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAYOCT 24th In-Reply-To: Message-ID: <001401c5d506$4dccbab0$6500a8c0@notebook> Hi, I have a script that is downloadable from the following address: http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz It goes through your local central and updates the ontology according to the API. Uncompress the contents and take a look at the readme file as it outlines what it does and what it needs from you. If you have any questions, let me know, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Martin > Senger > Sent: Tuesday, October 18, 2005 3:02 PM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [MOBY-dev] Migrating MOBY Central to the new > object API - MONDAYOCT 24th > > > So... I am sure that some of you will cheer this > decision > > > I am the one who cheers this decision :-) > ...but I do not understand what to change/do... :-( > > For example, there is a chain: > text-formatted inherits from text-plain inherits from > String > > Which object definition are you going to change? I > guess the > 'text-plain', correct? So now text-plain will contain a > String under an > article-name 'contents'. And the rest of the hierarchy > tree will > not be changed. Correct? > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Oct 21 05:28:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 21 Oct 2005 11:28:41 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <001201c5d04f$e2e15860$6900a8c0@notebook> References: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: Hi Eddie, On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > Hi Pieter, > > I have uploaded the 2 jar files to > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > There are 2 of them. > > Moreover, I have uploaded some workflows: > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > Test this version out. I believe that I fixed the article > name bug. I have also fixed various other anomalies. > > Let me know how it goes. You're the man! I have been testing for a few days now and so far I haven't been able to spot any anomalies :). Thanks! Pieter > I am going to keep trying to create > workflows that utilize complex Moby datatypes (GeneInfo > comes to mind) to ensure that all is well. > > Thanks a lot, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From aperezp at uma.es Fri Oct 21 07:32:45 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Fri, 21 Oct 2005 13:32:45 +0200 Subject: [MOBY-dev] Parsing Big XML Objects In-Reply-To: Message-ID: <20051021113249.67C0CC0008@correo2.uma.es> Hi, I have parsing moby objects with the getMobySimples function from MobyXmlObject.pm, but when the object is big (>1-2 Mb) the parsing is desperately slow. Do you know if there is a faster way to do this? Thanks in advance, Antonio. From duncan.hull at cs.man.ac.uk Fri Oct 21 07:17:59 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri, 21 Oct 2005 12:17:59 +0100 Subject: [MOBY-dev] new article in jMoby docs: wish list In-Reply-To: References: Message-ID: <4358CE67.9020307@cs.man.ac.uk> Hello Martin Senger wrote: >If you have a jMoby >(Java) related piece of documentation you may consider to add it to >moby-live/Java/docs, and to link it from index.html there. It would be >great to have more contributors. > > > Talking of jMoby documentation, it would be useful* to have some documentation on the graphs client(s): http://biomoby.org/moby-live/Java/docs/CmdLineClients.html#MobyGraphs http://www.ebi.ac.uk/collab/mygrid/service2/jmoby/graphs *maybe only useful for for me though :) Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From rebecca.ernst at gsf.de Fri Oct 21 08:17:41 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri, 21 Oct 2005 14:17:41 +0200 Subject: [MOBY-dev] Migration to new API Message-ID: <4358DC65.3070103@gsf.de> Hi Mark and others! just wanted to let you know that all MIPS services are migrated already. Unfortunately it took us much longer than 5 Minutes because many of our services used objects which inherited indirectly from string (second and more level in the hierarchy) therefore we had to change a lot of services (the part taking most of the time was to find out which services had to be changed!) And we are certainly happy that we don't have to re-register all of them again (*cheering*) !!! 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 carrere at toulouse.inra.fr Fri Oct 21 10:15:08 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Fri, 21 Oct 2005 16:15:08 +0200 Subject: [MOBY-dev] Parsing Big XML Objects In-Reply-To: <20051021113249.67C0CC0008@correo2.uma.es> References: <20051021113249.67C0CC0008@correo2.uma.es> Message-ID: <4358F7EC.6040005@toulouse.inra.fr> Hi, I added the Perl Module (i) we develloped in Toulouse and the mandatory XSLT style-sheet (ii) in the CVS repository to avoid the problem of huge XML messages. i. moby-live/Perl/MOBY/MOBYXSLT.pm ii. moby-live/Perl/MOBY/xsl/parseMobyMessage.xsl This module uses xsltproc to parse XML and builds Perl structures. If you want more information (services examples using this module), do not hesitate. Sebastien Antonio J. P?rez wrote: > Hi, I have parsing moby objects with the getMobySimples function >from MobyXmlObject.pm, but when the object is big (>1-2 Mb) the parsing is >desperately slow. Do you know if there is a faster way to do this? > Thanks in advance, > > Antonio. > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Fri Oct 21 11:53:24 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 21 Oct 2005 08:53:24 -0700 Subject: [moby] Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: References: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: <1129910004.14938.29.camel@bioinfo.icapture.ubc.ca> This is great news - I think we should pass this on to Tom and request a sub-version-release of Taverna now that this is fixed. M On Fri, 2005-10-21 at 11:28 +0200, Pieter Neerincx wrote: > Hi Eddie, > > On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I have uploaded the 2 jar files to > > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > > > There are 2 of them. > > > > Moreover, I have uploaded some workflows: > > > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > > > Test this version out. I believe that I fixed the article > > name bug. I have also fixed various other anomalies. > > > > Let me know how it goes. > > You're the man! I have been testing for a few days now and so far I > haven't been able to spot any anomalies :). > > Thanks! > > Pieter > > > I am going to keep trying to create > > workflows that utilize complex Moby datatypes (GeneInfo > > comes to mind) to ensure that all is well. > > > > Thanks a lot, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "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 edward.kawas at gmail.com Fri Oct 21 11:55:23 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 21 Oct 2005 08:55:23 -0700 Subject: [moby] Re: [MOBY-dev] Taverna plugin bug?: elements missing inBioMOBYobjects In-Reply-To: <1129910004.14938.29.camel@bioinfo.icapture.ubc.ca> Message-ID: <002b01c5d657$d9d6a9b0$6500a8c0@notebook> Last time Pieter said that, within hours he replied that he spoke too soon. Let's wait a little longer ;-) Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Friday, October 21, 2005 8:53 AM > To: Core developer announcements > Subject: Re: [moby] Re: [MOBY-dev] Taverna plugin bug?: > elements missing inBioMOBYobjects > > This is great news - I think we should pass this on to Tom > and request a > sub-version-release of Taverna now that this is fixed. > > M > > > > On Fri, 2005-10-21 at 11:28 +0200, Pieter Neerincx wrote: > > Hi Eddie, > > > > On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > > > > > Hi Pieter, > > > > > > I have uploaded the 2 jar files to > > > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > > > > > There are 2 of them. > > > > > > Moreover, I have uploaded some workflows: > > > > > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > > > > > Test this version out. I believe that I fixed the > article > > > name bug. I have also fixed various other anomalies. > > > > > > Let me know how it goes. > > > > You're the man! I have been testing for a few days now > and so far I > > haven't been able to spot any anomalies :). > > > > Thanks! > > > > Pieter > > > > > I am going to keep trying to create > > > workflows that utilize complex Moby datatypes > (GeneInfo > > > comes to mind) to ensure that all is well. > > > > > > Thanks a lot, > > > > > > Eddie > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Sun Oct 23 14:11:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 23 Oct 2005 19:11:31 +0100 (BST) Subject: [MOBY-dev] new article in jMoby docs: wish list In-Reply-To: <4358CE67.9020307@cs.man.ac.uk> Message-ID: > Talking of jMoby documentation, it would be useful* to have some > documentation on the graphs client(s): > > http://biomoby.org/moby-live/Java/docs/CmdLineClients.html#MobyGraphs > http://www.ebi.ac.uk/collab/mygrid/service2/jmoby/graphs > Good point. I have, still in my TODO list, a bug reported by Ben about this graphs client. I will look at it when I finish my current "project" (a Biomoby dashboard client for service providers). And it that time I will fix also the docs. Promise. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From ed.kawas at gmail.com Tue Oct 25 17:23:35 2005 From: ed.kawas at gmail.com (Eddie Kawas) Date: Tue, 25 Oct 2005 14:23:35 -0700 Subject: [MOBY-dev] Mobycentral has been updated Message-ID: <001e01c5d9aa$5d062a40$6600a8c0@notebook> Hi, Mobycentral has had its object ontology updated, i.e. there no longer exists data types that inherit from primitives. Moreover, if you are interested in updating your ontology, download the migration 'script' from http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz and follow the directions inside the archive. Thanks, Eddie From edward.kawas at gmail.com Tue Oct 25 17:24:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 25 Oct 2005 14:24:09 -0700 Subject: [MOBY-dev] Mobycentral has been updated Message-ID: <001f01c5d9aa$7109c2e0$6600a8c0@notebook> Hi, Mobycentral has had its object ontology updated, i.e. there no longer exists data types that inherit from primitives. Moreover, if you are interested in updating your ontology, download the migration 'script' from http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz and follow the directions inside the archive. Thanks, Eddie From senger at ebi.ac.uk Wed Oct 26 20:38:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 27 Oct 2005 01:38:49 +0100 (BST) Subject: [MOBY-dev] bad LSIDs produced by biomoby registry Message-ID: Eddie & Mark, Could you please fix the LSID creation: the entity name must be 'escaped' if it has characters that are not allowed in the LSID parts, especially colons. An example is a namespace named GOA:hamap that gets LSID: urn:lsid:biomoby.org:namespacetype:GOA:hamap which is, IMHO, wrong. It should be something like: urn:lsid:biomoby.org:namespacetype:GOA_hamap (but obviousy you need to do it in a way that allows you to map back the escaped lsid to the original entity). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Wed Oct 26 18:18:57 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 26 Oct 2005 15:18:57 -0700 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting Message-ID: <002801c5da7b$42e36ac0$6600a8c0@notebook> Hi, I am calling a vote on the RFC that discusses error reporting. Please refer to the following link: http://bugzilla.open-bio.org/show_bug.cgi?id=1863 Thanks. From senger at ebi.ac.uk Wed Oct 26 21:26:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 27 Oct 2005 02:26:14 +0100 (BST) Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > I believe that the casual consensus was that we will carry on votes by email and not in the bugzilla obscure pages. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Thu Oct 27 09:56:28 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 27 Oct 2005 09:56:28 -0400 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> I vote in favour of RFC 1863 (I've added my vote in bugzilla too). Martin, I agree that bugzilla is currently fairly obscure, mostly because nobody has had a reason to go there until recently. However, I think if you hang out there a little, you'll find it's not so inhospitable. It has the advantage of making it much easier to track the history of our decisions. It is also quite a bit easier to associate documents with those decisions, especially as they are revised over time. -Frank At 09:26 PM 10/26/2005, you wrote: > > I am calling a vote on the RFC that discusses error > > reporting. > > > > Please refer to the following link: > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > > I believe that the casual consensus was that we will carry on votes by >email and not in the bugzilla obscure pages. > > Martin > >-- >Martin Senger > email: martin.senger at gmail.com > skype: martinsenger >consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 gordonp at ucalgary.ca Thu Oct 27 10:32:29 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 27 Oct 2005 08:32:29 -0600 Subject: [MOBY-dev] bad LSIDs produced by biomoby registry In-Reply-To: References: Message-ID: <4360E4FD.6090202@ucalgary.ca> As this is a URN, you must use the percent sign hex character encoding for such cases e.g. urn:lsid:biomoby.org:namespacetype:GOA%3Ahamap The implication of course is that a URN resolver should always decode such strings properly. >Eddie & Mark, > Could you please fix the LSID creation: the entity name must be >'escaped' if it has characters that are not allowed in the LSID parts, >especially colons. An example is a namespace named GOA:hamap that gets >LSID: > urn:lsid:biomoby.org:namespacetype:GOA:hamap >which is, IMHO, wrong. It should be something like: > urn:lsid:biomoby.org:namespacetype:GOA_hamap >(but obviousy you need to do it in a way that allows you to map >back the escaped lsid to the original entity). > > Cheers, > Martin > > > From gordonp at ucalgary.ca Thu Oct 27 10:32:29 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 27 Oct 2005 08:32:29 -0600 Subject: [MOBY-dev] bad LSIDs produced by biomoby registry In-Reply-To: References: Message-ID: <4360E4FD.6090202@ucalgary.ca> As this is a URN, you must use the percent sign hex character encoding for such cases e.g. urn:lsid:biomoby.org:namespacetype:GOA%3Ahamap The implication of course is that a URN resolver should always decode such strings properly. >Eddie & Mark, > Could you please fix the LSID creation: the entity name must be >'escaped' if it has characters that are not allowed in the LSID parts, >especially colons. An example is a namespace named GOA:hamap that gets >LSID: > urn:lsid:biomoby.org:namespacetype:GOA:hamap >which is, IMHO, wrong. It should be something like: > urn:lsid:biomoby.org:namespacetype:GOA_hamap >(but obviousy you need to do it in a way that allows you to map >back the escaped lsid to the original entity). > > Cheers, > Martin > > > From markw at illuminae.com Mon Oct 3 17:16:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Oct 2005 10:16:09 -0700 Subject: [MOBY-dev] TWiki taken offline Message-ID: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> Hi all, I've decided to take the TWiki down after several recent serious security alerts that would require installation of a newer version (and installation of TWiki is not something I can do with my left hand, unfortunately... it's a bit ugly!) Since we're moving to the new website anyway, I don't see the point in the investment of time on the old one. I will continue to move documents over to the new site as I get the chance. Others are welcome to help :-) If there is anything on the TWiki that you need urgently, let me know and I'll make the document available some other way. 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 Pieter.Neerincx at wur.nl Tue Oct 4 12:43:47 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 14:43:47 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects Message-ID: <060DD7A8-411D-4F92-A5F3-A8EC7E33D536@wur.nl> Hi Eddie et al. Now that I have my local BioMOBY Central up and running I'd love to run some worksflows, but I think I ran into a bug. When I select BioMOBY objects and add them to a workflow all necessary processors for the child elements/objects are added as well. So far so good. But when I run a workflow, some of the child elements for the objects are missing from the object that is send to a service. Here's an example: If I have a nested structure like this: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Root_Moby_Object moby:My_Child_Level_1A moby:My_Child_Level_1B moby:My_Child_Level_2A moby:My_Child_Level_2B moby:My_Child_Level_1C moby:My_Child_Level_1D moby:My_Child_Level_2A moby:My_Child_Level_3A moby:My_Child_Level_1E * The MyRootMobyObject can have many ChildLevel1 elements. That's fine. * However if the ChildLevel1 elements have childs, they might be missing from the object that is send to a service. Some will be there, others will be missing. I tried to find a pattern, but I couldn't. So whether there is 1 or more elements added at level 2, whether they have an articleName or not, whether they have a namespace or not, etc. doesn't seem to make a difference. I also tried the official BioMOBY central: same result. I also tried the freshly released Taverna 1.3 today: same result again. So when I look in Taverna at the intermediate inputs and outputs for the different processors I see the following structures: The input for the service = the intermediate output of the processor that created MyRootMobyObject contains: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Root_Moby_Object moby:My_Child_Level_1A moby:My_Child_Level_1B moby:My_Child_Level_1C moby:My_Child_Level_1D moby:My_Child_Level_1E The intermediate input for the processor that created MyRootMobyObject = the intermediate output of the processor that created MyChildLevel1B contains: moby:MOBY moby:Content moby:Data moby:Simple moby:My_Child_Level_1B moby:My_Child_Level_2A moby:My_Child_Level_2B So that one looks fine, but when My_Child_Level_1B is appended to My_Root_Moby_Object, the children of My_Child_Level_1B are lost :(. I do not get any errors or scary log lines apart from my service complaining that some elements are missing from the input. Any idea what is messing up the fun? Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jpsanchez at isciii.es Tue Oct 4 13:00:59 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 15:00:59 +0200 Subject: Autoreply: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 13:44:55 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 06:44:55 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: <060DD7A8-411D-4F92-A5F3-A8EC7E33D536@wur.nl> Message-ID: <000c01c5c8e9$cffac320$6500a8c0@notebook> > moby:MOBY > moby:Content > moby:Data > moby:Simple > moby:My_Child_Level_1B > moby:My_Child_Level_2A > moby:My_Child_Level_2B > Do you have an example of an object that has this type of structure? Thanks, Eddie From jpsanchez at isciii.es Tue Oct 4 14:49:22 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 16:49:22 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 15:06:37 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 17:06:37 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: <000c01c5c8e9$cffac320$6500a8c0@notebook> References: <000c01c5c8e9$cffac320$6500a8c0@notebook> Message-ID: On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >> moby:MOBY >> moby:Content >> moby:Data >> moby:Simple >> moby:My_Child_Level_1B >> moby:My_Child_Level_2A >> moby:My_Child_Level_2B >> >> > > Do you have an example of an object that has this type of > structure? Yes, try for example DnaSequenceHolder from the BioMOBY Central. I have been running some other tests in the mean time and so far almost every object I tried lacks child elements at level 2 or further down. The only one that does have an element at level 2 is the BlastJob object I have in my local Central. This one has Strings, Objects and a DataTime at level 2 or further down. Everything is missing except the DataTime primitive... I noticed that hardly anyone is using the DataTime primitive if I'm not the only one using. It is also hardly documented. Maybe it's just random noise in my testing or maybe I'm onto something.... If you want to try the BlastJob object my local registry should still be accessible from outside at: http://137.224.52.237/phenolink/biomoby/central/cgi-bin/MOBY-Central.pl Hope this helps, Pi > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jpsanchez at isciii.es Tue Oct 4 15:13:02 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 17:13:02 +0200 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 15:12:29 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 08:12:29 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: Message-ID: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> No you are on to something! When I first created the plugin, I used a certain xml parser based on w3c dom. I had to switch to another parser and it seems that I was unaware of its limitations (getChildren only gets the direct children of an element). I will have this fixed fairly soon. 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 Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:07 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > > >> moby:MOBY > >> moby:Content > >> moby:Data > >> moby:Simple > >> moby:My_Child_Level_1B > >> moby:My_Child_Level_2A > >> moby:My_Child_Level_2B > >> > >> > > > > Do you have an example of an object that has this type > of > > structure? > > Yes, try for example DnaSequenceHolder from the BioMOBY > Central. > > I have been running some other tests in the mean time and > so far > almost every object I tried lacks child elements at level > 2 or > further down. The only one that does have an element at > level 2 is > the BlastJob object I have in my local Central. This one > has Strings, > Objects and a DataTime at level 2 or further down. > Everything is > missing except the DataTime primitive... I noticed that > hardly anyone > is using the DataTime primitive if I'm not the only one > using. It is > also hardly documented. Maybe it's just random noise in my > testing or > maybe I'm onto something.... > > If you want to try the BlastJob object my local registry > should still > be accessible from outside at: > http://137.224.52.237/phenolink/biomoby/central/cgi- > bin/MOBY-Central.pl > > Hope this helps, > > Pi > > > Thanks, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From simont at mcw.edu Tue Oct 4 15:17:20 2005 From: simont at mcw.edu (Twigger Simon) Date: Tue, 4 Oct 2005 10:17:20 -0500 Subject: [MOBY-dev] TWiki taken offline In-Reply-To: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> References: <1128359769.25592.19.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, There do appear to be some Wiki plugins for wordpress so in theory we could implement something similar over there. I could install it and we could play with it for a while... S. On Oct 3, 2005, at 12:16 PM, Mark Wilkinson wrote: > Hi all, > > I've decided to take the TWiki down after several recent serious > security alerts that would require installation of a newer version > (and > installation of TWiki is not something I can do with my left hand, > unfortunately... it's a bit ugly!) Since we're moving to the new > website anyway, I don't see the point in the investment of time on the > old one. > > I will continue to move documents over to the new site as I get the > chance. Others are welcome to help :-) > > If there is anything on the TWiki that you need urgently, let me know > and I'll make the document available some other way. > > 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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From jpsanchez at isciii.es Tue Oct 4 15:51:22 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 17:51:22 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 15:46:59 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 17:46:59 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBY objects In-Reply-To: References: <000c01c5c8e9$cffac320$6500a8c0@notebook> Message-ID: <0C17CCE2-4EC0-42BE-926A-89B14004BAF3@wur.nl> Hi Eddie, I found another interesting example. In this case I didn't loose any child elements, but they got appended to the wrong parent element ??? TropGENE_ACESSION TropGENE_LOCUS TropGENE_ALLELE TropGENE_LINKAGE_GROUP TropGENE_MAP_POSITION If I use the object above I get as input for a service: TropGENE_ACESSION TropGENE_LOCUS TropGENE_ALLELE TropGENE_MAP_POSITION TropGENE_LINKAGE_GROUP Hence, the TropGENE_MAP_POSITION is appended to the wrong child. The intermediate output of the processor that creates TropGENE_LINKAGE_GROUP seems to be fine, but when TropGENE_LINKAGE_GROUP is appended to TropGENE_LOCUS, the TropGENE_MAP_POSITION element jumps from the TropGENE_LINKAGE_GROUP to the TropGENE_ALLELE element... Regards, Pieter From jpsanchez at isciii.es Tue Oct 4 15:58:03 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 17:58:03 +0200 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From Pieter.Neerincx at wur.nl Tue Oct 4 16:03:59 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 4 Oct 2005 18:03:59 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> References: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> Message-ID: <71484B4E-298B-4423-BF74-D968B86E644B@wur.nl> On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: > No you are on to something! When I first created the plugin, > I used a certain xml parser based on w3c dom. I had to > switch to another parser and it seems that I was unaware of > its limitations (getChildren only gets the direct children > of an element). > > I will have this fixed fairly soon. I'm looking forward to "testdrive" it :) Thanks, Pieter > > 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 Pieter >> Neerincx >> Sent: Tuesday, October 04, 2005 8:07 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> >> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >> >> >>>> moby:MOBY >>>> moby:Content >>>> moby:Data >>>> moby:Simple >>>> moby:My_Child_Level_1B >>>> moby:My_Child_Level_2A >>>> moby:My_Child_Level_2B >>>> >>>> >>>> >>> >>> Do you have an example of an object that has this type >>> >> of >> >>> structure? >>> >> >> Yes, try for example DnaSequenceHolder from the BioMOBY >> Central. >> >> I have been running some other tests in the mean time and >> so far >> almost every object I tried lacks child elements at level >> 2 or >> further down. The only one that does have an element at >> level 2 is >> the BlastJob object I have in my local Central. This one >> has Strings, >> Objects and a DataTime at level 2 or further down. >> Everything is >> missing except the DataTime primitive... I noticed that >> hardly anyone >> is using the DataTime primitive if I'm not the only one >> using. It is >> also hardly documented. Maybe it's just random noise in my >> testing or >> maybe I'm onto something.... >> >> If you want to try the BlastJob object my local registry >> should still >> be accessible from outside at: >> http://137.224.52.237/phenolink/biomoby/central/cgi- >> bin/MOBY-Central.pl >> >> Hope this helps, >> >> Pi >> >> >>> Thanks, >>> >>> Eddie >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jpsanchez at isciii.es Tue Oct 4 16:04:48 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 18:04:48 +0200 Subject: Autoreply: Re: [MOBY-dev] TWiki taken offline Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From jpsanchez at isciii.es Tue Oct 4 16:13:00 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 18:13:00 +0200 Subject: Autoreply: Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 17:00:50 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 10:00:50 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <0C17CCE2-4EC0-42BE-926A-89B14004BAF3@wur.nl> Message-ID: <000e01c5c905$2eb83210$6500a8c0@notebook> Hi Pieter, I was wondering if you had a workflow that you use to build the object and run it with a Moby service. If you have one, do you think that you could email it to me? 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 Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > I found another interesting example. In this case I didn't > loose any > child elements, but they got appended to the wrong parent > element ??? > > TropGENE_ACESSION > TropGENE_LOCUS > TropGENE_ALLELE > TropGENE_LINKAGE_GROUP > TropGENE_MAP_POSITION > > If I use the object above I get as input for a service: > > TropGENE_ACESSION > TropGENE_LOCUS > TropGENE_ALLELE > TropGENE_MAP_POSITION > TropGENE_LINKAGE_GROUP > > Hence, the TropGENE_MAP_POSITION is appended to the wrong > child. The > intermediate output of the processor that creates > TropGENE_LINKAGE_GROUP seems to be fine, but when > TropGENE_LINKAGE_GROUP is appended to TropGENE_LOCUS, the > TropGENE_MAP_POSITION element jumps from the > TropGENE_LINKAGE_GROUP > to the TropGENE_ALLELE element... > > Regards, > > Pieter > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 17:32:39 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 19:32:39 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 15:12:29 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 08:12:29 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: Message-ID: <000d01c5c8f6$0b90dbc0$6500a8c0@notebook> No you are on to something! When I first created the plugin, I used a certain xml parser based on w3c dom. I had to switch to another parser and it seems that I was unaware of its limitations (getChildren only gets the direct children of an element). I will have this fixed fairly soon. 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 Pieter > Neerincx > Sent: Tuesday, October 04, 2005 8:07 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > > >> moby:MOBY > >> moby:Content > >> moby:Data > >> moby:Simple > >> moby:My_Child_Level_1B > >> moby:My_Child_Level_2A > >> moby:My_Child_Level_2B > >> > >> > > > > Do you have an example of an object that has this type > of > > structure? > > Yes, try for example DnaSequenceHolder from the BioMOBY > Central. > > I have been running some other tests in the mean time and > so far > almost every object I tried lacks child elements at level > 2 or > further down. The only one that does have an element at > level 2 is > the BlastJob object I have in my local Central. This one > has Strings, > Objects and a DataTime at level 2 or further down. > Everything is > missing except the DataTime primitive... I noticed that > hardly anyone > is using the DataTime primitive if I'm not the only one > using. It is > also hardly documented. Maybe it's just random noise in my > testing or > maybe I'm onto something.... > > If you want to try the BlastJob object my local registry > should still > be accessible from outside at: > http://137.224.52.237/phenolink/biomoby/central/cgi- > bin/MOBY-Central.pl > > Hope this helps, > > Pi > > > Thanks, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 17:48:22 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 19:48:22 +0200 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From francis_gibbons at hms.harvard.edu Tue Oct 4 18:38:29 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 04 Oct 2005 14:38:29 -0400 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Message-ID: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Hi, I'm trying to deregister some services originally created about a year ago. At the time I used the MOBY-S Perl API to do the job. Then Mark told us to go to a page which would generate RDF for us, which I dutifully did. But then the agent never really seemed to go into use. I threw away the RDF file, but my services remain registered; problem is, I can't deregister them using the API either. So they're currently immortal zombie services: they just won't die. That's a problem because I initially put up a number of services which were limited. Now that I'm older and wiser ;-), I'd like to rework them, but can't. I really don't want to create more services, since they more or less duplicate, but not exactly, the function of the existing ones. I simply want to revamp the existing ones. Can anyone tell me how I can do it? -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 jpsanchez at isciii.es Tue Oct 4 18:42:21 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 20:42:21 +0200 Subject: Autoreply: [MOBY-dev] Can't deregister services originally registered throughmethods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From edward.kawas at gmail.com Tue Oct 4 19:12:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 12:12:09 -0700 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <000001c5c917$85a34df0$6500a8c0@notebook> Hi Frank, You can't remove a service if you specified a signature url. With that being said, if you give me the servicenames and authority of the services that you would like to remove, I can 'erase' the signature url and then you can remove them. Does this sound good to you? And to confirm, you are talking about services registered in the default Mobycentral registry? Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Frank > Gibbons > Sent: Tuesday, October 04, 2005 11:38 AM > To: MOBY-dev at biomoby.org > Subject: [MOBY-dev] Can't deregister services originally > registered through methods, then converted to RDF > > Hi, > > I'm trying to deregister some services originally created > about a year ago. > At the time I used the MOBY-S Perl API to do the job. Then > Mark told us to > go to a page which would generate RDF for us, which I > dutifully did. But > then the agent never really seemed to go into use. I threw > away the RDF > file, but my services remain registered; problem is, I > can't deregister > them using the API either. So they're currently immortal > zombie services: > they just won't die. > > That's a problem because I initially put up a number of > services which were > limited. Now that I'm older and wiser ;-), I'd like to > rework them, but > can't. I really don't want to create more services, since > they more or less > duplicate, but not exactly, the function of the existing > ones. I simply > want to revamp the existing ones. > > Can anyone tell me how I can do it? > > -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-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jpsanchez at isciii.es Tue Oct 4 19:17:28 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 21:17:28 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From markw at illuminae.com Tue Oct 4 19:15:02 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 4 Oct 2005 19:15:02 +0000 GMT Subject: [MOBY-dev] Can't deregister services originally registered throughmethods, then converted to RDF Message-ID: <281305509-1128453358-cardhu_blackberry.rim.net-7785-@engine10-cell01> Hi Frank - give me a minute and I'll delete your signatureRDF's. The delay in the agent is due to our decision to synchronize our data models with myGrid, but that's takint longer than expected. I'll do it now, M -----Original Message----- From: Frank Gibbons Date: Tue, 04 Oct 2005 14:38:29 To:MOBY-dev at biomoby.org Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Hi, I'm trying to deregister some services originally created about a year ago. At the time I used the MOBY-S Perl API to do the job. Then Mark told us to go to a page which would generate RDF for us, which I dutifully did. But then the agent never really seemed to go into use. I threw away the RDF file, but my services remain registered; problem is, I can't deregister them using the API either. So they're currently immortal zombie services: they just won't die. That's a problem because I initially put up a number of services which were limited. Now that I'm older and wiser ;-), I'd like to rework them, but can't. I really don't want to create more services, since they more or less duplicate, but not exactly, the function of the existing ones. I simply want to revamp the existing ones. Can anyone tell me how I can do it? -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-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Tue Oct 4 19:16:08 2005 From: markw at illuminae.com (mark wilkinson) Date: Tue, 4 Oct 2005 19:16:08 +0000 GMT Subject: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: <1190951208-1128453424-cardhu_blackberry.rim.net-5001-@engine13-cell01> Eddie please do this. It will be easier for you to do it than for me to do it by ssh on my blackberry :-) Hello from the Biomoby scientific defense/review! Wish me luck!!! M -----Original Message----- From: "Edward Kawas" Date: Tue, 4 Oct 2005 12:12:09 To:"'Core developer announcements'" Subject: RE: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF Hi Frank, You can't remove a service if you specified a signature url. With that being said, if you give me the servicenames and authority of the services that you would like to remove, I can 'erase' the signature url and then you can remove them. Does this sound good to you? And to confirm, you are talking about services registered in the default Mobycentral registry? Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Frank > Gibbons > Sent: Tuesday, October 04, 2005 11:38 AM > To: MOBY-dev at biomoby.org > Subject: [MOBY-dev] Can't deregister services originally > registered through methods, then converted to RDF > > Hi, > > I'm trying to deregister some services originally created > about a year ago. > At the time I used the MOBY-S Perl API to do the job. Then > Mark told us to > go to a page which would generate RDF for us, which I > dutifully did. But > then the agent never really seemed to go into use. I threw > away the RDF > file, but my services remain registered; problem is, I > can't deregister > them using the API either. So they're currently immortal > zombie services: > they just won't die. > > That's a problem because I initially put up a number of > services which were > limited. Now that I'm older and wiser ;-), I'd like to > rework them, but > can't. I really don't want to create more services, since > they more or less > duplicate, but not exactly, the function of the existing > ones. I simply > want to revamp the existing ones. > > Can anyone tell me how I can do it? > > -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-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Tue Oct 4 19:25:11 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 12:25:11 -0700 Subject: [MOBY-dev] Can't deregister services originally registeredthroughmethods, then converted to RDF In-Reply-To: <1190951208-1128453424-cardhu_blackberry.rim.net-5001-@engine13-cell01> Message-ID: <000101c5c919$57a73b30$6500a8c0@notebook> Good luck Mark!!! I will do it right away! Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of mark > wilkinson > Sent: Tuesday, October 04, 2005 12:16 PM > To: Core developer announcements > Subject: Re: [MOBY-dev] Can't deregister services > originally registeredthroughmethods, then converted to RDF > > Eddie please do this. It will be easier for you to do it > than for me to do it by ssh on my blackberry :-) > > Hello from the Biomoby scientific defense/review! Wish me > luck!!! > > M > > > -----Original Message----- > From: "Edward Kawas" > Date: Tue, 4 Oct 2005 12:12:09 > To:"'Core developer announcements'" bio.org> > Subject: RE: [MOBY-dev] Can't deregister services > originally registered > through methods, then converted to RDF > > Hi Frank, > > You can't remove a service if you specified a signature > url. > With that being said, if you give me the servicenames and > authority of the services that you would like to remove, I > can 'erase' the signature url and then you can remove them. > > Does this sound good to you? And to confirm, you are > talking > about services registered in the default Mobycentral > registry? > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of Frank > > Gibbons > > Sent: Tuesday, October 04, 2005 11:38 AM > > To: MOBY-dev at biomoby.org > > Subject: [MOBY-dev] Can't deregister services originally > > registered through methods, then converted to RDF > > > > Hi, > > > > I'm trying to deregister some services originally > created > > about a year ago. > > At the time I used the MOBY-S Perl API to do the job. > Then > > Mark told us to > > go to a page which would generate RDF for us, which I > > dutifully did. But > > then the agent never really seemed to go into use. I > threw > > away the RDF > > file, but my services remain registered; problem is, I > > can't deregister > > them using the API either. So they're currently immortal > > zombie services: > > they just won't die. > > > > That's a problem because I initially put up a number of > > services which were > > limited. Now that I'm older and wiser ;-), I'd like to > > rework them, but > > can't. I really don't want to create more services, > since > > they more or less > > duplicate, but not exactly, the function of the existing > > ones. I simply > > want to revamp the existing ones. > > > > Can anyone tell me how I can do it? > > > > -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-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Tue Oct 4 19:35:19 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 12:35:19 -0700 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <000201c5c91a$c1f99860$6500a8c0@notebook> Hi Frank, I set your signature URLS, with contact email fgibbons @ hms.harvard.edu, to NULL. You should now be able to remove your services. Eddie From jpsanchez at isciii.es Tue Oct 4 19:36:19 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 21:36:19 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originallyregisteredthroughmethods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From jpsanchez at isciii.es Tue Oct 4 19:39:54 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 21:39:54 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From francis_gibbons at hms.harvard.edu Tue Oct 4 19:42:35 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 04 Oct 2005 15:42:35 -0400 Subject: [MOBY-dev] Can't deregister services originally registered through methods, then converted to RDF In-Reply-To: <000001c5c917$85a34df0$6500a8c0@notebook> References: <5.2.1.1.2.20051004143307.01123b50@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051004153438.01190d18@email.med.harvard.edu> Hi Eddie. Yeah, I know that I'm not supposed to be able to remove a service through the API if I have a signature URL. But that sort of assumes that there's an agent looking for RDF at the signature URL, and continuously updating the service registry. It's not meant to be that you can *never* remove a service that has a signature URL, right? I guess you meant that if it has a signature URL in the database, then it's not supposed to be deletable - well, it's still the same situation for me, since I don't think I can change the signature URL in the database, once the service is registered. Anyway, as per Mark's recent message, I'd really appreciate it if you could remove the signature URL for the following services: ASimpleService YAService DBI_CSV The authority is llama.med.harvard.edu They're all in the default registry. If I understand correctly, once you delete the signature URL from the database, then I should be able to delete them using the Perl API function call - correct? That would be awsome. Thanks a lot, -Frank At 03:12 PM 10/4/2005, you wrote: >Hi Frank, > >You can't remove a service if you specified a signature url. >With that being said, if you give me the servicenames and >authority of the services that you would like to remove, I >can 'erase' the signature url and then you can remove them. > >Does this sound good to you? And to confirm, you are talking >about services registered in the default Mobycentral >registry? > >Eddie > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of Frank > > Gibbons > > Sent: Tuesday, October 04, 2005 11:38 AM > > To: MOBY-dev at biomoby.org > > Subject: [MOBY-dev] Can't deregister services originally > > registered through methods, then converted to RDF > > > > Hi, > > > > I'm trying to deregister some services originally created > > about a year ago. > > At the time I used the MOBY-S Perl API to do the job. Then > > Mark told us to > > go to a page which would generate RDF for us, which I > > dutifully did. But > > then the agent never really seemed to go into use. I threw > > away the RDF > > file, but my services remain registered; problem is, I > > can't deregister > > them using the API either. So they're currently immortal > > zombie services: > > they just won't die. > > > > That's a problem because I initially put up a number of > > services which were > > limited. Now that I'm older and wiser ;-), I'd like to > > rework them, but > > can't. I really don't want to create more services, since > > they more or less > > duplicate, but not exactly, the function of the existing > > ones. I simply > > want to revamp the existing ones. > > > > Can anyone tell me how I can do it? > > > > -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-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 jpsanchez at isciii.es Tue Oct 4 19:44:33 2005 From: jpsanchez at isciii.es (jpsanchez at isciii.es) Date: Tue, 4 Oct 2005 21:44:33 +0200 Subject: Autoreply: RE: [MOBY-dev] Can't deregister services originally registeredthrough methods, then converted to RDF Message-ID: Hola, He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. From gordonp at ucalgary.ca Tue Oct 4 20:03:52 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 04 Oct 2005 14:03:52 -0600 Subject: Autoreply: RE: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: References: Message-ID: <4342E028.2040806@ucalgary.ca> Next time we have a MOBY meeting, Juan is buying us all a round of beer as punishment for setting autoreplies on mailing list messages... >Hola, >He cambiado de trabajo, por lo tanto esta direcci?n ser? dada de baja pr?ximamente. >Si necesitas contactar conmigo, puedes escribirme a juanpedrinyo at gmail.com. > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From edward.kawas at gmail.com Wed Oct 5 00:52:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 4 Oct 2005 17:52:09 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <71484B4E-298B-4423-BF74-D968B86E644B@wur.nl> Message-ID: <001101c5c947$04dfbd40$6500a8c0@notebook> Hi Pieter! I tracked down the bug and I fixed it (*fingers crossed*). I am placing 2 jar files at the following links that need to replace the ones in your /taverna-workbench-1.3/lib/ directory: http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar Be sure to backup the 2 files you are about to replace, just in case! Then try out your workflows and let me know what happens. Also, if all is well, do you think that you could send me one of those workflows so I can use it as an example? Thanks a lot, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Tuesday, October 04, 2005 9:04 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > > On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: > > > No you are on to something! When I first created the > plugin, > > I used a certain xml parser based on w3c dom. I had to > > switch to another parser and it seems that I was unaware > of > > its limitations (getChildren only gets the direct > children > > of an element). > > > > I will have this fixed fairly soon. > > I'm looking forward to "testdrive" it :) > > Thanks, > > Pieter > > > > > 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 Pieter > >> Neerincx > >> Sent: Tuesday, October 04, 2005 8:07 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > >> missing in BioMOBYobjects > >> > >> > >> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: > >> > >> > >>>> moby:MOBY > >>>> moby:Content > >>>> moby:Data > >>>> moby:Simple > >>>> moby:My_Child_Level_1B > >>>> moby:My_Child_Level_2A > >>>> moby:My_Child_Level_2B > >>>> > >>>> > >>>> > >>> > >>> Do you have an example of an object that has this type > >>> > >> of > >> > >>> structure? > >>> > >> > >> Yes, try for example DnaSequenceHolder from the BioMOBY > >> Central. > >> > >> I have been running some other tests in the mean time > and > >> so far > >> almost every object I tried lacks child elements at > level > >> 2 or > >> further down. The only one that does have an element at > >> level 2 is > >> the BlastJob object I have in my local Central. This > one > >> has Strings, > >> Objects and a DataTime at level 2 or further down. > >> Everything is > >> missing except the DataTime primitive... I noticed that > >> hardly anyone > >> is using the DataTime primitive if I'm not the only one > >> using. It is > >> also hardly documented. Maybe it's just random noise in > my > >> testing or > >> maybe I'm onto something.... > >> > >> If you want to try the BlastJob object my local > registry > >> should still > >> be accessible from outside at: > >> http://137.224.52.237/phenolink/biomoby/central/cgi- > >> bin/MOBY-Central.pl > >> > >> Hope this helps, > >> > >> Pi > >> > >> > >>> Thanks, > >>> > >>> Eddie > >>> > >>> _______________________________________________ > >>> MOBY-dev mailing list > >>> MOBY-dev at biomoby.org > >>> http://www.biomoby.org/mailman/listinfo/moby-dev > >>> > >>> > >> > >> > >> Wageningen University and Research centre (WUR) > >> Laboratory of Bioinformatics > >> Transitorium (building 312) room 1034 > >> Dreijenlaan 3 > >> 6703 HA Wageningen > >> The Netherlands > >> phone: 0317-483 060 > >> fax: 0317-483 584 > >> mobile: 06-143 66 783 > >> pieter.neerincx at wur.nl > >> > >> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Thu Oct 6 15:32:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 6 Oct 2005 17:32:41 +0200 Subject: [MOBY-dev] Migration of database to new API In-Reply-To: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > Hi all, > > As we move toward deploying the new API, there are some serious > consequences on the underlying databases. > > Let me first re-cap the new API features that I am discussing and what > effects they have on the databases: > > 1) Inheritence from primitives through ISA relationships is no longer > allowed. e.g. plain-text ISA String is no longer allowed. To > achieve > the same result, you now create an object that inherits from Object > and > contains the primitive. e.g. plain-text ISA Object; plain-text HASA > String. Hi Mark et al., Any idea when this change will happen? If I look in the Central that is running the latest and greatest codebase, the forbidden ISA [some primitive] relationships are still in place :(. What is even worse is that the primitive DateTime ISA String. As a result I can not get one of my Objects (that plays by the rules of the latest specs) registered. At least I suspect this to be the problem. I don't get an error message when register my object, but it has amongst others a HASA DataTime and that relationship is not getting registered... Cheers, Pi Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Thu Oct 6 16:08:10 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Oct 2005 09:08:10 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> Message-ID: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> As you have noticed, the change has already happened at the code level just to prevent any more registrations of what will soon be illegal objects. I have a script that will update the database records of the ontologies and deprecate the old nodes, but we haven't yet run it on the public registry. Eddie is going to make a couple of changes to it over the next day or two, and then will send out a heads-up that the ontologies are changing forever, and a tutorial on how to do the update for service providers. We'll give a reasonable amount of time for people to update their services (say, 6 weeks) and then we will delete the old nodes from the ontology completely. The script is in the CVS so anyone running a registry can do the same thing. When I went to update my own services it took me less than 5 minutes to do so, so 6 weeks should be more than enough time for anyone who is actively concerned about their service :-) Cheers! M On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > Hi all, > > > > As we move toward deploying the new API, there are some serious > > consequences on the underlying databases. > > > > Let me first re-cap the new API features that I am discussing and what > > effects they have on the databases: > > > > 1) Inheritence from primitives through ISA relationships is no longer > > allowed. e.g. plain-text ISA String is no longer allowed. To > > achieve > > the same result, you now create an object that inherits from Object > > and > > contains the primitive. e.g. plain-text ISA Object; plain-text HASA > > String. > > Hi Mark et al., > > Any idea when this change will happen? If I look in the Central that > is running the latest and greatest codebase, the forbidden ISA [some > primitive] relationships are still in place :(. What is even worse is > that the primitive DateTime ISA String. As a result I can not get one > of my Objects (that plays by the rules of the latest specs) > registered. At least I suspect this to be the problem. I don't get an > error message when register my object, but it has amongst others a > HASA DataTime and that relationship is not getting registered... > > Cheers, > > Pi > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "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 Thu Oct 6 21:39:45 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Oct 2005 14:39:45 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <000101c5cab8$549b3c20$6500a8c0@notebook> References: <000101c5cab8$549b3c20$6500a8c0@notebook> Message-ID: <1128634785.1179.111.camel@bioinfo.icapture.ubc.ca> It's not just that, it's also the "spirit" of the matter. e.g. our LSID's are based on the name of the object. Granted, we currently only return metadata, so we could in principle re-define the object without breaking the LSID standard, but it does break the "spirit" of the identifier. But having said that, I don't particularly care one way or the other. It's painful no matter what we do. 1) If we change to _2, deprecate the old ones, and after 6 weeks delete the old, leaving the _2's in their place then: a) people who are affected will have to update their servces b) people will have to re-register their services 2) If we change to _2 temporarily, deprecate, delete, and then rename the _2's back again after 6 weeks: a) people affected will have to either i) update their services, re-register, then ii) update their services again and re-register OR i) update their services and NOT re-register, and ii) their services will be "illegal" for 6 weeks, There's no painless way to do this, so whatever the community feels is best... M On Thu, 2005-10-06 at 13:55 -0700, Edward Kawas wrote: > Hi, > > I am working on this script right now as we speak, but I > just wanted to get feedback (for a second time). > > >From what I understand, I am going to go through the > ontology, and deprecate any data type that inherits from a > primitive. Any object that I deprecate will be duplicated > and have an _2 appended to its name as well as having its > ISA relationship set to object and adding a HASA primitive > relationship. So far so good. > > In six weeks, I am going to go through the ontology and > remove all objects that inherit from a primitive, leaving > those that were duplicated with an _2 alone. Therefore, in 6 > weeks, we will have objects like text-plain_2, text-xml_2, > etc. > > I know that some people are fine with this and others are > not. Some might not even care. However, what I want to know > is what MOBYers think and if anyone has any other > comments/suggestions. So please let me know. > > Just to get this started, I am still pretty iffy about > leaving x_2 data types in the ontology. I do see Marks point > on how services that are not updated choking since they > expect the data type to inherit from a primitive. Any ideas? > > Thanks, > > Eddie > > > -----Original Message----- > > From: Mark Wilkinson [mailto:markw at illuminae.com] > > Sent: Thursday, October 06, 2005 9:08 AM > > To: Core developer announcements > > Cc: Eddie Kawas > > Subject: Re: [moby] Re: [MOBY-dev] Migration of database > > to new API > > > > As you have noticed, the change has already happened at > > the code level > > just to prevent any more registrations of what will soon > > be illegal > > objects. I have a script that will update the database > > records of the > > ontologies and deprecate the old nodes, but we haven't yet > > run it on the > > public registry. Eddie is going to make a couple of > > changes to it over > > the next day or two, and then will send out a heads-up > > that the > > ontologies are changing forever, and a tutorial on how to > > do the update > > for service providers. We'll give a reasonable amount of > > time for > > people to update their services (say, 6 weeks) and then we > > will delete > > the old nodes from the ontology completely. The script is > > in the CVS so > > anyone running a registry can do the same thing. > > > > When I went to update my own services it took me less than > > 5 minutes to > > do so, so 6 weeks should be more than enough time for > > anyone who is > > actively concerned about their service :-) > > > > Cheers! > > > > M > > > > > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > > > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > > > > > Hi all, > > > > > > > > As we move toward deploying the new API, there are > > some serious > > > > consequences on the underlying databases. > > > > > > > > Let me first re-cap the new API features that I am > > discussing and what > > > > effects they have on the databases: > > > > > > > > 1) Inheritence from primitives through ISA > > relationships is no longer > > > > allowed. e.g. plain-text ISA String is no longer > > allowed. To > > > > achieve > > > > the same result, you now create an object that > > inherits from Object > > > > and > > > > contains the primitive. e.g. plain-text ISA Object; > > plain-text HASA > > > > String. > > > > > > Hi Mark et al., > > > > > > Any idea when this change will happen? If I look in the > > Central that > > > is running the latest and greatest codebase, the > > forbidden ISA [some > > > primitive] relationships are still in place :(. What is > > even worse is > > > that the primitive DateTime ISA String. As a result I > > can not get one > > > of my Objects (that plays by the rules of the latest > > specs) > > > registered. At least I suspect this to be the problem. I > > don't get an > > > error message when register my object, but it has > > amongst others a > > > HASA DataTime and that relationship is not getting > > registered... > > > > > > Cheers, > > > > > > Pi > > > > > > > > > > > > > > > Wageningen University and Research centre (WUR) > > > Laboratory of Bioinformatics > > > Transitorium (building 312) room 1034 > > > Dreijenlaan 3 > > > 6703 HA Wageningen > > > The Netherlands > > > phone: 0317-483 060 > > > fax: 0317-483 584 > > > mobile: 06-143 66 783 > > > pieter.neerincx at wur.nl > > > > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > > "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 > -- "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 edward.kawas at gmail.com Thu Oct 6 20:55:47 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 6 Oct 2005 13:55:47 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: <000101c5cab8$549b3c20$6500a8c0@notebook> Hi, I am working on this script right now as we speak, but I just wanted to get feedback (for a second time). >From what I understand, I am going to go through the ontology, and deprecate any data type that inherits from a primitive. Any object that I deprecate will be duplicated and have an _2 appended to its name as well as having its ISA relationship set to object and adding a HASA primitive relationship. So far so good. In six weeks, I am going to go through the ontology and remove all objects that inherit from a primitive, leaving those that were duplicated with an _2 alone. Therefore, in 6 weeks, we will have objects like text-plain_2, text-xml_2, etc. I know that some people are fine with this and others are not. Some might not even care. However, what I want to know is what MOBYers think and if anyone has any other comments/suggestions. So please let me know. Just to get this started, I am still pretty iffy about leaving x_2 data types in the ontology. I do see Marks point on how services that are not updated choking since they expect the data type to inherit from a primitive. Any ideas? Thanks, Eddie > -----Original Message----- > From: Mark Wilkinson [mailto:markw at illuminae.com] > Sent: Thursday, October 06, 2005 9:08 AM > To: Core developer announcements > Cc: Eddie Kawas > Subject: Re: [moby] Re: [MOBY-dev] Migration of database > to new API > > As you have noticed, the change has already happened at > the code level > just to prevent any more registrations of what will soon > be illegal > objects. I have a script that will update the database > records of the > ontologies and deprecate the old nodes, but we haven't yet > run it on the > public registry. Eddie is going to make a couple of > changes to it over > the next day or two, and then will send out a heads-up > that the > ontologies are changing forever, and a tutorial on how to > do the update > for service providers. We'll give a reasonable amount of > time for > people to update their services (say, 6 weeks) and then we > will delete > the old nodes from the ontology completely. The script is > in the CVS so > anyone running a registry can do the same thing. > > When I went to update my own services it took me less than > 5 minutes to > do so, so 6 weeks should be more than enough time for > anyone who is > actively concerned about their service :-) > > Cheers! > > M > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > > On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: > > > > > Hi all, > > > > > > As we move toward deploying the new API, there are > some serious > > > consequences on the underlying databases. > > > > > > Let me first re-cap the new API features that I am > discussing and what > > > effects they have on the databases: > > > > > > 1) Inheritence from primitives through ISA > relationships is no longer > > > allowed. e.g. plain-text ISA String is no longer > allowed. To > > > achieve > > > the same result, you now create an object that > inherits from Object > > > and > > > contains the primitive. e.g. plain-text ISA Object; > plain-text HASA > > > String. > > > > Hi Mark et al., > > > > Any idea when this change will happen? If I look in the > Central that > > is running the latest and greatest codebase, the > forbidden ISA [some > > primitive] relationships are still in place :(. What is > even worse is > > that the primitive DateTime ISA String. As a result I > can not get one > > of my Objects (that plays by the rules of the latest > specs) > > registered. At least I suspect this to be the problem. I > don't get an > > error message when register my object, but it has > amongst others a > > HASA DataTime and that relationship is not getting > registered... > > > > Cheers, > > > > Pi > > > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "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 Pieter.Neerincx at wur.nl Fri Oct 7 09:16:23 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 7 Oct 2005 11:16:23 +0200 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: On 6-Oct-2005, at 6:08 PM, Mark Wilkinson wrote: > As you have noticed, the change has already happened at the code level > just to prevent any more registrations of what will soon be illegal > objects. That would be fine, but I have upgraded my service and objects to conform to the new standard and can not register legal stuff :(. > I have a script that will update the database records of the > ontologies and deprecate the old nodes, but we haven't yet run it > on the > public registry. Eddie is going to make a couple of changes to it > over > the next day or two, and then will send out a heads-up that the > ontologies are changing forever, and a tutorial on how to do the > update > for service providers. We'll give a reasonable amount of time for > people to update their services (say, 6 weeks) and then we will delete > the old nodes from the ontology completely. The script is in the > CVS so > anyone running a registry can do the same thing. I'll run that script on my local central to see if I can register after the change. > > When I went to update my own services it took me less than 5 > minutes to > do so, so 6 weeks should be more than enough time for anyone who is > actively concerned about their service :-) IMHO it might be even a bit too much. Personally I opt for 2) If we change to _2 temporarily, deprecate, delete, and then rename the _2's back again after 6 weeks: with: i) update their services and NOT re-register, and ii) their services will be "illegal" for 6 weeks, This keeps the ontology clean. This change was announced long enough ago to give people a chance to update their services. For me it took even less time. I didn't have to update my services at all. When I extract for example text from a CustomObject ISA String object I was already assuming it would not have any HASA relations, because it is a primitive. So I was getting the text from that node and any childs it might have. After the change, if my service fetches text from CustomObject I get the text from it's HASA String. No recoding needed; painless change :). I did spend the 5 minutes though on the scripts I use to register my services at a central. Anyway, for the DateTime primitive things are still a bit strange. Currently DateTime ISA String ISA Object. All other primitives are simply ISA Object. This will change to DateTime ISA Object and HASA String. According to the spec DateTime shouldn't have a String, because it is by itself already a primitive... In the current situation DateTime is not a primitive, but just yet another type of String. just my 2c, Pi > > Cheers! > > M > > > > On Thu, 2005-10-06 at 17:32 +0200, Pieter Neerincx wrote: > >> On 27-Aug-2005, at 12:20 AM, Mark Wilkinson wrote: >> >> >>> Hi all, >>> >>> As we move toward deploying the new API, there are some serious >>> consequences on the underlying databases. >>> >>> Let me first re-cap the new API features that I am discussing and >>> what >>> effects they have on the databases: >>> >>> 1) Inheritence from primitives through ISA relationships is no >>> longer >>> allowed. e.g. plain-text ISA String is no longer allowed. To >>> achieve >>> the same result, you now create an object that inherits from Object >>> and >>> contains the primitive. e.g. plain-text ISA Object; plain-text HASA >>> String. >>> >> >> Hi Mark et al., >> >> Any idea when this change will happen? If I look in the Central that >> is running the latest and greatest codebase, the forbidden ISA [some >> primitive] relationships are still in place :(. What is even worse is >> that the primitive DateTime ISA String. As a result I can not get one >> of my Objects (that plays by the rules of the latest specs) >> registered. At least I suspect this to be the problem. I don't get an >> error message when register my object, but it has amongst others a >> HASA DataTime and that relationship is not getting registered... >> >> Cheers, >> >> Pi >> >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Oct 7 09:30:14 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 7 Oct 2005 11:30:14 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <001101c5c947$04dfbd40$6500a8c0@notebook> References: <001101c5c947$04dfbd40$6500a8c0@notebook> Message-ID: <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> Hi Eddie, On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > Hi Pieter! > > I tracked down the bug and I fixed it (*fingers crossed*). > > I am placing 2 jar files at the following links that need to > replace the ones in your /taverna-workbench-1.3/lib/ > directory: > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > Be sure to backup the 2 files you are about to replace, just > in case! > > Then try out your workflows and let me know what happens. I did some simple tests with the objects that failed previously and so far so good :) Thanks for the quick fix! > > Also, if all is well, do you think that you could send me > one of those workflows so I can use it as an example? After a lot of trail and error playing with a local central I think it's about time I register my services and objects at the central Central as well. Will do so once the central Central databases are migrated to the new API... Cheers, Pi > Thanks a lot, > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter >> Neerincx >> Sent: Tuesday, October 04, 2005 9:04 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> >> On 4-Oct-2005, at 5:12 PM, Edward Kawas wrote: >> >> >>> No you are on to something! When I first created the >>> >> plugin, >> >>> I used a certain xml parser based on w3c dom. I had to >>> switch to another parser and it seems that I was unaware >>> >> of >> >>> its limitations (getChildren only gets the direct >>> >> children >> >>> of an element). >>> >>> I will have this fixed fairly soon. >>> >> >> I'm looking forward to "testdrive" it :) >> >> Thanks, >> >> Pieter >> >> >>> >>> 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 Pieter >>>> Neerincx >>>> Sent: Tuesday, October 04, 2005 8:07 AM >>>> To: Core developer announcements >>>> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >>>> missing in BioMOBYobjects >>>> >>>> >>>> On 4-Oct-2005, at 3:44 PM, Edward Kawas wrote: >>>> >>>> >>>> >>>>>> moby:MOBY >>>>>> moby:Content >>>>>> moby:Data >>>>>> moby:Simple >>>>>> moby:My_Child_Level_1B >>>>>> moby:My_Child_Level_2A >>>>>> moby:My_Child_Level_2B >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> Do you have an example of an object that has this type >>>>> >>>>> >>>> of >>>> >>>> >>>>> structure? >>>>> >>>>> >>>> >>>> Yes, try for example DnaSequenceHolder from the BioMOBY >>>> Central. >>>> >>>> I have been running some other tests in the mean time >>>> >> and >> >>>> so far >>>> almost every object I tried lacks child elements at >>>> >> level >> >>>> 2 or >>>> further down. The only one that does have an element at >>>> level 2 is >>>> the BlastJob object I have in my local Central. This >>>> >> one >> >>>> has Strings, >>>> Objects and a DataTime at level 2 or further down. >>>> Everything is >>>> missing except the DataTime primitive... I noticed that >>>> hardly anyone >>>> is using the DataTime primitive if I'm not the only one >>>> using. It is >>>> also hardly documented. Maybe it's just random noise in >>>> >> my >> >>>> testing or >>>> maybe I'm onto something.... >>>> >>>> If you want to try the BlastJob object my local >>>> >> registry >> >>>> should still >>>> be accessible from outside at: >>>> http://137.224.52.237/phenolink/biomoby/central/cgi- >>>> bin/MOBY-Central.pl >>>> >>>> Hope this helps, >>>> >>>> Pi >>>> >>>> >>>> >>>>> Thanks, >>>>> >>>>> Eddie >>>>> >>>>> _______________________________________________ >>>>> MOBY-dev mailing list >>>>> MOBY-dev at biomoby.org >>>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>>> >>>>> >>>>> >>>> >>>> >>>> Wageningen University and Research centre (WUR) >>>> Laboratory of Bioinformatics >>>> Transitorium (building 312) room 1034 >>>> Dreijenlaan 3 >>>> 6703 HA Wageningen >>>> The Netherlands >>>> phone: 0317-483 060 >>>> fax: 0317-483 584 >>>> mobile: 06-143 66 783 >>>> pieter.neerincx at wur.nl >>>> >>>> >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at biomoby.org >>>> http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Oct 7 14:47:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Oct 2005 07:47:29 -0700 Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: References: <1125094831.14295.22.camel@bioinfo.icapture.ubc.ca> <1128614890.1179.56.camel@bioinfo.icapture.ubc.ca> Message-ID: <1128696449.3111.5.camel@bioinfo.icapture.ubc.ca> On Fri, 2005-10-07 at 11:16 +0200, Pieter Neerincx wrote: > Anyway, for the DateTime primitive things are still a bit strange. > Currently DateTime ISA String ISA Object. All other primitives are > simply ISA Object. This will change to DateTime ISA Object and HASA > String. According to the spec DateTime shouldn't have a String, > because it is by itself already a primitive... In the current > situation DateTime is not a primitive, but just yet another type of > String. Okay, I'll have a look at this today. Might be "just a bug" rather than a systemic error :-) M From Pieter.Neerincx at wur.nl Fri Oct 7 17:25:28 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 7 Oct 2005 19:25:28 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> References: <001101c5c947$04dfbd40$6500a8c0@notebook> <89DC5979-8B2F-4131-BE0D-07BF38326F9B@wur.nl> Message-ID: <0DCBF3DF-D564-47ED-9E85-9B669BA49ADA@wur.nl> Hi Eddie, Sorry, I cheered premature :(. For one of my services I use the articleName attribute of two String objects to know which one contains which data. Hence I have something like: Bla bla Alb alb The Object my service receives in Taverna lacks the articleName attributes for it's String childs :(. Hence it becomes this: Bla bla Alb alb Looks like the fix introduced a new bug as well... Pieter On 07Oct2005, at 11:30, Pieter Neerincx wrote: > Hi Eddie, > > On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > > >> Hi Pieter! >> >> I tracked down the bug and I fixed it (*fingers crossed*). >> >> I am placing 2 jar files at the following links that need to >> replace the ones in your /taverna-workbench-1.3/lib/ >> directory: >> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar >> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar >> >> Be sure to backup the 2 files you are about to replace, just >> in case! >> >> Then try out your workflows and let me know what happens. >> > > I did some simple tests with the objects that failed previously and > so far so good :) > > Thanks for the quick fix! > > >> >> Also, if all is well, do you think that you could send me >> one of those workflows so I can use it as an example? >> > > After a lot of trail and error playing with a local central I think > it's about time I register my services and objects at the central > Central as well. Will do so once the central Central databases are > migrated to the new API... > > Cheers, > > Pi > > >> Thanks a lot, >> >> Eddie >> From senger at ebi.ac.uk Sun Oct 9 21:18:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 9 Oct 2005 22:18:58 +0100 (BST) Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <433D0742.4050708@cnb.uam.es> Message-ID: Hi all, Last week, I have met David and he explained to me all what was happenning with the error handling (because I was off-line most of the last week). I agree with the various voices that serviceNotes is better than PIB, and I am happy to hear that Mark has not problem with an additional 'Notes' in 'serviceNotes' (he is probably the only one who is filling serviceNotes now). Could someone summarize the result of voting and publish somewhere the latest version of the API regarding the error handling please? When this is out I will immediately add it to the Moses-based generated services. Thanks and regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Sun Oct 9 21:48:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 9 Oct 2005 22:48:44 +0100 (BST) Subject: [moby] Re: [MOBY-dev] Migration of database to new API In-Reply-To: <000101c5cab8$549b3c20$6500a8c0@notebook> Message-ID: > Just to get this started, I am still pretty iffy about > leaving x_2 data types in the ontology. I do see Marks point > on how services that are not updated choking since they > expect the data type to inherit from a primitive. Any ideas? > As I said before I would suggest: - do not use any automatic script - tell people that after 6 weeks the deprecented data objects will be deleted (together with the services that still use them) - optionally: write a document to advise what people with affected data types types should do (e.g. help them by removing Signature URLs from such services so they can re-register them again) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Oct 10 01:35:42 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 09 Oct 2005 18:35:42 -0700 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: References: Message-ID: <4349C56E.8000308@illuminae.com> We should also call for a new vote, and perhaps this time simply use the mailing list since the last call for votes only got one response... Let's say October 24th as the final word on this? M Martin Senger wrote: >Hi all, > Last week, I have met David and he explained to me all what was >happenning with the error handling (because I was off-line most of the >last week). I agree with the various voices that serviceNotes is better >than PIB, and I am happy to hear that Mark has not problem with an >additional 'Notes' in 'serviceNotes' (he is probably the only one who is >filling serviceNotes now). > Could someone summarize the result of voting and publish somewhere the >latest version of the API regarding the error handling please? When this >is out I will immediately add it to the Moses-based generated services. > > Thanks and regards, > Martin > > > From senger at ebi.ac.uk Mon Oct 10 08:57:43 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 10 Oct 2005 09:57:43 +0100 (BST) Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <4349C56E.8000308@illuminae.com> Message-ID: > We should also call for a new vote, and perhaps this time simply use the > mailing list since the last call for votes only got one response... > > Let's say October 24th as the final word on this? > Where can I can the latest, official, document describing the latest consensus? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From dgpisano at cnb.uam.es Mon Oct 10 10:45:33 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Mon, 10 Oct 2005 12:45:33 +0200 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: References: Message-ID: <434A464D.7070203@cnb.uam.es> The latest version is in the bugzilla http://bugzilla.open-bio.org/attachment.cgi?id=233 David Martin Senger escribi?: >>We should also call for a new vote, and perhaps this time simply use the >>mailing list since the last call for votes only got one response... >> >>Let's say October 24th as the final word on this? >> >> >> > Where can I can the latest, official, document describing the latest >consensus? > > Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available URL: From edward.kawas at gmail.com Tue Oct 11 04:58:27 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 10 Oct 2005 21:58:27 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <0DCBF3DF-D564-47ED-9E85-9B669BA49ADA@wur.nl> Message-ID: <000401c5ce20$6bcf7300$6900a8c0@notebook> Hi Pieter, I uploaded 2 new files. I am not sure if your bug is fixed, but I thought that I would let you know. I have made new additions and I modified some of the xml parsing, so while I haven't worked on your bug, it may be fixed (or made worse ;-). By the way, do you think that you could send me a workflow whenever you notice something fishy? Thanks, Eddie http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Friday, October 07, 2005 10:25 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > Sorry, I cheered premature :(. For one of my services I > use the > articleName attribute of two String objects to know which > one > contains which data. Hence I have something like: > > > articleName="this.one"> > Bla bla > > articleName="the.other.one"> > Alb alb > > > > The Object my service receives in Taverna lacks the > articleName > attributes for it's String childs :(. Hence it becomes > this: > > > > Bla bla > > > Alb alb > > > > Looks like the fix introduced a new bug as well... > > Pieter > > On 07Oct2005, at 11:30, Pieter Neerincx wrote: > > > Hi Eddie, > > > > On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > > > > > >> Hi Pieter! > >> > >> I tracked down the bug and I fixed it (*fingers > crossed*). > >> > >> I am placing 2 jar files at the following links that > need to > >> replace the ones in your /taverna-workbench-1.3/lib/ > >> directory: > >> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > 1.3.jar > >> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > >> > >> Be sure to backup the 2 files you are about to replace, > just > >> in case! > >> > >> Then try out your workflows and let me know what > happens. > >> > > > > I did some simple tests with the objects that failed > previously and > > so far so good :) > > > > Thanks for the quick fix! > > > > > >> > >> Also, if all is well, do you think that you could send > me > >> one of those workflows so I can use it as an example? > >> > > > > After a lot of trail and error playing with a local > central I think > > it's about time I register my services and objects at > the central > > Central as well. Will do so once the central Central > databases are > > migrated to the new API... > > > > Cheers, > > > > Pi > > > > > >> Thanks a lot, > >> > >> Eddie > >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From carrere at toulouse.inra.fr Thu Oct 13 07:17:34 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu, 13 Oct 2005 09:17:34 +0200 Subject: [MOBY-dev] Hardware upgrade: services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <434E0A0E.50006@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Friday (October 14th) 9.00 a.m. (GMT+1) till monday (October 17th) 11.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Next week, services interruptions should happen... Sorry for inconvenience, Sebastien Carrere From carrere at toulouse.inra.fr Thu Oct 13 07:17:34 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Thu, 13 Oct 2005 09:17:34 +0200 Subject: [MOBY-dev] Hardware upgrade: services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <434E0A0E.50006@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Friday (October 14th) 9.00 a.m. (GMT+1) till monday (October 17th) 11.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Next week, services interruptions should happen... Sorry for inconvenience, Sebastien Carrere From Pieter.Neerincx at wur.nl Thu Oct 13 15:46:39 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 13 Oct 2005 17:46:39 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <000401c5ce20$6bcf7300$6900a8c0@notebook> References: <000401c5ce20$6bcf7300$6900a8c0@notebook> Message-ID: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Hi Eddie, On 11-Oct-2005, at 6:58 AM, Edward Kawas wrote: > Hi Pieter, > > I uploaded 2 new files. I am not sure if your bug is fixed, > but I thought that I would let you know. I have made new > additions and I modified some of the xml parsing, so while I > haven't worked on your bug, it may be fixed (or made worse > ;-). Well just tested the new versions and to be honest it kind of made it really bad :( I can not get any output anymore from any BioMOBY service. So I switched back to the previous versions of the *.jar files you had uploaded and apart from the missing articleName attribute things work again :). > > By the way, do you think that you could send me a workflow > whenever you notice something fishy? Sure. You mean the workflow saved as a scufl xml file I assume. Will do that in the future, but, in this case just try any BioMOBY service. Maybe some other files got updated as well in your development version apart from the 2 uploaded files... Cheers, Pieter > > Thanks, > > Eddie > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna-1.3.jar > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > >> -----Original Message----- >> From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter >> Neerincx >> Sent: Friday, October 07, 2005 10:25 AM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements >> missing in BioMOBYobjects >> >> Hi Eddie, >> >> Sorry, I cheered premature :(. For one of my services I >> use the >> articleName attribute of two String objects to know which >> one >> contains which data. Hence I have something like: >> >> >> > articleName="this.one"> >> Bla bla >> >> > articleName="the.other.one"> >> Alb alb >> >> >> >> The Object my service receives in Taverna lacks the >> articleName >> attributes for it's String childs :(. Hence it becomes >> this: >> >> >> >> Bla bla >> >> >> Alb alb >> >> >> >> Looks like the fix introduced a new bug as well... >> >> Pieter >> >> On 07Oct2005, at 11:30, Pieter Neerincx wrote: >> >> >>> Hi Eddie, >>> >>> On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: >>> >>> >>> >>>> Hi Pieter! >>>> >>>> I tracked down the bug and I fixed it (*fingers >>>> >> crossed*). >> >>>> >>>> I am placing 2 jar files at the following links that >>>> >> need to >> >>>> replace the ones in your /taverna-workbench-1.3/lib/ >>>> directory: >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- >>>> >> 1.3.jar >> >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar >>>> >>>> Be sure to backup the 2 files you are about to replace, >>>> >> just >> >>>> in case! >>>> >>>> Then try out your workflows and let me know what >>>> >> happens. >> >>>> >>>> >>> >>> I did some simple tests with the objects that failed >>> >> previously and >> >>> so far so good :) >>> >>> Thanks for the quick fix! >>> >>> >>> >>>> >>>> Also, if all is well, do you think that you could send >>>> >> me >> >>>> one of those workflows so I can use it as an example? >>>> >>>> >>> >>> After a lot of trail and error playing with a local >>> >> central I think >> >>> it's about time I register my services and objects at >>> >> the central >> >>> Central as well. Will do so once the central Central >>> >> databases are >> >>> migrated to the new API... >>> >>> Cheers, >>> >>> Pi >>> >>> >>> >>>> Thanks a lot, >>>> >>>> Eddie >>>> >>>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Thu Oct 13 15:52:02 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 13 Oct 2005 08:52:02 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Message-ID: <000601c5d00e$0fca4180$6900a8c0@notebook> Sorry Pieter, I am still looking into it. Since the last time you tested, I fixed numerous logic errors. I think that ultimately you will notice that the article name issue will be fixed. I will let you know when a new test version is out. I thought I just had one, but a workflow that executes every branch of a service found an error. Thanks for your patience! Ed > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Thursday, October 13, 2005 8:47 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > missing in BioMOBYobjects > > Hi Eddie, > > On 11-Oct-2005, at 6:58 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I uploaded 2 new files. I am not sure if your bug is > fixed, > > but I thought that I would let you know. I have made new > > additions and I modified some of the xml parsing, so > while I > > haven't worked on your bug, it may be fixed (or made > worse > > ;-). > > Well just tested the new versions and to be honest it kind > of made it > really bad :( I can not get any output anymore from any > BioMOBY > service. So I switched back to the previous versions of > the *.jar > files you had uploaded and apart from the missing > articleName > attribute things work again :). > > > > > By the way, do you think that you could send me a > workflow > > whenever you notice something fishy? > > Sure. You mean the workflow saved as a scufl xml file I > assume. Will > do that in the future, but, in this case just try any > BioMOBY > service. Maybe some other files got updated as well in > your > development version apart from the 2 uploaded files... > > Cheers, > > Pieter > > > > > Thanks, > > > > Eddie > > > > http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > 1.3.jar > > http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > > > > > >> -----Original Message----- > >> From: moby-dev-bounces at portal.open-bio.org > [mailto:moby- > >> dev-bounces at portal.open-bio.org] On Behalf Of Pieter > >> Neerincx > >> Sent: Friday, October 07, 2005 10:25 AM > >> To: Core developer announcements > >> Subject: Re: [MOBY-dev] Taverna plugin bug?: elements > >> missing in BioMOBYobjects > >> > >> Hi Eddie, > >> > >> Sorry, I cheered premature :(. For one of my services I > >> use the > >> articleName attribute of two String objects to know > which > >> one > >> contains which data. Hence I have something like: > >> > >> > >> >> articleName="this.one"> > >> Bla bla > >> > >> >> articleName="the.other.one"> > >> Alb alb > >> > >> > >> > >> The Object my service receives in Taverna lacks the > >> articleName > >> attributes for it's String childs :(. Hence it becomes > >> this: > >> > >> > >> > >> Bla bla > >> > >> > >> Alb alb > >> > >> > >> > >> Looks like the fix introduced a new bug as well... > >> > >> Pieter > >> > >> On 07Oct2005, at 11:30, Pieter Neerincx wrote: > >> > >> > >>> Hi Eddie, > >>> > >>> On 5-Oct-2005, at 2:52 AM, Edward Kawas wrote: > >>> > >>> > >>> > >>>> Hi Pieter! > >>>> > >>>> I tracked down the bug and I fixed it (*fingers > >>>> > >> crossed*). > >> > >>>> > >>>> I am placing 2 jar files at the following links that > >>>> > >> need to > >> > >>>> replace the ones in your /taverna-workbench-1.3/lib/ > >>>> directory: > >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/taverna- > >>>> > >> 1.3.jar > >> > >>>> http://bioinfo.icapture.ubc.ca/ekawas/jars/jmoby.jar > >>>> > >>>> Be sure to backup the 2 files you are about to > replace, > >>>> > >> just > >> > >>>> in case! > >>>> > >>>> Then try out your workflows and let me know what > >>>> > >> happens. > >> > >>>> > >>>> > >>> > >>> I did some simple tests with the objects that failed > >>> > >> previously and > >> > >>> so far so good :) > >>> > >>> Thanks for the quick fix! > >>> > >>> > >>> > >>>> > >>>> Also, if all is well, do you think that you could > send > >>>> > >> me > >> > >>>> one of those workflows so I can use it as an example? > >>>> > >>>> > >>> > >>> After a lot of trail and error playing with a local > >>> > >> central I think > >> > >>> it's about time I register my services and objects at > >>> > >> the central > >> > >>> Central as well. Will do so once the central Central > >>> > >> databases are > >> > >>> migrated to the new API... > >>> > >>> Cheers, > >>> > >>> Pi > >>> > >>> > >>> > >>>> Thanks a lot, > >>>> > >>>> Eddie > >>>> > >>>> > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Thu Oct 13 23:43:14 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 13 Oct 2005 16:43:14 -0700 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <1D0AA16F-E7C5-47AB-A36D-7BE22D953570@wur.nl> Message-ID: <001201c5d04f$e2e15860$6900a8c0@notebook> Hi Pieter, I have uploaded the 2 jar files to http://bioinfo.icapture.ubc.ca/ekawas/jars/ There are 2 of them. Moreover, I have uploaded some workflows: http://bioinfo.icapture.ubc.ca/ekawas/workflows/ Test this version out. I believe that I fixed the article name bug. I have also fixed various other anomalies. Let me know how it goes. I am going to keep trying to create workflows that utilize complex Moby datatypes (GeneInfo comes to mind) to ensure that all is well. Thanks a lot, Eddie From aperezp at uma.es Fri Oct 14 10:03:56 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Fri, 14 Oct 2005 12:03:56 +0200 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: <20051014100352.0A065C0015@correo2.uma.es> Hi, do you know if is there any easy Perl function for obtaining the dataType and serviceType ontology in a tree way? Thanks in advance, Antonio. From edward.kawas at gmail.com Fri Oct 14 14:56:02 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 14 Oct 2005 07:56:02 -0700 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <20051014100352.0A065C0015@correo2.uma.es> Message-ID: <000001c5d0cf$66552170$6900a8c0@notebook> Take a look at the following project http://bioinformatics.org/project/?group_id=190 I believe that it produces a tree using wxPerl. Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Antonio J. > P?rez > Sent: Friday, October 14, 2005 3:04 AM > To: 'Core developer announcements' > Cc: Inb-tecnico at everest.cnb.uam.es > Subject: [MOBY-dev] Perl function for object tree > > Hi, do you know if is there any easy Perl function > for obtaining the > dataType and serviceType ontology in a tree way? > Thanks in advance, > > Antonio. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Sat Oct 15 16:29:09 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 15 Oct 2005 09:29:09 -0700 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <000001c5d0cf$66552170$6900a8c0@notebook> References: <000001c5d0cf$66552170$6900a8c0@notebook> Message-ID: <43512E55.3050505@illuminae.com> yeah.. but no guarantees that it works - I haven't looked at that code in almost two years! I abandoned wxPerl because it was desperately under-documented at the time (yes, I know... people in glass houses...) If anyone needs it, I could update my GO_Browser.pm widget (part of BioPerl) so that it presents the ISA part of the Moby object/service hierarchy. It uses Tk Perl, and would only take a couple of minutes to modify... it also allows programmable call-backs on mouse events that take place on the tree nodes (clicks, double-clicks, mouseovers, etc). If there is a need for this, please say so. M Edward Kawas wrote: >Take a look at the following project >http://bioinformatics.org/project/?group_id=190 I believe >that it produces a tree using wxPerl. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>dev-bounces at portal.open-bio.org] On Behalf Of Antonio J. >>P?rez >>Sent: Friday, October 14, 2005 3:04 AM >>To: 'Core developer announcements' >>Cc: Inb-tecnico at everest.cnb.uam.es >>Subject: [MOBY-dev] Perl function for object tree >> >> Hi, do you know if is there any easy Perl function >>for obtaining the >>dataType and serviceType ontology in a tree way? >> Thanks in advance, >> >> Antonio. >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > From aperezp at uma.es Sat Oct 15 19:38:58 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Sat, 15 Oct 2005 21:38:58 +0200 Subject: [MOBY-dev] Perl function for object tree In-Reply-To: <43512E55.3050505@illuminae.com> Message-ID: <20051015193902.9A108C0008@correo2.uma.es> Hi Mark and Edward, and thank you to both, If it is not too work and bother, it would be very useful for showing the Biomoby ontology. We are now building CGIs showing object and service ontology and if there are modules which help in this subject, it is always good not repeat previously-done and as I can see good work. Regards and thanks again, Antonio. -----Mensaje original----- De: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] En nombre de Mark Wilkinson Enviado el: s?bado, 15 de octubre de 2005 18:29 Para: Core developer announcements Asunto: Re: [MOBY-dev] Perl function for object tree yeah.. but no guarantees that it works - I haven't looked at that code in almost two years! I abandoned wxPerl because it was desperately under-documented at the time (yes, I know... people in glass houses...) If anyone needs it, I could update my GO_Browser.pm widget (part of BioPerl) so that it presents the ISA part of the Moby object/service hierarchy. It uses Tk Perl, and would only take a couple of minutes to modify... it also allows programmable call-backs on mouse events that take place on the tree nodes (clicks, double-clicks, mouseovers, etc). If there is a need for this, please say so. M Edward Kawas wrote: >Take a look at the following project >http://bioinformatics.org/project/?group_id=190 I believe >that it produces a tree using wxPerl. > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>dev-bounces at portal.open-bio.org] On Behalf Of Antonio J. >>P?rez >>Sent: Friday, October 14, 2005 3:04 AM >>To: 'Core developer announcements' >>Cc: Inb-tecnico at everest.cnb.uam.es >>Subject: [MOBY-dev] Perl function for object tree >> >> Hi, do you know if is there any easy Perl function >>for obtaining the >>dataType and serviceType ontology in a tree way? >> Thanks in advance, >> >> Antonio. >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Mon Oct 17 16:25:36 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 17 Oct 2005 10:25:36 -0600 Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <434A464D.7070203@cnb.uam.es> References: <434A464D.7070203@cnb.uam.es> Message-ID: <4353D080.50701@ucalgary.ca> I have only a couple of suggestions, but I think they may be important: 1. I have a problem with callling all of this Error Handling and having the tag called mobyException, when this mechanism includes not only errors, but also non-fatal warnings and simple information blocks. Perhaps we should call it Execution Status Reporting or something like that? 2. Under "Service Intrinsic Errors", the footnote for 701 states that Blast reporting "No hits found" is a SERVICE_INTERNAL_ERROR. Why is getting no hits an error? Isn't it just a blank response? If I'm designing a sequencing oligo and am checking my oligo against my cloning vector sequence, I want no hits! A MOBY-aware program may see it as an error instead of a response to report... 3. Could we add a few codes to the 700 series "700 OK" (pretty obvious: everything was okay, but we want to provide a formatted info block in the response) "703 Data no longer valid" (once upon a time the data was valid, but no longer: a sequence identifier that has been retracted, a job ticket that is stale, etc.) "704 input invalid" (somehow you escaped the 200 series errors because it is MOBY-correct input, but biologically the input doesn't make sense e.g. an EC number is an object with a String, and that's what you gave us, but the string is HelloWorld, which is not of the form #.#.#.#) "705 data transformed" (e.g. warning: non-DNA chars ignored in DNA search) My CAN$0.02, Paul > The latest version is in the bugzilla > > http://bugzilla.open-bio.org/attachment.cgi?id=233 > > David > > Martin Senger escribi?: > >>> We should also call for a new vote, and perhaps this time simply use >>> the mailing list since the last call for votes only got one response... >>> >>> Let's say October 24th as the final word on this? >>> >>> >> >> Where can I can the latest, official, document describing the latest >> consensus? >> >> Martin >> >> >> >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From carrere at toulouse.inra.fr Tue Oct 18 06:47:24 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Tue, 18 Oct 2005 08:47:24 +0200 Subject: [MOBY-dev] Hardware upgrade: last programmed interruption - services unreachable bioinfo.genopole-toulouse.prd.fr In-Reply-To: <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> References: <43183B8A.2010607@cnb.uam.es> <1125675675.29942.36.camel@bioinfo.icapture.ubc.ca> Message-ID: <43549A7C.102@toulouse.inra.fr> Dear BioMobiers, Due to upgrade of our server hardware, services provided by bioinfo.genopole-toulouse.prd.fr will be unreachable from Today evening 8.00 p.m. (GMT+1) till Thursday (October 20th) 9.00 a.m. (GMT+1). Moreover, during this period the web client dedicated to design and execution of BioMoby workflows Remora (http://bioinfo.genopole-toulouse.prd.fr/remora) will be unavailable. Hope this should be the last interruption ... Sorry for inconvenience, Sebastien Carrere _______________________________________________ From senger at ebi.ac.uk Tue Oct 18 17:12:58 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 18 Oct 2005 18:12:58 +0100 (BST) Subject: [MOBY-dev] RFC #1863 - change request & question In-Reply-To: <4353D080.50701@ucalgary.ca> Message-ID: > 1. I have a problem with callling all of this Error Handling and having > the tag called mobyException, when this mechanism includes not only > errors, but also non-fatal warnings and simple information blocks. > I think this was caused by me: I have asked the authors to have there also simple information blocks. I see now that having two places for the same informations (a mobyException tag with a simple information, and the Notes tag) may be confusing. So I am fine with not having the type 'information' there). On the other hand, I think that having warnings in the mobyException is correct (I consider a warning as an exceptional condition). > 2. Under "Service Intrinsic Errors", the footnote for 701 states that > Blast reporting "No hits found" is a SERVICE_INTERNAL_ERROR. Why is > getting no hits an error? > I think that this is an example. Simply it refers to a service that *consider* this situation as exceptionla and errorneus. Your service may feel differently. But if you think that such example is confusing, it is simple to remove it (or to replace is by an another one). > "700 OK" (pretty obvious: everything was okay, but we want to > provide a formatted info block in the response) > But you can always use Notes to fo that withoutr having any exceptionMoby block at all. I am not sure what you want to achiev by this 700 code I must admit. > "703 Data no longer valid" (once upon a time the data was valid, but > no longer: a sequence identifier that has been retracted, a job ticket > that is stale, etc.) > "704 input invalid" (somehow you escaped the 200 series errors > because it is MOBY-correct input, but biologically the input doesn't > make sense e.g. an EC number is an object with a String, and that's what > you gave us, but the string is HelloWorld, which is not of the form #.#.#.#) > "705 data transformed" (e.g. warning: non-DNA chars ignored in DNA > search) > We surely can make more service-specific codes. But I feel that having them is not anyway rich enough - the service providers may specify more details (e.g. yout 704 woulod by better to say why it is invalid; and if not then the code 201 should be used). So I would keep the pre-defined 700 codes at minimum (anyway, what a client can do with them? it simply reports it - there is probably no general way how to send the same request again with the error corrected). I would even remove 701 and rename 702. See below. My additional comments to the latest draft are: * Make sure that upper/lower cases are consistent in attribute names. I notices that refqueryId is spelled both ways as: refQueryId and refqueryId. * I think that we do not need Error code 701. The general failure is reported by 600, and nayhinf more specific can have a concrete service specific code (documented in the service description). * Code 702 is either too generic (so some of 200 codes should be used instead ) or a service provider should be more specific and agin design its specific code and document it. But The example for this code is quite useful - even so useful that I would suggest to add a code for "not-matching namespace" condition (either as a 70x code, or perhaps as a 227 "INPUT_INCORRECT_NAMESPACE". Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Tue Oct 18 20:49:13 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 18 Oct 2005 13:49:13 -0700 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th Message-ID: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Hi all, Eddie and I have been discussing the object ontology migration now that we are not allowing inheritance from primitives. No matter what we do this will break some services, and though I was originally hoping to soften the blow by having a deprecation period, the amount of pain this causes (i.e. everyone having to edit and re-register their services TWICE!) is just inhumane :-) So... I am sure that some of you will cheer this decision, and others will loathe it... we're going to simply migrate the object ontology (in the public MOBY Central here at iCAPTURE) with **no deprecation period at all**. The object names will remain exactly as they are, but will (in some cases) now have different definitions. As such, for those of you running services that are affected by this change, you will only need to update your service code, but NOT need to de/re-register your service. We plan to do this Monday October 24th, so you have a few days to update your services now to reduce the down-time. The way to go about updating your services is as follows: Any XML node that currently has content, but is not a nominal primitive, will now be modified such that it CONTAINS a node that is a primitive, and that primitive will have data content. It's articleName is "content" in every case. e.g. name ACGTGTAGTGCTAGTC ]]> will become name ACGTGTGCTGATGAC ]]> And similarly for Integers, Floats, DateTime, etc. The definition of DateTime will also change, such that it is a primitive, rather than inheriting from String, as it currently does. Eddie has a migration script that will update your mySQL databases automatically. He will make this available on his website (details to follow). Any objections? (don't all yell at once ;-) ) Cheers! Mark -- "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 Pieter.Neerincx at wur.nl Tue Oct 18 21:53:16 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 18 Oct 2005 23:53:16 +0200 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> References: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: <68AE2417-6156-451C-BC4F-27E409EEFDD3@wur.nl> On 18Oct2005, at 22:49, Mark Wilkinson wrote: > Hi all, > > Eddie and I have been discussing the object ontology migration now > that > we are not allowing inheritance from primitives. No matter what we do > this will break some services, and though I was originally hoping to > soften the blow by having a deprecation period, the amount of pain > this > causes (i.e. everyone having to edit and re-register their services > TWICE!) is just inhumane :-) > > So... I am sure that some of you will cheer this decision, Well usually we have drinks on friday afternoon after work, but it looks we'll have to start next week with a small party :). Changing my services was easy, but starting up my brain on tuesday might be a tough one... > and others > will loathe it... we're going to simply migrate the object ontology > (in > the public MOBY Central here at iCAPTURE) with **no deprecation period > at all**. > > .... > > Any objections? (don't all yell at once ;-) ) NO! > Cheers! > > Mark > Cheers, Pieter > > > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Tue Oct 18 22:02:28 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 18 Oct 2005 23:02:28 +0100 (BST) Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: > So... I am sure that some of you will cheer this decision > I am the one who cheers this decision :-) ...but I do not understand what to change/do... :-( For example, there is a chain: text-formatted inherits from text-plain inherits from String Which object definition are you going to change? I guess the 'text-plain', correct? So now text-plain will contain a String under an article-name 'contents'. And the rest of the hierarchy tree will not be changed. Correct? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Tue Oct 18 22:32:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 18 Oct 2005 15:32:44 -0700 Subject: [personal] Re: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAY OCT 24th In-Reply-To: References: Message-ID: <1129674764.7012.4.camel@bioinfo.icapture.ubc.ca> On Tue, 2005-10-18 at 23:02 +0100, Martin Senger wrote: > > So... I am sure that some of you will cheer this decision > > > I am the one who cheers this decision :-) I knew you would :-) > For example, there is a chain: > text-formatted inherits from text-plain inherits from String > Which object definition are you going to change? I guess the > 'text-plain', correct? So now text-plain will contain a String under an > article-name 'contents'. And the rest of the hierarchy tree will > not be changed. Correct? Correct. We are only modifying the first level of objects that formerly inherited from primitives. Any deeper children's definitions will be "updated" by virtue of inheritance, but not by any modification we make to the ontology (similarly for hasa and has relationships). 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 Oct 18 22:32:59 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 18 Oct 2005 23:32:59 +0100 (BST) Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: <1129668553.6798.17.camel@bioinfo.icapture.ubc.ca> Message-ID: Eddie wrote a new article/guide about biomoby in Taverna. You can read it in usual place http://biomoby.org/moby-live/java/docs. The link is named "How to use BioMoby plugin in Taverna". Thanks, Eddie! Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Wed Oct 19 08:50:06 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 19 Oct 2005 10:50:06 +0200 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: References: Message-ID: On 19-Oct-2005, at 12:32 AM, Martin Senger wrote: > Eddie wrote a new article/guide about biomoby in Taverna. You can > read it > in usual place http://biomoby.org/moby-live/java/docs. Ooops, that link fails. Looks like it's running on a *n*x machine where Capitals make a difference. Try http://biomoby.org/moby-live/Java/docs instead :). > The link is named > "How to use BioMoby plugin in Taverna". Thanks, Eddie! One small comment. The info in that document on how to add a scavanger for a BioMOBY Central is outdated. Furthermore if you want to use a custom / local BioMOBY Central you'll have to install some additional servlets that Eddie created. I wrote a doc on how to get a local Taverna-1.3-compatible BioMOBY Central up and running. It's in ~moby-live/Docs/Central/ , but as far as I know this hasn't made it onto the old nor onto the new website yet... moby-live at biomoby.org is all about moby, but it isn't that live :) Cheers, Pieter > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Wed Oct 19 09:04:17 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 19 Oct 2005 10:04:17 +0100 (BST) Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: Message-ID: > Ooops, that link fails. Looks like it's running on a *n*x machine > where Capitals make a difference. Try > http://biomoby.org/moby-live/Java/docs > instead :). > My typo; thanks for correcting my email. > One small comment. The info in that document on how to add a > scavanger for a BioMOBY Central is outdated. Furthermore if you want > to use a custom / local BioMOBY Central you'll have to install some > additional servlets that Eddie created. > Well, this is not a small comment. I hoped that this docs covered everything needed. I must admit that Tom (Oinn) had warned me (the last time as I have spoken with him) that the moby-taverna docs is not fully "in the shape" - but I thought that this nice Eddie's guide solved it. Perhaps, Eddie will update his guide by the missing pieces. I think that important is that we have now a place (a page) that is visible for the jMoby developers (and users) and that can be easily updated. > I wrote a doc on how to get a local Taverna-1.3-compatible BioMOBY > Central up and running. It's in ~moby-live/Docs/Central/ , but as far > as I know this hasn't made it onto the old nor onto the new website > yet... moby-live at biomoby.org is all about moby, but it isn't that > live :) > The jMoby pages are quite active/live (even though not too many authors there - just four of us: Paul, Eddie, Ben and me). If you have a jMoby (Java) related piece of documentation you may consider to add it to moby-live/Java/docs, and to link it from index.html there. It would be great to have more contributors. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Wed Oct 19 12:52:42 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 19 Oct 2005 05:52:42 -0700 Subject: [MOBY-dev] new article in jMoby docs In-Reply-To: Message-ID: <000001c5d4ac$0038e800$6500a8c0@notebook> > > One small comment. The info in that document on how to > add a > > scavanger for a BioMOBY Central is outdated. Furthermore > if you want > > to use a custom / local BioMOBY Central you'll have to > install some > > additional servlets that Eddie created. I don't think that this belongs in the how to use Taverna documentation. I guess that it should be mentioned in passing. Eddie > Well, this is not a small comment. I hoped that this > docs covered > everything needed. I must admit that Tom (Oinn) had warned > me (the last > time as I have spoken with him) that the moby-taverna docs > is not fully > "in the shape" - but I thought that this nice Eddie's > guide solved it. > Perhaps, Eddie will update his guide by the missing pieces. > I think that > important is that we have now a place (a page) that is > visible for the > jMoby developers (and users) and that can be easily > updated. > > > > I wrote a doc on how to get a local Taverna-1.3- > compatible BioMOBY > > Central up and running. It's in ~moby- > live/Docs/Central/ , but as far > > as I know this hasn't made it onto the old nor onto the > new website > > yet... moby-live at biomoby.org is all about moby, but > it isn't that > > live :) > > > The jMoby pages are quite active/live (even though not > too many authors > there - just four of us: Paul, Eddie, Ben and me). If you > have a jMoby > (Java) related piece of documentation you may consider to > add it to > moby-live/Java/docs, and to link it from index.html there. > It would be > great to have more contributors. > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Wed Oct 19 23:39:06 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 19 Oct 2005 16:39:06 -0700 Subject: [MOBY-dev] Migrating MOBY Central to the new object API - MONDAYOCT 24th In-Reply-To: Message-ID: <001401c5d506$4dccbab0$6500a8c0@notebook> Hi, I have a script that is downloadable from the following address: http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz It goes through your local central and updates the ontology according to the API. Uncompress the contents and take a look at the readme file as it outlines what it does and what it needs from you. If you have any questions, let me know, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Martin > Senger > Sent: Tuesday, October 18, 2005 3:02 PM > To: markw at illuminae.com; Core developer announcements > Subject: Re: [MOBY-dev] Migrating MOBY Central to the new > object API - MONDAYOCT 24th > > > So... I am sure that some of you will cheer this > decision > > > I am the one who cheers this decision :-) > ...but I do not understand what to change/do... :-( > > For example, there is a chain: > text-formatted inherits from text-plain inherits from > String > > Which object definition are you going to change? I > guess the > 'text-plain', correct? So now text-plain will contain a > String under an > article-name 'contents'. And the rest of the hierarchy > tree will > not be changed. Correct? > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Oct 21 09:28:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 21 Oct 2005 11:28:41 +0200 Subject: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: <001201c5d04f$e2e15860$6900a8c0@notebook> References: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: Hi Eddie, On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > Hi Pieter, > > I have uploaded the 2 jar files to > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > There are 2 of them. > > Moreover, I have uploaded some workflows: > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > Test this version out. I believe that I fixed the article > name bug. I have also fixed various other anomalies. > > Let me know how it goes. You're the man! I have been testing for a few days now and so far I haven't been able to spot any anomalies :). Thanks! Pieter > I am going to keep trying to create > workflows that utilize complex Moby datatypes (GeneInfo > comes to mind) to ensure that all is well. > > Thanks a lot, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From aperezp at uma.es Fri Oct 21 11:32:45 2005 From: aperezp at uma.es (=?iso-8859-1?Q?Antonio_J._P=E9rez?=) Date: Fri, 21 Oct 2005 13:32:45 +0200 Subject: [MOBY-dev] Parsing Big XML Objects In-Reply-To: Message-ID: <20051021113249.67C0CC0008@correo2.uma.es> Hi, I have parsing moby objects with the getMobySimples function from MobyXmlObject.pm, but when the object is big (>1-2 Mb) the parsing is desperately slow. Do you know if there is a faster way to do this? Thanks in advance, Antonio. From duncan.hull at cs.man.ac.uk Fri Oct 21 11:17:59 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri, 21 Oct 2005 12:17:59 +0100 Subject: [MOBY-dev] new article in jMoby docs: wish list In-Reply-To: References: Message-ID: <4358CE67.9020307@cs.man.ac.uk> Hello Martin Senger wrote: >If you have a jMoby >(Java) related piece of documentation you may consider to add it to >moby-live/Java/docs, and to link it from index.html there. It would be >great to have more contributors. > > > Talking of jMoby documentation, it would be useful* to have some documentation on the graphs client(s): http://biomoby.org/moby-live/Java/docs/CmdLineClients.html#MobyGraphs http://www.ebi.ac.uk/collab/mygrid/service2/jmoby/graphs *maybe only useful for for me though :) Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From rebecca.ernst at gsf.de Fri Oct 21 12:17:41 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri, 21 Oct 2005 14:17:41 +0200 Subject: [MOBY-dev] Migration to new API Message-ID: <4358DC65.3070103@gsf.de> Hi Mark and others! just wanted to let you know that all MIPS services are migrated already. Unfortunately it took us much longer than 5 Minutes because many of our services used objects which inherited indirectly from string (second and more level in the hierarchy) therefore we had to change a lot of services (the part taking most of the time was to find out which services had to be changed!) And we are certainly happy that we don't have to re-register all of them again (*cheering*) !!! 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 carrere at toulouse.inra.fr Fri Oct 21 14:15:08 2005 From: carrere at toulouse.inra.fr (Sebastien Carrere) Date: Fri, 21 Oct 2005 16:15:08 +0200 Subject: [MOBY-dev] Parsing Big XML Objects In-Reply-To: <20051021113249.67C0CC0008@correo2.uma.es> References: <20051021113249.67C0CC0008@correo2.uma.es> Message-ID: <4358F7EC.6040005@toulouse.inra.fr> Hi, I added the Perl Module (i) we develloped in Toulouse and the mandatory XSLT style-sheet (ii) in the CVS repository to avoid the problem of huge XML messages. i. moby-live/Perl/MOBY/MOBYXSLT.pm ii. moby-live/Perl/MOBY/xsl/parseMobyMessage.xsl This module uses xsltproc to parse XML and builds Perl structures. If you want more information (services examples using this module), do not hesitate. Sebastien Antonio J. P?rez wrote: > Hi, I have parsing moby objects with the getMobySimples function >from MobyXmlObject.pm, but when the object is big (>1-2 Mb) the parsing is >desperately slow. Do you know if there is a faster way to do this? > Thanks in advance, > > Antonio. > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > -- __________________________________________________________ Sebastien CARRERE LIPM (INRA-CNRS) B.P.52627 -- 31326 CASTANET TOLOSAN tel:(33) 5-61-28-53-29 fax:(33) 5-61-28-50-61 From markw at illuminae.com Fri Oct 21 15:53:24 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 21 Oct 2005 08:53:24 -0700 Subject: [moby] Re: [MOBY-dev] Taverna plugin bug?: elements missing in BioMOBYobjects In-Reply-To: References: <001201c5d04f$e2e15860$6900a8c0@notebook> Message-ID: <1129910004.14938.29.camel@bioinfo.icapture.ubc.ca> This is great news - I think we should pass this on to Tom and request a sub-version-release of Taverna now that this is fixed. M On Fri, 2005-10-21 at 11:28 +0200, Pieter Neerincx wrote: > Hi Eddie, > > On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > > > Hi Pieter, > > > > I have uploaded the 2 jar files to > > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > > > There are 2 of them. > > > > Moreover, I have uploaded some workflows: > > > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > > > Test this version out. I believe that I fixed the article > > name bug. I have also fixed various other anomalies. > > > > Let me know how it goes. > > You're the man! I have been testing for a few days now and so far I > haven't been able to spot any anomalies :). > > Thanks! > > Pieter > > > I am going to keep trying to create > > workflows that utilize complex Moby datatypes (GeneInfo > > comes to mind) to ensure that all is well. > > > > Thanks a lot, > > > > Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "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 edward.kawas at gmail.com Fri Oct 21 15:55:23 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 21 Oct 2005 08:55:23 -0700 Subject: [moby] Re: [MOBY-dev] Taverna plugin bug?: elements missing inBioMOBYobjects In-Reply-To: <1129910004.14938.29.camel@bioinfo.icapture.ubc.ca> Message-ID: <002b01c5d657$d9d6a9b0$6500a8c0@notebook> Last time Pieter said that, within hours he replied that he spoke too soon. Let's wait a little longer ;-) Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Friday, October 21, 2005 8:53 AM > To: Core developer announcements > Subject: Re: [moby] Re: [MOBY-dev] Taverna plugin bug?: > elements missing inBioMOBYobjects > > This is great news - I think we should pass this on to Tom > and request a > sub-version-release of Taverna now that this is fixed. > > M > > > > On Fri, 2005-10-21 at 11:28 +0200, Pieter Neerincx wrote: > > Hi Eddie, > > > > On 14-Oct-2005, at 1:43 AM, Edward Kawas wrote: > > > > > Hi Pieter, > > > > > > I have uploaded the 2 jar files to > > > http://bioinfo.icapture.ubc.ca/ekawas/jars/ > > > > > > There are 2 of them. > > > > > > Moreover, I have uploaded some workflows: > > > > > > http://bioinfo.icapture.ubc.ca/ekawas/workflows/ > > > > > > Test this version out. I believe that I fixed the > article > > > name bug. I have also fixed various other anomalies. > > > > > > Let me know how it goes. > > > > You're the man! I have been testing for a few days now > and so far I > > haven't been able to spot any anomalies :). > > > > Thanks! > > > > Pieter > > > > > I am going to keep trying to create > > > workflows that utilize complex Moby datatypes > (GeneInfo > > > comes to mind) to ensure that all is well. > > > > > > Thanks a lot, > > > > > > Eddie > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Sun Oct 23 18:11:31 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 23 Oct 2005 19:11:31 +0100 (BST) Subject: [MOBY-dev] new article in jMoby docs: wish list In-Reply-To: <4358CE67.9020307@cs.man.ac.uk> Message-ID: > Talking of jMoby documentation, it would be useful* to have some > documentation on the graphs client(s): > > http://biomoby.org/moby-live/Java/docs/CmdLineClients.html#MobyGraphs > http://www.ebi.ac.uk/collab/mygrid/service2/jmoby/graphs > Good point. I have, still in my TODO list, a bug reported by Ben about this graphs client. I will look at it when I finish my current "project" (a Biomoby dashboard client for service providers). And it that time I will fix also the docs. Promise. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From ed.kawas at gmail.com Tue Oct 25 21:23:35 2005 From: ed.kawas at gmail.com (Eddie Kawas) Date: Tue, 25 Oct 2005 14:23:35 -0700 Subject: [MOBY-dev] Mobycentral has been updated Message-ID: <001e01c5d9aa$5d062a40$6600a8c0@notebook> Hi, Mobycentral has had its object ontology updated, i.e. there no longer exists data types that inherit from primitives. Moreover, if you are interested in updating your ontology, download the migration 'script' from http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz and follow the directions inside the archive. Thanks, Eddie From edward.kawas at gmail.com Tue Oct 25 21:24:09 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 25 Oct 2005 14:24:09 -0700 Subject: [MOBY-dev] Mobycentral has been updated Message-ID: <001f01c5d9aa$7109c2e0$6600a8c0@notebook> Hi, Mobycentral has had its object ontology updated, i.e. there no longer exists data types that inherit from primitives. Moreover, if you are interested in updating your ontology, download the migration 'script' from http://bioinfo.icapture.ubc.ca/ekawas/migration/migration.ta r.gz and follow the directions inside the archive. Thanks, Eddie From senger at ebi.ac.uk Thu Oct 27 00:38:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 27 Oct 2005 01:38:49 +0100 (BST) Subject: [MOBY-dev] bad LSIDs produced by biomoby registry Message-ID: Eddie & Mark, Could you please fix the LSID creation: the entity name must be 'escaped' if it has characters that are not allowed in the LSID parts, especially colons. An example is a namespace named GOA:hamap that gets LSID: urn:lsid:biomoby.org:namespacetype:GOA:hamap which is, IMHO, wrong. It should be something like: urn:lsid:biomoby.org:namespacetype:GOA_hamap (but obviousy you need to do it in a way that allows you to map back the escaped lsid to the original entity). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: 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 Wed Oct 26 22:18:57 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 26 Oct 2005 15:18:57 -0700 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting Message-ID: <002801c5da7b$42e36ac0$6600a8c0@notebook> Hi, I am calling a vote on the RFC that discusses error reporting. Please refer to the following link: http://bugzilla.open-bio.org/show_bug.cgi?id=1863 Thanks. From senger at ebi.ac.uk Thu Oct 27 01:26:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 27 Oct 2005 02:26:14 +0100 (BST) Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > I believe that the casual consensus was that we will carry on votes by email and not in the bugzilla obscure pages. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From francis_gibbons at hms.harvard.edu Thu Oct 27 13:56:28 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 27 Oct 2005 09:56:28 -0400 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> I vote in favour of RFC 1863 (I've added my vote in bugzilla too). Martin, I agree that bugzilla is currently fairly obscure, mostly because nobody has had a reason to go there until recently. However, I think if you hang out there a little, you'll find it's not so inhospitable. It has the advantage of making it much easier to track the history of our decisions. It is also quite a bit easier to associate documents with those decisions, especially as they are revised over time. -Frank At 09:26 PM 10/26/2005, you wrote: > > I am calling a vote on the RFC that discusses error > > reporting. > > > > Please refer to the following link: > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > > I believe that the casual consensus was that we will carry on votes by >email and not in the bugzilla obscure pages. > > Martin > >-- >Martin Senger > email: martin.senger at gmail.com > skype: martinsenger >consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 gordonp at ucalgary.ca Thu Oct 27 14:32:29 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 27 Oct 2005 08:32:29 -0600 Subject: [MOBY-dev] bad LSIDs produced by biomoby registry In-Reply-To: References: Message-ID: <4360E4FD.6090202@ucalgary.ca> As this is a URN, you must use the percent sign hex character encoding for such cases e.g. urn:lsid:biomoby.org:namespacetype:GOA%3Ahamap The implication of course is that a URN resolver should always decode such strings properly. >Eddie & Mark, > Could you please fix the LSID creation: the entity name must be >'escaped' if it has characters that are not allowed in the LSID parts, >especially colons. An example is a namespace named GOA:hamap that gets >LSID: > urn:lsid:biomoby.org:namespacetype:GOA:hamap >which is, IMHO, wrong. It should be something like: > urn:lsid:biomoby.org:namespacetype:GOA_hamap >(but obviousy you need to do it in a way that allows you to map >back the escaped lsid to the original entity). > > Cheers, > Martin > > > From gordonp at ucalgary.ca Thu Oct 27 14:32:29 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 27 Oct 2005 08:32:29 -0600 Subject: [MOBY-dev] bad LSIDs produced by biomoby registry In-Reply-To: References: Message-ID: <4360E4FD.6090202@ucalgary.ca> As this is a URN, you must use the percent sign hex character encoding for such cases e.g. urn:lsid:biomoby.org:namespacetype:GOA%3Ahamap The implication of course is that a URN resolver should always decode such strings properly. >Eddie & Mark, > Could you please fix the LSID creation: the entity name must be >'escaped' if it has characters that are not allowed in the LSID parts, >especially colons. An example is a namespace named GOA:hamap that gets >LSID: > urn:lsid:biomoby.org:namespacetype:GOA:hamap >which is, IMHO, wrong. It should be something like: > urn:lsid:biomoby.org:namespacetype:GOA_hamap >(but obviousy you need to do it in a way that allows you to map >back the escaped lsid to the original entity). > > Cheers, > Martin > > >