From akerhornou at imim.es Mon Jul 3 06:46:27 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 12:46:27 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 Message-ID: <44A8F583.8050700@imim.es> Hi everyone, I'd would like to track information about requests i receive from always the same IP address, 137.82.67.190. They don't really affect our services, i'm just curious about what's behind this. i can't map this IP address to a DNS entry, and it seems to request the services at 'genome.imim.es' on a regular basis, with empty an mobyData bloc, so they always fail. Is it happening to anyone else ? thanks Arnaud From senger at ebi.ac.uk Mon Jul 3 07:17:09 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 12:17:09 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A8F583.8050700@imim.es> Message-ID: > I'd would like to track information about requests i receive from always > the same IP address, 137.82.67.190. > My trace router locates this IP address to Vancouver (network UBC). Perhaps the famous moby agent? :-) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Sebastien.Carrere at toulouse.inra.fr Mon Jul 3 07:33:41 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Mon, 03 Jul 2006 13:33:41 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: Message-ID: <44A90095.3060302@toulouse.inra.fr> Bonjour a tous, I've got the same huge amount of requests ... The last point reached by my router is : stpaulshub1.net.ubc.ca Sebastien Martin Senger a ?crit : >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. >> >> > My trace router locates this IP address to Vancouver (network UBC). > Perhaps the famous moby agent? :-) > > Martin > > -- __________________________________________________________ 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 Sebastien.Carrere at toulouse.inra.fr Mon Jul 3 07:33:41 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Mon, 03 Jul 2006 13:33:41 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: Message-ID: <44A90095.3060302@toulouse.inra.fr> Bonjour a tous, I've got the same huge amount of requests ... The last point reached by my router is : stpaulshub1.net.ubc.ca Sebastien Martin Senger a ?crit : >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. >> >> > My trace router locates this IP address to Vancouver (network UBC). > Perhaps the famous moby agent? :-) > > Martin > > -- __________________________________________________________ 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 tmo at ebi.ac.uk Mon Jul 3 07:56:56 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 03 Jul 2006 12:56:56 +0100 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A90095.3060302@toulouse.inra.fr> References: <44A90095.3060302@toulouse.inra.fr> Message-ID: <44A90608.2070800@ebi.ac.uk> Sebastien Carrere wrote: > Bonjour a tous, > > I've got the same huge amount of requests ... > The last point reached by my router is : stpaulshub1.net.ubc.ca It's Mark's secret moby robot designed to up the hits for the next grant report :p Nah, just kidding, I've no idea what it is... Tom From tmo at ebi.ac.uk Mon Jul 3 07:56:56 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 03 Jul 2006 12:56:56 +0100 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A90095.3060302@toulouse.inra.fr> References: <44A90095.3060302@toulouse.inra.fr> Message-ID: <44A90608.2070800@ebi.ac.uk> Sebastien Carrere wrote: > Bonjour a tous, > > I've got the same huge amount of requests ... > The last point reached by my router is : stpaulshub1.net.ubc.ca It's Mark's secret moby robot designed to up the hits for the next grant report :p Nah, just kidding, I've no idea what it is... Tom From markw at illuminae.com Mon Jul 3 09:01:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Jul 2006 06:01:20 -0700 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A8F583.8050700@imim.es> References: <44A8F583.8050700@imim.es> Message-ID: This is Eddie's "isAlive?" script. It runs on a cron and hits every service in the registry with an empty mobyData block to see if the service responds with the same (as per the API). If not, the service is flagged as "dead" and this information is available in the LSID metadata for that service. We just started experimenting with this last week. If it is bothering you we can reduce the frequency of the cron... I don't actually know how frequent it is right now. M On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou wrote: > Hi everyone, > > I'd would like to track information about requests i receive from always > the same IP address, 137.82.67.190. They don't really affect our > services, i'm just curious about what's behind this. > i can't map this IP address to a DNS entry, and it seems to request the > services at 'genome.imim.es' on a regular basis, with empty an mobyData > bloc, so they always fail. > > Is it happening to anyone else ? > > thanks > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Jul 3 09:01:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Jul 2006 06:01:20 -0700 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A8F583.8050700@imim.es> References: <44A8F583.8050700@imim.es> Message-ID: This is Eddie's "isAlive?" script. It runs on a cron and hits every service in the registry with an empty mobyData block to see if the service responds with the same (as per the API). If not, the service is flagged as "dead" and this information is available in the LSID metadata for that service. We just started experimenting with this last week. If it is bothering you we can reduce the frequency of the cron... I don't actually know how frequent it is right now. M On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou wrote: > Hi everyone, > > I'd would like to track information about requests i receive from always > the same IP address, 137.82.67.190. They don't really affect our > services, i'm just curious about what's behind this. > i can't map this IP address to a DNS entry, and it seems to request the > services at 'genome.imim.es' on a regular basis, with empty an mobyData > bloc, so they always fail. > > Is it happening to anyone else ? > > thanks > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From akerhornou at imim.es Mon Jul 3 09:15:11 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 15:15:11 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: <44A8F583.8050700@imim.es> Message-ID: <44A9185F.4010502@imim.es> Mark Wilkinson wrote: > This is Eddie's "isAlive?" script. It runs on a cron and hits every > service in the registry with an empty mobyData block to see if the > service responds with the same (as per the API). If not, the service > is flagged as "dead" and this information is available in the LSID > metadata for that service. We just started experimenting with this > last week. > > If it is bothering you we can reduce the frequency of the cron... I > don't actually know how frequent it is right now. > it doesn't really affect the services, just the access and success rate statistics ;-) > M > > > > > On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou > wrote: > >> Hi everyone, >> >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. They don't really affect our >> services, i'm just curious about what's behind this. >> i can't map this IP address to a DNS entry, and it seems to request the >> services at 'genome.imim.es' on a regular basis, with empty an mobyData >> bloc, so they always fail. >> >> Is it happening to anyone else ? >> >> thanks >> Arnaud >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From senger at ebi.ac.uk Mon Jul 3 09:25:28 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:25:28 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: Message-ID: > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 09:25:28 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:25:28 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: Message-ID: > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From akerhornou at imim.es Mon Jul 3 09:15:11 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 15:15:11 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: <44A8F583.8050700@imim.es> Message-ID: <44A9185F.4010502@imim.es> Mark Wilkinson wrote: > This is Eddie's "isAlive?" script. It runs on a cron and hits every > service in the registry with an empty mobyData block to see if the > service responds with the same (as per the API). If not, the service > is flagged as "dead" and this information is available in the LSID > metadata for that service. We just started experimenting with this > last week. > > If it is bothering you we can reduce the frequency of the cron... I > don't actually know how frequent it is right now. > it doesn't really affect the services, just the access and success rate statistics ;-) > M > > > > > On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou > wrote: > >> Hi everyone, >> >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. They don't really affect our >> services, i'm just curious about what's behind this. >> i can't map this IP address to a DNS entry, and it seems to request the >> services at 'genome.imim.es' on a regular basis, with empty an mobyData >> bloc, so they always fail. >> >> Is it happening to anyone else ? >> >> thanks >> Arnaud >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From senger at ebi.ac.uk Mon Jul 3 09:29:49 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:29:49 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A9185F.4010502@imim.es> Message-ID: > it doesn't really affect the services, just the access and success rate > statistics ;-) > Well, every hit affect your srevices :-) And you are definitely right about the statistics: Such automatic tool should have a distinguish signature (HTTP_USER_AGENT variable). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 09:29:49 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:29:49 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A9185F.4010502@imim.es> Message-ID: > it doesn't really affect the services, just the access and success rate > statistics ;-) > Well, every hit affect your srevices :-) And you are definitely right about the statistics: Such automatic tool should have a distinguish signature (HTTP_USER_AGENT variable). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From darin.london at duke.edu Mon Jul 3 08:41:33 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 03 Jul 2006 08:41:33 -0400 Subject: [MOBY-dev] Call For Birds of a Feather Suggestions Message-ID: <44A9107D.2050304@duke.edu> The BOSC organizing comittee is currently seeking suggestions for Birds of a Feather meeting ideas. Birds of a Feather meetings are one of the more popular activities at BOSC, occurring at the end of each days session. These are free-form meetings organized by the attendees themselves to discuss one or a few topics of interest in greater detail. BOF?s have been formed to allow developers and users of individual OBF software to meet each other face-to-face to discuss the project, or to discuss completely new ideas, and even start new software development projects. These meetings offer a unique opportunity for individuals to explore more about the activities of the various Open Source Projects, and, in some cases, even take an active role influencing the future of Open Source Software development. If you would like to create a BOF, just sign up for a wiki account, login, and edit the BOSC 2006 Birds of a Feather page. From markw at illuminae.com Mon Jul 3 10:24:43 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 3 Jul 2006 14:24:43 +0000 GMT Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> I'm on my blackberry at the moment so I can't point you to a document directly right now, however I can explain more fully. It likely isn't stated outright in the API, but it is a consequence of other API requirements. One requirement is that there must be one mobyData block in the output for every mobyData block in the input, regardless of whether or not you were able to process it. It says something like that in the API, but as I said, I don't have access to the docs right now. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Mon, 3 Jul 2006 14:25:28 To:Mark Wilkinson Cc:mobydev , Core developer announcements Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Jul 3 10:24:43 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 3 Jul 2006 14:24:43 +0000 GMT Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> I'm on my blackberry at the moment so I can't point you to a document directly right now, however I can explain more fully. It likely isn't stated outright in the API, but it is a consequence of other API requirements. One requirement is that there must be one mobyData block in the output for every mobyData block in the input, regardless of whether or not you were able to process it. It says something like that in the API, but as I said, I don't have access to the docs right now. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Mon, 3 Jul 2006 14:25:28 To:Mark Wilkinson Cc:mobydev , Core developer announcements Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From akerhornou at imim.es Mon Jul 3 10:35:24 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 16:35:24 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <736246661-1151936853-cardhu_blackberry.rim.net-21340-@engine26-cell01> References: <44A8F583.8050700@imim.es> <44A9185F.4010502@imim.es> <736246661-1151936853-cardhu_blackberry.rim.net-21340-@engine26-cell01> Message-ID: <44A92B2C.8000200@imim.es> mark wilkinson wrote: > I would call it a "success" if it returns an empty mobyData block :-) > > It all depends how you define success! > > It returns an empty mobyData block but because it fails the input validation step - the service is not expecting an empty input mobyData bloc,so it returns in the service note the exception code, 201 - "INPUTS_INVALID" Arn. > M > > > -- > Mark Wilkinson > ...on the road! > > > -----Original Message----- > From: Arnaud Kerhornou > Date: Mon, 03 Jul 2006 15:15:11 > To:Core developer announcements > Cc:mobydev > Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP > address - 137.82.67.190 > > > > Mark Wilkinson wrote: > >> This is Eddie's "isAlive?" script. It runs on a cron and hits every >> service in the registry with an empty mobyData block to see if the >> service responds with the same (as per the API). If not, the service >> is flagged as "dead" and this information is available in the LSID >> metadata for that service. We just started experimenting with this >> last week. >> >> If it is bothering you we can reduce the frequency of the cron... I >> don't actually know how frequent it is right now. >> >> > it doesn't really affect the services, just the access and success rate > statistics ;-) > >> M >> >> >> >> >> On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou >> wrote: >> >> >>> Hi everyone, >>> >>> I'd would like to track information about requests i receive from always >>> the same IP address, 137.82.67.190. They don't really affect our >>> services, i'm just curious about what's behind this. >>> i can't map this IP address to a DNS entry, and it seems to request the >>> services at 'genome.imim.es' on a regular basis, with empty an mobyData >>> bloc, so they always fail. >>> >>> Is it happening to anyone else ? >>> >>> thanks >>> Arnaud >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon Jul 3 10:27:33 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 3 Jul 2006 14:27:33 +0000 GMT Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <44A9185F.4010502@imim.es> References: <44A8F583.8050700@imim.es> <44A9185F.4010502@imim.es> Message-ID: <736246661-1151936853-cardhu_blackberry.rim.net-21340-@engine26-cell01> I would call it a "success" if it returns an empty mobyData block :-) It all depends how you define success! M -- Mark Wilkinson ...on the road! -----Original Message----- From: Arnaud Kerhornou Date: Mon, 03 Jul 2006 15:15:11 To:Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 Mark Wilkinson wrote: > This is Eddie's "isAlive?" script. It runs on a cron and hits every > service in the registry with an empty mobyData block to see if the > service responds with the same (as per the API). If not, the service > is flagged as "dead" and this information is available in the LSID > metadata for that service. We just started experimenting with this > last week. > > If it is bothering you we can reduce the frequency of the cron... I > don't actually know how frequent it is right now. > it doesn't really affect the services, just the access and success rate statistics ;-) > M > > > > > On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou > wrote: > >> Hi everyone, >> >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. They don't really affect our >> services, i'm just curious about what's behind this. >> i can't map this IP address to a DNS entry, and it seems to request the >> services at 'genome.imim.es' on a regular basis, with empty an mobyData >> bloc, so they always fail. >> >> Is it happening to anyone else ? >> >> thanks >> Arnaud >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Mon Jul 3 10:37:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 15:37:54 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> Message-ID: > It likely isn't stated outright in the API, but it is a consequence of > other API requirements. One requirement is that there must be one > mobyData block in the output for every mobyData block in the input, > regardless of whether or not you were able to process it. > Well, we can argue this logic :-) However, more important is that this mechanism is not a bad one for the thing we were talking many times - a 'ping' request. Therefore, I will be happy to add it to the services generated from Moses. But I suggest to do first: * a clear definition of this feature in the MOBY API; * including a suggested value for HTTP_USER_AGENT variable that should be used when this 'ping' is invoked; * give service providers time (a deadline) for including this into their services - and only after that your agent should consider services 'dead'. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 10:37:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 15:37:54 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> Message-ID: > It likely isn't stated outright in the API, but it is a consequence of > other API requirements. One requirement is that there must be one > mobyData block in the output for every mobyData block in the input, > regardless of whether or not you were able to process it. > Well, we can argue this logic :-) However, more important is that this mechanism is not a bad one for the thing we were talking many times - a 'ping' request. Therefore, I will be happy to add it to the services generated from Moses. But I suggest to do first: * a clear definition of this feature in the MOBY API; * including a suggested value for HTTP_USER_AGENT variable that should be used when this 'ping' is invoked; * give service providers time (a deadline) for including this into their services - and only after that your agent should consider services 'dead'. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 14:37:42 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 19:37:42 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <44A92B2C.8000200@imim.es> Message-ID: > It returns an empty mobyData block but because it fails the input > validation step - the service is not expecting an empty input mobyData > bloc,so it returns in the service note the exception code, 201 - > "INPUTS_INVALID" > See, Mark? It seems that I am not the only one who did not know that this is part of the API :-) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From aloraine at gmail.com Mon Jul 3 17:07:42 2006 From: aloraine at gmail.com (Ann Loraine) Date: Mon, 3 Jul 2006 16:07:42 -0500 Subject: [MOBY-dev] new to list - python? Message-ID: <83722dde0607031407t3f291ecfy77e013e8ad858c6f@mail.gmail.com> Hi, Is anyone on the list working on (or thinking about) a python BioMoby API? Best, Ann Loraine -- Ann Loraine Assistant Professor Section on Statistical Genetics University of Alabama at Birmingham http://www.ssg.uab.edu http://www.transvar.org From markw at illuminae.com Mon Jul 3 18:59:54 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Jul 2006 15:59:54 -0700 Subject: [MOBY-dev] new to list - python? In-Reply-To: <83722dde0607031407t3f291ecfy77e013e8ad858c6f@mail.gmail.com> References: <83722dde0607031407t3f291ecfy77e013e8ad858c6f@mail.gmail.com> Message-ID: There is a Python folder in the moby-live CVS checkout. The original developer of the Python API, however, has left the project for greener pastures. I don't know what the current state of that Python code is... but you are welcome to have a look at it! Mark On Mon, 03 Jul 2006 14:07:42 -0700, Ann Loraine wrote: > Hi, > > Is anyone on the list working on (or thinking about) a python BioMoby > API? > > Best, > > Ann Loraine > From jmrodriguez at cnio.es Tue Jul 4 07:33:04 2006 From: jmrodriguez at cnio.es (Jose Manuel Rodriguez) Date: Tue, 04 Jul 2006 13:33:04 +0200 Subject: [MOBY-dev] exception reporting Message-ID: <44AA51F0.3020301@cnio.es> Hi everyone, I implemented the ability to report exception in the client side. I have the code in SVN server where you can see the code and information in HTML format related to. Even, there is tester script. The URL is http://www.inab.org/svn/Exception/. I hope help you. If you have any doubt...ask me. Best Regards, Jos?. Mark Wilkinson wrote: > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From usadel at mpimp-golm.mpg.de Tue Jul 4 09:25:21 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Tue, 04 Jul 2006 15:25:21 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <44AA6C41.5070102@mpimp-golm.mpg.de> Actually, I interpreted it the same way, so I always send back a serviceNote either 700_OK or whatever I consider the main error is at that moment. However, I guess this should be ok, if only the mobyData block is evaluated. Since exception and notes are decoupled from the data block. A problem might rather be the statement that "the same" data block is returned, since IMHO there would be different ways to write the same message, but I guess this is covered by keepAlive. I generally think it is a good idea, to test service availability and would even support to go further as to supply input/output pairs. Since I can figure out if a service is alive but not if I get back what I expected (e.g. always an empty data block) The API description is here: "There must be as many mobyData response elements as there were mobyData input elements (if a service can not respond to a specific query for whatever reason, this element may be empty!)" http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/OutputMessage.html Cheers, Bj?rn Martin Senger wrote: >> It returns an empty mobyData block but because it fails the input >> validation step - the service is not expecting an empty input mobyData >> bloc,so it returns in the service note the exception code, 201 - >> "INPUTS_INVALID" >> > See, Mark? It seems that I am not the only one who did not know that > this is part of the API :-) > > Martin > -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From markw at illuminae.com Tue Jul 4 10:43:57 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 04 Jul 2006 07:43:57 -0700 Subject: [MOBY-dev] [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <44AA6C41.5070102@mpimp-golm.mpg.de> References: <44AA6C41.5070102@mpimp-golm.mpg.de> Message-ID: <1152024237.25431.23.camel@bioinfo.icapture.ubc.ca> Hmmmmm... and I thought that section of the API was unambiguous :-) but it appears that >66% of the services function the "right" way, so at least some people are able to read my mind!! ;-) (or they copy/pasted my service examples) I seem to have not received some of the messages being quoted here... but it sounds like there is general agreement that the behaviour (I thought was) defined in the API, is a desirable one. This behaviour is also important for cases where, for example, the service HAS no input. For example, consider a service that returns randomly chosen sequences from a database. The service takes no input, and returns FASTA as output. The only way to indicate to that service that you want it to return 18 sequences would be to provide 18 mobyData blocks, each with its own queryID, but otherwise empty. An empty mobyData, in this case, is not only expected but it would be hard to elicit this behaviour any other way given the current API. So, unless there is any objection, I or Eddie will clarify and tighten- up the wording of this section of the API and send it out to everyone for comment to make sure that it is clear enough, and that it accurately represents the behaviour we need/expect. v.v. the "isAlive" script that started this whole conversation: AFAIK the only client that reads the "isAlive" predicate in the LSID metadata is the gbrowse_moby that is on MOBY Central. I needed to "weed out" dead services in order to re-submit the gbrowse_moby manuscript for review. (The last time I sent it to Bioinformatics the reviewers rejected it because many services were dead... which is ridiculous, of course... it's like rejecting Firefox as a browser because of404 errors! Anyway... I wont be submitting it there again!) thanks for all your input! It was great to see a flurry of activity on the list - it's reassuring that the project is still very much alive! Cheers all! Mark On Tue, 2006-07-04 at 15:25 +0200, Bj?rn Usadel wrote: > Actually, > > I interpreted it the same way, so I always send back a serviceNote > either 700_OK or whatever I consider the main error is at that moment. > > However, I guess this should be ok, if only the mobyData block is > evaluated. Since exception and notes are decoupled from the data block. > A problem might rather be the statement that "the same" data block is > returned, since IMHO there would be different ways to write the same > message, but I guess this is covered by keepAlive. > > I generally think it is a good idea, to test service availability and > would even support to go further as to supply input/output pairs. Since > I can figure out if a service is alive but not if I get back what I > expected (e.g. always an empty data block) > > > The API description is here: > "There must be as many mobyData response elements as there were mobyData > input elements (if a service can not respond to a specific query for > whatever reason, this element may be empty!)" > > http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/OutputMessage.html > > Cheers, > Bj?rn > > Martin Senger wrote: > >> It returns an empty mobyData block but because it fails the input > >> validation step - the service is not expecting an empty input mobyData > >> bloc,so it returns in the service note the exception code, 201 - > >> "INPUTS_INVALID" > >> > > See, Mark? It seems that I am not the only one who did not know that > > this is part of the API :-) > > > > Martin > > > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Tue Jul 4 11:14:25 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 4 Jul 2006 16:14:25 +0100 (BST) Subject: [MOBY-dev] [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <1152024237.25431.23.camel@bioinfo.icapture.ubc.ca> Message-ID: > (or they copy/pasted my service examples) > I guess so - that's how I found it. Anyway, I am implementing just now a new Perl library, so I would like to know what should be there. We all seem in agreement that a 'ping' feature is a good one, and we also seem to agree that it can be done by sending "something empty" back. Now, please tell me (rather exactly) the following (you may put the answer into MOBY-API docs and we are done): 1) The 'ping' feature (meaning that the service does not do anything except sending back an empty response) is considered when a request: - has no mobyData elements ("jobs"), OR - has a mobyData element, but without any simple or collection in it? Which is the right answer? 2) [This may already be answered by the previous question.] How does the 'ping' differ from a service that does not expect any input data (such as a HelloWorld service)? Mark already explained this case in his email - but I was not sure how to understand it. 3) When I am sending a 'ping' request, should I set an HTTP variable indicating the client (usually the HTTP_USER_AGENT) to some special value? If yes, which one? Thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Tue Jul 4 12:01:34 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 04 Jul 2006 09:01:34 -0700 Subject: [MOBY-dev] [personal] Re: [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-07-04 at 16:14 +0100, Martin Senger wrote: > 1) The 'ping' feature (meaning that the service does not do anything > except sending back an empty response) is considered when a request: > - has no mobyData elements ("jobs"), OR > - has a mobyData element, but without any simple or collection in it? > Which is the right answer? My interpretation of the *current* API is that a message with no mobyData element is considered an invalid message (or at least, we have not yet defined a behaviour for this case) and that a "ping" is when a request message has a mobyData element, with no Simple or Collection in it. ***HOWEVER***, I am not sure that this is a good thing: see further thoughts below > 2) [This may already be answered by the previous question.] How does > the 'ping' differ from a service that does not expect any input data > (such as a HelloWorld service)? > Mark already explained this case in his email - but I was not sure how > to understand it. I don't think there is a difference at the moment, and that's a problem. Given the current API a mobyData element with no content is the simplest form of a valid MOBY message. As such, there is no way to distinguish between a "ping" and an intentional service invocation of a service that requires no input. This is a dangerous situation if, for example, the service is a "database dump" service - registered as consuming no input, and dumping an entire database as output! This service would be invoked by our "ping", and this is not a desirable behaviour!! Perhaps it would be better to reserve an empty mobyData block for intentional service invocations (i.e. no changes to the current API with respect to balancing input/output mobyData elements) and define a "ping" as a MOBY message that contains no mobyData block at all (i.e. an extension to the current API) What do you think? > 3) When I am sending a 'ping' request, should I set an HTTP variable > indicating the client (usually the HTTP_USER_AGENT) to some special > value? If yes, which one? Also a good idea. I'd like to take some time to think about this before making any suggestions... does anyone else have suggestions? M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Tue Jul 4 12:15:30 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 4 Jul 2006 17:15:30 +0100 (BST) Subject: [MOBY-dev] [personal] Re: [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> Message-ID: > Perhaps it would be better to reserve an empty mobyData block for > intentional service invocations (i.e. no changes to the current API with > respect to balancing input/output mobyData elements) and define a "ping" > as a MOBY message that contains no mobyData block at all (i.e. an > extension to the current API) > I like this much more than the current 'dangerous' ambiguity. The only disadvantage is that the services need to be updated. (But again, those who are aware of the current 'ping' feature are probably those who are using CommonSubs anyway - so an update of CommonSubs is sufficinet.) > Also a good idea. I'd like to take some time to think about this before > making any suggestions... does anyone else have suggestions? > Just look at http://www.siteware.ch/webresources/useragents/ how many user agents are already around (I do not know how up-to-date the page is). Cheers, Martin PS. I have removed the email (from this thread) from Spain, mentioning the ability not only to 'ping' a service but also to run it with a pre-defined ste of data. We have a CVS module doing exactly that already. If you are interested please check the page http://moby.generationcp.org/mobyenv/index.html. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From usadel at mpimp-golm.mpg.de Wed Jul 5 16:59:24 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Wed, 05 Jul 2006 22:59:24 +0200 Subject: [MOBY-dev] [personal] Re: [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> References: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> Message-ID: <44AC282C.9010505@mpimp-golm.mpg.de> > > My interpretation of the *current* API is that a message with no > mobyData element is considered an invalid message (or at least, we have > not yet defined a behaviour for this case) and that a "ping" is when a > request message has a mobyData element, with no Simple or Collection in > it. > I think I might be missing something about the no simples/collection and mobyData balancing. Usually perl example services seem to start like this: my $inputs= serviceInputParser($incoming_message); # # or fail properly with an empty response if there is no input return SOAP::Data->type('base64' => responseHeader("my.authURI.com") . responseFooter()) unless (keys %$inputs); Thus replying with a message devoid of any data block, if queried with an empty mobyData block. Since CommonSubs:serviceInputParser only seems to initialize input_parameters if there are any articles within the mobyData blocks. (Verified with a minimal block w/o Simples inside) Or is this where I am missing something important? Also on the input API site it states: " " so not even invoking the service would be an option? Can someone enlighten me please? Or is this just another consequence of the current ambiguity? >Perhaps it would be better to reserve an empty mobyData block for >intentional service invocations (i.e. no changes to the current API with > respect to balancing input/output mobyData elements) and define a "ping" > as a MOBY message that contains no mobyData block at all (i.e. an > extension to the current API) Anyhow, even though I consider a ping service as being important, it should be possible with no code changes at all within the services. Therefore, I also favor the solution which is devoid of any mobyData block. Thus, if the API were extended by specifying that a message with no mobyData element is considered a ping where the reply should be any kind of moby header + footer. (+- servicenotes and exceptions), I guess most everyone (using perl at least) should be auto-compliant with this. (Assuming that most users copied the examples or at least used them as a template) Moreover, this should also generate the lowest overhead in the perl services, since they stop immediately. Cheers, Bj?rn From markw at illuminae.com Thu Jul 6 12:12:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:12:29 -0700 Subject: [MOBY-dev] Object ontology curated in the text-* branch Message-ID: <1152202349.31293.11.camel@bioinfo.icapture.ubc.ca> Hi all, In the absence of any objection to my request last week, I bravely went into the database this morning and re-wired the roots of the text-* branch of the Object ontology. Anyway, it looks much better now. There are still some objects at the root level of the ontology that clearly should be children of text-* objects, for example iANT_BLAST-Text, however I cannot curate these manually because the articleName for the contained string is more specific than "content"; I would break the service if I curated it to inherit from text-formatted. Hopefully the providers will eventually find time and motivation to go in and re-register their object/service. There's also the text_plain branch that would be nice to get rid of completely, but we will have to contact individual service providers who are using these objects to request this change. Please let me know ASAP if you notice anything unusual after this edit, M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 12:13:52 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:13:52 -0700 Subject: [MOBY-dev] v.v. the Object Ontology curation Message-ID: <1152202432.31293.13.camel@bioinfo.icapture.ubc.ca> Dashboard users - don't forget to reload the ontology from source. M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Jul 6 12:21:56 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:21:56 +0100 (BST) Subject: [MOBY-dev] v.v. the Object Ontology curation In-Reply-To: <1152202432.31293.13.camel@bioinfo.icapture.ubc.ca> Message-ID: > Dashboard users - don't forget to reload the ontology from source. > Yes. Just a reminder: Now when the registry supports fully LSIDs with versions, you do not need to 'reload' but should be sufficient to 'update' - just use a different button (this should update only those data types that were really changed, so it is faster than reload). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Thu Jul 6 12:23:28 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:23:28 +0100 (BST) Subject: [MOBY-dev] Object ontology curated in the text-* branch In-Reply-To: <1152202349.31293.11.camel@bioinfo.icapture.ubc.ca> Message-ID: Doing the cleaning you could consider to get rid of these Lincoln's (?) old sins, eg. snp_allele not having any parent. (Dashboard can show you them.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jul 6 12:24:46 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:24:46 -0700 Subject: [MOBY-dev] Request for good behaviour Message-ID: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Hi all, As I was poking around the Object ontology this morning I noticed some things that made me "cry". In particular, the way some objects are being defined is... well... not very helpful! The best example is Object Name: "TC" Description: "TC" Another example Object Name: AvailableMaterial Description: Object containing information about available material I am not sure that, given these descriptions, either of these Objects can be used by anyone other than their original author, which kind of defeats the purpose of having an Object ontology :-) The *king* of good object descriptions has got to be Martin Senger, and I think that some of mine are pretty good too... so here are two examples that show how I think it should be done: ================================= Object Name: Regexp Description: This object can carry a regular expression. It can also say what kind of regular expression is carried. Additionally, it can contain some flags that may not be (in some regular expression languages) put directly in the regular expression. The only mandatory member is the regular expression itself ("regex"). The other members are: "format" specifies what language/format/engine is the "regex" for; typical values are Java, Perl, POSIX. "case_insensitive" is a flag that enables case-insensitive matching. "multiline_mode" is a flag that enables multiline mode. In multiline mode the expressions ^ and $ match just after or just before, respectively, a line terminator or the end of the input. "dotall_mode" is a flag that enables dotall mode. In dotall mode, the expression . matches any character, including a line terminator (in Perl, this mode is called single-line mode). "literal_mode" is a flag that enables literal parsing of the pattern. When this flag is specified then the input string that specifies the pattern is treated as a sequence of literal characters. Metacharacters or escape sequences in the input sequence will be given no special meaning. "comments" is a human-readable text explaining what this regular expression means. =============================================== Object Name: GeneticMap Description: A representation of a genetic map. The contained Float (Length) indicates the full length of the map. The contained MappedLocus objects indicate the loci on the map, and their positions. It is likely that the namespace and id for the 'chromosome' component of the contained MapPosition object will usually be the same as the namespace and id for the parent GeneticMap object itself, but this may not always be the case. ================================================ It would be great if we all started putting a couple of extra minutes into defining our objects in a way that would allow other people to discover and use them appropriately... Mark -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 12:36:33 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:36:33 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Oh dear... I forgot about the LSID's... Ouch! that aspect of the LSID specification really is a painful one for database curators! This is actually going to be quite problematic. The edit that I just did was not allowed by the API (which is why I had to do it at the database level). The reason it is not allowed is that service instances use the LSID of their input/output objects as the primary key in the database, so if we update the LSID of every Object that I just modified, then all of those service registrations are broken and would also have to be updated by hand... and so on for each child object, and each service that uses a child object. Can I get a "bye" on doing these LSID updates in this case? please?? It really should be a transparent change v.v. the functionality of the services and the XML representation of the objects. I guess *technically*, since our LSIDs do not resolve by getData, only by getMetadata, we haven't really broken the LSID specification by not updating the version number in this case - we've broken it "in spirit", but not "in practice". >>sigh<< M On Thu, 2006-07-06 at 17:21 +0100, Martin Senger wrote: > > Dashboard users - don't forget to reload the ontology from source. > > > Yes. Just a reminder: Now when the registry supports fully LSIDs with > versions, you do not need to 'reload' but should be sufficient to > 'update' - just use a different button (this should update only those data > types that were really changed, so it is faster than reload). > > Cheers, > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 12:36:33 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:36:33 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Oh dear... I forgot about the LSID's... Ouch! that aspect of the LSID specification really is a painful one for database curators! This is actually going to be quite problematic. The edit that I just did was not allowed by the API (which is why I had to do it at the database level). The reason it is not allowed is that service instances use the LSID of their input/output objects as the primary key in the database, so if we update the LSID of every Object that I just modified, then all of those service registrations are broken and would also have to be updated by hand... and so on for each child object, and each service that uses a child object. Can I get a "bye" on doing these LSID updates in this case? please?? It really should be a transparent change v.v. the functionality of the services and the XML representation of the objects. I guess *technically*, since our LSIDs do not resolve by getData, only by getMetadata, we haven't really broken the LSID specification by not updating the version number in this case - we've broken it "in spirit", but not "in practice". >>sigh<< M On Thu, 2006-07-06 at 17:21 +0100, Martin Senger wrote: > > Dashboard users - don't forget to reload the ontology from source. > > > Yes. Just a reminder: Now when the registry supports fully LSIDs with > versions, you do not need to 'reload' but should be sufficient to > 'update' - just use a different button (this should update only those data > types that were really changed, so it is faster than reload). > > Cheers, > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 12:40:15 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:40:15 -0700 Subject: [MOBY-dev] [personal] Re: Object ontology curated in the text-* branch In-Reply-To: References: Message-ID: <1152204015.31293.40.camel@bioinfo.icapture.ubc.ca> Does Dashboard have a "Remove Lincoln's Sins" button? (I hope he's not reading this! ;-) ;-) ) M On Thu, 2006-07-06 at 17:23 +0100, Martin Senger wrote: > Doing the cleaning you could consider to get rid of these Lincoln's > (?) old sins, eg. snp_allele not having any parent. (Dashboard can show > you them.) > > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Jul 6 12:56:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:56:12 +0100 (BST) Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > The reason it is not allowed is that service instances use the LSID of > their input/output objects as the primary key in the database > But why it is like that? The simple name of a data type could be as good as its LSID - of course unless you consider the version in LSID. I think that the primary key could be either an LSID - but in such case the update of all connected entities must happen, or it should be a simple name (like DNASequence). Having it as it is now asks for troubles (as you have just described and witnessed). I am not that worried about this particular case of cleaning (okay: Dashboard's users, plese forget my reminder and use the button 'reload' and not 'update' :-)) but about that such situation can happen again. I am not a particular database person but I can imagine a script that will get as an input changed primary key and will go to other tables automatically and changed the references there. This seems (to me, as a non-db-expert) like a usual database maintainance task. Actually, it would be good if my service gets a new LSID just because some underlying data type - this service is using - changed. > I guess *technically*, since our LSIDs do not resolve by getData, only > by getMetadata, we haven't really broken the LSID specification by not > updating the version number in this case - we've broken it "in spirit", > but not "in practice". > I am not sure about this conclusion. We do not resolve our LSID's using getData, that's true. But we do not do it because we already have an API for the same functionality (the API returning definitions from the registry). But still our LSID represents a "chunk of bytes" - and if this chunk (even though not resolvable by getData) changes, its LSID should be changed, as well. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Thu Jul 6 12:56:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:56:12 +0100 (BST) Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > The reason it is not allowed is that service instances use the LSID of > their input/output objects as the primary key in the database > But why it is like that? The simple name of a data type could be as good as its LSID - of course unless you consider the version in LSID. I think that the primary key could be either an LSID - but in such case the update of all connected entities must happen, or it should be a simple name (like DNASequence). Having it as it is now asks for troubles (as you have just described and witnessed). I am not that worried about this particular case of cleaning (okay: Dashboard's users, plese forget my reminder and use the button 'reload' and not 'update' :-)) but about that such situation can happen again. I am not a particular database person but I can imagine a script that will get as an input changed primary key and will go to other tables automatically and changed the references there. This seems (to me, as a non-db-expert) like a usual database maintainance task. Actually, it would be good if my service gets a new LSID just because some underlying data type - this service is using - changed. > I guess *technically*, since our LSIDs do not resolve by getData, only > by getMetadata, we haven't really broken the LSID specification by not > updating the version number in this case - we've broken it "in spirit", > but not "in practice". > I am not sure about this conclusion. We do not resolve our LSID's using getData, that's true. But we do not do it because we already have an API for the same functionality (the API returning definitions from the registry). But still our LSID represents a "chunk of bytes" - and if this chunk (even though not resolvable by getData) changes, its LSID should be changed, as well. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jul 6 13:14:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 10:14:53 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152206093.31603.2.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-07-06 at 17:56 +0100, Martin Senger wrote: > But why it is like that? > The simple name of a data type could be as > good as its LSID - of course unless you consider the version in LSID. I > think that the primary key could be either an LSID - but in such case the > update of all connected entities must happen, or it should be a simple > name (like DNASequence). Having it as it is now asks for troubles (as you > have just described and witnessed). The object Name could equally well be used as the primary key, you're right. The API does not allow editing of an object definition if that object is being used by a service, or as a parent or hasa component of another object, so effectively the LSID for an object should never change in any case that affects service providers. It would only change (i.e. the object definition could only change) if no services were using it. As such, the object Name and the object LSID are equally "robust" as identifiers in the database. > I am not that worried about this particular case of cleaning (okay: > Dashboard's users, plese forget my reminder and use the button 'reload' > and not 'update' :-)) but about that such situation can happen again. I am > not a particular database person but I can imagine a script that will get > as an input changed primary key and will go to other tables automatically > and changed the references there. That script could be written; however this kind of editing isn't allowed in the API, so I've never taken the time to write it. > This seems (to me, as a non-db-expert) > like a usual database maintainance task. It is. It's just that we don't touch the database itself often enough to have written the kinds of support scripts we need for this detail of editing. > Actually, it would be good if my service gets a new LSID just because > some underlying data type - this service is using - changed. I thought this would horrify you! :-) The API does not allow this to happen because if I re-define an object that you are using I may (probably will) break your service. Even if I notify you that the definition has changed, and update the LSID of your service, it is still a destructive thing to do because I can't automatically update your code to compensate for this change (in fact, it may not be possible to compensate for the change if the object has been dramatically modified). > > I guess *technically*, since our LSIDs do not resolve by getData, only > > by getMetadata, we haven't really broken the LSID specification by not > > updating the version number in this case - we've broken it "in spirit", > > but not "in practice". > > > I am not sure about this conclusion. We do not resolve our LSID's using > getData, that's true. But we do not do it because we already have an API > for the same functionality (the API returning definitions from the > registry). But still our LSID represents a "chunk of bytes" - and if this > chunk (even though not resolvable by getData) changes, its LSID should be > changed, as well. I agree 100%... which is why I say we have broken the LSID spec "in spirit" :-) I'm certainly not saying that it is something to be proud of... but in the absence of DB maintenance scripts, it is just not practical (or should I say, it is more dangerous given how much I hate touching the database by hand) to do "the right thing" this time. M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Jul 6 14:29:01 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 19:29:01 +0100 (BST) Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: <1152206093.31603.2.camel@bioinfo.icapture.ubc.ca> Message-ID: > > Actually, it would be good if my service gets a new LSID just because > > some underlying data type - this service is using - changed. > > I thought this would horrify you! :-) > Well, not really. I am not asking to have this ability in the API, of course not. That definitely would horrify me. But when cases like today - a need for manual correction of database entries - occur then I would not mind to get also new LSIDs for everything involved (together with an email annoucement what happenned and why - as you did). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jul 6 14:39:07 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 11:39:07 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152211147.31807.10.camel@bioinfo.icapture.ubc.ca> Once I get this next manuscript submitted I'll take some time to write a few database maintenance scripts like this. I'd feel safer doing it using a script anyway... M On Thu, 2006-07-06 at 19:29 +0100, Martin Senger wrote: > > > Actually, it would be good if my service gets a new LSID just because > > > some underlying data type - this service is using - changed. > > > > I thought this would horrify you! :-) > > > Well, not really. I am not asking to have this ability in the API, of > course not. That definitely would horrify me. But when cases like today - > a need for manual correction of database entries - occur then I would > not mind to get also new LSIDs for everything involved (together with an > email annoucement what happenned and why - as you did). > > Cheers, > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 14:51:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 11:51:25 -0700 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] Message-ID: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.open-bio.org/pipermail/moby-dev/attachments/20060706/a3b464ad/attachment.pl -------------- next part -------------- An embedded message was scrubbed... From: "Byrne Reese" Subject: [personal] [soaplite] SOAP::Lite 0.68 Released Date: Thu, 06 Jul 2006 18:34:48 -0000 Size: 3062 Url: http://lists.open-bio.org/pipermail/moby-dev/attachments/20060706/a3b464ad/attachment.mht From Pieter.Neerincx at wur.nl Thu Jul 6 16:29:31 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 6 Jul 2006 22:29:31 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark et al., I'll give it a try tomorrow. As long as it doesn't introduce any new peculiarities I can check pretty fast if the previous problems still persist or not. In the mean time: did anyone test the patches for the BioMOBY Perl modules I send to the list some time ago? I'm especially interested from people who ran them on a system with S::L 0.60... Cheers, Pi On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > Heads-up! > > I wonder if this will solve or worsen the problems we've been having > with SOAP::Lite 0.67?? > > Is anyone in a position to try this new release and evaluate it? My > plate is full for the next couple of weeks... > > M > > > > > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > From: "Byrne Reese" > Date: 06 July 2006 20:34:48 GMT+02:00 > To: soaplite at yahoogroups.com > Subject: [personal] [soaplite] SOAP::Lite 0.68 Released > > > I have released a new version of SOAP::Lite. It is available on > sourceforge now, or on CPAN in a couple of hours. The new version is > 0.68 and includes a number of fixes that make working with WSDL less > error prone. > > What motivated the fixes is working with Google's APIs (specifically > the AdWords API). So I have confirmed that that works now. > > Please let me know if you experience any problems so that I can patch > it immediately. > > Byrne Reese > Lead Developer, SOAP::Lite > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Pieter.Neerincx at wur.nl Thu Jul 6 16:29:31 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 6 Jul 2006 22:29:31 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark et al., I'll give it a try tomorrow. As long as it doesn't introduce any new peculiarities I can check pretty fast if the previous problems still persist or not. In the mean time: did anyone test the patches for the BioMOBY Perl modules I send to the list some time ago? I'm especially interested from people who ran them on a system with S::L 0.60... Cheers, Pi On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > Heads-up! > > I wonder if this will solve or worsen the problems we've been having > with SOAP::Lite 0.67?? > > Is anyone in a position to try this new release and evaluate it? My > plate is full for the next couple of weeks... > > M > > > > > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > From: "Byrne Reese" > Date: 06 July 2006 20:34:48 GMT+02:00 > To: soaplite at yahoogroups.com > Subject: [personal] [soaplite] SOAP::Lite 0.68 Released > > > I have released a new version of SOAP::Lite. It is available on > sourceforge now, or on CPAN in a couple of hours. The new version is > 0.68 and includes a number of fixes that make working with WSDL less > error prone. > > What motivated the fixes is working with Google's APIs (specifically > the AdWords API). So I have confirmed that that works now. > > Please let me know if you experience any problems so that I can patch > it immediately. > > Byrne Reese > Lead Developer, SOAP::Lite > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 markw at illuminae.com Thu Jul 6 18:54:23 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 15:54:23 -0700 Subject: [MOBY-dev] a bit more hand-editing of the Object ontology Message-ID: I've also done a bit of hand-editing of the Blast report objects. There's a nice node "Sequence_alignment_report" that was starting to get populated with things like FASTA and ClustalW. I've taken the NCBI and WU blast objects and moved them as children of that node. Again, this will not affect anyone's services who use those objects, since the only links affected are ISA (thus no change in object structure), but I wanted to give everyone a heads-up that I did it. Please scream at me if you are upset about this. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From gordonp at ucalgary.ca Fri Jul 7 00:23:02 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 06 Jul 2006 22:23:02 -0600 Subject: [MOBY-dev] Code updates in jMOBY Message-ID: <44ADE1A6.4040608@ucalgary.ca> Hi all, I've finally had a chance to get around to committing changes to the jMOBY CVS. This includes updates to the org.biomoby.shared.data package. Please check it out and let me know what you think. I did a "ant clean" then a "build.sh" and everything seemed fine, but please let me know if jMOBY does something funny. I'm using Java 1.5 features such as Generics and autoboxing. As well, I have added new documentation introducing Seahawk, a MOBY GUI client with tabbed browsing. Please check it out and let me know if it works well for you (I know JAX-T on the Mac has problems, and SCUFL export doesn't work unless you're using it from within Bluejay for the moment). Follow the links on the jMOBY Web page (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/). Mark, maybe you can add this to the MOBY Clients section of the main Web site? Cheers, Paul From phillip.lord at newcastle.ac.uk Fri Jul 7 06:43:19 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 07 Jul 2006 11:43:19 +0100 Subject: [MOBY-dev] Request for good behaviour In-Reply-To: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> (Mark Wilkinson's message of "Thu, 06 Jul 2006 09:24:46 -0700") References: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark Never thought I would see the day, where you asked other people for good behaviour! You might be interested in this paper here. They define quality metrics for ontology definitions. They look quite interesting. Essentially their metrics pick up two ontological sins: circularlity and unintelligability. http://www.biomedcentral.com/1471-2105/7/212 >>>>> "Mark" == Mark Wilkinson writes: Mark> As I was poking around the Object ontology this morning I Mark> noticed some things that made me "cry". In particular, the Mark> way some objects are being defined is... well... not very Mark> helpful! Mark> The best example is Mark> Object Name: "TC" Description: "TC" This one would fall on the grounds that it's circular -- too many (i.e all) the words in the name occur in the description, and on the grounds that it's unintelligable (i.e none of the words in the description are in anyway meaningful). Mark> Another example Mark> Object Name: AvailableMaterial Description: Object containing Mark> information about available material This one is circular and has too many stop words: information, object, about and containing are always a little suspect in an ontology. Mark> I am not sure that, given these descriptions, either of these Mark> Objects can be used by anyone other than their original Mark> author, which kind of defeats the purpose of having an Object Mark> ontology :-) Mark> The *king* of good object descriptions has got to be Martin Mark> Senger, and I think that some of mine are pretty good too... Mark> so here are two examples that show how I think it should be Mark> done: All hail, Martin Senger? King of documentation. Cheers Phil From phillip.lord at newcastle.ac.uk Fri Jul 7 06:43:19 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 07 Jul 2006 11:43:19 +0100 Subject: [MOBY-dev] Request for good behaviour In-Reply-To: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> (Mark Wilkinson's message of "Thu, 06 Jul 2006 09:24:46 -0700") References: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark Never thought I would see the day, where you asked other people for good behaviour! You might be interested in this paper here. They define quality metrics for ontology definitions. They look quite interesting. Essentially their metrics pick up two ontological sins: circularlity and unintelligability. http://www.biomedcentral.com/1471-2105/7/212 >>>>> "Mark" == Mark Wilkinson writes: Mark> As I was poking around the Object ontology this morning I Mark> noticed some things that made me "cry". In particular, the Mark> way some objects are being defined is... well... not very Mark> helpful! Mark> The best example is Mark> Object Name: "TC" Description: "TC" This one would fall on the grounds that it's circular -- too many (i.e all) the words in the name occur in the description, and on the grounds that it's unintelligable (i.e none of the words in the description are in anyway meaningful). Mark> Another example Mark> Object Name: AvailableMaterial Description: Object containing Mark> information about available material This one is circular and has too many stop words: information, object, about and containing are always a little suspect in an ontology. Mark> I am not sure that, given these descriptions, either of these Mark> Objects can be used by anyone other than their original Mark> author, which kind of defeats the purpose of having an Object Mark> ontology :-) Mark> The *king* of good object descriptions has got to be Martin Mark> Senger, and I think that some of mine are pretty good too... Mark> so here are two examples that show how I think it should be Mark> done: All hail, Martin Senger? King of documentation. Cheers Phil From senger at ebi.ac.uk Fri Jul 7 07:37:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 12:37:54 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44ADE1A6.4040608@ucalgary.ca> Message-ID: > "ant clean" then a "build.sh" and everything seemed fine, but please let > me know if jMOBY does something funny. > Javac compiles it fine. But for year I have been using jikes because of its speed and accuracy regarding the java spec. And this does not work anymore now. I am using jikes 1.22 and it seems to be the latest version. This is annoying, but not critical. At least what I see so far. What is bothering me more is that you remove things that were working fine and that my code relies on. For example: I have looked into the reported errorrs and in the CVS what had been changed. I took an example, file CentralImpl.java. I wonder why you removed things there, such as AxisUtils.formatFault? Now, BTW, it gives a semantic error when compiled with jikes: [javac] Found 1 semantic error compiling "/home/senger/moby-live/Java/src/main/org/biomoby/client/CentralImpl.java": [javac] 222. (endpoint.toString()+(call == null ? "" : call.getOperationName()), e); [javac] ^--------------------------^ [javac] *** Semantic Error: In the conditional, the type of the true sub-expression, "java.lang.String", is not compatible with the type of the false sub-expression, "javax.xml.namespace.QName". Could we work on it soon please? Next week, I am giving a detailed tutorial on Moby and I would prefer to have things working as they did before. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Fri Jul 7 08:01:40 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 13:01:40 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44ADE1A6.4040608@ucalgary.ca> Message-ID: Paul, One more remark regarding jikes: Perhaps I am not using correct arguments for jikes (like -source 1.5). But it would need some time to investigate what arguments to use, and how to put them into jMoby build.xml. The time I am reluctant to spend just now. Perhaps you can consider to investigate - after all these were your changes :-) Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Fri Jul 7 10:31:54 2006 From: d.haase at gsf.de (Dirk Haase) Date: Fri, 7 Jul 2006 16:31:54 +0200 Subject: [MOBY-dev] a bit more hand-editing of the Object ontology In-Reply-To: References: Message-ID: <200607071631.54777.d.haase@gsf.de> On Friday 07 July 2006 00:54, Mark Wilkinson wrote: > I've also done a bit of hand-editing of the Blast report objects. There's > a nice node "Sequence_alignment_report" that was starting to get populated > with things like FASTA and ClustalW. I've taken the NCBI and WU blast > objects and moved them as children of that node. Maybe I'm a bit picky, but I want to remind you that BLAST and FASTA are not sequence alignment algorithms but sequence database search tools. What if I choose to display no alignments at all in my BLAST report? Regards, dirk From markw at illuminae.com Fri Jul 7 11:56:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Jul 2006 08:56:50 -0700 Subject: [MOBY-dev] [moby] Re: a bit more hand-editing of the Object ontology In-Reply-To: <200607071631.54777.d.haase@gsf.de> References: <200607071631.54777.d.haase@gsf.de> Message-ID: <1152287810.1577.12.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-07 at 16:31 +0200, Dirk Haase wrote: > Maybe I'm a bit picky, but I want to remind you that BLAST and FASTA are not > sequence alignment algorithms but sequence database search tools. What if I > choose to display no alignments at all in my BLAST report? Good point... Darn single-parenting! Alternate proposals? M > Regards, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Jul 7 11:58:11 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Jul 2006 08:58:11 -0700 Subject: [MOBY-dev] [moby] Re: Request for good behaviour In-Reply-To: References: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Message-ID: <1152287892.1577.14.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-07 at 11:43 +0100, Phillip Lord wrote: > Mark > Never thought I would see the day, where you asked other people for > good behaviour! Only academically... ;-) M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From enrique.deandres at pcm.uam.es Fri Jul 7 10:03:57 2006 From: enrique.deandres at pcm.uam.es (Enrique de Andres Saiz) Date: Fri, 07 Jul 2006 16:03:57 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: <44AE69CD.5030605@pcm.uam.es> Hi Pieter, I have tried your patches a little bit and I have found the following... When I use SOAP::Lite both v0.60 or v0.67, and I invoke MOBY::Client::Central registerObjectClass, I get the following error: Can't coerce array into hash at /usr/local/share/perl/5.8.4/MOBY/Client/Central.pm line 423. Everything else looks OK. Kind regards, Enrique. Pieter Neerincx wrote: > Hi Mark et al., > > I'll give it a try tomorrow. As long as it doesn't introduce any new > peculiarities I can check pretty fast if the previous problems still > persist or not. In the mean time: did anyone test the patches for the > BioMOBY Perl modules I send to the list some time ago? I'm especially > interested from people who ran them on a system with S::L 0.60... > > Cheers, > > Pi > > On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > >> Heads-up! >> >> I wonder if this will solve or worsen the problems we've been having >> with SOAP::Lite 0.67?? >> >> Is anyone in a position to try this new release and evaluate it? My >> plate is full for the next couple of weeks... >> >> M >> >> >> >> >> -- >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> From: "Byrne Reese" >> Date: 06 July 2006 20:34:48 GMT+02:00 >> To: soaplite at yahoogroups.com >> Subject: [personal] [soaplite] SOAP::Lite 0.68 Released >> >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new version is >> 0.68 and includes a number of fixes that make working with WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > -- Enrique de Andr?s Saiz Unidad de Bioinform?tica Parque Cient?fico de Madrid Ctra. de Colmenar, Km. 15 Campus Universidad Aut?noma de Madrid, Cantoblanco - Pabell?n C 28049 Madrid Phone: +34 91 497 3448 Fax: +34 91 497 3471 E-mail: enrique.deandres at pcm.uam.es From enrique.deandres at pcm.uam.es Fri Jul 7 10:03:57 2006 From: enrique.deandres at pcm.uam.es (Enrique de Andres Saiz) Date: Fri, 07 Jul 2006 16:03:57 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: <44AE69CD.5030605@pcm.uam.es> Hi Pieter, I have tried your patches a little bit and I have found the following... When I use SOAP::Lite both v0.60 or v0.67, and I invoke MOBY::Client::Central registerObjectClass, I get the following error: Can't coerce array into hash at /usr/local/share/perl/5.8.4/MOBY/Client/Central.pm line 423. Everything else looks OK. Kind regards, Enrique. Pieter Neerincx wrote: > Hi Mark et al., > > I'll give it a try tomorrow. As long as it doesn't introduce any new > peculiarities I can check pretty fast if the previous problems still > persist or not. In the mean time: did anyone test the patches for the > BioMOBY Perl modules I send to the list some time ago? I'm especially > interested from people who ran them on a system with S::L 0.60... > > Cheers, > > Pi > > On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > >> Heads-up! >> >> I wonder if this will solve or worsen the problems we've been having >> with SOAP::Lite 0.67?? >> >> Is anyone in a position to try this new release and evaluate it? My >> plate is full for the next couple of weeks... >> >> M >> >> >> >> >> -- >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> From: "Byrne Reese" >> Date: 06 July 2006 20:34:48 GMT+02:00 >> To: soaplite at yahoogroups.com >> Subject: [personal] [soaplite] SOAP::Lite 0.68 Released >> >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new version is >> 0.68 and includes a number of fixes that make working with WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > -- Enrique de Andr?s Saiz Unidad de Bioinform?tica Parque Cient?fico de Madrid Ctra. de Colmenar, Km. 15 Campus Universidad Aut?noma de Madrid, Cantoblanco - Pabell?n C 28049 Madrid Phone: +34 91 497 3448 Fax: +34 91 497 3471 E-mail: enrique.deandres at pcm.uam.es From gordonp at ucalgary.ca Fri Jul 7 14:28:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 12:28:50 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: References: Message-ID: <44AEA7E2.8030708@ucalgary.ca> Hi Martin, Sure, I can have a look at why jikes craps out... BTW, yes, I did make some minor code changes in classes directly in org.biomoby.shared and org.biomoby.client, primarily because of package creep. The functionality should not really be affected, if it is, let me know. For example the formatFault you mentioned is replaced by 3 lines that do essentially the same thing. By package creep, I mean that in order to compile core MOBY classes into my non-MOBY cvs projects, I don't want to have to include lots of extra jars (I'm writing applets, which have severe memory restrictions). For example, I moved JDOM specific code from Utils to JDOMUtils, and changed all references to those methods (very few actually) in CVS. Same thing with the tulsoft libraries. I think it's a generally good idea to limit the number external dependencies in the core shared classes, no? Cheers, Paul > . Paul, > One more remark regarding jikes: Perhaps I am not using correct > arguments for jikes (like -source 1.5). But it would need some time to > investigate what arguments to use, and how to put them into jMoby > build.xml. The time I am reluctant to spend just now. Perhaps you can > consider to investigate - after all these were your changes :-) > > Thanks, > Martin > > From gordonp at ucalgary.ca Fri Jul 7 15:34:31 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 13:34:31 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEA7E2.8030708@ucalgary.ca> References: <44AEA7E2.8030708@ucalgary.ca> Message-ID: <44AEB747.3000401@ucalgary.ca> As far as I can see, jikes does not support Java 1.5 language features yet. And there hasn't been a new release of jikes for almost 2 years now. http://sourceforge.net/tracker/index.php?func=detail&aid=1210781&group_id=128803&atid=712760 You can compile with the Java 1.5 runtime library, but you cannot compile features introduced in Java1.5 such as Generics, autoboxing, enumerated types, enhanced for loops, etc... Looks like you'll have to stick to javac for now. It takes 22 seconds for me to compile everything. Cheers, Paul > Hi Martin, > > Sure, I can have a look at why jikes craps out... > > BTW, yes, I did make some minor code changes in classes directly in > org.biomoby.shared and org.biomoby.client, primarily because of package > creep. The functionality should not really be affected, if it is, let > me know. For example the formatFault you mentioned is replaced by 3 > lines that do essentially the same thing. > > By package creep, I mean that in order to compile core MOBY classes into > my non-MOBY cvs projects, I don't want to have to include lots of extra > jars (I'm writing applets, which have severe memory restrictions). For > example, I moved JDOM specific code from Utils to JDOMUtils, and changed > all references to those methods (very few actually) in CVS. Same thing > with the tulsoft libraries. I think it's a generally good idea to limit > the number external dependencies in the core shared classes, no? > > Cheers, > > Paul > >> . Paul, >> One more remark regarding jikes: Perhaps I am not using correct >> arguments for jikes (like -source 1.5). But it would need some time to >> investigate what arguments to use, and how to put them into jMoby >> build.xml. The time I am reluctant to spend just now. Perhaps you can >> consider to investigate - after all these were your changes :-) >> >> Thanks, >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From senger at ebi.ac.uk Fri Jul 7 15:56:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 20:56:08 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEB747.3000401@ucalgary.ca> Message-ID: > As far as I can see, jikes does not support Java 1.5 language features > yet. And there hasn't been a new release of jikes for almost 2 years now. > > You can compile with the Java 1.5 runtime library, but you cannot > compile features introduced in Java1.5 such as Generics, autoboxing, > enumerated types, enhanced for loops, etc... Looks like you'll have to > stick to javac for now. It takes 22 seconds for me to compile everything. > Sorry, but this is hardly acceptible. I think I prefer to roll bcak. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Fri Jul 7 16:02:34 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 21:02:34 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEA7E2.8030708@ucalgary.ca> Message-ID: > By package creep, I mean that in order to compile core MOBY classes into > my non-MOBY cvs projects, I don't want to have to include lots of extra > jars (I'm writing applets, which have severe memory restrictions). For > example, I moved JDOM specific code from Utils to JDOMUtils, and changed > all references to those methods (very few actually) in CVS. > Paul, you did changes that you do not know about consequences. For example changes in packages affect the number of jar files that are to be deployed to the Tomcat. But you have not changed this in build.xml files. > The functionality should not really be affected, if it is, let me > know. For example the formatFault you mentioned is replaced by 3 > lines that do essentially the same thing. > Yes, now it is 3 lines of code but they are well separated and can be extended later for more sophisticated code. I would like to have them back please. I am now busy to finish other moby project (perl one) I am working on because I am leaving for a meeting soon. So I cannot look in details what you did - but I really ask you to re-consider your changes. I feel greatly disturbed now. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Jul 7 18:03:20 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 16:03:20 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: References: Message-ID: <44AEDA28.4060806@ucalgary.ca> Hi Martin, >> By package creep, I mean that in order to compile core MOBY classes into >> my non-MOBY cvs projects, I don't want to have to include lots of extra >> jars (I'm writing applets, which have severe memory restrictions). For >> example, I moved JDOM specific code from Utils to JDOMUtils, and changed >> all references to those methods (very few actually) in CVS. >> >> > Paul, you did changes that you do not know about consequences. For > example changes in packages affect the number of jar files that are to be > deployed to the Tomcat. But you have not changed this in build.xml files. > There may be some confusion: I did not remove or add any packages, I simply moved code (4 methods) to a new class org.biomoby.shared.parser JDOMUtils. For example, this cleaned org.biomoby.shared.data of the JDOM dependency you introduced in MobyProvisionInfo. None of these changes involved the subpackages dashboard, rdf, registry or ui, so I don't think any changes to build.xml need to be made. >> The functionality should not really be affected, if it is, let me >> know. For example the formatFault you mentioned is replaced by 3 >> lines that do essentially the same thing. >> >> > Yes, now it is 3 lines of code but they are well separated and can be > extended later for more sophisticated code. I would like to have them > back please. > I guess this becomes a philosophical question for the project as whole. Do you want to force anyone who want to use MOBY in their Java own program to bundle all of JAR files in lib with them in their deployments (e.g. otherwise I need know that I must have alltools2.jar in my classpath to use CentralImpl)? I am coming at this (as you've asked me before) from the perspective of someone not using jMOBY as their primary CVS tree but rather as a library to use. I carefully selected just a few parts (less than a dozen classes) to remove some small library dependencies from so that Seahawk (~2.7MB total) doesn't need to import a lot of external code to compile and run. Please note, I have not touched the dashboard, datatype, rdf, registry, ui, and not even most of the classes in shared. There is really just a core set of common classes I'd like to keep clean, and hopefully others will too, under org/biomoby: ./client/CentralCachedCallsImpl.java ./client/CentralImpl.java ./client/rdf/vocabulary/DC_PROTEGE.java ./client/rdf/vocabulary/FetaVocabulary.java ./client/rdf/vocabulary/MobyResources.java ./client/rdf/vocabulary/Predicates.java ./client/rdf/vocabulary/ServiceDescriptionPredicates.java ./client/rdf/vocabulary/XMLTypes.java ./shared/*.java ./shared/data/*.java ./shared/extended/DataTypeParser.java ./shared/extended/NamespaceParser.java ./shared/extended/ServiceInstanceParser.java ./shared/extended/ServiceTypeParser.java ./shared/parser/MobyTags.java ./shared/schema/MElement.java ./shared/schema/MElementHashtable.java ./shared/schema/PrimitiveVector.java ./shared/schema/RdfParser.java > I am now busy to finish other moby project (perl one) I am working on > because I am leaving for a meeting soon. So I cannot look in details what > you did - but I really ask you to re-consider your changes. I feel greatly > disturbed now. > Besides the 4 methods moved to JDOMUtils, there actually are few changes. There are less than 20 lines of code affected, all related to formatting utilities and empty string checks. I did not touch anything with fundamental functionality. I don't think you need to be "greatly disturbed" :-) Cool runnings, Paul From senger at ebi.ac.uk Fri Jul 7 18:12:49 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 23:12:49 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEDA28.4060806@ucalgary.ca> Message-ID: Paul, Thanks for assurance... I still do not have time to confirm or reject your explanation. I will do it later ad let you know.I m sure we will find a solution (if there is a problem). However, you mentioned several time that one of your concern is JDOM. Mine too, actually. I know that we (in jMoby) are using - unfortunately - both: DOM and JDOM. I prefer JDOM. Is there an easy way to use just one - jDOM? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Jul 7 18:34:47 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 16:34:47 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: References: Message-ID: <44AEE187.4060101@ucalgary.ca> Hi, All of my code is DOM based, primarily because I am using many tools that sit on top of the DOM, such as XPath evaluators, XSLT processors, etc. Also, the DOM implementation comes free with Java 1.5 (i.e. the JRE includes DOM compliant parsers, translators, etc.), so there are no external dependencies when using the JAXP and JAXT APIs. While there is nothing wrong with using jDOM, I'm just reluctant to force people to use it over the built-in Java methods. If everyone else (hello?) definitely wants to use jDOM though, we can make a plan to migrate the code base that way. Cheers, Paul > Paul, > Thanks for assurance... I still do not have time to confirm or reject > your explanation. I will do it later ad let you know.I m sure we will find > a solution (if there is a problem). > However, you mentioned several time that one of your concern is JDOM. > Mine too, actually. I know that we (in jMoby) are using - unfortunately - > both: DOM and JDOM. I prefer JDOM. Is there an easy way to use just one - > jDOM? > > Martin > > From senger at ebi.ac.uk Fri Jul 7 18:37:52 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 23:37:52 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEE187.4060101@ucalgary.ca> Message-ID: > All of my code is DOM based > Okay, okay... I was not sure who is using it, me or you. So let's have both, as so far. > If everyone else (hello?) definitely wants to use jDOM though, we can > make a plan to migrate the code base that way. > It would be nice but probably a lot of work I guess. Not my cup of tea :-) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Jul 7 19:00:44 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Jul 2006 16:00:44 -0700 Subject: [MOBY-dev] Fwd: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released In-Reply-To: <44AEB128.3090201@majordojo.com> References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> Message-ID: Another release of SOAP::Lite coming soon... M ------- Forwarded message ------- From: "Byrne Reese" To: "Chris McMahon" Cc: soaplite at yahoogroups.com Subject: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released Date: Fri, 07 Jul 2006 12:08:24 -0700 Yes. Apparently I forgot to check one file in. Damn it. So what worked for me in development didn't get fully released. Please stand-by. An update is forthcoming - perhaps by Monday. Chris McMahon wrote: > > > Hi... > This is significantly better than 0.67. However, I'm getting an > error vs. the WSDL I need to read: > > Type 'ArrayOfstring' can't be found in a schema class 'SOAP::Serializer' > > Any ideas on fixing this? > > On 7/6/06, *Byrne Reese* > wrote: > > I have released a new version of SOAP::Lite. It is available on > sourceforge now, or on CPAN in a couple of hours. The new version is > 0.68 and includes a number of fixes that make working with WSDL less > error prone. > > What motivated the fixes is working with Google's APIs (specifically > the AdWords API). So I have confirmed that that works now. > > Please let me know if you experience any problems so that I can patch > it immediately. > > Byrne Reese > Lead Developer, SOAP::Lite > > > > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From edward.kawas at gmail.com Thu Jul 13 14:35:23 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 13 Jul 2006 11:35:23 -0700 Subject: [MOBY-dev] RDF Message-ID: <005501c6a6ab$1c3b8900$6a00a8c0@notebook> FYI, The service instance RDF has been modified once again and should now be stable. For those that use the RDF (and java), I have updated the parsers at org.biomoby.shared.extended.*. Eddie From spies at ipk-gatersleben.de Wed Jul 19 12:08:29 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Wed, 19 Jul 2006 18:08:29 +0200 Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: <005501c6a6ab$1c3b8900$6a00a8c0@notebook> References: <005501c6a6ab$1c3b8900$6a00a8c0@notebook> Message-ID: <44BE58FD.3020408@ipk-gatersleben.de> Hi, I have some problems with deploying a simple jMoby service to an oracle application server. With tomcat it works fine, but if I deploy the same service with the same libraries to oracle I get an exception (java.lang.StackOverflowError). Have anybody of you experiences with other runtimes than tomcat??? Thanks for help. Karl From senger at ebi.ac.uk Wed Jul 19 12:40:23 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 19 Jul 2006 17:40:23 +0100 (BST) Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: <44BE58FD.3020408@ipk-gatersleben.de> Message-ID: > Have anybody of you experiences with other runtimes than tomcat??? > No, I have not. But I am very interested to learn how/when you are going to solve this problem. It may be worth to mention it also in the jMoby docs, for future reference. Are you using jMoby services generated by MoSeS? In which moment the stack overflow happens? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From spies at ipk-gatersleben.de Thu Jul 20 05:18:44 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 11:18:44 +0200 Subject: [MOBY-dev] jMoby Java 1.4 Message-ID: <44BF4A74.7090800@ipk-gatersleben.de> Hi, I know the change to Java 1.5 compiler has been discussed, but now I need a Java 1.4 compatible version. Is there an CVS arch or something like that? Or which date is the last, that contain only Java 1.4 compatible stuff? Sorry of that late entrance in this discussion. Karl From gordonp at ucalgary.ca Thu Jul 20 10:00:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 20 Jul 2006 08:00:43 -0600 Subject: [MOBY-dev] jMoby Java 1.4 In-Reply-To: <44BF4A74.7090800@ipk-gatersleben.de> References: <44BF4A74.7090800@ipk-gatersleben.de> Message-ID: <44BF8C8B.5080505@ucalgary.ca> Hi Karl, The switch over was June 30th. You can do a CVS checkout with that date stamp... > Hi, > > I know the change to Java 1.5 compiler has been discussed, but now I > need a Java 1.4 compatible version. Is there an CVS arch or something > like that? Or which date is the last, that contain only Java 1.4 > compatible stuff? > > Sorry of that late entrance in this discussion. > > Karl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From spies at ipk-gatersleben.de Thu Jul 20 11:16:52 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 17:16:52 +0200 Subject: [MOBY-dev] jMoby Java 1.4 In-Reply-To: <44BF8C8B.5080505@ucalgary.ca> References: <44BF4A74.7090800@ipk-gatersleben.de> <44BF8C8B.5080505@ucalgary.ca> Message-ID: <44BF9E64.9040401@ipk-gatersleben.de> Thanks, I will do so. It is possible to make such an arch in the CVS tree? May be it is useful for other peoples with the same problem? Karl From spies at ipk-gatersleben.de Thu Jul 20 11:19:17 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 17:19:17 +0200 Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: References: Message-ID: <44BF9EF5.7060503@ipk-gatersleben.de> Hi, i solved the problem and yes, first I used moses skeleton generator. But now I am using a recycled BaseService and implement the rest by myself. Why I am doing this? The reason is, that oracle is very strict with there design of web service. You are not allowed to use any abstract method in your implementation classes. So the public void processIt (MobyJob request, MobyJob response,MobyPackage outputContext) throws MobyException {} will crash the system. An other requirement is that every oracle based web service must have an interface which extends from java.rmi.Remote and very method declaration must throw a java.rmi.RemoteException. The solution was to take inspiration from the BaseService and the moses generator and implement my own BaseService(change the abtract process method). After that I copied code from the generated skeleton and put this into my implementation class. The last thing I had done was to add some dummy throws. JOB IS DONE! I know this is painful and neither handy nor stylish. But it works. The reason for the StackOverFlowError was the xsd "anyType" data type. I used the tools from oracle to build an deployable archive from classes and the generated WSDL use "anyType" to represent the Java data type "Object". This crashed the oracle AS internal XML parser. I experimented a little bit with tomcat and oracle. I found that the used xerxces parser from biomoby don't like this data type too. But the xerces parser announced an error not a StackOverFlow :-) . Now my services are running under both runtimes. Karl From edward.kawas at gmail.com Thu Jul 20 10:34:32 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 20 Jul 2006 07:34:32 -0700 Subject: [MOBY-dev] jMoby Java 1.4 In-Reply-To: <44BF4A74.7090800@ipk-gatersleben.de> Message-ID: <004d01c6ac09$9e6e9c10$6a00a8c0@notebook> Hi Karl, If you download the latest version of Taverna, you will find in the lib directory some jars that start with jMoby*.jar. Those where compiled in 1.4. Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Karl Spies > Sent: Thursday, July 20, 2006 2:19 AM > To: Core developer announcements > Subject: [MOBY-dev] jMoby Java 1.4 > > Hi, > > I know the change to Java 1.5 compiler has been discussed, > but now I need a Java 1.4 compatible version. Is there an CVS > arch or something like that? Or which date is the last, that > contain only Java 1.4 compatible stuff? > > Sorry of that late entrance in this discussion. > > Karl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From spies at ipk-gatersleben.de Thu Jul 20 13:33:16 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 19:33:16 +0200 Subject: [MOBY-dev] jMoby core libraries Message-ID: <44BFBE5C.6020207@ipk-gatersleben.de> Hi, I tried to find out which were the core libraries to run BioMoby services, but I can't find a hint in the documentation. Can anybody help me out with that problem? I need a lightweight deployable archive for my application server. Thanks Karl From senger at ebi.ac.uk Thu Jul 20 13:50:26 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 20 Jul 2006 18:50:26 +0100 (BST) Subject: [MOBY-dev] jMoby core libraries In-Reply-To: <44BFBE5C.6020207@ipk-gatersleben.de> Message-ID: > I tried to find out which were the core libraries to run BioMoby > services > The 'core' libraries that are needed for running BioMoby services that were generated by MoSeS are those that are used when deploying biomoby services to Tomcat. They are listed in xmls/deployBuild.xml, and they are: lib/alltools2.jar lib/jdom.jar lib/commons-lang-2.1.jar and build/lib/jmoby.jar At least, this was true before the big bang done by Paul (when he moved things to Java 1.5 and from some obscure :-) reasons restructured some libraries). Since I have not had chance to try. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From spies at ipk-gatersleben.de Thu Jul 20 14:15:06 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 20:15:06 +0200 Subject: [MOBY-dev] jMoby core libraries In-Reply-To: References: Message-ID: <44BFC82A.6050404@ipk-gatersleben.de> Hi Martin, thank you for that help. I made a little bit "try and error" :-). I found the libraries you mentioned. The tulsoft API require the xerces library. I tried other implementations for the SAXParser but it fails. So the expand the list to: alltools2.jar jdom.jar commons-lang-2.1.jar jmoby.jar xercesImpl.jar Karl From senger at ebi.ac.uk Thu Jul 20 14:38:13 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 20 Jul 2006 19:38:13 +0100 (BST) Subject: [MOBY-dev] jMoby core libraries In-Reply-To: <44BFC82A.6050404@ipk-gatersleben.de> Message-ID: > The tulsoft API require the xerces library. > Yes, that's true. I considered xerces library a default for tomcat so I forgot to mention it. Sorry... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Thu Jul 20 14:45:37 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 20 Jul 2006 12:45:37 -0600 Subject: [MOBY-dev] jMoby core libraries In-Reply-To: References: Message-ID: <44BFCF51.6090306@ucalgary.ca> None of my changes added any library dependencies. I am anti-library dependency all the way :-) > The 'core' libraries that are needed for running BioMoby services that > were generated by MoSeS are those that are used when deploying biomoby > services to Tomcat. They are listed in xmls/deployBuild.xml, and they are: > lib/alltools2.jar > lib/jdom.jar > lib/commons-lang-2.1.jar > and > build/lib/jmoby.jar > > At least, this was true before the big bang done by Paul (when he moved > things to Java 1.5 and from some obscure :-) reasons restructured some > libraries). Since I have not had chance to try. > From senger at ebi.ac.uk Thu Jul 20 18:21:37 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 20 Jul 2006 23:21:37 +0100 (BST) Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: <44BF7388.8000208@ipk-gatersleben.de> Message-ID: Thanks for details about oracle web services requirements. Interesting, and good to know. > The reason is, that oracle is very strict with there design of web > service. You are not allowed to use any abstract method in your > implementation classes. > It's a bit strange because the class that represents a moby service does not have any abstract method. The generated skeleton has, but your implementation class (that extends the skeleton and implements method processIt()) does not have. And it is the implementation class that is used to be deployed. > An other requirement is that every oracle based web service must have > an interface which extends from java.rmi.Remote and very method > declaration must throw a java.rmi.RemoteException. > Okay, good to know. So why not just to implement (actually to extend) this interface in your implementation class? I may not understand fully the concept of the Remote interface, but a brief reading of javadoc tells me that "Only those methods specified in a 'remote interface', an interface that extends java.rmi.Remote are available remotely." Which indicates that perhaps something like this could work (assuming, for example, that your service name is 'HelloOracle'): // this class is generated by MoSeS abstract class your.authority.HelloOracleSkel {...} // this clas is deployed as a web service main class class your.package.HelloOracleImpl extends your.authority.HelloOracleSkel implements HelloOracleRemote { ... } // this interface should make oracle happy interface HelloOracleRemote extends java.rmi.Remote { String HelloOracle (Object data); } > Now my services are running under both runtimes. > And that's the main thing! Perfect. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From spies at ipk-gatersleben.de Fri Jul 21 03:52:26 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Fri, 21 Jul 2006 09:52:26 +0200 Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: References: Message-ID: <44C087BA.6090603@ipk-gatersleben.de> Hi, > It's a bit strange because the class that represents a moby service > does not have any abstract method. The generated skeleton has, but your > implementation class (that extends the skeleton and implements method > processIt()) does not have. And it is the implementation class that is > used to be deployed. You are right about that the implementation class does not have any abstract method. This is my fault. I am trying to explain it again. :-) The main concept of moses service generation is to extend the org.biomoby.service.BaseService and put all needed stuff in it. The service providers only needs to overwrite the abstract process method from BaseService in there implementation class. The Oracle system don't like this. I don't know why. I think its stupid. :-( > Okay, good to know. So why not just to implement (actually to extend) > this interface in your implementation class? I may not understand fully > the concept of the Remote interface, but a brief reading of javadoc tells > me that "Only those methods specified in a 'remote interface', an > interface that extends java.rmi.Remote are available remotely." Which > indicates that perhaps something like this could work (assuming, for > example, that your service name is 'HelloOracle'): > > // this class is generated by MoSeS > abstract class your.authority.HelloOracleSkel {...} > > // this clas is deployed as a web service main class > class your.package.HelloOracleImpl > extends your.authority.HelloOracleSkel > implements HelloOracleRemote { > ... > } > > // this interface should make oracle happy > interface HelloOracleRemote > extends java.rmi.Remote { > String HelloOracle (Object data); > } > I done it exactly like you, but the HelloOracleSkel extends the BaseService and again oracle fails to execute the service. My solution was to copy the BaseService, rename it, and change the abstract method into a "normal" method. Karl From spies at ipk-gatersleben.de Fri Jul 21 03:57:45 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Fri, 21 Jul 2006 09:57:45 +0200 Subject: [MOBY-dev] jMoby core libraries In-Reply-To: <44BFCF51.6090306@ucalgary.ca> References: <44BFCF51.6090306@ucalgary.ca> Message-ID: <44C088F9.5060805@ipk-gatersleben.de> Hi, here is the complete list of libraries to deploy a BioMOBY Service to a non tomcat system. jmoby.jar commons-lang-2.1.jar commons-logging-1.0.4.jar alltools2.jar xercesImpl.jar xml-apis.jar jdom.jar biomoby-datatypes.jar axis.jar I hope it is useful for somebody else like me :-) Karl From fgibbons at hms.harvard.edu Fri Jul 21 11:48:34 2006 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 21 Jul 2006 11:48:34 -0400 Subject: [MOBY-dev] encodeException question.... Message-ID: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Hi, Been away from MOBY for a while, now I'm back, and I see that everyone's been very busy ;-) Major kudos to Mark/Pieter on his work encoding Exceptions in the Perl API, as well as cleaning up the message-parsing into an object-oriented form. So much cleaner now than in the past! I notice also that the INB group posted to the mailing list some nice-looking code to encode all the work in the RFC from last year, but I didn't see it make it into the actual code base. Am I right? It too looked pretty clean, seems like it'd make a good addition to the codebase. Regarding the docs for CommonSubs::encodeExceptions, it seems to me that the first two arguments are confused: usage: encodeException( -refElement => 'refers to the queryID of the offending input mobyData', -refQueryID => 'refers to the articleName of the offending input Simple or Collection' Surely, 'refQueryID' should contain the queryID, and not refElement, while refElement should contain the articleName. I can fix it, just wanted to check, since I've been away for a while. -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 [1]http://llama.med.harvard.edu/~fgibbons References 1. http://llama.med.harvard.edu/~fgibbons From usadel at mpimp-golm.mpg.de Fri Jul 21 12:23:07 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Fri, 21 Jul 2006 18:23:07 +0200 Subject: [MOBY-dev] encodeException question.... In-Reply-To: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Message-ID: <44C0FF6B.9040902@mpimp-golm.mpg.de> Hi Frank, as far as I am concerned just fix my documentation bug. The reason I incorporated these (methods not the bug) into CommonSubs is that there was no solution available and when I asked in the beginning of the year if somebody was working on it, nobody replied. I personally think the INB solution is cleaner and also contains all the error codes etc., but by then I already had the code checked in. As far as I know their code is not yet checked in. I think also in the OO Perl approach there seems to be some code. So there will be many ways for the same goal. Oh also if you use the CommonSubs methods please report if it actually proves useful. Cheers, Bj?rn Frank Gibbons wrote: > Hi, > Been away from MOBY for a while, now I'm back, and I see that everyone's > been very busy ;-) Major kudos to Mark/Pieter on his work encoding > Exceptions in the Perl API, as well as cleaning up the message-parsing into > an object-oriented form. So much cleaner now than in the past! > I notice also that the INB group posted to the mailing list some > nice-looking code to encode all the work in the RFC from last year, but I > didn't see it make it into the actual code base. Am I right? It too looked > pretty clean, seems like it'd make a good addition to the codebase. > Regarding the docs for CommonSubs::encodeExceptions, it seems to me that the > first two arguments are confused: > usage: > encodeException( > > -refElement => 'refers to the queryID of the offending input > mobyData', > > -refQueryID => 'refers to the articleName of the offending input > Simple or Collection' > > > Surely, 'refQueryID' should contain the queryID, and not refElement, while > refElement should contain the articleName. I can fix it, just wanted to > check, since I've been away for a while. > -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 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From usadel at mpimp-golm.mpg.de Fri Jul 21 12:23:07 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Fri, 21 Jul 2006 18:23:07 +0200 Subject: [MOBY-dev] encodeException question.... In-Reply-To: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Message-ID: <44C0FF6B.9040902@mpimp-golm.mpg.de> Hi Frank, as far as I am concerned just fix my documentation bug. The reason I incorporated these (methods not the bug) into CommonSubs is that there was no solution available and when I asked in the beginning of the year if somebody was working on it, nobody replied. I personally think the INB solution is cleaner and also contains all the error codes etc., but by then I already had the code checked in. As far as I know their code is not yet checked in. I think also in the OO Perl approach there seems to be some code. So there will be many ways for the same goal. Oh also if you use the CommonSubs methods please report if it actually proves useful. Cheers, Bj?rn Frank Gibbons wrote: > Hi, > Been away from MOBY for a while, now I'm back, and I see that everyone's > been very busy ;-) Major kudos to Mark/Pieter on his work encoding > Exceptions in the Perl API, as well as cleaning up the message-parsing into > an object-oriented form. So much cleaner now than in the past! > I notice also that the INB group posted to the mailing list some > nice-looking code to encode all the work in the RFC from last year, but I > didn't see it make it into the actual code base. Am I right? It too looked > pretty clean, seems like it'd make a good addition to the codebase. > Regarding the docs for CommonSubs::encodeExceptions, it seems to me that the > first two arguments are confused: > usage: > encodeException( > > -refElement => 'refers to the queryID of the offending input > mobyData', > > -refQueryID => 'refers to the articleName of the offending input > Simple or Collection' > > > Surely, 'refQueryID' should contain the queryID, and not refElement, while > refElement should contain the articleName. I can fix it, just wanted to > check, since I've been away for a while. > -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 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From fgibbons at hms.harvard.edu Fri Jul 21 14:08:54 2006 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 21 Jul 2006 14:08:54 -0400 Subject: [MOBY-dev] encodeException question.... In-Reply-To: <44C0FF6B.9040902@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060721140730.0123ccc8@email.med.harvard.edu> Thanks for the feedback, Bj?rn. And of course, I should have credited you with the Exception coding in CommonSubs. I'll fix the documentation, and let you know whether I encounter success or failure ;-) Thanks again. -Frank At 12:23 PM 7/21/2006, you wrote: >Hi Frank, > >as far as I am concerned just fix my documentation bug. > >The reason I incorporated these (methods not the bug) into CommonSubs is >that there was no solution available and when I asked in the beginning >of the year if somebody was working on it, nobody replied. > >I personally think the INB solution is cleaner and also contains all the >error codes etc., but by then I already had the code checked in. As far >as I know their code is not yet checked in. > >I think also in the OO Perl approach there seems to be some code. So >there will be many ways for the same goal. > > >Oh also if you use the CommonSubs methods please report if it actually >proves useful. > >Cheers, >Bj?rn > >Frank Gibbons wrote: > > Hi, > > Been away from MOBY for a while, now I'm back, and I see that everyone's > > been very busy ;-) Major kudos to Mark/Pieter on his work encoding > > Exceptions in the Perl API, as well as cleaning up the > message-parsing into > > an object-oriented form. So much cleaner now than in the past! > > I notice also that the INB group posted to the mailing list some > > nice-looking code to encode all the work in the RFC from last year, > but I > > didn't see it make it into the actual code base. Am I right? It too > looked > > pretty clean, seems like it'd make a good addition to the codebase. > > Regarding the docs for CommonSubs::encodeExceptions, it seems to me > that the > > first two arguments are confused: > > usage: > > encodeException( > > > > -refElement => 'refers to the queryID of the offending input > > mobyData', > > > > -refQueryID => 'refers to the articleName of the offending input > > Simple or Collection' > > > > > > Surely, 'refQueryID' should contain the queryID, and not refElement, > while > > refElement should contain the articleName. I can fix it, just wanted to > > check, since I've been away for a while. > > -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 [1]http://llama.med.harvard.edu/~fgibbons > > > > References > > > > 1. http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > >-- >-+-+-+-+-+-+-+-+-+-+-+- >Bj?rn Usadel, PhD > >Max Planck Institute of Molecular Plant Physiology >System Regulation Group > >Am M?hlenberg 1 >D-14476 Golm >Germany > >Tel (+49 331) 567-8114 > >Email usadel at mpimp-golm.mpg.de >WWW mapman.mpimp-golm.mpg.de >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at lists.open-bio.org >http://lists.open-bio.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 markw at illuminae.com Fri Jul 21 16:01:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 21 Jul 2006 13:01:27 -0700 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44C0FF6B.9040902@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF6B.9040902@mpimp-golm.mpg.de> Message-ID: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > I personally think the INB solution is cleaner and also contains all the > error codes etc., but by then I already had the code checked in. As far > as I know their code is not yet checked in. I've asked them why they are reluctant to contribute this code to the CVS (especially since they announced it on this mailing list), and got no answer :-( I really wish they would... M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Fri Jul 21 16:01:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 21 Jul 2006 13:01:27 -0700 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44C0FF6B.9040902@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF6B.9040902@mpimp-golm.mpg.de> Message-ID: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > I personally think the INB solution is cleaner and also contains all the > error codes etc., but by then I already had the code checked in. As far > as I know their code is not yet checked in. I've asked them why they are reluctant to contribute this code to the CVS (especially since they announced it on this mailing list), and got no answer :-( I really wish they would... M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Mon Jul 24 09:57:48 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 24 Jul 2006 13:57:48 +0000 GMT Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> :-) Tell then "modesty doesn't make you famous" :-) Thanks David! M -- Mark Wilkinson ...on the road! -----Original Message----- From: "David G. Pisano" Date: Mon, 24 Jul 2006 10:22:53 To:markw at illuminae.com, Core developer announcements Cc:MOBY-dev at biomoby.org Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > >_______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From markw at illuminae.com Mon Jul 24 09:57:48 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 24 Jul 2006 13:57:48 +0000 GMT Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> :-) Tell then "modesty doesn't make you famous" :-) Thanks David! M -- Mark Wilkinson ...on the road! -----Original Message----- From: "David G. Pisano" Date: Mon, 24 Jul 2006 10:22:53 To:markw at illuminae.com, Core developer announcements Cc:MOBY-dev at biomoby.org Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > >_______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From Pieter.Neerincx at wur.nl Wed Jul 26 05:57:24 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 11:57:24 +0200 Subject: [MOBY-dev] BioMOBY powered logo? In-Reply-To: <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> Message-ID: <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> Hi all, I'm making a poster for a project where we have used BioMOBY to make webservices. I'd like to advertise how wonderfull the BioMOBY project is on that poster, so I was wondering if there is an official "powered by BioMOBY" logo or something like that... Too much text on a poster doesn't sell the message, so I prefer a good logo and a reference to to www.biomoby.org over a literature reference. Cheers, Pi From Pieter.Neerincx at wur.nl Wed Jul 26 06:02:21 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 12:02:21 +0200 Subject: [MOBY-dev] Fwd: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> Message-ID: <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Looks like it's not going to be that soon... I have postponed further S::L testing until that "full release" will become available. Pi On 08 Jul 2006, at 01:00, Mark Wilkinson wrote: > Another release of SOAP::Lite coming soon... > > M > > > > ------- Forwarded message ------- > From: "Byrne Reese" > To: "Chris McMahon" > Cc: soaplite at yahoogroups.com > Subject: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 > Released > Date: Fri, 07 Jul 2006 12:08:24 -0700 > > Yes. Apparently I forgot to check one file in. Damn it. So what worked > for me in development didn't get fully released. > > Please stand-by. An update is forthcoming - perhaps by Monday. > > Chris McMahon wrote: >> >> >> Hi... >> This is significantly better than 0.67. However, I'm getting an >> error vs. the WSDL I need to read: >> >> Type 'ArrayOfstring' can't be found in a schema class >> 'SOAP::Serializer' >> >> Any ideas on fixing this? >> >> On 7/6/06, *Byrne Reese* > > wrote: >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new >> version is >> 0.68 and includes a number of fixes that make working with >> WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs >> (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I >> can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Pieter.Neerincx at wur.nl Wed Jul 26 06:02:21 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 12:02:21 +0200 Subject: [MOBY-dev] Fwd: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> Message-ID: <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Looks like it's not going to be that soon... I have postponed further S::L testing until that "full release" will become available. Pi On 08 Jul 2006, at 01:00, Mark Wilkinson wrote: > Another release of SOAP::Lite coming soon... > > M > > > > ------- Forwarded message ------- > From: "Byrne Reese" > To: "Chris McMahon" > Cc: soaplite at yahoogroups.com > Subject: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 > Released > Date: Fri, 07 Jul 2006 12:08:24 -0700 > > Yes. Apparently I forgot to check one file in. Damn it. So what worked > for me in development didn't get fully released. > > Please stand-by. An update is forthcoming - perhaps by Monday. > > Chris McMahon wrote: >> >> >> Hi... >> This is significantly better than 0.67. However, I'm getting an >> error vs. the WSDL I need to read: >> >> Type 'ArrayOfstring' can't be found in a schema class >> 'SOAP::Serializer' >> >> Any ideas on fixing this? >> >> On 7/6/06, *Byrne Reese* > > wrote: >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new >> version is >> 0.68 and includes a number of fixes that make working with >> WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs >> (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I >> can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Pieter.Neerincx at wur.nl Wed Jul 26 07:53:47 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 13:53:47 +0200 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: Hi All, I was wondering who's traveling to Fortaleza next week. I quickly browsed the program and saw Martin (et al.) will give a presentation at BOSC and will have a poster at ISMB, but I didn't spot any gathering for Mobyfiers yet. It's been a while since Martin organized BioMOBY meetings, so I was wondering in case many of you will be there if we can have some sort of informal BioMOBY gathering. Surely this mailinglist does a fine job, but sometimes it's much faster to talk to people "live" :). Furthermore I'd love to see the faces that go with the names on this list :). So how do the others feel about a BioMOBY lunch or a BioMOBY coffee break meeting point? I also wouldn't mind to stay longer at the convention center for a BioMOBY diner. Then there is also the option of a Birds of a Feather (BOF) meeting during BOSC (These are free- form meetings organized by the attendees themselves to discuss one or a few topics of interest in greater detail). The list with suggestion for BOF topics is still empty last time I checked.... Cheers, Pi From senger at ebi.ac.uk Wed Jul 26 08:24:47 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 26 Jul 2006 13:24:47 +0100 (BST) Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: Message-ID: > It's been a while since Martin organized BioMOBY meetings > Correction: I have never organized such meetings, it was Mark. I have been just too loud to noticed that Mark was there, as well :-). > So how do the others feel about a BioMOBY lunch or a BioMOBY coffee > break meeting point? I also wouldn't mind to stay longer at the > convention center for a BioMOBY diner. Then there is also the option > of a Birds of a Feather (BOF) meeting during BOSC > I definitely agree with the BOF. Actually, that's my only option - I am not staying for ISMB - I will be leaving on the 6th. Thanks for bringing this topic on the table, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Pieter.Neerincx at wur.nl Wed Jul 26 09:27:39 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 15:27:39 +0200 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: References: Message-ID: <5D8551B7-1D22-4CAE-B208-FBA8AFD22B19@wur.nl> On 26 Jul 2006, at 14:24, Martin Senger wrote: >> It's been a while since Martin organized BioMOBY meetings >> > Correction: I have never organized such meetings, it was Mark. I > have > been just too loud to noticed that Mark was there, as well :-). Sorry, I knew it was Mark who organised them. Stupid typo. > >> So how do the others feel about a BioMOBY lunch or a BioMOBY coffee >> break meeting point? I also wouldn't mind to stay longer at the >> convention center for a BioMOBY diner. Then there is also the option >> of a Birds of a Feather (BOF) meeting during BOSC >> > I definitely agree with the BOF. Actually, that's my only option > - I am > not staying for ISMB - I will be leaving on the 6th. Ok, at least a BOF it will be then. I'll register one and hope more people will join. Looking forward to meeting you there, Pi > > Thanks for bringing this topic on the table, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > > From phillip.lord at newcastle.ac.uk Wed Jul 26 10:18:16 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Wed, 26 Jul 2006 15:18:16 +0100 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: (Pieter Neerincx's message of "Wed, 26 Jul 2006 13:53:47 +0200") References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: >>>>> "PN" == Pieter Neerincx writes: PN> So how do the others feel about a BioMOBY lunch or a BioMOBY PN> coffee break meeting point? I also wouldn't mind to stay longer PN> at the convention center for a BioMOBY diner. My understanding is that the convention center is someway from the hotels, and that there will be transport provided too and from. Besides, what's wrong with the beech.... Phil From Pieter.Neerincx at wur.nl Wed Jul 26 11:35:04 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 17:35:04 +0200 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> On 26 Jul 2006, at 16:18, Phillip Lord wrote: >>>>>> "PN" == Pieter Neerincx writes: > > PN> So how do the others feel about a BioMOBY lunch or a BioMOBY > PN> coffee break meeting point? I also wouldn't mind to stay longer > PN> at the convention center for a BioMOBY diner. > > > My understanding is that the convention center is someway from the > hotels, Yes, most hotels are along the coast and the convention center is more towards the center of town. > and that there will be transport provided too and from. > > Besides, what's wrong with the beech.... There's nothing wrong with the beach. Might want to try a BioMOBYfiers cocktail pipeline: everybody bring your own bottle, contribute to the mix and pass a glass on to the next person/ service :). Might result in some good ideas, but the beach is usually not the best place to take notes and my laptop probably doesn't like the sand... So I assume you'll be there too. That's 3 and counting... Pi > > > Phil > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Wed Jul 26 11:36:27 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 26 Jul 2006 16:36:27 +0100 (BST) Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: Message-ID: > Besides, what's wrong with the beech.... > The BOF is for working (concentrating), beach is for relaxing (de-concentrating). Working on the beach is simply wrong. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed Jul 26 11:58:47 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 26 Jul 2006 08:58:47 -0700 Subject: [MOBY-dev] [moby] BioMOBY powered logo? In-Reply-To: <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> Message-ID: <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> Hi Pieter, The M(actg)BY logo here (http://biomoby.org/moby1.gif) is the only logo we really have. There are some "powered-by" buttons, but they aren't that spectacular. There's a nice logo/button created by the Remora group here (http://lipm-bioinfo.toulouse.inra.fr/remora/img/remora.png), but since they use the M(actg)BY logo in their logo, I doubt that they have a high-res version of it. The M(actg)BY logo was created by a colleague of Paul Gordon's way back in 2002... I don't know if the original file still exists, but I have c.c.'d him on this response to bring it to his attention. If not, then all we have is that low-res version of the logo. :-/ M On Wed, 2006-07-26 at 11:57 +0200, Pieter Neerincx wrote: > Hi all, > > I'm making a poster for a project where we have used BioMOBY to make > webservices. I'd like to advertise how wonderfull the BioMOBY project > is on that poster, so I was wondering if there is an official > "powered by BioMOBY" logo or something like that... Too much text on > a poster doesn't sell the message, so I prefer a good logo and a > reference to to www.biomoby.org over a literature reference. > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Jul 26 12:06:12 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 26 Jul 2006 09:06:12 -0700 Subject: [MOBY-dev] [moby] BioMOBY at ISMB / BOSC 2006 In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: <1153929972.15097.27.camel@bioinfo.icapture.ubc.ca> Hi Pieter, Nobody from the Vancouver crew will be at that meeting, unfortunately, but a BOF would be really great - beach or no beach :-) I suspect that some of the Madrid/Barcelona team will be at ISMB as well, and it would be really great for us to somehow better coordinate with their activities. A MOBY Booze-flow pipeline sounds like something I am going to regret missing! M On Wed, 2006-07-26 at 13:53 +0200, Pieter Neerincx wrote: > Hi All, > > I was wondering who's traveling to Fortaleza next week. I quickly > browsed the program and saw Martin (et al.) will give a presentation > at BOSC and will have a poster at ISMB, but I didn't spot any > gathering for Mobyfiers yet. It's been a while since Martin organized > BioMOBY meetings, so I was wondering in case many of you will be > there if we can have some sort of informal BioMOBY gathering. Surely > this mailinglist does a fine job, but sometimes it's much faster to > talk to people "live" :). Furthermore I'd love to see the faces that > go with the names on this list :). > > So how do the others feel about a BioMOBY lunch or a BioMOBY coffee > break meeting point? I also wouldn't mind to stay longer at the > convention center for a BioMOBY diner. Then there is also the option > of a Birds of a Feather (BOF) meeting during BOSC (These are free- > form meetings organized by the attendees themselves to discuss one or > a few topics of interest in greater detail). The list with suggestion > for BOF topics is still empty last time I checked.... > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From phillip.lord at newcastle.ac.uk Wed Jul 26 15:28:09 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Wed, 26 Jul 2006 20:28:09 +0100 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> (Pieter Neerincx's message of "Wed, 26 Jul 2006 17:35:04 +0200") References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> Message-ID: >>>>> "PN" == Pieter Neerincx writes: PN> Yes, most hotels are along the coast and the convention center PN> is more towards the center of town. >> and that there will be transport provided too and from. >> >> Besides, what's wrong with the beech.... PN> There's nothing wrong with the beach. Might want to try a PN> BioMOBYfiers cocktail pipeline: everybody bring your own bottle, PN> contribute to the mix and pass a glass on to the next person/ PN> service :). Might result in some good ideas, but the beach is PN> usually not the best place to take notes and my laptop probably PN> doesn't like the sand... PN> So I assume you'll be there too. That's 3 and counting... Sorry for the last email, sent by mistake. To be honest, I don't think Fortaleza is the sort of place you will need to take a bottle the beech. There should be plenty around. And, yes, I will be there. Although, I would hesitate to describe myself as a BioMOBYier, rather than a mailing list lurker, it would be good to have an opportunity to meet people. Phil From phillip.lord at newcastle.ac.uk Wed Jul 26 15:25:43 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Wed, 26 Jul 2006 20:25:43 +0100 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> (Pieter Neerincx's message of "Wed, 26 Jul 2006 17:35:04 +0200") References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> Message-ID: -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.lord at newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Newcastle University, Claremont Tower, Room 909 NE1 7RU From Pieter.Neerincx at wur.nl Thu Jul 27 14:07:45 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 27 Jul 2006 20:07:45 +0200 Subject: [MOBY-dev] [moby] BioMOBY powered logo? In-Reply-To: <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <6479F85C-EA37-40C4-B342-86A15DB3A682@wur.nl> Hi Mark, I really like the "old" logo and I want to make BioMOBY look good on that poster, so I didn't want to settle for the low-res version. It turns out the font used to create it was American Typewriter and once you have the correct font recreating a high resolution vector image is no longer mission impossible :). I made a new high res version in Adobe Illustrator and PDF format. The position of the Cs, Gs and Ts is slightly different in the new version, but you'll have to see them side by side to notice the difference. To make sure it won't get lost again I checked them into the CVS. They are available from ~moby-live/ Docs/Artwork/ Cheers, Pi On 26-Jul-2006, at 5:58 PM, Mark Wilkinson wrote: > Hi Pieter, > > The M(actg)BY logo here (http://biomoby.org/moby1.gif) is the only > logo > we really have. There are some "powered-by" buttons, but they aren't > that spectacular. There's a nice logo/button created by the Remora > group here (http://lipm-bioinfo.toulouse.inra.fr/remora/img/ > remora.png), > but since they use the M(actg)BY logo in their logo, I doubt that they > have a high-res version of it. > > The M(actg)BY logo was created by a colleague of Paul Gordon's way > back > in 2002... I don't know if the original file still exists, but I have > c.c.'d him on this response to bring it to his attention. If not, > then > all we have is that low-res version of the logo. > > :-/ > > M > > > > > On Wed, 2006-07-26 at 11:57 +0200, Pieter Neerincx wrote: >> Hi all, >> >> I'm making a poster for a project where we have used BioMOBY to make >> webservices. I'd like to advertise how wonderfull the BioMOBY project >> is on that poster, so I was wondering if there is an official >> "powered by BioMOBY" logo or something like that... Too much text on >> a poster doesn't sell the message, so I prefer a good logo and a >> reference to to www.biomoby.org over a literature reference. >> >> Cheers, >> >> Pi >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Thu Jul 27 14:21:05 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 27 Jul 2006 11:21:05 -0700 Subject: [MOBY-dev] [moby] BioMOBY powered logo? In-Reply-To: <6479F85C-EA37-40C4-B342-86A15DB3A682@wur.nl> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> <6479F85C-EA37-40C4-B342-86A15DB3A682@wur.nl> Message-ID: Fantastic!!!!! Thanks!!!!! M On Thu, 27 Jul 2006 11:07:45 -0700, Pieter Neerincx wrote: > Hi Mark, > > I really like the "old" logo and I want to make BioMOBY look good on > that poster, so I didn't want to settle for the low-res version. It > turns out the font used to create it was American Typewriter and once > you have the correct font recreating a high resolution vector image > is no longer mission impossible :). I made a new high res version in > Adobe Illustrator and PDF format. The position of the Cs, Gs and Ts > is slightly different in the new version, but you'll have to see them > side by side to notice the difference. To make sure it won't get lost > again I checked them into the CVS. They are available from ~moby-live/ > Docs/Artwork/ > > Cheers, > > Pi > > > On 26-Jul-2006, at 5:58 PM, Mark Wilkinson wrote: > >> Hi Pieter, >> >> The M(actg)BY logo here (http://biomoby.org/moby1.gif) is the only >> logo >> we really have. There are some "powered-by" buttons, but they aren't >> that spectacular. There's a nice logo/button created by the Remora >> group here (http://lipm-bioinfo.toulouse.inra.fr/remora/img/ >> remora.png), >> but since they use the M(actg)BY logo in their logo, I doubt that they >> have a high-res version of it. >> >> The M(actg)BY logo was created by a colleague of Paul Gordon's way >> back >> in 2002... I don't know if the original file still exists, but I have >> c.c.'d him on this response to bring it to his attention. If not, >> then >> all we have is that low-res version of the logo. >> >> :-/ >> >> M >> >> >> >> >> On Wed, 2006-07-26 at 11:57 +0200, Pieter Neerincx wrote: >>> Hi all, >>> >>> I'm making a poster for a project where we have used BioMOBY to make >>> webservices. I'd like to advertise how wonderfull the BioMOBY project >>> is on that poster, so I was wondering if there is an official >>> "powered by BioMOBY" logo or something like that... Too much text on >>> a poster doesn't sell the message, so I prefer a good logo and a >>> reference to to www.biomoby.org over a literature reference. >>> >>> Cheers, >>> >>> Pi >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of a >> term to >> someone who is unfamiliar with its proper application, the use of >> language that doesn't help such a person learn how to apply the >> term is >> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >> but it is a lousy definition." >> >> K?hler et al, 2006 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From Pieter.Neerincx at wur.nl Fri Jul 28 05:44:15 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 28 Jul 2006 11:44:15 +0200 Subject: [MOBY-dev] [moby] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <1153929972.15097.27.camel@bioinfo.icapture.ubc.ca> References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> <1153929972.15097.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <35E02AE2-4B2C-4DA1-87E1-82795B7E6B3E@wur.nl> On 26-Jul-2006, at 6:06 PM, Mark Wilkinson wrote: > Hi Pieter, > > Nobody from the Vancouver crew will be at that meeting, unfortunately, > but a BOF would be really great - beach or no beach :-) That's really a pitty nobody of your group will be there :(. > I suspect that > some of the Madrid/Barcelona team will be at ISMB as well, and it > would > be really great for us to somehow better coordinate with their > activities. I hope some of them will be there. We'll see. For those who will be there: I registered the first BOF for friday 17:00. http://www.open-bio.org/wiki/BOSC_2006/Birds-of-a-Feather Place is not yet known as I have no clue what options the convention center has... stay tuned. > > A MOBY Booze-flow pipeline sounds like something I am going to regret > missing! Who said there would be booze? Might be healthy juices overloaded with vitamins as well :). Anyway I'll do an intensive case-study and try to document it :). Pi > > M > > > On Wed, 2006-07-26 at 13:53 +0200, Pieter Neerincx wrote: >> Hi All, >> >> I was wondering who's traveling to Fortaleza next week. I quickly >> browsed the program and saw Martin (et al.) will give a presentation >> at BOSC and will have a poster at ISMB, but I didn't spot any >> gathering for Mobyfiers yet. It's been a while since Mark organized >> BioMOBY meetings, so I was wondering in case many of you will be >> there if we can have some sort of informal BioMOBY gathering. Surely >> this mailinglist does a fine job, but sometimes it's much faster to >> talk to people "live" :). Furthermore I'd love to see the faces that >> go with the names on this list :). >> >> So how do the others feel about a BioMOBY lunch or a BioMOBY coffee >> break meeting point? I also wouldn't mind to stay longer at the >> convention center for a BioMOBY diner. Then there is also the option >> of a Birds of a Feather (BOF) meeting during BOSC (These are free- >> form meetings organized by the attendees themselves to discuss one or >> a few topics of interest in greater detail). The list with suggestion >> for BOF topics is still empty last time I checked.... >> >> Cheers, >> >> Pi >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 dgonzalez at cnio.es Mon Jul 24 04:22:53 2006 From: dgonzalez at cnio.es (David G. Pisano) Date: Mon, 24 Jul 2006 10:22:53 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> Message-ID: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From dgonzalez at cnio.es Mon Jul 24 04:22:53 2006 From: dgonzalez at cnio.es (David G. Pisano) Date: Mon, 24 Jul 2006 10:22:53 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> Message-ID: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From dgonzalez at cnio.es Fri Jul 28 08:08:07 2006 From: dgonzalez at cnio.es (David G. Pisano) Date: Fri, 28 Jul 2006 14:08:07 +0200 Subject: [MOBY-dev] Fwd: [Inb-tecnico] inab.org References: <44C9F00F.1010403@cnio.es> Message-ID: <95334374-397E-42A5-8AF1-E2F3EA7B8CC6@cnio.es> For your information (for those of you who sometimes use our moby central at inab.org) Regards, David Begin forwarded message: > From: Eduardo Andr?s Le?n > Date: 28 de julio de 2006 13:07:59 GMT+02:00 > To: "'Lista INB Tecnico'" > Subject: [Inb-tecnico] inab.org > > Hi everybody, > This weekend you may experience wrong functionality at our > URLS : inab.org , www.inab.org, moby-dev.inab.org .... > This is related with the planning movement of all Central Node > resources to our new center. > This movement not only implies physical movement of servers, it > also implies domain movement, dns configuration ... and so on. > > Apart from this wrong functionality , it's planned to move > physically the server on Monday morning, so there will not be > connection to our servers/lists in the whole morning. > > > We have planned everything in order to make this as clear as > possible, with the less interruptions at your work, but ..... I > will appreciate your patience ;) > > Regards. > > -- > Eduardo Andr?s Le?n > Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 2264) > e-mail: leon at cnio.es Fax: (+34) 91 224 69 76 > Unidad de Bioinform?tica Bioinformatics Unit > Centro Nacional de Investigaciones Oncol?gicas > C.P.: 28029 Zip Code: 28029 > C/. Melchor Fern?ndez Almagro, 3 Madrid (Spain) > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso > los ficheros adjuntos, pueden contener informaci?n protegida para > el uso exclusivo de su destinatario. Se proh?be la distribuci?n, > reproducci?n o cualquier otro tipo de transmisi?n por parte de otra > persona que no sea el destinatario. Si usted recibe por error este > correo, se ruega comunicarlo al remitente y borrar el mensaje > recibido. > **CONFIDENTIALITY NOTICE** This email communication and any > attachments may contain confidential and privileged information for > the sole use of the designated recipient named above. Distribution, > reproduction or any other use of this transmission by any party > other than the intended recipient is prohibited. If you are not the > intended recipient please contact the sender and delete all copies. > > _______________________________________________ > Inb-tecnico mailing list > Inb-tecnico at everest.cnb.uam.es > http://everest.cnb.uam.es/cgi-bin/mailman/listinfo/inb-tecnico **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From ots at ac.uma.es Fri Jul 28 12:14:16 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 28 Jul 2006 18:14:16 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <007701c6b260$df802680$346dd696@ac.uma.es> Hi from the gnv5 at the INB we have been working -Johan in particular- in the asynch proposal. We have a almost final (internal) document we plan to submit early next week (there are a little bit of problems with my personnel since they have started vacation time and I am trying to contact them) On the other hand we have developed a prototype for testing the proposal that will also be ckeck-in soon regarding the exception-handling libraries we provide the proposal -discussed internally at the INB and latter in the moby list-, but the code has been developed outside our node. I am sure the owner will checkin the code soon. best regards Oswaldo ----- Original Message ----- From: "David G. Pisano" To: ; "Core developer announcements" Cc: Sent: Monday, July 24, 2006 10:22 AM Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > Seems that our developers are too shy to check in code. I'll try to > get this code checked in by the author. > > Regards, > > David > > On 21/07/2006, at 22:01, Mark Wilkinson wrote: > > > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > > > >> I personally think the INB solution is cleaner and also contains > >> all the > >> error codes etc., but by then I already had the code checked in. > >> As far > >> as I know their code is not yet checked in. > > > > I've asked them why they are reluctant to contribute this code to the > > CVS (especially since they announced it on this mailing list), and got > > no answer :-( > > > > I really wish they would... > > > > M > > > > > > -- > > Mark Wilkinson > > Asst. Professor, Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics, iCAPTURE Centre > > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "Since the point of a definition is to explain the meaning of a > > term to > > someone who is unfamiliar with its proper application, the use of > > language that doesn't help such a person learn how to apply the > > term is > > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > > but it is a lousy definition." > > > > K?hler et al, 2006 > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ots at ac.uma.es Fri Jul 28 12:14:16 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 28 Jul 2006 18:14:16 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <007701c6b260$df802680$346dd696@ac.uma.es> Hi from the gnv5 at the INB we have been working -Johan in particular- in the asynch proposal. We have a almost final (internal) document we plan to submit early next week (there are a little bit of problems with my personnel since they have started vacation time and I am trying to contact them) On the other hand we have developed a prototype for testing the proposal that will also be ckeck-in soon regarding the exception-handling libraries we provide the proposal -discussed internally at the INB and latter in the moby list-, but the code has been developed outside our node. I am sure the owner will checkin the code soon. best regards Oswaldo ----- Original Message ----- From: "David G. Pisano" To: ; "Core developer announcements" Cc: Sent: Monday, July 24, 2006 10:22 AM Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > Seems that our developers are too shy to check in code. I'll try to > get this code checked in by the author. > > Regards, > > David > > On 21/07/2006, at 22:01, Mark Wilkinson wrote: > > > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > > > >> I personally think the INB solution is cleaner and also contains > >> all the > >> error codes etc., but by then I already had the code checked in. > >> As far > >> as I know their code is not yet checked in. > > > > I've asked them why they are reluctant to contribute this code to the > > CVS (especially since they announced it on this mailing list), and got > > no answer :-( > > > > I really wish they would... > > > > M > > > > > > -- > > Mark Wilkinson > > Asst. Professor, Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics, iCAPTURE Centre > > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "Since the point of a definition is to explain the meaning of a > > term to > > someone who is unfamiliar with its proper application, the use of > > language that doesn't help such a person learn how to apply the > > term is > > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > > but it is a lousy definition." > > > > K?hler et al, 2006 > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ddg at ncgr.org Fri Jul 28 13:48:09 2006 From: ddg at ncgr.org (Damian Gessler) Date: Fri, 28 Jul 2006 11:48:09 -0600 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com><44AEB128.3090201@majordojo.com><147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: <017701c6b26d$fd4b7cc0$674413ac@ncgr.org> > I was wondering who's traveling to Fortaleza next week For Semantic MOBY, Cliff Joslyn of LANL (Los Alamos National Lab) will be presenting our paper on how to decompose large monolithic ontologies into distributed (modular) ontologies for use in Semantic Web Services. His talk on Saturday, Aug 5 is part of the Bio-LINK and Bio-Ontologies SIG (http://ismb2006.cbi.cnptia.embrapa.br/sigs.html#jbb and http://bio-ontologies.man.ac.uk/programme.html). Damian. ----- Original Message ----- From: "Pieter Neerincx" To: "Core developer announcements" Sent: Wednesday, July 26, 2006 5:53 AM Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 > Hi All, > > I was wondering who's traveling to Fortaleza next week. I quickly > browsed the program and saw Martin (et al.) will give a presentation > at BOSC and will have a poster at ISMB, but I didn't spot any > gathering for Mobyfiers yet. It's been a while since Martin organized > BioMOBY meetings, so I was wondering in case many of you will be > there if we can have some sort of informal BioMOBY gathering. Surely > this mailinglist does a fine job, but sometimes it's much faster to > talk to people "live" :). Furthermore I'd love to see the faces that > go with the names on this list :). > > So how do the others feel about a BioMOBY lunch or a BioMOBY coffee > break meeting point? I also wouldn't mind to stay longer at the > convention center for a BioMOBY diner. Then there is also the option > of a Birds of a Feather (BOF) meeting during BOSC (These are free- > form meetings organized by the attendees themselves to discuss one or > a few topics of interest in greater detail). The list with suggestion > for BOF topics is still empty last time I checked.... > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From jmrc at cnb.uam.es Tue Jul 4 06:26:25 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Tue, 04 Jul 2006 10:26:25 -0000 Subject: [MOBY-dev] exception reporting In-Reply-To: References: Message-ID: <44AA405F.80702@cnb.uam.es> Hi everyone, I implemented the ability to report exception in the client side. I sorry, we had the code in SVN server but now we have some problems in that server. However, I have attached you a tar file where you can see the code and information related to. I hope help you. If you have any doubt...ask me. Best Regards, Jos?. Mark Wilkinson wrote: > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: MobyException.tar.gz Type: application/gzip Size: 752557 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20060704/b857b5cb/attachment-0002.bin From jmrc at cnb.uam.es Tue Jul 4 06:26:31 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Tue, 04 Jul 2006 10:26:31 -0000 Subject: [MOBY-dev] exception reporting In-Reply-To: References: Message-ID: <44AA405F.80702@cnb.uam.es> Hi everyone, I implemented the ability to report exception in the client side. I sorry, we had the code in SVN server but now we have some problems in that server. However, I have attached you a tar file where you can see the code and information related to. I hope help you. If you have any doubt...ask me. Best Regards, Jos?. Mark Wilkinson wrote: > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: MobyException.tar.gz Type: application/gzip Size: 752557 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20060704/b857b5cb/attachment-0003.bin From jmrc at cnb.uam.es Mon Jul 31 04:47:29 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Mon, 31 Jul 2006 10:47:29 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <007701c6b260$df802680$346dd696@ac.uma.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc. ca><6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> Message-ID: <44CDC3A1.1080103@cnb.uam.es> Hi everyone, Oswaldo Trelles wrote: > Hi from the gnv5 at the INB > > we have been working -Johan in particular- in the asynch proposal. We have a > almost final (internal) document we plan to submit early next week (there > are a little bit of problems with my personnel since they have started > vacation time and I am trying to contact them) > > On the other hand we have developed a prototype for testing the proposal > that will also be ckeck-in soon > > regarding the exception-handling libraries we provide the > proposal -discussed internally at the INB and latter in the moby list-, but > the code has been developed outside our node. I am sure the owner will > checkin the code soon. > > The exception-handling library from the side of services has been checked for INB developers and it is OK. I wrote Mark Wilkinson to upload the code to BioMoby CVS. I am waiting the permissions for the administrator and I hope the code will be there very soon. Best Regards, Jos?. > best regards > Oswaldo > > > > > > > ----- Original Message ----- > From: "David G. Pisano" > To: ; "Core developer announcements" > > Cc: > Sent: Monday, July 24, 2006 10:22 AM > Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > > > >> Seems that our developers are too shy to check in code. I'll try to >> get this code checked in by the author. >> >> Regards, >> >> David >> >> On 21/07/2006, at 22:01, Mark Wilkinson wrote: >> >> >>> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: >>> >>> >>>> I personally think the INB solution is cleaner and also contains >>>> all the >>>> error codes etc., but by then I already had the code checked in. >>>> As far >>>> as I know their code is not yet checked in. >>>> >>> I've asked them why they are reluctant to contribute this code to the >>> CVS (especially since they announced it on this mailing list), and got >>> no answer :-( >>> >>> I really wish they would... >>> >>> M >>> >>> >>> -- >>> Mark Wilkinson >>> Asst. Professor, Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics, iCAPTURE Centre >>> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "Since the point of a definition is to explain the meaning of a >>> term to >>> someone who is unfamiliar with its proper application, the use of >>> language that doesn't help such a person learn how to apply the >>> term is >>> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >>> but it is a lousy definition." >>> >>> K?hler et al, 2006 >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los >> > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo al > remitente y borrar el mensaje recibido. > >> **CONFIDENTIALITY NOTICE** This email communication and any attachments >> > may contain confidential and privileged information for the sole use of the > designated recipient named above. Distribution, reproduction or any other > use of this transmission by any party other than the intended recipient is > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From jmrc at cnb.uam.es Mon Jul 31 04:47:29 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Mon, 31 Jul 2006 10:47:29 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <007701c6b260$df802680$346dd696@ac.uma.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc. ca><6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> Message-ID: <44CDC3A1.1080103@cnb.uam.es> Hi everyone, Oswaldo Trelles wrote: > Hi from the gnv5 at the INB > > we have been working -Johan in particular- in the asynch proposal. We have a > almost final (internal) document we plan to submit early next week (there > are a little bit of problems with my personnel since they have started > vacation time and I am trying to contact them) > > On the other hand we have developed a prototype for testing the proposal > that will also be ckeck-in soon > > regarding the exception-handling libraries we provide the > proposal -discussed internally at the INB and latter in the moby list-, but > the code has been developed outside our node. I am sure the owner will > checkin the code soon. > > The exception-handling library from the side of services has been checked for INB developers and it is OK. I wrote Mark Wilkinson to upload the code to BioMoby CVS. I am waiting the permissions for the administrator and I hope the code will be there very soon. Best Regards, Jos?. > best regards > Oswaldo > > > > > > > ----- Original Message ----- > From: "David G. Pisano" > To: ; "Core developer announcements" > > Cc: > Sent: Monday, July 24, 2006 10:22 AM > Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > > > >> Seems that our developers are too shy to check in code. I'll try to >> get this code checked in by the author. >> >> Regards, >> >> David >> >> On 21/07/2006, at 22:01, Mark Wilkinson wrote: >> >> >>> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: >>> >>> >>>> I personally think the INB solution is cleaner and also contains >>>> all the >>>> error codes etc., but by then I already had the code checked in. >>>> As far >>>> as I know their code is not yet checked in. >>>> >>> I've asked them why they are reluctant to contribute this code to the >>> CVS (especially since they announced it on this mailing list), and got >>> no answer :-( >>> >>> I really wish they would... >>> >>> M >>> >>> >>> -- >>> Mark Wilkinson >>> Asst. Professor, Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics, iCAPTURE Centre >>> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "Since the point of a definition is to explain the meaning of a >>> term to >>> someone who is unfamiliar with its proper application, the use of >>> language that doesn't help such a person learn how to apply the >>> term is >>> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >>> but it is a lousy definition." >>> >>> K?hler et al, 2006 >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los >> > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo al > remitente y borrar el mensaje recibido. > >> **CONFIDENTIALITY NOTICE** This email communication and any attachments >> > may contain confidential and privileged information for the sole use of the > designated recipient named above. Distribution, reproduction or any other > use of this transmission by any party other than the intended recipient is > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From usadel at mpimp-golm.mpg.de Mon Jul 31 08:54:41 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Mon, 31 Jul 2006 14:54:41 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44CDC3A1.1080103@cnb.uam.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc. ca><6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> <44CDC3A1.1080103@cnb.uam.es> Message-ID: <44CDFD91.9090102@mpimp-golm.mpg.de> Cool, I think you guys know best, how to interpret your RFC anyway. Should we then revert the code from CommonSubs, so as to avoid duplicated code or do we stick to Perl's "there is more than one way to do it" ? Do you have some code examples? We might want to put them in the tutorials and also hand them over to other tutorials on the web (I could do so for the TIGR wiki) Cheers, Bj?rn Jose Manuel Rodriguez wrote: > Hi everyone, > > Oswaldo Trelles wrote: >> Hi from the gnv5 at the INB >> >> we have been working -Johan in particular- in the asynch proposal. We have a >> almost final (internal) document we plan to submit early next week (there >> are a little bit of problems with my personnel since they have started >> vacation time and I am trying to contact them) >> >> On the other hand we have developed a prototype for testing the proposal >> that will also be ckeck-in soon >> >> regarding the exception-handling libraries we provide the >> proposal -discussed internally at the INB and latter in the moby list-, but >> the code has been developed outside our node. I am sure the owner will >> checkin the code soon. >> >> > The exception-handling library from the side of services has been > checked for INB developers and it is OK. I wrote Mark Wilkinson to > upload the code to BioMoby CVS. I am waiting the permissions for the > administrator and I hope the code will be there very soon. > > Best Regards, > Jos?. > > >> best regards >> Oswaldo >> >> >> >> >> >> >> ----- Original Message ----- >> From: "David G. Pisano" >> To: ; "Core developer announcements" >> >> Cc: >> Sent: Monday, July 24, 2006 10:22 AM >> Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... >> >> >> >>> Seems that our developers are too shy to check in code. I'll try to >>> get this code checked in by the author. >>> >>> Regards, >>> >>> David >>> >>> On 21/07/2006, at 22:01, Mark Wilkinson wrote: >>> >>> >>>> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: >>>> >>>> >>>>> I personally think the INB solution is cleaner and also contains >>>>> all the >>>>> error codes etc., but by then I already had the code checked in. >>>>> As far >>>>> as I know their code is not yet checked in. >>>>> >>>> I've asked them why they are reluctant to contribute this code to the >>>> CVS (especially since they announced it on this mailing list), and got >>>> no answer :-( >>>> >>>> I really wish they would... >>>> >>>> M >>>> >>>> >>>> -- >>>> Mark Wilkinson >>>> Asst. Professor, Dept. of Medical Genetics >>>> University of British Columbia >>>> PI in Bioinformatics, iCAPTURE Centre >>>> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >>>> Vancouver, BC, V6Z 1Y6 >>>> tel: 604 682 2344 x62129 >>>> fax: 604 806 9274 >>>> >>>> "Since the point of a definition is to explain the meaning of a >>>> term to >>>> someone who is unfamiliar with its proper application, the use of >>>> language that doesn't help such a person learn how to apply the >>>> term is >>>> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >>>> but it is a lousy definition." >>>> >>>> K?hler et al, 2006 >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>> **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los >>> >> ficheros adjuntos, pueden contener informaci?n protegida para el uso >> exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o >> cualquier otro tipo de transmisi?n por parte de otra persona que no sea el >> destinatario. Si usted recibe por error este correo, se ruega comunicarlo al >> remitente y borrar el mensaje recibido. >> >>> **CONFIDENTIALITY NOTICE** This email communication and any attachments >>> >> may contain confidential and privileged information for the sole use of the >> designated recipient named above. Distribution, reproduction or any other >> use of this transmission by any party other than the intended recipient is >> prohibited. If you are not the intended recipient please contact the sender >> and delete all copies. >> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From spies at ipk-gatersleben.de Mon Jul 31 12:54:06 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Mon, 31 Jul 2006 18:54:06 +0200 Subject: [MOBY-dev] RDF Generation Message-ID: <44CE35AE.6070305@ipk-gatersleben.de> Hi, I'm looking for a tool which helps me with rdf generation for biomoby service. I don't want to do this by hand. Is there any such tool? How long will be the old registration style(XML) supported by biomoby? Karl From gss at ncgr.org Mon Jul 31 13:28:03 2006 From: gss at ncgr.org (Gary Schiltz) Date: Mon, 31 Jul 2006 11:28:03 -0600 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE35AE.6070305@ipk-gatersleben.de> References: <44CE35AE.6070305@ipk-gatersleben.de> Message-ID: <44CE3DA3.6060905@ncgr.org> If you're using Java, a rather heavyweight but very nice tool defacto standard tool for working with RDF is Jena (http://jena.sourceforge.net). If you're using Perl, then I'm no authority, but the RDF::Core (http://search.cpan.org/~dpokorny/RDF-Core-0.50/lib/RDF/Core.pm) set of modules looks good. // Gary Karl Spies wrote: > Hi, > > I'm looking for a tool which helps me with rdf generation for biomoby > service. I don't want to do this by hand. > > Is there any such tool? > > How long will be the old registration style(XML) supported by biomoby? > > Karl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From spies at ipk-gatersleben.de Mon Jul 31 14:10:45 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Mon, 31 Jul 2006 20:10:45 +0200 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE3DA3.6060905@ncgr.org> References: <44CE35AE.6070305@ipk-gatersleben.de> <44CE3DA3.6060905@ncgr.org> Message-ID: <44CE47A5.4080207@ipk-gatersleben.de> Hi, thanks for the hint to jena. But the existing jMOBY or MobyCentral doesn't support such tool? I'am a little bit busy at the moment and I hoped for a ready to use tool. :-) Karl From edward.kawas at gmail.com Mon Jul 31 13:40:55 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 31 Jul 2006 10:40:55 -0700 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE3DA3.6060905@ncgr.org> Message-ID: <006001c6b4c8$7a8281f0$6a00a8c0@notebook> Hi, If all you want is the RDF-XML that describes MOBY services, then the following should be what you are looking for: RDFGenerator (http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator)- Retrieve the RDF representation for your BioMoby Service. This servlet takes in the following parameters: * name - the name of your service * auth - the service providers authority URI * url - an optional mobycentral registry endpoint to use when generating your RDF * uri - an optional mobycentral registry namespace to use when generating your RDF If you are using JAVA and want to be able to programmatically generate RDF for any arbitrary service, then take a look at the class: org.biomoby.client.rdf.builder.ServiceInstanceRDF Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Gary Schiltz > Sent: Monday, July 31, 2006 10:28 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] RDF Generation > > If you're using Java, a rather heavyweight but very nice tool > defacto standard tool for working with RDF is Jena > (http://jena.sourceforge.net). > > If you're using Perl, then I'm no authority, but the RDF::Core > (http://search.cpan.org/~dpokorny/RDF-Core-0.50/lib/RDF/Core.p > m) set of modules looks good. > > // Gary > > Karl Spies wrote: > > Hi, > > > > I'm looking for a tool which helps me with rdf generation > for biomoby > > service. I don't want to do this by hand. > > > > Is there any such tool? > > > > How long will be the old registration style(XML) supported > by biomoby? > > > > Karl > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From spies at ipk-gatersleben.de Mon Jul 31 17:40:50 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Mon, 31 Jul 2006 23:40:50 +0200 Subject: [MOBY-dev] RDF Generation In-Reply-To: <006001c6b4c8$7a8281f0$6a00a8c0@notebook> References: <006001c6b4c8$7a8281f0$6a00a8c0@notebook> Message-ID: <44CE78E2.708@ipk-gatersleben.de> Hi, thank you. The servlet is exactly what I need, but I think there is an error. http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerato produces "The service name is missing". Thanks again for that quick help. Karl From markw at illuminae.com Mon Jul 31 18:41:39 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 31 Jul 2006 15:41:39 -0700 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44CDFD91.9090102@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc. ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> <44CDC3A1.1080103@cnb.uam.es> <44CDFD91.9090102@mpimp-golm.mpg.de> Message-ID: On Mon, 31 Jul 2006 05:54:41 -0700, Bj?rn Usadel wrote: > Cool, > > I think you guys know best, how to interpret your RFC anyway. > > Should we then revert the code from CommonSubs, so as to avoid > duplicated code or do we stick to Perl's "there is more than one way to > do it" ? I think we should use the INB code modules, and remove the current code from CommonSubs. The CommonSubs module will soon be replaced (though not removed, for legacy reasons) with Martin and Eddie's work on Perl MoSeS... which is unbelievably cool! M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From edward.kawas at gmail.com Mon Jul 31 18:21:19 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 31 Jul 2006 15:21:19 -0700 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE78E2.708@ipk-gatersleben.de> Message-ID: <001b01c6b4ef$a67ed070$756fa8c0@notebook> Hi, You will have to provide some parameters, for example, to generate RDF for getGOTerm,bioinfo.icapture.ubc.ca http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator?name=getGoTerm&aut h=bioinfo.icapture.ubc.ca The parameters you can use are: * name - the name of your service * auth - the service providers authority URI * url - an optional mobycentral registry endpoint to use when generating your RDF * uri - an optional mobycentral registry namespace to use when generating your RDF Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Karl Spies > Sent: Monday, July 31, 2006 2:41 PM > To: Core developer announcements > Subject: Re: [MOBY-dev] RDF Generation > > Hi, > > thank you. The servlet is exactly what I need, but I think > there is an error. > > http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerato > produces "The service name is missing". > > Thanks again for that quick help. > > Karl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From akerhornou at imim.es Mon Jul 3 10:46:27 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 12:46:27 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 Message-ID: <44A8F583.8050700@imim.es> Hi everyone, I'd would like to track information about requests i receive from always the same IP address, 137.82.67.190. They don't really affect our services, i'm just curious about what's behind this. i can't map this IP address to a DNS entry, and it seems to request the services at 'genome.imim.es' on a regular basis, with empty an mobyData bloc, so they always fail. Is it happening to anyone else ? thanks Arnaud From senger at ebi.ac.uk Mon Jul 3 11:17:09 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 12:17:09 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A8F583.8050700@imim.es> Message-ID: > I'd would like to track information about requests i receive from always > the same IP address, 137.82.67.190. > My trace router locates this IP address to Vancouver (network UBC). Perhaps the famous moby agent? :-) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Sebastien.Carrere at toulouse.inra.fr Mon Jul 3 11:33:41 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Mon, 03 Jul 2006 13:33:41 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: Message-ID: <44A90095.3060302@toulouse.inra.fr> Bonjour a tous, I've got the same huge amount of requests ... The last point reached by my router is : stpaulshub1.net.ubc.ca Sebastien Martin Senger a ?crit : >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. >> >> > My trace router locates this IP address to Vancouver (network UBC). > Perhaps the famous moby agent? :-) > > Martin > > -- __________________________________________________________ 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 Sebastien.Carrere at toulouse.inra.fr Mon Jul 3 11:33:41 2006 From: Sebastien.Carrere at toulouse.inra.fr (Sebastien Carrere) Date: Mon, 03 Jul 2006 13:33:41 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: Message-ID: <44A90095.3060302@toulouse.inra.fr> Bonjour a tous, I've got the same huge amount of requests ... The last point reached by my router is : stpaulshub1.net.ubc.ca Sebastien Martin Senger a ?crit : >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. >> >> > My trace router locates this IP address to Vancouver (network UBC). > Perhaps the famous moby agent? :-) > > Martin > > -- __________________________________________________________ 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 tmo at ebi.ac.uk Mon Jul 3 11:56:56 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 03 Jul 2006 12:56:56 +0100 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A90095.3060302@toulouse.inra.fr> References: <44A90095.3060302@toulouse.inra.fr> Message-ID: <44A90608.2070800@ebi.ac.uk> Sebastien Carrere wrote: > Bonjour a tous, > > I've got the same huge amount of requests ... > The last point reached by my router is : stpaulshub1.net.ubc.ca It's Mark's secret moby robot designed to up the hits for the next grant report :p Nah, just kidding, I've no idea what it is... Tom From tmo at ebi.ac.uk Mon Jul 3 11:56:56 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Mon, 03 Jul 2006 12:56:56 +0100 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A90095.3060302@toulouse.inra.fr> References: <44A90095.3060302@toulouse.inra.fr> Message-ID: <44A90608.2070800@ebi.ac.uk> Sebastien Carrere wrote: > Bonjour a tous, > > I've got the same huge amount of requests ... > The last point reached by my router is : stpaulshub1.net.ubc.ca It's Mark's secret moby robot designed to up the hits for the next grant report :p Nah, just kidding, I've no idea what it is... Tom From markw at illuminae.com Mon Jul 3 13:01:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Jul 2006 06:01:20 -0700 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A8F583.8050700@imim.es> References: <44A8F583.8050700@imim.es> Message-ID: This is Eddie's "isAlive?" script. It runs on a cron and hits every service in the registry with an empty mobyData block to see if the service responds with the same (as per the API). If not, the service is flagged as "dead" and this information is available in the LSID metadata for that service. We just started experimenting with this last week. If it is bothering you we can reduce the frequency of the cron... I don't actually know how frequent it is right now. M On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou wrote: > Hi everyone, > > I'd would like to track information about requests i receive from always > the same IP address, 137.82.67.190. They don't really affect our > services, i'm just curious about what's behind this. > i can't map this IP address to a DNS entry, and it seems to request the > services at 'genome.imim.es' on a regular basis, with empty an mobyData > bloc, so they always fail. > > Is it happening to anyone else ? > > thanks > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Jul 3 13:01:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Jul 2006 06:01:20 -0700 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A8F583.8050700@imim.es> References: <44A8F583.8050700@imim.es> Message-ID: This is Eddie's "isAlive?" script. It runs on a cron and hits every service in the registry with an empty mobyData block to see if the service responds with the same (as per the API). If not, the service is flagged as "dead" and this information is available in the LSID metadata for that service. We just started experimenting with this last week. If it is bothering you we can reduce the frequency of the cron... I don't actually know how frequent it is right now. M On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou wrote: > Hi everyone, > > I'd would like to track information about requests i receive from always > the same IP address, 137.82.67.190. They don't really affect our > services, i'm just curious about what's behind this. > i can't map this IP address to a DNS entry, and it seems to request the > services at 'genome.imim.es' on a regular basis, with empty an mobyData > bloc, so they always fail. > > Is it happening to anyone else ? > > thanks > Arnaud > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From akerhornou at imim.es Mon Jul 3 13:15:11 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 15:15:11 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: <44A8F583.8050700@imim.es> Message-ID: <44A9185F.4010502@imim.es> Mark Wilkinson wrote: > This is Eddie's "isAlive?" script. It runs on a cron and hits every > service in the registry with an empty mobyData block to see if the > service responds with the same (as per the API). If not, the service > is flagged as "dead" and this information is available in the LSID > metadata for that service. We just started experimenting with this > last week. > > If it is bothering you we can reduce the frequency of the cron... I > don't actually know how frequent it is right now. > it doesn't really affect the services, just the access and success rate statistics ;-) > M > > > > > On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou > wrote: > >> Hi everyone, >> >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. They don't really affect our >> services, i'm just curious about what's behind this. >> i can't map this IP address to a DNS entry, and it seems to request the >> services at 'genome.imim.es' on a regular basis, with empty an mobyData >> bloc, so they always fail. >> >> Is it happening to anyone else ? >> >> thanks >> Arnaud >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From senger at ebi.ac.uk Mon Jul 3 13:25:28 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:25:28 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: Message-ID: > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 13:25:28 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:25:28 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: Message-ID: > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From akerhornou at imim.es Mon Jul 3 13:15:11 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 15:15:11 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: References: <44A8F583.8050700@imim.es> Message-ID: <44A9185F.4010502@imim.es> Mark Wilkinson wrote: > This is Eddie's "isAlive?" script. It runs on a cron and hits every > service in the registry with an empty mobyData block to see if the > service responds with the same (as per the API). If not, the service > is flagged as "dead" and this information is available in the LSID > metadata for that service. We just started experimenting with this > last week. > > If it is bothering you we can reduce the frequency of the cron... I > don't actually know how frequent it is right now. > it doesn't really affect the services, just the access and success rate statistics ;-) > M > > > > > On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou > wrote: > >> Hi everyone, >> >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. They don't really affect our >> services, i'm just curious about what's behind this. >> i can't map this IP address to a DNS entry, and it seems to request the >> services at 'genome.imim.es' on a regular basis, with empty an mobyData >> bloc, so they always fail. >> >> Is it happening to anyone else ? >> >> thanks >> Arnaud >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From senger at ebi.ac.uk Mon Jul 3 13:29:49 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:29:49 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A9185F.4010502@imim.es> Message-ID: > it doesn't really affect the services, just the access and success rate > statistics ;-) > Well, every hit affect your srevices :-) And you are definitely right about the statistics: Such automatic tool should have a distinguish signature (HTTP_USER_AGENT variable). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 13:29:49 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 14:29:49 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 In-Reply-To: <44A9185F.4010502@imim.es> Message-ID: > it doesn't really affect the services, just the access and success rate > statistics ;-) > Well, every hit affect your srevices :-) And you are definitely right about the statistics: Such automatic tool should have a distinguish signature (HTTP_USER_AGENT variable). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From darin.london at duke.edu Mon Jul 3 12:41:33 2006 From: darin.london at duke.edu (Darin London) Date: Mon, 03 Jul 2006 08:41:33 -0400 Subject: [MOBY-dev] Call For Birds of a Feather Suggestions Message-ID: <44A9107D.2050304@duke.edu> The BOSC organizing comittee is currently seeking suggestions for Birds of a Feather meeting ideas. Birds of a Feather meetings are one of the more popular activities at BOSC, occurring at the end of each days session. These are free-form meetings organized by the attendees themselves to discuss one or a few topics of interest in greater detail. BOF?s have been formed to allow developers and users of individual OBF software to meet each other face-to-face to discuss the project, or to discuss completely new ideas, and even start new software development projects. These meetings offer a unique opportunity for individuals to explore more about the activities of the various Open Source Projects, and, in some cases, even take an active role influencing the future of Open Source Software development. If you would like to create a BOF, just sign up for a wiki account, login, and edit the BOSC 2006 Birds of a Feather page. From markw at illuminae.com Mon Jul 3 14:24:43 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 3 Jul 2006 14:24:43 +0000 GMT Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> I'm on my blackberry at the moment so I can't point you to a document directly right now, however I can explain more fully. It likely isn't stated outright in the API, but it is a consequence of other API requirements. One requirement is that there must be one mobyData block in the output for every mobyData block in the input, regardless of whether or not you were able to process it. It says something like that in the API, but as I said, I don't have access to the docs right now. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Mon, 3 Jul 2006 14:25:28 To:Mark Wilkinson Cc:mobydev , Core developer announcements Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Jul 3 14:24:43 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 3 Jul 2006 14:24:43 +0000 GMT Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> I'm on my blackberry at the moment so I can't point you to a document directly right now, however I can explain more fully. It likely isn't stated outright in the API, but it is a consequence of other API requirements. One requirement is that there must be one mobyData block in the output for every mobyData block in the input, regardless of whether or not you were able to process it. It says something like that in the API, but as I said, I don't have access to the docs right now. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Martin Senger Date: Mon, 3 Jul 2006 14:25:28 To:Mark Wilkinson Cc:mobydev , Core developer announcements Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 > service in the registry with an empty mobyData block to see if the service > responds with the same (as per the API) > I have never heard about this part of API. I am not saying that it does not exist, but simply that I have never seen it (I see it now, however, in the moby CVS, in your service implementation). And I have never mentioned it in any of my courses, and definitely the Moses generated services do not have any support for that. Could you point me up to the place in the API where it is documented perhaps? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From akerhornou at imim.es Mon Jul 3 14:35:24 2006 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 03 Jul 2006 16:35:24 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <736246661-1151936853-cardhu_blackberry.rim.net-21340-@engine26-cell01> References: <44A8F583.8050700@imim.es> <44A9185F.4010502@imim.es> <736246661-1151936853-cardhu_blackberry.rim.net-21340-@engine26-cell01> Message-ID: <44A92B2C.8000200@imim.es> mark wilkinson wrote: > I would call it a "success" if it returns an empty mobyData block :-) > > It all depends how you define success! > > It returns an empty mobyData block but because it fails the input validation step - the service is not expecting an empty input mobyData bloc,so it returns in the service note the exception code, 201 - "INPUTS_INVALID" Arn. > M > > > -- > Mark Wilkinson > ...on the road! > > > -----Original Message----- > From: Arnaud Kerhornou > Date: Mon, 03 Jul 2006 15:15:11 > To:Core developer announcements > Cc:mobydev > Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP > address - 137.82.67.190 > > > > Mark Wilkinson wrote: > >> This is Eddie's "isAlive?" script. It runs on a cron and hits every >> service in the registry with an empty mobyData block to see if the >> service responds with the same (as per the API). If not, the service >> is flagged as "dead" and this information is available in the LSID >> metadata for that service. We just started experimenting with this >> last week. >> >> If it is bothering you we can reduce the frequency of the cron... I >> don't actually know how frequent it is right now. >> >> > it doesn't really affect the services, just the access and success rate > statistics ;-) > >> M >> >> >> >> >> On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou >> wrote: >> >> >>> Hi everyone, >>> >>> I'd would like to track information about requests i receive from always >>> the same IP address, 137.82.67.190. They don't really affect our >>> services, i'm just curious about what's behind this. >>> i can't map this IP address to a DNS entry, and it seems to request the >>> services at 'genome.imim.es' on a regular basis, with empty an mobyData >>> bloc, so they always fail. >>> >>> Is it happening to anyone else ? >>> >>> thanks >>> Arnaud >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From markw at illuminae.com Mon Jul 3 14:27:33 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 3 Jul 2006 14:27:33 +0000 GMT Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <44A9185F.4010502@imim.es> References: <44A8F583.8050700@imim.es> <44A9185F.4010502@imim.es> Message-ID: <736246661-1151936853-cardhu_blackberry.rim.net-21340-@engine26-cell01> I would call it a "success" if it returns an empty mobyData block :-) It all depends how you define success! M -- Mark Wilkinson ...on the road! -----Original Message----- From: Arnaud Kerhornou Date: Mon, 03 Jul 2006 15:15:11 To:Core developer announcements Cc:mobydev Subject: Re: [MOBY-dev] Large amounts of requests from always the same IP address - 137.82.67.190 Mark Wilkinson wrote: > This is Eddie's "isAlive?" script. It runs on a cron and hits every > service in the registry with an empty mobyData block to see if the > service responds with the same (as per the API). If not, the service > is flagged as "dead" and this information is available in the LSID > metadata for that service. We just started experimenting with this > last week. > > If it is bothering you we can reduce the frequency of the cron... I > don't actually know how frequent it is right now. > it doesn't really affect the services, just the access and success rate statistics ;-) > M > > > > > On Mon, 03 Jul 2006 03:46:27 -0700, Arnaud Kerhornou > wrote: > >> Hi everyone, >> >> I'd would like to track information about requests i receive from always >> the same IP address, 137.82.67.190. They don't really affect our >> services, i'm just curious about what's behind this. >> i can't map this IP address to a DNS entry, and it seems to request the >> services at 'genome.imim.es' on a regular basis, with empty an mobyData >> bloc, so they always fail. >> >> Is it happening to anyone else ? >> >> thanks >> Arnaud >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Mon Jul 3 14:37:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 15:37:54 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> Message-ID: > It likely isn't stated outright in the API, but it is a consequence of > other API requirements. One requirement is that there must be one > mobyData block in the output for every mobyData block in the input, > regardless of whether or not you were able to process it. > Well, we can argue this logic :-) However, more important is that this mechanism is not a bad one for the thing we were talking many times - a 'ping' request. Therefore, I will be happy to add it to the services generated from Moses. But I suggest to do first: * a clear definition of this feature in the MOBY API; * including a suggested value for HTTP_USER_AGENT variable that should be used when this 'ping' is invoked; * give service providers time (a deadline) for including this into their services - and only after that your agent should consider services 'dead'. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 14:37:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 15:37:54 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <427150011-1151936681-cardhu_blackberry.rim.net-8735-@engine12-cell01> Message-ID: > It likely isn't stated outright in the API, but it is a consequence of > other API requirements. One requirement is that there must be one > mobyData block in the output for every mobyData block in the input, > regardless of whether or not you were able to process it. > Well, we can argue this logic :-) However, more important is that this mechanism is not a bad one for the thing we were talking many times - a 'ping' request. Therefore, I will be happy to add it to the services generated from Moses. But I suggest to do first: * a clear definition of this feature in the MOBY API; * including a suggested value for HTTP_USER_AGENT variable that should be used when this 'ping' is invoked; * give service providers time (a deadline) for including this into their services - and only after that your agent should consider services 'dead'. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Mon Jul 3 18:37:42 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 3 Jul 2006 19:37:42 +0100 (BST) Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <44A92B2C.8000200@imim.es> Message-ID: > It returns an empty mobyData block but because it fails the input > validation step - the service is not expecting an empty input mobyData > bloc,so it returns in the service note the exception code, 201 - > "INPUTS_INVALID" > See, Mark? It seems that I am not the only one who did not know that this is part of the API :-) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From aloraine at gmail.com Mon Jul 3 21:07:42 2006 From: aloraine at gmail.com (Ann Loraine) Date: Mon, 3 Jul 2006 16:07:42 -0500 Subject: [MOBY-dev] new to list - python? Message-ID: <83722dde0607031407t3f291ecfy77e013e8ad858c6f@mail.gmail.com> Hi, Is anyone on the list working on (or thinking about) a python BioMoby API? Best, Ann Loraine -- Ann Loraine Assistant Professor Section on Statistical Genetics University of Alabama at Birmingham http://www.ssg.uab.edu http://www.transvar.org From markw at illuminae.com Mon Jul 3 22:59:54 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 03 Jul 2006 15:59:54 -0700 Subject: [MOBY-dev] new to list - python? In-Reply-To: <83722dde0607031407t3f291ecfy77e013e8ad858c6f@mail.gmail.com> References: <83722dde0607031407t3f291ecfy77e013e8ad858c6f@mail.gmail.com> Message-ID: There is a Python folder in the moby-live CVS checkout. The original developer of the Python API, however, has left the project for greener pastures. I don't know what the current state of that Python code is... but you are welcome to have a look at it! Mark On Mon, 03 Jul 2006 14:07:42 -0700, Ann Loraine wrote: > Hi, > > Is anyone on the list working on (or thinking about) a python BioMoby > API? > > Best, > > Ann Loraine > From jmrodriguez at cnio.es Tue Jul 4 11:33:04 2006 From: jmrodriguez at cnio.es (Jose Manuel Rodriguez) Date: Tue, 04 Jul 2006 13:33:04 +0200 Subject: [MOBY-dev] exception reporting Message-ID: <44AA51F0.3020301@cnio.es> Hi everyone, I implemented the ability to report exception in the client side. I have the code in SVN server where you can see the code and information in HTML format related to. Even, there is tester script. The URL is http://www.inab.org/svn/Exception/. I hope help you. If you have any doubt...ask me. Best Regards, Jos?. Mark Wilkinson wrote: > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From usadel at mpimp-golm.mpg.de Tue Jul 4 13:25:21 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Tue, 04 Jul 2006 15:25:21 +0200 Subject: [MOBY-dev] Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <44AA6C41.5070102@mpimp-golm.mpg.de> Actually, I interpreted it the same way, so I always send back a serviceNote either 700_OK or whatever I consider the main error is at that moment. However, I guess this should be ok, if only the mobyData block is evaluated. Since exception and notes are decoupled from the data block. A problem might rather be the statement that "the same" data block is returned, since IMHO there would be different ways to write the same message, but I guess this is covered by keepAlive. I generally think it is a good idea, to test service availability and would even support to go further as to supply input/output pairs. Since I can figure out if a service is alive but not if I get back what I expected (e.g. always an empty data block) The API description is here: "There must be as many mobyData response elements as there were mobyData input elements (if a service can not respond to a specific query for whatever reason, this element may be empty!)" http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/OutputMessage.html Cheers, Bj?rn Martin Senger wrote: >> It returns an empty mobyData block but because it fails the input >> validation step - the service is not expecting an empty input mobyData >> bloc,so it returns in the service note the exception code, 201 - >> "INPUTS_INVALID" >> > See, Mark? It seems that I am not the only one who did not know that > this is part of the API :-) > > Martin > -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From markw at illuminae.com Tue Jul 4 14:43:57 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 04 Jul 2006 07:43:57 -0700 Subject: [MOBY-dev] [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <44AA6C41.5070102@mpimp-golm.mpg.de> References: <44AA6C41.5070102@mpimp-golm.mpg.de> Message-ID: <1152024237.25431.23.camel@bioinfo.icapture.ubc.ca> Hmmmmm... and I thought that section of the API was unambiguous :-) but it appears that >66% of the services function the "right" way, so at least some people are able to read my mind!! ;-) (or they copy/pasted my service examples) I seem to have not received some of the messages being quoted here... but it sounds like there is general agreement that the behaviour (I thought was) defined in the API, is a desirable one. This behaviour is also important for cases where, for example, the service HAS no input. For example, consider a service that returns randomly chosen sequences from a database. The service takes no input, and returns FASTA as output. The only way to indicate to that service that you want it to return 18 sequences would be to provide 18 mobyData blocks, each with its own queryID, but otherwise empty. An empty mobyData, in this case, is not only expected but it would be hard to elicit this behaviour any other way given the current API. So, unless there is any objection, I or Eddie will clarify and tighten- up the wording of this section of the API and send it out to everyone for comment to make sure that it is clear enough, and that it accurately represents the behaviour we need/expect. v.v. the "isAlive" script that started this whole conversation: AFAIK the only client that reads the "isAlive" predicate in the LSID metadata is the gbrowse_moby that is on MOBY Central. I needed to "weed out" dead services in order to re-submit the gbrowse_moby manuscript for review. (The last time I sent it to Bioinformatics the reviewers rejected it because many services were dead... which is ridiculous, of course... it's like rejecting Firefox as a browser because of404 errors! Anyway... I wont be submitting it there again!) thanks for all your input! It was great to see a flurry of activity on the list - it's reassuring that the project is still very much alive! Cheers all! Mark On Tue, 2006-07-04 at 15:25 +0200, Bj?rn Usadel wrote: > Actually, > > I interpreted it the same way, so I always send back a serviceNote > either 700_OK or whatever I consider the main error is at that moment. > > However, I guess this should be ok, if only the mobyData block is > evaluated. Since exception and notes are decoupled from the data block. > A problem might rather be the statement that "the same" data block is > returned, since IMHO there would be different ways to write the same > message, but I guess this is covered by keepAlive. > > I generally think it is a good idea, to test service availability and > would even support to go further as to supply input/output pairs. Since > I can figure out if a service is alive but not if I get back what I > expected (e.g. always an empty data block) > > > The API description is here: > "There must be as many mobyData response elements as there were mobyData > input elements (if a service can not respond to a specific query for > whatever reason, this element may be empty!)" > > http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/OutputMessage.html > > Cheers, > Bj?rn > > Martin Senger wrote: > >> It returns an empty mobyData block but because it fails the input > >> validation step - the service is not expecting an empty input mobyData > >> bloc,so it returns in the service note the exception code, 201 - > >> "INPUTS_INVALID" > >> > > See, Mark? It seems that I am not the only one who did not know that > > this is part of the API :-) > > > > Martin > > > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Tue Jul 4 15:14:25 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 4 Jul 2006 16:14:25 +0100 (BST) Subject: [MOBY-dev] [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <1152024237.25431.23.camel@bioinfo.icapture.ubc.ca> Message-ID: > (or they copy/pasted my service examples) > I guess so - that's how I found it. Anyway, I am implementing just now a new Perl library, so I would like to know what should be there. We all seem in agreement that a 'ping' feature is a good one, and we also seem to agree that it can be done by sending "something empty" back. Now, please tell me (rather exactly) the following (you may put the answer into MOBY-API docs and we are done): 1) The 'ping' feature (meaning that the service does not do anything except sending back an empty response) is considered when a request: - has no mobyData elements ("jobs"), OR - has a mobyData element, but without any simple or collection in it? Which is the right answer? 2) [This may already be answered by the previous question.] How does the 'ping' differ from a service that does not expect any input data (such as a HelloWorld service)? Mark already explained this case in his email - but I was not sure how to understand it. 3) When I am sending a 'ping' request, should I set an HTTP variable indicating the client (usually the HTTP_USER_AGENT) to some special value? If yes, which one? Thanks. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Tue Jul 4 16:01:34 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 04 Jul 2006 09:01:34 -0700 Subject: [MOBY-dev] [personal] Re: [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: References: Message-ID: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-07-04 at 16:14 +0100, Martin Senger wrote: > 1) The 'ping' feature (meaning that the service does not do anything > except sending back an empty response) is considered when a request: > - has no mobyData elements ("jobs"), OR > - has a mobyData element, but without any simple or collection in it? > Which is the right answer? My interpretation of the *current* API is that a message with no mobyData element is considered an invalid message (or at least, we have not yet defined a behaviour for this case) and that a "ping" is when a request message has a mobyData element, with no Simple or Collection in it. ***HOWEVER***, I am not sure that this is a good thing: see further thoughts below > 2) [This may already be answered by the previous question.] How does > the 'ping' differ from a service that does not expect any input data > (such as a HelloWorld service)? > Mark already explained this case in his email - but I was not sure how > to understand it. I don't think there is a difference at the moment, and that's a problem. Given the current API a mobyData element with no content is the simplest form of a valid MOBY message. As such, there is no way to distinguish between a "ping" and an intentional service invocation of a service that requires no input. This is a dangerous situation if, for example, the service is a "database dump" service - registered as consuming no input, and dumping an entire database as output! This service would be invoked by our "ping", and this is not a desirable behaviour!! Perhaps it would be better to reserve an empty mobyData block for intentional service invocations (i.e. no changes to the current API with respect to balancing input/output mobyData elements) and define a "ping" as a MOBY message that contains no mobyData block at all (i.e. an extension to the current API) What do you think? > 3) When I am sending a 'ping' request, should I set an HTTP variable > indicating the client (usually the HTTP_USER_AGENT) to some special > value? If yes, which one? Also a good idea. I'd like to take some time to think about this before making any suggestions... does anyone else have suggestions? M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Tue Jul 4 16:15:30 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 4 Jul 2006 17:15:30 +0100 (BST) Subject: [MOBY-dev] [personal] Re: [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> Message-ID: > Perhaps it would be better to reserve an empty mobyData block for > intentional service invocations (i.e. no changes to the current API with > respect to balancing input/output mobyData elements) and define a "ping" > as a MOBY message that contains no mobyData block at all (i.e. an > extension to the current API) > I like this much more than the current 'dangerous' ambiguity. The only disadvantage is that the services need to be updated. (But again, those who are aware of the current 'ping' feature are probably those who are using CommonSubs anyway - so an update of CommonSubs is sufficinet.) > Also a good idea. I'd like to take some time to think about this before > making any suggestions... does anyone else have suggestions? > Just look at http://www.siteware.ch/webresources/useragents/ how many user agents are already around (I do not know how up-to-date the page is). Cheers, Martin PS. I have removed the email (from this thread) from Spain, mentioning the ability not only to 'ping' a service but also to run it with a pre-defined ste of data. We have a CVS module doing exactly that already. If you are interested please check the page http://moby.generationcp.org/mobyenv/index.html. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From usadel at mpimp-golm.mpg.de Wed Jul 5 20:59:24 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Wed, 05 Jul 2006 22:59:24 +0200 Subject: [MOBY-dev] [personal] Re: [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190 In-Reply-To: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> References: <1152028894.25431.42.camel@bioinfo.icapture.ubc.ca> Message-ID: <44AC282C.9010505@mpimp-golm.mpg.de> > > My interpretation of the *current* API is that a message with no > mobyData element is considered an invalid message (or at least, we have > not yet defined a behaviour for this case) and that a "ping" is when a > request message has a mobyData element, with no Simple or Collection in > it. > I think I might be missing something about the no simples/collection and mobyData balancing. Usually perl example services seem to start like this: my $inputs= serviceInputParser($incoming_message); # # or fail properly with an empty response if there is no input return SOAP::Data->type('base64' => responseHeader("my.authURI.com") . responseFooter()) unless (keys %$inputs); Thus replying with a message devoid of any data block, if queried with an empty mobyData block. Since CommonSubs:serviceInputParser only seems to initialize input_parameters if there are any articles within the mobyData blocks. (Verified with a minimal block w/o Simples inside) Or is this where I am missing something important? Also on the input API site it states: " " so not even invoking the service would be an option? Can someone enlighten me please? Or is this just another consequence of the current ambiguity? >Perhaps it would be better to reserve an empty mobyData block for >intentional service invocations (i.e. no changes to the current API with > respect to balancing input/output mobyData elements) and define a "ping" > as a MOBY message that contains no mobyData block at all (i.e. an > extension to the current API) Anyhow, even though I consider a ping service as being important, it should be possible with no code changes at all within the services. Therefore, I also favor the solution which is devoid of any mobyData block. Thus, if the API were extended by specifying that a message with no mobyData element is considered a ping where the reply should be any kind of moby header + footer. (+- servicenotes and exceptions), I guess most everyone (using perl at least) should be auto-compliant with this. (Assuming that most users copied the examples or at least used them as a template) Moreover, this should also generate the lowest overhead in the perl services, since they stop immediately. Cheers, Bj?rn From markw at illuminae.com Thu Jul 6 16:12:29 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:12:29 -0700 Subject: [MOBY-dev] Object ontology curated in the text-* branch Message-ID: <1152202349.31293.11.camel@bioinfo.icapture.ubc.ca> Hi all, In the absence of any objection to my request last week, I bravely went into the database this morning and re-wired the roots of the text-* branch of the Object ontology. Anyway, it looks much better now. There are still some objects at the root level of the ontology that clearly should be children of text-* objects, for example iANT_BLAST-Text, however I cannot curate these manually because the articleName for the contained string is more specific than "content"; I would break the service if I curated it to inherit from text-formatted. Hopefully the providers will eventually find time and motivation to go in and re-register their object/service. There's also the text_plain branch that would be nice to get rid of completely, but we will have to contact individual service providers who are using these objects to request this change. Please let me know ASAP if you notice anything unusual after this edit, M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 16:13:52 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:13:52 -0700 Subject: [MOBY-dev] v.v. the Object Ontology curation Message-ID: <1152202432.31293.13.camel@bioinfo.icapture.ubc.ca> Dashboard users - don't forget to reload the ontology from source. M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Jul 6 16:21:56 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:21:56 +0100 (BST) Subject: [MOBY-dev] v.v. the Object Ontology curation In-Reply-To: <1152202432.31293.13.camel@bioinfo.icapture.ubc.ca> Message-ID: > Dashboard users - don't forget to reload the ontology from source. > Yes. Just a reminder: Now when the registry supports fully LSIDs with versions, you do not need to 'reload' but should be sufficient to 'update' - just use a different button (this should update only those data types that were really changed, so it is faster than reload). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Thu Jul 6 16:23:28 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:23:28 +0100 (BST) Subject: [MOBY-dev] Object ontology curated in the text-* branch In-Reply-To: <1152202349.31293.11.camel@bioinfo.icapture.ubc.ca> Message-ID: Doing the cleaning you could consider to get rid of these Lincoln's (?) old sins, eg. snp_allele not having any parent. (Dashboard can show you them.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jul 6 16:24:46 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:24:46 -0700 Subject: [MOBY-dev] Request for good behaviour Message-ID: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Hi all, As I was poking around the Object ontology this morning I noticed some things that made me "cry". In particular, the way some objects are being defined is... well... not very helpful! The best example is Object Name: "TC" Description: "TC" Another example Object Name: AvailableMaterial Description: Object containing information about available material I am not sure that, given these descriptions, either of these Objects can be used by anyone other than their original author, which kind of defeats the purpose of having an Object ontology :-) The *king* of good object descriptions has got to be Martin Senger, and I think that some of mine are pretty good too... so here are two examples that show how I think it should be done: ================================= Object Name: Regexp Description: This object can carry a regular expression. It can also say what kind of regular expression is carried. Additionally, it can contain some flags that may not be (in some regular expression languages) put directly in the regular expression. The only mandatory member is the regular expression itself ("regex"). The other members are: "format" specifies what language/format/engine is the "regex" for; typical values are Java, Perl, POSIX. "case_insensitive" is a flag that enables case-insensitive matching. "multiline_mode" is a flag that enables multiline mode. In multiline mode the expressions ^ and $ match just after or just before, respectively, a line terminator or the end of the input. "dotall_mode" is a flag that enables dotall mode. In dotall mode, the expression . matches any character, including a line terminator (in Perl, this mode is called single-line mode). "literal_mode" is a flag that enables literal parsing of the pattern. When this flag is specified then the input string that specifies the pattern is treated as a sequence of literal characters. Metacharacters or escape sequences in the input sequence will be given no special meaning. "comments" is a human-readable text explaining what this regular expression means. =============================================== Object Name: GeneticMap Description: A representation of a genetic map. The contained Float (Length) indicates the full length of the map. The contained MappedLocus objects indicate the loci on the map, and their positions. It is likely that the namespace and id for the 'chromosome' component of the contained MapPosition object will usually be the same as the namespace and id for the parent GeneticMap object itself, but this may not always be the case. ================================================ It would be great if we all started putting a couple of extra minutes into defining our objects in a way that would allow other people to discover and use them appropriately... Mark -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 16:36:33 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:36:33 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Oh dear... I forgot about the LSID's... Ouch! that aspect of the LSID specification really is a painful one for database curators! This is actually going to be quite problematic. The edit that I just did was not allowed by the API (which is why I had to do it at the database level). The reason it is not allowed is that service instances use the LSID of their input/output objects as the primary key in the database, so if we update the LSID of every Object that I just modified, then all of those service registrations are broken and would also have to be updated by hand... and so on for each child object, and each service that uses a child object. Can I get a "bye" on doing these LSID updates in this case? please?? It really should be a transparent change v.v. the functionality of the services and the XML representation of the objects. I guess *technically*, since our LSIDs do not resolve by getData, only by getMetadata, we haven't really broken the LSID specification by not updating the version number in this case - we've broken it "in spirit", but not "in practice". >>sigh<< M On Thu, 2006-07-06 at 17:21 +0100, Martin Senger wrote: > > Dashboard users - don't forget to reload the ontology from source. > > > Yes. Just a reminder: Now when the registry supports fully LSIDs with > versions, you do not need to 'reload' but should be sufficient to > 'update' - just use a different button (this should update only those data > types that were really changed, so it is faster than reload). > > Cheers, > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 16:36:33 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:36:33 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Oh dear... I forgot about the LSID's... Ouch! that aspect of the LSID specification really is a painful one for database curators! This is actually going to be quite problematic. The edit that I just did was not allowed by the API (which is why I had to do it at the database level). The reason it is not allowed is that service instances use the LSID of their input/output objects as the primary key in the database, so if we update the LSID of every Object that I just modified, then all of those service registrations are broken and would also have to be updated by hand... and so on for each child object, and each service that uses a child object. Can I get a "bye" on doing these LSID updates in this case? please?? It really should be a transparent change v.v. the functionality of the services and the XML representation of the objects. I guess *technically*, since our LSIDs do not resolve by getData, only by getMetadata, we haven't really broken the LSID specification by not updating the version number in this case - we've broken it "in spirit", but not "in practice". >>sigh<< M On Thu, 2006-07-06 at 17:21 +0100, Martin Senger wrote: > > Dashboard users - don't forget to reload the ontology from source. > > > Yes. Just a reminder: Now when the registry supports fully LSIDs with > versions, you do not need to 'reload' but should be sufficient to > 'update' - just use a different button (this should update only those data > types that were really changed, so it is faster than reload). > > Cheers, > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 16:40:15 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 09:40:15 -0700 Subject: [MOBY-dev] [personal] Re: Object ontology curated in the text-* branch In-Reply-To: References: Message-ID: <1152204015.31293.40.camel@bioinfo.icapture.ubc.ca> Does Dashboard have a "Remove Lincoln's Sins" button? (I hope he's not reading this! ;-) ;-) ) M On Thu, 2006-07-06 at 17:23 +0100, Martin Senger wrote: > Doing the cleaning you could consider to get rid of these Lincoln's > (?) old sins, eg. snp_allele not having any parent. (Dashboard can show > you them.) > > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Jul 6 16:56:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:56:12 +0100 (BST) Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > The reason it is not allowed is that service instances use the LSID of > their input/output objects as the primary key in the database > But why it is like that? The simple name of a data type could be as good as its LSID - of course unless you consider the version in LSID. I think that the primary key could be either an LSID - but in such case the update of all connected entities must happen, or it should be a simple name (like DNASequence). Having it as it is now asks for troubles (as you have just described and witnessed). I am not that worried about this particular case of cleaning (okay: Dashboard's users, plese forget my reminder and use the button 'reload' and not 'update' :-)) but about that such situation can happen again. I am not a particular database person but I can imagine a script that will get as an input changed primary key and will go to other tables automatically and changed the references there. This seems (to me, as a non-db-expert) like a usual database maintainance task. Actually, it would be good if my service gets a new LSID just because some underlying data type - this service is using - changed. > I guess *technically*, since our LSIDs do not resolve by getData, only > by getMetadata, we haven't really broken the LSID specification by not > updating the version number in this case - we've broken it "in spirit", > but not "in practice". > I am not sure about this conclusion. We do not resolve our LSID's using getData, that's true. But we do not do it because we already have an API for the same functionality (the API returning definitions from the registry). But still our LSID represents a "chunk of bytes" - and if this chunk (even though not resolvable by getData) changes, its LSID should be changed, as well. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Thu Jul 6 16:56:12 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 17:56:12 +0100 (BST) Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: <1152203793.31293.38.camel@bioinfo.icapture.ubc.ca> Message-ID: > The reason it is not allowed is that service instances use the LSID of > their input/output objects as the primary key in the database > But why it is like that? The simple name of a data type could be as good as its LSID - of course unless you consider the version in LSID. I think that the primary key could be either an LSID - but in such case the update of all connected entities must happen, or it should be a simple name (like DNASequence). Having it as it is now asks for troubles (as you have just described and witnessed). I am not that worried about this particular case of cleaning (okay: Dashboard's users, plese forget my reminder and use the button 'reload' and not 'update' :-)) but about that such situation can happen again. I am not a particular database person but I can imagine a script that will get as an input changed primary key and will go to other tables automatically and changed the references there. This seems (to me, as a non-db-expert) like a usual database maintainance task. Actually, it would be good if my service gets a new LSID just because some underlying data type - this service is using - changed. > I guess *technically*, since our LSIDs do not resolve by getData, only > by getMetadata, we haven't really broken the LSID specification by not > updating the version number in this case - we've broken it "in spirit", > but not "in practice". > I am not sure about this conclusion. We do not resolve our LSID's using getData, that's true. But we do not do it because we already have an API for the same functionality (the API returning definitions from the registry). But still our LSID represents a "chunk of bytes" - and if this chunk (even though not resolvable by getData) changes, its LSID should be changed, as well. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jul 6 17:14:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 10:14:53 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152206093.31603.2.camel@bioinfo.icapture.ubc.ca> On Thu, 2006-07-06 at 17:56 +0100, Martin Senger wrote: > But why it is like that? > The simple name of a data type could be as > good as its LSID - of course unless you consider the version in LSID. I > think that the primary key could be either an LSID - but in such case the > update of all connected entities must happen, or it should be a simple > name (like DNASequence). Having it as it is now asks for troubles (as you > have just described and witnessed). The object Name could equally well be used as the primary key, you're right. The API does not allow editing of an object definition if that object is being used by a service, or as a parent or hasa component of another object, so effectively the LSID for an object should never change in any case that affects service providers. It would only change (i.e. the object definition could only change) if no services were using it. As such, the object Name and the object LSID are equally "robust" as identifiers in the database. > I am not that worried about this particular case of cleaning (okay: > Dashboard's users, plese forget my reminder and use the button 'reload' > and not 'update' :-)) but about that such situation can happen again. I am > not a particular database person but I can imagine a script that will get > as an input changed primary key and will go to other tables automatically > and changed the references there. That script could be written; however this kind of editing isn't allowed in the API, so I've never taken the time to write it. > This seems (to me, as a non-db-expert) > like a usual database maintainance task. It is. It's just that we don't touch the database itself often enough to have written the kinds of support scripts we need for this detail of editing. > Actually, it would be good if my service gets a new LSID just because > some underlying data type - this service is using - changed. I thought this would horrify you! :-) The API does not allow this to happen because if I re-define an object that you are using I may (probably will) break your service. Even if I notify you that the definition has changed, and update the LSID of your service, it is still a destructive thing to do because I can't automatically update your code to compensate for this change (in fact, it may not be possible to compensate for the change if the object has been dramatically modified). > > I guess *technically*, since our LSIDs do not resolve by getData, only > > by getMetadata, we haven't really broken the LSID specification by not > > updating the version number in this case - we've broken it "in spirit", > > but not "in practice". > > > I am not sure about this conclusion. We do not resolve our LSID's using > getData, that's true. But we do not do it because we already have an API > for the same functionality (the API returning definitions from the > registry). But still our LSID represents a "chunk of bytes" - and if this > chunk (even though not resolvable by getData) changes, its LSID should be > changed, as well. I agree 100%... which is why I say we have broken the LSID spec "in spirit" :-) I'm certainly not saying that it is something to be proud of... but in the absence of DB maintenance scripts, it is just not practical (or should I say, it is more dangerous given how much I hate touching the database by hand) to do "the right thing" this time. M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Thu Jul 6 18:29:01 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 6 Jul 2006 19:29:01 +0100 (BST) Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: <1152206093.31603.2.camel@bioinfo.icapture.ubc.ca> Message-ID: > > Actually, it would be good if my service gets a new LSID just because > > some underlying data type - this service is using - changed. > > I thought this would horrify you! :-) > Well, not really. I am not asking to have this ability in the API, of course not. That definitely would horrify me. But when cases like today - a need for manual correction of database entries - occur then I would not mind to get also new LSIDs for everything involved (together with an email annoucement what happenned and why - as you did). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Thu Jul 6 18:39:07 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 11:39:07 -0700 Subject: [MOBY-dev] [moby] Re: v.v. the Object Ontology curation In-Reply-To: References: Message-ID: <1152211147.31807.10.camel@bioinfo.icapture.ubc.ca> Once I get this next manuscript submitted I'll take some time to write a few database maintenance scripts like this. I'd feel safer doing it using a script anyway... M On Thu, 2006-07-06 at 19:29 +0100, Martin Senger wrote: > > > Actually, it would be good if my service gets a new LSID just because > > > some underlying data type - this service is using - changed. > > > > I thought this would horrify you! :-) > > > Well, not really. I am not asking to have this ability in the API, of > course not. That definitely would horrify me. But when cases like today - > a need for manual correction of database entries - occur then I would > not mind to get also new LSIDs for everything involved (together with an > email annoucement what happenned and why - as you did). > > Cheers, > Martin > -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jul 6 18:51:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 11:51:25 -0700 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] Message-ID: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- An embedded message was scrubbed... From: "Byrne Reese" Subject: [personal] [soaplite] SOAP::Lite 0.68 Released Date: Thu, 06 Jul 2006 18:34:48 -0000 Size: 3062 URL: From Pieter.Neerincx at wur.nl Thu Jul 6 20:29:31 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 6 Jul 2006 22:29:31 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark et al., I'll give it a try tomorrow. As long as it doesn't introduce any new peculiarities I can check pretty fast if the previous problems still persist or not. In the mean time: did anyone test the patches for the BioMOBY Perl modules I send to the list some time ago? I'm especially interested from people who ran them on a system with S::L 0.60... Cheers, Pi On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > Heads-up! > > I wonder if this will solve or worsen the problems we've been having > with SOAP::Lite 0.67?? > > Is anyone in a position to try this new release and evaluate it? My > plate is full for the next couple of weeks... > > M > > > > > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > From: "Byrne Reese" > Date: 06 July 2006 20:34:48 GMT+02:00 > To: soaplite at yahoogroups.com > Subject: [personal] [soaplite] SOAP::Lite 0.68 Released > > > I have released a new version of SOAP::Lite. It is available on > sourceforge now, or on CPAN in a couple of hours. The new version is > 0.68 and includes a number of fixes that make working with WSDL less > error prone. > > What motivated the fixes is working with Google's APIs (specifically > the AdWords API). So I have confirmed that that works now. > > Please let me know if you experience any problems so that I can patch > it immediately. > > Byrne Reese > Lead Developer, SOAP::Lite > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Pieter.Neerincx at wur.nl Thu Jul 6 20:29:31 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 6 Jul 2006 22:29:31 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark et al., I'll give it a try tomorrow. As long as it doesn't introduce any new peculiarities I can check pretty fast if the previous problems still persist or not. In the mean time: did anyone test the patches for the BioMOBY Perl modules I send to the list some time ago? I'm especially interested from people who ran them on a system with S::L 0.60... Cheers, Pi On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > Heads-up! > > I wonder if this will solve or worsen the problems we've been having > with SOAP::Lite 0.67?? > > Is anyone in a position to try this new release and evaluate it? My > plate is full for the next couple of weeks... > > M > > > > > -- > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > From: "Byrne Reese" > Date: 06 July 2006 20:34:48 GMT+02:00 > To: soaplite at yahoogroups.com > Subject: [personal] [soaplite] SOAP::Lite 0.68 Released > > > I have released a new version of SOAP::Lite. It is available on > sourceforge now, or on CPAN in a couple of hours. The new version is > 0.68 and includes a number of fixes that make working with WSDL less > error prone. > > What motivated the fixes is working with Google's APIs (specifically > the AdWords API). So I have confirmed that that works now. > > Please let me know if you experience any problems so that I can patch > it immediately. > > Byrne Reese > Lead Developer, SOAP::Lite > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 markw at illuminae.com Thu Jul 6 22:54:23 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 06 Jul 2006 15:54:23 -0700 Subject: [MOBY-dev] a bit more hand-editing of the Object ontology Message-ID: I've also done a bit of hand-editing of the Blast report objects. There's a nice node "Sequence_alignment_report" that was starting to get populated with things like FASTA and ClustalW. I've taken the NCBI and WU blast objects and moved them as children of that node. Again, this will not affect anyone's services who use those objects, since the only links affected are ISA (thus no change in object structure), but I wanted to give everyone a heads-up that I did it. Please scream at me if you are upset about this. M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From gordonp at ucalgary.ca Fri Jul 7 04:23:02 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 06 Jul 2006 22:23:02 -0600 Subject: [MOBY-dev] Code updates in jMOBY Message-ID: <44ADE1A6.4040608@ucalgary.ca> Hi all, I've finally had a chance to get around to committing changes to the jMOBY CVS. This includes updates to the org.biomoby.shared.data package. Please check it out and let me know what you think. I did a "ant clean" then a "build.sh" and everything seemed fine, but please let me know if jMOBY does something funny. I'm using Java 1.5 features such as Generics and autoboxing. As well, I have added new documentation introducing Seahawk, a MOBY GUI client with tabbed browsing. Please check it out and let me know if it works well for you (I know JAX-T on the Mac has problems, and SCUFL export doesn't work unless you're using it from within Bluejay for the moment). Follow the links on the jMOBY Web page (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/). Mark, maybe you can add this to the MOBY Clients section of the main Web site? Cheers, Paul From phillip.lord at newcastle.ac.uk Fri Jul 7 10:43:19 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 07 Jul 2006 11:43:19 +0100 Subject: [MOBY-dev] Request for good behaviour In-Reply-To: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> (Mark Wilkinson's message of "Thu, 06 Jul 2006 09:24:46 -0700") References: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark Never thought I would see the day, where you asked other people for good behaviour! You might be interested in this paper here. They define quality metrics for ontology definitions. They look quite interesting. Essentially their metrics pick up two ontological sins: circularlity and unintelligability. http://www.biomedcentral.com/1471-2105/7/212 >>>>> "Mark" == Mark Wilkinson writes: Mark> As I was poking around the Object ontology this morning I Mark> noticed some things that made me "cry". In particular, the Mark> way some objects are being defined is... well... not very Mark> helpful! Mark> The best example is Mark> Object Name: "TC" Description: "TC" This one would fall on the grounds that it's circular -- too many (i.e all) the words in the name occur in the description, and on the grounds that it's unintelligable (i.e none of the words in the description are in anyway meaningful). Mark> Another example Mark> Object Name: AvailableMaterial Description: Object containing Mark> information about available material This one is circular and has too many stop words: information, object, about and containing are always a little suspect in an ontology. Mark> I am not sure that, given these descriptions, either of these Mark> Objects can be used by anyone other than their original Mark> author, which kind of defeats the purpose of having an Object Mark> ontology :-) Mark> The *king* of good object descriptions has got to be Martin Mark> Senger, and I think that some of mine are pretty good too... Mark> so here are two examples that show how I think it should be Mark> done: All hail, Martin Senger? King of documentation. Cheers Phil From phillip.lord at newcastle.ac.uk Fri Jul 7 10:43:19 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 07 Jul 2006 11:43:19 +0100 Subject: [MOBY-dev] Request for good behaviour In-Reply-To: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> (Mark Wilkinson's message of "Thu, 06 Jul 2006 09:24:46 -0700") References: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark Never thought I would see the day, where you asked other people for good behaviour! You might be interested in this paper here. They define quality metrics for ontology definitions. They look quite interesting. Essentially their metrics pick up two ontological sins: circularlity and unintelligability. http://www.biomedcentral.com/1471-2105/7/212 >>>>> "Mark" == Mark Wilkinson writes: Mark> As I was poking around the Object ontology this morning I Mark> noticed some things that made me "cry". In particular, the Mark> way some objects are being defined is... well... not very Mark> helpful! Mark> The best example is Mark> Object Name: "TC" Description: "TC" This one would fall on the grounds that it's circular -- too many (i.e all) the words in the name occur in the description, and on the grounds that it's unintelligable (i.e none of the words in the description are in anyway meaningful). Mark> Another example Mark> Object Name: AvailableMaterial Description: Object containing Mark> information about available material This one is circular and has too many stop words: information, object, about and containing are always a little suspect in an ontology. Mark> I am not sure that, given these descriptions, either of these Mark> Objects can be used by anyone other than their original Mark> author, which kind of defeats the purpose of having an Object Mark> ontology :-) Mark> The *king* of good object descriptions has got to be Martin Mark> Senger, and I think that some of mine are pretty good too... Mark> so here are two examples that show how I think it should be Mark> done: All hail, Martin Senger? King of documentation. Cheers Phil From senger at ebi.ac.uk Fri Jul 7 11:37:54 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 12:37:54 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44ADE1A6.4040608@ucalgary.ca> Message-ID: > "ant clean" then a "build.sh" and everything seemed fine, but please let > me know if jMOBY does something funny. > Javac compiles it fine. But for year I have been using jikes because of its speed and accuracy regarding the java spec. And this does not work anymore now. I am using jikes 1.22 and it seems to be the latest version. This is annoying, but not critical. At least what I see so far. What is bothering me more is that you remove things that were working fine and that my code relies on. For example: I have looked into the reported errorrs and in the CVS what had been changed. I took an example, file CentralImpl.java. I wonder why you removed things there, such as AxisUtils.formatFault? Now, BTW, it gives a semantic error when compiled with jikes: [javac] Found 1 semantic error compiling "/home/senger/moby-live/Java/src/main/org/biomoby/client/CentralImpl.java": [javac] 222. (endpoint.toString()+(call == null ? "" : call.getOperationName()), e); [javac] ^--------------------------^ [javac] *** Semantic Error: In the conditional, the type of the true sub-expression, "java.lang.String", is not compatible with the type of the false sub-expression, "javax.xml.namespace.QName". Could we work on it soon please? Next week, I am giving a detailed tutorial on Moby and I would prefer to have things working as they did before. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Fri Jul 7 12:01:40 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 13:01:40 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44ADE1A6.4040608@ucalgary.ca> Message-ID: Paul, One more remark regarding jikes: Perhaps I am not using correct arguments for jikes (like -source 1.5). But it would need some time to investigate what arguments to use, and how to put them into jMoby build.xml. The time I am reluctant to spend just now. Perhaps you can consider to investigate - after all these were your changes :-) Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Fri Jul 7 14:31:54 2006 From: d.haase at gsf.de (Dirk Haase) Date: Fri, 7 Jul 2006 16:31:54 +0200 Subject: [MOBY-dev] a bit more hand-editing of the Object ontology In-Reply-To: References: Message-ID: <200607071631.54777.d.haase@gsf.de> On Friday 07 July 2006 00:54, Mark Wilkinson wrote: > I've also done a bit of hand-editing of the Blast report objects. There's > a nice node "Sequence_alignment_report" that was starting to get populated > with things like FASTA and ClustalW. I've taken the NCBI and WU blast > objects and moved them as children of that node. Maybe I'm a bit picky, but I want to remind you that BLAST and FASTA are not sequence alignment algorithms but sequence database search tools. What if I choose to display no alignments at all in my BLAST report? Regards, dirk From markw at illuminae.com Fri Jul 7 15:56:50 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Jul 2006 08:56:50 -0700 Subject: [MOBY-dev] [moby] Re: a bit more hand-editing of the Object ontology In-Reply-To: <200607071631.54777.d.haase@gsf.de> References: <200607071631.54777.d.haase@gsf.de> Message-ID: <1152287810.1577.12.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-07 at 16:31 +0200, Dirk Haase wrote: > Maybe I'm a bit picky, but I want to remind you that BLAST and FASTA are not > sequence alignment algorithms but sequence database search tools. What if I > choose to display no alignments at all in my BLAST report? Good point... Darn single-parenting! Alternate proposals? M > Regards, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Fri Jul 7 15:58:11 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Jul 2006 08:58:11 -0700 Subject: [MOBY-dev] [moby] Re: Request for good behaviour In-Reply-To: References: <1152203086.31293.24.camel@bioinfo.icapture.ubc.ca> Message-ID: <1152287892.1577.14.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-07 at 11:43 +0100, Phillip Lord wrote: > Mark > Never thought I would see the day, where you asked other people for > good behaviour! Only academically... ;-) M -- -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From enrique.deandres at pcm.uam.es Fri Jul 7 14:03:57 2006 From: enrique.deandres at pcm.uam.es (Enrique de Andres Saiz) Date: Fri, 07 Jul 2006 16:03:57 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: <44AE69CD.5030605@pcm.uam.es> Hi Pieter, I have tried your patches a little bit and I have found the following... When I use SOAP::Lite both v0.60 or v0.67, and I invoke MOBY::Client::Central registerObjectClass, I get the following error: Can't coerce array into hash at /usr/local/share/perl/5.8.4/MOBY/Client/Central.pm line 423. Everything else looks OK. Kind regards, Enrique. Pieter Neerincx wrote: > Hi Mark et al., > > I'll give it a try tomorrow. As long as it doesn't introduce any new > peculiarities I can check pretty fast if the previous problems still > persist or not. In the mean time: did anyone test the patches for the > BioMOBY Perl modules I send to the list some time ago? I'm especially > interested from people who ran them on a system with S::L 0.60... > > Cheers, > > Pi > > On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > >> Heads-up! >> >> I wonder if this will solve or worsen the problems we've been having >> with SOAP::Lite 0.67?? >> >> Is anyone in a position to try this new release and evaluate it? My >> plate is full for the next couple of weeks... >> >> M >> >> >> >> >> -- >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> From: "Byrne Reese" >> Date: 06 July 2006 20:34:48 GMT+02:00 >> To: soaplite at yahoogroups.com >> Subject: [personal] [soaplite] SOAP::Lite 0.68 Released >> >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new version is >> 0.68 and includes a number of fixes that make working with WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > -- Enrique de Andr?s Saiz Unidad de Bioinform?tica Parque Cient?fico de Madrid Ctra. de Colmenar, Km. 15 Campus Universidad Aut?noma de Madrid, Cantoblanco - Pabell?n C 28049 Madrid Phone: +34 91 497 3448 Fax: +34 91 497 3471 E-mail: enrique.deandres at pcm.uam.es From enrique.deandres at pcm.uam.es Fri Jul 7 14:03:57 2006 From: enrique.deandres at pcm.uam.es (Enrique de Andres Saiz) Date: Fri, 07 Jul 2006 16:03:57 +0200 Subject: [MOBY-dev] [Fwd: [soaplite] SOAP::Lite 0.68 Released] In-Reply-To: References: <1152211885.31807.21.camel@bioinfo.icapture.ubc.ca> Message-ID: <44AE69CD.5030605@pcm.uam.es> Hi Pieter, I have tried your patches a little bit and I have found the following... When I use SOAP::Lite both v0.60 or v0.67, and I invoke MOBY::Client::Central registerObjectClass, I get the following error: Can't coerce array into hash at /usr/local/share/perl/5.8.4/MOBY/Client/Central.pm line 423. Everything else looks OK. Kind regards, Enrique. Pieter Neerincx wrote: > Hi Mark et al., > > I'll give it a try tomorrow. As long as it doesn't introduce any new > peculiarities I can check pretty fast if the previous problems still > persist or not. In the mean time: did anyone test the patches for the > BioMOBY Perl modules I send to the list some time ago? I'm especially > interested from people who ran them on a system with S::L 0.60... > > Cheers, > > Pi > > On 06 Jul 2006, at 20:51, Mark Wilkinson wrote: > >> Heads-up! >> >> I wonder if this will solve or worsen the problems we've been having >> with SOAP::Lite 0.67?? >> >> Is anyone in a position to try this new release and evaluate it? My >> plate is full for the next couple of weeks... >> >> M >> >> >> >> >> -- >> >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "For most of this century we have viewed communications as a conduit, >> a pipe between physical locations on the planet. >> What's happened now is that the conduit has become so big and >> interesting >> that communication has become more than a conduit, >> it has become a destination in its own right..." >> >> Paul Saffo - Director, Institute for the Future >> >> From: "Byrne Reese" >> Date: 06 July 2006 20:34:48 GMT+02:00 >> To: soaplite at yahoogroups.com >> Subject: [personal] [soaplite] SOAP::Lite 0.68 Released >> >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new version is >> 0.68 and includes a number of fixes that make working with WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > -- Enrique de Andr?s Saiz Unidad de Bioinform?tica Parque Cient?fico de Madrid Ctra. de Colmenar, Km. 15 Campus Universidad Aut?noma de Madrid, Cantoblanco - Pabell?n C 28049 Madrid Phone: +34 91 497 3448 Fax: +34 91 497 3471 E-mail: enrique.deandres at pcm.uam.es From gordonp at ucalgary.ca Fri Jul 7 18:28:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 12:28:50 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: References: Message-ID: <44AEA7E2.8030708@ucalgary.ca> Hi Martin, Sure, I can have a look at why jikes craps out... BTW, yes, I did make some minor code changes in classes directly in org.biomoby.shared and org.biomoby.client, primarily because of package creep. The functionality should not really be affected, if it is, let me know. For example the formatFault you mentioned is replaced by 3 lines that do essentially the same thing. By package creep, I mean that in order to compile core MOBY classes into my non-MOBY cvs projects, I don't want to have to include lots of extra jars (I'm writing applets, which have severe memory restrictions). For example, I moved JDOM specific code from Utils to JDOMUtils, and changed all references to those methods (very few actually) in CVS. Same thing with the tulsoft libraries. I think it's a generally good idea to limit the number external dependencies in the core shared classes, no? Cheers, Paul > . Paul, > One more remark regarding jikes: Perhaps I am not using correct > arguments for jikes (like -source 1.5). But it would need some time to > investigate what arguments to use, and how to put them into jMoby > build.xml. The time I am reluctant to spend just now. Perhaps you can > consider to investigate - after all these were your changes :-) > > Thanks, > Martin > > From gordonp at ucalgary.ca Fri Jul 7 19:34:31 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 13:34:31 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEA7E2.8030708@ucalgary.ca> References: <44AEA7E2.8030708@ucalgary.ca> Message-ID: <44AEB747.3000401@ucalgary.ca> As far as I can see, jikes does not support Java 1.5 language features yet. And there hasn't been a new release of jikes for almost 2 years now. http://sourceforge.net/tracker/index.php?func=detail&aid=1210781&group_id=128803&atid=712760 You can compile with the Java 1.5 runtime library, but you cannot compile features introduced in Java1.5 such as Generics, autoboxing, enumerated types, enhanced for loops, etc... Looks like you'll have to stick to javac for now. It takes 22 seconds for me to compile everything. Cheers, Paul > Hi Martin, > > Sure, I can have a look at why jikes craps out... > > BTW, yes, I did make some minor code changes in classes directly in > org.biomoby.shared and org.biomoby.client, primarily because of package > creep. The functionality should not really be affected, if it is, let > me know. For example the formatFault you mentioned is replaced by 3 > lines that do essentially the same thing. > > By package creep, I mean that in order to compile core MOBY classes into > my non-MOBY cvs projects, I don't want to have to include lots of extra > jars (I'm writing applets, which have severe memory restrictions). For > example, I moved JDOM specific code from Utils to JDOMUtils, and changed > all references to those methods (very few actually) in CVS. Same thing > with the tulsoft libraries. I think it's a generally good idea to limit > the number external dependencies in the core shared classes, no? > > Cheers, > > Paul > >> . Paul, >> One more remark regarding jikes: Perhaps I am not using correct >> arguments for jikes (like -source 1.5). But it would need some time to >> investigate what arguments to use, and how to put them into jMoby >> build.xml. The time I am reluctant to spend just now. Perhaps you can >> consider to investigate - after all these were your changes :-) >> >> Thanks, >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From senger at ebi.ac.uk Fri Jul 7 19:56:08 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 20:56:08 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEB747.3000401@ucalgary.ca> Message-ID: > As far as I can see, jikes does not support Java 1.5 language features > yet. And there hasn't been a new release of jikes for almost 2 years now. > > You can compile with the Java 1.5 runtime library, but you cannot > compile features introduced in Java1.5 such as Generics, autoboxing, > enumerated types, enhanced for loops, etc... Looks like you'll have to > stick to javac for now. It takes 22 seconds for me to compile everything. > Sorry, but this is hardly acceptible. I think I prefer to roll bcak. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From senger at ebi.ac.uk Fri Jul 7 20:02:34 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 21:02:34 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEA7E2.8030708@ucalgary.ca> Message-ID: > By package creep, I mean that in order to compile core MOBY classes into > my non-MOBY cvs projects, I don't want to have to include lots of extra > jars (I'm writing applets, which have severe memory restrictions). For > example, I moved JDOM specific code from Utils to JDOMUtils, and changed > all references to those methods (very few actually) in CVS. > Paul, you did changes that you do not know about consequences. For example changes in packages affect the number of jar files that are to be deployed to the Tomcat. But you have not changed this in build.xml files. > The functionality should not really be affected, if it is, let me > know. For example the formatFault you mentioned is replaced by 3 > lines that do essentially the same thing. > Yes, now it is 3 lines of code but they are well separated and can be extended later for more sophisticated code. I would like to have them back please. I am now busy to finish other moby project (perl one) I am working on because I am leaving for a meeting soon. So I cannot look in details what you did - but I really ask you to re-consider your changes. I feel greatly disturbed now. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Jul 7 22:03:20 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 16:03:20 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: References: Message-ID: <44AEDA28.4060806@ucalgary.ca> Hi Martin, >> By package creep, I mean that in order to compile core MOBY classes into >> my non-MOBY cvs projects, I don't want to have to include lots of extra >> jars (I'm writing applets, which have severe memory restrictions). For >> example, I moved JDOM specific code from Utils to JDOMUtils, and changed >> all references to those methods (very few actually) in CVS. >> >> > Paul, you did changes that you do not know about consequences. For > example changes in packages affect the number of jar files that are to be > deployed to the Tomcat. But you have not changed this in build.xml files. > There may be some confusion: I did not remove or add any packages, I simply moved code (4 methods) to a new class org.biomoby.shared.parser JDOMUtils. For example, this cleaned org.biomoby.shared.data of the JDOM dependency you introduced in MobyProvisionInfo. None of these changes involved the subpackages dashboard, rdf, registry or ui, so I don't think any changes to build.xml need to be made. >> The functionality should not really be affected, if it is, let me >> know. For example the formatFault you mentioned is replaced by 3 >> lines that do essentially the same thing. >> >> > Yes, now it is 3 lines of code but they are well separated and can be > extended later for more sophisticated code. I would like to have them > back please. > I guess this becomes a philosophical question for the project as whole. Do you want to force anyone who want to use MOBY in their Java own program to bundle all of JAR files in lib with them in their deployments (e.g. otherwise I need know that I must have alltools2.jar in my classpath to use CentralImpl)? I am coming at this (as you've asked me before) from the perspective of someone not using jMOBY as their primary CVS tree but rather as a library to use. I carefully selected just a few parts (less than a dozen classes) to remove some small library dependencies from so that Seahawk (~2.7MB total) doesn't need to import a lot of external code to compile and run. Please note, I have not touched the dashboard, datatype, rdf, registry, ui, and not even most of the classes in shared. There is really just a core set of common classes I'd like to keep clean, and hopefully others will too, under org/biomoby: ./client/CentralCachedCallsImpl.java ./client/CentralImpl.java ./client/rdf/vocabulary/DC_PROTEGE.java ./client/rdf/vocabulary/FetaVocabulary.java ./client/rdf/vocabulary/MobyResources.java ./client/rdf/vocabulary/Predicates.java ./client/rdf/vocabulary/ServiceDescriptionPredicates.java ./client/rdf/vocabulary/XMLTypes.java ./shared/*.java ./shared/data/*.java ./shared/extended/DataTypeParser.java ./shared/extended/NamespaceParser.java ./shared/extended/ServiceInstanceParser.java ./shared/extended/ServiceTypeParser.java ./shared/parser/MobyTags.java ./shared/schema/MElement.java ./shared/schema/MElementHashtable.java ./shared/schema/PrimitiveVector.java ./shared/schema/RdfParser.java > I am now busy to finish other moby project (perl one) I am working on > because I am leaving for a meeting soon. So I cannot look in details what > you did - but I really ask you to re-consider your changes. I feel greatly > disturbed now. > Besides the 4 methods moved to JDOMUtils, there actually are few changes. There are less than 20 lines of code affected, all related to formatting utilities and empty string checks. I did not touch anything with fundamental functionality. I don't think you need to be "greatly disturbed" :-) Cool runnings, Paul From senger at ebi.ac.uk Fri Jul 7 22:12:49 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 23:12:49 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEDA28.4060806@ucalgary.ca> Message-ID: Paul, Thanks for assurance... I still do not have time to confirm or reject your explanation. I will do it later ad let you know.I m sure we will find a solution (if there is a problem). However, you mentioned several time that one of your concern is JDOM. Mine too, actually. I know that we (in jMoby) are using - unfortunately - both: DOM and JDOM. I prefer JDOM. Is there an easy way to use just one - jDOM? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Jul 7 22:34:47 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 07 Jul 2006 16:34:47 -0600 Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: References: Message-ID: <44AEE187.4060101@ucalgary.ca> Hi, All of my code is DOM based, primarily because I am using many tools that sit on top of the DOM, such as XPath evaluators, XSLT processors, etc. Also, the DOM implementation comes free with Java 1.5 (i.e. the JRE includes DOM compliant parsers, translators, etc.), so there are no external dependencies when using the JAXP and JAXT APIs. While there is nothing wrong with using jDOM, I'm just reluctant to force people to use it over the built-in Java methods. If everyone else (hello?) definitely wants to use jDOM though, we can make a plan to migrate the code base that way. Cheers, Paul > Paul, > Thanks for assurance... I still do not have time to confirm or reject > your explanation. I will do it later ad let you know.I m sure we will find > a solution (if there is a problem). > However, you mentioned several time that one of your concern is JDOM. > Mine too, actually. I know that we (in jMoby) are using - unfortunately - > both: DOM and JDOM. I prefer JDOM. Is there an easy way to use just one - > jDOM? > > Martin > > From senger at ebi.ac.uk Fri Jul 7 22:37:52 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 7 Jul 2006 23:37:52 +0100 (BST) Subject: [MOBY-dev] Code updates in jMOBY In-Reply-To: <44AEE187.4060101@ucalgary.ca> Message-ID: > All of my code is DOM based > Okay, okay... I was not sure who is using it, me or you. So let's have both, as so far. > If everyone else (hello?) definitely wants to use jDOM though, we can > make a plan to migrate the code base that way. > It would be nice but probably a lot of work I guess. Not my cup of tea :-) Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Jul 7 23:00:44 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 07 Jul 2006 16:00:44 -0700 Subject: [MOBY-dev] Fwd: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released In-Reply-To: <44AEB128.3090201@majordojo.com> References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> Message-ID: Another release of SOAP::Lite coming soon... M ------- Forwarded message ------- From: "Byrne Reese" To: "Chris McMahon" Cc: soaplite at yahoogroups.com Subject: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released Date: Fri, 07 Jul 2006 12:08:24 -0700 Yes. Apparently I forgot to check one file in. Damn it. So what worked for me in development didn't get fully released. Please stand-by. An update is forthcoming - perhaps by Monday. Chris McMahon wrote: > > > Hi... > This is significantly better than 0.67. However, I'm getting an > error vs. the WSDL I need to read: > > Type 'ArrayOfstring' can't be found in a schema class 'SOAP::Serializer' > > Any ideas on fixing this? > > On 7/6/06, *Byrne Reese* > wrote: > > I have released a new version of SOAP::Lite. It is available on > sourceforge now, or on CPAN in a couple of hours. The new version is > 0.68 and includes a number of fixes that make working with WSDL less > error prone. > > What motivated the fixes is working with Google's APIs (specifically > the AdWords API). So I have confirmed that that works now. > > Please let me know if you experience any problems so that I can patch > it immediately. > > Byrne Reese > Lead Developer, SOAP::Lite > > > > -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From edward.kawas at gmail.com Thu Jul 13 18:35:23 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 13 Jul 2006 11:35:23 -0700 Subject: [MOBY-dev] RDF Message-ID: <005501c6a6ab$1c3b8900$6a00a8c0@notebook> FYI, The service instance RDF has been modified once again and should now be stable. For those that use the RDF (and java), I have updated the parsers at org.biomoby.shared.extended.*. Eddie From spies at ipk-gatersleben.de Wed Jul 19 16:08:29 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Wed, 19 Jul 2006 18:08:29 +0200 Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: <005501c6a6ab$1c3b8900$6a00a8c0@notebook> References: <005501c6a6ab$1c3b8900$6a00a8c0@notebook> Message-ID: <44BE58FD.3020408@ipk-gatersleben.de> Hi, I have some problems with deploying a simple jMoby service to an oracle application server. With tomcat it works fine, but if I deploy the same service with the same libraries to oracle I get an exception (java.lang.StackOverflowError). Have anybody of you experiences with other runtimes than tomcat??? Thanks for help. Karl From senger at ebi.ac.uk Wed Jul 19 16:40:23 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 19 Jul 2006 17:40:23 +0100 (BST) Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: <44BE58FD.3020408@ipk-gatersleben.de> Message-ID: > Have anybody of you experiences with other runtimes than tomcat??? > No, I have not. But I am very interested to learn how/when you are going to solve this problem. It may be worth to mention it also in the jMoby docs, for future reference. Are you using jMoby services generated by MoSeS? In which moment the stack overflow happens? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From spies at ipk-gatersleben.de Thu Jul 20 09:18:44 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 11:18:44 +0200 Subject: [MOBY-dev] jMoby Java 1.4 Message-ID: <44BF4A74.7090800@ipk-gatersleben.de> Hi, I know the change to Java 1.5 compiler has been discussed, but now I need a Java 1.4 compatible version. Is there an CVS arch or something like that? Or which date is the last, that contain only Java 1.4 compatible stuff? Sorry of that late entrance in this discussion. Karl From gordonp at ucalgary.ca Thu Jul 20 14:00:43 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 20 Jul 2006 08:00:43 -0600 Subject: [MOBY-dev] jMoby Java 1.4 In-Reply-To: <44BF4A74.7090800@ipk-gatersleben.de> References: <44BF4A74.7090800@ipk-gatersleben.de> Message-ID: <44BF8C8B.5080505@ucalgary.ca> Hi Karl, The switch over was June 30th. You can do a CVS checkout with that date stamp... > Hi, > > I know the change to Java 1.5 compiler has been discussed, but now I > need a Java 1.4 compatible version. Is there an CVS arch or something > like that? Or which date is the last, that contain only Java 1.4 > compatible stuff? > > Sorry of that late entrance in this discussion. > > Karl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From spies at ipk-gatersleben.de Thu Jul 20 15:16:52 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 17:16:52 +0200 Subject: [MOBY-dev] jMoby Java 1.4 In-Reply-To: <44BF8C8B.5080505@ucalgary.ca> References: <44BF4A74.7090800@ipk-gatersleben.de> <44BF8C8B.5080505@ucalgary.ca> Message-ID: <44BF9E64.9040401@ipk-gatersleben.de> Thanks, I will do so. It is possible to make such an arch in the CVS tree? May be it is useful for other peoples with the same problem? Karl From spies at ipk-gatersleben.de Thu Jul 20 15:19:17 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 17:19:17 +0200 Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: References: Message-ID: <44BF9EF5.7060503@ipk-gatersleben.de> Hi, i solved the problem and yes, first I used moses skeleton generator. But now I am using a recycled BaseService and implement the rest by myself. Why I am doing this? The reason is, that oracle is very strict with there design of web service. You are not allowed to use any abstract method in your implementation classes. So the public void processIt (MobyJob request, MobyJob response,MobyPackage outputContext) throws MobyException {} will crash the system. An other requirement is that every oracle based web service must have an interface which extends from java.rmi.Remote and very method declaration must throw a java.rmi.RemoteException. The solution was to take inspiration from the BaseService and the moses generator and implement my own BaseService(change the abtract process method). After that I copied code from the generated skeleton and put this into my implementation class. The last thing I had done was to add some dummy throws. JOB IS DONE! I know this is painful and neither handy nor stylish. But it works. The reason for the StackOverFlowError was the xsd "anyType" data type. I used the tools from oracle to build an deployable archive from classes and the generated WSDL use "anyType" to represent the Java data type "Object". This crashed the oracle AS internal XML parser. I experimented a little bit with tomcat and oracle. I found that the used xerxces parser from biomoby don't like this data type too. But the xerces parser announced an error not a StackOverFlow :-) . Now my services are running under both runtimes. Karl From edward.kawas at gmail.com Thu Jul 20 14:34:32 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 20 Jul 2006 07:34:32 -0700 Subject: [MOBY-dev] jMoby Java 1.4 In-Reply-To: <44BF4A74.7090800@ipk-gatersleben.de> Message-ID: <004d01c6ac09$9e6e9c10$6a00a8c0@notebook> Hi Karl, If you download the latest version of Taverna, you will find in the lib directory some jars that start with jMoby*.jar. Those where compiled in 1.4. Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Karl Spies > Sent: Thursday, July 20, 2006 2:19 AM > To: Core developer announcements > Subject: [MOBY-dev] jMoby Java 1.4 > > Hi, > > I know the change to Java 1.5 compiler has been discussed, > but now I need a Java 1.4 compatible version. Is there an CVS > arch or something like that? Or which date is the last, that > contain only Java 1.4 compatible stuff? > > Sorry of that late entrance in this discussion. > > Karl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From spies at ipk-gatersleben.de Thu Jul 20 17:33:16 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 19:33:16 +0200 Subject: [MOBY-dev] jMoby core libraries Message-ID: <44BFBE5C.6020207@ipk-gatersleben.de> Hi, I tried to find out which were the core libraries to run BioMoby services, but I can't find a hint in the documentation. Can anybody help me out with that problem? I need a lightweight deployable archive for my application server. Thanks Karl From senger at ebi.ac.uk Thu Jul 20 17:50:26 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 20 Jul 2006 18:50:26 +0100 (BST) Subject: [MOBY-dev] jMoby core libraries In-Reply-To: <44BFBE5C.6020207@ipk-gatersleben.de> Message-ID: > I tried to find out which were the core libraries to run BioMoby > services > The 'core' libraries that are needed for running BioMoby services that were generated by MoSeS are those that are used when deploying biomoby services to Tomcat. They are listed in xmls/deployBuild.xml, and they are: lib/alltools2.jar lib/jdom.jar lib/commons-lang-2.1.jar and build/lib/jmoby.jar At least, this was true before the big bang done by Paul (when he moved things to Java 1.5 and from some obscure :-) reasons restructured some libraries). Since I have not had chance to try. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From spies at ipk-gatersleben.de Thu Jul 20 18:15:06 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Thu, 20 Jul 2006 20:15:06 +0200 Subject: [MOBY-dev] jMoby core libraries In-Reply-To: References: Message-ID: <44BFC82A.6050404@ipk-gatersleben.de> Hi Martin, thank you for that help. I made a little bit "try and error" :-). I found the libraries you mentioned. The tulsoft API require the xerces library. I tried other implementations for the SAXParser but it fails. So the expand the list to: alltools2.jar jdom.jar commons-lang-2.1.jar jmoby.jar xercesImpl.jar Karl From senger at ebi.ac.uk Thu Jul 20 18:38:13 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 20 Jul 2006 19:38:13 +0100 (BST) Subject: [MOBY-dev] jMoby core libraries In-Reply-To: <44BFC82A.6050404@ipk-gatersleben.de> Message-ID: > The tulsoft API require the xerces library. > Yes, that's true. I considered xerces library a default for tomcat so I forgot to mention it. Sorry... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Thu Jul 20 18:45:37 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Thu, 20 Jul 2006 12:45:37 -0600 Subject: [MOBY-dev] jMoby core libraries In-Reply-To: References: Message-ID: <44BFCF51.6090306@ucalgary.ca> None of my changes added any library dependencies. I am anti-library dependency all the way :-) > The 'core' libraries that are needed for running BioMoby services that > were generated by MoSeS are those that are used when deploying biomoby > services to Tomcat. They are listed in xmls/deployBuild.xml, and they are: > lib/alltools2.jar > lib/jdom.jar > lib/commons-lang-2.1.jar > and > build/lib/jmoby.jar > > At least, this was true before the big bang done by Paul (when he moved > things to Java 1.5 and from some obscure :-) reasons restructured some > libraries). Since I have not had chance to try. > From senger at ebi.ac.uk Thu Jul 20 22:21:37 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 20 Jul 2006 23:21:37 +0100 (BST) Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: <44BF7388.8000208@ipk-gatersleben.de> Message-ID: Thanks for details about oracle web services requirements. Interesting, and good to know. > The reason is, that oracle is very strict with there design of web > service. You are not allowed to use any abstract method in your > implementation classes. > It's a bit strange because the class that represents a moby service does not have any abstract method. The generated skeleton has, but your implementation class (that extends the skeleton and implements method processIt()) does not have. And it is the implementation class that is used to be deployed. > An other requirement is that every oracle based web service must have > an interface which extends from java.rmi.Remote and very method > declaration must throw a java.rmi.RemoteException. > Okay, good to know. So why not just to implement (actually to extend) this interface in your implementation class? I may not understand fully the concept of the Remote interface, but a brief reading of javadoc tells me that "Only those methods specified in a 'remote interface', an interface that extends java.rmi.Remote are available remotely." Which indicates that perhaps something like this could work (assuming, for example, that your service name is 'HelloOracle'): // this class is generated by MoSeS abstract class your.authority.HelloOracleSkel {...} // this clas is deployed as a web service main class class your.package.HelloOracleImpl extends your.authority.HelloOracleSkel implements HelloOracleRemote { ... } // this interface should make oracle happy interface HelloOracleRemote extends java.rmi.Remote { String HelloOracle (Object data); } > Now my services are running under both runtimes. > And that's the main thing! Perfect. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From spies at ipk-gatersleben.de Fri Jul 21 07:52:26 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Fri, 21 Jul 2006 09:52:26 +0200 Subject: [MOBY-dev] Deploy jMoby Service In-Reply-To: References: Message-ID: <44C087BA.6090603@ipk-gatersleben.de> Hi, > It's a bit strange because the class that represents a moby service > does not have any abstract method. The generated skeleton has, but your > implementation class (that extends the skeleton and implements method > processIt()) does not have. And it is the implementation class that is > used to be deployed. You are right about that the implementation class does not have any abstract method. This is my fault. I am trying to explain it again. :-) The main concept of moses service generation is to extend the org.biomoby.service.BaseService and put all needed stuff in it. The service providers only needs to overwrite the abstract process method from BaseService in there implementation class. The Oracle system don't like this. I don't know why. I think its stupid. :-( > Okay, good to know. So why not just to implement (actually to extend) > this interface in your implementation class? I may not understand fully > the concept of the Remote interface, but a brief reading of javadoc tells > me that "Only those methods specified in a 'remote interface', an > interface that extends java.rmi.Remote are available remotely." Which > indicates that perhaps something like this could work (assuming, for > example, that your service name is 'HelloOracle'): > > // this class is generated by MoSeS > abstract class your.authority.HelloOracleSkel {...} > > // this clas is deployed as a web service main class > class your.package.HelloOracleImpl > extends your.authority.HelloOracleSkel > implements HelloOracleRemote { > ... > } > > // this interface should make oracle happy > interface HelloOracleRemote > extends java.rmi.Remote { > String HelloOracle (Object data); > } > I done it exactly like you, but the HelloOracleSkel extends the BaseService and again oracle fails to execute the service. My solution was to copy the BaseService, rename it, and change the abstract method into a "normal" method. Karl From spies at ipk-gatersleben.de Fri Jul 21 07:57:45 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Fri, 21 Jul 2006 09:57:45 +0200 Subject: [MOBY-dev] jMoby core libraries In-Reply-To: <44BFCF51.6090306@ucalgary.ca> References: <44BFCF51.6090306@ucalgary.ca> Message-ID: <44C088F9.5060805@ipk-gatersleben.de> Hi, here is the complete list of libraries to deploy a BioMOBY Service to a non tomcat system. jmoby.jar commons-lang-2.1.jar commons-logging-1.0.4.jar alltools2.jar xercesImpl.jar xml-apis.jar jdom.jar biomoby-datatypes.jar axis.jar I hope it is useful for somebody else like me :-) Karl From fgibbons at hms.harvard.edu Fri Jul 21 15:48:34 2006 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 21 Jul 2006 11:48:34 -0400 Subject: [MOBY-dev] encodeException question.... Message-ID: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Hi, Been away from MOBY for a while, now I'm back, and I see that everyone's been very busy ;-) Major kudos to Mark/Pieter on his work encoding Exceptions in the Perl API, as well as cleaning up the message-parsing into an object-oriented form. So much cleaner now than in the past! I notice also that the INB group posted to the mailing list some nice-looking code to encode all the work in the RFC from last year, but I didn't see it make it into the actual code base. Am I right? It too looked pretty clean, seems like it'd make a good addition to the codebase. Regarding the docs for CommonSubs::encodeExceptions, it seems to me that the first two arguments are confused: usage: encodeException( -refElement => 'refers to the queryID of the offending input mobyData', -refQueryID => 'refers to the articleName of the offending input Simple or Collection' Surely, 'refQueryID' should contain the queryID, and not refElement, while refElement should contain the articleName. I can fix it, just wanted to check, since I've been away for a while. -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 [1]http://llama.med.harvard.edu/~fgibbons References 1. http://llama.med.harvard.edu/~fgibbons From usadel at mpimp-golm.mpg.de Fri Jul 21 16:23:07 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Fri, 21 Jul 2006 18:23:07 +0200 Subject: [MOBY-dev] encodeException question.... In-Reply-To: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Message-ID: <44C0FF6B.9040902@mpimp-golm.mpg.de> Hi Frank, as far as I am concerned just fix my documentation bug. The reason I incorporated these (methods not the bug) into CommonSubs is that there was no solution available and when I asked in the beginning of the year if somebody was working on it, nobody replied. I personally think the INB solution is cleaner and also contains all the error codes etc., but by then I already had the code checked in. As far as I know their code is not yet checked in. I think also in the OO Perl approach there seems to be some code. So there will be many ways for the same goal. Oh also if you use the CommonSubs methods please report if it actually proves useful. Cheers, Bj?rn Frank Gibbons wrote: > Hi, > Been away from MOBY for a while, now I'm back, and I see that everyone's > been very busy ;-) Major kudos to Mark/Pieter on his work encoding > Exceptions in the Perl API, as well as cleaning up the message-parsing into > an object-oriented form. So much cleaner now than in the past! > I notice also that the INB group posted to the mailing list some > nice-looking code to encode all the work in the RFC from last year, but I > didn't see it make it into the actual code base. Am I right? It too looked > pretty clean, seems like it'd make a good addition to the codebase. > Regarding the docs for CommonSubs::encodeExceptions, it seems to me that the > first two arguments are confused: > usage: > encodeException( > > -refElement => 'refers to the queryID of the offending input > mobyData', > > -refQueryID => 'refers to the articleName of the offending input > Simple or Collection' > > > Surely, 'refQueryID' should contain the queryID, and not refElement, while > refElement should contain the articleName. I can fix it, just wanted to > check, since I've been away for a while. > -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 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From usadel at mpimp-golm.mpg.de Fri Jul 21 16:23:07 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Fri, 21 Jul 2006 18:23:07 +0200 Subject: [MOBY-dev] encodeException question.... In-Reply-To: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Message-ID: <44C0FF6B.9040902@mpimp-golm.mpg.de> Hi Frank, as far as I am concerned just fix my documentation bug. The reason I incorporated these (methods not the bug) into CommonSubs is that there was no solution available and when I asked in the beginning of the year if somebody was working on it, nobody replied. I personally think the INB solution is cleaner and also contains all the error codes etc., but by then I already had the code checked in. As far as I know their code is not yet checked in. I think also in the OO Perl approach there seems to be some code. So there will be many ways for the same goal. Oh also if you use the CommonSubs methods please report if it actually proves useful. Cheers, Bj?rn Frank Gibbons wrote: > Hi, > Been away from MOBY for a while, now I'm back, and I see that everyone's > been very busy ;-) Major kudos to Mark/Pieter on his work encoding > Exceptions in the Perl API, as well as cleaning up the message-parsing into > an object-oriented form. So much cleaner now than in the past! > I notice also that the INB group posted to the mailing list some > nice-looking code to encode all the work in the RFC from last year, but I > didn't see it make it into the actual code base. Am I right? It too looked > pretty clean, seems like it'd make a good addition to the codebase. > Regarding the docs for CommonSubs::encodeExceptions, it seems to me that the > first two arguments are confused: > usage: > encodeException( > > -refElement => 'refers to the queryID of the offending input > mobyData', > > -refQueryID => 'refers to the articleName of the offending input > Simple or Collection' > > > Surely, 'refQueryID' should contain the queryID, and not refElement, while > refElement should contain the articleName. I can fix it, just wanted to > check, since I've been away for a while. > -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 [1]http://llama.med.harvard.edu/~fgibbons > > References > > 1. http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From fgibbons at hms.harvard.edu Fri Jul 21 18:08:54 2006 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Fri, 21 Jul 2006 14:08:54 -0400 Subject: [MOBY-dev] encodeException question.... In-Reply-To: <44C0FF6B.9040902@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060721140730.0123ccc8@email.med.harvard.edu> Thanks for the feedback, Bj?rn. And of course, I should have credited you with the Exception coding in CommonSubs. I'll fix the documentation, and let you know whether I encounter success or failure ;-) Thanks again. -Frank At 12:23 PM 7/21/2006, you wrote: >Hi Frank, > >as far as I am concerned just fix my documentation bug. > >The reason I incorporated these (methods not the bug) into CommonSubs is >that there was no solution available and when I asked in the beginning >of the year if somebody was working on it, nobody replied. > >I personally think the INB solution is cleaner and also contains all the >error codes etc., but by then I already had the code checked in. As far >as I know their code is not yet checked in. > >I think also in the OO Perl approach there seems to be some code. So >there will be many ways for the same goal. > > >Oh also if you use the CommonSubs methods please report if it actually >proves useful. > >Cheers, >Bj?rn > >Frank Gibbons wrote: > > Hi, > > Been away from MOBY for a while, now I'm back, and I see that everyone's > > been very busy ;-) Major kudos to Mark/Pieter on his work encoding > > Exceptions in the Perl API, as well as cleaning up the > message-parsing into > > an object-oriented form. So much cleaner now than in the past! > > I notice also that the INB group posted to the mailing list some > > nice-looking code to encode all the work in the RFC from last year, > but I > > didn't see it make it into the actual code base. Am I right? It too > looked > > pretty clean, seems like it'd make a good addition to the codebase. > > Regarding the docs for CommonSubs::encodeExceptions, it seems to me > that the > > first two arguments are confused: > > usage: > > encodeException( > > > > -refElement => 'refers to the queryID of the offending input > > mobyData', > > > > -refQueryID => 'refers to the articleName of the offending input > > Simple or Collection' > > > > > > Surely, 'refQueryID' should contain the queryID, and not refElement, > while > > refElement should contain the articleName. I can fix it, just wanted to > > check, since I've been away for a while. > > -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 [1]http://llama.med.harvard.edu/~fgibbons > > > > References > > > > 1. http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > >-- >-+-+-+-+-+-+-+-+-+-+-+- >Bj?rn Usadel, PhD > >Max Planck Institute of Molecular Plant Physiology >System Regulation Group > >Am M?hlenberg 1 >D-14476 Golm >Germany > >Tel (+49 331) 567-8114 > >Email usadel at mpimp-golm.mpg.de >WWW mapman.mpimp-golm.mpg.de >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at lists.open-bio.org >http://lists.open-bio.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 markw at illuminae.com Fri Jul 21 20:01:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 21 Jul 2006 13:01:27 -0700 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44C0FF6B.9040902@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF6B.9040902@mpimp-golm.mpg.de> Message-ID: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > I personally think the INB solution is cleaner and also contains all the > error codes etc., but by then I already had the code checked in. As far > as I know their code is not yet checked in. I've asked them why they are reluctant to contribute this code to the CVS (especially since they announced it on this mailing list), and got no answer :-( I really wish they would... M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Fri Jul 21 20:01:27 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 21 Jul 2006 13:01:27 -0700 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44C0FF6B.9040902@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF6B.9040902@mpimp-golm.mpg.de> Message-ID: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > I personally think the INB solution is cleaner and also contains all the > error codes etc., but by then I already had the code checked in. As far > as I know their code is not yet checked in. I've asked them why they are reluctant to contribute this code to the CVS (especially since they announced it on this mailing list), and got no answer :-( I really wish they would... M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Mon Jul 24 13:57:48 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 24 Jul 2006 13:57:48 +0000 GMT Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> :-) Tell then "modesty doesn't make you famous" :-) Thanks David! M -- Mark Wilkinson ...on the road! -----Original Message----- From: "David G. Pisano" Date: Mon, 24 Jul 2006 10:22:53 To:markw at illuminae.com, Core developer announcements Cc:MOBY-dev at biomoby.org Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > >_______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From markw at illuminae.com Mon Jul 24 13:57:48 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 24 Jul 2006 13:57:48 +0000 GMT Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> :-) Tell then "modesty doesn't make you famous" :-) Thanks David! M -- Mark Wilkinson ...on the road! -----Original Message----- From: "David G. Pisano" Date: Mon, 24 Jul 2006 10:22:53 To:markw at illuminae.com, Core developer announcements Cc:MOBY-dev at biomoby.org Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > >_______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From Pieter.Neerincx at wur.nl Wed Jul 26 09:57:24 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 11:57:24 +0200 Subject: [MOBY-dev] BioMOBY powered logo? In-Reply-To: <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> Message-ID: <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> Hi all, I'm making a poster for a project where we have used BioMOBY to make webservices. I'd like to advertise how wonderfull the BioMOBY project is on that poster, so I was wondering if there is an official "powered by BioMOBY" logo or something like that... Too much text on a poster doesn't sell the message, so I prefer a good logo and a reference to to www.biomoby.org over a literature reference. Cheers, Pi From Pieter.Neerincx at wur.nl Wed Jul 26 10:02:21 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 12:02:21 +0200 Subject: [MOBY-dev] Fwd: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> Message-ID: <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Looks like it's not going to be that soon... I have postponed further S::L testing until that "full release" will become available. Pi On 08 Jul 2006, at 01:00, Mark Wilkinson wrote: > Another release of SOAP::Lite coming soon... > > M > > > > ------- Forwarded message ------- > From: "Byrne Reese" > To: "Chris McMahon" > Cc: soaplite at yahoogroups.com > Subject: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 > Released > Date: Fri, 07 Jul 2006 12:08:24 -0700 > > Yes. Apparently I forgot to check one file in. Damn it. So what worked > for me in development didn't get fully released. > > Please stand-by. An update is forthcoming - perhaps by Monday. > > Chris McMahon wrote: >> >> >> Hi... >> This is significantly better than 0.67. However, I'm getting an >> error vs. the WSDL I need to read: >> >> Type 'ArrayOfstring' can't be found in a schema class >> 'SOAP::Serializer' >> >> Any ideas on fixing this? >> >> On 7/6/06, *Byrne Reese* > > wrote: >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new >> version is >> 0.68 and includes a number of fixes that make working with >> WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs >> (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I >> can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Pieter.Neerincx at wur.nl Wed Jul 26 10:02:21 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 12:02:21 +0200 Subject: [MOBY-dev] Fwd: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 Released In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> Message-ID: <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Looks like it's not going to be that soon... I have postponed further S::L testing until that "full release" will become available. Pi On 08 Jul 2006, at 01:00, Mark Wilkinson wrote: > Another release of SOAP::Lite coming soon... > > M > > > > ------- Forwarded message ------- > From: "Byrne Reese" > To: "Chris McMahon" > Cc: soaplite at yahoogroups.com > Subject: Re: Better but have a problem. Re: [soaplite] SOAP::Lite 0.68 > Released > Date: Fri, 07 Jul 2006 12:08:24 -0700 > > Yes. Apparently I forgot to check one file in. Damn it. So what worked > for me in development didn't get fully released. > > Please stand-by. An update is forthcoming - perhaps by Monday. > > Chris McMahon wrote: >> >> >> Hi... >> This is significantly better than 0.67. However, I'm getting an >> error vs. the WSDL I need to read: >> >> Type 'ArrayOfstring' can't be found in a schema class >> 'SOAP::Serializer' >> >> Any ideas on fixing this? >> >> On 7/6/06, *Byrne Reese* > > wrote: >> >> I have released a new version of SOAP::Lite. It is available on >> sourceforge now, or on CPAN in a couple of hours. The new >> version is >> 0.68 and includes a number of fixes that make working with >> WSDL less >> error prone. >> >> What motivated the fixes is working with Google's APIs >> (specifically >> the AdWords API). So I have confirmed that that works now. >> >> Please let me know if you experience any problems so that I >> can patch >> it immediately. >> >> Byrne Reese >> Lead Developer, SOAP::Lite >> >> >> >> > > > > -- > -- > Mark Wilkinson > Assistant Professor, Dept. Medical Genetics > University of British Columbia > PI Bioinformatics > iCAPTURE Centre, St. Paul's Hospital > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Pieter.Neerincx at wur.nl Wed Jul 26 11:53:47 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 13:53:47 +0200 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: Hi All, I was wondering who's traveling to Fortaleza next week. I quickly browsed the program and saw Martin (et al.) will give a presentation at BOSC and will have a poster at ISMB, but I didn't spot any gathering for Mobyfiers yet. It's been a while since Martin organized BioMOBY meetings, so I was wondering in case many of you will be there if we can have some sort of informal BioMOBY gathering. Surely this mailinglist does a fine job, but sometimes it's much faster to talk to people "live" :). Furthermore I'd love to see the faces that go with the names on this list :). So how do the others feel about a BioMOBY lunch or a BioMOBY coffee break meeting point? I also wouldn't mind to stay longer at the convention center for a BioMOBY diner. Then there is also the option of a Birds of a Feather (BOF) meeting during BOSC (These are free- form meetings organized by the attendees themselves to discuss one or a few topics of interest in greater detail). The list with suggestion for BOF topics is still empty last time I checked.... Cheers, Pi From senger at ebi.ac.uk Wed Jul 26 12:24:47 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 26 Jul 2006 13:24:47 +0100 (BST) Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: Message-ID: > It's been a while since Martin organized BioMOBY meetings > Correction: I have never organized such meetings, it was Mark. I have been just too loud to noticed that Mark was there, as well :-). > So how do the others feel about a BioMOBY lunch or a BioMOBY coffee > break meeting point? I also wouldn't mind to stay longer at the > convention center for a BioMOBY diner. Then there is also the option > of a Birds of a Feather (BOF) meeting during BOSC > I definitely agree with the BOF. Actually, that's my only option - I am not staying for ISMB - I will be leaving on the 6th. Thanks for bringing this topic on the table, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From Pieter.Neerincx at wur.nl Wed Jul 26 13:27:39 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 15:27:39 +0200 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: References: Message-ID: <5D8551B7-1D22-4CAE-B208-FBA8AFD22B19@wur.nl> On 26 Jul 2006, at 14:24, Martin Senger wrote: >> It's been a while since Martin organized BioMOBY meetings >> > Correction: I have never organized such meetings, it was Mark. I > have > been just too loud to noticed that Mark was there, as well :-). Sorry, I knew it was Mark who organised them. Stupid typo. > >> So how do the others feel about a BioMOBY lunch or a BioMOBY coffee >> break meeting point? I also wouldn't mind to stay longer at the >> convention center for a BioMOBY diner. Then there is also the option >> of a Birds of a Feather (BOF) meeting during BOSC >> > I definitely agree with the BOF. Actually, that's my only option > - I am > not staying for ISMB - I will be leaving on the 6th. Ok, at least a BOF it will be then. I'll register one and hope more people will join. Looking forward to meeting you there, Pi > > Thanks for bringing this topic on the table, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > > From phillip.lord at newcastle.ac.uk Wed Jul 26 14:18:16 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Wed, 26 Jul 2006 15:18:16 +0100 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: (Pieter Neerincx's message of "Wed, 26 Jul 2006 13:53:47 +0200") References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: >>>>> "PN" == Pieter Neerincx writes: PN> So how do the others feel about a BioMOBY lunch or a BioMOBY PN> coffee break meeting point? I also wouldn't mind to stay longer PN> at the convention center for a BioMOBY diner. My understanding is that the convention center is someway from the hotels, and that there will be transport provided too and from. Besides, what's wrong with the beech.... Phil From Pieter.Neerincx at wur.nl Wed Jul 26 15:35:04 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 26 Jul 2006 17:35:04 +0200 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> On 26 Jul 2006, at 16:18, Phillip Lord wrote: >>>>>> "PN" == Pieter Neerincx writes: > > PN> So how do the others feel about a BioMOBY lunch or a BioMOBY > PN> coffee break meeting point? I also wouldn't mind to stay longer > PN> at the convention center for a BioMOBY diner. > > > My understanding is that the convention center is someway from the > hotels, Yes, most hotels are along the coast and the convention center is more towards the center of town. > and that there will be transport provided too and from. > > Besides, what's wrong with the beech.... There's nothing wrong with the beach. Might want to try a BioMOBYfiers cocktail pipeline: everybody bring your own bottle, contribute to the mix and pass a glass on to the next person/ service :). Might result in some good ideas, but the beach is usually not the best place to take notes and my laptop probably doesn't like the sand... So I assume you'll be there too. That's 3 and counting... Pi > > > Phil > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Wed Jul 26 15:36:27 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 26 Jul 2006 16:36:27 +0100 (BST) Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: Message-ID: > Besides, what's wrong with the beech.... > The BOF is for working (concentrating), beach is for relaxing (de-concentrating). Working on the beach is simply wrong. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed Jul 26 15:58:47 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 26 Jul 2006 08:58:47 -0700 Subject: [MOBY-dev] [moby] BioMOBY powered logo? In-Reply-To: <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> Message-ID: <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> Hi Pieter, The M(actg)BY logo here (http://biomoby.org/moby1.gif) is the only logo we really have. There are some "powered-by" buttons, but they aren't that spectacular. There's a nice logo/button created by the Remora group here (http://lipm-bioinfo.toulouse.inra.fr/remora/img/remora.png), but since they use the M(actg)BY logo in their logo, I doubt that they have a high-res version of it. The M(actg)BY logo was created by a colleague of Paul Gordon's way back in 2002... I don't know if the original file still exists, but I have c.c.'d him on this response to bring it to his attention. If not, then all we have is that low-res version of the logo. :-/ M On Wed, 2006-07-26 at 11:57 +0200, Pieter Neerincx wrote: > Hi all, > > I'm making a poster for a project where we have used BioMOBY to make > webservices. I'd like to advertise how wonderfull the BioMOBY project > is on that poster, so I was wondering if there is an official > "powered by BioMOBY" logo or something like that... Too much text on > a poster doesn't sell the message, so I prefer a good logo and a > reference to to www.biomoby.org over a literature reference. > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Jul 26 16:06:12 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 26 Jul 2006 09:06:12 -0700 Subject: [MOBY-dev] [moby] BioMOBY at ISMB / BOSC 2006 In-Reply-To: References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: <1153929972.15097.27.camel@bioinfo.icapture.ubc.ca> Hi Pieter, Nobody from the Vancouver crew will be at that meeting, unfortunately, but a BOF would be really great - beach or no beach :-) I suspect that some of the Madrid/Barcelona team will be at ISMB as well, and it would be really great for us to somehow better coordinate with their activities. A MOBY Booze-flow pipeline sounds like something I am going to regret missing! M On Wed, 2006-07-26 at 13:53 +0200, Pieter Neerincx wrote: > Hi All, > > I was wondering who's traveling to Fortaleza next week. I quickly > browsed the program and saw Martin (et al.) will give a presentation > at BOSC and will have a poster at ISMB, but I didn't spot any > gathering for Mobyfiers yet. It's been a while since Martin organized > BioMOBY meetings, so I was wondering in case many of you will be > there if we can have some sort of informal BioMOBY gathering. Surely > this mailinglist does a fine job, but sometimes it's much faster to > talk to people "live" :). Furthermore I'd love to see the faces that > go with the names on this list :). > > So how do the others feel about a BioMOBY lunch or a BioMOBY coffee > break meeting point? I also wouldn't mind to stay longer at the > convention center for a BioMOBY diner. Then there is also the option > of a Birds of a Feather (BOF) meeting during BOSC (These are free- > form meetings organized by the attendees themselves to discuss one or > a few topics of interest in greater detail). The list with suggestion > for BOF topics is still empty last time I checked.... > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From phillip.lord at newcastle.ac.uk Wed Jul 26 19:28:09 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Wed, 26 Jul 2006 20:28:09 +0100 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> (Pieter Neerincx's message of "Wed, 26 Jul 2006 17:35:04 +0200") References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> Message-ID: >>>>> "PN" == Pieter Neerincx writes: PN> Yes, most hotels are along the coast and the convention center PN> is more towards the center of town. >> and that there will be transport provided too and from. >> >> Besides, what's wrong with the beech.... PN> There's nothing wrong with the beach. Might want to try a PN> BioMOBYfiers cocktail pipeline: everybody bring your own bottle, PN> contribute to the mix and pass a glass on to the next person/ PN> service :). Might result in some good ideas, but the beach is PN> usually not the best place to take notes and my laptop probably PN> doesn't like the sand... PN> So I assume you'll be there too. That's 3 and counting... Sorry for the last email, sent by mistake. To be honest, I don't think Fortaleza is the sort of place you will need to take a bottle the beech. There should be plenty around. And, yes, I will be there. Although, I would hesitate to describe myself as a BioMOBYier, rather than a mailing list lurker, it would be good to have an opportunity to meet people. Phil From phillip.lord at newcastle.ac.uk Wed Jul 26 19:25:43 2006 From: phillip.lord at newcastle.ac.uk (Phillip Lord) Date: Wed, 26 Jul 2006 20:25:43 +0100 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> (Pieter Neerincx's message of "Wed, 26 Jul 2006 17:35:04 +0200") References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> <82B47E89-4439-4C9D-AE3A-28DD7E0CF6F3@wur.nl> Message-ID: -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.lord at newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Newcastle University, Claremont Tower, Room 909 NE1 7RU From Pieter.Neerincx at wur.nl Thu Jul 27 18:07:45 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 27 Jul 2006 20:07:45 +0200 Subject: [MOBY-dev] [moby] BioMOBY powered logo? In-Reply-To: <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <6479F85C-EA37-40C4-B342-86A15DB3A682@wur.nl> Hi Mark, I really like the "old" logo and I want to make BioMOBY look good on that poster, so I didn't want to settle for the low-res version. It turns out the font used to create it was American Typewriter and once you have the correct font recreating a high resolution vector image is no longer mission impossible :). I made a new high res version in Adobe Illustrator and PDF format. The position of the Cs, Gs and Ts is slightly different in the new version, but you'll have to see them side by side to notice the difference. To make sure it won't get lost again I checked them into the CVS. They are available from ~moby-live/ Docs/Artwork/ Cheers, Pi On 26-Jul-2006, at 5:58 PM, Mark Wilkinson wrote: > Hi Pieter, > > The M(actg)BY logo here (http://biomoby.org/moby1.gif) is the only > logo > we really have. There are some "powered-by" buttons, but they aren't > that spectacular. There's a nice logo/button created by the Remora > group here (http://lipm-bioinfo.toulouse.inra.fr/remora/img/ > remora.png), > but since they use the M(actg)BY logo in their logo, I doubt that they > have a high-res version of it. > > The M(actg)BY logo was created by a colleague of Paul Gordon's way > back > in 2002... I don't know if the original file still exists, but I have > c.c.'d him on this response to bring it to his attention. If not, > then > all we have is that low-res version of the logo. > > :-/ > > M > > > > > On Wed, 2006-07-26 at 11:57 +0200, Pieter Neerincx wrote: >> Hi all, >> >> I'm making a poster for a project where we have used BioMOBY to make >> webservices. I'd like to advertise how wonderfull the BioMOBY project >> is on that poster, so I was wondering if there is an official >> "powered by BioMOBY" logo or something like that... Too much text on >> a poster doesn't sell the message, so I prefer a good logo and a >> reference to to www.biomoby.org over a literature reference. >> >> Cheers, >> >> Pi >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 Thu Jul 27 18:21:05 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 27 Jul 2006 11:21:05 -0700 Subject: [MOBY-dev] [moby] BioMOBY powered logo? In-Reply-To: <6479F85C-EA37-40C4-B342-86A15DB3A682@wur.nl> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <1633454598-1153749554-cardhu_blackberry.rim.net-1156-@engine25-cell01> <919E616E-356C-4029-AF24-EABF3BC8AD5A@wur.nl> <1153929527.15097.18.camel@bioinfo.icapture.ubc.ca> <6479F85C-EA37-40C4-B342-86A15DB3A682@wur.nl> Message-ID: Fantastic!!!!! Thanks!!!!! M On Thu, 27 Jul 2006 11:07:45 -0700, Pieter Neerincx wrote: > Hi Mark, > > I really like the "old" logo and I want to make BioMOBY look good on > that poster, so I didn't want to settle for the low-res version. It > turns out the font used to create it was American Typewriter and once > you have the correct font recreating a high resolution vector image > is no longer mission impossible :). I made a new high res version in > Adobe Illustrator and PDF format. The position of the Cs, Gs and Ts > is slightly different in the new version, but you'll have to see them > side by side to notice the difference. To make sure it won't get lost > again I checked them into the CVS. They are available from ~moby-live/ > Docs/Artwork/ > > Cheers, > > Pi > > > On 26-Jul-2006, at 5:58 PM, Mark Wilkinson wrote: > >> Hi Pieter, >> >> The M(actg)BY logo here (http://biomoby.org/moby1.gif) is the only >> logo >> we really have. There are some "powered-by" buttons, but they aren't >> that spectacular. There's a nice logo/button created by the Remora >> group here (http://lipm-bioinfo.toulouse.inra.fr/remora/img/ >> remora.png), >> but since they use the M(actg)BY logo in their logo, I doubt that they >> have a high-res version of it. >> >> The M(actg)BY logo was created by a colleague of Paul Gordon's way >> back >> in 2002... I don't know if the original file still exists, but I have >> c.c.'d him on this response to bring it to his attention. If not, >> then >> all we have is that low-res version of the logo. >> >> :-/ >> >> M >> >> >> >> >> On Wed, 2006-07-26 at 11:57 +0200, Pieter Neerincx wrote: >>> Hi all, >>> >>> I'm making a poster for a project where we have used BioMOBY to make >>> webservices. I'd like to advertise how wonderfull the BioMOBY project >>> is on that poster, so I was wondering if there is an official >>> "powered by BioMOBY" logo or something like that... Too much text on >>> a poster doesn't sell the message, so I prefer a good logo and a >>> reference to to www.biomoby.org over a literature reference. >>> >>> Cheers, >>> >>> Pi >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >> -- >> Mark Wilkinson >> Asst. Professor, Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics, iCAPTURE Centre >> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> "Since the point of a definition is to explain the meaning of a >> term to >> someone who is unfamiliar with its proper application, the use of >> language that doesn't help such a person learn how to apply the >> term is >> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >> but it is a lousy definition." >> >> K?hler et al, 2006 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.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 lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From Pieter.Neerincx at wur.nl Fri Jul 28 09:44:15 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 28 Jul 2006 11:44:15 +0200 Subject: [MOBY-dev] [moby] BioMOBY at ISMB / BOSC 2006 In-Reply-To: <1153929972.15097.27.camel@bioinfo.icapture.ubc.ca> References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com> <44AEB128.3090201@majordojo.com> <147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> <1153929972.15097.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <35E02AE2-4B2C-4DA1-87E1-82795B7E6B3E@wur.nl> On 26-Jul-2006, at 6:06 PM, Mark Wilkinson wrote: > Hi Pieter, > > Nobody from the Vancouver crew will be at that meeting, unfortunately, > but a BOF would be really great - beach or no beach :-) That's really a pitty nobody of your group will be there :(. > I suspect that > some of the Madrid/Barcelona team will be at ISMB as well, and it > would > be really great for us to somehow better coordinate with their > activities. I hope some of them will be there. We'll see. For those who will be there: I registered the first BOF for friday 17:00. http://www.open-bio.org/wiki/BOSC_2006/Birds-of-a-Feather Place is not yet known as I have no clue what options the convention center has... stay tuned. > > A MOBY Booze-flow pipeline sounds like something I am going to regret > missing! Who said there would be booze? Might be healthy juices overloaded with vitamins as well :). Anyway I'll do an intensive case-study and try to document it :). Pi > > M > > > On Wed, 2006-07-26 at 13:53 +0200, Pieter Neerincx wrote: >> Hi All, >> >> I was wondering who's traveling to Fortaleza next week. I quickly >> browsed the program and saw Martin (et al.) will give a presentation >> at BOSC and will have a poster at ISMB, but I didn't spot any >> gathering for Mobyfiers yet. It's been a while since Mark organized >> BioMOBY meetings, so I was wondering in case many of you will be >> there if we can have some sort of informal BioMOBY gathering. Surely >> this mailinglist does a fine job, but sometimes it's much faster to >> talk to people "live" :). Furthermore I'd love to see the faces that >> go with the names on this list :). >> >> So how do the others feel about a BioMOBY lunch or a BioMOBY coffee >> break meeting point? I also wouldn't mind to stay longer at the >> convention center for a BioMOBY diner. Then there is also the option >> of a Birds of a Feather (BOF) meeting during BOSC (These are free- >> form meetings organized by the attendees themselves to discuss one or >> a few topics of interest in greater detail). The list with suggestion >> for BOF topics is still empty last time I checked.... >> >> Cheers, >> >> Pi >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.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 dgonzalez at cnio.es Mon Jul 24 08:22:53 2006 From: dgonzalez at cnio.es (David G. Pisano) Date: Mon, 24 Jul 2006 10:22:53 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> Message-ID: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From dgonzalez at cnio.es Mon Jul 24 08:22:53 2006 From: dgonzalez at cnio.es (David G. Pisano) Date: Mon, 24 Jul 2006 10:22:53 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> Message-ID: <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Seems that our developers are too shy to check in code. I'll try to get this code checked in by the author. Regards, David On 21/07/2006, at 22:01, Mark Wilkinson wrote: > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > >> I personally think the INB solution is cleaner and also contains >> all the >> error codes etc., but by then I already had the code checked in. >> As far >> as I know their code is not yet checked in. > > I've asked them why they are reluctant to contribute this code to the > CVS (especially since they announced it on this mailing list), and got > no answer :-( > > I really wish they would... > > M > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From dgonzalez at cnio.es Fri Jul 28 12:08:07 2006 From: dgonzalez at cnio.es (David G. Pisano) Date: Fri, 28 Jul 2006 14:08:07 +0200 Subject: [MOBY-dev] Fwd: [Inb-tecnico] inab.org References: <44C9F00F.1010403@cnio.es> Message-ID: <95334374-397E-42A5-8AF1-E2F3EA7B8CC6@cnio.es> For your information (for those of you who sometimes use our moby central at inab.org) Regards, David Begin forwarded message: > From: Eduardo Andr?s Le?n > Date: 28 de julio de 2006 13:07:59 GMT+02:00 > To: "'Lista INB Tecnico'" > Subject: [Inb-tecnico] inab.org > > Hi everybody, > This weekend you may experience wrong functionality at our > URLS : inab.org , www.inab.org, moby-dev.inab.org .... > This is related with the planning movement of all Central Node > resources to our new center. > This movement not only implies physical movement of servers, it > also implies domain movement, dns configuration ... and so on. > > Apart from this wrong functionality , it's planned to move > physically the server on Monday morning, so there will not be > connection to our servers/lists in the whole morning. > > > We have planned everything in order to make this as clear as > possible, with the less interruptions at your work, but ..... I > will appreciate your patience ;) > > Regards. > > -- > Eduardo Andr?s Le?n > Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 2264) > e-mail: leon at cnio.es Fax: (+34) 91 224 69 76 > Unidad de Bioinform?tica Bioinformatics Unit > Centro Nacional de Investigaciones Oncol?gicas > C.P.: 28029 Zip Code: 28029 > C/. Melchor Fern?ndez Almagro, 3 Madrid (Spain) > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso > los ficheros adjuntos, pueden contener informaci?n protegida para > el uso exclusivo de su destinatario. Se proh?be la distribuci?n, > reproducci?n o cualquier otro tipo de transmisi?n por parte de otra > persona que no sea el destinatario. Si usted recibe por error este > correo, se ruega comunicarlo al remitente y borrar el mensaje > recibido. > **CONFIDENTIALITY NOTICE** This email communication and any > attachments may contain confidential and privileged information for > the sole use of the designated recipient named above. Distribution, > reproduction or any other use of this transmission by any party > other than the intended recipient is prohibited. If you are not the > intended recipient please contact the sender and delete all copies. > > _______________________________________________ > Inb-tecnico mailing list > Inb-tecnico at everest.cnb.uam.es > http://everest.cnb.uam.es/cgi-bin/mailman/listinfo/inb-tecnico **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. From ots at ac.uma.es Fri Jul 28 16:14:16 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 28 Jul 2006 18:14:16 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <007701c6b260$df802680$346dd696@ac.uma.es> Hi from the gnv5 at the INB we have been working -Johan in particular- in the asynch proposal. We have a almost final (internal) document we plan to submit early next week (there are a little bit of problems with my personnel since they have started vacation time and I am trying to contact them) On the other hand we have developed a prototype for testing the proposal that will also be ckeck-in soon regarding the exception-handling libraries we provide the proposal -discussed internally at the INB and latter in the moby list-, but the code has been developed outside our node. I am sure the owner will checkin the code soon. best regards Oswaldo ----- Original Message ----- From: "David G. Pisano" To: ; "Core developer announcements" Cc: Sent: Monday, July 24, 2006 10:22 AM Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > Seems that our developers are too shy to check in code. I'll try to > get this code checked in by the author. > > Regards, > > David > > On 21/07/2006, at 22:01, Mark Wilkinson wrote: > > > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > > > >> I personally think the INB solution is cleaner and also contains > >> all the > >> error codes etc., but by then I already had the code checked in. > >> As far > >> as I know their code is not yet checked in. > > > > I've asked them why they are reluctant to contribute this code to the > > CVS (especially since they announced it on this mailing list), and got > > no answer :-( > > > > I really wish they would... > > > > M > > > > > > -- > > Mark Wilkinson > > Asst. Professor, Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics, iCAPTURE Centre > > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "Since the point of a definition is to explain the meaning of a > > term to > > someone who is unfamiliar with its proper application, the use of > > language that doesn't help such a person learn how to apply the > > term is > > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > > but it is a lousy definition." > > > > K?hler et al, 2006 > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ots at ac.uma.es Fri Jul 28 16:14:16 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Fri, 28 Jul 2006 18:14:16 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc.ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> Message-ID: <007701c6b260$df802680$346dd696@ac.uma.es> Hi from the gnv5 at the INB we have been working -Johan in particular- in the asynch proposal. We have a almost final (internal) document we plan to submit early next week (there are a little bit of problems with my personnel since they have started vacation time and I am trying to contact them) On the other hand we have developed a prototype for testing the proposal that will also be ckeck-in soon regarding the exception-handling libraries we provide the proposal -discussed internally at the INB and latter in the moby list-, but the code has been developed outside our node. I am sure the owner will checkin the code soon. best regards Oswaldo ----- Original Message ----- From: "David G. Pisano" To: ; "Core developer announcements" Cc: Sent: Monday, July 24, 2006 10:22 AM Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > Seems that our developers are too shy to check in code. I'll try to > get this code checked in by the author. > > Regards, > > David > > On 21/07/2006, at 22:01, Mark Wilkinson wrote: > > > On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: > > > >> I personally think the INB solution is cleaner and also contains > >> all the > >> error codes etc., but by then I already had the code checked in. > >> As far > >> as I know their code is not yet checked in. > > > > I've asked them why they are reluctant to contribute this code to the > > CVS (especially since they announced it on this mailing list), and got > > no answer :-( > > > > I really wish they would... > > > > M > > > > > > -- > > Mark Wilkinson > > Asst. Professor, Dept. of Medical Genetics > > University of British Columbia > > PI in Bioinformatics, iCAPTURE Centre > > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > > Vancouver, BC, V6Z 1Y6 > > tel: 604 682 2344 x62129 > > fax: 604 806 9274 > > > > "Since the point of a definition is to explain the meaning of a > > term to > > someone who is unfamiliar with its proper application, the use of > > language that doesn't help such a person learn how to apply the > > term is > > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > > but it is a lousy definition." > > > > K?hler et al, 2006 > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los ficheros adjuntos, pueden contener informaci?n protegida para el uso exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o cualquier otro tipo de transmisi?n por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido. > **CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From ddg at ncgr.org Fri Jul 28 17:48:09 2006 From: ddg at ncgr.org (Damian Gessler) Date: Fri, 28 Jul 2006 11:48:09 -0600 Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 References: <72799cd70607071026v4ac1f85fwf3e07293970f0e95@mail.gmail.com><44AEB128.3090201@majordojo.com><147BC071-1D80-4082-AFED-23325EC0AEB1@wur.nl> Message-ID: <017701c6b26d$fd4b7cc0$674413ac@ncgr.org> > I was wondering who's traveling to Fortaleza next week For Semantic MOBY, Cliff Joslyn of LANL (Los Alamos National Lab) will be presenting our paper on how to decompose large monolithic ontologies into distributed (modular) ontologies for use in Semantic Web Services. His talk on Saturday, Aug 5 is part of the Bio-LINK and Bio-Ontologies SIG (http://ismb2006.cbi.cnptia.embrapa.br/sigs.html#jbb and http://bio-ontologies.man.ac.uk/programme.html). Damian. ----- Original Message ----- From: "Pieter Neerincx" To: "Core developer announcements" Sent: Wednesday, July 26, 2006 5:53 AM Subject: [MOBY-dev] BioMOBY at ISMB / BOSC 2006 > Hi All, > > I was wondering who's traveling to Fortaleza next week. I quickly > browsed the program and saw Martin (et al.) will give a presentation > at BOSC and will have a poster at ISMB, but I didn't spot any > gathering for Mobyfiers yet. It's been a while since Martin organized > BioMOBY meetings, so I was wondering in case many of you will be > there if we can have some sort of informal BioMOBY gathering. Surely > this mailinglist does a fine job, but sometimes it's much faster to > talk to people "live" :). Furthermore I'd love to see the faces that > go with the names on this list :). > > So how do the others feel about a BioMOBY lunch or a BioMOBY coffee > break meeting point? I also wouldn't mind to stay longer at the > convention center for a BioMOBY diner. Then there is also the option > of a Birds of a Feather (BOF) meeting during BOSC (These are free- > form meetings organized by the attendees themselves to discuss one or > a few topics of interest in greater detail). The list with suggestion > for BOF topics is still empty last time I checked.... > > Cheers, > > Pi > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From jmrc at cnb.uam.es Tue Jul 4 10:26:25 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Tue, 04 Jul 2006 10:26:25 -0000 Subject: [MOBY-dev] exception reporting In-Reply-To: References: Message-ID: <44AA405F.80702@cnb.uam.es> Hi everyone, I implemented the ability to report exception in the client side. I sorry, we had the code in SVN server but now we have some problems in that server. However, I have attached you a tar file where you can see the code and information related to. I hope help you. If you have any doubt...ask me. Best Regards, Jos?. Mark Wilkinson wrote: > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: MobyException.tar.gz Type: application/gzip Size: 752557 bytes Desc: not available URL: From jmrc at cnb.uam.es Tue Jul 4 10:26:31 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Tue, 04 Jul 2006 10:26:31 -0000 Subject: [MOBY-dev] exception reporting In-Reply-To: References: Message-ID: <44AA405F.80702@cnb.uam.es> Hi everyone, I implemented the ability to report exception in the client side. I sorry, we had the code in SVN server but now we have some problems in that server. However, I have attached you a tar file where you can see the code and information related to. I hope help you. If you have any doubt...ask me. Best Regards, Jos?. Mark Wilkinson wrote: > Hi all, > > Has anyone implemented the ability to report exceptions into the Perl > services code? > > M > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: MobyException.tar.gz Type: application/gzip Size: 752557 bytes Desc: not available URL: From jmrc at cnb.uam.es Mon Jul 31 08:47:29 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Mon, 31 Jul 2006 10:47:29 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <007701c6b260$df802680$346dd696@ac.uma.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc. ca><6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> Message-ID: <44CDC3A1.1080103@cnb.uam.es> Hi everyone, Oswaldo Trelles wrote: > Hi from the gnv5 at the INB > > we have been working -Johan in particular- in the asynch proposal. We have a > almost final (internal) document we plan to submit early next week (there > are a little bit of problems with my personnel since they have started > vacation time and I am trying to contact them) > > On the other hand we have developed a prototype for testing the proposal > that will also be ckeck-in soon > > regarding the exception-handling libraries we provide the > proposal -discussed internally at the INB and latter in the moby list-, but > the code has been developed outside our node. I am sure the owner will > checkin the code soon. > > The exception-handling library from the side of services has been checked for INB developers and it is OK. I wrote Mark Wilkinson to upload the code to BioMoby CVS. I am waiting the permissions for the administrator and I hope the code will be there very soon. Best Regards, Jos?. > best regards > Oswaldo > > > > > > > ----- Original Message ----- > From: "David G. Pisano" > To: ; "Core developer announcements" > > Cc: > Sent: Monday, July 24, 2006 10:22 AM > Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > > > >> Seems that our developers are too shy to check in code. I'll try to >> get this code checked in by the author. >> >> Regards, >> >> David >> >> On 21/07/2006, at 22:01, Mark Wilkinson wrote: >> >> >>> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: >>> >>> >>>> I personally think the INB solution is cleaner and also contains >>>> all the >>>> error codes etc., but by then I already had the code checked in. >>>> As far >>>> as I know their code is not yet checked in. >>>> >>> I've asked them why they are reluctant to contribute this code to the >>> CVS (especially since they announced it on this mailing list), and got >>> no answer :-( >>> >>> I really wish they would... >>> >>> M >>> >>> >>> -- >>> Mark Wilkinson >>> Asst. Professor, Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics, iCAPTURE Centre >>> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "Since the point of a definition is to explain the meaning of a >>> term to >>> someone who is unfamiliar with its proper application, the use of >>> language that doesn't help such a person learn how to apply the >>> term is >>> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >>> but it is a lousy definition." >>> >>> K?hler et al, 2006 >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los >> > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo al > remitente y borrar el mensaje recibido. > >> **CONFIDENTIALITY NOTICE** This email communication and any attachments >> > may contain confidential and privileged information for the sole use of the > designated recipient named above. Distribution, reproduction or any other > use of this transmission by any party other than the intended recipient is > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From jmrc at cnb.uam.es Mon Jul 31 08:47:29 2006 From: jmrc at cnb.uam.es (Jose Manuel Rodriguez) Date: Mon, 31 Jul 2006 10:47:29 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <007701c6b260$df802680$346dd696@ac.uma.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc. ca><6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> Message-ID: <44CDC3A1.1080103@cnb.uam.es> Hi everyone, Oswaldo Trelles wrote: > Hi from the gnv5 at the INB > > we have been working -Johan in particular- in the asynch proposal. We have a > almost final (internal) document we plan to submit early next week (there > are a little bit of problems with my personnel since they have started > vacation time and I am trying to contact them) > > On the other hand we have developed a prototype for testing the proposal > that will also be ckeck-in soon > > regarding the exception-handling libraries we provide the > proposal -discussed internally at the INB and latter in the moby list-, but > the code has been developed outside our node. I am sure the owner will > checkin the code soon. > > The exception-handling library from the side of services has been checked for INB developers and it is OK. I wrote Mark Wilkinson to upload the code to BioMoby CVS. I am waiting the permissions for the administrator and I hope the code will be there very soon. Best Regards, Jos?. > best regards > Oswaldo > > > > > > > ----- Original Message ----- > From: "David G. Pisano" > To: ; "Core developer announcements" > > Cc: > Sent: Monday, July 24, 2006 10:22 AM > Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... > > > >> Seems that our developers are too shy to check in code. I'll try to >> get this code checked in by the author. >> >> Regards, >> >> David >> >> On 21/07/2006, at 22:01, Mark Wilkinson wrote: >> >> >>> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: >>> >>> >>>> I personally think the INB solution is cleaner and also contains >>>> all the >>>> error codes etc., but by then I already had the code checked in. >>>> As far >>>> as I know their code is not yet checked in. >>>> >>> I've asked them why they are reluctant to contribute this code to the >>> CVS (especially since they announced it on this mailing list), and got >>> no answer :-( >>> >>> I really wish they would... >>> >>> M >>> >>> >>> -- >>> Mark Wilkinson >>> Asst. Professor, Dept. of Medical Genetics >>> University of British Columbia >>> PI in Bioinformatics, iCAPTURE Centre >>> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >>> Vancouver, BC, V6Z 1Y6 >>> tel: 604 682 2344 x62129 >>> fax: 604 806 9274 >>> >>> "Since the point of a definition is to explain the meaning of a >>> term to >>> someone who is unfamiliar with its proper application, the use of >>> language that doesn't help such a person learn how to apply the >>> term is >>> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >>> but it is a lousy definition." >>> >>> K?hler et al, 2006 >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los >> > ficheros adjuntos, pueden contener informaci?n protegida para el uso > exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o > cualquier otro tipo de transmisi?n por parte de otra persona que no sea el > destinatario. Si usted recibe por error este correo, se ruega comunicarlo al > remitente y borrar el mensaje recibido. > >> **CONFIDENTIALITY NOTICE** This email communication and any attachments >> > may contain confidential and privileged information for the sole use of the > designated recipient named above. Distribution, reproduction or any other > use of this transmission by any party other than the intended recipient is > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > From usadel at mpimp-golm.mpg.de Mon Jul 31 12:54:41 2006 From: usadel at mpimp-golm.mpg.de (=?ISO-8859-1?Q?Bj=F6rn_Usadel?=) Date: Mon, 31 Jul 2006 14:54:41 +0200 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44CDC3A1.1080103@cnb.uam.es> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu><44C0FF 6B.9040902@mpimp-golm.mpg.de><1153512087.5761.4.camel@bioinfo.icapture.ubc. ca><6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> <44CDC3A1.1080103@cnb.uam.es> Message-ID: <44CDFD91.9090102@mpimp-golm.mpg.de> Cool, I think you guys know best, how to interpret your RFC anyway. Should we then revert the code from CommonSubs, so as to avoid duplicated code or do we stick to Perl's "there is more than one way to do it" ? Do you have some code examples? We might want to put them in the tutorials and also hand them over to other tutorials on the web (I could do so for the TIGR wiki) Cheers, Bj?rn Jose Manuel Rodriguez wrote: > Hi everyone, > > Oswaldo Trelles wrote: >> Hi from the gnv5 at the INB >> >> we have been working -Johan in particular- in the asynch proposal. We have a >> almost final (internal) document we plan to submit early next week (there >> are a little bit of problems with my personnel since they have started >> vacation time and I am trying to contact them) >> >> On the other hand we have developed a prototype for testing the proposal >> that will also be ckeck-in soon >> >> regarding the exception-handling libraries we provide the >> proposal -discussed internally at the INB and latter in the moby list-, but >> the code has been developed outside our node. I am sure the owner will >> checkin the code soon. >> >> > The exception-handling library from the side of services has been > checked for INB developers and it is OK. I wrote Mark Wilkinson to > upload the code to BioMoby CVS. I am waiting the permissions for the > administrator and I hope the code will be there very soon. > > Best Regards, > Jos?. > > >> best regards >> Oswaldo >> >> >> >> >> >> >> ----- Original Message ----- >> From: "David G. Pisano" >> To: ; "Core developer announcements" >> >> Cc: >> Sent: Monday, July 24, 2006 10:22 AM >> Subject: Re: [MOBY-dev] [moby] Re: encodeException question.... >> >> >> >>> Seems that our developers are too shy to check in code. I'll try to >>> get this code checked in by the author. >>> >>> Regards, >>> >>> David >>> >>> On 21/07/2006, at 22:01, Mark Wilkinson wrote: >>> >>> >>>> On Fri, 2006-07-21 at 18:23 +0200, Bj?rn Usadel wrote: >>>> >>>> >>>>> I personally think the INB solution is cleaner and also contains >>>>> all the >>>>> error codes etc., but by then I already had the code checked in. >>>>> As far >>>>> as I know their code is not yet checked in. >>>>> >>>> I've asked them why they are reluctant to contribute this code to the >>>> CVS (especially since they announced it on this mailing list), and got >>>> no answer :-( >>>> >>>> I really wish they would... >>>> >>>> M >>>> >>>> >>>> -- >>>> Mark Wilkinson >>>> Asst. Professor, Dept. of Medical Genetics >>>> University of British Columbia >>>> PI in Bioinformatics, iCAPTURE Centre >>>> St. Paul's Hospital, Rm. 166, 1081 Burrard St. >>>> Vancouver, BC, V6Z 1Y6 >>>> tel: 604 682 2344 x62129 >>>> fax: 604 806 9274 >>>> >>>> "Since the point of a definition is to explain the meaning of a >>>> term to >>>> someone who is unfamiliar with its proper application, the use of >>>> language that doesn't help such a person learn how to apply the >>>> term is >>>> pointless. Thus, "happiness is a warm puppy" may be a lovely thought, >>>> but it is a lousy definition." >>>> >>>> K?hler et al, 2006 >>>> >>>> _______________________________________________ >>>> MOBY-dev mailing list >>>> MOBY-dev at lists.open-bio.org >>>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>>> >>> **NOTA DE CONFIDENCIALIDAD** Este correo electr?nico, y en su caso los >>> >> ficheros adjuntos, pueden contener informaci?n protegida para el uso >> exclusivo de su destinatario. Se proh?be la distribuci?n, reproducci?n o >> cualquier otro tipo de transmisi?n por parte de otra persona que no sea el >> destinatario. Si usted recibe por error este correo, se ruega comunicarlo al >> remitente y borrar el mensaje recibido. >> >>> **CONFIDENTIALITY NOTICE** This email communication and any attachments >>> >> may contain confidential and privileged information for the sole use of the >> designated recipient named above. Distribution, reproduction or any other >> use of this transmission by any party other than the intended recipient is >> prohibited. If you are not the intended recipient please contact the sender >> and delete all copies. >> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- -+-+-+-+-+-+-+-+-+-+-+- Bj?rn Usadel, PhD Max Planck Institute of Molecular Plant Physiology System Regulation Group Am M?hlenberg 1 D-14476 Golm Germany Tel (+49 331) 567-8114 Email usadel at mpimp-golm.mpg.de WWW mapman.mpimp-golm.mpg.de From spies at ipk-gatersleben.de Mon Jul 31 16:54:06 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Mon, 31 Jul 2006 18:54:06 +0200 Subject: [MOBY-dev] RDF Generation Message-ID: <44CE35AE.6070305@ipk-gatersleben.de> Hi, I'm looking for a tool which helps me with rdf generation for biomoby service. I don't want to do this by hand. Is there any such tool? How long will be the old registration style(XML) supported by biomoby? Karl From gss at ncgr.org Mon Jul 31 17:28:03 2006 From: gss at ncgr.org (Gary Schiltz) Date: Mon, 31 Jul 2006 11:28:03 -0600 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE35AE.6070305@ipk-gatersleben.de> References: <44CE35AE.6070305@ipk-gatersleben.de> Message-ID: <44CE3DA3.6060905@ncgr.org> If you're using Java, a rather heavyweight but very nice tool defacto standard tool for working with RDF is Jena (http://jena.sourceforge.net). If you're using Perl, then I'm no authority, but the RDF::Core (http://search.cpan.org/~dpokorny/RDF-Core-0.50/lib/RDF/Core.pm) set of modules looks good. // Gary Karl Spies wrote: > Hi, > > I'm looking for a tool which helps me with rdf generation for biomoby > service. I don't want to do this by hand. > > Is there any such tool? > > How long will be the old registration style(XML) supported by biomoby? > > Karl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From spies at ipk-gatersleben.de Mon Jul 31 18:10:45 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Mon, 31 Jul 2006 20:10:45 +0200 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE3DA3.6060905@ncgr.org> References: <44CE35AE.6070305@ipk-gatersleben.de> <44CE3DA3.6060905@ncgr.org> Message-ID: <44CE47A5.4080207@ipk-gatersleben.de> Hi, thanks for the hint to jena. But the existing jMOBY or MobyCentral doesn't support such tool? I'am a little bit busy at the moment and I hoped for a ready to use tool. :-) Karl From edward.kawas at gmail.com Mon Jul 31 17:40:55 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 31 Jul 2006 10:40:55 -0700 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE3DA3.6060905@ncgr.org> Message-ID: <006001c6b4c8$7a8281f0$6a00a8c0@notebook> Hi, If all you want is the RDF-XML that describes MOBY services, then the following should be what you are looking for: RDFGenerator (http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator)- Retrieve the RDF representation for your BioMoby Service. This servlet takes in the following parameters: * name - the name of your service * auth - the service providers authority URI * url - an optional mobycentral registry endpoint to use when generating your RDF * uri - an optional mobycentral registry namespace to use when generating your RDF If you are using JAVA and want to be able to programmatically generate RDF for any arbitrary service, then take a look at the class: org.biomoby.client.rdf.builder.ServiceInstanceRDF Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Gary Schiltz > Sent: Monday, July 31, 2006 10:28 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] RDF Generation > > If you're using Java, a rather heavyweight but very nice tool > defacto standard tool for working with RDF is Jena > (http://jena.sourceforge.net). > > If you're using Perl, then I'm no authority, but the RDF::Core > (http://search.cpan.org/~dpokorny/RDF-Core-0.50/lib/RDF/Core.p > m) set of modules looks good. > > // Gary > > Karl Spies wrote: > > Hi, > > > > I'm looking for a tool which helps me with rdf generation > for biomoby > > service. I don't want to do this by hand. > > > > Is there any such tool? > > > > How long will be the old registration style(XML) supported > by biomoby? > > > > Karl > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From spies at ipk-gatersleben.de Mon Jul 31 21:40:50 2006 From: spies at ipk-gatersleben.de (Karl Spies) Date: Mon, 31 Jul 2006 23:40:50 +0200 Subject: [MOBY-dev] RDF Generation In-Reply-To: <006001c6b4c8$7a8281f0$6a00a8c0@notebook> References: <006001c6b4c8$7a8281f0$6a00a8c0@notebook> Message-ID: <44CE78E2.708@ipk-gatersleben.de> Hi, thank you. The servlet is exactly what I need, but I think there is an error. http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerato produces "The service name is missing". Thanks again for that quick help. Karl From markw at illuminae.com Mon Jul 31 22:41:39 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 31 Jul 2006 15:41:39 -0700 Subject: [MOBY-dev] [moby] Re: encodeException question.... In-Reply-To: <44CDFD91.9090102@mpimp-golm.mpg.de> References: <5.2.1.1.2.20060721113801.0111b800@email.med.harvard.edu> <44C0FF 6B.9040902@mpimp-golm.mpg.de> <1153512087.5761.4.camel@bioinfo.icapture.ubc. ca> <6D26FB00-E116-4FE7-8751-94828AC4FB20@cnio.es> <007701c6b260$df802680$346dd696@ac.uma.es> <44CDC3A1.1080103@cnb.uam.es> <44CDFD91.9090102@mpimp-golm.mpg.de> Message-ID: On Mon, 31 Jul 2006 05:54:41 -0700, Bj?rn Usadel wrote: > Cool, > > I think you guys know best, how to interpret your RFC anyway. > > Should we then revert the code from CommonSubs, so as to avoid > duplicated code or do we stick to Perl's "there is more than one way to > do it" ? I think we should use the INB code modules, and remove the current code from CommonSubs. The CommonSubs module will soon be replaced (though not removed, for legacy reasons) with Martin and Eddie's work on Perl MoSeS... which is unbelievably cool! M -- -- Mark Wilkinson Assistant Professor, Dept. Medical Genetics University of British Columbia PI Bioinformatics iCAPTURE Centre, St. Paul's Hospital From edward.kawas at gmail.com Mon Jul 31 22:21:19 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 31 Jul 2006 15:21:19 -0700 Subject: [MOBY-dev] RDF Generation In-Reply-To: <44CE78E2.708@ipk-gatersleben.de> Message-ID: <001b01c6b4ef$a67ed070$756fa8c0@notebook> Hi, You will have to provide some parameters, for example, to generate RDF for getGOTerm,bioinfo.icapture.ubc.ca http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerator?name=getGoTerm&aut h=bioinfo.icapture.ubc.ca The parameters you can use are: * name - the name of your service * auth - the service providers authority URI * url - an optional mobycentral registry endpoint to use when generating your RDF * uri - an optional mobycentral registry namespace to use when generating your RDF Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Karl Spies > Sent: Monday, July 31, 2006 2:41 PM > To: Core developer announcements > Subject: Re: [MOBY-dev] RDF Generation > > Hi, > > thank you. The servlet is exactly what I need, but I think > there is an error. > > http://mobycentral.icapture.ubc.ca:8090/servlets/RDFGenerato > produces "The service name is missing". > > Thanks again for that quick help. > > Karl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev