From rebecca.ernst at gsf.de Wed Nov 2 07:32:47 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed Nov 2 07:38:36 2005 Subject: [MOBY-dev] parseMobyData Message-ID: <4368B1EF.9060004@gsf.de> Hi Eddie! I had another look into Taverna to see if our workflows now run correctly but found two problems of parseMobyData. The first problem is that parseMobyData can't deal with collections (it never could) the second is that it also can't deal with the new object stucture (e.g. a string object containing a string now) as it only checks the first layer content and never goes into the additional string. Do you know of these problems and if so - are there any plans for fixing it? Cheers, Rebecca From Pieter.Neerincx at wur.nl Wed Nov 2 07:44:21 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed Nov 2 07:54:54 2005 Subject: [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <4360E4FD.6090202@ucalgary.ca> References: <4360E4FD.6090202@ucalgary.ca> Message-ID: <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> Hi all, Here is a question for those using the Perl API. In MOBY/Client/Central.pm we have a sub retrieveObjectDefinition which calls sub _ObjectDefinitionPayload { This produces an array for the objects, articleNames and lsids for the relationships of the object whose definition is requested. I'm wondering why this is an array. Currently I have to rely on the order of elements in this array to figure out which element is the object, which one is articleName, etc. These are the lines producing the array: 553 push @{ $relationships{$relationshipType} }, 554 [ $_->toString, $article, $rlsid ]; Is there any reason why this should be an array? I'd rather not have to rely on the order of the elements, so are there people who have any objections when I change this into a hash like in: push @{ $relationships{$relationshipType} }, { object => $_->toString, articleName => $article, lsid => $rlsid }; Cheers, Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From Pieter.Neerincx at wur.nl Wed Nov 2 08:06:16 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed Nov 2 08:04:55 2005 Subject: [MOBY-dev] parseMobyData In-Reply-To: <4368B1EF.9060004@gsf.de> References: <4368B1EF.9060004@gsf.de> Message-ID: <0B94C244-81D6-4AE5-A457-37E71E0192E5@wur.nl> Hi all, On 2-Nov-2005, at 1:32 PM, Rebecca Ernst wrote: > Hi Eddie! > > I had another look into Taverna to see if our workflows now run > correctly but found two problems of parseMobyData. > The first problem is that parseMobyData can't deal with collections > (it never could) the second is that it also can't deal with the new > object stucture (e.g. a string object containing a string now) as > it only checks the first layer content and never goes into the > additional string. Well as far as I know it never did that either. It's a much bigger problem. It will not decompose any multi-layered objects. Currently it's easy to compile a big object from multiple smaller objects. If you add a complex object to your workflow Taverna will add all the individual parts and create the links between them. But decomposing the big object is something else. The info about the object's relationships are stored in the ontology, so theoretically it should be possible to generate proccessors to decompose the big ones, but I guess that is more like a feature request then a bug :). Currently I create custom services to decompose big objects again as a workaround, but some automated object decomposition in taverna would be really cool... Cheers, Pieter > Do you know of these problems and if so - are there any plans for > fixing it? > > Cheers, > Rebecca > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From markw at illuminae.com Wed Nov 2 11:12:56 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 11:43:09 2005 Subject: [moby] [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> Message-ID: <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> I think you're right - that's a much better data structure to be passing around. This does change the external (perl client) API, right? :-/ Really, what the Perl client code needs is a good laundering. The CommonSubs.pm module is a total mess after being modified piecemeal over the past 3 years... I wonder if we shouldn't just start a new module (or modules) that are named by their domain of function (RegistryIO, OntologyIO, or something like that) and have all fresh code? Gradually we could migrate all functionality into these modules. Client::Central has been around since the 0.1 prototype of MOBY in 2001 and has never been re-written top-to- bottom! I'm still waiting to hear about the re-funding attempts for MOBY... fingers crossed! There will hopefully be a second opportunity later in the winter, so all is not lost if we fail. It would be great to have a couple of extra hands dedicated to a complete code re-write. M On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: > Hi all, > > Here is a question for those using the Perl API. In > > MOBY/Client/Central.pm > > we have a > > sub retrieveObjectDefinition > > which calls > > sub _ObjectDefinitionPayload { > > This produces an array for the objects, articleNames and lsids for > the relationships of the object whose definition is requested. I'm > wondering why this is an array. Currently I have to rely on the order > of elements in this array to figure out which element is the object, > which one is articleName, etc. These are the lines producing the array: > > 553 push @{ $relationships{$relationshipType} }, > 554 [ $_->toString, $article, $rlsid ]; > > Is there any reason why this should be an array? I'd rather not have > to rely on the order of the elements, so are there people who have > any objections when I change this into a hash like in: > > push @{ $relationships{$relationshipType} }, > { object => $_->toString, > articleName => $article, > lsid => $rlsid }; > > Cheers, > > Pieter > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Wed Nov 2 10:47:45 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed Nov 2 12:31:07 2005 Subject: [MOBY-dev] RE: parseMobyData In-Reply-To: <4368B1EF.9060004@gsf.de> Message-ID: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Hi Rebecca, I was unaware of those issues, mainly because I didn't touch that widget and I left it as is for compatibility reasons. Also, I think that I could add support for parsing collections. Given a collection, return a list of whatever that widget returns. Moreover, you and Pieter have been talking about retrieving the string (and most likely integers, floats, etc) from the objects. Pieter went as far to say that he creates processors to do that for him. Do you think that it would be worthwhile to add another port to processors that contain the 'primitives' so that you can retrieve them? For example, imagine that you are using a processor blastDB that performs a blast search on some database and returns the blast results in xml. In Moby, this would be a data type called text-xml (I think). Would it be useful to also have an output port that contains only the xml text in it? Let me know what you think. Most likely, you have a better idea. Tell it to me and I will see what I can do. Eddie > -----Original Message----- > From: Rebecca Ernst [mailto:rebecca.ernst@gsf.de] > Sent: Wednesday, November 02, 2005 4:33 AM > To: Edward Kawas > Cc: mobydev > Subject: parseMobyData > > Hi Eddie! > > I had another look into Taverna to see if our workflows > now run > correctly but found two problems of parseMobyData. > The first problem is that parseMobyData can't deal with > collections (it > never could) the second is that it also can't deal with > the new object > stucture (e.g. a string object containing a string now) as > it only > checks the first layer content and never goes into the > additional string. > Do you know of these problems and if so - are there any > plans for fixing it? > > Cheers, > Rebecca From markw at illuminae.com Wed Nov 2 12:50:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 12:48:44 2005 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > Also, I think that I could add support for parsing > collections. Given a collection, return a list of whatever > that widget returns. Wow... I didn't realize that this functionality wasn't already in there somewhere. Or am I misunderstanding? Can't Taverna take a collection and pass the individual members one at a time to a downstream service that consumes simples? I guess I've never built a workflow that needs this. It's an interesting "book-keeping" problem for Taverna in that it would have to generate unique queryID's for each of the Simples it passed, since these would not have been provided by the previous service provider... > Moreover, you and Pieter have been talking about retrieving > the string (and most likely integers, floats, etc) from the > objects. Pieter went as far to say that he creates > processors to do that for him. Do you think that it would be > worthwhile to add another port to processors that contain > the 'primitives' so that you can retrieve them? YES! YES! YES! This is critical for interacting with anything other than a MOBY service... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 12:50:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 13:05:42 2005 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > Also, I think that I could add support for parsing > collections. Given a collection, return a list of whatever > that widget returns. Wow... I didn't realize that this functionality wasn't already in there somewhere. Or am I misunderstanding? Can't Taverna take a collection and pass the individual members one at a time to a downstream service that consumes simples? I guess I've never built a workflow that needs this. It's an interesting "book-keeping" problem for Taverna in that it would have to generate unique queryID's for each of the Simples it passed, since these would not have been provided by the previous service provider... > Moreover, you and Pieter have been talking about retrieving > the string (and most likely integers, floats, etc) from the > objects. Pieter went as far to say that he creates > processors to do that for him. Do you think that it would be > worthwhile to add another port to processors that contain > the 'primitives' so that you can retrieve them? YES! YES! YES! This is critical for interacting with anything other than a MOBY service... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 13:44:40 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 13:43:15 2005 Subject: [MOBY-dev] RFC Voting - message to all core developers In-Reply-To: <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> Message-ID: <1130957080.27282.40.camel@bioinfo.icapture.ubc.ca> So, this just isn't working at all :-/ A couple of frustrating things have happened v.v. RFC 1863: First: a vote was called, and there were some post-call suggestions which resulted in a revision of the document. The vote was subsequently called off. Second: there were some late suggestions from Paul and Martin (Oct 17/18) that were not discussed further by the interested parties (in particular, the group that put forward the RFC in the first place). An indication that the suggested changes are accepted/rejected by the proponents would be a good idea before a vote is called. Third: In the absence of changes to the document, the call for a re-vote was made, but was ignored by all but one of the RFC panel members (including my own local team, so I am just as guilty... but thanks Frank for being conscientious!). Whether it be by bugzilla or by email, it really doesn't matter to me which method people use - since this isn't a high-traffic event I can make notes on a piece of paper to tally the votes - but we need to actually DO it. I don't mean for this to be an accusatory message in any way. I only mean to point out that the RFC process for MOBY isn't working as we are currently implementing it, so we should perhaps come up with a better mechanism that accomplishes what we need to accomplish. There are a LOT of great suggestions currently sitting in Bugzilla that we will need to start addressing quickly. Do we need to set up a more dedicated mailing list or forum for RFC events so that they don't get lost in the general traffic of the -dev mailing list? (which is no longer a "low traffic" list, as it is described in the mailing list documentation ;-) ). Would a once-monthly teleconference solve the problem? What mechanism would the RFC panel find most intuitive and useful? Bugzilla is already in place, but if people are finding it too arcane, I can find a pre-canned or script-up an alternative solution... either way we need to quickly find something that does work, because I'm sure that David and his team in Spain are going nuts by now (especially since it is obvious that their RFC is, in principle, going to pass - we're only negotiating the details now :-) ) M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From tmo at ebi.ac.uk Wed Nov 2 12:58:07 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed Nov 2 14:29:37 2005 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> Message-ID: <4368FE2F.4070901@ebi.ac.uk> Mark Wilkinson wrote: > On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > > >>Also, I think that I could add support for parsing >>collections. Given a collection, return a list of whatever >>that widget returns. > > > Wow... I didn't realize that this functionality wasn't already in there > somewhere. Or am I misunderstanding? Can't Taverna take a collection > and pass the individual members one at a time to a downstream service > that consumes simples? I guess I've never built a workflow that needs > this. It's an interesting "book-keeping" problem for Taverna in that it > would have to generate unique queryID's for each of the Simples it > passed, since these would not have been provided by the previous service > provider... It _did_ work like that in our original version, yes. We broke all moby collections into Taverna collections of moby simples, using Taverna's type reconciliation layer to reconstitute these into moby collections if required or to iterate over services consuming moby simples. A while ago we agreed that this behaviour should be retained so if it doesn't do that now it's a bug. Tom From tmo at ebi.ac.uk Wed Nov 2 12:58:07 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed Nov 2 14:29:51 2005 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> Message-ID: <4368FE2F.4070901@ebi.ac.uk> Mark Wilkinson wrote: > On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > > >>Also, I think that I could add support for parsing >>collections. Given a collection, return a list of whatever >>that widget returns. > > > Wow... I didn't realize that this functionality wasn't already in there > somewhere. Or am I misunderstanding? Can't Taverna take a collection > and pass the individual members one at a time to a downstream service > that consumes simples? I guess I've never built a workflow that needs > this. It's an interesting "book-keeping" problem for Taverna in that it > would have to generate unique queryID's for each of the Simples it > passed, since these would not have been provided by the previous service > provider... It _did_ work like that in our original version, yes. We broke all moby collections into Taverna collections of moby simples, using Taverna's type reconciliation layer to reconstitute these into moby collections if required or to iterate over services consuming moby simples. A while ago we agreed that this behaviour should be retained so if it doesn't do that now it's a bug. Tom From markw at illuminae.com Wed Nov 2 17:03:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 17:02:04 2005 Subject: [MOBY-dev] A consequence of the new Object inheritence rules... Message-ID: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Hi all, I keep forgetting to mention, but it needs to be said so that people know about it until we have time to code it into the API: The way I see it, one of the consequences of not inheriting from Primitives is that MOBY now has its first "reserved word". The primary content of a given object (i.e. the content that would have been the CDATA, string, or integer content of the node in old-style objects) has now been stuck into a primitive data-type, however there is nothing preventing an object from having two HASA's, one containing the actual content, and the other containing a primitive. For example: AnnotatedFASTA hasa String (content) <--- this is the FASTA hasa String (Description) Back when we were allowing inheritance from primitives, it was obvious where the content was, but it isn't anymore, so we need a reserved word as the articleName of the contained primitive :-/ An alternative route would be to disallow use of primitives for anything *other* than containing 'content'. That would require another extensive re-working of the Object ontology, but we would end up with something like this: AnnotatedFASTA hasa String (content) hasa Description (anotation) hasa String (content) The latter seems more "correct", but it would require us to re-write the ontology again... Comments? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 17:40:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 17:39:08 2005 Subject: [moby] [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> References: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: <1130971234.27282.83.camel@bioinfo.icapture.ubc.ca> Just a clarification - by saying that the solution below seems more "correct" I was not suggesting that I *support* this solution. This solution leads to a massive proliferation of task-specific objects; every use of String now becomes a first-class MOBY Object, rather than simply a "performs role" relationship as we had with articleName. A pox on the Java-guys who don't like inheritance... ;-) M On Wed, 2005-11-02 at 14:03 -0800, Mark Wilkinson wrote: > An alternative route > would be to disallow use of primitives for anything *other* than > containing 'content'. That would require another extensive re-working > of the Object ontology, but we would end up with something like this: > > AnnotatedFASTA > hasa String (content) > hasa Description (anotation) > hasa String (content) > > The latter seems more "correct", but it would require us to re-write the > ontology again... -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 17:40:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 17:39:08 2005 Subject: [moby] [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> References: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: <1130971234.27282.83.camel@bioinfo.icapture.ubc.ca> Just a clarification - by saying that the solution below seems more "correct" I was not suggesting that I *support* this solution. This solution leads to a massive proliferation of task-specific objects; every use of String now becomes a first-class MOBY Object, rather than simply a "performs role" relationship as we had with articleName. A pox on the Java-guys who don't like inheritance... ;-) M On Wed, 2005-11-02 at 14:03 -0800, Mark Wilkinson wrote: > An alternative route > would be to disallow use of primitives for anything *other* than > containing 'content'. That would require another extensive re-working > of the Object ontology, but we would end up with something like this: > > AnnotatedFASTA > hasa String (content) > hasa Description (anotation) > hasa String (content) > > The latter seems more "correct", but it would require us to re-write the > ontology again... -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Nov 2 18:52:38 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 2 18:51:17 2005 Subject: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, What the hell are you talking about? :-) It's morning here so I may not be fully awoke... > The way I see it, one of the consequences of not inheriting from > Primitives is that MOBY now has its first "reserved word". > The reserverd words we have are the names of primitive types (String, Integer, Float, DateTime, Boolean, Object), we do not need any reserved word for an article name. You created the name 'content' just because you changed the old ontology to the new one by a script - which is fine (as long as nobody in that time was using the name 'content' for any HAS[A] members - probably was not, or possibly your script could have be clever and check this). But now, it really does not matter how to name it, does it? > The primary content of a given object > There is nothing like "the primary content". And if yes, today is the first time I hear it. I hope we do not need such concept. No, unless you explain it further I do not see any need for having a primary content, and that's why we do not need any reserved word for it. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 2 18:52:38 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 2 18:51:20 2005 Subject: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, What the hell are you talking about? :-) It's morning here so I may not be fully awoke... > The way I see it, one of the consequences of not inheriting from > Primitives is that MOBY now has its first "reserved word". > The reserverd words we have are the names of primitive types (String, Integer, Float, DateTime, Boolean, Object), we do not need any reserved word for an article name. You created the name 'content' just because you changed the old ontology to the new one by a script - which is fine (as long as nobody in that time was using the name 'content' for any HAS[A] members - probably was not, or possibly your script could have be clever and check this). But now, it really does not matter how to name it, does it? > The primary content of a given object > There is nothing like "the primary content". And if yes, today is the first time I hear it. I hope we do not need such concept. No, unless you explain it further I do not see any need for having a primary content, and that's why we do not need any reserved word for it. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 2 19:08:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 2 19:07:33 2005 Subject: [MOBY-dev] RFC Voting - message to all core developers In-Reply-To: <1130957080.27282.40.camel@bioinfo.icapture.ubc.ca> Message-ID: You are right that the voting process was not so smooth as it could have been - but do not be too desperate - it was not that bad. I think it is still better than it was before. I agree with you that the main problems were: * Not always clear where the latest document can be found (that's, for example, why I could not vote the last time). * Not sure where to vote (email or bugzilla). * Not fast enough replies from the voters about suggested changes. I still think that we should conclude this error handling voting now, and try again for other issues: - not in bugzilla, - discussion and document udates driven by the proponents, - keeping deadlines of voting Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 18:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 19:12:56 2005 Subject: [unclassified] Re: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: References: Message-ID: <1130975822.27282.90.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 23:52 +0000, Martin Senger wrote: > Mark, > What the hell are you talking about? :-) > It's morning here so I may not be fully awoke... I'll let you wake up a little more and think about it again before I try to explain it in more detail... it's a tricky one, and I'm multi-tasking right now... :-) M From markw at illuminae.com Wed Nov 2 20:51:11 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 20:49:48 2005 Subject: [MOBY-dev] Reserved word... perhaps unnecessary... Message-ID: <43696D0F.7010605@illuminae.com> Hi Martin, I love using you as the bellweather for my own thoughts :-) You are seldom wrong, and delight in telling me when I am! ;-) I think I am starting to see your point - I had not been thinking of the object ontology in quite that way, but you've got me reconsidering now. I'm going to bring it up for discussion at my lab meeting tomorrow and try to hash-out with the local guys exactly why I feel the way I do, and whether or not there are any serious adverse effects to thinking about it your way. It certainly makes things easier to do it your way, though I wish now that we had had this discussion while Eddie was writing the database update script because I would have changed the way we approached it... Oh well... I guess that's why MOBY is still considered a research project ;-) Thanks for being so forthright in your opinons - you are an extremely valuable asset to the project! M From markw at illuminae.com Wed Nov 2 21:15:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 21:14:16 2005 Subject: [MOBY-dev] New website is ready... Message-ID: <436972D0.8020606@illuminae.com> Hi all, I think I'm just about finished moving stuff over to the new website. Please browse it and get back to me or Simon with comments. http://biomoby.open-bio.org M From senger at ebi.ac.uk Wed Nov 2 21:28:48 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 2 21:27:22 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> Message-ID: > http://biomoby.open-bio.org > I asked to have there a link to jMoby pages. I cannot find it. Could it be inserted there please? The old link was/is http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move the jMoby pages somewhere else, or you just use to link to that old hyperlink. Thanks, Martin PS. The jMoby pages still use the old stylesheet, but that will be rectified in due time. No time for that now, I am afraid. M. -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 21:54:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 21:53:17 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43697BF3.7040209@illuminae.com> Sorry about that! It's now a link in the deveopers page M Martin Senger wrote: >>http://biomoby.open-bio.org >> >> >> > I asked to have there a link to jMoby pages. I cannot find it. Could it >be inserted there please? The old link was/is >http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move >the jMoby pages somewhere else, or you just use to link to that old >hyperlink. > > Thanks, > Martin > >PS. The jMoby pages still use the old stylesheet, but that will be >rectified in due time. No time for that now, I am afraid. M. > > > From markw at illuminae.com Wed Nov 2 21:56:31 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 21:54:59 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43697C5F.3020402@illuminae.com> I still don't have the cvs update on a cron... Does anyone know offhand if a cvs update preserves the permissions that I have set on the server, or does it over-write them with the permissions in the CVS repository? M Martin Senger wrote: >>http://biomoby.open-bio.org >> >> >> > I asked to have there a link to jMoby pages. I cannot find it. Could it >be inserted there please? The old link was/is >http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move >the jMoby pages somewhere else, or you just use to link to that old >hyperlink. > > Thanks, > Martin > >PS. The jMoby pages still use the old stylesheet, but that will be >rectified in due time. No time for that now, I am afraid. M. > > > From markw at illuminae.com Wed Nov 2 21:58:39 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 21:57:05 2005 Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? Message-ID: <43697CDF.5000408@illuminae.com> Under "Clients" on the new homepage is a list of all of the clients and applications that use MOBY that I know about. If I have missed anyone, please say so and I'll add it. M From senger at ebi.ac.uk Wed Nov 2 22:02:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 2 22:01:17 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: <43697C5F.3020402@illuminae.com> Message-ID: > I still don't have the cvs update on a cron... > This is what jMoby has for updating its documentation from CVS: #!/bin/bash # PATH=$PATH:/usr/java/j2sdk1.4.2_02/bin export PATH cd /home/websites/biomoby.org/html/moby-live/Java cvs -d :pserver:cvs:cvs@cvs.open-bio.org:/home/repository/moby -q update -dP ./build.sh docs > Does anyone know offhand if a cvs update preserves the permissions that > I have set on the server, or does it over-write them with the > permissions in the CVS repository? > My experiences are: It preserves them - but once they are in the cvs server you cannot change them. So if you commit a script script.pl without executing permissions, it will be always given to the local copies without this flag (unless you change it on the server side I guess). Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 2 22:05:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 2 22:06:05 2005 Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <43697CDF.5000408@illuminae.com> Message-ID: > Under "Clients" on the new homepage is a list of all of the clients and > applications that use MOBY that I know about. If I have missed anyone, > please say so and I'll add it. > client title: "command-line clients" source: jMoby platform: Java link: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/CmdLineClients.html Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 22:13:56 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 22:12:33 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43698074.8060708@illuminae.com> > This is what jMoby has for updating its documentation from CVS: > >#!/bin/bash ># >PATH=$PATH:/usr/java/j2sdk1.4.2_02/bin >export PATH >cd /home/websites/biomoby.org/html/moby-live/Java >cvs -d :pserver:cvs:cvs@cvs.open-bio.org:/home/repository/moby -q update -dP >./build.sh docs > > > Is that a script that I can call from the cron? > My experiences are: It preserves them - but once they are in the cvs >server you cannot change them. So if you commit a script script.pl without >executing permissions, it will be always given to the local copies >without this flag (unless you change it on the server side I guess). > > I know that it preserves them over CVS commits (i.e. if I commit without execute permission, and then commit with execute permission, it will still not have it), but I am unsure about whether something that was committed with execute permission will change the permissions of something that I set as non-executable locally and then cvs update over top of it. M > > From senger at ebi.ac.uk Wed Nov 2 22:17:18 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 2 22:15:56 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: <43698074.8060708@illuminae.com> Message-ID: > Is that a script that I can call from the cron? > Yes. I am calling it as a cronjob on machine portal.open-bio.org. My crontab item for this script is the following: # update jMoby from CVS and update its documentation # every 3 hours, every day 28 0,3,6,9,12,15,18,21 * * * $HOME/scripts/update-jmoby-docs.sh > /dev/null Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 22:30:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 2 22:29:46 2005 Subject: [MOBY-dev] jMOBY documentation Message-ID: <4369845B.6000301@illuminae.com> 1) it is now accessible through the new website under "MOBY For Developers" 2) I just read it for the first time... WOW! Martin, you did a really great job on that documentation! Kudo's to you! From bmg at sfu.ca Wed Nov 2 22:59:34 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed Nov 2 23:17:54 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <3DD0C1BE-C048-4F8D-B104-9391280F6DF0@sfu.ca> I don't see a link to register for the mailing list anywhere? Martin's graphs, Net Nanny on tools and toys? Should there be a contact link on the first page somewhere? Cool possible additions: A listing of project websites that employ moby services. Links to principle developers home pages if they exist. Dynamically updated statistics on services, moby central hits etc. Net Nanny for services! 2c -ben On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From Pieter.Neerincx at wur.nl Thu Nov 3 06:17:28 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu Nov 3 06:21:50 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> On 03Nov2005, at 03:15, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. Hi Mark and Simon, Nice job! Looks like I found some small permission bugs though: Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Docs/MOBY- S_API/index_API.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Java/docs/ taverna/guide/index.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Java/docs/ API/index.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Furthermore I added a page to the Docs in the CVS some time ago, but I can not find it anywhere on the new website... I'd love to be able to contribute to the new site, so I also registered for a WordPress account, but so far I haven't been able to do anything useful with it. Sure I can login (and logout), but that's it :(. Cheers, Pieter > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From Pieter.Neerincx at wur.nl Thu Nov 3 06:56:08 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu Nov 3 06:54:57 2005 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <0C0A3DE6-E48B-48AA-A62B-163E1DFCFD65@wur.nl> On 27Oct2005, at 24:18, Edward Kawas wrote: > Hi, > > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 I'm in favor of RFC 1863. So I vote yes again. I think it's crucial for the speed of BioMOBY evolution to have have at least some error reporting in place. In the current situation where empty objects are returned if something goes wrong, a user is completely in the dark. Debugging such cases is extremely painful. Currently most users are developers as well so we can look in the log files of the machines where our services are running, but if we want BioMOBY to become more popular with 'normal' users we need some error reporting that makes sense a.s.a.p. I found two small inconsistencies though: Page 4 mentions refqueryID, refQuery and refQueryID attributes. Do I get it right that these are typo's and all the same atribute...? Furtermore I think this: "refElement - refers to the articleName of the offending input Simple or Collection" will be a problem. If it's referring to the articleName it should be called refArticleName. The problem is that articleNames are optional. There is no guarantee they will be present. Furthermore they not need to be unique. In case there are multiple elements of the same type, the articleName attribute can be used to differentiate between them. Hence the combination of element and articleName can be used by a service to find a specific element. If you want to link an execption to a specific element of the input you will need both a refElement and a refArticleName... So instead of: 600 Unable to execute the service I propose something like this: 600 Unable to execute the service Just my 2c, Pieter > > Thanks. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From rebecca.ernst at gsf.de Thu Nov 3 09:58:32 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu Nov 3 09:56:09 2005 Subject: [MOBY-dev] Re: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <436A2598.4050307@gsf.de> Hi Eddie, Mark, Pieter, Tom and others! The problem No.1 (Collections in parsemobydata) is solved resp. it didn't exist. As for every other service or scavenger Taverna decomposes the object into simples! (this is true for Taverna versions up to 1.1 and for 1.3. Not for the 1.2 release though but here Eddie has a bugfix via CVS) The reason we believed it is a collection problem is that parsing of one service output failed which gives back collections. Now we digged into it and found that Taverna doesn't have a problem with the object being a collection: the problem was that the service is registered as giving back simples but gives back collections. In contrast to gbrowse Taverna obviously only decomposes collections when it expects them to be there. We had a look at the second problem (primitives in moby-objects) and think that your suggestion with further ports giving access to the primitives would solve the problem. If we got it right this would replace the 'parseMobyData' scavenger completely - is that right? Cheers, Rebecca and Dirk Edward Kawas wrote: >Hi Rebecca, > >I was unaware of those issues, mainly because I didn't touch >that widget and I left it as is for compatibility reasons. > >Also, I think that I could add support for parsing >collections. Given a collection, return a list of whatever >that widget returns. > >Moreover, you and Pieter have been talking about retrieving >the string (and most likely integers, floats, etc) from the >objects. Pieter went as far to say that he creates >processors to do that for him. Do you think that it would be >worthwhile to add another port to processors that contain >the 'primitives' so that you can retrieve them? > >For example, imagine that you are using a processor blastDB >that performs a blast search on some database and returns >the blast results in xml. In Moby, this would be a data type >called text-xml (I think). Would it be useful to also have >an output port that contains only the xml text in it? > >Let me know what you think. Most likely, you have a better >idea. Tell it to me and I will see what I can do. > >Eddie > > > >>-----Original Message----- >>From: Rebecca Ernst [mailto:rebecca.ernst@gsf.de] >>Sent: Wednesday, November 02, 2005 4:33 AM >>To: Edward Kawas >>Cc: mobydev >>Subject: parseMobyData >> >>Hi Eddie! >> >>I had another look into Taverna to see if our workflows >>now run >>correctly but found two problems of parseMobyData. >>The first problem is that parseMobyData can't deal with >>collections (it >>never could) the second is that it also can't deal with >>the new object >>stucture (e.g. a string object containing a string now) as >>it only >>checks the first layer content and never goes into the >>additional string. >>Do you know of these problems and if so - are there any >>plans for fixing it? >> >>Cheers, >>Rebecca >> >> > > > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From francis_gibbons at hms.harvard.edu Thu Nov 3 10:00:39 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu Nov 3 10:09:31 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> Message-ID: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> Mark, Under "For developers", the link to the "latest Perl API" docs doesn't work, because: You don't have permission to access /CVS_CONTENT/moby-live/Docs/MOBY-S_API/index_API.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Also, it struck me that the links to the tutorials are not the same as what's in CVS. I felt like it was important to have all documentation under CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other documentation is in the parent directory (omit the "Perl" above). -Frank At 09:15 PM 11/2/2005, you wrote: >Hi all, > >I think I'm just about finished moving stuff over to the new website. >Please browse it and get back to me or Simon with comments. > >http://biomoby.open-bio.org > >M > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Nov 3 10:23:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu Nov 3 10:34:53 2005 Subject: [MOBY-dev] New website is ready... Message-ID: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> Look under "clients" - many websites are there. Look under "about moby" - mailing list info is there. M -----Original Message----- From: Benjamin Good Date: Wed, 2 Nov 2005 19:59:34 To:Core developer announcements Subject: Re: [MOBY-dev] New website is ready... I don't see a link to register for the mailing list anywhere? Martin's graphs, Net Nanny on tools and toys? Should there be a contact link on the first page somewhere? Cool possible additions: A listing of project websites that employ moby services. Links to principle developers home pages if they exist. Dynamically updated statistics on services, moby central hits etc. Net Nanny for services! 2c -ben On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Thu Nov 3 10:00:30 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Nov 3 11:07:24 2005 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <0C0A3DE6-E48B-48AA-A62B-163E1DFCFD65@wur.nl> Message-ID: <000101c5e087$56402ba0$6600a8c0@notebook> I vote in favor. Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Thursday, November 03, 2005 3:56 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] vote on the RFC discussing Error > Reporting > > On 27Oct2005, at 24:18, Edward Kawas wrote: > > > Hi, > > > > I am calling a vote on the RFC that discusses error > > reporting. > > > > Please refer to the following link: > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > I'm in favor of RFC 1863. So I vote yes again. I think > it's crucial > for the speed of BioMOBY evolution to have have at least > some error > reporting in place. In the current situation where empty > objects are > returned if something goes wrong, a user is completely in > the dark. > Debugging such cases is extremely painful. Currently most > users are > developers as well so we can look in the log files of the > machines > where our services are running, but if we want BioMOBY to > become more > popular with 'normal' users we need some error reporting > that makes > sense a.s.a.p. > > I found two small inconsistencies though: > > Page 4 mentions refqueryID, refQuery and refQueryID > attributes. Do I > get it right that these are typo's and all the same > atribute...? > > Furtermore I think this: > > "refElement - refers to the articleName of the offending > input > Simple or Collection" > > will be a problem. If it's referring to the articleName it > should be > called refArticleName. The problem is that articleNames > are optional. > There is no guarantee they will be present. Furthermore > they not need > to be unique. In case there are multiple elements of the > same type, > the articleName attribute can be used to differentiate > between them. > Hence the combination of element and articleName can be > used by a > service to find a specific element. If you want to link an > execption > to a specific element of the input you will need both a > refElement > and a refArticleName... > > So instead of: > > refQueryID="1" > severity ="error"> > 600 > Unable to execute the > service > > > I propose something like this: > > refArticleName="input1" > refQueryID="1" > severity ="error"> > 600 > Unable to execute the > service > > > Just my 2c, > > Pieter > > > > > > Thanks. > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1038 > Dreijenlaan 3 > 6703 HA Wageningen > phone: 0317-484 706 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Thu Nov 3 11:10:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:09:04 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> References: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> Message-ID: <1131034229.31833.16.camel@bioinfo.icapture.ubc.ca> Martin, what is the URL for the NetNanny project? M On Thu, 2005-11-03 at 15:23 +0000, mark wilkinson wrote: > Look under "clients" - many websites are there. > > Look under "about moby" - mailing list info is there. > > M > > > -----Original Message----- > From: Benjamin Good > Date: Wed, 2 Nov 2005 19:59:34 > To:Core developer announcements > Subject: Re: [MOBY-dev] New website is ready... > > I don't see a link to register for the mailing list anywhere? > > Martin's graphs, Net Nanny on tools and toys? > > Should there be a contact link on the first page somewhere? > > Cool possible additions: > A listing of project websites that employ moby services. > Links to principle developers home pages if they exist. > Dynamically updated statistics on services, moby central hits etc. > Net Nanny for services! > > 2c > > -ben > > > > On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > > > Hi all, > > > > I think I'm just about finished moving stuff over to the new > > website. Please browse it and get back to me or Simon with comments. > > > > http://biomoby.open-bio.org > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:11:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:10:05 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> Message-ID: <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > Also, it struck me that the links to the tutorials are not the same as > what's in CVS. I felt like it was important to have all documentation under > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > documentation is in the parent directory (omit the "Perl" above). Right, the link in the tutorials is actually cyclic (it eventually leads back to itself), but I forgot to update it last night. I'll do that right away. M From markw at illuminae.com Thu Nov 3 11:11:49 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:10:21 2005 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <000101c5e087$56402ba0$6600a8c0@notebook> References: <000101c5e087$56402ba0$6600a8c0@notebook> Message-ID: <1131034309.31833.20.camel@bioinfo.icapture.ubc.ca> I vote in favor also. On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > I vote in favor. > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > > dev-bounces@portal.open-bio.org] On Behalf Of Pieter > > Neerincx > > Sent: Thursday, November 03, 2005 3:56 AM > > To: Core developer announcements > > Subject: Re: [MOBY-dev] vote on the RFC discussing Error > > Reporting > > > > On 27Oct2005, at 24:18, Edward Kawas wrote: > > > > > Hi, > > > > > > I am calling a vote on the RFC that discusses error > > > reporting. > > > > > > Please refer to the following link: > > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > > > I'm in favor of RFC 1863. So I vote yes again. I think > > it's crucial > > for the speed of BioMOBY evolution to have have at least > > some error > > reporting in place. In the current situation where empty > > objects are > > returned if something goes wrong, a user is completely in > > the dark. > > Debugging such cases is extremely painful. Currently most > > users are > > developers as well so we can look in the log files of the > > machines > > where our services are running, but if we want BioMOBY to > > become more > > popular with 'normal' users we need some error reporting > > that makes > > sense a.s.a.p. > > > > I found two small inconsistencies though: > > > > Page 4 mentions refqueryID, refQuery and refQueryID > > attributes. Do I > > get it right that these are typo's and all the same > > atribute...? > > > > Furtermore I think this: > > > > "refElement - refers to the articleName of the offending > > input > > Simple or Collection" > > > > will be a problem. If it's referring to the articleName it > > should be > > called refArticleName. The problem is that articleNames > > are optional. > > There is no guarantee they will be present. Furthermore > > they not need > > to be unique. In case there are multiple elements of the > > same type, > > the articleName attribute can be used to differentiate > > between them. > > Hence the combination of element and articleName can be > > used by a > > service to find a specific element. If you want to link an > > execption > > to a specific element of the input you will need both a > > refElement > > and a refArticleName... > > > > So instead of: > > > > > refQueryID="1" > > severity ="error"> > > 600 > > Unable to execute the > > service > > > > > > I propose something like this: > > > > > refArticleName="input1" > > refQueryID="1" > > severity ="error"> > > 600 > > Unable to execute the > > service > > > > > > Just my 2c, > > > > Pieter > > > > > > > > > > Thanks. > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev@biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1038 > > Dreijenlaan 3 > > 6703 HA Wageningen > > phone: 0317-484 706 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx@wur.nl > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Thu Nov 3 11:15:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Nov 3 11:14:11 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034229.31833.16.camel@bioinfo.icapture.ubc.ca> Message-ID: > Martin, what is the URL for the NetNanny project? > Does not ring any bells. Unless you mean BioNanny - that is http://www.bionanny.org. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 3 11:16:52 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Nov 3 11:15:30 2005 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <1131034309.31833.20.camel@bioinfo.icapture.ubc.ca> Message-ID: Could anybody sent me the latest document we are voting on? (But do not sent me a link to bugzilla please). Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Nov 3 11:18:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:16:59 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> Message-ID: <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 12:17 +0100, Pieter Neerincx wrote: > Forbidden All these that I can find are now fixed. I was paranoid last night and switched off execute permissions on all folders in the CVS except for the ones that I knew contained documentation because it makes me nervous having end-user-writable executable folders on our website! > Furthermore I added a page to the Docs in the CVS some time ago, but > I can not find it anywhere on the new website... where? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:23:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:21:32 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> Oh, I see what you mean. You have already ported the TWiki documentation over to the CVS. Super! I'll remove the ones that I moved last night then. M On Thu, 2005-11-03 at 08:11 -0800, Mark Wilkinson wrote: > On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > > > Also, it struck me that the links to the tutorials are not the same as > > what's in CVS. I felt like it was important to have all documentation under > > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > > documentation is in the parent directory (omit the "Perl" above). > > Right, the link in the tutorials is actually cyclic (it eventually leads > back to itself), but I forgot to update it last night. I'll do that > right away. > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Thu Nov 3 11:38:10 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu Nov 3 11:35:45 2005 Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <43697CDF.5000408@illuminae.com> References: <43697CDF.5000408@illuminae.com> Message-ID: <436A3CF2.3070905@gsf.de> Hi Mark! here are two more clients. maybe you want to include them in the page (but in another table like 'specific clients' as they are not very generic) http://urgi.infobiogen.fr/BioFloWeb/ http://mips.gsf.de/cgi-bin/proj/planet/moby/AtiDBClient.cgi Cheers, Rebecca Mark Wilkinson wrote: > Under "Clients" on the new homepage is a list of all of the clients > and applications that use MOBY that I know about. If I have missed > anyone, please say so and I'll add it. > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Thu Nov 3 11:39:58 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:38:31 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131035998.31833.29.camel@bioinfo.icapture.ubc.ca> Done! Thanks again Frank - that was a fantastic effort and it looks great!! M On Thu, 2005-11-03 at 08:23 -0800, Mark Wilkinson wrote: > Oh, I see what you mean. You have already ported the TWiki > documentation over to the CVS. Super! I'll remove the ones that I > moved last night then. > > M > > > On Thu, 2005-11-03 at 08:11 -0800, Mark Wilkinson wrote: > > On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > > > > > Also, it struck me that the links to the tutorials are not the same as > > > what's in CVS. I felt like it was important to have all documentation under > > > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > > > documentation is in the parent directory (omit the "Perl" above). > > > > Right, the link in the tutorials is actually cyclic (it eventually leads > > back to itself), but I forgot to update it last night. I'll do that > > right away. > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Thu Nov 3 11:31:35 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu Nov 3 11:39:46 2005 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <436A3B67.5070302@gsf.de> Hi Mark! I had a look on the website and wanted to test the LSID resolver.. (http://mobycentral.icapture.ubc.ca/cgi-bin/LSID_Resolver.pl) I only get internal server errors when trying it with one of the examples you give on that page... Cheers, Rebecca Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new website. > Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Thu Nov 3 11:46:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:45:06 2005 Subject: [moby] Re: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <436A3CF2.3070905@gsf.de> References: <43697CDF.5000408@illuminae.com> <436A3CF2.3070905@gsf.de> Message-ID: <1131036394.31833.31.camel@bioinfo.icapture.ubc.ca> Done On Thu, 2005-11-03 at 17:38 +0100, Rebecca Ernst wrote: > Hi Mark! > > here are two more clients. maybe you want to include them in the page > (but in another table like 'specific clients' as they are not very generic) > > http://urgi.infobiogen.fr/BioFloWeb/ > http://mips.gsf.de/cgi-bin/proj/planet/moby/AtiDBClient.cgi > > Cheers, > Rebecca > > > > Mark Wilkinson wrote: > > > Under "Clients" on the new homepage is a list of all of the clients > > and applications that use MOBY that I know about. If I have missed > > anyone, please say so and I'll add it. > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Thu Nov 3 10:00:17 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Nov 3 11:45:43 2005 Subject: [MOBY-dev] RE: parseMobyData In-Reply-To: <436A2598.4050307@gsf.de> Message-ID: <000001c5e087$4f3a8850$6600a8c0@notebook> HI! > -----Original Message----- > From: Rebecca Ernst [mailto:rebecca.ernst@gsf.de] > Sent: Thursday, November 03, 2005 6:59 AM > To: Edward Kawas > Cc: 'Moby Developers' > Subject: Re: parseMobyData > > Hi Eddie, Mark, Pieter, Tom and others! > > The problem No.1 (Collections in parsemobydata) is solved > resp. it > didn't exist. > As for every other service or scavenger Taverna decomposes > the object > into simples! (this is true for Taverna versions up to 1.1 > and for 1.3. > Not for the 1.2 release though but here Eddie has a bugfix > via CVS) > The reason we believed it is a collection problem is that > parsing of one > service output failed which gives back collections. > Now we digged into it and found that Taverna doesn't have > a problem with > the object being a collection: the problem was that the > service is > registered as giving back simples but gives back > collections. In > contrast to gbrowse Taverna obviously only decomposes > collections when > it expects them to be there. > > We had a look at the second problem (primitives in moby- > objects) and > think that your suggestion with further ports giving > access to the > primitives would solve the problem. If we got it right > this would > replace the 'parseMobyData' scavenger completely - is that > right? I think so. But then again, parseMobyData also allows you to retrieve ids, namespaces, etc. I would only give you the primitive information. Eddie > > Cheers, > Rebecca and Dirk > > > > > > > > > Edward Kawas wrote: > > >Hi Rebecca, > > > >I was unaware of those issues, mainly because I didn't > touch > >that widget and I left it as is for compatibility reasons. > > > >Also, I think that I could add support for parsing > >collections. Given a collection, return a list of > whatever > >that widget returns. > > > >Moreover, you and Pieter have been talking about > retrieving > >the string (and most likely integers, floats, etc) from > the > >objects. Pieter went as far to say that he creates > >processors to do that for him. Do you think that it would > be > >worthwhile to add another port to processors that contain > >the 'primitives' so that you can retrieve them? > > > >For example, imagine that you are using a processor > blastDB > >that performs a blast search on some database and returns > >the blast results in xml. In Moby, this would be a data > type > >called text-xml (I think). Would it be useful to also > have > >an output port that contains only the xml text in it? > > > >Let me know what you think. Most likely, you have a > better > >idea. Tell it to me and I will see what I can do. > > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Rebecca Ernst [mailto:rebecca.ernst@gsf.de] > >>Sent: Wednesday, November 02, 2005 4:33 AM > >>To: Edward Kawas > >>Cc: mobydev > >>Subject: parseMobyData > >> > >>Hi Eddie! > >> > >>I had another look into Taverna to see if our workflows > >>now run > >>correctly but found two problems of parseMobyData. > >>The first problem is that parseMobyData can't deal with > >>collections (it > >>never could) the second is that it also can't deal with > >>the new object > >>stucture (e.g. a string object containing a string now) > as > >>it only > >>checks the first layer content and never goes into the > >>additional string. > >>Do you know of these problems and if so - are there any > >>plans for fixing it? > >> > >>Cheers, > >>Rebecca > >> > >> > > > > > > > > > > > > -- > Rebecca Ernst > MIPS, Inst. for Bioinformatics > GSF Research Center for Environment and Health > Ingolstaedter Landstr. 1 > 85764 Neuherberg > fon: +49 89 3187 3583 > email: Rebecca.Ernst@gsf.de From markw at illuminae.com Thu Nov 3 11:48:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:47:15 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <436A3B67.5070302@gsf.de> References: <436972D0.8020606@illuminae.com> <436A3B67.5070302@gsf.de> Message-ID: <1131036523.31833.35.camel@bioinfo.icapture.ubc.ca> Hi Rebecca, Yeah, it turns out that the LSID Perl client stack from Sourceforge doesn't handle namespaces on its wsdl documents (ask me how long it took me to debug THAT problem!), so that resolver doesn't work anymore :-/ >>sigh<< The Perl support for XML is **SO** crappy! Anyway, Eddie has written a new one in Java, and I just haven't had time to set up the link to it. I'll do that right now. Thanks for reminding me! M On Thu, 2005-11-03 at 17:31 +0100, Rebecca Ernst wrote: > Hi Mark! > > I had a look on the website and wanted to test the LSID resolver.. > (http://mobycentral.icapture.ubc.ca/cgi-bin/LSID_Resolver.pl) > > I only get internal server errors when trying it with one of the > examples you give on that page... > > Cheers, > Rebecca > > > > > Mark Wilkinson wrote: > > > Hi all, > > > > I think I'm just about finished moving stuff over to the new website. > > Please browse it and get back to me or Simon with comments. > > > > http://biomoby.open-bio.org > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:51:41 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:50:16 2005 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000001c5e087$4f3a8850$6600a8c0@notebook> References: <000001c5e087$4f3a8850$6600a8c0@notebook> Message-ID: <1131036701.31833.41.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > > think that your suggestion with further ports giving > > access to the > > primitives would solve the problem. If we got it right > > this would > > replace the 'parseMobyData' scavenger completely - is that > > right? > I think so. But then again, parseMobyData also allows you to > retrieve ids, namespaces, etc. I would only give you the > primitive information. Is there a need to have both, or should they be rolled into one now? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:51:41 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 11:50:17 2005 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000001c5e087$4f3a8850$6600a8c0@notebook> References: <000001c5e087$4f3a8850$6600a8c0@notebook> Message-ID: <1131036701.31833.41.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > > think that your suggestion with further ports giving > > access to the > > primitives would solve the problem. If we got it right > > this would > > replace the 'parseMobyData' scavenger completely - is that > > right? > I think so. But then again, parseMobyData also allows you to > retrieve ids, namespaces, etc. I would only give you the > primitive information. Is there a need to have both, or should they be rolled into one now? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From dgpisano at cnb.uam.es Thu Nov 3 12:08:18 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu Nov 3 12:23:03 2005 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: Message-ID: <436A4402.7000209@cnb.uam.es> Martin Senger escribi?: >Could anybody sent me the latest document we are voting on? (But do not >sent me a link to bugzilla please). > >Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v2.02.pdf Type: application/pdf Size: 186802 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20051103/84c7dcac/0501INB-ExceptionReporting-v2.02-0001.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20051103/84c7dcac/dgpisano-0001.vcf From dgpisano at cnb.uam.es Thu Nov 3 12:36:53 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu Nov 3 12:35:34 2005 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: Message-ID: <436A4AB5.6050903@cnb.uam.es> Hello Martin, I've just sent you the latest version (2.02, 3rd November 2005) version which includes some of the changes that were discussed during October. The document is also in the bugzilla (http://bugzilla.open-bio.org/attachment.cgi?id=246) My vote is YES, just in case somebody is wondering ;-) Martin Senger escribi?: >Could anybody sent me the latest document we are voting on? (But do not >sent me a link to bugzilla please). > Some comments about this latest version (the author's name and the date the comment was sent to core developers included, plus the request and the action taken and reflected in the 2.02 version). No major changes, the proposal is still the same than 1 month ago with some rewordings and typos corrected: - Mark (29/09/2005) - Request for change the wording of Change 1 to "In the case of an error, failure should raise an exception and an empty mobyData block with the appropriate queryID will be returned" - INCLUDED - Paul (17/10/2005) - Request to rename the proposal to something more meaningful - DONE, now the proposal is called "Exception Reporting in MOBY-S" - Paul (17/10/2005) - Doubts about the error 701 - DONE, the ambiguous example has been removed - Paul (17/10/2005) - Errors 70* suggestions - DONE partially, added the "error" 700 as a generic service intrinsic exception placeholder for any generic situation where the execution was ok and we want to use mobyException. Other codes not added, see next comment - Martin (18/10/2005) - Type "information" in exception reporting - I think it not hurts to leave it there. It could be used to report informative (non erroneous or warning) exceptions about a specific element (Simple or Collection) or mobyData entry in a structured (parseable) way, because mobyException allows us to map the information to that specific element. We still maintain the Notes in serviceNotes to report general unstructured information, and for functional compatibility with old moby versions - Martin (18/10/2005) - Errors 70* suggestions - DONE partially, added the "error" 700 (see above) and removed all the codes but 701 (SERVICE_INTERNAL_ERROR). As Martin suggests, created a 227 INPUT_INCORRECT_NAMESPACE - Pieter (3/11/2005) - typos in the document - DONE, the tag is called refQueryID, reviewed and changed - Pieter (3/11/2005) - refArticlename - NOT INCLUDED. I know this can open a new can of worms about whether rticlenames should be mandatory or not, and we have talked about this in the past. The problem is not with the exception reporting proposal, but with the MOBY specification itself: if Articlenames are not mandatory, and I can send several elements to the same type to my service, how can I differenciate them? If there is no need to differenciate them, or that does not make sense from the point of view of the service execution, then it makes no sense from the point of view of the exception reporting. If I cannot identify them individually, then I cannot report exceptions about them individually and thus I have to say "There is a problem with one or more or the inputs". If I can differenciate them because they have an Articlename, then I use the refElement tag to refer to the problematic element... Does this make sense? -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20051103/44cbafb8/dgpisano.vcf From duncan.hull at cs.man.ac.uk Thu Nov 3 14:42:13 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Thu Nov 3 15:01:44 2005 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436A6815.70201@cs.man.ac.uk> Dear Mark / BioMOBYers Can you advise me on the best way to get the rdf for the service "EMBOSSbacktranseq" I just wanted some examples, and found http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf ...from martins handy client documentation but not sure if the RDF is up to date. Thanks Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From simont at mcw.edu Thu Nov 3 15:17:50 2005 From: simont at mcw.edu (Twigger Simon) Date: Thu Nov 3 15:42:22 2005 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <78883846-6389-4B18-B334-8D0D3FFC1B04@mcw.edu> I vote in favour of RFC 1863. Simon. On Oct 26, 2005, at 5:18 PM, Edward Kawas wrote: > Hi, > > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > Thanks. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From markw at illuminae.com Thu Nov 3 15:56:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 15:55:01 2005 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <436A6815.70201@cs.man.ac.uk> References: <436A6815.70201@cs.man.ac.uk> Message-ID: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Hi Dunc! I hope you aren't writing another thesis saying nasty things about MOBY! Okay, the main problem is that the RDF is not up to date - we're still negotiating with Pinar about what the RDF representation of MOBY/myGrid services is going to be (in fact, Eddie is here right now and we are going over the final details). As such, when you do what I suggest below, you are going to get RDF that is still changing daily. Having said all that - there are two ways to get MOBY RDF. You can get it from our RESOURCES script, or by LSID resolution to metadata. To get a full dump of MOBY Central as RDF (the old RDF that we will NOT be using) go to: http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances (this takes a while, since it is dynamically generated...) Or for a specific service, resolve the LSID: urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName (e.g. urn:lsid:biomoby.org:serviceinstance:www.illuminae.com,getSHound3DNeighboursFromGi) We'll have the RDF generator updated in the next few days - hopefully today will be the last of our modifications of the RDF structure to be myGrid-compatible. M On Thu, 2005-11-03 at 19:42 +0000, Duncan Hull wrote: > Dear Mark / BioMOBYers > > Can you advise me on the best way to get the rdf for the service > "EMBOSSbacktranseq" > > I just wanted some examples, and found > http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf > > ...from martins handy client documentation but not sure if the RDF is up > to date. > > Thanks > > Duncan > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 15:59:28 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 15:58:01 2005 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> If you like, I will ask Eddie to write to you when the updates are done, and then you will have something stable to play with... M On Thu, 2005-11-03 at 12:56 -0800, Mark Wilkinson wrote: > Hi Dunc! > > I hope you aren't writing another thesis saying nasty things about MOBY! > > Okay, the main problem is that the RDF is not up to date - we're still > negotiating with Pinar about what the RDF representation of MOBY/myGrid > services is going to be (in fact, Eddie is here right now and we are > going over the final details). As such, when you do what I suggest > below, you are going to get RDF that is still changing daily. > > Having said all that - there are two ways to get MOBY RDF. You can get > it from our RESOURCES script, or by LSID resolution to metadata. > > To get a full dump of MOBY Central as RDF (the old RDF that we will NOT > be using) go to: > > http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances > (this takes a while, since it is dynamically generated...) > > Or for a specific service, resolve the LSID: > > urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName > > (e.g. > urn:lsid:biomoby.org:serviceinstance:www.illuminae.com,getSHound3DNeighboursFromGi) > > We'll have the RDF generator updated in the next few days - hopefully > today will be the last of our modifications of the RDF structure to be > myGrid-compatible. > > M > > > > On Thu, 2005-11-03 at 19:42 +0000, Duncan Hull wrote: > > Dear Mark / BioMOBYers > > > > Can you advise me on the best way to get the rdf for the service > > "EMBOSSbacktranseq" > > > > I just wanted some examples, and found > > http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf > > > > ...from martins handy client documentation but not sure if the RDF is up > > to date. > > > > Thanks > > > > Duncan > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 16:19:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu Nov 3 16:18:04 2005 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <43696D0F.7010605@illuminae.com> References: <43696D0F.7010605@illuminae.com> Message-ID: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Okay, I have thought about this now, and discussed it with Eddie and Ben for a while. I can see the way Martin is thinking, and it is certainly different from how I have always "seen" MOBY Objects. Here's how the argument goes: Martin: MOBY Objects are just syntax, so there is no such thing as a "core" data-type for MOBY objects. They don't have an "essense"! Objects are just "stuff" Mark: Yes they do! The ISA hierarchy implies that an object has an "essense". There are two ways to construct an AnnotatedFASTA object: It can either inherit from FASTA, and add an Annotation, or it can inherit from Annotation and add a FASTA. Under the new object creation system, the syntactic outcome of these paths is identical, but they are "qualitatively" different.... it is nonsensical to "FASTA an Annotation", but it is sensible to "Annotate a FASTA". The "essense" of the object is the FASTA sequence it contains, based on its ISA hierarchy. The problem we have now is that, without querying the ontology and traversing back to the most primitive object, I cannot know which contained object represents the "essense" of my in-hand object (i.e. the thing that I would MOST want to represent if I had to represent that object in a hurry). It also causes a problem with rendering... a FASTA sequence and a Genbank record are formatted strings. What happens now that we have contained primitives is that you have to ask the parent tag about its type before you know how to render the child tag. I can't render a string containing a genbank record without paying attention to its formatting, but I don't know that a String is a formatted string until I ask the parent GenBankFlatfile object what it is... :-/ >>sigh<< I dunno... the world just got much harder. M On Wed, 2005-11-02 at 17:51 -0800, Mark Wilkinson wrote: > Hi Martin, > > I love using you as the bellweather for my own thoughts :-) You are > seldom wrong, and delight in telling me when I am! ;-) > > I think I am starting to see your point - I had not been thinking of the > object ontology in quite that way, but you've got me reconsidering now. > I'm going to bring it up for discussion at my lab meeting tomorrow and > try to hash-out with the local guys exactly why I feel the way I do, and > whether or not there are any serious adverse effects to thinking about > it your way. It certainly makes things easier to do it your way, though > I wish now that we had had this discussion while Eddie was writing the > database update script because I would have changed the way we > approached it... > > Oh well... I guess that's why MOBY is still considered a research > project ;-) > > Thanks for being so forthright in your opinons - you are an extremely > valuable asset to the project! > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Thu Nov 3 15:56:20 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu Nov 3 18:41:23 2005 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436A6815.70201@cs.man.ac.uk> Message-ID: <000201c5e0b9$0d6d0fb0$2566a8c0@notebook> Hi Duncan, I am reworking the structure of the rdf document that describes Moby services. Right now, if you want to see an outdated version, http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances would be the place to get a document describing all services. Once the structure has been reworked, I will let you know. Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Duncan Hull > Sent: Thursday, November 03, 2005 11:42 AM > To: Core developer announcements; markw@illuminae.com > Subject: [MOBY-dev] Please sir, can I have some more RDF? > > Dear Mark / BioMOBYers > > Can you advise me on the best way to get the rdf for the > service > "EMBOSSbacktranseq" > > I just wanted some examples, and found > http://www.biomoby.org/moby- > live/Java/docs/Testing_service.rdf > > ...from martins handy client documentation but not sure if > the RDF is up > to date. > > Thanks > > Duncan > > -- > Duncan Hull > http://www.cs.man.ac.uk/~hulld/ > Phone: +44 (0) 161 275 0677 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From adf at ncgr.org Thu Nov 3 19:44:54 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Thu Nov 3 19:58:19 2005 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark and Martin- I can't resist jumping in here from somewhere out of left field (and without much time over the next week to engage very deeply in the discussion), BUT: it seems to me that the argument you are beginning to hash out here gets close to the issue that the semantic moby side of the world has with respect to moby services' MOBY-XML representation of data vs semantic moby's preference to represent the data (not just the ontologies) as RDF (using RDF/XML or some other RDF syntax). The position below that you ascribe to Martin concerning the non-essential nature of the objects would for the semantic web data representation approach be instead better characterized as a "multi-faceted essence"; that is to say that an object can belong to many classes and each of these "types" associated with the object may (or may not) imply a set of properties ("the stuff") to be expected of an instance of the type OR (conversely) an object that has a certain set of properties may be inferred to belong to a class defined in a certain way. The decision about what is "essential" is I believe one determined by the user of the information, and the best systems are those that allow the same "stuff" to be used in many different purposes (since there is no single type of user). I think it is true that MOBY objects can have multiple typing, by reusing the namespace id in a structure with a different "class tag" (apologies if I have the lingo a bit off, it's been a while for me); and yet, I think your insistence that the ISA determines the object's essence is somewhat indicative of the use of XML structure to have the data producer determine intended usage rather than allowing the data consumer to determine how it may be used. (If we wanted to make this discussion more concrete, I have been fooling around with a little OWL ontology ("owl-let") for properties representing mapping/sequence/feature type info; it is in the same conceptual space as your "genericsequence/virtualsequence/etc." stuff, and might be an instructive example of how the two approaches differ in practice.) My 2c, and not necessarily reflective of the opinions of others in the s-moby sphere, but I do think that this is one of the critical areas to resolve in order to be able to bring the two branches of the project back together. Whether or not RDF is appropriate as a representation of all pieces of a message is another question, but in terms of a data payload representation format, I think we should really give it some consideration if and when we are able to move forward on the long promised reunification of the two branches. RDF: it's not just for metadata! Andrew Farmer PS. I hope this message doesn't hit Martin's mailbox before he's had time for tea... ;) PPS I am not clear on the "rendering" issues you allude to at the end, but we have been having some debates around the issue of transmitting data in well-known text formats embedded within (or as some sort of attachment to) the RDF. I would be interested in hearing about your experiences with such things... On Thu, 3 Nov 2005, Mark Wilkinson wrote: > Okay, I have thought about this now, and discussed it with Eddie and Ben > for a while. I can see the way Martin is thinking, and it is certainly > different from how I have always "seen" MOBY Objects. > > Here's how the argument goes: > > Martin: MOBY Objects are just syntax, so there is no such thing as a > "core" data-type for MOBY objects. They don't have an "essense"! > Objects are just "stuff" > > Mark: Yes they do! The ISA hierarchy implies that an object has an > "essense". There are two ways to construct an AnnotatedFASTA object: > It can either inherit from FASTA, and add an Annotation, or it can > inherit from Annotation and add a FASTA. Under the new object creation > system, the syntactic outcome of these paths is identical, but they are > "qualitatively" different.... it is nonsensical to "FASTA an > Annotation", but it is sensible to "Annotate a FASTA". The "essense" of > the object is the FASTA sequence it contains, based on its ISA > hierarchy. The problem we have now is that, without querying the > ontology and traversing back to the most primitive object, I cannot know > which contained object represents the "essense" of my in-hand object > (i.e. the thing that I would MOST want to represent if I had to > represent that object in a hurry). > > It also causes a problem with rendering... a FASTA sequence and a > Genbank record are formatted strings. What happens now that we have > contained primitives is that you have to ask the parent tag about its > type before you know how to render the child tag. I can't render a > string containing a genbank record without paying attention to its > formatting, but I don't know that a String is a formatted string until I > ask the parent GenBankFlatfile object what it is... :-/ > > >>sigh<< > > I dunno... the world just got much harder. > > M > > > > > On Wed, 2005-11-02 at 17:51 -0800, Mark Wilkinson wrote: > > Hi Martin, > > > > I love using you as the bellweather for my own thoughts :-) You are > > seldom wrong, and delight in telling me when I am! ;-) > > > > I think I am starting to see your point - I had not been thinking of the > > object ontology in quite that way, but you've got me reconsidering now. > > I'm going to bring it up for discussion at my lab meeting tomorrow and > > try to hash-out with the local guys exactly why I feel the way I do, and > > whether or not there are any serious adverse effects to thinking about > > it your way. It certainly makes things easier to do it your way, though > > I wish now that we had had this discussion while Eddie was writing the > > database update script because I would have changed the way we > > approached it... > > > > Oh well... I guess that's why MOBY is still considered a research > > project ;-) > > > > Thanks for being so forthright in your opinons - you are an extremely > > valuable asset to the project! > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Andrew Farmer adf@ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From senger at ebi.ac.uk Thu Nov 3 21:36:04 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Nov 3 21:34:41 2005 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <78883846-6389-4B18-B334-8D0D3FFC1B04@mcw.edu> Message-ID: YES. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 3 21:59:00 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Nov 3 21:57:36 2005 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Message-ID: > Having said all that - there are two ways to get MOBY RDF. You can get > it from our RESOURCES script, or by LSID resolution to metadata. > Interesting is that Mark has not mentioned the only "offical" way how to get RDF: use Biomoby API! This gives you, however, back RDF of all services, not only the one you are interested in - so perhaps that's the reason why he has not mentioned it. (But I doubt it :-) - Mark never liked this part of the Moby API.) I am making jokes but I am also getting tired by the endless discussions about RDF and how to get it. Biomoby is killing itself by having so many ways, so many unofficial ways, and still none of them is working properly for years (yes, I am talking now about the RDF agent which is intrinsicaly connected with RDF...) Duncan, in jMoby, call: build/run/run-cmdline-clinet -rdf services -q > services.rdf and you will get all RDF for services. This is the only official way. Because: 1) going directly to URL > http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances > is an unofficial, never made official, hack. If you wish yo use this way, you should at least get the URL first uding Biomoby API, by calling: build/run/run-cmdline-client -lu Resource URLs: -------------- ServiceInstance http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances Object http://biomoby.org/RESOURCES/MOBY-S/Objects Service http://biomoby.org/RESOURCES/MOBY-S/Services Namespace http://biomoby.org/RESOURCES/MOBY-S/Namespaces Full http://biomoby.org/RESOURCES/MOBY-S/FULL 2) using > Or for a specific service, resolve the LSID: > urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName > suffers from the fact that Biomoby LSIDs were not yet documented properly: you do not know (now) if you should resolve it to data or metadata, and what to expect. As I said, tired from this stuff... Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Nov 4 00:37:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Nov 4 00:36:07 2005 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436AF39A.1030104@illuminae.com> >Biomoby is killing itself > In no way is that true, since only a very few people care right now if there is RDF in MOBY or not. > by >having so many ways, so many unofficial ways, and still none of them is >working properly for years (yes, I am talking now about the RDF agent >which is intrinsicaly connected with RDF...) > > The RDF itself has been changing because it is a new standard, and because it is important to get it right rather than ask people to change it every few months. The desire to adopt the same RDF representationas myGrid is laudible (in my opinion), however the myGrid RDF has also been changing, and still is. We have just sent the myGrid folks a copy of what we hope will be a mutually agreeable document. If they sign-off on it as well, then everything else is in place. > is an unofficial, never made official, hack. > I think Duncan got what he needed, through formal or informal means. These (non-API) features of MOBY are documented in part on the new website (http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/moby_metadata), however the full documentation will take considerable time to write, so it isn't complete. Having multiple ways of obtaining information is a good thing, since it gives people a lot of flexibility in how they build their code, so I don't see this as a legitimate criticism. > As I said, tired from this stuff... > > There are a wide variety of ways you can make the situation better, but bitching about it isn't one of them. M From senger at ebi.ac.uk Fri Nov 4 00:58:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Nov 4 00:56:42 2005 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <436AF39A.1030104@illuminae.com> Message-ID: Mark, I am not bitching around... I am trying to make Biomoby clear. It was always the major Biomoby problem: you have a good idea, but you are not so good at presenting it clearly. So other people must take care about that part. You have Frank to make your documentation more precise, and you have me to make your API design better useable. During the last developer meeting, we had concluded that Biomoby is good in its essence but it is badly presented, it is not a "production-level" product, it does not have proper releases, etc. And until this is done, I will continue to claim that "Biomoby is killing itself by not being a real, "from-the-shelf" product. It is not that it cannot change (after all, it was always a research project) but it should change in predicted or well defined intervals and in a usual form. For example, you should not mix "the contents of RDF" and "the way how to get this RDF". The way how to get it should be fixed and relatively unchanged for longer, the contents itself may be labelled as "not-yet-stable", so it can changed more often. But you do not support this if you do not stick always with the API you yourself created. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 4 01:37:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Nov 4 01:36:24 2005 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Message-ID: > Martin: MOBY Objects are just syntax, so there is no such thing as a > "core" data-type for MOBY objects. They don't have an "essense"! > Of course, the objects are just syntax (with semantics added by documentation). But let's not play with the words... What you are saying (IMHO) is that you like to have there also an additional attribute that would define an "essence". In your other email, you called it a "primary contents". You are also saying that two objects may have the same structure, but they can differ by this "primary contents" atribute. I can have an object X that has two members: FASTA and Annotation, and an object Y that has the same members. But Object X inherited from Annotation and added FASTA (because I am creating this object for analyzing various kind of annotations, for example), and the object Y inherited from FASTA and added Annotation as a member (because I am using Y for dealing with sequences). [This is what Andrew said about having multiple users of the same data. Yes, Andrew, I had my cup ot tea :-) ] You are right that to find the ISA hierarchy of objects X and Y you need to traverse back. The attribute "primary contents" would help you to find what you need without traversing back. But they may be other members (children) that you wish to know where they come from - so you would need (theoretically) more and more "essence" attributes. In other words, you may be interested in a complete hierarchy without traversing it back using a registry, but you do not have it because the Biomoby XML message is flatten! This situation is actually not a consequence of banning inheriting from primitives but a consequence of a unfortunate (flatten) design of Biomoby XML message from the beginning. (Now you know what I was bitching around, and lobbying in Vancouver meeting.) If the Biomoby message is a "usual" type of XML, you would have all. For example, and simplified, my X and Y objects would be: hello atata atata hello Just for the readers, what you have now is: hello atata hello atata Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From adf at ncgr.org Fri Nov 4 02:18:53 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Fri Nov 4 02:17:29 2005 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi again- I'm not sure I have completely grasped your example, but the point about XML hierarchy vs "flattening" is I think quite important. I can't speak to the MOBY object structure very much, but with the RDF-graph mentality, you don't flatten everything, i.e. paths between objects can be traversed via properties that connect them, though there is not a single root at which all paths must begin as with XML. My opinion is that the rootedness and guaranteed depth-first traversal of XML streams is quite nice when you are exchanging messages that are designed for a single purpose that is understood by sender and receiver; but, when the point is merely to represent data (not what is to be done with it), there is no reason to believe that one starting point is more privileged than another- this is IMHO one reason why relational dbs are so versatile and powerful. I might benefit from some clarification of your example. I can easily imagine a sensible case of a sequence with an annotation with a sequence (consider the translation of a CDS on a genomic sequence). The two sequences have different relationships to the annotation but are in themselves both the same type of thing (ignoring the protein/DNA difference). But, there is no reason I can see to treat them differently in terms of "hierarchy" until you provide a context for choosing the "root perspective". Have some more tea, I'm relieved that you haven't completely shut out those of us who can't help using the RDF-word... (sounds like there have been a lot of conversations I have been blissfully unaware of). Andrew > Of course, the objects are just syntax (with semantics added by > documentation). But let's not play with the words... > What you are saying (IMHO) is that you like to have there also an > additional attribute that would define an "essence". In your other email, > you called it a "primary contents". > You are also saying that two objects may have the same structure, but > they can differ by this "primary contents" atribute. I can have an object > X that has two members: FASTA and Annotation, and an object Y that has the > same members. But Object X inherited from Annotation and added FASTA > (because I am creating this object for analyzing various kind of > annotations, for example), and the object Y inherited from FASTA and added > Annotation as a member (because I am using Y for dealing with > sequences). [This is what Andrew said about having multiple users of the > same data. Yes, Andrew, I had my cup ot tea :-) ] > You are right that to find the ISA hierarchy of objects X and Y you > need to traverse back. The attribute "primary contents" would help you to > find what you need without traversing back. > But they may be other members (children) that you wish to know where > they come from - so you would need (theoretically) more and more "essence" > attributes. In other words, you may be interested in a complete hierarchy > without traversing it back using a registry, but you do not have it > because the Biomoby XML message is flatten! > This situation is actually not a consequence of banning inheriting from > primitives but a consequence of a unfortunate (flatten) design of Biomoby > XML message from the beginning. (Now you know what I was bitching around, > and lobbying in Vancouver meeting.) If the Biomoby message is a > "usual" type of XML, you would have all. For example, and simplified, my X > and Y objects would be: > > > hello > > atata > > > > > atata > > hello > > > > Just for the readers, what you have now is: > > > hello > atata > > > > hello > atata > > > Cheers, > Martin > > -- Andrew Farmer adf@ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From senger at ebi.ac.uk Fri Nov 4 02:43:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Nov 4 02:41:53 2005 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi, Nice to hear from you. Yout email helps to clarify the issues. They are (at least for now) two issues: rootedness (not mentioned in my neither Mark's emails) and flatteness. Rootedness (or not rootnedness) can be addressed by choosing pure XML message or RDF-based message. Flatteness is an issue only for pure XML messages (RDF is not flatten by default). So we have (beter: would have) three ways how to pass Biomoby messages: 1) Flatten traditional XML. This is the current situation in Moby-S. Because of this flatteness, Mark finds problems with not knowning the "primary contents" without traversing/contacting Biomoby registry. 2) Hierarchical traditional XML. This creates more complex messages but it is fully in the XML concepts. It carries all parental, ISA relationships. This is what Moby-S does not use. And there is no strong movement to this (except me advocating at least discussion about it). 3) RDF-based message. This would, additionally to not being flat, so keeping ISA hierarchy, add also non-rootedness. There is no discussion whether to move Moby-S this direction. My guess is that if we move Moby-S to any big changes regarding the message structure, it would probably be better to jump here and skip the "hierarchical traditional XML" structure. One last comment regarding rootedness: If you interpres a message, you always need to know when to start, so anyway you define a root node. This is the same for RDBS: you need to know which table to start with. So the rootedness is not about "not having a root" but about "having more roots than just one". But that is very probably what you meant anyway. > I might benefit from some clarification of your example. I can easily imagine > a sensible case of a sequence with an annotation with a sequence > I can clarify further, but it seems to me that you got it already right. Yes, your example is a better way to say what I was expressing. But please let me know if I can clarify better. > Have some more tea, I'm relieved that you haven't completely shut out those > of us who can't help using the RDF-word... > I am not against RDF. I am just against jumping to it without saying why. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Fri Nov 4 05:51:14 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Nov 4 05:49:56 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> Message-ID: <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> On 3-Nov-2005, at 5:18 PM, Mark Wilkinson wrote: > On Thu, 2005-11-03 at 12:17 +0100, Pieter Neerincx wrote: > > >> Forbidden > > All these that I can find are now fixed. Thanks! > I was paranoid last night and > switched off execute permissions on all folders in the CVS except for > the ones that I knew contained documentation because it makes me > nervous > having end-user-writable executable folders on our website! > > >> Furthermore I added a page to the Docs in the CVS some time ago, but >> I can not find it anywhere on the new website... > > where? It's in moby-live/Docs/Central/ Pieter > > M > > > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From Pieter.Neerincx at wur.nl Fri Nov 4 07:12:43 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Nov 4 07:11:22 2005 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <436A4AB5.6050903@cnb.uam.es> References: <436A4AB5.6050903@cnb.uam.es> Message-ID: <781B1075-CF65-4D12-B4A5-5C1AB925C3FF@wur.nl> Hi David, On 3-Nov-2005, at 6:36 PM, David Gonz?lez Pisano wrote: > > - Pieter (3/11/2005) - refArticlename - NOT INCLUDED. I know this > can open a new can of worms about whether articlenames should be > mandatory or not, and we have talked about this in the past. The > problem is not with the exception reporting proposal, but with the > MOBY specification itself: if Articlenames are not mandatory, and I > can send several elements to the same type to my service, how can I > differenciate them? If there is no need to differenciate them, or > that does not make sense from the point of view of the service > execution, then it makes no sense from the point of view of the > exception reporting. If I cannot identify them individually, then I > cannot report exceptions about them individually and thus I have to > say "There is a problem with one or more or the inputs" Good point. It's more clear to me now and I think what you describe above is the best solution for the current BioMOBY spec. > If I can differenciate them because they have an Articlename, then > I use the refElement tag to refer to the problematic element... If you ignore the element name and use the articleName attribute to point to specific elements I do think it makes more sense to name that attribute refArticleName instead of refElement though. Having the refElement attribute contain a articleName adds unnescessary confusion to the error reporting mix. Cheers, Pieter > Does this make sense? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From duncan.hull at cs.man.ac.uk Fri Nov 4 07:28:13 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri Nov 4 07:26:16 2005 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> Message-ID: <436B53DD.9070100@cs.man.ac.uk> Mark, Martin and Eddie Thank you all for your rapid and informative responses to my question, I now have what I need. I'd be interested to hear about the RDF updates Eddie is working on, so keep us posted. Mark Wilkinson wrote: > I hope you aren't writing another thesis saying nasty things about MOBY! I hope I've never said nasty things about MOBY, at least not while I was sober... I frequently say nasty things about RDF, but thats a seperate issue :) BTW: We're writing a paper for Dubya Dubya Dubya http://www2006.org/ and BioMOBY is a core part of the related work section, so I needed an RDF example for illustration. If the paper makes it into the 15% of submissions that get accepted, we can add it to the growing list of BioMOBY publications...fingers crossed. Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From markw at illuminae.com Fri Nov 4 09:31:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Nov 4 09:30:04 2005 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436B53DD.9070100@cs.man.ac.uk> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> <436B53DD.9070100@cs.man.ac.uk> Message-ID: <436B70BE.2090007@illuminae.com> Hi Duncan! > Thank you all for your rapid and informative responses to my question, > I now have what I need. I'd be interested to hear about the RDF > updates Eddie is working on, so keep us posted. I believe that the LSID resolver and the RESOURCES script are both now outputting our latest version of the Service Instance RDF. We're sending it to Pinar today along with the changes that are required in the myGrid ontology to make it compatible (i.e. things that we think are wrong in the myGrid ontology... cheeky buggers that we are!). Hopefully this will be useful to you in that you will be able to write a single tool to explore both registry systems for your research. >> I hope you aren't writing another thesis saying nasty things about MOBY! > > I hope I've never said nasty things about MOBY, at least not while I > was sober... :-) I know :-) Just teasing. > BTW: We're writing a paper for Dubya Dubya Dubya http://www2006.org/ > and BioMOBY is a core part of the related work section, so I needed an > RDF example for illustration. Excellent! > If the paper makes it into the 15% of submissions that get accepted, > we can add it to the growing list of BioMOBY publications...fingers > crossed. Excellent! Good luck! M > Duncan > From markw at illuminae.com Fri Nov 4 09:55:51 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Nov 4 09:54:19 2005 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436B70BE.2090007@illuminae.com> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> <436B53DD.9070100@cs.man.ac.uk> <436B70BE.2090007@illuminae.com> Message-ID: <436B7677.9010301@illuminae.com> > We're sending it to Pinar today along with the changes that are > required in the myGrid ontology to make it compatible (i.e. things > that we think are wrong in the myGrid ontology... cheeky buggers that > we are!). Of course, our suggestions may be complete rubbish... (sorry myGrid folks - the message about sounded MUCH funnier in my head than it came out on paper! :-) ) M > From akerhornou at imim.es Fri Nov 4 10:44:20 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri Nov 4 10:55:17 2005 Subject: [MOBY-dev] Registrying a moby service that takes an input collection Message-ID: <436B81D4.6040102@imim.es> Hi everyone, I want to register, at icapture registry, a moby service that takes a collection of DNASequence objects (the service is called 'runMatScanGFFCollection') The registration seems fine, but i get this message errors when trying to retrieve information from the registry (using a customised perl script of ours): -------------------------------> ../retrieveService.pl -x 4 -s runMatScanGFFCollection -w genome.imim.es * Name: runMatScanGFFCollection * Contact e-mail: akerhornou@imim.es * Provider: genome.imim.es * URL: http://genome.imim.es/cgi-bin/moby/MobyServices.cgi * Type: Analysis * Category: moby * Description: Promoter regions analysis program. Matscan is a program to search putative binding sites in genomic sequences. You can search for example the Transfac database, but also MEME or jaspar matrices. This service only accepts a collection of DNASequence objects and returns a collection of GFF objects (one GFF object for each DNASequence). If you want to give MatScan output to Meta-alignment program, you MUST use the 'log-likelihood matrix' mode. * Input: articleName: upstream_sequences collection of => articleName: objectType: DNASequence Use of uninitialized value in pattern match (m//) at /home/ug/arnau/cvs/moby-live/Perl/MOBY/Client/CollectionArticle.pm line 189. Use of uninitialized value in pattern match (m//) at /home/ug/arnau/cvs/moby-live/Perl/MOBY/Client/CollectionArticle.pm line 189. No such method: MOBY::Client::CollectionArticle::namespaces at ../retrieveService.pl line 162 <------------------------------------ Does it mean the registration has failed ? Anyway, the service is visible and i have also tried to execute it using taverna 1.3 and it fails (i have attached a workflow). i get this error, ERROR 2005-11-03 17:55:52,228 (org.biomoby.client.taverna.plugin.BiomobyTask:233) - Error invoking biomoby service for biomoby java.lang.ClassCastException at org.biomoby.client.taverna.plugin.BiomobyTask.execute(BiomobyTask.java:95) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenerateTemplates(ProcessorTask.java:462) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocationWithRetryLogic(ProcessorTask.java:407) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(ProcessorTask.java:329) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithoutIteration(ProcessorTask.java:521) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(ProcessorTask.java:261) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(ProcessorTask.java:199) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) Any idea why it fails ? thanks, Arnaud -------------- next part -------------- A non-text attachment was scrubbed... Name: iCapture_getUpstreamSeqfromEnsembl_MatScanCollection.xml Type: text/xml Size: 2754 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20051104/d9bbea1f/iCapture_getUpstreamSeqfromEnsembl_MatScanCollection.xml From markw at illuminae.com Fri Nov 4 11:00:24 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Nov 4 10:58:55 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> Message-ID: <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> > It's in moby-live/Docs/Central/ Perhaps move it into moby-live/Docs/MOBY-S_API where the other documents are. It's important to have them all in one place. That folder currently doesn't have an index.html file - only an index_API.html. If your document is API related, then you should add a link to it in the index_API.html file. If it isn't, then perhaps make an index.html file with appropriate links to both your document and to the index_API.html file. I'll change the links on the website to make it accessible. these are all in the CVS. M From markw at illuminae.com Fri Nov 4 11:05:52 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Nov 4 11:04:24 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436B81D4.6040102@imim.es> References: <436B81D4.6040102@imim.es> Message-ID: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> I'll address the first part... > <------------------------------------ > > Does it mean the registration has failed ? You need to check the return value of your registration attempt - a small XML object is returned to you that contans (among other things - see the API) a boolean 1/0 as to success or failure of your registration. Your registration was successful (I just checked the database). The client-side problem is a new one for me. I'll try to duplicate it here later. The Taverna problem I will leave to Eddie to answer (though I think I know what the answer is) M From adf at ncgr.org Fri Nov 4 11:16:09 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Fri Nov 4 11:14:46 2005 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi again- > One last comment regarding rootedness: If you interpres a message, you > always need to know when to start, so anyway you define a root node. This > is the same for RDBS: you need to know which table to start with. So the > rootedness is not about "not having a root" but about "having more roots > than just one". But that is very probably what you meant anyway. Well, not exactly. Certainly for RDBMS the theory is that the starting point(s) are irrelevant : which table to start with for a query involving joins is an implementation detail determined not by your query message but by the optimizer; similarly the row in a table that is processed first is immaterial to the sense of the query. In terms of serialization yes, you must pick a first element (otherwise it wouldn't be serial!), but RDF as a data model (not a concrete syntax) seems to be inherently about "random access"; e.g. the ability to ask for all resources having a given property (regardless of what class they belong to) is perhaps even more "unrooted" than RDBMs in which you clearly specify the tables to which your desired instances belong- but it is probably a wrong analogy to pair tables with classes- better would be to think of each property as its own two-element "relation". If pressed to comment on the actual practical implication of taking one attitude rather than another, my thoughts are not entirely clear, but I would claim that it has to do with thinking about "service descriptions" in part as defining queries that extract the data that they will process from a given dataset rather than defining message structures that they expect a client to formulate and send to them. The former approach is along the lines of the data-driven "dynamic discovery" idea of ISYS. This is also the direction I think semantic MOBY is in some ways trying to take. > I am not against RDF. I am just against jumping to it without saying > why. I am in whole-hearted agreement with that attitude. I feel the same way about XML ;) In all seriousness though, I think you are absolutely right to insist on conceptual clarity in these decisions and that there are areas in the MOBY problem space where RDF is NOT the right approach. Regards, -- Andrew Farmer adf@ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From edward.kawas at gmail.com Fri Nov 4 11:18:03 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri Nov 4 11:16:51 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninput collection In-Reply-To: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <000c01c5e15b$563059d0$6600a8c0@notebook> Hi, The problem is on the side of the service provider: They advertise a collection as the output, yet this is the output: 2000 TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGAAAG TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTTTTT AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGTAGG GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAAGTA AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAGTGG TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAGGGG CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAGACA AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAATCTG GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAGACA CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATGAAG TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACCTCT GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAGGCG CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATGTTG GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAAGTG CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGATTA CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTTTTT TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTTGGC TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGTAGT TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGGGTT TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGGCCT CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGTTTC TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCTAAG GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGGCAG CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGCGAG CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCCTTT TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCCACC GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTGCTC TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCTCCA GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGCTCC ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGAGTG TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGGCCC TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGGCCG AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCCCTG TCCGGCCAGCCCCTCGAAGC 2222:NCBI35:8:11695664:11697663:1 Not a collection. If you are the service provider, you must ensure that you output what you state that you will. Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Friday, November 04, 2005 8:06 AM > To: Arnaud Kerhornou; Core developer announcements > Subject: Re: [moby] [MOBY-dev] Registrying a moby service > that takes aninput collection > > I'll address the first part... > > > > > <------------------------------------ > > > > Does it mean the registration has failed ? > > You need to check the return value of your registration > attempt - a > small XML object is returned to you that contans (among > other things - > see the API) a boolean 1/0 as to success or failure of > your > registration. > > Your registration was successful (I just checked the > database). The > client-side problem is a new one for me. I'll try to > duplicate it here > later. > > The Taverna problem I will leave to Eddie to answer > (though I think I > know what the answer is) > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Fri Nov 4 11:01:33 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri Nov 4 11:19:31 2005 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436B85DD.7060907@cnb.uam.es> Hi everybody, I think Martin is right about a fixed and relatively unchanged way to obtain the RDF representation for each one of the registered services, objects and namespaces. If you are telling MOBY RDF structure is evolving, then RDF files published by any one of the service providers must be updated each time i changes. And also, there should be some well-known APIs (or procedures) to ease the automation of that process. Currently, the RDFs I have are from the Jurassic MOBY! Best Regards, Jos? Mar?a Martin Senger wrote: > Mark, > I am not bitching around... I am trying to make Biomoby clear. It was > always the major Biomoby problem: you have a good idea, but you are not so > good at presenting it clearly. So other people must take care about that > part. You have Frank to make your documentation more precise, and you have > me to make your API design better useable. > During the last developer meeting, we had concluded that Biomoby is > good in its essence but it is badly presented, it is not a > "production-level" product, it does not have proper releases, etc. And > until this is done, I will continue to claim that "Biomoby is killing > itself by not being a real, "from-the-shelf" product. > It is not that it cannot change (after all, it was always a research > project) but it should change in predicted or well defined intervals and > in a usual form. For example, you should not mix "the contents of RDF" and > "the way how to get this RDF". The way how to get it should be fixed and > relatively unchanged for longer, the contents itself may be labelled as > "not-yet-stable", so it can changed more often. But you do not support > this if you do not stick always with the API you yourself created. > > Martin > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From akerhornou at imim.es Fri Nov 4 11:16:37 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri Nov 4 11:27:20 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> References: <436B81D4.6040102@imim.es> <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <436B8965.9060705@imim.es> Mark Wilkinson wrote: >I'll address the first part... > > >><------------------------------------ >> >>Does it mean the registration has failed ? >> >> > >You need to check the return value of your registration attempt - a >small XML object is returned to you that contans (among other things - >see the API) a boolean 1/0 as to success or failure of your >registration. > > > it actually returned 1 >Your registration was successful (I just checked the database). The >client-side problem is a new one for me. I'll try to duplicate it here >later. > > > ok, thanks Arnaud >The Taverna problem I will leave to Eddie to answer (though I think I >know what the answer is) > >M > > > > > From akerhornou at imim.es Fri Nov 4 12:21:33 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri Nov 4 12:20:07 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninput collection In-Reply-To: <000c01c5e15b$563059d0$6600a8c0@notebook> References: <000c01c5e15b$563059d0$6600a8c0@notebook> Message-ID: <436B989D.8040108@imim.es> Hi Eddie, I'm the service provider of getUpstreamSeqfromEnsembl and i've checked the apache log file, and i get a collection back (giving a list of ensembl gene identifiers, 'ENSG00000160087' and 'ENSG00000160182' in a text-formatted object): 2000 ACCCGTGTAAATAAATCATGTCTCCCTAAAATGTATAAAAGCGAGCTGTGCCACATGCACCTTGGGCACCTCCCGAGATGTCATGGGTGTGTCCTTAACCTTGGCAAAACAAACTTTCTAAAGGGACTGAGACCTTCCTCAGTTTGCACCCTCCAGGCTGGGTTCTCTGTCCCTCAAGCATCCCCTGGCCAGACAATCCCTGCTGTTCAGAGGCAGCCAAGGCTTTCTGGTCCAACCCTGGGGGCTGGAGGAGGTGGGGGCAGGAGGTGGTAACTGGGTTGGGGGATGTTTTCTTGGTTGCCAAAGCAGAGGGTGCCCCCCGCTGCTCAAGATGCTGAGGGTGGTCCCTGTTGTCCTATTCCTGAAGCTGCCAGAGGAAGTCCCTCCGGAGGGCTGGCCCACAGCAGAAGGGCTGCTCCTGCCCTCAGAGGGCAATCTCAGGGTTGAGAAGGTTACAGCCACCATCTGCCACCAACCTAGCTGCTTGTGCCGATCCCACTGGCCAAGGCCATCGGCTCTATGGCTAGAGGCCTGGGCAGCCTGTGTCCTGCTTACCAGAAGGCCACAGATGCGGGTGGGTGGGGTGGTGGGGTCTTGGCAAGACGTGCTGGCCACACCTGTCCGGGGCACCTTCTCCCTGGGGTGTGACTCAGCCATGCTCCTGAGCAGGGGCCTCTGAGTTGAGCCTCGCTGCAGTCTTCCCAGCTGCAGGGCCCCCACAGGTGTGCTGTCATCGCACACTACTGAGGGACAGACAAGGCAGAGCGGGCCTCCATCTGCCGCGGGCCACAGCCGTGAGTGTGCATGCGAGTGGATGTGCTGGTGCCTGTATCTGCGGCCGGTGTGGCTTCCCTCACATAACTTTCCATGCTGTGAAAACAGTTTGGCCTGCCCTGCATGGGAACGGCAGAGGCCTGAGAGGAGGCAGAGGAAGGAGGCTGGATGCTGAGATGTTCTCCGAAGGTGGAGCCGGTGACGGCAGTAATGGAGGCAGGCTGGATTCCCACGGGCTGAGGCTGCGTGGACACTCCTCCTGGCTTCTGCCCCACGGCCTGCAGCAACGTCTCAGACCCACCAAGGTGTCCCAGAGGGCCAGAGTCAGGGCTGAGCATGGACACAGCCTGCCCTCTGCCCGTAGCCACAGCGGGACTGACCCTCAATATTCAGCCACCTTGCTGACCTGTGGTTGTTCCTGAGAGGCAGTCAGGGTTGGGGCAAAGGAGAGGGCCACAGGCAGCCAGGTGGCGAGGTCCACCTCCTGATCCCCCACCAGGGGACCACCCTCAGCTCCCCGCTGTCCTCAGCGGCCTCTCAGGGAGGCGGTGGGCTGCGCGCCTGCCCCCAGCGTCCCACCCCAGCGCCCCGCCACCTACCGCTCTCTCCCAATGTGTCTGGGGTCAGAGAGAGGTGGAGAGGACGCAGCGCCCCGCGCTTTCTGCAGTCTGTCCAAGGGGAGGTCAGGGGCATCCCGGGGCTGGGCAGGCACCTGCAGGGGAGGGTGCTGCGGCGCGGACGTGGGTTGCAAAGAGATGCCACGCGTGTCACTCTCGGGTCCCTGAACGAGAGAGCTCTGAGCTCCCTGGAGCCCAACCCTCCACTGAGCCTCCAGGGGCCCGGGACGCTCCATGCCCGGGCCGCGCCGCGCCTCCCCTAAGGGCCGGGTGGGGCGTGGGAGCGGAGGACAAGGCGGGAGCCGGGAGGCGGGAGGGTCGGGGTTCTTTCTCCACCGGGGTCGCCCTCAGCCGGGCCTGCCGCCCTGGGCCGTGGCACATGGGGAGGGAAGCGCGCGGCTTCGGGGTCTGGGGCTCTCGCGCCCACTAACGGTGCCCGGAGCCGCCCGCCAGTGCGCAAGCGCCGCCCCGCCCCCCGCCCCATCCCCCACCCCGGGGTCGACGGCGACAGAGAGTCGTGGGCGCGGTCCGCCAGTCTGCCTAGAGCGGCCAGCCCTCCCCCTCCCTCCTCACCGCCCCGGACCGCGCACCGGAAGCAGAAGCTAGGCT ENSG00000160087:NCBI35:1:1249158:1251157:-1 2000 GGACTTGAGCATTTGTGGATTTTGGCATCCCTGGGTGGGGGGTCCTGAAACCAGTCCCCCAGGGGTACTAAGGGACGACTGCATTGTATTTTAAGTTCATTTTCCCTTTCCCTGGTTAATGAATATTTATTTTGCTTTTCTTTCCCTCCTTTCCTTCCTTCCTTCTTTCCCTGTTTCCAGCTGTTACAAACAATGCTAAAAAGAATATCTTTGCCTGTGTTTTCTTCTGCCCAAGTATGAACATGTTTCTGGGATTAAGAGACCAGGCCTGGAAACAGAAGAATTTGCTGAGCTGTAAAATCTGTATGGCTTAAACCTCACCGAACACTGCCCACCTTTTCTCCAAATGATTGTGCAATTTACATCCCATTTCCAAGAGCCCCCATTTTGATCCGAGAAATTAGAGCAGCGAAAACCACCGTCACTATGAGCACCACCCTGGGCCTGGTGCCCCCGTCCTGTTTTCAATAAACTTAAGCTGACCACAGAGGACACCAGGCCTCGGCCCCTCCCTGGGTCCTGCGGTCAGGCCCCTCCTGGAGACCCTGGCCCAGGAGTGGAGACCCCGGTGCAGGAGTGGCAGCCCTGGAGGAGGGGCTGGGTCCTGGGATGGAGCGAAGAGGAACATGGCCGCCCCCATTCTGGCCCAGGCTCCCCTCCCAGAGGGGCTGCAGAAATGTACTGACTAGGTCACCCAAGAAAAGATAGTACCTTTGTTAGGCTAGCATGCATTTTCCTCAGGGCCTAATTTCTCACTGAAGAAGAAAAGATTTCTCCTGTTGTCCATTTCTTCATGCAGCTCTTCAACAGCTGTTTCTCGAATGCCAATCAAAGCCACTGTTCTAGGGTCTGGGGCCACCTCAAGGCACTAGGAGATGAGGACTTCTGCTCCCATGCGCCCTCCCGTCTGCTGCAGGGAGGAGTGCAATGAATAAATAACCAACATAATGTGTCAGTCACTTGTTTTATCCACCAGGAGGTAATAAGAGCTATGAAAGAGAAAGCTCCGAGCAGGGGAGGGGAGTGAGGCATGGTACAGGAGAGCAGGAGGCTGTCCTCTAAAATACAGGAGTCCAGGGGACCAACTGGGAAGGTGTGGGAGGGGGAGGGAGGGAGCCCCATAGACACAGGGGAGTGAACCACGTTCACTTTGTCAGTTTTTGATGGCAGCTCGTATATACTATTTTTTTCTCCCTCCTGCCCCCAGCCCCTCCCAGAAGGAGACTTAATCTGTCGCTCAGGCTGGAGTGCAGTAGGGTGATCTCGACTCACTGCAACCTCCGCCTCCCAGGTTCAAGTGATTCTCCTGACTTAACCTCCAGAGTAGCTAGGATTACAGGCACCCGCCACCATGCCTGGCTAATTTTTGTATTTTTTTTTTTTGTAGAGACGGGGTTTCGCCATGTTGGCCAGGCTAGTCTCAAACTCCTGACTTTAAGTGATCCGCCTGCTTTGGCCTCCCAAAGTGTTGGGATTACAGGCGTGAGCCACTGCGCCAGGCCTACAATTTCATTATTAAAACAATTCCACTGTAAAAGAATTAGCTTAGGCCTAGACGGAATGGGCTTCATGAGCTCCTTCCCTTCCCCCTGCAAGGTCACGGTGGCCACCCCGTGAGCCACTGTTGTCACGGCCAAGCCTTTTTCCGGCCATCTCTCACTATGAATCACTTCTGCAGTGAGTACAGTATTTACCCTGGCGGGAGGGCCTCTCAGATATGAGTAGGACCTGGATTAAGGTCAGGTTGGAGGAGACTCCCATGGGAAAGAGGGACTTTCTGAATCTCAGATCCCTCAGCCAAGATGACCTCACCACATGTCGTCTCTGTCTATCAGCAAATCCTTCCATGTAGCTTGACCATGTCTAGGAAACACCTTTGATAAAAATCAGTGGAGATTATTGTCTCAGAGGATCCCCGGGCCTCCTTAGGCAAATGTTATCTAACGCTCTTTAAGCAAACAGAGCCTGCCCTATAAAATCCGGGGCTCGGGCGGCCTCTC ENSG00000160182:NCBI35:21:42659714:42661713:-1 but you're right taverna displays a list of two simple DNASequence objects, so i don't understand what i am doing wrong ? cheers, Arnaud Edward Kawas wrote: >Hi, > >The problem is on the side of the service provider: > >They advertise a collection as the output, yet this is the >output: > > > > > > > > id="ENSG00000079459"> > namespace="" id="" articleName="Length"> >2000 > > namespace="" id="" articleName="SequenceString"> >TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGAAAG >TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTTTTT >AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGTAGG >GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAAGTA >AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAGTGG >TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAGGGG >CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAGACA >AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAATCTG >GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAGACA >CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATGAAG >TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACCTCT >GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAGGCG >CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATGTTG >GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAAGTG >CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGATTA >CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTTTTT >TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTTGGC >TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGTAGT >TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGGGTT >TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGGCCT >CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGTTTC >TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCTAAG >GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGGCAG >CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGCGAG >CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCCTTT >TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCCACC >GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTGCTC >TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCTCCA >GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGCTCC >ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGAGTG >TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGGCCC >TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGGCCG >AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCCCTG >TCCGGCCAGCCCCTCGAAGC > > namespace="" id="" articleName="Description"> >2222:NCBI35:8:11695664:11697663:1 > > > > > > > >Not a collection. > >If you are the service provider, you must ensure that you >output what you state that you will. > >Hope this helps, > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces@portal.open-bio.org [mailto:moby- >>dev-bounces@portal.open-bio.org] On Behalf Of Mark >>Wilkinson >>Sent: Friday, November 04, 2005 8:06 AM >>To: Arnaud Kerhornou; Core developer announcements >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service >>that takes aninput collection >> >>I'll address the first part... >> >> >> >> >> >>><------------------------------------ >>> >>>Does it mean the registration has failed ? >>> >>> >>You need to check the return value of your registration >>attempt - a >>small XML object is returned to you that contans (among >>other things - >>see the API) a boolean 1/0 as to success or failure of >>your >>registration. >> >>Your registration was successful (I just checked the >>database). The >>client-side problem is a new one for me. I'll try to >>duplicate it here >>later. >> >>The Taverna problem I will leave to Eddie to answer >>(though I think I >>know what the answer is) >> >>M >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From Pieter.Neerincx at wur.nl Fri Nov 4 12:23:02 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Nov 4 12:21:41 2005 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> Message-ID: <775C08CD-2DC3-42DB-85F6-0F2DE5D7F80F@wur.nl> Ok, will do that sometime this weekend ... On 4-Nov-2005, at 5:00 PM, Mark Wilkinson wrote: > >> It's in moby-live/Docs/Central/ > > Perhaps move it into moby-live/Docs/MOBY-S_API where the other > documents > are. It's important to have them all in one place. > > That folder currently doesn't have an index.html file - only an > index_API.html. If your document is API related, then you should > add a > link to it in the index_API.html file. If it isn't, then perhaps make > an index.html file with appropriate links to both your document and to > the index_API.html file. I'll change the links on the website to make > it accessible. > > these are all in the CVS. > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From edward.kawas at gmail.com Fri Nov 4 12:49:33 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri Nov 4 12:55:06 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninputcollection In-Reply-To: <436B989D.8040108@imim.es> Message-ID: <000d01c5e168$1e0bdef0$6600a8c0@notebook> Sorry, it turns out you did nothing wrong. You found a bug that I have fixed and will commit to the Taverna cvs as soon as I stop getting timeout errors. In the meantime, download the taverna1.3.jar from the following location: http://bioinfo.icapture.ubc.ca/ekawas/jars/ and replace the one in the taverna-workbench-1.3/lib directory. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Arnaud > Kerhornou > Sent: Friday, November 04, 2005 9:22 AM > To: Core developer announcements > Subject: Re: [moby] [MOBY-dev] Registrying a moby service > that takes aninputcollection > > Hi Eddie, > > I'm the service provider of getUpstreamSeqfromEnsembl and > i've checked > the apache log file, and i get a collection back (giving a > list of > ensembl gene identifiers, 'ENSG00000160087' and > 'ENSG00000160182' in a > text-formatted object): > > > moby:articleName='upstream_sequences'> > > namespace='ENSEMBL' id='ENSG00000160087'> > articleName="Length">2000 > articleName="SequenceString">ACCCGTGTAAATAAATCATGTCTCCCTAA > AATGTATAAAAGCGAGCTGTGCCACATGCACCTTGGGCACCTCCCGAGATGTCATGGG > TGTGTCCTTAACCTTGGCAAAACAAACTTTCTAAAGGGACTGAGACCTTCCTCAGTTT > GCACCCTCCAGGCTGGGTTCTCTGTCCCTCAAGCATCCCCTGGCCAGACAATCCCTGC > TGTTCAGAGGCAGCCAAGGCTTTCTGGTCCAACCCTGGGGGCTGGAGGAGGTGGGGGC > AGGAGGTGGTAACTGGGTTGGGGGATGTTTTCTTGGTTGCCAAAGCAGAGGGTGCCCC > CCGCTGCTCAAGATGCTGAGGGTGGTCCCTGTTGTCCTATTCCTGAAGCTGCCAGAGG > AAGTCCCTCCGGAGGGCTGGCCCACAGCAGAAGGGCTGCTCCTGCCCTCAGAGGGCAA > TCTCAGGGTTGAGAAGGTTACAGCCACCATCTGCCACCAACCTAGCTGCTTGTGCCGA > TCCCACTGGCCAAGGCCATCGGCTCTATGGCTAGAGGCCTGGGCAGCCTGTGTCCTGC > TTACCAGAAGGCCACAGATGCGGGTGGGTGGGGTGGTGGGGTCTTGGCAAGACGTGCT > GGCCACACCTGTCCGGGGCACCTTCTCCCTGGGGTGTGACTCAGCCATGCTCCTGAGC > AGGGGCCTCTGAGTTGAGCCTCGCTGCAGTCTTCCCAGCTGCAGGGCCCCCACAGGTG > TGCTGTCATCGCACACTACTGAGGGACAGACAAGGCAGAGCGGGCCTCCATCTGCCGC > GGGCCACAGCCGTGAGTGTGCATGCGAGTGGATGTGCTGGTGCCTGTATCTGCGGCCG > GTGTGGCTTCCCTCACATAACTTTCCATGCTGTGAAAACAGTTTGGCCTGCCCTGCAT > GGGAACGGCAGAGGCCTGAGAGGAGGCAGAGGAAGGAGGCTGGATGCTGAGATGTTCT > CCG! > AAGGTGGAGCCGGTGACGGCAGTAATGGAGGCAGGCTGGATTCCCACGGGCTGAGGCT > GCGTGGACACTCCTCCTGGCTTCTGCCCCACGGCCTGCAGCAACGTCTCAGACCCACC > AAGGTGTCCCAGAGGGCCAGAGTCAGGGCTGAGCATGGACACAGCCTGCCCTCTGCCC > GTAGCCACAGCGGGACTGACCCTCAATATTCAGCCACCTTGCTGACCTGTGGTTGTTC > CTGAGAGGCAGTCAGGGTTGGGGCAAAGGAGAGGGCCACAGGCAGCCAGGTGGCGAGG > TCCACCTCCTGATCCCCCACCAGGGGACCACCCTCAGCTCCCCGCTGTCCTCAGCGGC > CTCTCAGGGAGGCGGTGGGCTGCGCGCCTGCCCCCAGCGTCCCACCCCAGCGCCCCGC > CACCTACCGCTCTCTCCCAATGTGTCTGGGGTCAGAGAGAGGTGGAGAGGACGCAGCG > CCCCGCGCTTTCTGCAGTCTGTCCAAGGGGAGGTCAGGGGCATCCCGGGGCTGGGCAG > GCACCTGCAGGGGAGGGTGCTGCGGCGCGGACGTGGGTTGCAAAGAGATGCCACGCGT > GTCACTCTCGGGTCCCTGAACGAGAGAGCTCTGAGCTCCCTGGAGCCCAACCCTCCAC > TGAGCCTCCAGGGGCCCGGGACGCTCCATGCCCGGGCCGCGCCGCGCCTCCCCTAAGG > GCCGGGTGGGGCGTGGGAGCGGAGGACAAGGCGGGAGCCGGGAGGCGGGAGGGTCGGG > GTTCTTTCTCCACCGGGGTCGCCCTCAGCCGGGCCTGCCGCCCTGGGCCGTGGCACAT > GGGGAGGGAAGCGCGCGGCTTCGGGGTCTGGGGCTCTCGCGCCCACTAACGGTGCCCG > GAGCCGCCCGCCAGTGCGCAAGCGCCGCCCCGCCCCCCGCCCCATCCCCCACCCCGGG > GTCGACGGCGACAGAGAGTCGTGGGCGCGGTCCGCCAGTCTGCCTAGAGCGGCCAGCC > CTC! > CCCCTCCCTCCTCACCGCCCCGGACCGCGCACCGGAAGCAGAAGCTAGGCT g> > articleName="Description">ENSG00000160087:NCBI35:1:1249158 > :1251157:-1 > > > > namespace='ENSEMBL' id='ENSG00000160182'> > articleName="Length">2000 > articleName="SequenceString">GGACTTGAGCATTTGTGGATTTTGGCATC > CCTGGGTGGGGGGTCCTGAAACCAGTCCCCCAGGGGTACTAAGGGACGACTGCATTGT > ATTTTAAGTTCATTTTCCCTTTCCCTGGTTAATGAATATTTATTTTGCTTTTCTTTCC > CTCCTTTCCTTCCTTCCTTCTTTCCCTGTTTCCAGCTGTTACAAACAATGCTAAAAAG > AATATCTTTGCCTGTGTTTTCTTCTGCCCAAGTATGAACATGTTTCTGGGATTAAGAG > ACCAGGCCTGGAAACAGAAGAATTTGCTGAGCTGTAAAATCTGTATGGCTTAAACCTC > ACCGAACACTGCCCACCTTTTCTCCAAATGATTGTGCAATTTACATCCCATTTCCAAG > AGCCCCCATTTTGATCCGAGAAATTAGAGCAGCGAAAACCACCGTCACTATGAGCACC > ACCCTGGGCCTGGTGCCCCCGTCCTGTTTTCAATAAACTTAAGCTGACCACAGAGGAC > ACCAGGCCTCGGCCCCTCCCTGGGTCCTGCGGTCAGGCCCCTCCTGGAGACCCTGGCC > CAGGAGTGGAGACCCCGGTGCAGGAGTGGCAGCCCTGGAGGAGGGGCTGGGTCCTGGG > ATGGAGCGAAGAGGAACATGGCCGCCCCCATTCTGGCCCAGGCTCCCCTCCCAGAGGG > GCTGCAGAAATGTACTGACTAGGTCACCCAAGAAAAGATAGTACCTTTGTTAGGCTAG > CATGCATTTTCCTCAGGGCCTAATTTCTCACTGAAGAAGAAAAGATTTCTCCTGTTGT > CCATTTCTTCATGCAGCTCTTCAACAGCTGTTTCTCGAATGCCAATCAAAGCCACTGT > TCTAGGGTCTGGGGCCACCTCAAGGCACTAGGAGATGAGGACTTCTGCTCCCATGCGC > CCTCCCGTCTGCTGCAGGGAGGAGTGCAATGAATAAATAACCAACATAATGTGTCAGT > CAC! > TTGTTTTATCCACCAGGAGGTAATAAGAGCTATGAAAGAGAAAGCTCCGAGCAGGGGA > GGGGAGTGAGGCATGGTACAGGAGAGCAGGAGGCTGTCCTCTAAAATACAGGAGTCCA > GGGGACCAACTGGGAAGGTGTGGGAGGGGGAGGGAGGGAGCCCCATAGACACAGGGGA > GTGAACCACGTTCACTTTGTCAGTTTTTGATGGCAGCTCGTATATACTATTTTTTTCT > CCCTCCTGCCCCCAGCCCCTCCCAGAAGGAGACTTAATCTGTCGCTCAGGCTGGAGTG > CAGTAGGGTGATCTCGACTCACTGCAACCTCCGCCTCCCAGGTTCAAGTGATTCTCCT > GACTTAACCTCCAGAGTAGCTAGGATTACAGGCACCCGCCACCATGCCTGGCTAATTT > TTGTATTTTTTTTTTTTGTAGAGACGGGGTTTCGCCATGTTGGCCAGGCTAGTCTCAA > ACTCCTGACTTTAAGTGATCCGCCTGCTTTGGCCTCCCAAAGTGTTGGGATTACAGGC > GTGAGCCACTGCGCCAGGCCTACAATTTCATTATTAAAACAATTCCACTGTAAAAGAA > TTAGCTTAGGCCTAGACGGAATGGGCTTCATGAGCTCCTTCCCTTCCCCCTGCAAGGT > CACGGTGGCCACCCCGTGAGCCACTGTTGTCACGGCCAAGCCTTTTTCCGGCCATCTC > TCACTATGAATCACTTCTGCAGTGAGTACAGTATTTACCCTGGCGGGAGGGCCTCTCA > GATATGAGTAGGACCTGGATTAAGGTCAGGTTGGAGGAGACTCCCATGGGAAAGAGGG > ACTTTCTGAATCTCAGATCCCTCAGCCAAGATGACCTCACCACATGTCGTCTCTGTCT > ATCAGCAAATCCTTCCATGTAGCTTGACCATGTCTAGGAAACACCTTTGATAAAAATC > AGTGGAGATTATTGTCTCAGAGGATCCCCGGGCCTCCTTAGGCAAATGTTATCTAACG > CTC! > TTTAAGCAAACAGAGCCTGCCCTATAAAATCCGGGGCTCGGGCGGCCTCTC g> > articleName="Description">ENSG00000160182:NCBI35:21:426597 > 14:42661713:-1 > > > > > > > > but you're right taverna displays a list of two simple > DNASequence > objects, so i don't understand what i am doing wrong ? > > cheers, > Arnaud > > Edward Kawas wrote: > > >Hi, > > > >The problem is on the side of the service provider: > > > >They advertise a collection as the output, yet this is > the > >output: > > > > > > > > > > > > > > > > namespace="ENSEMBL" > >id="ENSG00000079459"> > > xmlns="http://www.biomoby.org/moby" > >namespace="" id="" articleName="Length"> > >2000 > > > > >namespace="" id="" articleName="SequenceString"> > >TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGA > AAG > >TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTT > TTT > >AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGT > AGG > >GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAA > GTA > >AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAG > TGG > >TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAG > GGG > >CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAG > ACA > >AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAAT > CTG > >GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAG > ACA > >CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATG > AAG > >TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACC > TCT > >GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAG > GCG > >CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATG > TTG > >GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAA > GTG > >CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGA > TTA > >CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTT > TTT > >TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTT > GGC > >TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGT > AGT > >TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGG > GTT > >TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGG > CCT > >CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGT > TTC > >TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCT > AAG > >GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGG > CAG > >CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGC > GAG > >CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCC > TTT > >TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCC > ACC > >GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTG > CTC > >TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCT > CCA > >GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGC > TCC > >ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGA > GTG > >TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGG > CCC > >TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGG > CCG > >AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCC > CTG > >TCCGGCCAGCCCCTCGAAGC > > > > >namespace="" id="" articleName="Description"> > >2222:NCBI35:8:11695664:11697663:1 > > > > > > > > > > > > > > > >Not a collection. > > > >If you are the service provider, you must ensure that you > >output what you state that you will. > > > >Hope this helps, > > > >Eddie > > > > > > > >>-----Original Message----- > >>From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > >>dev-bounces@portal.open-bio.org] On Behalf Of Mark > >>Wilkinson > >>Sent: Friday, November 04, 2005 8:06 AM > >>To: Arnaud Kerhornou; Core developer announcements > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby > service > >>that takes aninput collection > >> > >>I'll address the first part... > >> > >> > >> > >> > >> > >>><------------------------------------ > >>> > >>>Does it mean the registration has failed ? > >>> > >>> > >>You need to check the return value of your registration > >>attempt - a > >>small XML object is returned to you that contans (among > >>other things - > >>see the API) a boolean 1/0 as to success or failure of > >>your > >>registration. > >> > >>Your registration was successful (I just checked the > >>database). The > >>client-side problem is a new one for me. I'll try to > >>duplicate it here > >>later. > >> > >>The Taverna problem I will leave to Eddie to answer > >>(though I think I > >>know what the answer is) > >> > >>M > >> > >> > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev@biomoby.org > >>http://www.biomoby.org/mailman/listinfo/moby-dev > >> > >> > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev@biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Nov 4 16:41:50 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri Nov 4 16:40:28 2005 Subject: [moby] [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> Message-ID: <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> On 02Nov2005, at 17:12, Mark Wilkinson wrote: > I think you're right - that's a much better data structure to be > passing > around. > > This does change the external (perl client) API, right? :-/ Yep, that's why I'm asking. I have no idea who is currently relying on the retrieveObjectDefinition call and what might break if I change it... So far I have heard no complaints, so I suggest I go ahead and make the change... > > Really, what the Perl client code needs is a good laundering. The > CommonSubs.pm module is a total mess after being modified piecemeal > over > the past 3 years... > > I wonder if we shouldn't just start a new module (or modules) that are > named by their domain of function (RegistryIO, OntologyIO, or > something > like that) and have all fresh code? Gradually we could migrate all > functionality into these modules. Client::Central has been around > since > the 0.1 prototype of MOBY in 2001 and has never been re-written top- > to- > bottom! That would be a good idea to get cleaner code, but for the time being it's not that bad! It works as advertised and gets my job done :). Try debugging SOAP::Lite and MIME::Parser... those are the ones that really need a complete make-over! > > I'm still waiting to hear about the re-funding attempts for MOBY... > fingers crossed! There will hopefully be a second opportunity > later in > the winter, so all is not lost if we fail. Good luck! Pieter > It would be great to have a > couple of extra hands dedicated to a complete code re-write > > M > > > > > On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: >> Hi all, >> >> Here is a question for those using the Perl API. In >> >> MOBY/Client/Central.pm >> >> we have a >> >> sub retrieveObjectDefinition >> >> which calls >> >> sub _ObjectDefinitionPayload { >> >> This produces an array for the objects, articleNames and lsids for >> the relationships of the object whose definition is requested. I'm >> wondering why this is an array. Currently I have to rely on the order >> of elements in this array to figure out which element is the object, >> which one is articleName, etc. These are the lines producing the >> array: >> >> 553 push @{ $relationships{$relationshipType} }, >> 554 [ $_->toString, $article, $rlsid ]; >> >> Is there any reason why this should be an array? I'd rather not have >> to rely on the order of the elements, so are there people who have >> any objections when I change this into a hash like in: >> >> push @{ $relationships{$relationshipType} }, >> { object => $_->toString, >> articleName => $article, >> lsid => $rlsid }; >> >> Cheers, >> >> Pieter >> >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx@wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From senger at ebi.ac.uk Sat Nov 5 04:03:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Nov 5 04:01:48 2005 Subject: [MOBY-dev] Biomoby registry down? Message-ID: ...or it just not reachable from here at IRRI now? Thanks, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Sat Nov 5 06:56:27 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat Nov 5 06:55:07 2005 Subject: [MOBY-dev] Biomoby registry down? In-Reply-To: References: Message-ID: <9E523DCF-FFF4-4460-936D-D9A7841934AA@wur.nl> I get connection time-outs as well at WUR, so it looks like it's down :(. Pieter On 05Nov2005, at 10:03, Martin Senger wrote: > ...or it just not reachable from here at IRRI now? > > Thanks, > Martin > > -- > Martin Senger > email: martin.senger@gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From Phillip.Lord at newcastle.ac.uk Fri Nov 4 10:26:48 2005 From: Phillip.Lord at newcastle.ac.uk (Phillip Lord) Date: Sat Nov 5 10:10:36 2005 Subject: [MOBY-dev] Please sir, can I have some more RDF? Message-ID: <6942EE35B530F84EAD432959F5E4DAB581BF67@largo.campus.ncl.ac.uk> Mark Wilkinson wrote: >> We're sending it to Pinar today along with the changes that are >> required in the myGrid ontology to make it compatible (i.e. things >> that we think are wrong in the myGrid ontology... cheeky buggers that >> we are!). > > Of course, our suggestions may be complete rubbish... (sorry myGrid > folks - the message about sounded MUCH funnier in my head than it > came out on paper! :-) ) I thought it was funny on paper. Besides which, it's true. There are things wrong with the mygrid ontology! Phil From akerhornou at imim.es Mon Nov 7 10:37:59 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon Nov 7 10:36:33 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> Message-ID: <436F74D7.1010809@imim.es> Edward Kawas wrote: >Hi, > >This is happening, because Taverna is expecting an object >type of DNASequence, yet CommentedDNASequence is being >passed in. > > > okay, maybe i should have asked this before, the service returns CommentedDNASequence objects, and the service specs say DNASequence objects, but CommentedDNASequence is-a DNASequence. I designed the service to return DNASequence objects. Then a user asked me to add a description foreach sequence the service returns, so i just changed the type of object the service returns to CommentedDNASequence and I didn't changed the specification of the service because i thought i didn't have to. Does it mean it is not allowed to do so ? I have a similar problem with the next service in my workflow. This service analyzes DNASequence objects. But i get CommentedDNASequence objects from the retrieval service. Again i can not do that ? Arnaud >Eddie > > > >>-----Original Message----- >>From: Arnaud Kerhornou [mailto:akerhornou@imim.es] >>Sent: Monday, November 07, 2005 6:47 AM >>To: Edward Kawas >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service >>that takes an input collection >> >>ok, so i could modify my workflow to connect the >>DNASequence >>(Collection) output port to the input port of the next >>node. >> >>but why, in the case i use the port that says collection, >>do i get an >>empty collection tag, >> >>* "DNASequence (Collection)" gives me: >> >> >> >> >> > moby:articleName="upstream_sequences" /> >> >> >> >> >>why are the simples missing ? >> >>Arnaud >> >> >> >> > > From markw at illuminae.com Mon Nov 7 10:55:37 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Nov 7 10:54:06 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436F74D7.1010809@imim.es> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> <436F74D7.1010809@imim.es> Message-ID: <1131378937.15487.22.camel@bioinfo.icapture.ubc.ca> Strictly speaking, so long as you return an object that is an ISA child of what you have registered, you are compliant with the API. Having said that, if you *always* return a CommentedDNASequence, then you should probably re-register your service, since the intention is to register the most complex object type that you can guarantee to return in every case. Either way, you are API compliant, so if this is what is causing the problem, then it is a bug at our end. M On Mon, 2005-11-07 at 16:37 +0100, Arnaud Kerhornou wrote: > > Edward Kawas wrote: > > >Hi, > > > >This is happening, because Taverna is expecting an object > >type of DNASequence, yet CommentedDNASequence is being > >passed in. > > > > > > > okay, maybe i should have asked this before, the service returns > CommentedDNASequence objects, and the service specs say DNASequence > objects, but CommentedDNASequence is-a DNASequence. > > I designed the service to return DNASequence objects. Then a user asked > me to add a description foreach sequence the service returns, so i just > changed the type of object the service returns to CommentedDNASequence > and I didn't changed the specification of the service because i thought > i didn't have to. > > Does it mean it is not allowed to do so ? > > I have a similar problem with the next service in my workflow. This > service analyzes DNASequence objects. But i get CommentedDNASequence > objects from the retrieval service. Again i can not do that ? > > Arnaud > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Arnaud Kerhornou [mailto:akerhornou@imim.es] > >>Sent: Monday, November 07, 2005 6:47 AM > >>To: Edward Kawas > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service > >>that takes an input collection > >> > >>ok, so i could modify my workflow to connect the > >>DNASequence > >>(Collection) output port to the input port of the next > >>node. > >> > >>but why, in the case i use the port that says collection, > >>do i get an > >>empty collection tag, > >> > >>* "DNASequence (Collection)" gives me: > >> > >> > >> > >> > >> >> moby:articleName="upstream_sequences" /> > >> > >> > >> > >> > >>why are the simples missing ? > >> > >>Arnaud > >> > >> > >> > >> > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Nov 7 10:55:37 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Nov 7 10:54:07 2005 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436F74D7.1010809@imim.es> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> <436F74D7.1010809@imim.es> Message-ID: <1131378937.15487.22.camel@bioinfo.icapture.ubc.ca> Strictly speaking, so long as you return an object that is an ISA child of what you have registered, you are compliant with the API. Having said that, if you *always* return a CommentedDNASequence, then you should probably re-register your service, since the intention is to register the most complex object type that you can guarantee to return in every case. Either way, you are API compliant, so if this is what is causing the problem, then it is a bug at our end. M On Mon, 2005-11-07 at 16:37 +0100, Arnaud Kerhornou wrote: > > Edward Kawas wrote: > > >Hi, > > > >This is happening, because Taverna is expecting an object > >type of DNASequence, yet CommentedDNASequence is being > >passed in. > > > > > > > okay, maybe i should have asked this before, the service returns > CommentedDNASequence objects, and the service specs say DNASequence > objects, but CommentedDNASequence is-a DNASequence. > > I designed the service to return DNASequence objects. Then a user asked > me to add a description foreach sequence the service returns, so i just > changed the type of object the service returns to CommentedDNASequence > and I didn't changed the specification of the service because i thought > i didn't have to. > > Does it mean it is not allowed to do so ? > > I have a similar problem with the next service in my workflow. This > service analyzes DNASequence objects. But i get CommentedDNASequence > objects from the retrieval service. Again i can not do that ? > > Arnaud > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Arnaud Kerhornou [mailto:akerhornou@imim.es] > >>Sent: Monday, November 07, 2005 6:47 AM > >>To: Edward Kawas > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service > >>that takes an input collection > >> > >>ok, so i could modify my workflow to connect the > >>DNASequence > >>(Collection) output port to the input port of the next > >>node. > >> > >>but why, in the case i use the port that says collection, > >>do i get an > >>empty collection tag, > >> > >>* "DNASequence (Collection)" gives me: > >> > >> > >> > >> > >> >> moby:articleName="upstream_sequences" /> > >> > >> > >> > >> > >>why are the simples missing ? > >> > >>Arnaud > >> > >> > >> > >> > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Nov 7 11:04:45 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Nov 7 11:03:11 2005 Subject: [MOBY-dev] starting website redirect... Message-ID: <1131379485.15487.29.camel@bioinfo.icapture.ubc.ca> Hi MOBYers, I'm soon going to start re-directing HTTP traffic to the new website by default. This will give us the chance to port-over anything from the old site that we might have forgotten before it disappears. If there are things on the old site that you want/need, please grab them, or let me know and I'll grab them. Cheers! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Mon Nov 7 11:13:13 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Nov 7 11:11:41 2005 Subject: [MOBY-dev] starting website redirect... In-Reply-To: <1131379485.15487.29.camel@bioinfo.icapture.ubc.ca> Message-ID: > I'm soon going to start re-directing HTTP traffic to the new website by > default. This will give us the chance to port-over anything from the > old site that we might have forgotten before it disappears. > I lost the track... My feeling was that we are making a better web page. But now it seems that *in the same time* we are also changing a physical server. Is that correct? Is it also true that after moving to the new server, the new server will get (back) the old URL biomoby.org? > If there are things on the old site that you want/need, please grab > them, or let me know and I'll grab them. > With whom should I talked to give me enought priviledges to make the same what is cronning now for jMoby? And what time schedule for this should I plan? Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Nov 7 18:42:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Nov 7 18:40:35 2005 Subject: [MOBY-dev] jMoby (AGAIN!) not compilable Message-ID: Please, correct it asap - whoever committed file ServiceDescrParser.java. Nobody can work if this happens. Thanks, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Nov 9 17:10:19 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed Nov 9 17:18:26 2005 Subject: [MOBY-dev] rdf agent Message-ID: <003001c5e57a$604d32d0$6600a8c0@notebook> Hi, If anyone received any messages from the rdf agent, please disregard them! I was testing the agents ability to clone the registry and all services that were not (legal) may have caused the agent to send you a message. If you were affected, sorry about that. Sincerely, An extremely red in the face Eddie From markw at illuminae.com Wed Nov 9 18:07:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 9 18:06:07 2005 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <003001c5e57a$604d32d0$6600a8c0@notebook> References: <003001c5e57a$604d32d0$6600a8c0@notebook> Message-ID: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> They were all sent to me... thanks!!! ;-) M On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > Hi, > > If anyone received any messages from the rdf agent, please > disregard them! I was testing the agents ability to clone > the registry and all services that were not (legal) may have > caused the agent to send you a message. > > If you were affected, sorry about that. > > Sincerely, > > An extremely red in the face Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 9 18:07:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 9 18:06:09 2005 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <003001c5e57a$604d32d0$6600a8c0@notebook> References: <003001c5e57a$604d32d0$6600a8c0@notebook> Message-ID: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> They were all sent to me... thanks!!! ;-) M On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > Hi, > > If anyone received any messages from the rdf agent, please > disregard them! I was testing the agents ability to clone > the registry and all services that were not (legal) may have > caused the agent to send you a message. > > If you were affected, sorry about that. > > Sincerely, > > An extremely red in the face Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Nov 9 19:26:26 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 9 19:24:54 2005 Subject: [MOBY-dev] Moby registry down...? Message-ID: ...or just my corner-of-the-world network problem? Thanks for letting me know. Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 9 19:37:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Nov 9 19:36:16 2005 Subject: [MOBY-dev] Moby registry down...? In-Reply-To: Message-ID: Solved. Sorry to disturb you. Probablt just a small hiccup on our network. Works fine now. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Nov 9 19:05:42 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed Nov 9 20:52:14 2005 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> Message-ID: <003f01c5e58a$7eb3fe60$6600a8c0@notebook> Hi Mark, As an aside, there were over 320 services and about 174 made it (were legal). That has got to be good news! I think that the agent is good to go. I had to code the logic where a user submits a URL and the services are sucked into the registry. The only thing that I haven't done yet is add the rdf to the report. I will do this now and then try it out again (making sure that the email is sent to me ;-) ). Sounds like today may have been a good day after all! Eddie > -----Original Message----- > From: moby-dev-bounces@portal.open-bio.org [mailto:moby- > dev-bounces@portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Wednesday, November 09, 2005 3:08 PM > To: Core developer announcements > Cc: 'Moby Developers' > Subject: Re: [moby] [MOBY-dev] rdf agent > > They were all sent to me... > > thanks!!! ;-) > > M > > > On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > > Hi, > > > > If anyone received any messages from the rdf agent, > please > > disregard them! I was testing the agents ability to > clone > > the registry and all services that were not (legal) may > have > > caused the agent to send you a message. > > > > If you were affected, sorry about that. > > > > Sincerely, > > > > An extremely red in the face Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Sat Nov 12 08:15:05 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Nov 12 08:13:36 2005 Subject: [MOBY-dev] different types of results Message-ID: I wonder why moby register returned for two almost identical calls different result type: once a String, once an array of bytes: At the end of this message you will find two xml files, they differ only in the authority: senger@sherekhan:~/jMoby$ diff q1.xml q2.xml 11c11 < samples.jmoby.net --- > www.iris.irri.org 18d17 < When I call "findService" for authority samples.jmoby.net, I get results as a String. When I call it for www.iris.irri.org, I am getting it as an array of bytes. In both cases the contents of the reasult is correct but I wonder if this is the bug. Does it perhaps depend on the special unicode characters that are used in the services? (Not that I am awaee of any of those in these services.) I understand that biomoby services and clients are supposed to understand both String and byte arrays, but it was never (AFAIK) mentioned that also biomoby registry has this behaviour. I can fix it in jMoby (actually I am fixing it as I speak) but I think that such behaviour is not good. Any comment on that? Thanks, Martin q1.xml ------ moby samples.jmoby.net 1 1 0 q2.xml ------ moby www.iris.irri.org 1 1 0 -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Nov 12 16:38:51 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat Nov 12 16:53:19 2005 Subject: [MOBY-dev] different types of results In-Reply-To: References: Message-ID: <437660EB.9060604@illuminae.com> That's bizarre...??!? There is no reason for that to happen as far as I can tell. Both calls go through the same subroutine, and at least when they leave the MOBY Central code modules they are being returned as String's. I haven't had a chance to duplicate your result here (I'll try to get to that when I have finished what I am doing), but my first suspicon is that the SOAP::Lite library itself is somehow looking at the content of the document it is about to pass, and making the choice to send it one way or the other. Certainly the decision is not being made by MOBY code... I'll look into this more deeply later today. Hey Martin, we're almost in the same time-zone! Greetings from Sydney! Mark Martin Senger wrote: >I wonder why moby register returned for two almost identical calls >different result type: once a String, once an array of bytes: > >At the end of this message you will find two xml files, they differ only >in the authority: > >senger@sherekhan:~/jMoby$ diff q1.xml q2.xml >11c11 >< samples.jmoby.net >--- > > >>www.iris.irri.org >> >> >18d17 >< > >When I call "findService" for authority samples.jmoby.net, I get results >as a String. When I call it for www.iris.irri.org, I am getting it as an >array of bytes. > >In both cases the contents of the reasult is correct but I wonder if this >is the bug. Does it perhaps depend on the special unicode characters that >are used in the services? (Not that I am awaee of any of those in these >services.) > >I understand that biomoby services and clients are supposed to understand >both String and byte arrays, but it was never (AFAIK) mentioned that also >biomoby registry has this behaviour. I can fix it in jMoby (actually I am >fixing it as I speak) but I think that such behaviour is not good. Any >comment on that? > >Thanks, >Martin > >q1.xml >------ > > > > > > > > > >moby >samples.jmoby.net >1 >1 >0 > > > > >q2.xml >------ > > > > > > > > > >moby >www.iris.irri.org >1 >1 >0 > > > > > > > > From senger at ebi.ac.uk Sat Nov 12 22:25:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat Nov 12 22:24:05 2005 Subject: [MOBY-dev] different types of results In-Reply-To: <437660EB.9060604@illuminae.com> Message-ID: Hi to Sydney (and to others, as well, of course), > That's bizarre...??!? > We exchanged emails with Eddie about it yesterday. It seems that we all, Mark including, concluded that SOAP::Lite is the "culprit". I said it in quotes because actually SOAP::Lite tries to help. I found that some of the IRRI services used some (probably) non-ascii characters in the description - and that fact probably triggered SOAP::Lite to switch to byte array. I think that it could be switched off (using something like: SOAP::Data->type (string => $result) but perhaps it is a good think to have there byte array. Anyway, I have fixed the jMoby library (CentralImpl.java) so it accepts now both types. Still it is an interesting thing... Cheers, Martin PS: I love Sydney - I wish you the best there, and be prepared when you go home: Eddie has for you a present from us, the Richard's Moby group here in Los Banos... (Don't worry, nothing nasty...). M. -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Nov 12 22:27:24 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat Nov 12 22:31:41 2005 Subject: [MOBY-dev] different types of results Message-ID: <1749433976-1131852476-cardhu_blackberry.rim.net-23911-@engine19-cell01> I'm glad it wasn't me :-) M -----Original Message----- From: Martin Senger Date: Sun, 13 Nov 2005 03:25:14 To:Mark Wilkinson Cc:Moby Developers Subject: Re: [MOBY-dev] different types of results Hi to Sydney (and to others, as well, of course), > That's bizarre...??!? > We exchanged emails with Eddie about it yesterday. It seems that we all, Mark including, concluded that SOAP::Lite is the "culprit". I said it in quotes because actually SOAP::Lite tries to help. I found that some of the IRRI services used some (probably) non-ascii characters in the description - and that fact probably triggered SOAP::Lite to switch to byte array. I think that it could be switched off (using something like: SOAP::Data->type (string => $result) but perhaps it is a good think to have there byte array. Anyway, I have fixed the jMoby library (CentralImpl.java) so it accepts now both types. Still it is an interesting thing... Cheers, Martin PS: I love Sydney - I wish you the best there, and be prepared when you go home: Eddie has for you a present from us, the Richard's Moby group here in Los Banos... (Don't worry, nothing nasty...). M. -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Mon Nov 14 14:00:22 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon Nov 14 14:04:45 2005 Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <1864146826-1131994113-cardhu_blackberry.rim.net-30532-@engine20-cell01> Message-ID: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Hi, Mark and I were talking about what we feel is the need to create a CommonSubs interface that would be implemented in both Java and Perl. Currently, CommonSubs.pm has the following methods: genericServiceInputParser complexServiceInputParser getArticles genericServiceInputParserAsObject getSimpleArticleIDs getSimpleArticleNamespaceURI simpleResponse collectionResponse responseHeader responseFooter getInputs getInputID getArticlesAsObjects getCollectedSimples getInputArticles isSimpleArticle isCollectionArticle isSecondaryArticle extractRawContent getNodeContentWithArticle validateNamespaces validateThisNamespace getResponseArticles (a.k.a. extractResponseArticles) getServiceNotes getCrossReferences whichDeepestParentObject _rearrange (stolen from BioPerl ;-) ) The subroutine descriptions can be found at http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html We need functions that will, among other things: 1) Get enumerated invocations from an incoming message 2) Add enumerated outputs to an outgoing message 3) Add an error message to the header 4) Read error messages from the header 5) Extract individual inputs from an invocation... ... etc So this is a call out to service providers to tell us what functions they believe would be useful to have (i.e. make their lives much easier). Thanks, Eddie From senger at ebi.ac.uk Mon Nov 14 18:52:23 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Nov 14 18:56:35 2005 Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: > Mark and I were talking about what we feel is the need to > create a CommonSubs interface that would be implemented in > both Java and Perl. > In Java, it is implemented already. Regarding Perl, I was rather thinking about having a Perl version of Moses (generator of Perl modules representing services), but it is not high priority in my calendar at the moment. But Moses was designed very modularly, so it should not be that hard to generated Perl code. If anyone is willing to try I am happy to help... Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Tue Nov 15 04:15:02 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Nov 15 04:18:37 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: Hi Mark, I noticed that complexResponse is not listed in CommonSubs.html. I thought it might get created automatically from the comments/ descriptions in CommonSubs.pm..., but apparently it's not. Can I run some tool to recreate CommonSubs.html or do I have to add the description manually or...? Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but is in @EXPORT_OK", but it's not there either: our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); Without complexResponse it's no longer possible to send secondary articles back to a client :(. Cheers, Pieter On 14-Nov-2005, at 8:00 PM, Edward Kawas wrote: > Hi, > > Currently, CommonSubs.pm has the following methods: > > genericServiceInputParser > complexServiceInputParser > getArticles > genericServiceInputParserAsObject > getSimpleArticleIDs > getSimpleArticleNamespaceURI > simpleResponse > collectionResponse > responseHeader > responseFooter > getInputs > getInputID > getArticlesAsObjects > getCollectedSimples > getInputArticles > isSimpleArticle > isCollectionArticle > isSecondaryArticle > extractRawContent > getNodeContentWithArticle > validateNamespaces > validateThisNamespace > getResponseArticles (a.k.a. extractResponseArticles) > getServiceNotes > getCrossReferences > whichDeepestParentObject > _rearrange (stolen from BioPerl ;-) ) > > The subroutine descriptions can be found at > http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From Pieter.Neerincx at wur.nl Tue Nov 15 06:12:24 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Nov 15 06:20:22 2005 Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <505C05C8-65D7-45E6-AD7F-C96D65C3F946@wur.nl> Hi, On 14-Nov-2005, at 8:00 PM, Edward Kawas wrote: > Hi, > > Mark and I were talking about what we feel is the need to > create a CommonSubs interface that would be implemented in > both Java and Perl. Sounds like a good plan to me :). I'm not using the Python API, but wouldn't it be a good idea to do the same thing for Python as well then? > > Currently, CommonSubs.pm has the following methods: > > genericServiceInputParser > complexServiceInputParser > getArticles > genericServiceInputParserAsObject > getSimpleArticleIDs > getSimpleArticleNamespaceURI > simpleResponse > collectionResponse > responseHeader > responseFooter > getInputs > getInputID > getArticlesAsObjects > getCollectedSimples > getInputArticles > isSimpleArticle > isCollectionArticle > isSecondaryArticle > extractRawContent > getNodeContentWithArticle > validateNamespaces > validateThisNamespace > getResponseArticles (a.k.a. extractResponseArticles) > getServiceNotes > getCrossReferences > whichDeepestParentObject > _rearrange (stolen from BioPerl ;-) ) > > The subroutine descriptions can be found at > http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html > > We need functions that will, among other things: > > 1) Get enumerated invocations from an incoming > message > > 2) Add enumerated outputs to an outgoing message Currently (in Perl) we have 3 *ServiceInputParser functions and another 3 *Response functions. To keeps things simple I would rather like to see just 1 serviceInputParser and 1 serviceResponse function. The current complex* functions are not that hard to use :), the other ones are just crippled and don't support the complete BioMOBY specs. > 3) Add an error message to the header > > 4) Read error messages from the header Do you mean the SOAP header? In that case it would be good also to think of functions to handle errors in the ServiceNotes part. So far I have only seen votes in favour of RFC 1863 :). > > 5) Extract individual inputs from an invocation... > > ... The rest of what I need is already there :). My only problem with the current functions is that it doesn't work well for large objects due to DOM parsing. I know it's not going to be easy to change to stream or chunk based parsing, but if it would be possible to improve the scalability it would make my life even easier :). Just my 0.02 ?, Pieter > > etc > > So this is a call out to service providers to tell us what > functions they believe would be useful to have (i.e. make > their lives much easier). > > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From francis_gibbons at hms.harvard.edu Wed Nov 16 09:49:17 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Nov 16 09:56:32 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> Hi Pieter, >Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. >There is a comment "complexResponse is *not* here, but >is in @EXPORT_OK", but it's not there either: >our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); > >Without complexResponse it's no longer possible to send secondary >articles back to a client :(. I'm the one who put that comment in there. The code had two long lists containing almost the same things, but as you see, there was one component which was lacking. I guess I mistyped the name, putting "collectionResponse" instead of "complexResponse". My bad! One reason for the confusion is that as I was writing the unit tests, I just couldn't figure out what the purpose of complexResponse was, how it was different from collectionResponse. Now that I look at it again, it seems not so puzzling (I guess I was fairly punchy after writing so many tests), but it would help a great deal to have someone who actually uses write an explanation of why it's useful. CommonSubs contains lots of routines that appear almost identical in their functionality, yet are subtly different (for example, pulling out parts of the moby:MOBY message at different levels). We need good explanations for why it is useful to do each of these. How about this: I've fixed that line defining EXPORT_OK, and checked it back in. Could you add some useful explanation of complexReponse's purpose and usage to the POD? I'm thinking specifics - the current text is way too generic (e.g., "function: wraps articles in the appropriate (mobyData) structure") We also need an example showing what exactly this routine should do, so that we can add it to the test suite. If you want to just send me an example, I can construct the test. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Wed Nov 16 09:54:32 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Nov 16 10:01:47 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> Of course, I should also have asked why complexResponse was singled out in this way - why is it NOT in @EXPORT? Just a typo/omission? -Frank At 04:15 AM 11/15/2005, you wrote: >Hi Mark, > >I noticed that complexResponse is not listed in CommonSubs.html. I >thought it might get created automatically from the comments/ descriptions >in CommonSubs.pm..., but apparently it's not. Can I run >some tool to recreate CommonSubs.html or do I have to add the >description manually or...? > >Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. >There is a comment "complexResponse is *not* here, but >is in @EXPORT_OK", but it's not there either: >our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); > >Without complexResponse it's no longer possible to send secondary >articles back to a client :(. >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Wed Nov 16 17:38:44 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed Nov 16 17:37:01 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> Message-ID: <46FF29A8-FD3C-4EF6-AFDC-FECE0919553A@wur.nl> Hi Frank, On 16Nov2005, at 15:49, Frank Gibbons wrote: > Hi Pieter, > >> Furthermore in CommonSubs.pm complexResponse is gone from '% >> EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but >> is in @EXPORT_OK", but it's not there either: >> our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); >> >> Without complexResponse it's no longer possible to send secondary >> articles back to a client :(. > > I'm the one who put that comment in there. The code had two long > lists containing almost the same things, but as you see, there was > one component which was lacking. I guess I mistyped the name, > putting "collectionResponse" instead of "complexResponse". My bad! > > One reason for the confusion is that as I was writing the unit > tests, I just couldn't figure out what the purpose of > complexResponse was, how it was different from collectionResponse. > Now that I look at it again, it seems not so puzzling (I guess I > was fairly punchy after writing so many tests), but it would help a > great deal to have someone who actually uses write an explanation > of why it's useful. CommonSubs contains lots of routines that > appear almost identical in their functionality, yet are subtly > different (for example, pulling out parts of the moby:MOBY message > at different levels). We need good explanations for why it is > useful to do each of these. > > How about this: I've fixed that line defining EXPORT_OK, and > checked it back in. Thanks! > Could you add some useful explanation of complexReponse's purpose > and usage to the POD? I'm thinking specifics - the current text is > way too generic (e.g., "function: wraps articles in the appropriate > (mobyData) structure") Ok I'll add that. > We also need an example showing what exactly this routine should > do, so that we can add it to the test suite. If you want to just > send me an example, I can construct the test. I'll send you an example too... Cheers, Pi > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From Pieter.Neerincx at wur.nl Wed Nov 16 17:42:47 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed Nov 16 17:40:59 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> Message-ID: <0F7F19F4-5401-4FD1-9518-FCAFC225559C@wur.nl> On 16Nov2005, at 15:54, Frank Gibbons wrote: > Of course, I should also have asked why complexResponse was singled > out in this way - why is it NOT in @EXPORT? Just a typo/omission? That was puzzling me too. I think I put it there... at least I should have! I'll put it there now. If someone deliberately removed for whatever reason, please let me know. Pieter > -Frank > > At 04:15 AM 11/15/2005, you wrote: >> Hi Mark, >> >> I noticed that complexResponse is not listed in CommonSubs.html. I >> thought it might get created automatically from the comments/ >> descriptions in CommonSubs.pm..., but apparently it's not. Can I run >> some tool to recreate CommonSubs.html or do I have to add the >> description manually or...? >> >> Furthermore in CommonSubs.pm complexResponse is gone from '% >> EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but >> is in @EXPORT_OK", but it's not there either: >> our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); >> >> Without complexResponse it's no longer possible to send secondary >> articles back to a client :(. >> http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From edward.kawas at gmail.com Mon Nov 14 12:18:23 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri Nov 18 13:04:45 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object Message-ID: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Hi, I was unable to find a method that parses xml similar to the registerService (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY -S_API/XMLPayloads.html) xml and returns a MobyService object. I did notice the method in CentralImpl called extractServices(string) but the it parses a different message structure than the registerService xml. Does anyone know of a method that does what I need? Thanks, Eddie From gordonp at ucalgary.ca Fri Nov 18 13:13:06 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri Nov 18 13:59:52 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <002701c5e93f$6c3b3c40$6600a8c0@notebook> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Message-ID: <437E19B2.4050505@ucalgary.ca> > CentralImpl.findService CentralImpl.findService() obviously parses the XML at some point to give you the service object. Ah, yes. MobyServices[] CentralImpl.extractServices(String) >I was unable to find a method that parses xml similar to the >registerService >(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >-S_API/XMLPayloads.html) xml and returns a MobyService >object. > >I did notice the method in CentralImpl called >extractServices(string) but the it parses a different >message structure than the registerService xml. > >Does anyone know of a method that does what I need? > >Thanks, > >Eddie > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From gordonp at ucalgary.ca Fri Nov 18 14:53:44 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri Nov 18 14:51:48 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E19B2.4050505@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> Message-ID: <437E3148.9070105@ucalgary.ca> I am stupid. Time to go home for the weekend. :-) I don't think the method you are looking for exists in Java yet. > > > CentralImpl.findService() obviously parses the XML at some point to > give you the service object. > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > >> I was unable to find a method that parses xml similar to the >> registerService >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >> -S_API/XMLPayloads.html) xml and returns a MobyService >> object. >> >> I did notice the method in CentralImpl called >> extractServices(string) but the it parses a different >> message structure than the registerService xml. >> >> Does anyone know of a method that does what I need? >> >> Thanks, >> >> Eddie >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Fri Nov 18 14:09:18 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri Nov 18 15:02:57 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E19B2.4050505@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> Message-ID: Hi Paul, I did notice the method in CentralImpl called extractServices(string) but the it parses a different message structure than the registerService xml. Do you know of any others? Thanks, Eddie On 11/18/05, Paul Gordon wrote: > > > CentralImpl.findService > > > CentralImpl.findService() obviously parses the XML at some point to give > you the service object. > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > > >I was unable to find a method that parses xml similar to the > >registerService > >(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY > >-S_API/XMLPayloads.html) xml and returns a MobyService > >object. > > > >I did notice the method in CentralImpl called > >extractServices(string) but the it parses a different > >message structure than the registerService xml. > > > >Does anyone know of a method that does what I need? > > > >Thanks, > > > >Eddie > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev@biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From edward.kawas at gmail.com Fri Nov 18 14:56:21 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri Nov 18 15:21:30 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E3148.9070105@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> <437E3148.9070105@ucalgary.ca> Message-ID: Do you think that it is a useful method for me to create? I have my own use for it, but do you think that others would find it useful? Thanks, Eddie On 11/18/05, Paul Gordon wrote: > > I am stupid. Time to go home for the weekend. :-) > I don't think the method you are looking for exists in Java yet. > > > > > > > CentralImpl.findService() obviously parses the XML at some point to > > give you the service object. > > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > > > >> I was unable to find a method that parses xml similar to the > >> registerService > >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY > >> -S_API/XMLPayloads.html) xml and returns a MobyService > >> object. > >> > >> I did notice the method in CentralImpl called > >> extractServices(string) but the it parses a different > >> message structure than the registerService xml. > >> > >> Does anyone know of a method that does what I need? > >> > >> Thanks, > >> > >> Eddie > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev@biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From gordonp at ucalgary.ca Fri Nov 18 15:29:44 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri Nov 18 15:27:48 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> <437E3148.9070105@ucalgary.ca> Message-ID: <437E39B8.3020108@ucalgary.ca> If some one wants to implement moby central in Java, this would be very handy. To prepare for that eventuality, perhaps you could write this as a static method in a new server utility class, say org.biomoby.registry.requestParser or something of the like. >Do you think that it is a useful method for me to create? I have my own use >for it, but do you think that others would find it useful? > Thanks, > Eddie > > On 11/18/05, Paul Gordon wrote: > > >>I am stupid. Time to go home for the weekend. :-) >>I don't think the method you are looking for exists in Java yet. >> >> >> >>>CentralImpl.findService() obviously parses the XML at some point to >>>give you the service object. >>>Ah, yes. MobyServices[] CentralImpl.extractServices(String) >>> >>> >>> >>>>I was unable to find a method that parses xml similar to the >>>>registerService >>>>(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >>>>-S_API/XMLPayloads.html) xml and returns a MobyService >>>>object. >>>> >>>>I did notice the method in CentralImpl called >>>>extractServices(string) but the it parses a different >>>>message structure than the registerService xml. >>>> >>>>Does anyone know of a method that does what I need? >>>> >>>>Thanks, >>>> >>>>Eddie >>>> >>>>_______________________________________________ >>>>MOBY-dev mailing list >>>>MOBY-dev@biomoby.org >>>>http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev@biomoby.org >>>http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From senger at ebi.ac.uk Fri Nov 18 19:00:47 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Nov 18 18:59:01 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Message-ID: > I was unable to find a method that parses xml similar to the > registerService > jMoby does not contain stuff that is needed to write a biomoby register in Java; and the XML structure for 'registerService' is exactly that type of stuff: it has not use for clients, but only for server; if you are starting to add these things to jMoby, I suggest you create a new Java interface (e.g. Registry.java) in package org.biomoby.registry for that. But I am curious what you are working on that you need this... Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 18 19:03:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Nov 18 19:01:16 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E39B8.3020108@ucalgary.ca> Message-ID: Interestingly I have read this Paul's answer only I have sent my own answer, and I am pleased that we came to almost identical suggestion :-) > If some one wants to implement moby central in Java, this would be very > handy. To prepare for that eventuality, perhaps you could write this as > a static method in a new server utility class, say > org.biomoby.registry.requestParser or something of the like. > Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 18 19:23:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Nov 18 19:21:22 2005 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: Message-ID: > Interestingly I have read this Paul's answer only I have sent my own > answer, and I am pleased that we came to almost identical suggestion :-) > And more interestingly: I was wrong. There *is* such service in jMoby - because I needed it for biomoby dashboard (that will be announced next week). So last week I have extracted from the existing method registerService() this part and created in CentralImpl.java a new method public String getRegisterServiceXML (MobyService service) that does exactly what Eddie is looking for (the same was done for other moby entities, such as data types, service types and namespaces) as well. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 01:55:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun Nov 20 02:11:11 2005 Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: I am calling: retrieveServiceNames and I am getting back: ... Why are lsids empty? Could you fix it please? Thanks, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 11:21:56 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun Nov 20 11:19:59 2005 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: <4380A101.9040504@illuminae.com> Message-ID: > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 11:21:56 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun Nov 20 11:20:07 2005 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: <4380A101.9040504@illuminae.com> Message-ID: > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sun Nov 20 11:31:57 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun Nov 20 11:38:20 2005 Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: <443899406-1132504485-cardhu_blackberry.rim.net-29404-@engine18-cell01> My pleasure. Greetings from Vancouver airport! (thank goodness for wireless...) M -----Original Message----- From: Martin Senger Date: Sun, 20 Nov 2005 16:21:56 To:Mark Wilkinson Cc:Core developer announcements , Martin Senger , Moby Developers Subject: Re: [MOBY-dev] why a list of services does not have lsid filled? > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Sun Nov 20 11:31:57 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun Nov 20 11:38:23 2005 Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: <443899406-1132504485-cardhu_blackberry.rim.net-29404-@engine18-cell01> My pleasure. Greetings from Vancouver airport! (thank goodness for wireless...) M -----Original Message----- From: Martin Senger Date: Sun, 20 Nov 2005 16:21:56 To:Mark Wilkinson Cc:Core developer announcements , Martin Senger , Moby Developers Subject: Re: [MOBY-dev] why a list of services does not have lsid filled? > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Sun Nov 20 11:14:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun Nov 20 15:01:32 2005 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: References: Message-ID: <4380A101.9040504@illuminae.com> should be fixed now. Please confirm. I've also added a test for this case to the harness. M Martin Senger wrote: >I am calling: > retrieveServiceNames >and I am getting back: > > > > > >... > > >Why are lsids empty? Could you fix it please? > >Thanks, >Martin > > > From markw at illuminae.com Sun Nov 20 11:14:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun Nov 20 18:04:04 2005 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: References: Message-ID: <4380A101.9040504@illuminae.com> should be fixed now. Please confirm. I've also added a test for this case to the harness. M Martin Senger wrote: >I am calling: > retrieveServiceNames >and I am getting back: > > > > > >... > > >Why are lsids empty? Could you fix it please? > >Thanks, >Martin > > > From francis_gibbons at hms.harvard.edu Mon Nov 21 09:46:29 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Mon Nov 21 09:53:27 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <2121ED51-4164-4E48-9624-89239815D503@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Congratulations, Pieter, At 08:32 AM 11/21/2005, you wrote: >One more thing. After my changes I tried make test and noticed that >the Config.t is skipped, because it's only required for a local >BioMOBY Central..., but I do have one and I have set my >MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >familiar with the test scripts... I think you just got yourself nominated to be caretaker of the test t/Config.t. I don't have a local registry, so there was no way for me to test its operation. Most users (I think) are in the same position, so this test is skipped by default. For details on how to use the testing framework, you could look at the Perl modules Test::Simple and Test:More. The basic idea is that you execute some MOBY code for which you believe you know the output. You compare actual output to expected output using the is() function. It generates errors if the two don't match. You can also check for correct failure using isnt(), which generates a similar error. Examples might be: is(2+2, 4, "Can't do addition");' # Generates error with this string showing up on output device is(scalar @A, $#A + 1, "Scalar gives incorrect results"); Generally, tests should be symbolic, rather than specific. This leads to tests that are more easy to maintain over time: if an array is built before it is tested, and if it's tested symbolically, it should be possible to alter the array contents at a later point, without breaking that test. Take a look in the Client-Central.t for examples of this: a registration structure is created, services are registered, then the registration object is itself queried, and the results compared symbolically with the original data. This verifies that the information flows through the system correctly. If someone later decides to change a small detail (e.g., a parameter name), the tests should continue to pass without modification. But the tests themselves don't really have to complicated to be useful: check that each module exports the functions it claims to implement, check that set/get methods work correctly, check return types in all contexts (does it return array in list context, scalar in scalar context). All that stuff is important in maintaining a coherent interface over time. It also helps to find inconsistencies. I think it would be really great if you could build some useful, robust, portable tests for the local-registry configuration. This kind of test can be a big help to users trying to install their local registry, so its utility goes beyond merely regression testing the code, it's also useful to debugging local installations with perfectly functioning code. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Tue Nov 22 05:49:49 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Nov 22 05:48:01 2005 Subject: [MOBY-dev] Perl API: retrieveObjectDefinition and registerObjectClass call In-Reply-To: <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> Message-ID: <30E59CF1-9CA2-43A8-A219-AACCE4F03E0F@wur.nl> On 4-Nov-2005, at 10:41 PM, Pieter Neerincx wrote: > > On 02Nov2005, at 17:12, Mark Wilkinson wrote: > >> I think you're right - that's a much better data structure to be >> passing >> around. >> >> This does change the external (perl client) API, right? :-/ > > Yep, that's why I'm asking. I have no idea who is currently relying > on the retrieveObjectDefinition call and what might break if I > change it... So far I have heard no complaints, so I suggest I go > ahead and make the change... One more thing. The retrieveObjectDefinition function lists that it returns what you send it when you register an object. In that case it makes sense to change the registerObject a.k.a. registerObjectClass function as well. Summarising this would mean the following changes (changes marked with "->"): registerObject a.k.a registerObjectClass Usage : $REG = $MOBY->registerObject(%args) Usage : $REG = $MOBY->registerObjectClass(%args) Function : register a new type of MOBY Object Returns : MOBY::Registration object Args : objectType => "the name of the Object" description => "a human-readable description of the object" contactEmail => "your@email.address" authURI => "URI of the registrar of this object" OLD Relationships => { relationshipType1 => [ -> [Object1, articleName], -> [Object2, articleName] ], relationshipType2 => [ -> [Object3, articleName] ] } NEW Relationships => { relationshipType1 => [ -> {object => Object1, -> articleName => ArticleName1}, -> {object => Object2, -> articleName => ArticleName2} ], -> relationshipType2 => [ -> {object => Object3, -> articleName => ArticleName3} ] } retrieveObjectDefinition Usage : $DEF = $MOBY->retrieveObjectDefinition($objectType[, $registry]) Function : retrieve the $XML that was used to register an object and its relationships Returns : hashref, similar to the hash sent during Object registration, plus an additional XML hash key that contains the actual XML containing the object definition as sent by MOBY Central (used for a visual overview, rather than parsing all of the hash keys) objectType => "the name of the Object" objectLSID => "urn:lsid:..." description => "a human-readable description of the object" contactEmail => "your@email.address" authURI => "URI of the registrar of this object" OLD Relationships => { relationshipType1 => [ -> [Object1, articleName1, lsid1], -> [Object2, articleName2, lsid2] ], relationshipType2 => [ -> [Object1, articleName3, lsid3] ] } NEW Relationships => { relationshipType1 => [ -> {object => Object1, -> articleName => ArticleName1, -> lsid => lsid1}, -> {object => Object2, -> articleName => ArticleName2, -> lsid => lsid2} ], relationshipType2 => [ -> {object => Object3, -> articleName => ArticleName3, -> lsid => lsid3} ] } XML => <....XML of object registration.../> Args : objectType => the name or LSID URI for an object I have the necessary changes including those to Frank's tests standing by. If I don't receive any complaints during the next days I will commit these changes to the CVS on Friday... Cheers, Pieter > >> >> Really, what the Perl client code needs is a good laundering. The >> CommonSubs.pm module is a total mess after being modified >> piecemeal over >> the past 3 years... >> >> I wonder if we shouldn't just start a new module (or modules) that >> are >> named by their domain of function (RegistryIO, OntologyIO, or >> something >> like that) and have all fresh code? Gradually we could migrate all >> functionality into these modules. Client::Central has been around >> since >> the 0.1 prototype of MOBY in 2001 and has never been re-written >> top-to- >> bottom! > > That would be a good idea to get cleaner code, but for the time > being it's not that bad! It works as advertised and gets my job > done :). Try debugging SOAP::Lite and MIME::Parser... those are the > ones that really need a complete make-over! > >> >> I'm still waiting to hear about the re-funding attempts for MOBY... >> fingers crossed! There will hopefully be a second opportunity >> later in >> the winter, so all is not lost if we fail. > > Good luck! > > Pieter > >> It would be great to have a >> couple of extra hands dedicated to a complete code re-write >> >> M >> >> >> >> >> On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: >>> Hi all, >>> >>> Here is a question for those using the Perl API. In >>> >>> MOBY/Client/Central.pm >>> >>> we have a >>> >>> sub retrieveObjectDefinition >>> >>> which calls >>> >>> sub _ObjectDefinitionPayload { >>> >>> This produces an array for the objects, articleNames and lsids for >>> the relationships of the object whose definition is requested. I'm >>> wondering why this is an array. Currently I have to rely on the >>> order >>> of elements in this array to figure out which element is the object, >>> which one is articleName, etc. These are the lines producing the >>> array: >>> >>> 553 push @{ $relationships{$relationshipType} }, >>> 554 [ $_->toString, $article, $rlsid ]; >>> >>> Is there any reason why this should be an array? I'd rather not have >>> to rely on the order of the elements, so are there people who have >>> any objections when I change this into a hash like in: >>> >>> push @{ $relationships{$relationshipType} }, >>> { object => $_->toString, >>> articleName => $article, >>> lsid => $rlsid }; >>> >>> Cheers, >>> >>> Pieter >>> >>> >>> >>> >>> Wageningen University and Research centre (WUR) >>> Laboratory of Bioinformatics >>> Transitorium (building 312) room 1034 >>> Dreijenlaan 3 >>> 6703 HA Wageningen >>> The Netherlands >>> phone: 0317-483 060 >>> fax: 0317-483 584 >>> mobile: 06-143 66 783 >>> pieter.neerincx@wur.nl >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >> -- >> "Ontologists do it with the edges!" >> >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1038 > Dreijenlaan 3 > 6703 HA Wageningen > phone: 0317-484 706 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From markw at illuminae.com Tue Nov 22 08:01:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Nov 22 08:34:43 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <438316A6.6040204@illuminae.com> I just changed the code on my own t/* to use environment variables while I was on the plane yesterday so that I could run tests on my own Windows installation - funny that we were all looking at the same piece of code at the same time :-) i'll commit these changes as soon as I have double-checked them. In general it will allow you to test your local registry instead of the remote one by default. M Frank Gibbons wrote: > Congratulations, Pieter, > > At 08:32 AM 11/21/2005, you wrote: > >> One more thing. After my changes I tried make test and noticed that >> the Config.t is skipped, because it's only required for a local >> BioMOBY Central..., but I do have one and I have set my >> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> familiar with the test scripts... > > > I think you just got yourself nominated to be caretaker of the test > t/Config.t. I don't have a local registry, so there was no way for me > to test its operation. Most users (I think) are in the same position, > so this test is skipped by default. > > For details on how to use the testing framework, you could look at > the Perl modules Test::Simple and Test:More. The basic idea is that > you execute some MOBY code for which you believe you know the output. > You compare actual output to expected output using the is() function. > It generates errors if the two don't match. You can also check for > correct failure using isnt(), which generates a similar error. > Examples might be: > > is(2+2, 4, "Can't do addition");' # Generates error with this string > showing up on output device > is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > Generally, tests should be symbolic, rather than specific. This leads > to tests that are more easy to maintain over time: if an array is > built before it is tested, and if it's tested symbolically, it should > be possible to alter the array contents at a later point, without > breaking that test. Take a look in the Client-Central.t for examples > of this: a registration structure is created, services are registered, > then the registration object is itself queried, and the results > compared symbolically with the original data. This verifies that the > information flows through the system correctly. If someone later > decides to change a small detail (e.g., a parameter name), the tests > should continue to pass without modification. > > But the tests themselves don't really have to complicated to be > useful: check that each module exports the functions it claims to > implement, check that set/get methods work correctly, check return > types in all contexts (does it return array in list context, scalar in > scalar context). All that stuff is important in maintaining a coherent > interface over time. It also helps to find inconsistencies. > > I think it would be really great if you could build some useful, > robust, portable tests for the local-registry configuration. This kind > of test can be a big help to users trying to install their local > registry, so its utility goes beyond merely regression testing the > code, it's also useful to debugging local installations with perfectly > functioning code. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From markw at illuminae.com Tue Nov 22 08:01:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Nov 22 08:34:49 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <438316A6.6040204@illuminae.com> I just changed the code on my own t/* to use environment variables while I was on the plane yesterday so that I could run tests on my own Windows installation - funny that we were all looking at the same piece of code at the same time :-) i'll commit these changes as soon as I have double-checked them. In general it will allow you to test your local registry instead of the remote one by default. M Frank Gibbons wrote: > Congratulations, Pieter, > > At 08:32 AM 11/21/2005, you wrote: > >> One more thing. After my changes I tried make test and noticed that >> the Config.t is skipped, because it's only required for a local >> BioMOBY Central..., but I do have one and I have set my >> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> familiar with the test scripts... > > > I think you just got yourself nominated to be caretaker of the test > t/Config.t. I don't have a local registry, so there was no way for me > to test its operation. Most users (I think) are in the same position, > so this test is skipped by default. > > For details on how to use the testing framework, you could look at > the Perl modules Test::Simple and Test:More. The basic idea is that > you execute some MOBY code for which you believe you know the output. > You compare actual output to expected output using the is() function. > It generates errors if the two don't match. You can also check for > correct failure using isnt(), which generates a similar error. > Examples might be: > > is(2+2, 4, "Can't do addition");' # Generates error with this string > showing up on output device > is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > Generally, tests should be symbolic, rather than specific. This leads > to tests that are more easy to maintain over time: if an array is > built before it is tested, and if it's tested symbolically, it should > be possible to alter the array contents at a later point, without > breaking that test. Take a look in the Client-Central.t for examples > of this: a registration structure is created, services are registered, > then the registration object is itself queried, and the results > compared symbolically with the original data. This verifies that the > information flows through the system correctly. If someone later > decides to change a small detail (e.g., a parameter name), the tests > should continue to pass without modification. > > But the tests themselves don't really have to complicated to be > useful: check that each module exports the functions it claims to > implement, check that set/get methods work correctly, check return > types in all contexts (does it return array in list context, scalar in > scalar context). All that stuff is important in maintaining a coherent > interface over time. It also helps to find inconsistencies. > > I think it would be really great if you could build some useful, > robust, portable tests for the local-registry configuration. This kind > of test can be a big help to users trying to install their local > registry, so its utility goes beyond merely regression testing the > code, it's also useful to debugging local installations with perfectly > functioning code. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From Pieter.Neerincx at wur.nl Tue Nov 22 08:50:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue Nov 22 08:48:45 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <438316A6.6040204@illuminae.com> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> Message-ID: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > I just changed the code on my own t/* to use environment variables > while I was on the plane yesterday so that I could run tests on my > own Windows installation - funny that we were all looking at the > same piece of code at the same time :-) > > i'll commit these changes as soon as I have double-checked them. > In general it will allow you to test your local registry instead of > the remote one by default. That's cool! I'm looking forward to test the tests :) Pieter > > M > > > > Frank Gibbons wrote: > >> Congratulations, Pieter, >> >> At 08:32 AM 11/21/2005, you wrote: >> >>> One more thing. After my changes I tried make test and noticed that >>> the Config.t is skipped, because it's only required for a local >>> BioMOBY Central..., but I do have one and I have set my >>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>> familiar with the test scripts... >> >> >> I think you just got yourself nominated to be caretaker of the >> test t/Config.t. I don't have a local registry, so there was no >> way for me to test its operation. Most users (I think) are in the >> same position, so this test is skipped by default. >> >> For details on how to use the testing framework, you could look >> at the Perl modules Test::Simple and Test:More. The basic idea is >> that you execute some MOBY code for which you believe you know the >> output. You compare actual output to expected output using the is >> () function. It generates errors if the two don't match. You can >> also check for correct failure using isnt(), which generates a >> similar error. Examples might be: >> >> is(2+2, 4, "Can't do addition");' # Generates error with this >> string showing up on output device >> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> >> Generally, tests should be symbolic, rather than specific. This >> leads to tests that are more easy to maintain over time: if an >> array is built before it is tested, and if it's tested >> symbolically, it should be possible to alter the array contents at >> a later point, without breaking that test. Take a look in the >> Client-Central.t for examples of this: a registration structure is >> created, services are registered, then the registration object is >> itself queried, and the results compared symbolically with the >> original data. This verifies that the information flows through >> the system correctly. If someone later decides to change a small >> detail (e.g., a parameter name), the tests should continue to pass >> without modification. >> >> But the tests themselves don't really have to complicated to be >> useful: check that each module exports the functions it claims to >> implement, check that set/get methods work correctly, check return >> types in all contexts (does it return array in list context, >> scalar in scalar context). All that stuff is important in >> maintaining a coherent interface over time. It also helps to find >> inconsistencies. >> >> I think it would be really great if you could build some useful, >> robust, portable tests for the local-registry configuration. This >> kind of test can be a big help to users trying to install their >> local registry, so its utility goes beyond merely regression >> testing the code, it's also useful to debugging local >> installations with perfectly functioning code. >> >> -Frank >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: 617-432-3557 http:// >> llama.med.harvard.edu/~fgibbons >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx@wur.nl From markw at illuminae.com Tue Nov 22 15:09:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 23 08:59:37 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43837AFE.5010901@illuminae.com> Hmmmm... there's still a dependency on the public ontologyserver though... and therefore a dependency on having a network connection. I remember now that this is somethign I wanted to fix a couple of months ago but it got pushed down my TO DO list in favor of keeping my job ;-) I'll try to fix that today - it will make the PlaNet people happy as well! :-) M Pieter Neerincx wrote: > > On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > >> I just changed the code on my own t/* to use environment variables >> while I was on the plane yesterday so that I could run tests on my >> own Windows installation - funny that we were all looking at the >> same piece of code at the same time :-) >> >> i'll commit these changes as soon as I have double-checked them. In >> general it will allow you to test your local registry instead of the >> remote one by default. > > > That's cool! I'm looking forward to test the tests :) > > Pieter > >> >> M >> >> >> >> Frank Gibbons wrote: >> >>> Congratulations, Pieter, >>> >>> At 08:32 AM 11/21/2005, you wrote: >>> >>>> One more thing. After my changes I tried make test and noticed that >>>> the Config.t is skipped, because it's only required for a local >>>> BioMOBY Central..., but I do have one and I have set my >>>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>> familiar with the test scripts... >>> >>> >>> >>> I think you just got yourself nominated to be caretaker of the test >>> t/Config.t. I don't have a local registry, so there was no way for >>> me to test its operation. Most users (I think) are in the same >>> position, so this test is skipped by default. >>> >>> For details on how to use the testing framework, you could look at >>> the Perl modules Test::Simple and Test:More. The basic idea is that >>> you execute some MOBY code for which you believe you know the >>> output. You compare actual output to expected output using the is () >>> function. It generates errors if the two don't match. You can also >>> check for correct failure using isnt(), which generates a similar >>> error. Examples might be: >>> >>> is(2+2, 4, "Can't do addition");' # Generates error with this >>> string showing up on output device >>> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >>> >>> Generally, tests should be symbolic, rather than specific. This >>> leads to tests that are more easy to maintain over time: if an >>> array is built before it is tested, and if it's tested >>> symbolically, it should be possible to alter the array contents at >>> a later point, without breaking that test. Take a look in the >>> Client-Central.t for examples of this: a registration structure is >>> created, services are registered, then the registration object is >>> itself queried, and the results compared symbolically with the >>> original data. This verifies that the information flows through the >>> system correctly. If someone later decides to change a small detail >>> (e.g., a parameter name), the tests should continue to pass without >>> modification. >>> >>> But the tests themselves don't really have to complicated to be >>> useful: check that each module exports the functions it claims to >>> implement, check that set/get methods work correctly, check return >>> types in all contexts (does it return array in list context, scalar >>> in scalar context). All that stuff is important in maintaining a >>> coherent interface over time. It also helps to find inconsistencies. >>> >>> I think it would be really great if you could build some useful, >>> robust, portable tests for the local-registry configuration. This >>> kind of test can be a big help to users trying to install their >>> local registry, so its utility goes beyond merely regression >>> testing the code, it's also useful to debugging local installations >>> with perfectly functioning code. >>> >>> -Frank >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: 617-432-3557 http:// >>> llama.med.harvard.edu/~fgibbons >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From francis_gibbons at hms.harvard.edu Wed Nov 23 10:01:23 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Nov 23 09:56:20 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <438316A6.6040204@illuminae.com> References: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> At 08:01 AM 11/22/2005, you wrote: >I just changed the code on my own t/* to use environment variables while I >was on the plane yesterday so that I could run tests on my own Windows >installation - funny that we were all looking at the same piece of code at >the same time :-) > >i'll commit these changes as soon as I have double-checked them. In >general it will allow you to test your local registry instead of the >remote one by default. So Mark, if I understand correctly, it should first check to see if the user has defined those environment variables. That should indicate that the user does have a local registry. It should a local registry if available, but fall back to using MOBY Central if it's not available. Right? That'd be awsome! -Frank >M > > > >Frank Gibbons wrote: > >>Congratulations, Pieter, >> >>At 08:32 AM 11/21/2005, you wrote: >> >>>One more thing. After my changes I tried make test and noticed that >>>the Config.t is skipped, because it's only required for a local >>>BioMOBY Central..., but I do have one and I have set my >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>familiar with the test scripts... >> >> >>I think you just got yourself nominated to be caretaker of the test >>t/Config.t. I don't have a local registry, so there was no way for me to >>test its operation. Most users (I think) are in the same position, so >>this test is skipped by default. >> >>For details on how to use the testing framework, you could look at >>the Perl modules Test::Simple and Test:More. The basic idea is that you >>execute some MOBY code for which you believe you know the output. You >>compare actual output to expected output using the is() function. It >>generates errors if the two don't match. You can also check for correct >>failure using isnt(), which generates a similar error. Examples might be: >> >>is(2+2, 4, "Can't do addition");' # Generates error with this string >>showing up on output device >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> >>Generally, tests should be symbolic, rather than specific. This leads to >>tests that are more easy to maintain over time: if an array is built >>before it is tested, and if it's tested symbolically, it should be >>possible to alter the array contents at a later point, without breaking >>that test. Take a look in the Client-Central.t for examples of this: a >>registration structure is created, services are registered, then the >>registration object is itself queried, and the results compared >>symbolically with the original data. This verifies that the information >>flows through the system correctly. If someone later decides to change a >>small detail (e.g., a parameter name), the tests should continue to pass >>without modification. >> >>But the tests themselves don't really have to complicated to be useful: >>check that each module exports the functions it claims to implement, >>check that set/get methods work correctly, check return types in all >>contexts (does it return array in list context, scalar in scalar >>context). All that stuff is important in maintaining a coherent interface >>over time. It also helps to find inconsistencies. >> >>I think it would be really great if you could build some useful, robust, >>portable tests for the local-registry configuration. This kind of test >>can be a big help to users trying to install their local registry, so its >>utility goes beyond merely regression testing the code, it's also useful >>to debugging local installations with perfectly functioning code. >> >>-Frank >> >>PhD, Computational Biologist, >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. >>Tel: 617-432-3555 Fax: 617-432-3557 >>http://llama.med.harvard.edu/~fgibbons >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Nov 22 16:32:36 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 23 11:11:13 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43838E74.1010100@illuminae.com> Okay, now it is *really* done. by setting the environment variables: MOBY_SERVER MOBY_URI MOBY_ONTOLOGYSERVER you can connect to your own registry and your own ontology server. This also works for the test harness. I need to document the MOBY_ONTOLOGYSERVER information somewhere... I'll get to that soon! M Pieter Neerincx wrote: > > On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > >> I just changed the code on my own t/* to use environment variables >> while I was on the plane yesterday so that I could run tests on my >> own Windows installation - funny that we were all looking at the >> same piece of code at the same time :-) >> >> i'll commit these changes as soon as I have double-checked them. In >> general it will allow you to test your local registry instead of the >> remote one by default. > > > That's cool! I'm looking forward to test the tests :) > > Pieter > >> >> M >> >> >> >> Frank Gibbons wrote: >> >>> Congratulations, Pieter, >>> >>> At 08:32 AM 11/21/2005, you wrote: >>> >>>> One more thing. After my changes I tried make test and noticed that >>>> the Config.t is skipped, because it's only required for a local >>>> BioMOBY Central..., but I do have one and I have set my >>>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>> familiar with the test scripts... >>> >>> >>> >>> I think you just got yourself nominated to be caretaker of the test >>> t/Config.t. I don't have a local registry, so there was no way for >>> me to test its operation. Most users (I think) are in the same >>> position, so this test is skipped by default. >>> >>> For details on how to use the testing framework, you could look at >>> the Perl modules Test::Simple and Test:More. The basic idea is that >>> you execute some MOBY code for which you believe you know the >>> output. You compare actual output to expected output using the is () >>> function. It generates errors if the two don't match. You can also >>> check for correct failure using isnt(), which generates a similar >>> error. Examples might be: >>> >>> is(2+2, 4, "Can't do addition");' # Generates error with this >>> string showing up on output device >>> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >>> >>> Generally, tests should be symbolic, rather than specific. This >>> leads to tests that are more easy to maintain over time: if an >>> array is built before it is tested, and if it's tested >>> symbolically, it should be possible to alter the array contents at >>> a later point, without breaking that test. Take a look in the >>> Client-Central.t for examples of this: a registration structure is >>> created, services are registered, then the registration object is >>> itself queried, and the results compared symbolically with the >>> original data. This verifies that the information flows through the >>> system correctly. If someone later decides to change a small detail >>> (e.g., a parameter name), the tests should continue to pass without >>> modification. >>> >>> But the tests themselves don't really have to complicated to be >>> useful: check that each module exports the functions it claims to >>> implement, check that set/get methods work correctly, check return >>> types in all contexts (does it return array in list context, scalar >>> in scalar context). All that stuff is important in maintaining a >>> coherent interface over time. It also helps to find inconsistencies. >>> >>> I think it would be really great if you could build some useful, >>> robust, portable tests for the local-registry configuration. This >>> kind of test can be a big help to users trying to install their >>> local registry, so its utility goes beyond merely regression >>> testing the code, it's also useful to debugging local installations >>> with perfectly functioning code. >>> >>> -Frank >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: 617-432-3557 http:// >>> llama.med.harvard.edu/~fgibbons >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev@biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx@wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From markw at illuminae.com Tue Nov 22 15:06:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 23 16:30:34 2005 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43837A42.3020409@illuminae.com> > That's cool! I'm looking forward to test the tests :) Okay, it's done. MOBY::Client::Central always checks the environment variables MOBY_SERVER and MOBY_URI first unless you tell it otherwise, but it was hard-coded to talk to mobycentral.icapture.ubc.ca in the test suite. I've removed that now, and added an informational message to the test suite output to indicate how to set it up to test other registries. I've also changed the Client::Service test so that it looks for a service that is guaranteed to be there, rather than one that we just chose at random from the public registry. all 391 tests pass on Windows - Hurrah! M From markw at illuminae.com Wed Nov 23 16:05:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 23 16:35:14 2005 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> References: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> Message-ID: <1132779947.22071.10.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > So Mark, if I understand correctly, it should first check to see if the > user has defined those environment variables. That should indicate that the > user does have a local registry. Not necessarily local - the environment variables are simply a way of specifying which MOBY Central you wish to talk to by default (i.e. when you don't initialize the MOBY::Client::Central object with a "Registries" parameter). The following statements describe what happens: 1) The MOBY::Client::Central module is hard-coded to default to mobycentral.icapture.ubc.ca as it's default registry 2) When it is initializing, it first checks for the MOBY_SERVER and MOBY_URI environment variables and uses those instead of the defaults if they exist, otherwise it will default. 3) Initializing MOBY::Client::Central using the "Registries" argument will over-ride both of the previous behaviours -> use of this argument also allows you to interact with more than one registry at a time (for **read-only** interactions) ...(note that this latter behaviour has never been adequately tested, since it has never been used AFAIK) > It should a local registry if available, > but fall back to using MOBY Central if it's not available. Right? yup. That behaviour has always been true, actually; however the test harness was hard coded to use the 'Registries' argument when it started- up, so it was over-riding the useful behaviour that MOBY::Client::Central already had :-) The same behaviour is now true for MOBY::Client::OntologyServer - it will first check the environment variable, and if it isn't set, then it will default to call home to mobycentral.icapture.ubc.ca Cheers! M > That'd be awsome! > > -Frank > > > >M > > > > > > > >Frank Gibbons wrote: > > > >>Congratulations, Pieter, > >> > >>At 08:32 AM 11/21/2005, you wrote: > >> > >>>One more thing. After my changes I tried make test and noticed that > >>>the Config.t is skipped, because it's only required for a local > >>>BioMOBY Central..., but I do have one and I have set my > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > >>>familiar with the test scripts... > >> > >> > >>I think you just got yourself nominated to be caretaker of the test > >>t/Config.t. I don't have a local registry, so there was no way for me to > >>test its operation. Most users (I think) are in the same position, so > >>this test is skipped by default. > >> > >>For details on how to use the testing framework, you could look at > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > >>execute some MOBY code for which you believe you know the output. You > >>compare actual output to expected output using the is() function. It > >>generates errors if the two don't match. You can also check for correct > >>failure using isnt(), which generates a similar error. Examples might be: > >> > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > >>showing up on output device > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > >> > >>Generally, tests should be symbolic, rather than specific. This leads to > >>tests that are more easy to maintain over time: if an array is built > >>before it is tested, and if it's tested symbolically, it should be > >>possible to alter the array contents at a later point, without breaking > >>that test. Take a look in the Client-Central.t for examples of this: a > >>registration structure is created, services are registered, then the > >>registration object is itself queried, and the results compared > >>symbolically with the original data. This verifies that the information > >>flows through the system correctly. If someone later decides to change a > >>small detail (e.g., a parameter name), the tests should continue to pass > >>without modification. > >> > >>But the tests themselves don't really have to complicated to be useful: > >>check that each module exports the functions it claims to implement, > >>check that set/get methods work correctly, check return types in all > >>contexts (does it return array in list context, scalar in scalar > >>context). All that stuff is important in maintaining a coherent interface > >>over time. It also helps to find inconsistencies. > >> > >>I think it would be really great if you could build some useful, robust, > >>portable tests for the local-registry configuration. This kind of test > >>can be a big help to users trying to install their local registry, so its > >>utility goes beyond merely regression testing the code, it's also useful > >>to debugging local installations with perfectly functioning code. > >> > >>-Frank > >> > >>PhD, Computational Biologist, > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > >>Tel: 617-432-3555 Fax: 617-432-3557 > >>http://llama.med.harvard.edu/~fgibbons > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev@biomoby.org > >>http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev@biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From francis_gibbons at hms.harvard.edu Wed Nov 23 16:49:15 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Nov 23 16:56:09 2005 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <1132779947.22071.10.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Mark, Just ran the tests. Looks good, except the informational message is somewhat jarring... ideally, the only output that appears is a series of test-file names, with "..........ok" after them. I wonder if developers need to see that message each time they run the tests - perhaps it would help just as well if it were embedded as comments? What do you think? I'll be gone for a few days, as it Thanksgiving down here. -Frank At 04:05 PM 11/23/2005, you wrote: >On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > > > So Mark, if I understand correctly, it should first check to see if the > > user has defined those environment variables. That should indicate that > the > > user does have a local registry. > >Not necessarily local - the environment variables are simply a way of >specifying which MOBY Central you wish to talk to by default (i.e. when >you don't initialize the MOBY::Client::Central object with a >"Registries" parameter). > >The following statements describe what happens: > >1) The MOBY::Client::Central module is hard-coded to default to >mobycentral.icapture.ubc.ca as it's default registry > >2) When it is initializing, it first checks for the MOBY_SERVER and >MOBY_URI environment variables and uses those instead of the defaults if >they exist, otherwise it will default. > >3) Initializing MOBY::Client::Central using the "Registries" argument >will over-ride both of the previous behaviours > -> use of this argument also allows you to interact with more > than one >registry at a time (for **read-only** interactions) ...(note that this >latter behaviour has never been adequately tested, since it has never >been used AFAIK) > > > > > It should a local registry if available, > > but fall back to using MOBY Central if it's not available. Right? > > >yup. That behaviour has always been true, actually; however the test >harness was hard coded to use the 'Registries' argument when it started- >up, so it was over-riding the useful behaviour that >MOBY::Client::Central already had :-) > >The same behaviour is now true for MOBY::Client::OntologyServer - it >will first check the environment variable, and if it isn't set, then it >will default to call home to mobycentral.icapture.ubc.ca > >Cheers! > >M > > > > > > That'd be awsome! > > > > -Frank > > > > > > >M > > > > > > > > > > > >Frank Gibbons wrote: > > > > > >>Congratulations, Pieter, > > >> > > >>At 08:32 AM 11/21/2005, you wrote: > > >> > > >>>One more thing. After my changes I tried make test and noticed that > > >>>the Config.t is skipped, because it's only required for a local > > >>>BioMOBY Central..., but I do have one and I have set my > > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > > >>>familiar with the test scripts... > > >> > > >> > > >>I think you just got yourself nominated to be caretaker of the test > > >>t/Config.t. I don't have a local registry, so there was no way for me to > > >>test its operation. Most users (I think) are in the same position, so > > >>this test is skipped by default. > > >> > > >>For details on how to use the testing framework, you could look at > > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > > >>execute some MOBY code for which you believe you know the output. You > > >>compare actual output to expected output using the is() function. It > > >>generates errors if the two don't match. You can also check for correct > > >>failure using isnt(), which generates a similar error. Examples might be: > > >> > > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > > >>showing up on output device > > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > >> > > >>Generally, tests should be symbolic, rather than specific. This leads to > > >>tests that are more easy to maintain over time: if an array is built > > >>before it is tested, and if it's tested symbolically, it should be > > >>possible to alter the array contents at a later point, without breaking > > >>that test. Take a look in the Client-Central.t for examples of this: a > > >>registration structure is created, services are registered, then the > > >>registration object is itself queried, and the results compared > > >>symbolically with the original data. This verifies that the information > > >>flows through the system correctly. If someone later decides to change a > > >>small detail (e.g., a parameter name), the tests should continue to pass > > >>without modification. > > >> > > >>But the tests themselves don't really have to complicated to be useful: > > >>check that each module exports the functions it claims to implement, > > >>check that set/get methods work correctly, check return types in all > > >>contexts (does it return array in list context, scalar in scalar > > >>context). All that stuff is important in maintaining a coherent > interface > > >>over time. It also helps to find inconsistencies. > > >> > > >>I think it would be really great if you could build some useful, robust, > > >>portable tests for the local-registry configuration. This kind of test > > >>can be a big help to users trying to install their local registry, so > its > > >>utility goes beyond merely regression testing the code, it's also useful > > >>to debugging local installations with perfectly functioning code. > > >> > > >>-Frank > > >> > > >>PhD, Computational Biologist, > > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > > >>Tel: 617-432-3555 Fax: 617-432-3557 > > >>http://llama.med.harvard.edu/~fgibbons > > >>_______________________________________________ > > >>MOBY-dev mailing list > > >>MOBY-dev@biomoby.org > > >>http://www.biomoby.org/mailman/listinfo/moby-dev > > >> > > > > > >_______________________________________________ > > >MOBY-dev mailing list > > >MOBY-dev@biomoby.org > > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > PhD, Computational Biologist, > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > > Tel: 617-432-3555 Fax: > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev >-- >"Ontologists do it with the edges!" > >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 Wed Nov 23 17:34:19 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Nov 23 17:32:15 2005 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Message-ID: <1132785259.22071.22.camel@bioinfo.icapture.ubc.ca> It doesn't really bother me so much, but to be honest I think the bigger problem is that "make install" doesn't create a default local registry, and that "make test" would have to be run after "make install", which is even stranger. There was a time when Richard B had set up the Makefile to do this, or at least had set up an install script that would do the default MOBY Central installation and bootstrapping... that might be worth resurrecting. I think the code is still commented out in the Makefile... M On Wed, 2005-11-23 at 16:49 -0500, Frank Gibbons wrote: > Mark, > > Just ran the tests. Looks good, except the informational message is > somewhat jarring... ideally, the only output that appears is a series of > test-file names, with "..........ok" after them. I wonder if developers > need to see that message each time they run the tests - perhaps it would > help just as well if it were embedded as comments? What do you think? > > I'll be gone for a few days, as it Thanksgiving down here. > > -Frank > > At 04:05 PM 11/23/2005, you wrote: > >On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > > > > > So Mark, if I understand correctly, it should first check to see if the > > > user has defined those environment variables. That should indicate that > > the > > > user does have a local registry. > > > >Not necessarily local - the environment variables are simply a way of > >specifying which MOBY Central you wish to talk to by default (i.e. when > >you don't initialize the MOBY::Client::Central object with a > >"Registries" parameter). > > > >The following statements describe what happens: > > > >1) The MOBY::Client::Central module is hard-coded to default to > >mobycentral.icapture.ubc.ca as it's default registry > > > >2) When it is initializing, it first checks for the MOBY_SERVER and > >MOBY_URI environment variables and uses those instead of the defaults if > >they exist, otherwise it will default. > > > >3) Initializing MOBY::Client::Central using the "Registries" argument > >will over-ride both of the previous behaviours > > -> use of this argument also allows you to interact with more > > than one > >registry at a time (for **read-only** interactions) ...(note that this > >latter behaviour has never been adequately tested, since it has never > >been used AFAIK) > > > > > > > > > It should a local registry if available, > > > but fall back to using MOBY Central if it's not available. Right? > > > > > >yup. That behaviour has always been true, actually; however the test > >harness was hard coded to use the 'Registries' argument when it started- > >up, so it was over-riding the useful behaviour that > >MOBY::Client::Central already had :-) > > > >The same behaviour is now true for MOBY::Client::OntologyServer - it > >will first check the environment variable, and if it isn't set, then it > >will default to call home to mobycentral.icapture.ubc.ca > > > >Cheers! > > > >M > > > > > > > > > > > That'd be awsome! > > > > > > -Frank > > > > > > > > > >M > > > > > > > > > > > > > > > >Frank Gibbons wrote: > > > > > > > >>Congratulations, Pieter, > > > >> > > > >>At 08:32 AM 11/21/2005, you wrote: > > > >> > > > >>>One more thing. After my changes I tried make test and noticed that > > > >>>the Config.t is skipped, because it's only required for a local > > > >>>BioMOBY Central..., but I do have one and I have set my > > > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > > > >>>familiar with the test scripts... > > > >> > > > >> > > > >>I think you just got yourself nominated to be caretaker of the test > > > >>t/Config.t. I don't have a local registry, so there was no way for me to > > > >>test its operation. Most users (I think) are in the same position, so > > > >>this test is skipped by default. > > > >> > > > >>For details on how to use the testing framework, you could look at > > > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > > > >>execute some MOBY code for which you believe you know the output. You > > > >>compare actual output to expected output using the is() function. It > > > >>generates errors if the two don't match. You can also check for correct > > > >>failure using isnt(), which generates a similar error. Examples might be: > > > >> > > > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > > > >>showing up on output device > > > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > > >> > > > >>Generally, tests should be symbolic, rather than specific. This leads to > > > >>tests that are more easy to maintain over time: if an array is built > > > >>before it is tested, and if it's tested symbolically, it should be > > > >>possible to alter the array contents at a later point, without breaking > > > >>that test. Take a look in the Client-Central.t for examples of this: a > > > >>registration structure is created, services are registered, then the > > > >>registration object is itself queried, and the results compared > > > >>symbolically with the original data. This verifies that the information > > > >>flows through the system correctly. If someone later decides to change a > > > >>small detail (e.g., a parameter name), the tests should continue to pass > > > >>without modification. > > > >> > > > >>But the tests themselves don't really have to complicated to be useful: > > > >>check that each module exports the functions it claims to implement, > > > >>check that set/get methods work correctly, check return types in all > > > >>contexts (does it return array in list context, scalar in scalar > > > >>context). All that stuff is important in maintaining a coherent > > interface > > > >>over time. It also helps to find inconsistencies. > > > >> > > > >>I think it would be really great if you could build some useful, robust, > > > >>portable tests for the local-registry configuration. This kind of test > > > >>can be a big help to users trying to install their local registry, so > > its > > > >>utility goes beyond merely regression testing the code, it's also useful > > > >>to debugging local installations with perfectly functioning code. > > > >> > > > >>-Frank > > > >> > > > >>PhD, Computational Biologist, > > > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > > 02115, USA. > > > >>Tel: 617-432-3555 Fax: 617-432-3557 > > > >>http://llama.med.harvard.edu/~fgibbons > > > >>_______________________________________________ > > > >>MOBY-dev mailing list > > > >>MOBY-dev@biomoby.org > > > >>http://www.biomoby.org/mailman/listinfo/moby-dev > > > >> > > > > > > > >_______________________________________________ > > > >MOBY-dev mailing list > > > >MOBY-dev@biomoby.org > > > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > PhD, Computational Biologist, > > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > > USA. > > > Tel: 617-432-3555 Fax: > > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev@biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > >-- > >"Ontologists do it with the edges!" > > > >Mark Wilkinson > >Asst. Professor > >Dept. of Medical Genetics > >University of British Columbia > >PI in Bioinformatics > >iCAPTURE Centre > >St. Paul's Hospital > >Rm. 166, 1081 Burrard St. > >Vancouver, BC, V6Z 1Y6 > >tel: 604 682 2344 x62129 > >fax: 604 806 9274 > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev@biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From jmfernandez at cnb.uam.es Wed Nov 23 17:20:14 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Wed Nov 23 17:33:50 2005 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu><5.2.1. 1.2.20051121093229.010aed90@email.med.harvard.edu><5.2.1.1.2.20051118123741 .0123a990@email.med.harvard.edu><432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.n l><004401c5e94d$ab0c70c0$6600a8c0@notebook><004401c5e94d$ab0c70c0$6600a8c0@ notebook><5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu><432C2FF2 -E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl><5.2.1.1.2.20051118123741.0123a990@emai l.med.harvard.edu><5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Message-ID: <4384EB1E.9080403@cnb.uam.es> Hi everybody, I have installed many Perl packages, and many of them show lots of information when it is done the next invokation: make TEST_VERBOSE=1 test For instance, DBI uses Test::More inside its tests. Best Regards, Jos? Mar?a Frank Gibbons wrote: > Mark, > > Just ran the tests. Looks good, except the informational message is > somewhat jarring... ideally, the only output that appears is a series of > test-file names, with "..........ok" after them. I wonder if developers > need to see that message each time they run the tests - perhaps it would > help just as well if it were embedded as comments? What do you think? > > I'll be gone for a few days, as it Thanksgiving down here. > > -Frank > > At 04:05 PM 11/23/2005, you wrote: > >> On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: >> >> > So Mark, if I understand correctly, it should first check to see if the >> > user has defined those environment variables. That should indicate >> that the >> > user does have a local registry. >> >> Not necessarily local - the environment variables are simply a way of >> specifying which MOBY Central you wish to talk to by default (i.e. when >> you don't initialize the MOBY::Client::Central object with a >> "Registries" parameter). >> >> The following statements describe what happens: >> >> 1) The MOBY::Client::Central module is hard-coded to default to >> mobycentral.icapture.ubc.ca as it's default registry >> >> 2) When it is initializing, it first checks for the MOBY_SERVER and >> MOBY_URI environment variables and uses those instead of the defaults if >> they exist, otherwise it will default. >> >> 3) Initializing MOBY::Client::Central using the "Registries" argument >> will over-ride both of the previous behaviours >> -> use of this argument also allows you to interact with more >> than one >> registry at a time (for **read-only** interactions) ...(note that this >> latter behaviour has never been adequately tested, since it has never >> been used AFAIK) >> >> >> >> > It should a local registry if available, >> > but fall back to using MOBY Central if it's not available. Right? >> >> >> yup. That behaviour has always been true, actually; however the test >> harness was hard coded to use the 'Registries' argument when it started- >> up, so it was over-riding the useful behaviour that >> MOBY::Client::Central already had :-) >> >> The same behaviour is now true for MOBY::Client::OntologyServer - it >> will first check the environment variable, and if it isn't set, then it >> will default to call home to mobycentral.icapture.ubc.ca >> >> Cheers! >> >> M >> >> >> >> >> > That'd be awsome! >> > >> > -Frank >> > >> > >> > >M >> > > >> > > >> > > >> > >Frank Gibbons wrote: >> > > >> > >>Congratulations, Pieter, >> > >> >> > >>At 08:32 AM 11/21/2005, you wrote: >> > >> >> > >>>One more thing. After my changes I tried make test and noticed that >> > >>>the Config.t is skipped, because it's only required for a local >> > >>>BioMOBY Central..., but I do have one and I have set my >> > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> > >>>familiar with the test scripts... >> > >> >> > >> >> > >>I think you just got yourself nominated to be caretaker of the test >> > >>t/Config.t. I don't have a local registry, so there was no way for >> me to >> > >>test its operation. Most users (I think) are in the same position, so >> > >>this test is skipped by default. >> > >> >> > >>For details on how to use the testing framework, you could look at >> > >>the Perl modules Test::Simple and Test:More. The basic idea is >> that you >> > >>execute some MOBY code for which you believe you know the output. You >> > >>compare actual output to expected output using the is() function. It >> > >>generates errors if the two don't match. You can also check for >> correct >> > >>failure using isnt(), which generates a similar error. Examples >> might be: >> > >> >> > >>is(2+2, 4, "Can't do addition");' # Generates error with this string >> > >>showing up on output device >> > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> > >> >> > >>Generally, tests should be symbolic, rather than specific. This >> leads to >> > >>tests that are more easy to maintain over time: if an array is built >> > >>before it is tested, and if it's tested symbolically, it should be >> > >>possible to alter the array contents at a later point, without >> breaking >> > >>that test. Take a look in the Client-Central.t for examples of >> this: a >> > >>registration structure is created, services are registered, then the >> > >>registration object is itself queried, and the results compared >> > >>symbolically with the original data. This verifies that the >> information >> > >>flows through the system correctly. If someone later decides to >> change a >> > >>small detail (e.g., a parameter name), the tests should continue >> to pass >> > >>without modification. >> > >> >> > >>But the tests themselves don't really have to complicated to be >> useful: >> > >>check that each module exports the functions it claims to implement, >> > >>check that set/get methods work correctly, check return types in all >> > >>contexts (does it return array in list context, scalar in scalar >> > >>context). All that stuff is important in maintaining a coherent >> interface >> > >>over time. It also helps to find inconsistencies. >> > >> >> > >>I think it would be really great if you could build some useful, >> robust, >> > >>portable tests for the local-registry configuration. This kind of >> test >> > >>can be a big help to users trying to install their local registry, >> so its >> > >>utility goes beyond merely regression testing the code, it's also >> useful >> > >>to debugging local installations with perfectly functioning code. >> > >> >> > >>-Frank >> > >> >> > >>PhD, Computational Biologist, >> > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> > >>Tel: 617-432-3555 Fax: 617-432-3557 >> > >>http://llama.med.harvard.edu/~fgibbons >> > >>_______________________________________________ >> > >>MOBY-dev mailing list >> > >>MOBY-dev@biomoby.org >> > >>http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> >> > > >> > >_______________________________________________ >> > >MOBY-dev mailing list >> > >MOBY-dev@biomoby.org >> > >http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> > PhD, Computational Biologist, >> > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> > Tel: 617-432-3555 Fax: >> > 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev@biomoby.org >> > http://www.biomoby.org/mailman/listinfo/moby-dev >> -- >> "Ontologists do it with the edges!" >> >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From senger at ebi.ac.uk Thu Nov 24 09:14:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Nov 24 09:12:41 2005 Subject: [MOBY-dev] Biomoby Dashboard beta release Message-ID: Dear Moby-ists, There is another result (after Moses code generator) of my lucky (lucky for me) involvement with the Generation Challenge Programm and with IRRI particularly: it is my pleasure to announce a beta version of a Biomoby Dashboard (or shortly a Dash, as Eddie already nicknamed it, but I am not sure about English, especially slang English meaning of it :-)). It is for Biomoby service providers, it is potentially extensible also for Biomoby client. We will be adding there new panels shortly, and I hope to get feedback from you so we can improve it. I am sorry that the documentation is (almost) missing, but I wanted to release it so I can get feedback as soon as possible. We are working on documentation, as well. You can find basic instructions and some screen-shots here: http://biomoby.org/moby-live/Java/docs/Dashboard.html. With regards, Martin -- Martin Senger email: martin.senger@gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From rebecca.ernst at gsf.de Fri Nov 25 04:55:13 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri Nov 25 05:07:53 2005 Subject: [MOBY-dev] dashboard Message-ID: <4386DF81.6040500@gsf.de> Hi Martin! I had a first look at dashboard and I really loved it! I makes things so much easier! I also found it quite intuitive to use. In principle everything worked but there were some problems. 1) If I use the planet registry it reads out the datatypes but after finishing reading it doesn't have them anymore. Is it possible that it misses the LSID resolver which we don't have yet? 2) In the Moses-Generator section I couldn't find out how to select a service to generate code for... I have them in the service listing on the left but how do I select one to generate code for?? Cheers, Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Fri Nov 25 11:11:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Nov 25 11:09:37 2005 Subject: [moby] [MOBY-dev] dashboard In-Reply-To: <4386DF81.6040500@gsf.de> References: <4386DF81.6040500@gsf.de> Message-ID: <1132935095.27789.21.camel@bioinfo.icapture.ubc.ca> We can help you set up the LSID resolver if you like. The current release of the Perl LSID stack is broken, but in the past week the CVS version is now working - we've asked them to make a release, since this is the last unfinished issue that is preventing us from both starting the RDF agent, and making a new MOBY code release... LSID's in Perl have been problematic for years, and have prevented us from ever becoming dependent on them v.v. the RDF agent, as Martin has pointed out several times! Hopefully this latest release will be stable for the long-term... hopefully! In any case, I suspect that Martin's dashboard is using LSID resolution of MOBY stuff to metadata, since he was asking about it frequently in the past few weeks. If that is the only issue standing between you and success, then please let me know and either Eddie or I will get you up and running quickly! M On Fri, 2005-11-25 at 10:55 +0100, Rebecca Ernst wrote: > Hi Martin! > > I had a first look at dashboard and I really loved it! I makes things so > much easier! I also found it quite intuitive to use. > > In principle everything worked but there were some problems. > > 1) If I use the planet registry it reads out the datatypes but after > finishing reading it doesn't have them anymore. Is it possible that it > misses the LSID resolver which we don't have yet? > > 2) In the Moses-Generator section I couldn't find out how to select a > service to generate code for... I have them in the service listing on > the left but how do I select one to generate code for?? > > Cheers, > Rebecca > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Wed Nov 2 07:32:47 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed, 02 Nov 2005 13:32:47 +0100 Subject: [MOBY-dev] parseMobyData Message-ID: <4368B1EF.9060004@gsf.de> Hi Eddie! I had another look into Taverna to see if our workflows now run correctly but found two problems of parseMobyData. The first problem is that parseMobyData can't deal with collections (it never could) the second is that it also can't deal with the new object stucture (e.g. a string object containing a string now) as it only checks the first layer content and never goes into the additional string. Do you know of these problems and if so - are there any plans for fixing it? Cheers, Rebecca From Pieter.Neerincx at wur.nl Wed Nov 2 07:44:21 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 2 Nov 2005 13:44:21 +0100 Subject: [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <4360E4FD.6090202@ucalgary.ca> References: <4360E4FD.6090202@ucalgary.ca> Message-ID: <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> Hi all, Here is a question for those using the Perl API. In MOBY/Client/Central.pm we have a sub retrieveObjectDefinition which calls sub _ObjectDefinitionPayload { This produces an array for the objects, articleNames and lsids for the relationships of the object whose definition is requested. I'm wondering why this is an array. Currently I have to rely on the order of elements in this array to figure out which element is the object, which one is articleName, etc. These are the lines producing the array: 553 push @{ $relationships{$relationshipType} }, 554 [ $_->toString, $article, $rlsid ]; Is there any reason why this should be an array? I'd rather not have to rely on the order of the elements, so are there people who have any objections when I change this into a hash like in: push @{ $relationships{$relationshipType} }, { object => $_->toString, articleName => $article, lsid => $rlsid }; Cheers, Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Wed Nov 2 08:06:16 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 2 Nov 2005 14:06:16 +0100 Subject: [MOBY-dev] parseMobyData In-Reply-To: <4368B1EF.9060004@gsf.de> References: <4368B1EF.9060004@gsf.de> Message-ID: <0B94C244-81D6-4AE5-A457-37E71E0192E5@wur.nl> Hi all, On 2-Nov-2005, at 1:32 PM, Rebecca Ernst wrote: > Hi Eddie! > > I had another look into Taverna to see if our workflows now run > correctly but found two problems of parseMobyData. > The first problem is that parseMobyData can't deal with collections > (it never could) the second is that it also can't deal with the new > object stucture (e.g. a string object containing a string now) as > it only checks the first layer content and never goes into the > additional string. Well as far as I know it never did that either. It's a much bigger problem. It will not decompose any multi-layered objects. Currently it's easy to compile a big object from multiple smaller objects. If you add a complex object to your workflow Taverna will add all the individual parts and create the links between them. But decomposing the big object is something else. The info about the object's relationships are stored in the ontology, so theoretically it should be possible to generate proccessors to decompose the big ones, but I guess that is more like a feature request then a bug :). Currently I create custom services to decompose big objects again as a workaround, but some automated object decomposition in taverna would be really cool... Cheers, Pieter > Do you know of these problems and if so - are there any plans for > fixing it? > > Cheers, > Rebecca > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Wed Nov 2 11:12:56 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 08:12:56 -0800 Subject: [moby] [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> Message-ID: <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> I think you're right - that's a much better data structure to be passing around. This does change the external (perl client) API, right? :-/ Really, what the Perl client code needs is a good laundering. The CommonSubs.pm module is a total mess after being modified piecemeal over the past 3 years... I wonder if we shouldn't just start a new module (or modules) that are named by their domain of function (RegistryIO, OntologyIO, or something like that) and have all fresh code? Gradually we could migrate all functionality into these modules. Client::Central has been around since the 0.1 prototype of MOBY in 2001 and has never been re-written top-to- bottom! I'm still waiting to hear about the re-funding attempts for MOBY... fingers crossed! There will hopefully be a second opportunity later in the winter, so all is not lost if we fail. It would be great to have a couple of extra hands dedicated to a complete code re-write. M On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: > Hi all, > > Here is a question for those using the Perl API. In > > MOBY/Client/Central.pm > > we have a > > sub retrieveObjectDefinition > > which calls > > sub _ObjectDefinitionPayload { > > This produces an array for the objects, articleNames and lsids for > the relationships of the object whose definition is requested. I'm > wondering why this is an array. Currently I have to rely on the order > of elements in this array to figure out which element is the object, > which one is articleName, etc. These are the lines producing the array: > > 553 push @{ $relationships{$relationshipType} }, > 554 [ $_->toString, $article, $rlsid ]; > > Is there any reason why this should be an array? I'd rather not have > to rely on the order of the elements, so are there people who have > any objections when I change this into a hash like in: > > push @{ $relationships{$relationshipType} }, > { object => $_->toString, > articleName => $article, > lsid => $rlsid }; > > Cheers, > > Pieter > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Wed Nov 2 10:47:45 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 2 Nov 2005 07:47:45 -0800 Subject: [MOBY-dev] RE: parseMobyData In-Reply-To: <4368B1EF.9060004@gsf.de> Message-ID: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Hi Rebecca, I was unaware of those issues, mainly because I didn't touch that widget and I left it as is for compatibility reasons. Also, I think that I could add support for parsing collections. Given a collection, return a list of whatever that widget returns. Moreover, you and Pieter have been talking about retrieving the string (and most likely integers, floats, etc) from the objects. Pieter went as far to say that he creates processors to do that for him. Do you think that it would be worthwhile to add another port to processors that contain the 'primitives' so that you can retrieve them? For example, imagine that you are using a processor blastDB that performs a blast search on some database and returns the blast results in xml. In Moby, this would be a data type called text-xml (I think). Would it be useful to also have an output port that contains only the xml text in it? Let me know what you think. Most likely, you have a better idea. Tell it to me and I will see what I can do. Eddie > -----Original Message----- > From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] > Sent: Wednesday, November 02, 2005 4:33 AM > To: Edward Kawas > Cc: mobydev > Subject: parseMobyData > > Hi Eddie! > > I had another look into Taverna to see if our workflows > now run > correctly but found two problems of parseMobyData. > The first problem is that parseMobyData can't deal with > collections (it > never could) the second is that it also can't deal with > the new object > stucture (e.g. a string object containing a string now) as > it only > checks the first layer content and never goes into the > additional string. > Do you know of these problems and if so - are there any > plans for fixing it? > > Cheers, > Rebecca From markw at illuminae.com Wed Nov 2 12:50:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 09:50:04 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > Also, I think that I could add support for parsing > collections. Given a collection, return a list of whatever > that widget returns. Wow... I didn't realize that this functionality wasn't already in there somewhere. Or am I misunderstanding? Can't Taverna take a collection and pass the individual members one at a time to a downstream service that consumes simples? I guess I've never built a workflow that needs this. It's an interesting "book-keeping" problem for Taverna in that it would have to generate unique queryID's for each of the Simples it passed, since these would not have been provided by the previous service provider... > Moreover, you and Pieter have been talking about retrieving > the string (and most likely integers, floats, etc) from the > objects. Pieter went as far to say that he creates > processors to do that for him. Do you think that it would be > worthwhile to add another port to processors that contain > the 'primitives' so that you can retrieve them? YES! YES! YES! This is critical for interacting with anything other than a MOBY service... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 12:50:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 09:50:04 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > Also, I think that I could add support for parsing > collections. Given a collection, return a list of whatever > that widget returns. Wow... I didn't realize that this functionality wasn't already in there somewhere. Or am I misunderstanding? Can't Taverna take a collection and pass the individual members one at a time to a downstream service that consumes simples? I guess I've never built a workflow that needs this. It's an interesting "book-keeping" problem for Taverna in that it would have to generate unique queryID's for each of the Simples it passed, since these would not have been provided by the previous service provider... > Moreover, you and Pieter have been talking about retrieving > the string (and most likely integers, floats, etc) from the > objects. Pieter went as far to say that he creates > processors to do that for him. Do you think that it would be > worthwhile to add another port to processors that contain > the 'primitives' so that you can retrieve them? YES! YES! YES! This is critical for interacting with anything other than a MOBY service... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 13:44:40 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 10:44:40 -0800 Subject: [MOBY-dev] RFC Voting - message to all core developers In-Reply-To: <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> Message-ID: <1130957080.27282.40.camel@bioinfo.icapture.ubc.ca> So, this just isn't working at all :-/ A couple of frustrating things have happened v.v. RFC 1863: First: a vote was called, and there were some post-call suggestions which resulted in a revision of the document. The vote was subsequently called off. Second: there were some late suggestions from Paul and Martin (Oct 17/18) that were not discussed further by the interested parties (in particular, the group that put forward the RFC in the first place). An indication that the suggested changes are accepted/rejected by the proponents would be a good idea before a vote is called. Third: In the absence of changes to the document, the call for a re-vote was made, but was ignored by all but one of the RFC panel members (including my own local team, so I am just as guilty... but thanks Frank for being conscientious!). Whether it be by bugzilla or by email, it really doesn't matter to me which method people use - since this isn't a high-traffic event I can make notes on a piece of paper to tally the votes - but we need to actually DO it. I don't mean for this to be an accusatory message in any way. I only mean to point out that the RFC process for MOBY isn't working as we are currently implementing it, so we should perhaps come up with a better mechanism that accomplishes what we need to accomplish. There are a LOT of great suggestions currently sitting in Bugzilla that we will need to start addressing quickly. Do we need to set up a more dedicated mailing list or forum for RFC events so that they don't get lost in the general traffic of the -dev mailing list? (which is no longer a "low traffic" list, as it is described in the mailing list documentation ;-) ). Would a once-monthly teleconference solve the problem? What mechanism would the RFC panel find most intuitive and useful? Bugzilla is already in place, but if people are finding it too arcane, I can find a pre-canned or script-up an alternative solution... either way we need to quickly find something that does work, because I'm sure that David and his team in Spain are going nuts by now (especially since it is obvious that their RFC is, in principle, going to pass - we're only negotiating the details now :-) ) M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From tmo at ebi.ac.uk Wed Nov 2 12:58:07 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 02 Nov 2005 17:58:07 +0000 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> Message-ID: <4368FE2F.4070901@ebi.ac.uk> Mark Wilkinson wrote: > On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > > >>Also, I think that I could add support for parsing >>collections. Given a collection, return a list of whatever >>that widget returns. > > > Wow... I didn't realize that this functionality wasn't already in there > somewhere. Or am I misunderstanding? Can't Taverna take a collection > and pass the individual members one at a time to a downstream service > that consumes simples? I guess I've never built a workflow that needs > this. It's an interesting "book-keeping" problem for Taverna in that it > would have to generate unique queryID's for each of the Simples it > passed, since these would not have been provided by the previous service > provider... It _did_ work like that in our original version, yes. We broke all moby collections into Taverna collections of moby simples, using Taverna's type reconciliation layer to reconstitute these into moby collections if required or to iterate over services consuming moby simples. A while ago we agreed that this behaviour should be retained so if it doesn't do that now it's a bug. Tom From tmo at ebi.ac.uk Wed Nov 2 12:58:07 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 02 Nov 2005 17:58:07 +0000 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> Message-ID: <4368FE2F.4070901@ebi.ac.uk> Mark Wilkinson wrote: > On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > > >>Also, I think that I could add support for parsing >>collections. Given a collection, return a list of whatever >>that widget returns. > > > Wow... I didn't realize that this functionality wasn't already in there > somewhere. Or am I misunderstanding? Can't Taverna take a collection > and pass the individual members one at a time to a downstream service > that consumes simples? I guess I've never built a workflow that needs > this. It's an interesting "book-keeping" problem for Taverna in that it > would have to generate unique queryID's for each of the Simples it > passed, since these would not have been provided by the previous service > provider... It _did_ work like that in our original version, yes. We broke all moby collections into Taverna collections of moby simples, using Taverna's type reconciliation layer to reconstitute these into moby collections if required or to iterate over services consuming moby simples. A while ago we agreed that this behaviour should be retained so if it doesn't do that now it's a bug. Tom From markw at illuminae.com Wed Nov 2 17:03:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 14:03:29 -0800 Subject: [MOBY-dev] A consequence of the new Object inheritence rules... Message-ID: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Hi all, I keep forgetting to mention, but it needs to be said so that people know about it until we have time to code it into the API: The way I see it, one of the consequences of not inheriting from Primitives is that MOBY now has its first "reserved word". The primary content of a given object (i.e. the content that would have been the CDATA, string, or integer content of the node in old-style objects) has now been stuck into a primitive data-type, however there is nothing preventing an object from having two HASA's, one containing the actual content, and the other containing a primitive. For example: AnnotatedFASTA hasa String (content) <--- this is the FASTA hasa String (Description) Back when we were allowing inheritance from primitives, it was obvious where the content was, but it isn't anymore, so we need a reserved word as the articleName of the contained primitive :-/ An alternative route would be to disallow use of primitives for anything *other* than containing 'content'. That would require another extensive re-working of the Object ontology, but we would end up with something like this: AnnotatedFASTA hasa String (content) hasa Description (anotation) hasa String (content) The latter seems more "correct", but it would require us to re-write the ontology again... Comments? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 17:40:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 14:40:34 -0800 Subject: [moby] [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> References: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: <1130971234.27282.83.camel@bioinfo.icapture.ubc.ca> Just a clarification - by saying that the solution below seems more "correct" I was not suggesting that I *support* this solution. This solution leads to a massive proliferation of task-specific objects; every use of String now becomes a first-class MOBY Object, rather than simply a "performs role" relationship as we had with articleName. A pox on the Java-guys who don't like inheritance... ;-) M On Wed, 2005-11-02 at 14:03 -0800, Mark Wilkinson wrote: > An alternative route > would be to disallow use of primitives for anything *other* than > containing 'content'. That would require another extensive re-working > of the Object ontology, but we would end up with something like this: > > AnnotatedFASTA > hasa String (content) > hasa Description (anotation) > hasa String (content) > > The latter seems more "correct", but it would require us to re-write the > ontology again... -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 17:40:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 14:40:34 -0800 Subject: [moby] [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> References: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: <1130971234.27282.83.camel@bioinfo.icapture.ubc.ca> Just a clarification - by saying that the solution below seems more "correct" I was not suggesting that I *support* this solution. This solution leads to a massive proliferation of task-specific objects; every use of String now becomes a first-class MOBY Object, rather than simply a "performs role" relationship as we had with articleName. A pox on the Java-guys who don't like inheritance... ;-) M On Wed, 2005-11-02 at 14:03 -0800, Mark Wilkinson wrote: > An alternative route > would be to disallow use of primitives for anything *other* than > containing 'content'. That would require another extensive re-working > of the Object ontology, but we would end up with something like this: > > AnnotatedFASTA > hasa String (content) > hasa Description (anotation) > hasa String (content) > > The latter seems more "correct", but it would require us to re-write the > ontology again... -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Nov 2 18:52:38 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 2 Nov 2005 23:52:38 +0000 (GMT) Subject: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, What the hell are you talking about? :-) It's morning here so I may not be fully awoke... > The way I see it, one of the consequences of not inheriting from > Primitives is that MOBY now has its first "reserved word". > The reserverd words we have are the names of primitive types (String, Integer, Float, DateTime, Boolean, Object), we do not need any reserved word for an article name. You created the name 'content' just because you changed the old ontology to the new one by a script - which is fine (as long as nobody in that time was using the name 'content' for any HAS[A] members - probably was not, or possibly your script could have be clever and check this). But now, it really does not matter how to name it, does it? > The primary content of a given object > There is nothing like "the primary content". And if yes, today is the first time I hear it. I hope we do not need such concept. No, unless you explain it further I do not see any need for having a primary content, and that's why we do not need any reserved word for it. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 2 18:52:38 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 2 Nov 2005 23:52:38 +0000 (GMT) Subject: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, What the hell are you talking about? :-) It's morning here so I may not be fully awoke... > The way I see it, one of the consequences of not inheriting from > Primitives is that MOBY now has its first "reserved word". > The reserverd words we have are the names of primitive types (String, Integer, Float, DateTime, Boolean, Object), we do not need any reserved word for an article name. You created the name 'content' just because you changed the old ontology to the new one by a script - which is fine (as long as nobody in that time was using the name 'content' for any HAS[A] members - probably was not, or possibly your script could have be clever and check this). But now, it really does not matter how to name it, does it? > The primary content of a given object > There is nothing like "the primary content". And if yes, today is the first time I hear it. I hope we do not need such concept. No, unless you explain it further I do not see any need for having a primary content, and that's why we do not need any reserved word for it. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 2 19:08:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 00:08:49 +0000 (GMT) Subject: [MOBY-dev] RFC Voting - message to all core developers In-Reply-To: <1130957080.27282.40.camel@bioinfo.icapture.ubc.ca> Message-ID: You are right that the voting process was not so smooth as it could have been - but do not be too desperate - it was not that bad. I think it is still better than it was before. I agree with you that the main problems were: * Not always clear where the latest document can be found (that's, for example, why I could not vote the last time). * Not sure where to vote (email or bugzilla). * Not fast enough replies from the voters about suggested changes. I still think that we should conclude this error handling voting now, and try again for other issues: - not in bugzilla, - discussion and document udates driven by the proponents, - keeping deadlines of voting Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 18:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 15:57:02 -0800 Subject: [unclassified] Re: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: References: Message-ID: <1130975822.27282.90.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 23:52 +0000, Martin Senger wrote: > Mark, > What the hell are you talking about? :-) > It's morning here so I may not be fully awoke... I'll let you wake up a little more and think about it again before I try to explain it in more detail... it's a tricky one, and I'm multi-tasking right now... :-) M From markw at illuminae.com Wed Nov 2 20:51:11 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 17:51:11 -0800 Subject: [MOBY-dev] Reserved word... perhaps unnecessary... Message-ID: <43696D0F.7010605@illuminae.com> Hi Martin, I love using you as the bellweather for my own thoughts :-) You are seldom wrong, and delight in telling me when I am! ;-) I think I am starting to see your point - I had not been thinking of the object ontology in quite that way, but you've got me reconsidering now. I'm going to bring it up for discussion at my lab meeting tomorrow and try to hash-out with the local guys exactly why I feel the way I do, and whether or not there are any serious adverse effects to thinking about it your way. It certainly makes things easier to do it your way, though I wish now that we had had this discussion while Eddie was writing the database update script because I would have changed the way we approached it... Oh well... I guess that's why MOBY is still considered a research project ;-) Thanks for being so forthright in your opinons - you are an extremely valuable asset to the project! M From markw at illuminae.com Wed Nov 2 21:15:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:15:44 -0800 Subject: [MOBY-dev] New website is ready... Message-ID: <436972D0.8020606@illuminae.com> Hi all, I think I'm just about finished moving stuff over to the new website. Please browse it and get back to me or Simon with comments. http://biomoby.open-bio.org M From senger at ebi.ac.uk Wed Nov 2 21:28:48 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 02:28:48 +0000 (GMT) Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> Message-ID: > http://biomoby.open-bio.org > I asked to have there a link to jMoby pages. I cannot find it. Could it be inserted there please? The old link was/is http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move the jMoby pages somewhere else, or you just use to link to that old hyperlink. Thanks, Martin PS. The jMoby pages still use the old stylesheet, but that will be rectified in due time. No time for that now, I am afraid. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 21:54:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:54:43 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43697BF3.7040209@illuminae.com> Sorry about that! It's now a link in the deveopers page M Martin Senger wrote: >>http://biomoby.open-bio.org >> >> >> > I asked to have there a link to jMoby pages. I cannot find it. Could it >be inserted there please? The old link was/is >http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move >the jMoby pages somewhere else, or you just use to link to that old >hyperlink. > > Thanks, > Martin > >PS. The jMoby pages still use the old stylesheet, but that will be >rectified in due time. No time for that now, I am afraid. M. > > > From markw at illuminae.com Wed Nov 2 21:56:31 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:56:31 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43697C5F.3020402@illuminae.com> I still don't have the cvs update on a cron... Does anyone know offhand if a cvs update preserves the permissions that I have set on the server, or does it over-write them with the permissions in the CVS repository? M Martin Senger wrote: >>http://biomoby.open-bio.org >> >> >> > I asked to have there a link to jMoby pages. I cannot find it. Could it >be inserted there please? The old link was/is >http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move >the jMoby pages somewhere else, or you just use to link to that old >hyperlink. > > Thanks, > Martin > >PS. The jMoby pages still use the old stylesheet, but that will be >rectified in due time. No time for that now, I am afraid. M. > > > From markw at illuminae.com Wed Nov 2 21:58:39 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:58:39 -0800 Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? Message-ID: <43697CDF.5000408@illuminae.com> Under "Clients" on the new homepage is a list of all of the clients and applications that use MOBY that I know about. If I have missed anyone, please say so and I'll add it. M From senger at ebi.ac.uk Wed Nov 2 22:02:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 03:02:41 +0000 (GMT) Subject: [MOBY-dev] New website is ready... In-Reply-To: <43697C5F.3020402@illuminae.com> Message-ID: > I still don't have the cvs update on a cron... > This is what jMoby has for updating its documentation from CVS: #!/bin/bash # PATH=$PATH:/usr/java/j2sdk1.4.2_02/bin export PATH cd /home/websites/biomoby.org/html/moby-live/Java cvs -d :pserver:cvs:cvs at cvs.open-bio.org:/home/repository/moby -q update -dP ./build.sh docs > Does anyone know offhand if a cvs update preserves the permissions that > I have set on the server, or does it over-write them with the > permissions in the CVS repository? > My experiences are: It preserves them - but once they are in the cvs server you cannot change them. So if you commit a script script.pl without executing permissions, it will be always given to the local copies without this flag (unless you change it on the server side I guess). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 2 22:05:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 03:05:44 +0000 (GMT) Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <43697CDF.5000408@illuminae.com> Message-ID: > Under "Clients" on the new homepage is a list of all of the clients and > applications that use MOBY that I know about. If I have missed anyone, > please say so and I'll add it. > client title: "command-line clients" source: jMoby platform: Java link: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/CmdLineClients.html Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 22:13:56 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 19:13:56 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43698074.8060708@illuminae.com> > This is what jMoby has for updating its documentation from CVS: > >#!/bin/bash ># >PATH=$PATH:/usr/java/j2sdk1.4.2_02/bin >export PATH >cd /home/websites/biomoby.org/html/moby-live/Java >cvs -d :pserver:cvs:cvs at cvs.open-bio.org:/home/repository/moby -q update -dP >./build.sh docs > > > Is that a script that I can call from the cron? > My experiences are: It preserves them - but once they are in the cvs >server you cannot change them. So if you commit a script script.pl without >executing permissions, it will be always given to the local copies >without this flag (unless you change it on the server side I guess). > > I know that it preserves them over CVS commits (i.e. if I commit without execute permission, and then commit with execute permission, it will still not have it), but I am unsure about whether something that was committed with execute permission will change the permissions of something that I set as non-executable locally and then cvs update over top of it. M > > From senger at ebi.ac.uk Wed Nov 2 22:17:18 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 03:17:18 +0000 (GMT) Subject: [MOBY-dev] New website is ready... In-Reply-To: <43698074.8060708@illuminae.com> Message-ID: > Is that a script that I can call from the cron? > Yes. I am calling it as a cronjob on machine portal.open-bio.org. My crontab item for this script is the following: # update jMoby from CVS and update its documentation # every 3 hours, every day 28 0,3,6,9,12,15,18,21 * * * $HOME/scripts/update-jmoby-docs.sh > /dev/null Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 22:30:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 19:30:35 -0800 Subject: [MOBY-dev] jMOBY documentation Message-ID: <4369845B.6000301@illuminae.com> 1) it is now accessible through the new website under "MOBY For Developers" 2) I just read it for the first time... WOW! Martin, you did a really great job on that documentation! Kudo's to you! From bmg at sfu.ca Wed Nov 2 22:59:34 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed, 2 Nov 2005 19:59:34 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <3DD0C1BE-C048-4F8D-B104-9391280F6DF0@sfu.ca> I don't see a link to register for the mailing list anywhere? Martin's graphs, Net Nanny on tools and toys? Should there be a contact link on the first page somewhere? Cool possible additions: A listing of project websites that employ moby services. Links to principle developers home pages if they exist. Dynamically updated statistics on services, moby central hits etc. Net Nanny for services! 2c -ben On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From Pieter.Neerincx at wur.nl Thu Nov 3 06:17:28 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 3 Nov 2005 12:17:28 +0100 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> On 03Nov2005, at 03:15, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. Hi Mark and Simon, Nice job! Looks like I found some small permission bugs though: Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Docs/MOBY- S_API/index_API.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Java/docs/ taverna/guide/index.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Java/docs/ API/index.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Furthermore I added a page to the Docs in the CVS some time ago, but I can not find it anywhere on the new website... I'd love to be able to contribute to the new site, so I also registered for a WordPress account, but so far I haven't been able to do anything useful with it. Sure I can login (and logout), but that's it :(. Cheers, Pieter > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Thu Nov 3 06:56:08 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 3 Nov 2005 12:56:08 +0100 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <0C0A3DE6-E48B-48AA-A62B-163E1DFCFD65@wur.nl> On 27Oct2005, at 24:18, Edward Kawas wrote: > Hi, > > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 I'm in favor of RFC 1863. So I vote yes again. I think it's crucial for the speed of BioMOBY evolution to have have at least some error reporting in place. In the current situation where empty objects are returned if something goes wrong, a user is completely in the dark. Debugging such cases is extremely painful. Currently most users are developers as well so we can look in the log files of the machines where our services are running, but if we want BioMOBY to become more popular with 'normal' users we need some error reporting that makes sense a.s.a.p. I found two small inconsistencies though: Page 4 mentions refqueryID, refQuery and refQueryID attributes. Do I get it right that these are typo's and all the same atribute...? Furtermore I think this: "refElement - refers to the articleName of the offending input Simple or Collection" will be a problem. If it's referring to the articleName it should be called refArticleName. The problem is that articleNames are optional. There is no guarantee they will be present. Furthermore they not need to be unique. In case there are multiple elements of the same type, the articleName attribute can be used to differentiate between them. Hence the combination of element and articleName can be used by a service to find a specific element. If you want to link an execption to a specific element of the input you will need both a refElement and a refArticleName... So instead of: 600 Unable to execute the service I propose something like this: 600 Unable to execute the service Just my 2c, Pieter > > Thanks. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From rebecca.ernst at gsf.de Thu Nov 3 09:58:32 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 03 Nov 2005 15:58:32 +0100 Subject: [MOBY-dev] Re: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <436A2598.4050307@gsf.de> Hi Eddie, Mark, Pieter, Tom and others! The problem No.1 (Collections in parsemobydata) is solved resp. it didn't exist. As for every other service or scavenger Taverna decomposes the object into simples! (this is true for Taverna versions up to 1.1 and for 1.3. Not for the 1.2 release though but here Eddie has a bugfix via CVS) The reason we believed it is a collection problem is that parsing of one service output failed which gives back collections. Now we digged into it and found that Taverna doesn't have a problem with the object being a collection: the problem was that the service is registered as giving back simples but gives back collections. In contrast to gbrowse Taverna obviously only decomposes collections when it expects them to be there. We had a look at the second problem (primitives in moby-objects) and think that your suggestion with further ports giving access to the primitives would solve the problem. If we got it right this would replace the 'parseMobyData' scavenger completely - is that right? Cheers, Rebecca and Dirk Edward Kawas wrote: >Hi Rebecca, > >I was unaware of those issues, mainly because I didn't touch >that widget and I left it as is for compatibility reasons. > >Also, I think that I could add support for parsing >collections. Given a collection, return a list of whatever >that widget returns. > >Moreover, you and Pieter have been talking about retrieving >the string (and most likely integers, floats, etc) from the >objects. Pieter went as far to say that he creates >processors to do that for him. Do you think that it would be >worthwhile to add another port to processors that contain >the 'primitives' so that you can retrieve them? > >For example, imagine that you are using a processor blastDB >that performs a blast search on some database and returns >the blast results in xml. In Moby, this would be a data type >called text-xml (I think). Would it be useful to also have >an output port that contains only the xml text in it? > >Let me know what you think. Most likely, you have a better >idea. Tell it to me and I will see what I can do. > >Eddie > > > >>-----Original Message----- >>From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] >>Sent: Wednesday, November 02, 2005 4:33 AM >>To: Edward Kawas >>Cc: mobydev >>Subject: parseMobyData >> >>Hi Eddie! >> >>I had another look into Taverna to see if our workflows >>now run >>correctly but found two problems of parseMobyData. >>The first problem is that parseMobyData can't deal with >>collections (it >>never could) the second is that it also can't deal with >>the new object >>stucture (e.g. a string object containing a string now) as >>it only >>checks the first layer content and never goes into the >>additional string. >>Do you know of these problems and if so - are there any >>plans for fixing it? >> >>Cheers, >>Rebecca >> >> > > > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From francis_gibbons at hms.harvard.edu Thu Nov 3 10:00:39 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 03 Nov 2005 10:00:39 -0500 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> Message-ID: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> Mark, Under "For developers", the link to the "latest Perl API" docs doesn't work, because: You don't have permission to access /CVS_CONTENT/moby-live/Docs/MOBY-S_API/index_API.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Also, it struck me that the links to the tutorials are not the same as what's in CVS. I felt like it was important to have all documentation under CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other documentation is in the parent directory (omit the "Perl" above). -Frank At 09:15 PM 11/2/2005, you wrote: >Hi all, > >I think I'm just about finished moving stuff over to the new website. >Please browse it and get back to me or Simon with comments. > >http://biomoby.open-bio.org > >M > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Nov 3 10:23:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 3 Nov 2005 15:23:47 +0000 GMT Subject: [MOBY-dev] New website is ready... Message-ID: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> Look under "clients" - many websites are there. Look under "about moby" - mailing list info is there. M -----Original Message----- From: Benjamin Good Date: Wed, 2 Nov 2005 19:59:34 To:Core developer announcements Subject: Re: [MOBY-dev] New website is ready... I don't see a link to register for the mailing list anywhere? Martin's graphs, Net Nanny on tools and toys? Should there be a contact link on the first page somewhere? Cool possible additions: A listing of project websites that employ moby services. Links to principle developers home pages if they exist. Dynamically updated statistics on services, moby central hits etc. Net Nanny for services! 2c -ben On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Thu Nov 3 10:00:30 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 3 Nov 2005 07:00:30 -0800 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <0C0A3DE6-E48B-48AA-A62B-163E1DFCFD65@wur.nl> Message-ID: <000101c5e087$56402ba0$6600a8c0@notebook> I vote in favor. Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Thursday, November 03, 2005 3:56 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] vote on the RFC discussing Error > Reporting > > On 27Oct2005, at 24:18, Edward Kawas wrote: > > > Hi, > > > > I am calling a vote on the RFC that discusses error > > reporting. > > > > Please refer to the following link: > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > I'm in favor of RFC 1863. So I vote yes again. I think > it's crucial > for the speed of BioMOBY evolution to have have at least > some error > reporting in place. In the current situation where empty > objects are > returned if something goes wrong, a user is completely in > the dark. > Debugging such cases is extremely painful. Currently most > users are > developers as well so we can look in the log files of the > machines > where our services are running, but if we want BioMOBY to > become more > popular with 'normal' users we need some error reporting > that makes > sense a.s.a.p. > > I found two small inconsistencies though: > > Page 4 mentions refqueryID, refQuery and refQueryID > attributes. Do I > get it right that these are typo's and all the same > atribute...? > > Furtermore I think this: > > "refElement - refers to the articleName of the offending > input > Simple or Collection" > > will be a problem. If it's referring to the articleName it > should be > called refArticleName. The problem is that articleNames > are optional. > There is no guarantee they will be present. Furthermore > they not need > to be unique. In case there are multiple elements of the > same type, > the articleName attribute can be used to differentiate > between them. > Hence the combination of element and articleName can be > used by a > service to find a specific element. If you want to link an > execption > to a specific element of the input you will need both a > refElement > and a refArticleName... > > So instead of: > > refQueryID="1" > severity ="error"> > 600 > Unable to execute the > service > > > I propose something like this: > > refArticleName="input1" > refQueryID="1" > severity ="error"> > 600 > Unable to execute the > service > > > Just my 2c, > > Pieter > > > > > > Thanks. > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1038 > Dreijenlaan 3 > 6703 HA Wageningen > phone: 0317-484 706 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Thu Nov 3 11:10:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:10:29 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> References: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> Message-ID: <1131034229.31833.16.camel@bioinfo.icapture.ubc.ca> Martin, what is the URL for the NetNanny project? M On Thu, 2005-11-03 at 15:23 +0000, mark wilkinson wrote: > Look under "clients" - many websites are there. > > Look under "about moby" - mailing list info is there. > > M > > > -----Original Message----- > From: Benjamin Good > Date: Wed, 2 Nov 2005 19:59:34 > To:Core developer announcements > Subject: Re: [MOBY-dev] New website is ready... > > I don't see a link to register for the mailing list anywhere? > > Martin's graphs, Net Nanny on tools and toys? > > Should there be a contact link on the first page somewhere? > > Cool possible additions: > A listing of project websites that employ moby services. > Links to principle developers home pages if they exist. > Dynamically updated statistics on services, moby central hits etc. > Net Nanny for services! > > 2c > > -ben > > > > On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > > > Hi all, > > > > I think I'm just about finished moving stuff over to the new > > website. Please browse it and get back to me or Simon with comments. > > > > http://biomoby.open-bio.org > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:11:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:11:30 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> Message-ID: <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > Also, it struck me that the links to the tutorials are not the same as > what's in CVS. I felt like it was important to have all documentation under > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > documentation is in the parent directory (omit the "Perl" above). Right, the link in the tutorials is actually cyclic (it eventually leads back to itself), but I forgot to update it last night. I'll do that right away. M From markw at illuminae.com Thu Nov 3 11:11:49 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:11:49 -0800 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <000101c5e087$56402ba0$6600a8c0@notebook> References: <000101c5e087$56402ba0$6600a8c0@notebook> Message-ID: <1131034309.31833.20.camel@bioinfo.icapture.ubc.ca> I vote in favor also. On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > I vote in favor. > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > > Neerincx > > Sent: Thursday, November 03, 2005 3:56 AM > > To: Core developer announcements > > Subject: Re: [MOBY-dev] vote on the RFC discussing Error > > Reporting > > > > On 27Oct2005, at 24:18, Edward Kawas wrote: > > > > > Hi, > > > > > > I am calling a vote on the RFC that discusses error > > > reporting. > > > > > > Please refer to the following link: > > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > > > I'm in favor of RFC 1863. So I vote yes again. I think > > it's crucial > > for the speed of BioMOBY evolution to have have at least > > some error > > reporting in place. In the current situation where empty > > objects are > > returned if something goes wrong, a user is completely in > > the dark. > > Debugging such cases is extremely painful. Currently most > > users are > > developers as well so we can look in the log files of the > > machines > > where our services are running, but if we want BioMOBY to > > become more > > popular with 'normal' users we need some error reporting > > that makes > > sense a.s.a.p. > > > > I found two small inconsistencies though: > > > > Page 4 mentions refqueryID, refQuery and refQueryID > > attributes. Do I > > get it right that these are typo's and all the same > > atribute...? > > > > Furtermore I think this: > > > > "refElement - refers to the articleName of the offending > > input > > Simple or Collection" > > > > will be a problem. If it's referring to the articleName it > > should be > > called refArticleName. The problem is that articleNames > > are optional. > > There is no guarantee they will be present. Furthermore > > they not need > > to be unique. In case there are multiple elements of the > > same type, > > the articleName attribute can be used to differentiate > > between them. > > Hence the combination of element and articleName can be > > used by a > > service to find a specific element. If you want to link an > > execption > > to a specific element of the input you will need both a > > refElement > > and a refArticleName... > > > > So instead of: > > > > > refQueryID="1" > > severity ="error"> > > 600 > > Unable to execute the > > service > > > > > > I propose something like this: > > > > > refArticleName="input1" > > refQueryID="1" > > severity ="error"> > > 600 > > Unable to execute the > > service > > > > > > Just my 2c, > > > > Pieter > > > > > > > > > > Thanks. > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1038 > > Dreijenlaan 3 > > 6703 HA Wageningen > > phone: 0317-484 706 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Thu Nov 3 11:15:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 16:15:29 +0000 (GMT) Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034229.31833.16.camel@bioinfo.icapture.ubc.ca> Message-ID: > Martin, what is the URL for the NetNanny project? > Does not ring any bells. Unless you mean BioNanny - that is http://www.bionanny.org. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 3 11:16:52 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 16:16:52 +0000 (GMT) Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <1131034309.31833.20.camel@bioinfo.icapture.ubc.ca> Message-ID: Could anybody sent me the latest document we are voting on? (But do not sent me a link to bugzilla please). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Nov 3 11:18:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:18:26 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> Message-ID: <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 12:17 +0100, Pieter Neerincx wrote: > Forbidden All these that I can find are now fixed. I was paranoid last night and switched off execute permissions on all folders in the CVS except for the ones that I knew contained documentation because it makes me nervous having end-user-writable executable folders on our website! > Furthermore I added a page to the Docs in the CVS some time ago, but > I can not find it anywhere on the new website... where? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:23:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:23:00 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> Oh, I see what you mean. You have already ported the TWiki documentation over to the CVS. Super! I'll remove the ones that I moved last night then. M On Thu, 2005-11-03 at 08:11 -0800, Mark Wilkinson wrote: > On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > > > Also, it struck me that the links to the tutorials are not the same as > > what's in CVS. I felt like it was important to have all documentation under > > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > > documentation is in the parent directory (omit the "Perl" above). > > Right, the link in the tutorials is actually cyclic (it eventually leads > back to itself), but I forgot to update it last night. I'll do that > right away. > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Thu Nov 3 11:38:10 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 03 Nov 2005 17:38:10 +0100 Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <43697CDF.5000408@illuminae.com> References: <43697CDF.5000408@illuminae.com> Message-ID: <436A3CF2.3070905@gsf.de> Hi Mark! here are two more clients. maybe you want to include them in the page (but in another table like 'specific clients' as they are not very generic) http://urgi.infobiogen.fr/BioFloWeb/ http://mips.gsf.de/cgi-bin/proj/planet/moby/AtiDBClient.cgi Cheers, Rebecca Mark Wilkinson wrote: > Under "Clients" on the new homepage is a list of all of the clients > and applications that use MOBY that I know about. If I have missed > anyone, please say so and I'll add it. > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Nov 3 11:39:58 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:39:58 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131035998.31833.29.camel@bioinfo.icapture.ubc.ca> Done! Thanks again Frank - that was a fantastic effort and it looks great!! M On Thu, 2005-11-03 at 08:23 -0800, Mark Wilkinson wrote: > Oh, I see what you mean. You have already ported the TWiki > documentation over to the CVS. Super! I'll remove the ones that I > moved last night then. > > M > > > On Thu, 2005-11-03 at 08:11 -0800, Mark Wilkinson wrote: > > On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > > > > > Also, it struck me that the links to the tutorials are not the same as > > > what's in CVS. I felt like it was important to have all documentation under > > > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > > > documentation is in the parent directory (omit the "Perl" above). > > > > Right, the link in the tutorials is actually cyclic (it eventually leads > > back to itself), but I forgot to update it last night. I'll do that > > right away. > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Thu Nov 3 11:31:35 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 03 Nov 2005 17:31:35 +0100 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <436A3B67.5070302@gsf.de> Hi Mark! I had a look on the website and wanted to test the LSID resolver.. (http://mobycentral.icapture.ubc.ca/cgi-bin/LSID_Resolver.pl) I only get internal server errors when trying it with one of the examples you give on that page... Cheers, Rebecca Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new website. > Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Nov 3 11:46:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:46:34 -0800 Subject: [moby] Re: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <436A3CF2.3070905@gsf.de> References: <43697CDF.5000408@illuminae.com> <436A3CF2.3070905@gsf.de> Message-ID: <1131036394.31833.31.camel@bioinfo.icapture.ubc.ca> Done On Thu, 2005-11-03 at 17:38 +0100, Rebecca Ernst wrote: > Hi Mark! > > here are two more clients. maybe you want to include them in the page > (but in another table like 'specific clients' as they are not very generic) > > http://urgi.infobiogen.fr/BioFloWeb/ > http://mips.gsf.de/cgi-bin/proj/planet/moby/AtiDBClient.cgi > > Cheers, > Rebecca > > > > Mark Wilkinson wrote: > > > Under "Clients" on the new homepage is a list of all of the clients > > and applications that use MOBY that I know about. If I have missed > > anyone, please say so and I'll add it. > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Thu Nov 3 10:00:17 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 3 Nov 2005 07:00:17 -0800 Subject: [MOBY-dev] RE: parseMobyData In-Reply-To: <436A2598.4050307@gsf.de> Message-ID: <000001c5e087$4f3a8850$6600a8c0@notebook> HI! > -----Original Message----- > From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] > Sent: Thursday, November 03, 2005 6:59 AM > To: Edward Kawas > Cc: 'Moby Developers' > Subject: Re: parseMobyData > > Hi Eddie, Mark, Pieter, Tom and others! > > The problem No.1 (Collections in parsemobydata) is solved > resp. it > didn't exist. > As for every other service or scavenger Taverna decomposes > the object > into simples! (this is true for Taverna versions up to 1.1 > and for 1.3. > Not for the 1.2 release though but here Eddie has a bugfix > via CVS) > The reason we believed it is a collection problem is that > parsing of one > service output failed which gives back collections. > Now we digged into it and found that Taverna doesn't have > a problem with > the object being a collection: the problem was that the > service is > registered as giving back simples but gives back > collections. In > contrast to gbrowse Taverna obviously only decomposes > collections when > it expects them to be there. > > We had a look at the second problem (primitives in moby- > objects) and > think that your suggestion with further ports giving > access to the > primitives would solve the problem. If we got it right > this would > replace the 'parseMobyData' scavenger completely - is that > right? I think so. But then again, parseMobyData also allows you to retrieve ids, namespaces, etc. I would only give you the primitive information. Eddie > > Cheers, > Rebecca and Dirk > > > > > > > > > Edward Kawas wrote: > > >Hi Rebecca, > > > >I was unaware of those issues, mainly because I didn't > touch > >that widget and I left it as is for compatibility reasons. > > > >Also, I think that I could add support for parsing > >collections. Given a collection, return a list of > whatever > >that widget returns. > > > >Moreover, you and Pieter have been talking about > retrieving > >the string (and most likely integers, floats, etc) from > the > >objects. Pieter went as far to say that he creates > >processors to do that for him. Do you think that it would > be > >worthwhile to add another port to processors that contain > >the 'primitives' so that you can retrieve them? > > > >For example, imagine that you are using a processor > blastDB > >that performs a blast search on some database and returns > >the blast results in xml. In Moby, this would be a data > type > >called text-xml (I think). Would it be useful to also > have > >an output port that contains only the xml text in it? > > > >Let me know what you think. Most likely, you have a > better > >idea. Tell it to me and I will see what I can do. > > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] > >>Sent: Wednesday, November 02, 2005 4:33 AM > >>To: Edward Kawas > >>Cc: mobydev > >>Subject: parseMobyData > >> > >>Hi Eddie! > >> > >>I had another look into Taverna to see if our workflows > >>now run > >>correctly but found two problems of parseMobyData. > >>The first problem is that parseMobyData can't deal with > >>collections (it > >>never could) the second is that it also can't deal with > >>the new object > >>stucture (e.g. a string object containing a string now) > as > >>it only > >>checks the first layer content and never goes into the > >>additional string. > >>Do you know of these problems and if so - are there any > >>plans for fixing it? > >> > >>Cheers, > >>Rebecca > >> > >> > > > > > > > > > > > > -- > Rebecca Ernst > MIPS, Inst. for Bioinformatics > GSF Research Center for Environment and Health > Ingolstaedter Landstr. 1 > 85764 Neuherberg > fon: +49 89 3187 3583 > email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Nov 3 11:48:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:48:43 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <436A3B67.5070302@gsf.de> References: <436972D0.8020606@illuminae.com> <436A3B67.5070302@gsf.de> Message-ID: <1131036523.31833.35.camel@bioinfo.icapture.ubc.ca> Hi Rebecca, Yeah, it turns out that the LSID Perl client stack from Sourceforge doesn't handle namespaces on its wsdl documents (ask me how long it took me to debug THAT problem!), so that resolver doesn't work anymore :-/ >>sigh<< The Perl support for XML is **SO** crappy! Anyway, Eddie has written a new one in Java, and I just haven't had time to set up the link to it. I'll do that right now. Thanks for reminding me! M On Thu, 2005-11-03 at 17:31 +0100, Rebecca Ernst wrote: > Hi Mark! > > I had a look on the website and wanted to test the LSID resolver.. > (http://mobycentral.icapture.ubc.ca/cgi-bin/LSID_Resolver.pl) > > I only get internal server errors when trying it with one of the > examples you give on that page... > > Cheers, > Rebecca > > > > > Mark Wilkinson wrote: > > > Hi all, > > > > I think I'm just about finished moving stuff over to the new website. > > Please browse it and get back to me or Simon with comments. > > > > http://biomoby.open-bio.org > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:51:41 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:51:41 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000001c5e087$4f3a8850$6600a8c0@notebook> References: <000001c5e087$4f3a8850$6600a8c0@notebook> Message-ID: <1131036701.31833.41.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > > think that your suggestion with further ports giving > > access to the > > primitives would solve the problem. If we got it right > > this would > > replace the 'parseMobyData' scavenger completely - is that > > right? > I think so. But then again, parseMobyData also allows you to > retrieve ids, namespaces, etc. I would only give you the > primitive information. Is there a need to have both, or should they be rolled into one now? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 11:51:41 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:51:41 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000001c5e087$4f3a8850$6600a8c0@notebook> References: <000001c5e087$4f3a8850$6600a8c0@notebook> Message-ID: <1131036701.31833.41.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > > think that your suggestion with further ports giving > > access to the > > primitives would solve the problem. If we got it right > > this would > > replace the 'parseMobyData' scavenger completely - is that > > right? > I think so. But then again, parseMobyData also allows you to > retrieve ids, namespaces, etc. I would only give you the > primitive information. Is there a need to have both, or should they be rolled into one now? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From dgpisano at cnb.uam.es Thu Nov 3 12:08:18 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 03 Nov 2005 18:08:18 +0100 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: Message-ID: <436A4402.7000209@cnb.uam.es> Martin Senger escribi?: >Could anybody sent me the latest document we are voting on? (But do not >sent me a link to bugzilla please). > >Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v2.02.pdf Type: application/pdf Size: 186802 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20051103/84c7dcac/0501INB-ExceptionReporting-v2.02-0002.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20051103/84c7dcac/dgpisano-0002.vcf From dgpisano at cnb.uam.es Thu Nov 3 12:36:53 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 03 Nov 2005 18:36:53 +0100 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: Message-ID: <436A4AB5.6050903@cnb.uam.es> Hello Martin, I've just sent you the latest version (2.02, 3rd November 2005) version which includes some of the changes that were discussed during October. The document is also in the bugzilla (http://bugzilla.open-bio.org/attachment.cgi?id=246) My vote is YES, just in case somebody is wondering ;-) Martin Senger escribi?: >Could anybody sent me the latest document we are voting on? (But do not >sent me a link to bugzilla please). > Some comments about this latest version (the author's name and the date the comment was sent to core developers included, plus the request and the action taken and reflected in the 2.02 version). No major changes, the proposal is still the same than 1 month ago with some rewordings and typos corrected: - Mark (29/09/2005) - Request for change the wording of Change 1 to "In the case of an error, failure should raise an exception and an empty mobyData block with the appropriate queryID will be returned" - INCLUDED - Paul (17/10/2005) - Request to rename the proposal to something more meaningful - DONE, now the proposal is called "Exception Reporting in MOBY-S" - Paul (17/10/2005) - Doubts about the error 701 - DONE, the ambiguous example has been removed - Paul (17/10/2005) - Errors 70* suggestions - DONE partially, added the "error" 700 as a generic service intrinsic exception placeholder for any generic situation where the execution was ok and we want to use mobyException. Other codes not added, see next comment - Martin (18/10/2005) - Type "information" in exception reporting - I think it not hurts to leave it there. It could be used to report informative (non erroneous or warning) exceptions about a specific element (Simple or Collection) or mobyData entry in a structured (parseable) way, because mobyException allows us to map the information to that specific element. We still maintain the Notes in serviceNotes to report general unstructured information, and for functional compatibility with old moby versions - Martin (18/10/2005) - Errors 70* suggestions - DONE partially, added the "error" 700 (see above) and removed all the codes but 701 (SERVICE_INTERNAL_ERROR). As Martin suggests, created a 227 INPUT_INCORRECT_NAMESPACE - Pieter (3/11/2005) - typos in the document - DONE, the tag is called refQueryID, reviewed and changed - Pieter (3/11/2005) - refArticlename - NOT INCLUDED. I know this can open a new can of worms about whether rticlenames should be mandatory or not, and we have talked about this in the past. The problem is not with the exception reporting proposal, but with the MOBY specification itself: if Articlenames are not mandatory, and I can send several elements to the same type to my service, how can I differenciate them? If there is no need to differenciate them, or that does not make sense from the point of view of the service execution, then it makes no sense from the point of view of the exception reporting. If I cannot identify them individually, then I cannot report exceptions about them individually and thus I have to say "There is a problem with one or more or the inputs". If I can differenciate them because they have an Articlename, then I use the refElement tag to refer to the problematic element... Does this make sense? -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20051103/44cbafb8/dgpisano-0002.vcf From duncan.hull at cs.man.ac.uk Thu Nov 3 14:42:13 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Thu, 03 Nov 2005 19:42:13 +0000 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436A6815.70201@cs.man.ac.uk> Dear Mark / BioMOBYers Can you advise me on the best way to get the rdf for the service "EMBOSSbacktranseq" I just wanted some examples, and found http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf ...from martins handy client documentation but not sure if the RDF is up to date. Thanks Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From simont at mcw.edu Thu Nov 3 15:17:50 2005 From: simont at mcw.edu (Twigger Simon) Date: Thu, 3 Nov 2005 14:17:50 -0600 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <78883846-6389-4B18-B334-8D0D3FFC1B04@mcw.edu> I vote in favour of RFC 1863. Simon. On Oct 26, 2005, at 5:18 PM, Edward Kawas wrote: > Hi, > > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > Thanks. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From markw at illuminae.com Thu Nov 3 15:56:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 12:56:29 -0800 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <436A6815.70201@cs.man.ac.uk> References: <436A6815.70201@cs.man.ac.uk> Message-ID: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Hi Dunc! I hope you aren't writing another thesis saying nasty things about MOBY! Okay, the main problem is that the RDF is not up to date - we're still negotiating with Pinar about what the RDF representation of MOBY/myGrid services is going to be (in fact, Eddie is here right now and we are going over the final details). As such, when you do what I suggest below, you are going to get RDF that is still changing daily. Having said all that - there are two ways to get MOBY RDF. You can get it from our RESOURCES script, or by LSID resolution to metadata. To get a full dump of MOBY Central as RDF (the old RDF that we will NOT be using) go to: http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances (this takes a while, since it is dynamically generated...) Or for a specific service, resolve the LSID: urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName (e.g. urn:lsid:biomoby.org:serviceinstance:www.illuminae.com,getSHound3DNeighboursFromGi) We'll have the RDF generator updated in the next few days - hopefully today will be the last of our modifications of the RDF structure to be myGrid-compatible. M On Thu, 2005-11-03 at 19:42 +0000, Duncan Hull wrote: > Dear Mark / BioMOBYers > > Can you advise me on the best way to get the rdf for the service > "EMBOSSbacktranseq" > > I just wanted some examples, and found > http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf > > ...from martins handy client documentation but not sure if the RDF is up > to date. > > Thanks > > Duncan > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 15:59:28 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 12:59:28 -0800 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> If you like, I will ask Eddie to write to you when the updates are done, and then you will have something stable to play with... M On Thu, 2005-11-03 at 12:56 -0800, Mark Wilkinson wrote: > Hi Dunc! > > I hope you aren't writing another thesis saying nasty things about MOBY! > > Okay, the main problem is that the RDF is not up to date - we're still > negotiating with Pinar about what the RDF representation of MOBY/myGrid > services is going to be (in fact, Eddie is here right now and we are > going over the final details). As such, when you do what I suggest > below, you are going to get RDF that is still changing daily. > > Having said all that - there are two ways to get MOBY RDF. You can get > it from our RESOURCES script, or by LSID resolution to metadata. > > To get a full dump of MOBY Central as RDF (the old RDF that we will NOT > be using) go to: > > http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances > (this takes a while, since it is dynamically generated...) > > Or for a specific service, resolve the LSID: > > urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName > > (e.g. > urn:lsid:biomoby.org:serviceinstance:www.illuminae.com,getSHound3DNeighboursFromGi) > > We'll have the RDF generator updated in the next few days - hopefully > today will be the last of our modifications of the RDF structure to be > myGrid-compatible. > > M > > > > On Thu, 2005-11-03 at 19:42 +0000, Duncan Hull wrote: > > Dear Mark / BioMOBYers > > > > Can you advise me on the best way to get the rdf for the service > > "EMBOSSbacktranseq" > > > > I just wanted some examples, and found > > http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf > > > > ...from martins handy client documentation but not sure if the RDF is up > > to date. > > > > Thanks > > > > Duncan > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 16:19:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 13:19:30 -0800 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <43696D0F.7010605@illuminae.com> References: <43696D0F.7010605@illuminae.com> Message-ID: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Okay, I have thought about this now, and discussed it with Eddie and Ben for a while. I can see the way Martin is thinking, and it is certainly different from how I have always "seen" MOBY Objects. Here's how the argument goes: Martin: MOBY Objects are just syntax, so there is no such thing as a "core" data-type for MOBY objects. They don't have an "essense"! Objects are just "stuff" Mark: Yes they do! The ISA hierarchy implies that an object has an "essense". There are two ways to construct an AnnotatedFASTA object: It can either inherit from FASTA, and add an Annotation, or it can inherit from Annotation and add a FASTA. Under the new object creation system, the syntactic outcome of these paths is identical, but they are "qualitatively" different.... it is nonsensical to "FASTA an Annotation", but it is sensible to "Annotate a FASTA". The "essense" of the object is the FASTA sequence it contains, based on its ISA hierarchy. The problem we have now is that, without querying the ontology and traversing back to the most primitive object, I cannot know which contained object represents the "essense" of my in-hand object (i.e. the thing that I would MOST want to represent if I had to represent that object in a hurry). It also causes a problem with rendering... a FASTA sequence and a Genbank record are formatted strings. What happens now that we have contained primitives is that you have to ask the parent tag about its type before you know how to render the child tag. I can't render a string containing a genbank record without paying attention to its formatting, but I don't know that a String is a formatted string until I ask the parent GenBankFlatfile object what it is... :-/ >>sigh<< I dunno... the world just got much harder. M On Wed, 2005-11-02 at 17:51 -0800, Mark Wilkinson wrote: > Hi Martin, > > I love using you as the bellweather for my own thoughts :-) You are > seldom wrong, and delight in telling me when I am! ;-) > > I think I am starting to see your point - I had not been thinking of the > object ontology in quite that way, but you've got me reconsidering now. > I'm going to bring it up for discussion at my lab meeting tomorrow and > try to hash-out with the local guys exactly why I feel the way I do, and > whether or not there are any serious adverse effects to thinking about > it your way. It certainly makes things easier to do it your way, though > I wish now that we had had this discussion while Eddie was writing the > database update script because I would have changed the way we > approached it... > > Oh well... I guess that's why MOBY is still considered a research > project ;-) > > Thanks for being so forthright in your opinons - you are an extremely > valuable asset to the project! > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Thu Nov 3 15:56:20 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 3 Nov 2005 12:56:20 -0800 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436A6815.70201@cs.man.ac.uk> Message-ID: <000201c5e0b9$0d6d0fb0$2566a8c0@notebook> Hi Duncan, I am reworking the structure of the rdf document that describes Moby services. Right now, if you want to see an outdated version, http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances would be the place to get a document describing all services. Once the structure has been reworked, I will let you know. Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Duncan Hull > Sent: Thursday, November 03, 2005 11:42 AM > To: Core developer announcements; markw at illuminae.com > Subject: [MOBY-dev] Please sir, can I have some more RDF? > > Dear Mark / BioMOBYers > > Can you advise me on the best way to get the rdf for the > service > "EMBOSSbacktranseq" > > I just wanted some examples, and found > http://www.biomoby.org/moby- > live/Java/docs/Testing_service.rdf > > ...from martins handy client documentation but not sure if > the RDF is up > to date. > > Thanks > > Duncan > > -- > Duncan Hull > http://www.cs.man.ac.uk/~hulld/ > Phone: +44 (0) 161 275 0677 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From adf at ncgr.org Thu Nov 3 19:44:54 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Thu, 3 Nov 2005 17:44:54 -0700 (MST) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark and Martin- I can't resist jumping in here from somewhere out of left field (and without much time over the next week to engage very deeply in the discussion), BUT: it seems to me that the argument you are beginning to hash out here gets close to the issue that the semantic moby side of the world has with respect to moby services' MOBY-XML representation of data vs semantic moby's preference to represent the data (not just the ontologies) as RDF (using RDF/XML or some other RDF syntax). The position below that you ascribe to Martin concerning the non-essential nature of the objects would for the semantic web data representation approach be instead better characterized as a "multi-faceted essence"; that is to say that an object can belong to many classes and each of these "types" associated with the object may (or may not) imply a set of properties ("the stuff") to be expected of an instance of the type OR (conversely) an object that has a certain set of properties may be inferred to belong to a class defined in a certain way. The decision about what is "essential" is I believe one determined by the user of the information, and the best systems are those that allow the same "stuff" to be used in many different purposes (since there is no single type of user). I think it is true that MOBY objects can have multiple typing, by reusing the namespace id in a structure with a different "class tag" (apologies if I have the lingo a bit off, it's been a while for me); and yet, I think your insistence that the ISA determines the object's essence is somewhat indicative of the use of XML structure to have the data producer determine intended usage rather than allowing the data consumer to determine how it may be used. (If we wanted to make this discussion more concrete, I have been fooling around with a little OWL ontology ("owl-let") for properties representing mapping/sequence/feature type info; it is in the same conceptual space as your "genericsequence/virtualsequence/etc." stuff, and might be an instructive example of how the two approaches differ in practice.) My 2c, and not necessarily reflective of the opinions of others in the s-moby sphere, but I do think that this is one of the critical areas to resolve in order to be able to bring the two branches of the project back together. Whether or not RDF is appropriate as a representation of all pieces of a message is another question, but in terms of a data payload representation format, I think we should really give it some consideration if and when we are able to move forward on the long promised reunification of the two branches. RDF: it's not just for metadata! Andrew Farmer PS. I hope this message doesn't hit Martin's mailbox before he's had time for tea... ;) PPS I am not clear on the "rendering" issues you allude to at the end, but we have been having some debates around the issue of transmitting data in well-known text formats embedded within (or as some sort of attachment to) the RDF. I would be interested in hearing about your experiences with such things... On Thu, 3 Nov 2005, Mark Wilkinson wrote: > Okay, I have thought about this now, and discussed it with Eddie and Ben > for a while. I can see the way Martin is thinking, and it is certainly > different from how I have always "seen" MOBY Objects. > > Here's how the argument goes: > > Martin: MOBY Objects are just syntax, so there is no such thing as a > "core" data-type for MOBY objects. They don't have an "essense"! > Objects are just "stuff" > > Mark: Yes they do! The ISA hierarchy implies that an object has an > "essense". There are two ways to construct an AnnotatedFASTA object: > It can either inherit from FASTA, and add an Annotation, or it can > inherit from Annotation and add a FASTA. Under the new object creation > system, the syntactic outcome of these paths is identical, but they are > "qualitatively" different.... it is nonsensical to "FASTA an > Annotation", but it is sensible to "Annotate a FASTA". The "essense" of > the object is the FASTA sequence it contains, based on its ISA > hierarchy. The problem we have now is that, without querying the > ontology and traversing back to the most primitive object, I cannot know > which contained object represents the "essense" of my in-hand object > (i.e. the thing that I would MOST want to represent if I had to > represent that object in a hurry). > > It also causes a problem with rendering... a FASTA sequence and a > Genbank record are formatted strings. What happens now that we have > contained primitives is that you have to ask the parent tag about its > type before you know how to render the child tag. I can't render a > string containing a genbank record without paying attention to its > formatting, but I don't know that a String is a formatted string until I > ask the parent GenBankFlatfile object what it is... :-/ > > >>sigh<< > > I dunno... the world just got much harder. > > M > > > > > On Wed, 2005-11-02 at 17:51 -0800, Mark Wilkinson wrote: > > Hi Martin, > > > > I love using you as the bellweather for my own thoughts :-) You are > > seldom wrong, and delight in telling me when I am! ;-) > > > > I think I am starting to see your point - I had not been thinking of the > > object ontology in quite that way, but you've got me reconsidering now. > > I'm going to bring it up for discussion at my lab meeting tomorrow and > > try to hash-out with the local guys exactly why I feel the way I do, and > > whether or not there are any serious adverse effects to thinking about > > it your way. It certainly makes things easier to do it your way, though > > I wish now that we had had this discussion while Eddie was writing the > > database update script because I would have changed the way we > > approached it... > > > > Oh well... I guess that's why MOBY is still considered a research > > project ;-) > > > > Thanks for being so forthright in your opinons - you are an extremely > > valuable asset to the project! > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From senger at ebi.ac.uk Thu Nov 3 21:36:04 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 02:36:04 +0000 (GMT) Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <78883846-6389-4B18-B334-8D0D3FFC1B04@mcw.edu> Message-ID: YES. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 3 21:59:00 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 02:59:00 +0000 (GMT) Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Message-ID: > Having said all that - there are two ways to get MOBY RDF. You can get > it from our RESOURCES script, or by LSID resolution to metadata. > Interesting is that Mark has not mentioned the only "offical" way how to get RDF: use Biomoby API! This gives you, however, back RDF of all services, not only the one you are interested in - so perhaps that's the reason why he has not mentioned it. (But I doubt it :-) - Mark never liked this part of the Moby API.) I am making jokes but I am also getting tired by the endless discussions about RDF and how to get it. Biomoby is killing itself by having so many ways, so many unofficial ways, and still none of them is working properly for years (yes, I am talking now about the RDF agent which is intrinsicaly connected with RDF...) Duncan, in jMoby, call: build/run/run-cmdline-clinet -rdf services -q > services.rdf and you will get all RDF for services. This is the only official way. Because: 1) going directly to URL > http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances > is an unofficial, never made official, hack. If you wish yo use this way, you should at least get the URL first uding Biomoby API, by calling: build/run/run-cmdline-client -lu Resource URLs: -------------- ServiceInstance http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances Object http://biomoby.org/RESOURCES/MOBY-S/Objects Service http://biomoby.org/RESOURCES/MOBY-S/Services Namespace http://biomoby.org/RESOURCES/MOBY-S/Namespaces Full http://biomoby.org/RESOURCES/MOBY-S/FULL 2) using > Or for a specific service, resolve the LSID: > urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName > suffers from the fact that Biomoby LSIDs were not yet documented properly: you do not know (now) if you should resolve it to data or metadata, and what to expect. As I said, tired from this stuff... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Nov 4 00:37:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 21:37:30 -0800 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436AF39A.1030104@illuminae.com> >Biomoby is killing itself > In no way is that true, since only a very few people care right now if there is RDF in MOBY or not. > by >having so many ways, so many unofficial ways, and still none of them is >working properly for years (yes, I am talking now about the RDF agent >which is intrinsicaly connected with RDF...) > > The RDF itself has been changing because it is a new standard, and because it is important to get it right rather than ask people to change it every few months. The desire to adopt the same RDF representationas myGrid is laudible (in my opinion), however the myGrid RDF has also been changing, and still is. We have just sent the myGrid folks a copy of what we hope will be a mutually agreeable document. If they sign-off on it as well, then everything else is in place. > is an unofficial, never made official, hack. > I think Duncan got what he needed, through formal or informal means. These (non-API) features of MOBY are documented in part on the new website (http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/moby_metadata), however the full documentation will take considerable time to write, so it isn't complete. Having multiple ways of obtaining information is a good thing, since it gives people a lot of flexibility in how they build their code, so I don't see this as a legitimate criticism. > As I said, tired from this stuff... > > There are a wide variety of ways you can make the situation better, but bitching about it isn't one of them. M From senger at ebi.ac.uk Fri Nov 4 00:58:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 05:58:09 +0000 (GMT) Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <436AF39A.1030104@illuminae.com> Message-ID: Mark, I am not bitching around... I am trying to make Biomoby clear. It was always the major Biomoby problem: you have a good idea, but you are not so good at presenting it clearly. So other people must take care about that part. You have Frank to make your documentation more precise, and you have me to make your API design better useable. During the last developer meeting, we had concluded that Biomoby is good in its essence but it is badly presented, it is not a "production-level" product, it does not have proper releases, etc. And until this is done, I will continue to claim that "Biomoby is killing itself by not being a real, "from-the-shelf" product. It is not that it cannot change (after all, it was always a research project) but it should change in predicted or well defined intervals and in a usual form. For example, you should not mix "the contents of RDF" and "the way how to get this RDF". The way how to get it should be fixed and relatively unchanged for longer, the contents itself may be labelled as "not-yet-stable", so it can changed more often. But you do not support this if you do not stick always with the API you yourself created. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 4 01:37:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 06:37:49 +0000 (GMT) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Message-ID: > Martin: MOBY Objects are just syntax, so there is no such thing as a > "core" data-type for MOBY objects. They don't have an "essense"! > Of course, the objects are just syntax (with semantics added by documentation). But let's not play with the words... What you are saying (IMHO) is that you like to have there also an additional attribute that would define an "essence". In your other email, you called it a "primary contents". You are also saying that two objects may have the same structure, but they can differ by this "primary contents" atribute. I can have an object X that has two members: FASTA and Annotation, and an object Y that has the same members. But Object X inherited from Annotation and added FASTA (because I am creating this object for analyzing various kind of annotations, for example), and the object Y inherited from FASTA and added Annotation as a member (because I am using Y for dealing with sequences). [This is what Andrew said about having multiple users of the same data. Yes, Andrew, I had my cup ot tea :-) ] You are right that to find the ISA hierarchy of objects X and Y you need to traverse back. The attribute "primary contents" would help you to find what you need without traversing back. But they may be other members (children) that you wish to know where they come from - so you would need (theoretically) more and more "essence" attributes. In other words, you may be interested in a complete hierarchy without traversing it back using a registry, but you do not have it because the Biomoby XML message is flatten! This situation is actually not a consequence of banning inheriting from primitives but a consequence of a unfortunate (flatten) design of Biomoby XML message from the beginning. (Now you know what I was bitching around, and lobbying in Vancouver meeting.) If the Biomoby message is a "usual" type of XML, you would have all. For example, and simplified, my X and Y objects would be: hello atata atata hello Just for the readers, what you have now is: hello atata hello atata Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From adf at ncgr.org Fri Nov 4 02:18:53 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Fri, 4 Nov 2005 00:18:53 -0700 (MST) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi again- I'm not sure I have completely grasped your example, but the point about XML hierarchy vs "flattening" is I think quite important. I can't speak to the MOBY object structure very much, but with the RDF-graph mentality, you don't flatten everything, i.e. paths between objects can be traversed via properties that connect them, though there is not a single root at which all paths must begin as with XML. My opinion is that the rootedness and guaranteed depth-first traversal of XML streams is quite nice when you are exchanging messages that are designed for a single purpose that is understood by sender and receiver; but, when the point is merely to represent data (not what is to be done with it), there is no reason to believe that one starting point is more privileged than another- this is IMHO one reason why relational dbs are so versatile and powerful. I might benefit from some clarification of your example. I can easily imagine a sensible case of a sequence with an annotation with a sequence (consider the translation of a CDS on a genomic sequence). The two sequences have different relationships to the annotation but are in themselves both the same type of thing (ignoring the protein/DNA difference). But, there is no reason I can see to treat them differently in terms of "hierarchy" until you provide a context for choosing the "root perspective". Have some more tea, I'm relieved that you haven't completely shut out those of us who can't help using the RDF-word... (sounds like there have been a lot of conversations I have been blissfully unaware of). Andrew > Of course, the objects are just syntax (with semantics added by > documentation). But let's not play with the words... > What you are saying (IMHO) is that you like to have there also an > additional attribute that would define an "essence". In your other email, > you called it a "primary contents". > You are also saying that two objects may have the same structure, but > they can differ by this "primary contents" atribute. I can have an object > X that has two members: FASTA and Annotation, and an object Y that has the > same members. But Object X inherited from Annotation and added FASTA > (because I am creating this object for analyzing various kind of > annotations, for example), and the object Y inherited from FASTA and added > Annotation as a member (because I am using Y for dealing with > sequences). [This is what Andrew said about having multiple users of the > same data. Yes, Andrew, I had my cup ot tea :-) ] > You are right that to find the ISA hierarchy of objects X and Y you > need to traverse back. The attribute "primary contents" would help you to > find what you need without traversing back. > But they may be other members (children) that you wish to know where > they come from - so you would need (theoretically) more and more "essence" > attributes. In other words, you may be interested in a complete hierarchy > without traversing it back using a registry, but you do not have it > because the Biomoby XML message is flatten! > This situation is actually not a consequence of banning inheriting from > primitives but a consequence of a unfortunate (flatten) design of Biomoby > XML message from the beginning. (Now you know what I was bitching around, > and lobbying in Vancouver meeting.) If the Biomoby message is a > "usual" type of XML, you would have all. For example, and simplified, my X > and Y objects would be: > > > hello > > atata > > > > > atata > > hello > > > > Just for the readers, what you have now is: > > > hello > atata > > > > hello > atata > > > Cheers, > Martin > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From senger at ebi.ac.uk Fri Nov 4 02:43:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 07:43:11 +0000 (GMT) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi, Nice to hear from you. Yout email helps to clarify the issues. They are (at least for now) two issues: rootedness (not mentioned in my neither Mark's emails) and flatteness. Rootedness (or not rootnedness) can be addressed by choosing pure XML message or RDF-based message. Flatteness is an issue only for pure XML messages (RDF is not flatten by default). So we have (beter: would have) three ways how to pass Biomoby messages: 1) Flatten traditional XML. This is the current situation in Moby-S. Because of this flatteness, Mark finds problems with not knowning the "primary contents" without traversing/contacting Biomoby registry. 2) Hierarchical traditional XML. This creates more complex messages but it is fully in the XML concepts. It carries all parental, ISA relationships. This is what Moby-S does not use. And there is no strong movement to this (except me advocating at least discussion about it). 3) RDF-based message. This would, additionally to not being flat, so keeping ISA hierarchy, add also non-rootedness. There is no discussion whether to move Moby-S this direction. My guess is that if we move Moby-S to any big changes regarding the message structure, it would probably be better to jump here and skip the "hierarchical traditional XML" structure. One last comment regarding rootedness: If you interpres a message, you always need to know when to start, so anyway you define a root node. This is the same for RDBS: you need to know which table to start with. So the rootedness is not about "not having a root" but about "having more roots than just one". But that is very probably what you meant anyway. > I might benefit from some clarification of your example. I can easily imagine > a sensible case of a sequence with an annotation with a sequence > I can clarify further, but it seems to me that you got it already right. Yes, your example is a better way to say what I was expressing. But please let me know if I can clarify better. > Have some more tea, I'm relieved that you haven't completely shut out those > of us who can't help using the RDF-word... > I am not against RDF. I am just against jumping to it without saying why. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Fri Nov 4 05:51:14 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 11:51:14 +0100 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> Message-ID: <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> On 3-Nov-2005, at 5:18 PM, Mark Wilkinson wrote: > On Thu, 2005-11-03 at 12:17 +0100, Pieter Neerincx wrote: > > >> Forbidden > > All these that I can find are now fixed. Thanks! > I was paranoid last night and > switched off execute permissions on all folders in the CVS except for > the ones that I knew contained documentation because it makes me > nervous > having end-user-writable executable folders on our website! > > >> Furthermore I added a page to the Docs in the CVS some time ago, but >> I can not find it anywhere on the new website... > > where? It's in moby-live/Docs/Central/ Pieter > > M > > > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Nov 4 07:12:43 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 13:12:43 +0100 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <436A4AB5.6050903@cnb.uam.es> References: <436A4AB5.6050903@cnb.uam.es> Message-ID: <781B1075-CF65-4D12-B4A5-5C1AB925C3FF@wur.nl> Hi David, On 3-Nov-2005, at 6:36 PM, David Gonz?lez Pisano wrote: > > - Pieter (3/11/2005) - refArticlename - NOT INCLUDED. I know this > can open a new can of worms about whether articlenames should be > mandatory or not, and we have talked about this in the past. The > problem is not with the exception reporting proposal, but with the > MOBY specification itself: if Articlenames are not mandatory, and I > can send several elements to the same type to my service, how can I > differenciate them? If there is no need to differenciate them, or > that does not make sense from the point of view of the service > execution, then it makes no sense from the point of view of the > exception reporting. If I cannot identify them individually, then I > cannot report exceptions about them individually and thus I have to > say "There is a problem with one or more or the inputs" Good point. It's more clear to me now and I think what you describe above is the best solution for the current BioMOBY spec. > If I can differenciate them because they have an Articlename, then > I use the refElement tag to refer to the problematic element... If you ignore the element name and use the articleName attribute to point to specific elements I do think it makes more sense to name that attribute refArticleName instead of refElement though. Having the refElement attribute contain a articleName adds unnescessary confusion to the error reporting mix. Cheers, Pieter > Does this make sense? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From duncan.hull at cs.man.ac.uk Fri Nov 4 07:28:13 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri, 04 Nov 2005 12:28:13 +0000 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> Message-ID: <436B53DD.9070100@cs.man.ac.uk> Mark, Martin and Eddie Thank you all for your rapid and informative responses to my question, I now have what I need. I'd be interested to hear about the RDF updates Eddie is working on, so keep us posted. Mark Wilkinson wrote: > I hope you aren't writing another thesis saying nasty things about MOBY! I hope I've never said nasty things about MOBY, at least not while I was sober... I frequently say nasty things about RDF, but thats a seperate issue :) BTW: We're writing a paper for Dubya Dubya Dubya http://www2006.org/ and BioMOBY is a core part of the related work section, so I needed an RDF example for illustration. If the paper makes it into the 15% of submissions that get accepted, we can add it to the growing list of BioMOBY publications...fingers crossed. Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From markw at illuminae.com Fri Nov 4 09:31:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 06:31:26 -0800 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436B53DD.9070100@cs.man.ac.uk> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> <436B53DD.9070100@cs.man.ac.uk> Message-ID: <436B70BE.2090007@illuminae.com> Hi Duncan! > Thank you all for your rapid and informative responses to my question, > I now have what I need. I'd be interested to hear about the RDF > updates Eddie is working on, so keep us posted. I believe that the LSID resolver and the RESOURCES script are both now outputting our latest version of the Service Instance RDF. We're sending it to Pinar today along with the changes that are required in the myGrid ontology to make it compatible (i.e. things that we think are wrong in the myGrid ontology... cheeky buggers that we are!). Hopefully this will be useful to you in that you will be able to write a single tool to explore both registry systems for your research. >> I hope you aren't writing another thesis saying nasty things about MOBY! > > I hope I've never said nasty things about MOBY, at least not while I > was sober... :-) I know :-) Just teasing. > BTW: We're writing a paper for Dubya Dubya Dubya http://www2006.org/ > and BioMOBY is a core part of the related work section, so I needed an > RDF example for illustration. Excellent! > If the paper makes it into the 15% of submissions that get accepted, > we can add it to the growing list of BioMOBY publications...fingers > crossed. Excellent! Good luck! M > Duncan > From markw at illuminae.com Fri Nov 4 09:55:51 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 06:55:51 -0800 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436B70BE.2090007@illuminae.com> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> <436B53DD.9070100@cs.man.ac.uk> <436B70BE.2090007@illuminae.com> Message-ID: <436B7677.9010301@illuminae.com> > We're sending it to Pinar today along with the changes that are > required in the myGrid ontology to make it compatible (i.e. things > that we think are wrong in the myGrid ontology... cheeky buggers that > we are!). Of course, our suggestions may be complete rubbish... (sorry myGrid folks - the message about sounded MUCH funnier in my head than it came out on paper! :-) ) M > From akerhornou at imim.es Fri Nov 4 10:44:20 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 04 Nov 2005 16:44:20 +0100 Subject: [MOBY-dev] Registrying a moby service that takes an input collection Message-ID: <436B81D4.6040102@imim.es> Hi everyone, I want to register, at icapture registry, a moby service that takes a collection of DNASequence objects (the service is called 'runMatScanGFFCollection') The registration seems fine, but i get this message errors when trying to retrieve information from the registry (using a customised perl script of ours): -------------------------------> ../retrieveService.pl -x 4 -s runMatScanGFFCollection -w genome.imim.es * Name: runMatScanGFFCollection * Contact e-mail: akerhornou at imim.es * Provider: genome.imim.es * URL: http://genome.imim.es/cgi-bin/moby/MobyServices.cgi * Type: Analysis * Category: moby * Description: Promoter regions analysis program. Matscan is a program to search putative binding sites in genomic sequences. You can search for example the Transfac database, but also MEME or jaspar matrices. This service only accepts a collection of DNASequence objects and returns a collection of GFF objects (one GFF object for each DNASequence). If you want to give MatScan output to Meta-alignment program, you MUST use the 'log-likelihood matrix' mode. * Input: articleName: upstream_sequences collection of => articleName: objectType: DNASequence Use of uninitialized value in pattern match (m//) at /home/ug/arnau/cvs/moby-live/Perl/MOBY/Client/CollectionArticle.pm line 189. Use of uninitialized value in pattern match (m//) at /home/ug/arnau/cvs/moby-live/Perl/MOBY/Client/CollectionArticle.pm line 189. No such method: MOBY::Client::CollectionArticle::namespaces at ../retrieveService.pl line 162 <------------------------------------ Does it mean the registration has failed ? Anyway, the service is visible and i have also tried to execute it using taverna 1.3 and it fails (i have attached a workflow). i get this error, ERROR 2005-11-03 17:55:52,228 (org.biomoby.client.taverna.plugin.BiomobyTask:233) - Error invoking biomoby service for biomoby java.lang.ClassCastException at org.biomoby.client.taverna.plugin.BiomobyTask.execute(BiomobyTask.java:95) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenerateTemplates(ProcessorTask.java:462) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocationWithRetryLogic(ProcessorTask.java:407) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(ProcessorTask.java:329) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithoutIteration(ProcessorTask.java:521) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(ProcessorTask.java:261) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(ProcessorTask.java:199) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) Any idea why it fails ? thanks, Arnaud -------------- next part -------------- A non-text attachment was scrubbed... Name: iCapture_getUpstreamSeqfromEnsembl_MatScanCollection.xml Type: text/xml Size: 2754 bytes Desc: not available Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20051104/d9bbea1f/iCapture_getUpstreamSeqfromEnsembl_MatScanCollection-0002.xml From markw at illuminae.com Fri Nov 4 11:00:24 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 08:00:24 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> Message-ID: <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> > It's in moby-live/Docs/Central/ Perhaps move it into moby-live/Docs/MOBY-S_API where the other documents are. It's important to have them all in one place. That folder currently doesn't have an index.html file - only an index_API.html. If your document is API related, then you should add a link to it in the index_API.html file. If it isn't, then perhaps make an index.html file with appropriate links to both your document and to the index_API.html file. I'll change the links on the website to make it accessible. these are all in the CVS. M From markw at illuminae.com Fri Nov 4 11:05:52 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 08:05:52 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436B81D4.6040102@imim.es> References: <436B81D4.6040102@imim.es> Message-ID: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> I'll address the first part... > <------------------------------------ > > Does it mean the registration has failed ? You need to check the return value of your registration attempt - a small XML object is returned to you that contans (among other things - see the API) a boolean 1/0 as to success or failure of your registration. Your registration was successful (I just checked the database). The client-side problem is a new one for me. I'll try to duplicate it here later. The Taverna problem I will leave to Eddie to answer (though I think I know what the answer is) M From adf at ncgr.org Fri Nov 4 11:16:09 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Fri, 4 Nov 2005 09:16:09 -0700 (MST) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi again- > One last comment regarding rootedness: If you interpres a message, you > always need to know when to start, so anyway you define a root node. This > is the same for RDBS: you need to know which table to start with. So the > rootedness is not about "not having a root" but about "having more roots > than just one". But that is very probably what you meant anyway. Well, not exactly. Certainly for RDBMS the theory is that the starting point(s) are irrelevant : which table to start with for a query involving joins is an implementation detail determined not by your query message but by the optimizer; similarly the row in a table that is processed first is immaterial to the sense of the query. In terms of serialization yes, you must pick a first element (otherwise it wouldn't be serial!), but RDF as a data model (not a concrete syntax) seems to be inherently about "random access"; e.g. the ability to ask for all resources having a given property (regardless of what class they belong to) is perhaps even more "unrooted" than RDBMs in which you clearly specify the tables to which your desired instances belong- but it is probably a wrong analogy to pair tables with classes- better would be to think of each property as its own two-element "relation". If pressed to comment on the actual practical implication of taking one attitude rather than another, my thoughts are not entirely clear, but I would claim that it has to do with thinking about "service descriptions" in part as defining queries that extract the data that they will process from a given dataset rather than defining message structures that they expect a client to formulate and send to them. The former approach is along the lines of the data-driven "dynamic discovery" idea of ISYS. This is also the direction I think semantic MOBY is in some ways trying to take. > I am not against RDF. I am just against jumping to it without saying > why. I am in whole-hearted agreement with that attitude. I feel the same way about XML ;) In all seriousness though, I think you are absolutely right to insist on conceptual clarity in these decisions and that there are areas in the MOBY problem space where RDF is NOT the right approach. Regards, -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From edward.kawas at gmail.com Fri Nov 4 11:18:03 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 4 Nov 2005 08:18:03 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninput collection In-Reply-To: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <000c01c5e15b$563059d0$6600a8c0@notebook> Hi, The problem is on the side of the service provider: They advertise a collection as the output, yet this is the output: 2000 TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGAAAG TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTTTTT AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGTAGG GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAAGTA AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAGTGG TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAGGGG CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAGACA AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAATCTG GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAGACA CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATGAAG TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACCTCT GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAGGCG CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATGTTG GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAAGTG CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGATTA CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTTTTT TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTTGGC TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGTAGT TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGGGTT TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGGCCT CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGTTTC TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCTAAG GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGGCAG CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGCGAG CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCCTTT TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCCACC GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTGCTC TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCTCCA GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGCTCC ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGAGTG TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGGCCC TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGGCCG AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCCCTG TCCGGCCAGCCCCTCGAAGC 2222:NCBI35:8:11695664:11697663:1 Not a collection. If you are the service provider, you must ensure that you output what you state that you will. Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Friday, November 04, 2005 8:06 AM > To: Arnaud Kerhornou; Core developer announcements > Subject: Re: [moby] [MOBY-dev] Registrying a moby service > that takes aninput collection > > I'll address the first part... > > > > > <------------------------------------ > > > > Does it mean the registration has failed ? > > You need to check the return value of your registration > attempt - a > small XML object is returned to you that contans (among > other things - > see the API) a boolean 1/0 as to success or failure of > your > registration. > > Your registration was successful (I just checked the > database). The > client-side problem is a new one for me. I'll try to > duplicate it here > later. > > The Taverna problem I will leave to Eddie to answer > (though I think I > know what the answer is) > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Fri Nov 4 11:01:33 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 04 Nov 2005 17:01:33 +0100 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436B85DD.7060907@cnb.uam.es> Hi everybody, I think Martin is right about a fixed and relatively unchanged way to obtain the RDF representation for each one of the registered services, objects and namespaces. If you are telling MOBY RDF structure is evolving, then RDF files published by any one of the service providers must be updated each time i changes. And also, there should be some well-known APIs (or procedures) to ease the automation of that process. Currently, the RDFs I have are from the Jurassic MOBY! Best Regards, Jos? Mar?a Martin Senger wrote: > Mark, > I am not bitching around... I am trying to make Biomoby clear. It was > always the major Biomoby problem: you have a good idea, but you are not so > good at presenting it clearly. So other people must take care about that > part. You have Frank to make your documentation more precise, and you have > me to make your API design better useable. > During the last developer meeting, we had concluded that Biomoby is > good in its essence but it is badly presented, it is not a > "production-level" product, it does not have proper releases, etc. And > until this is done, I will continue to claim that "Biomoby is killing > itself by not being a real, "from-the-shelf" product. > It is not that it cannot change (after all, it was always a research > project) but it should change in predicted or well defined intervals and > in a usual form. For example, you should not mix "the contents of RDF" and > "the way how to get this RDF". The way how to get it should be fixed and > relatively unchanged for longer, the contents itself may be labelled as > "not-yet-stable", so it can changed more often. But you do not support > this if you do not stick always with the API you yourself created. > > Martin > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From akerhornou at imim.es Fri Nov 4 11:16:37 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 04 Nov 2005 17:16:37 +0100 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> References: <436B81D4.6040102@imim.es> <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <436B8965.9060705@imim.es> Mark Wilkinson wrote: >I'll address the first part... > > >><------------------------------------ >> >>Does it mean the registration has failed ? >> >> > >You need to check the return value of your registration attempt - a >small XML object is returned to you that contans (among other things - >see the API) a boolean 1/0 as to success or failure of your >registration. > > > it actually returned 1 >Your registration was successful (I just checked the database). The >client-side problem is a new one for me. I'll try to duplicate it here >later. > > > ok, thanks Arnaud >The Taverna problem I will leave to Eddie to answer (though I think I >know what the answer is) > >M > > > > > From akerhornou at imim.es Fri Nov 4 12:21:33 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 04 Nov 2005 18:21:33 +0100 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninput collection In-Reply-To: <000c01c5e15b$563059d0$6600a8c0@notebook> References: <000c01c5e15b$563059d0$6600a8c0@notebook> Message-ID: <436B989D.8040108@imim.es> Hi Eddie, I'm the service provider of getUpstreamSeqfromEnsembl and i've checked the apache log file, and i get a collection back (giving a list of ensembl gene identifiers, 'ENSG00000160087' and 'ENSG00000160182' in a text-formatted object): 2000 ACCCGTGTAAATAAATCATGTCTCCCTAAAATGTATAAAAGCGAGCTGTGCCACATGCACCTTGGGCACCTCCCGAGATGTCATGGGTGTGTCCTTAACCTTGGCAAAACAAACTTTCTAAAGGGACTGAGACCTTCCTCAGTTTGCACCCTCCAGGCTGGGTTCTCTGTCCCTCAAGCATCCCCTGGCCAGACAATCCCTGCTGTTCAGAGGCAGCCAAGGCTTTCTGGTCCAACCCTGGGGGCTGGAGGAGGTGGGGGCAGGAGGTGGTAACTGGGTTGGGGGATGTTTTCTTGGTTGCCAAAGCAGAGGGTGCCCCCCGCTGCTCAAGATGCTGAGGGTGGTCCCTGTTGTCCTATTCCTGAAGCTGCCAGAGGAAGTCCCTCCGGAGGGCTGGCCCACAGCAGAAGGGCTGCTCCTGCCCTCAGAGGGCAATCTCAGGGTTGAGAAGGTTACAGCCACCATCTGCCACCAACCTAGCTGCTTGTGCCGATCCCACTGGCCAAGGCCATCGGCTCTATGGCTAGAGGCCTGGGCAGCCTGTGTCCTGCTTACCAGAAGGCCACAGATGCGGGTGGGTGGGGTGGTGGGGTCTTGGCAAGACGTGCTGGCCACACCTGTCCGGGGCACCTTCTCCCTGGGGTGTGACTCAGCCATGCTCCTGAGCAGGGGCCTCTGAGTTGAGCCTCGCTGCAGTCTTCCCAGCTGCAGGGCCCCCACAGGTGTGCTGTCATCGCACACTACTGAGGGACAGACAAGGCAGAGCGGGCCTCCATCTGCCGCGGGCCACAGCCGTGAGTGTGCATGCGAGTGGATGTGCTGGTGCCTGTATCTGCGGCCGGTGTGGCTTCCCTCACATAACTTTCCATGCTGTGAAAACAGTTTGGCCTGCCCTGCATGGGAACGGCAGAGGCCTGAGAGGAGGCAGAGGAAGGAGGCTGGATGCTGAGATGTTCTCCGAAGGTGGAGCCGGTGACGGCAGTAATGGAGGCAGGCTGGATTCCCACGGGCTGAGGCTGCGTGGACACTCCTCCTGGCTTCTGCCCCACGGCCTGCAGCAACGTCTCAGACCCACCAAGGTGTCCCAGAGGGCCAGAGTCAGGGCTGAGCATGGACACAGCCTGCCCTCTGCCCGTAGCCACAGCGGGACTGACCCTCAATATTCAGCCACCTTGCTGACCTGTGGTTGTTCCTGAGAGGCAGTCAGGGTTGGGGCAAAGGAGAGGGCCACAGGCAGCCAGGTGGCGAGGTCCACCTCCTGATCCCCCACCAGGGGACCACCCTCAGCTCCCCGCTGTCCTCAGCGGCCTCTCAGGGAGGCGGTGGGCTGCGCGCCTGCCCCCAGCGTCCCACCCCAGCGCCCCGCCACCTACCGCTCTCTCCCAATGTGTCTGGGGTCAGAGAGAGGTGGAGAGGACGCAGCGCCCCGCGCTTTCTGCAGTCTGTCCAAGGGGAGGTCAGGGGCATCCCGGGGCTGGGCAGGCACCTGCAGGGGAGGGTGCTGCGGCGCGGACGTGGGTTGCAAAGAGATGCCACGCGTGTCACTCTCGGGTCCCTGAACGAGAGAGCTCTGAGCTCCCTGGAGCCCAACCCTCCACTGAGCCTCCAGGGGCCCGGGACGCTCCATGCCCGGGCCGCGCCGCGCCTCCCCTAAGGGCCGGGTGGGGCGTGGGAGCGGAGGACAAGGCGGGAGCCGGGAGGCGGGAGGGTCGGGGTTCTTTCTCCACCGGGGTCGCCCTCAGCCGGGCCTGCCGCCCTGGGCCGTGGCACATGGGGAGGGAAGCGCGCGGCTTCGGGGTCTGGGGCTCTCGCGCCCACTAACGGTGCCCGGAGCCGCCCGCCAGTGCGCAAGCGCCGCCCCGCCCCCCGCCCCATCCCCCACCCCGGGGTCGACGGCGACAGAGAGTCGTGGGCGCGGTCCGCCAGTCTGCCTAGAGCGGCCAGCCCTCCCCCTCCCTCCTCACCGCCCCGGACCGCGCACCGGAAGCAGAAGCTAGGCT ENSG00000160087:NCBI35:1:1249158:1251157:-1 2000 GGACTTGAGCATTTGTGGATTTTGGCATCCCTGGGTGGGGGGTCCTGAAACCAGTCCCCCAGGGGTACTAAGGGACGACTGCATTGTATTTTAAGTTCATTTTCCCTTTCCCTGGTTAATGAATATTTATTTTGCTTTTCTTTCCCTCCTTTCCTTCCTTCCTTCTTTCCCTGTTTCCAGCTGTTACAAACAATGCTAAAAAGAATATCTTTGCCTGTGTTTTCTTCTGCCCAAGTATGAACATGTTTCTGGGATTAAGAGACCAGGCCTGGAAACAGAAGAATTTGCTGAGCTGTAAAATCTGTATGGCTTAAACCTCACCGAACACTGCCCACCTTTTCTCCAAATGATTGTGCAATTTACATCCCATTTCCAAGAGCCCCCATTTTGATCCGAGAAATTAGAGCAGCGAAAACCACCGTCACTATGAGCACCACCCTGGGCCTGGTGCCCCCGTCCTGTTTTCAATAAACTTAAGCTGACCACAGAGGACACCAGGCCTCGGCCCCTCCCTGGGTCCTGCGGTCAGGCCCCTCCTGGAGACCCTGGCCCAGGAGTGGAGACCCCGGTGCAGGAGTGGCAGCCCTGGAGGAGGGGCTGGGTCCTGGGATGGAGCGAAGAGGAACATGGCCGCCCCCATTCTGGCCCAGGCTCCCCTCCCAGAGGGGCTGCAGAAATGTACTGACTAGGTCACCCAAGAAAAGATAGTACCTTTGTTAGGCTAGCATGCATTTTCCTCAGGGCCTAATTTCTCACTGAAGAAGAAAAGATTTCTCCTGTTGTCCATTTCTTCATGCAGCTCTTCAACAGCTGTTTCTCGAATGCCAATCAAAGCCACTGTTCTAGGGTCTGGGGCCACCTCAAGGCACTAGGAGATGAGGACTTCTGCTCCCATGCGCCCTCCCGTCTGCTGCAGGGAGGAGTGCAATGAATAAATAACCAACATAATGTGTCAGTCACTTGTTTTATCCACCAGGAGGTAATAAGAGCTATGAAAGAGAAAGCTCCGAGCAGGGGAGGGGAGTGAGGCATGGTACAGGAGAGCAGGAGGCTGTCCTCTAAAATACAGGAGTCCAGGGGACCAACTGGGAAGGTGTGGGAGGGGGAGGGAGGGAGCCCCATAGACACAGGGGAGTGAACCACGTTCACTTTGTCAGTTTTTGATGGCAGCTCGTATATACTATTTTTTTCTCCCTCCTGCCCCCAGCCCCTCCCAGAAGGAGACTTAATCTGTCGCTCAGGCTGGAGTGCAGTAGGGTGATCTCGACTCACTGCAACCTCCGCCTCCCAGGTTCAAGTGATTCTCCTGACTTAACCTCCAGAGTAGCTAGGATTACAGGCACCCGCCACCATGCCTGGCTAATTTTTGTATTTTTTTTTTTTGTAGAGACGGGGTTTCGCCATGTTGGCCAGGCTAGTCTCAAACTCCTGACTTTAAGTGATCCGCCTGCTTTGGCCTCCCAAAGTGTTGGGATTACAGGCGTGAGCCACTGCGCCAGGCCTACAATTTCATTATTAAAACAATTCCACTGTAAAAGAATTAGCTTAGGCCTAGACGGAATGGGCTTCATGAGCTCCTTCCCTTCCCCCTGCAAGGTCACGGTGGCCACCCCGTGAGCCACTGTTGTCACGGCCAAGCCTTTTTCCGGCCATCTCTCACTATGAATCACTTCTGCAGTGAGTACAGTATTTACCCTGGCGGGAGGGCCTCTCAGATATGAGTAGGACCTGGATTAAGGTCAGGTTGGAGGAGACTCCCATGGGAAAGAGGGACTTTCTGAATCTCAGATCCCTCAGCCAAGATGACCTCACCACATGTCGTCTCTGTCTATCAGCAAATCCTTCCATGTAGCTTGACCATGTCTAGGAAACACCTTTGATAAAAATCAGTGGAGATTATTGTCTCAGAGGATCCCCGGGCCTCCTTAGGCAAATGTTATCTAACGCTCTTTAAGCAAACAGAGCCTGCCCTATAAAATCCGGGGCTCGGGCGGCCTCTC ENSG00000160182:NCBI35:21:42659714:42661713:-1 but you're right taverna displays a list of two simple DNASequence objects, so i don't understand what i am doing wrong ? cheers, Arnaud Edward Kawas wrote: >Hi, > >The problem is on the side of the service provider: > >They advertise a collection as the output, yet this is the >output: > > > > > > > > id="ENSG00000079459"> > namespace="" id="" articleName="Length"> >2000 > > namespace="" id="" articleName="SequenceString"> >TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGAAAG >TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTTTTT >AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGTAGG >GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAAGTA >AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAGTGG >TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAGGGG >CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAGACA >AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAATCTG >GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAGACA >CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATGAAG >TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACCTCT >GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAGGCG >CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATGTTG >GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAAGTG >CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGATTA >CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTTTTT >TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTTGGC >TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGTAGT >TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGGGTT >TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGGCCT >CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGTTTC >TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCTAAG >GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGGCAG >CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGCGAG >CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCCTTT >TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCCACC >GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTGCTC >TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCTCCA >GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGCTCC >ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGAGTG >TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGGCCC >TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGGCCG >AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCCCTG >TCCGGCCAGCCCCTCGAAGC > > namespace="" id="" articleName="Description"> >2222:NCBI35:8:11695664:11697663:1 > > > > > > > >Not a collection. > >If you are the service provider, you must ensure that you >output what you state that you will. > >Hope this helps, > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>dev-bounces at portal.open-bio.org] On Behalf Of Mark >>Wilkinson >>Sent: Friday, November 04, 2005 8:06 AM >>To: Arnaud Kerhornou; Core developer announcements >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service >>that takes aninput collection >> >>I'll address the first part... >> >> >> >> >> >>><------------------------------------ >>> >>>Does it mean the registration has failed ? >>> >>> >>You need to check the return value of your registration >>attempt - a >>small XML object is returned to you that contans (among >>other things - >>see the API) a boolean 1/0 as to success or failure of >>your >>registration. >> >>Your registration was successful (I just checked the >>database). The >>client-side problem is a new one for me. I'll try to >>duplicate it here >>later. >> >>The Taverna problem I will leave to Eddie to answer >>(though I think I >>know what the answer is) >> >>M >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From Pieter.Neerincx at wur.nl Fri Nov 4 12:23:02 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 18:23:02 +0100 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> Message-ID: <775C08CD-2DC3-42DB-85F6-0F2DE5D7F80F@wur.nl> Ok, will do that sometime this weekend ... On 4-Nov-2005, at 5:00 PM, Mark Wilkinson wrote: > >> It's in moby-live/Docs/Central/ > > Perhaps move it into moby-live/Docs/MOBY-S_API where the other > documents > are. It's important to have them all in one place. > > That folder currently doesn't have an index.html file - only an > index_API.html. If your document is API related, then you should > add a > link to it in the index_API.html file. If it isn't, then perhaps make > an index.html file with appropriate links to both your document and to > the index_API.html file. I'll change the links on the website to make > it accessible. > > these are all in the CVS. > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Fri Nov 4 12:49:33 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 4 Nov 2005 09:49:33 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninputcollection In-Reply-To: <436B989D.8040108@imim.es> Message-ID: <000d01c5e168$1e0bdef0$6600a8c0@notebook> Sorry, it turns out you did nothing wrong. You found a bug that I have fixed and will commit to the Taverna cvs as soon as I stop getting timeout errors. In the meantime, download the taverna1.3.jar from the following location: http://bioinfo.icapture.ubc.ca/ekawas/jars/ and replace the one in the taverna-workbench-1.3/lib directory. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Arnaud > Kerhornou > Sent: Friday, November 04, 2005 9:22 AM > To: Core developer announcements > Subject: Re: [moby] [MOBY-dev] Registrying a moby service > that takes aninputcollection > > Hi Eddie, > > I'm the service provider of getUpstreamSeqfromEnsembl and > i've checked > the apache log file, and i get a collection back (giving a > list of > ensembl gene identifiers, 'ENSG00000160087' and > 'ENSG00000160182' in a > text-formatted object): > > > moby:articleName='upstream_sequences'> > > namespace='ENSEMBL' id='ENSG00000160087'> > articleName="Length">2000 > articleName="SequenceString">ACCCGTGTAAATAAATCATGTCTCCCTAA > AATGTATAAAAGCGAGCTGTGCCACATGCACCTTGGGCACCTCCCGAGATGTCATGGG > TGTGTCCTTAACCTTGGCAAAACAAACTTTCTAAAGGGACTGAGACCTTCCTCAGTTT > GCACCCTCCAGGCTGGGTTCTCTGTCCCTCAAGCATCCCCTGGCCAGACAATCCCTGC > TGTTCAGAGGCAGCCAAGGCTTTCTGGTCCAACCCTGGGGGCTGGAGGAGGTGGGGGC > AGGAGGTGGTAACTGGGTTGGGGGATGTTTTCTTGGTTGCCAAAGCAGAGGGTGCCCC > CCGCTGCTCAAGATGCTGAGGGTGGTCCCTGTTGTCCTATTCCTGAAGCTGCCAGAGG > AAGTCCCTCCGGAGGGCTGGCCCACAGCAGAAGGGCTGCTCCTGCCCTCAGAGGGCAA > TCTCAGGGTTGAGAAGGTTACAGCCACCATCTGCCACCAACCTAGCTGCTTGTGCCGA > TCCCACTGGCCAAGGCCATCGGCTCTATGGCTAGAGGCCTGGGCAGCCTGTGTCCTGC > TTACCAGAAGGCCACAGATGCGGGTGGGTGGGGTGGTGGGGTCTTGGCAAGACGTGCT > GGCCACACCTGTCCGGGGCACCTTCTCCCTGGGGTGTGACTCAGCCATGCTCCTGAGC > AGGGGCCTCTGAGTTGAGCCTCGCTGCAGTCTTCCCAGCTGCAGGGCCCCCACAGGTG > TGCTGTCATCGCACACTACTGAGGGACAGACAAGGCAGAGCGGGCCTCCATCTGCCGC > GGGCCACAGCCGTGAGTGTGCATGCGAGTGGATGTGCTGGTGCCTGTATCTGCGGCCG > GTGTGGCTTCCCTCACATAACTTTCCATGCTGTGAAAACAGTTTGGCCTGCCCTGCAT > GGGAACGGCAGAGGCCTGAGAGGAGGCAGAGGAAGGAGGCTGGATGCTGAGATGTTCT > CCG! > AAGGTGGAGCCGGTGACGGCAGTAATGGAGGCAGGCTGGATTCCCACGGGCTGAGGCT > GCGTGGACACTCCTCCTGGCTTCTGCCCCACGGCCTGCAGCAACGTCTCAGACCCACC > AAGGTGTCCCAGAGGGCCAGAGTCAGGGCTGAGCATGGACACAGCCTGCCCTCTGCCC > GTAGCCACAGCGGGACTGACCCTCAATATTCAGCCACCTTGCTGACCTGTGGTTGTTC > CTGAGAGGCAGTCAGGGTTGGGGCAAAGGAGAGGGCCACAGGCAGCCAGGTGGCGAGG > TCCACCTCCTGATCCCCCACCAGGGGACCACCCTCAGCTCCCCGCTGTCCTCAGCGGC > CTCTCAGGGAGGCGGTGGGCTGCGCGCCTGCCCCCAGCGTCCCACCCCAGCGCCCCGC > CACCTACCGCTCTCTCCCAATGTGTCTGGGGTCAGAGAGAGGTGGAGAGGACGCAGCG > CCCCGCGCTTTCTGCAGTCTGTCCAAGGGGAGGTCAGGGGCATCCCGGGGCTGGGCAG > GCACCTGCAGGGGAGGGTGCTGCGGCGCGGACGTGGGTTGCAAAGAGATGCCACGCGT > GTCACTCTCGGGTCCCTGAACGAGAGAGCTCTGAGCTCCCTGGAGCCCAACCCTCCAC > TGAGCCTCCAGGGGCCCGGGACGCTCCATGCCCGGGCCGCGCCGCGCCTCCCCTAAGG > GCCGGGTGGGGCGTGGGAGCGGAGGACAAGGCGGGAGCCGGGAGGCGGGAGGGTCGGG > GTTCTTTCTCCACCGGGGTCGCCCTCAGCCGGGCCTGCCGCCCTGGGCCGTGGCACAT > GGGGAGGGAAGCGCGCGGCTTCGGGGTCTGGGGCTCTCGCGCCCACTAACGGTGCCCG > GAGCCGCCCGCCAGTGCGCAAGCGCCGCCCCGCCCCCCGCCCCATCCCCCACCCCGGG > GTCGACGGCGACAGAGAGTCGTGGGCGCGGTCCGCCAGTCTGCCTAGAGCGGCCAGCC > CTC! > CCCCTCCCTCCTCACCGCCCCGGACCGCGCACCGGAAGCAGAAGCTAGGCT g> > articleName="Description">ENSG00000160087:NCBI35:1:1249158 > :1251157:-1 > > > > namespace='ENSEMBL' id='ENSG00000160182'> > articleName="Length">2000 > articleName="SequenceString">GGACTTGAGCATTTGTGGATTTTGGCATC > CCTGGGTGGGGGGTCCTGAAACCAGTCCCCCAGGGGTACTAAGGGACGACTGCATTGT > ATTTTAAGTTCATTTTCCCTTTCCCTGGTTAATGAATATTTATTTTGCTTTTCTTTCC > CTCCTTTCCTTCCTTCCTTCTTTCCCTGTTTCCAGCTGTTACAAACAATGCTAAAAAG > AATATCTTTGCCTGTGTTTTCTTCTGCCCAAGTATGAACATGTTTCTGGGATTAAGAG > ACCAGGCCTGGAAACAGAAGAATTTGCTGAGCTGTAAAATCTGTATGGCTTAAACCTC > ACCGAACACTGCCCACCTTTTCTCCAAATGATTGTGCAATTTACATCCCATTTCCAAG > AGCCCCCATTTTGATCCGAGAAATTAGAGCAGCGAAAACCACCGTCACTATGAGCACC > ACCCTGGGCCTGGTGCCCCCGTCCTGTTTTCAATAAACTTAAGCTGACCACAGAGGAC > ACCAGGCCTCGGCCCCTCCCTGGGTCCTGCGGTCAGGCCCCTCCTGGAGACCCTGGCC > CAGGAGTGGAGACCCCGGTGCAGGAGTGGCAGCCCTGGAGGAGGGGCTGGGTCCTGGG > ATGGAGCGAAGAGGAACATGGCCGCCCCCATTCTGGCCCAGGCTCCCCTCCCAGAGGG > GCTGCAGAAATGTACTGACTAGGTCACCCAAGAAAAGATAGTACCTTTGTTAGGCTAG > CATGCATTTTCCTCAGGGCCTAATTTCTCACTGAAGAAGAAAAGATTTCTCCTGTTGT > CCATTTCTTCATGCAGCTCTTCAACAGCTGTTTCTCGAATGCCAATCAAAGCCACTGT > TCTAGGGTCTGGGGCCACCTCAAGGCACTAGGAGATGAGGACTTCTGCTCCCATGCGC > CCTCCCGTCTGCTGCAGGGAGGAGTGCAATGAATAAATAACCAACATAATGTGTCAGT > CAC! > TTGTTTTATCCACCAGGAGGTAATAAGAGCTATGAAAGAGAAAGCTCCGAGCAGGGGA > GGGGAGTGAGGCATGGTACAGGAGAGCAGGAGGCTGTCCTCTAAAATACAGGAGTCCA > GGGGACCAACTGGGAAGGTGTGGGAGGGGGAGGGAGGGAGCCCCATAGACACAGGGGA > GTGAACCACGTTCACTTTGTCAGTTTTTGATGGCAGCTCGTATATACTATTTTTTTCT > CCCTCCTGCCCCCAGCCCCTCCCAGAAGGAGACTTAATCTGTCGCTCAGGCTGGAGTG > CAGTAGGGTGATCTCGACTCACTGCAACCTCCGCCTCCCAGGTTCAAGTGATTCTCCT > GACTTAACCTCCAGAGTAGCTAGGATTACAGGCACCCGCCACCATGCCTGGCTAATTT > TTGTATTTTTTTTTTTTGTAGAGACGGGGTTTCGCCATGTTGGCCAGGCTAGTCTCAA > ACTCCTGACTTTAAGTGATCCGCCTGCTTTGGCCTCCCAAAGTGTTGGGATTACAGGC > GTGAGCCACTGCGCCAGGCCTACAATTTCATTATTAAAACAATTCCACTGTAAAAGAA > TTAGCTTAGGCCTAGACGGAATGGGCTTCATGAGCTCCTTCCCTTCCCCCTGCAAGGT > CACGGTGGCCACCCCGTGAGCCACTGTTGTCACGGCCAAGCCTTTTTCCGGCCATCTC > TCACTATGAATCACTTCTGCAGTGAGTACAGTATTTACCCTGGCGGGAGGGCCTCTCA > GATATGAGTAGGACCTGGATTAAGGTCAGGTTGGAGGAGACTCCCATGGGAAAGAGGG > ACTTTCTGAATCTCAGATCCCTCAGCCAAGATGACCTCACCACATGTCGTCTCTGTCT > ATCAGCAAATCCTTCCATGTAGCTTGACCATGTCTAGGAAACACCTTTGATAAAAATC > AGTGGAGATTATTGTCTCAGAGGATCCCCGGGCCTCCTTAGGCAAATGTTATCTAACG > CTC! > TTTAAGCAAACAGAGCCTGCCCTATAAAATCCGGGGCTCGGGCGGCCTCTC g> > articleName="Description">ENSG00000160182:NCBI35:21:426597 > 14:42661713:-1 > > > > > > > > but you're right taverna displays a list of two simple > DNASequence > objects, so i don't understand what i am doing wrong ? > > cheers, > Arnaud > > Edward Kawas wrote: > > >Hi, > > > >The problem is on the side of the service provider: > > > >They advertise a collection as the output, yet this is > the > >output: > > > > > > > > > > > > > > > > namespace="ENSEMBL" > >id="ENSG00000079459"> > > xmlns="http://www.biomoby.org/moby" > >namespace="" id="" articleName="Length"> > >2000 > > > > >namespace="" id="" articleName="SequenceString"> > >TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGA > AAG > >TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTT > TTT > >AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGT > AGG > >GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAA > GTA > >AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAG > TGG > >TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAG > GGG > >CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAG > ACA > >AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAAT > CTG > >GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAG > ACA > >CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATG > AAG > >TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACC > TCT > >GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAG > GCG > >CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATG > TTG > >GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAA > GTG > >CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGA > TTA > >CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTT > TTT > >TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTT > GGC > >TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGT > AGT > >TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGG > GTT > >TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGG > CCT > >CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGT > TTC > >TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCT > AAG > >GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGG > CAG > >CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGC > GAG > >CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCC > TTT > >TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCC > ACC > >GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTG > CTC > >TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCT > CCA > >GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGC > TCC > >ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGA > GTG > >TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGG > CCC > >TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGG > CCG > >AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCC > CTG > >TCCGGCCAGCCCCTCGAAGC > > > > >namespace="" id="" articleName="Description"> > >2222:NCBI35:8:11695664:11697663:1 > > > > > > > > > > > > > > > >Not a collection. > > > >If you are the service provider, you must ensure that you > >output what you state that you will. > > > >Hope this helps, > > > >Eddie > > > > > > > >>-----Original Message----- > >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > >>dev-bounces at portal.open-bio.org] On Behalf Of Mark > >>Wilkinson > >>Sent: Friday, November 04, 2005 8:06 AM > >>To: Arnaud Kerhornou; Core developer announcements > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby > service > >>that takes aninput collection > >> > >>I'll address the first part... > >> > >> > >> > >> > >> > >>><------------------------------------ > >>> > >>>Does it mean the registration has failed ? > >>> > >>> > >>You need to check the return value of your registration > >>attempt - a > >>small XML object is returned to you that contans (among > >>other things - > >>see the API) a boolean 1/0 as to success or failure of > >>your > >>registration. > >> > >>Your registration was successful (I just checked the > >>database). The > >>client-side problem is a new one for me. I'll try to > >>duplicate it here > >>later. > >> > >>The Taverna problem I will leave to Eddie to answer > >>(though I think I > >>know what the answer is) > >> > >>M > >> > >> > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://www.biomoby.org/mailman/listinfo/moby-dev > >> > >> > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Nov 4 16:41:50 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 22:41:50 +0100 Subject: [moby] [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> Message-ID: <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> On 02Nov2005, at 17:12, Mark Wilkinson wrote: > I think you're right - that's a much better data structure to be > passing > around. > > This does change the external (perl client) API, right? :-/ Yep, that's why I'm asking. I have no idea who is currently relying on the retrieveObjectDefinition call and what might break if I change it... So far I have heard no complaints, so I suggest I go ahead and make the change... > > Really, what the Perl client code needs is a good laundering. The > CommonSubs.pm module is a total mess after being modified piecemeal > over > the past 3 years... > > I wonder if we shouldn't just start a new module (or modules) that are > named by their domain of function (RegistryIO, OntologyIO, or > something > like that) and have all fresh code? Gradually we could migrate all > functionality into these modules. Client::Central has been around > since > the 0.1 prototype of MOBY in 2001 and has never been re-written top- > to- > bottom! That would be a good idea to get cleaner code, but for the time being it's not that bad! It works as advertised and gets my job done :). Try debugging SOAP::Lite and MIME::Parser... those are the ones that really need a complete make-over! > > I'm still waiting to hear about the re-funding attempts for MOBY... > fingers crossed! There will hopefully be a second opportunity > later in > the winter, so all is not lost if we fail. Good luck! Pieter > It would be great to have a > couple of extra hands dedicated to a complete code re-write > > M > > > > > On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: >> Hi all, >> >> Here is a question for those using the Perl API. In >> >> MOBY/Client/Central.pm >> >> we have a >> >> sub retrieveObjectDefinition >> >> which calls >> >> sub _ObjectDefinitionPayload { >> >> This produces an array for the objects, articleNames and lsids for >> the relationships of the object whose definition is requested. I'm >> wondering why this is an array. Currently I have to rely on the order >> of elements in this array to figure out which element is the object, >> which one is articleName, etc. These are the lines producing the >> array: >> >> 553 push @{ $relationships{$relationshipType} }, >> 554 [ $_->toString, $article, $rlsid ]; >> >> Is there any reason why this should be an array? I'd rather not have >> to rely on the order of the elements, so are there people who have >> any objections when I change this into a hash like in: >> >> push @{ $relationships{$relationshipType} }, >> { object => $_->toString, >> articleName => $article, >> lsid => $rlsid }; >> >> Cheers, >> >> Pieter >> >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 Sat Nov 5 04:03:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 5 Nov 2005 09:03:10 +0000 (GMT) Subject: [MOBY-dev] Biomoby registry down? Message-ID: ...or it just not reachable from here at IRRI now? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Sat Nov 5 06:56:27 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Nov 2005 12:56:27 +0100 Subject: [MOBY-dev] Biomoby registry down? In-Reply-To: References: Message-ID: <9E523DCF-FFF4-4460-936D-D9A7841934AA@wur.nl> I get connection time-outs as well at WUR, so it looks like it's down :(. Pieter On 05Nov2005, at 10:03, Martin Senger wrote: > ...or it just not reachable from here at IRRI now? > > Thanks, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 Phillip.Lord at newcastle.ac.uk Fri Nov 4 10:26:48 2005 From: Phillip.Lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 4 Nov 2005 15:26:48 -0000 Subject: [MOBY-dev] Please sir, can I have some more RDF? Message-ID: <6942EE35B530F84EAD432959F5E4DAB581BF67@largo.campus.ncl.ac.uk> Mark Wilkinson wrote: >> We're sending it to Pinar today along with the changes that are >> required in the myGrid ontology to make it compatible (i.e. things >> that we think are wrong in the myGrid ontology... cheeky buggers that >> we are!). > > Of course, our suggestions may be complete rubbish... (sorry myGrid > folks - the message about sounded MUCH funnier in my head than it > came out on paper! :-) ) I thought it was funny on paper. Besides which, it's true. There are things wrong with the mygrid ontology! Phil From akerhornou at imim.es Mon Nov 7 10:37:59 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 07 Nov 2005 16:37:59 +0100 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> Message-ID: <436F74D7.1010809@imim.es> Edward Kawas wrote: >Hi, > >This is happening, because Taverna is expecting an object >type of DNASequence, yet CommentedDNASequence is being >passed in. > > > okay, maybe i should have asked this before, the service returns CommentedDNASequence objects, and the service specs say DNASequence objects, but CommentedDNASequence is-a DNASequence. I designed the service to return DNASequence objects. Then a user asked me to add a description foreach sequence the service returns, so i just changed the type of object the service returns to CommentedDNASequence and I didn't changed the specification of the service because i thought i didn't have to. Does it mean it is not allowed to do so ? I have a similar problem with the next service in my workflow. This service analyzes DNASequence objects. But i get CommentedDNASequence objects from the retrieval service. Again i can not do that ? Arnaud >Eddie > > > >>-----Original Message----- >>From: Arnaud Kerhornou [mailto:akerhornou at imim.es] >>Sent: Monday, November 07, 2005 6:47 AM >>To: Edward Kawas >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service >>that takes an input collection >> >>ok, so i could modify my workflow to connect the >>DNASequence >>(Collection) output port to the input port of the next >>node. >> >>but why, in the case i use the port that says collection, >>do i get an >>empty collection tag, >> >>* "DNASequence (Collection)" gives me: >> >> >> >> >> > moby:articleName="upstream_sequences" /> >> >> >> >> >>why are the simples missing ? >> >>Arnaud >> >> >> >> > > From markw at illuminae.com Mon Nov 7 10:55:37 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 07 Nov 2005 07:55:37 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436F74D7.1010809@imim.es> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> <436F74D7.1010809@imim.es> Message-ID: <1131378937.15487.22.camel@bioinfo.icapture.ubc.ca> Strictly speaking, so long as you return an object that is an ISA child of what you have registered, you are compliant with the API. Having said that, if you *always* return a CommentedDNASequence, then you should probably re-register your service, since the intention is to register the most complex object type that you can guarantee to return in every case. Either way, you are API compliant, so if this is what is causing the problem, then it is a bug at our end. M On Mon, 2005-11-07 at 16:37 +0100, Arnaud Kerhornou wrote: > > Edward Kawas wrote: > > >Hi, > > > >This is happening, because Taverna is expecting an object > >type of DNASequence, yet CommentedDNASequence is being > >passed in. > > > > > > > okay, maybe i should have asked this before, the service returns > CommentedDNASequence objects, and the service specs say DNASequence > objects, but CommentedDNASequence is-a DNASequence. > > I designed the service to return DNASequence objects. Then a user asked > me to add a description foreach sequence the service returns, so i just > changed the type of object the service returns to CommentedDNASequence > and I didn't changed the specification of the service because i thought > i didn't have to. > > Does it mean it is not allowed to do so ? > > I have a similar problem with the next service in my workflow. This > service analyzes DNASequence objects. But i get CommentedDNASequence > objects from the retrieval service. Again i can not do that ? > > Arnaud > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Arnaud Kerhornou [mailto:akerhornou at imim.es] > >>Sent: Monday, November 07, 2005 6:47 AM > >>To: Edward Kawas > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service > >>that takes an input collection > >> > >>ok, so i could modify my workflow to connect the > >>DNASequence > >>(Collection) output port to the input port of the next > >>node. > >> > >>but why, in the case i use the port that says collection, > >>do i get an > >>empty collection tag, > >> > >>* "DNASequence (Collection)" gives me: > >> > >> > >> > >> > >> >> moby:articleName="upstream_sequences" /> > >> > >> > >> > >> > >>why are the simples missing ? > >> > >>Arnaud > >> > >> > >> > >> > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Nov 7 10:55:37 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 07 Nov 2005 07:55:37 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436F74D7.1010809@imim.es> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> <436F74D7.1010809@imim.es> Message-ID: <1131378937.15487.22.camel@bioinfo.icapture.ubc.ca> Strictly speaking, so long as you return an object that is an ISA child of what you have registered, you are compliant with the API. Having said that, if you *always* return a CommentedDNASequence, then you should probably re-register your service, since the intention is to register the most complex object type that you can guarantee to return in every case. Either way, you are API compliant, so if this is what is causing the problem, then it is a bug at our end. M On Mon, 2005-11-07 at 16:37 +0100, Arnaud Kerhornou wrote: > > Edward Kawas wrote: > > >Hi, > > > >This is happening, because Taverna is expecting an object > >type of DNASequence, yet CommentedDNASequence is being > >passed in. > > > > > > > okay, maybe i should have asked this before, the service returns > CommentedDNASequence objects, and the service specs say DNASequence > objects, but CommentedDNASequence is-a DNASequence. > > I designed the service to return DNASequence objects. Then a user asked > me to add a description foreach sequence the service returns, so i just > changed the type of object the service returns to CommentedDNASequence > and I didn't changed the specification of the service because i thought > i didn't have to. > > Does it mean it is not allowed to do so ? > > I have a similar problem with the next service in my workflow. This > service analyzes DNASequence objects. But i get CommentedDNASequence > objects from the retrieval service. Again i can not do that ? > > Arnaud > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Arnaud Kerhornou [mailto:akerhornou at imim.es] > >>Sent: Monday, November 07, 2005 6:47 AM > >>To: Edward Kawas > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service > >>that takes an input collection > >> > >>ok, so i could modify my workflow to connect the > >>DNASequence > >>(Collection) output port to the input port of the next > >>node. > >> > >>but why, in the case i use the port that says collection, > >>do i get an > >>empty collection tag, > >> > >>* "DNASequence (Collection)" gives me: > >> > >> > >> > >> > >> >> moby:articleName="upstream_sequences" /> > >> > >> > >> > >> > >>why are the simples missing ? > >> > >>Arnaud > >> > >> > >> > >> > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Nov 7 11:04:45 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 07 Nov 2005 08:04:45 -0800 Subject: [MOBY-dev] starting website redirect... Message-ID: <1131379485.15487.29.camel@bioinfo.icapture.ubc.ca> Hi MOBYers, I'm soon going to start re-directing HTTP traffic to the new website by default. This will give us the chance to port-over anything from the old site that we might have forgotten before it disappears. If there are things on the old site that you want/need, please grab them, or let me know and I'll grab them. Cheers! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Mon Nov 7 11:13:13 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 7 Nov 2005 16:13:13 +0000 (GMT) Subject: [MOBY-dev] starting website redirect... In-Reply-To: <1131379485.15487.29.camel@bioinfo.icapture.ubc.ca> Message-ID: > I'm soon going to start re-directing HTTP traffic to the new website by > default. This will give us the chance to port-over anything from the > old site that we might have forgotten before it disappears. > I lost the track... My feeling was that we are making a better web page. But now it seems that *in the same time* we are also changing a physical server. Is that correct? Is it also true that after moving to the new server, the new server will get (back) the old URL biomoby.org? > If there are things on the old site that you want/need, please grab > them, or let me know and I'll grab them. > With whom should I talked to give me enought priviledges to make the same what is cronning now for jMoby? And what time schedule for this should I plan? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Nov 7 18:42:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 7 Nov 2005 23:42:10 +0000 (GMT) Subject: [MOBY-dev] jMoby (AGAIN!) not compilable Message-ID: Please, correct it asap - whoever committed file ServiceDescrParser.java. Nobody can work if this happens. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Nov 9 17:10:19 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 9 Nov 2005 14:10:19 -0800 Subject: [MOBY-dev] rdf agent Message-ID: <003001c5e57a$604d32d0$6600a8c0@notebook> Hi, If anyone received any messages from the rdf agent, please disregard them! I was testing the agents ability to clone the registry and all services that were not (legal) may have caused the agent to send you a message. If you were affected, sorry about that. Sincerely, An extremely red in the face Eddie From markw at illuminae.com Wed Nov 9 18:07:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 09 Nov 2005 15:07:47 -0800 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <003001c5e57a$604d32d0$6600a8c0@notebook> References: <003001c5e57a$604d32d0$6600a8c0@notebook> Message-ID: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> They were all sent to me... thanks!!! ;-) M On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > Hi, > > If anyone received any messages from the rdf agent, please > disregard them! I was testing the agents ability to clone > the registry and all services that were not (legal) may have > caused the agent to send you a message. > > If you were affected, sorry about that. > > Sincerely, > > An extremely red in the face Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 9 18:07:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 09 Nov 2005 15:07:47 -0800 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <003001c5e57a$604d32d0$6600a8c0@notebook> References: <003001c5e57a$604d32d0$6600a8c0@notebook> Message-ID: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> They were all sent to me... thanks!!! ;-) M On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > Hi, > > If anyone received any messages from the rdf agent, please > disregard them! I was testing the agents ability to clone > the registry and all services that were not (legal) may have > caused the agent to send you a message. > > If you were affected, sorry about that. > > Sincerely, > > An extremely red in the face Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Nov 9 19:26:26 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 10 Nov 2005 00:26:26 +0000 (GMT) Subject: [MOBY-dev] Moby registry down...? Message-ID: ...or just my corner-of-the-world network problem? Thanks for letting me know. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 9 19:37:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 10 Nov 2005 00:37:55 +0000 (GMT) Subject: [MOBY-dev] Moby registry down...? In-Reply-To: Message-ID: Solved. Sorry to disturb you. Probablt just a small hiccup on our network. Works fine now. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Nov 9 19:05:42 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 9 Nov 2005 16:05:42 -0800 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> Message-ID: <003f01c5e58a$7eb3fe60$6600a8c0@notebook> Hi Mark, As an aside, there were over 320 services and about 174 made it (were legal). That has got to be good news! I think that the agent is good to go. I had to code the logic where a user submits a URL and the services are sucked into the registry. The only thing that I haven't done yet is add the rdf to the report. I will do this now and then try it out again (making sure that the email is sent to me ;-) ). Sounds like today may have been a good day after all! Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Wednesday, November 09, 2005 3:08 PM > To: Core developer announcements > Cc: 'Moby Developers' > Subject: Re: [moby] [MOBY-dev] rdf agent > > They were all sent to me... > > thanks!!! ;-) > > M > > > On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > > Hi, > > > > If anyone received any messages from the rdf agent, > please > > disregard them! I was testing the agents ability to > clone > > the registry and all services that were not (legal) may > have > > caused the agent to send you a message. > > > > If you were affected, sorry about that. > > > > Sincerely, > > > > An extremely red in the face Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Sat Nov 12 08:15:05 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 12 Nov 2005 13:15:05 +0000 (GMT) Subject: [MOBY-dev] different types of results Message-ID: I wonder why moby register returned for two almost identical calls different result type: once a String, once an array of bytes: At the end of this message you will find two xml files, they differ only in the authority: senger at sherekhan:~/jMoby$ diff q1.xml q2.xml 11c11 < samples.jmoby.net --- > www.iris.irri.org 18d17 < When I call "findService" for authority samples.jmoby.net, I get results as a String. When I call it for www.iris.irri.org, I am getting it as an array of bytes. In both cases the contents of the reasult is correct but I wonder if this is the bug. Does it perhaps depend on the special unicode characters that are used in the services? (Not that I am awaee of any of those in these services.) I understand that biomoby services and clients are supposed to understand both String and byte arrays, but it was never (AFAIK) mentioned that also biomoby registry has this behaviour. I can fix it in jMoby (actually I am fixing it as I speak) but I think that such behaviour is not good. Any comment on that? Thanks, Martin q1.xml ------ moby samples.jmoby.net 1 1 0 q2.xml ------ moby www.iris.irri.org 1 1 0 -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Nov 12 16:38:51 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 12 Nov 2005 13:38:51 -0800 Subject: [MOBY-dev] different types of results In-Reply-To: References: Message-ID: <437660EB.9060604@illuminae.com> That's bizarre...??!? There is no reason for that to happen as far as I can tell. Both calls go through the same subroutine, and at least when they leave the MOBY Central code modules they are being returned as String's. I haven't had a chance to duplicate your result here (I'll try to get to that when I have finished what I am doing), but my first suspicon is that the SOAP::Lite library itself is somehow looking at the content of the document it is about to pass, and making the choice to send it one way or the other. Certainly the decision is not being made by MOBY code... I'll look into this more deeply later today. Hey Martin, we're almost in the same time-zone! Greetings from Sydney! Mark Martin Senger wrote: >I wonder why moby register returned for two almost identical calls >different result type: once a String, once an array of bytes: > >At the end of this message you will find two xml files, they differ only >in the authority: > >senger at sherekhan:~/jMoby$ diff q1.xml q2.xml >11c11 >< samples.jmoby.net >--- > > >>www.iris.irri.org >> >> >18d17 >< > >When I call "findService" for authority samples.jmoby.net, I get results >as a String. When I call it for www.iris.irri.org, I am getting it as an >array of bytes. > >In both cases the contents of the reasult is correct but I wonder if this >is the bug. Does it perhaps depend on the special unicode characters that >are used in the services? (Not that I am awaee of any of those in these >services.) > >I understand that biomoby services and clients are supposed to understand >both String and byte arrays, but it was never (AFAIK) mentioned that also >biomoby registry has this behaviour. I can fix it in jMoby (actually I am >fixing it as I speak) but I think that such behaviour is not good. Any >comment on that? > >Thanks, >Martin > >q1.xml >------ > > > > > > > > > >moby >samples.jmoby.net >1 >1 >0 > > > > >q2.xml >------ > > > > > > > > > >moby >www.iris.irri.org >1 >1 >0 > > > > > > > > From senger at ebi.ac.uk Sat Nov 12 22:25:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 13 Nov 2005 03:25:14 +0000 (GMT) Subject: [MOBY-dev] different types of results In-Reply-To: <437660EB.9060604@illuminae.com> Message-ID: Hi to Sydney (and to others, as well, of course), > That's bizarre...??!? > We exchanged emails with Eddie about it yesterday. It seems that we all, Mark including, concluded that SOAP::Lite is the "culprit". I said it in quotes because actually SOAP::Lite tries to help. I found that some of the IRRI services used some (probably) non-ascii characters in the description - and that fact probably triggered SOAP::Lite to switch to byte array. I think that it could be switched off (using something like: SOAP::Data->type (string => $result) but perhaps it is a good think to have there byte array. Anyway, I have fixed the jMoby library (CentralImpl.java) so it accepts now both types. Still it is an interesting thing... Cheers, Martin PS: I love Sydney - I wish you the best there, and be prepared when you go home: Eddie has for you a present from us, the Richard's Moby group here in Los Banos... (Don't worry, nothing nasty...). M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Nov 12 22:27:24 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 13 Nov 2005 03:27:24 +0000 GMT Subject: [MOBY-dev] different types of results Message-ID: <1749433976-1131852476-cardhu_blackberry.rim.net-23911-@engine19-cell01> I'm glad it wasn't me :-) M -----Original Message----- From: Martin Senger Date: Sun, 13 Nov 2005 03:25:14 To:Mark Wilkinson Cc:Moby Developers Subject: Re: [MOBY-dev] different types of results Hi to Sydney (and to others, as well, of course), > That's bizarre...??!? > We exchanged emails with Eddie about it yesterday. It seems that we all, Mark including, concluded that SOAP::Lite is the "culprit". I said it in quotes because actually SOAP::Lite tries to help. I found that some of the IRRI services used some (probably) non-ascii characters in the description - and that fact probably triggered SOAP::Lite to switch to byte array. I think that it could be switched off (using something like: SOAP::Data->type (string => $result) but perhaps it is a good think to have there byte array. Anyway, I have fixed the jMoby library (CentralImpl.java) so it accepts now both types. Still it is an interesting thing... Cheers, Martin PS: I love Sydney - I wish you the best there, and be prepared when you go home: Eddie has for you a present from us, the Richard's Moby group here in Los Banos... (Don't worry, nothing nasty...). M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Mon Nov 14 14:00:22 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 14 Nov 2005 11:00:22 -0800 Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <1864146826-1131994113-cardhu_blackberry.rim.net-30532-@engine20-cell01> Message-ID: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Hi, Mark and I were talking about what we feel is the need to create a CommonSubs interface that would be implemented in both Java and Perl. Currently, CommonSubs.pm has the following methods: genericServiceInputParser complexServiceInputParser getArticles genericServiceInputParserAsObject getSimpleArticleIDs getSimpleArticleNamespaceURI simpleResponse collectionResponse responseHeader responseFooter getInputs getInputID getArticlesAsObjects getCollectedSimples getInputArticles isSimpleArticle isCollectionArticle isSecondaryArticle extractRawContent getNodeContentWithArticle validateNamespaces validateThisNamespace getResponseArticles (a.k.a. extractResponseArticles) getServiceNotes getCrossReferences whichDeepestParentObject _rearrange (stolen from BioPerl ;-) ) The subroutine descriptions can be found at http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html We need functions that will, among other things: 1) Get enumerated invocations from an incoming message 2) Add enumerated outputs to an outgoing message 3) Add an error message to the header 4) Read error messages from the header 5) Extract individual inputs from an invocation... ... etc So this is a call out to service providers to tell us what functions they believe would be useful to have (i.e. make their lives much easier). Thanks, Eddie From senger at ebi.ac.uk Mon Nov 14 18:52:23 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 14 Nov 2005 23:52:23 +0000 (GMT) Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: > Mark and I were talking about what we feel is the need to > create a CommonSubs interface that would be implemented in > both Java and Perl. > In Java, it is implemented already. Regarding Perl, I was rather thinking about having a Perl version of Moses (generator of Perl modules representing services), but it is not high priority in my calendar at the moment. But Moses was designed very modularly, so it should not be that hard to generated Perl code. If anyone is willing to try I am happy to help... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Tue Nov 15 04:15:02 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 15 Nov 2005 10:15:02 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: Hi Mark, I noticed that complexResponse is not listed in CommonSubs.html. I thought it might get created automatically from the comments/ descriptions in CommonSubs.pm..., but apparently it's not. Can I run some tool to recreate CommonSubs.html or do I have to add the description manually or...? Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but is in @EXPORT_OK", but it's not there either: our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); Without complexResponse it's no longer possible to send secondary articles back to a client :(. Cheers, Pieter On 14-Nov-2005, at 8:00 PM, Edward Kawas wrote: > Hi, > > Currently, CommonSubs.pm has the following methods: > > genericServiceInputParser > complexServiceInputParser > getArticles > genericServiceInputParserAsObject > getSimpleArticleIDs > getSimpleArticleNamespaceURI > simpleResponse > collectionResponse > responseHeader > responseFooter > getInputs > getInputID > getArticlesAsObjects > getCollectedSimples > getInputArticles > isSimpleArticle > isCollectionArticle > isSecondaryArticle > extractRawContent > getNodeContentWithArticle > validateNamespaces > validateThisNamespace > getResponseArticles (a.k.a. extractResponseArticles) > getServiceNotes > getCrossReferences > whichDeepestParentObject > _rearrange (stolen from BioPerl ;-) ) > > The subroutine descriptions can be found at > http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Tue Nov 15 06:12:24 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 15 Nov 2005 12:12:24 +0100 Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <505C05C8-65D7-45E6-AD7F-C96D65C3F946@wur.nl> Hi, On 14-Nov-2005, at 8:00 PM, Edward Kawas wrote: > Hi, > > Mark and I were talking about what we feel is the need to > create a CommonSubs interface that would be implemented in > both Java and Perl. Sounds like a good plan to me :). I'm not using the Python API, but wouldn't it be a good idea to do the same thing for Python as well then? > > Currently, CommonSubs.pm has the following methods: > > genericServiceInputParser > complexServiceInputParser > getArticles > genericServiceInputParserAsObject > getSimpleArticleIDs > getSimpleArticleNamespaceURI > simpleResponse > collectionResponse > responseHeader > responseFooter > getInputs > getInputID > getArticlesAsObjects > getCollectedSimples > getInputArticles > isSimpleArticle > isCollectionArticle > isSecondaryArticle > extractRawContent > getNodeContentWithArticle > validateNamespaces > validateThisNamespace > getResponseArticles (a.k.a. extractResponseArticles) > getServiceNotes > getCrossReferences > whichDeepestParentObject > _rearrange (stolen from BioPerl ;-) ) > > The subroutine descriptions can be found at > http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html > > We need functions that will, among other things: > > 1) Get enumerated invocations from an incoming > message > > 2) Add enumerated outputs to an outgoing message Currently (in Perl) we have 3 *ServiceInputParser functions and another 3 *Response functions. To keeps things simple I would rather like to see just 1 serviceInputParser and 1 serviceResponse function. The current complex* functions are not that hard to use :), the other ones are just crippled and don't support the complete BioMOBY specs. > 3) Add an error message to the header > > 4) Read error messages from the header Do you mean the SOAP header? In that case it would be good also to think of functions to handle errors in the ServiceNotes part. So far I have only seen votes in favour of RFC 1863 :). > > 5) Extract individual inputs from an invocation... > > ... The rest of what I need is already there :). My only problem with the current functions is that it doesn't work well for large objects due to DOM parsing. I know it's not going to be easy to change to stream or chunk based parsing, but if it would be possible to improve the scalability it would make my life even easier :). Just my 0.02 ?, Pieter > > etc > > So this is a call out to service providers to tell us what > functions they believe would be useful to have (i.e. make > their lives much easier). > > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From francis_gibbons at hms.harvard.edu Wed Nov 16 09:49:17 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 16 Nov 2005 09:49:17 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> Hi Pieter, >Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. >There is a comment "complexResponse is *not* here, but >is in @EXPORT_OK", but it's not there either: >our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); > >Without complexResponse it's no longer possible to send secondary >articles back to a client :(. I'm the one who put that comment in there. The code had two long lists containing almost the same things, but as you see, there was one component which was lacking. I guess I mistyped the name, putting "collectionResponse" instead of "complexResponse". My bad! One reason for the confusion is that as I was writing the unit tests, I just couldn't figure out what the purpose of complexResponse was, how it was different from collectionResponse. Now that I look at it again, it seems not so puzzling (I guess I was fairly punchy after writing so many tests), but it would help a great deal to have someone who actually uses write an explanation of why it's useful. CommonSubs contains lots of routines that appear almost identical in their functionality, yet are subtly different (for example, pulling out parts of the moby:MOBY message at different levels). We need good explanations for why it is useful to do each of these. How about this: I've fixed that line defining EXPORT_OK, and checked it back in. Could you add some useful explanation of complexReponse's purpose and usage to the POD? I'm thinking specifics - the current text is way too generic (e.g., "function: wraps articles in the appropriate (mobyData) structure") We also need an example showing what exactly this routine should do, so that we can add it to the test suite. If you want to just send me an example, I can construct the test. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Wed Nov 16 09:54:32 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 16 Nov 2005 09:54:32 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> Of course, I should also have asked why complexResponse was singled out in this way - why is it NOT in @EXPORT? Just a typo/omission? -Frank At 04:15 AM 11/15/2005, you wrote: >Hi Mark, > >I noticed that complexResponse is not listed in CommonSubs.html. I >thought it might get created automatically from the comments/ descriptions >in CommonSubs.pm..., but apparently it's not. Can I run >some tool to recreate CommonSubs.html or do I have to add the >description manually or...? > >Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. >There is a comment "complexResponse is *not* here, but >is in @EXPORT_OK", but it's not there either: >our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); > >Without complexResponse it's no longer possible to send secondary >articles back to a client :(. >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Wed Nov 16 17:38:44 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 16 Nov 2005 23:38:44 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> Message-ID: <46FF29A8-FD3C-4EF6-AFDC-FECE0919553A@wur.nl> Hi Frank, On 16Nov2005, at 15:49, Frank Gibbons wrote: > Hi Pieter, > >> Furthermore in CommonSubs.pm complexResponse is gone from '% >> EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but >> is in @EXPORT_OK", but it's not there either: >> our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); >> >> Without complexResponse it's no longer possible to send secondary >> articles back to a client :(. > > I'm the one who put that comment in there. The code had two long > lists containing almost the same things, but as you see, there was > one component which was lacking. I guess I mistyped the name, > putting "collectionResponse" instead of "complexResponse". My bad! > > One reason for the confusion is that as I was writing the unit > tests, I just couldn't figure out what the purpose of > complexResponse was, how it was different from collectionResponse. > Now that I look at it again, it seems not so puzzling (I guess I > was fairly punchy after writing so many tests), but it would help a > great deal to have someone who actually uses write an explanation > of why it's useful. CommonSubs contains lots of routines that > appear almost identical in their functionality, yet are subtly > different (for example, pulling out parts of the moby:MOBY message > at different levels). We need good explanations for why it is > useful to do each of these. > > How about this: I've fixed that line defining EXPORT_OK, and > checked it back in. Thanks! > Could you add some useful explanation of complexReponse's purpose > and usage to the POD? I'm thinking specifics - the current text is > way too generic (e.g., "function: wraps articles in the appropriate > (mobyData) structure") Ok I'll add that. > We also need an example showing what exactly this routine should > do, so that we can add it to the test suite. If you want to just > send me an example, I can construct the test. I'll send you an example too... Cheers, Pi > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev 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 Nov 16 17:42:47 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 16 Nov 2005 23:42:47 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> Message-ID: <0F7F19F4-5401-4FD1-9518-FCAFC225559C@wur.nl> On 16Nov2005, at 15:54, Frank Gibbons wrote: > Of course, I should also have asked why complexResponse was singled > out in this way - why is it NOT in @EXPORT? Just a typo/omission? That was puzzling me too. I think I put it there... at least I should have! I'll put it there now. If someone deliberately removed for whatever reason, please let me know. Pieter > -Frank > > At 04:15 AM 11/15/2005, you wrote: >> Hi Mark, >> >> I noticed that complexResponse is not listed in CommonSubs.html. I >> thought it might get created automatically from the comments/ >> descriptions in CommonSubs.pm..., but apparently it's not. Can I run >> some tool to recreate CommonSubs.html or do I have to add the >> description manually or...? >> >> Furthermore in CommonSubs.pm complexResponse is gone from '% >> EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but >> is in @EXPORT_OK", but it's not there either: >> our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); >> >> Without complexResponse it's no longer possible to send secondary >> articles back to a client :(. >> http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Mon Nov 14 12:18:23 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 14 Nov 2005 09:18:23 -0800 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object Message-ID: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Hi, I was unable to find a method that parses xml similar to the registerService (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY -S_API/XMLPayloads.html) xml and returns a MobyService object. I did notice the method in CentralImpl called extractServices(string) but the it parses a different message structure than the registerService xml. Does anyone know of a method that does what I need? Thanks, Eddie From gordonp at ucalgary.ca Fri Nov 18 13:13:06 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 18 Nov 2005 11:13:06 -0700 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <002701c5e93f$6c3b3c40$6600a8c0@notebook> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Message-ID: <437E19B2.4050505@ucalgary.ca> > CentralImpl.findService CentralImpl.findService() obviously parses the XML at some point to give you the service object. Ah, yes. MobyServices[] CentralImpl.extractServices(String) >I was unable to find a method that parses xml similar to the >registerService >(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >-S_API/XMLPayloads.html) xml and returns a MobyService >object. > >I did notice the method in CentralImpl called >extractServices(string) but the it parses a different >message structure than the registerService xml. > >Does anyone know of a method that does what I need? > >Thanks, > >Eddie > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From gordonp at ucalgary.ca Fri Nov 18 14:53:44 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 18 Nov 2005 12:53:44 -0700 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E19B2.4050505@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> Message-ID: <437E3148.9070105@ucalgary.ca> I am stupid. Time to go home for the weekend. :-) I don't think the method you are looking for exists in Java yet. > > > CentralImpl.findService() obviously parses the XML at some point to > give you the service object. > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > >> I was unable to find a method that parses xml similar to the >> registerService >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >> -S_API/XMLPayloads.html) xml and returns a MobyService >> object. >> >> I did notice the method in CentralImpl called >> extractServices(string) but the it parses a different >> message structure than the registerService xml. >> >> Does anyone know of a method that does what I need? >> >> Thanks, >> >> Eddie >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Fri Nov 18 14:09:18 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 18 Nov 2005 11:09:18 -0800 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E19B2.4050505@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> Message-ID: Hi Paul, I did notice the method in CentralImpl called extractServices(string) but the it parses a different message structure than the registerService xml. Do you know of any others? Thanks, Eddie On 11/18/05, Paul Gordon wrote: > > > CentralImpl.findService > > > CentralImpl.findService() obviously parses the XML at some point to give > you the service object. > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > > >I was unable to find a method that parses xml similar to the > >registerService > >(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY > >-S_API/XMLPayloads.html) xml and returns a MobyService > >object. > > > >I did notice the method in CentralImpl called > >extractServices(string) but the it parses a different > >message structure than the registerService xml. > > > >Does anyone know of a method that does what I need? > > > >Thanks, > > > >Eddie > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From edward.kawas at gmail.com Fri Nov 18 14:56:21 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 18 Nov 2005 11:56:21 -0800 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E3148.9070105@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> <437E3148.9070105@ucalgary.ca> Message-ID: Do you think that it is a useful method for me to create? I have my own use for it, but do you think that others would find it useful? Thanks, Eddie On 11/18/05, Paul Gordon wrote: > > I am stupid. Time to go home for the weekend. :-) > I don't think the method you are looking for exists in Java yet. > > > > > > > CentralImpl.findService() obviously parses the XML at some point to > > give you the service object. > > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > > > >> I was unable to find a method that parses xml similar to the > >> registerService > >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY > >> -S_API/XMLPayloads.html) xml and returns a MobyService > >> object. > >> > >> I did notice the method in CentralImpl called > >> extractServices(string) but the it parses a different > >> message structure than the registerService xml. > >> > >> Does anyone know of a method that does what I need? > >> > >> Thanks, > >> > >> Eddie > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From gordonp at ucalgary.ca Fri Nov 18 15:29:44 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 18 Nov 2005 13:29:44 -0700 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> <437E3148.9070105@ucalgary.ca> Message-ID: <437E39B8.3020108@ucalgary.ca> If some one wants to implement moby central in Java, this would be very handy. To prepare for that eventuality, perhaps you could write this as a static method in a new server utility class, say org.biomoby.registry.requestParser or something of the like. >Do you think that it is a useful method for me to create? I have my own use >for it, but do you think that others would find it useful? > Thanks, > Eddie > > On 11/18/05, Paul Gordon wrote: > > >>I am stupid. Time to go home for the weekend. :-) >>I don't think the method you are looking for exists in Java yet. >> >> >> >>>CentralImpl.findService() obviously parses the XML at some point to >>>give you the service object. >>>Ah, yes. MobyServices[] CentralImpl.extractServices(String) >>> >>> >>> >>>>I was unable to find a method that parses xml similar to the >>>>registerService >>>>(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >>>>-S_API/XMLPayloads.html) xml and returns a MobyService >>>>object. >>>> >>>>I did notice the method in CentralImpl called >>>>extractServices(string) but the it parses a different >>>>message structure than the registerService xml. >>>> >>>>Does anyone know of a method that does what I need? >>>> >>>>Thanks, >>>> >>>>Eddie >>>> >>>>_______________________________________________ >>>>MOBY-dev mailing list >>>>MOBY-dev at biomoby.org >>>>http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev at biomoby.org >>>http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From senger at ebi.ac.uk Fri Nov 18 19:00:47 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 19 Nov 2005 00:00:47 +0000 (GMT) Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Message-ID: > I was unable to find a method that parses xml similar to the > registerService > jMoby does not contain stuff that is needed to write a biomoby register in Java; and the XML structure for 'registerService' is exactly that type of stuff: it has not use for clients, but only for server; if you are starting to add these things to jMoby, I suggest you create a new Java interface (e.g. Registry.java) in package org.biomoby.registry for that. But I am curious what you are working on that you need this... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 18 19:03:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 19 Nov 2005 00:03:10 +0000 (GMT) Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E39B8.3020108@ucalgary.ca> Message-ID: Interestingly I have read this Paul's answer only I have sent my own answer, and I am pleased that we came to almost identical suggestion :-) > If some one wants to implement moby central in Java, this would be very > handy. To prepare for that eventuality, perhaps you could write this as > a static method in a new server utility class, say > org.biomoby.registry.requestParser or something of the like. > Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 18 19:23:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 19 Nov 2005 00:23:14 +0000 (GMT) Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: Message-ID: > Interestingly I have read this Paul's answer only I have sent my own > answer, and I am pleased that we came to almost identical suggestion :-) > And more interestingly: I was wrong. There *is* such service in jMoby - because I needed it for biomoby dashboard (that will be announced next week). So last week I have extracted from the existing method registerService() this part and created in CentralImpl.java a new method public String getRegisterServiceXML (MobyService service) that does exactly what Eddie is looking for (the same was done for other moby entities, such as data types, service types and namespaces) as well. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 01:55:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 20 Nov 2005 06:55:09 +0000 (GMT) Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: I am calling: retrieveServiceNames and I am getting back: ... Why are lsids empty? Could you fix it please? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 11:21:56 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 20 Nov 2005 16:21:56 +0000 (GMT) Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: <4380A101.9040504@illuminae.com> Message-ID: > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 11:21:56 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 20 Nov 2005 16:21:56 +0000 (GMT) Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: <4380A101.9040504@illuminae.com> Message-ID: > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sun Nov 20 11:31:57 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 20 Nov 2005 16:31:57 +0000 GMT Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: <443899406-1132504485-cardhu_blackberry.rim.net-29404-@engine18-cell01> My pleasure. Greetings from Vancouver airport! (thank goodness for wireless...) M -----Original Message----- From: Martin Senger Date: Sun, 20 Nov 2005 16:21:56 To:Mark Wilkinson Cc:Core developer announcements , Martin Senger , Moby Developers Subject: Re: [MOBY-dev] why a list of services does not have lsid filled? > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Sun Nov 20 11:31:57 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 20 Nov 2005 16:31:57 +0000 GMT Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: <443899406-1132504485-cardhu_blackberry.rim.net-29404-@engine18-cell01> My pleasure. Greetings from Vancouver airport! (thank goodness for wireless...) M -----Original Message----- From: Martin Senger Date: Sun, 20 Nov 2005 16:21:56 To:Mark Wilkinson Cc:Core developer announcements , Martin Senger , Moby Developers Subject: Re: [MOBY-dev] why a list of services does not have lsid filled? > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Sun Nov 20 11:14:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 20 Nov 2005 08:14:57 -0800 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: References: Message-ID: <4380A101.9040504@illuminae.com> should be fixed now. Please confirm. I've also added a test for this case to the harness. M Martin Senger wrote: >I am calling: > retrieveServiceNames >and I am getting back: > > > > > >... > > >Why are lsids empty? Could you fix it please? > >Thanks, >Martin > > > From markw at illuminae.com Sun Nov 20 11:14:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 20 Nov 2005 08:14:57 -0800 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: References: Message-ID: <4380A101.9040504@illuminae.com> should be fixed now. Please confirm. I've also added a test for this case to the harness. M Martin Senger wrote: >I am calling: > retrieveServiceNames >and I am getting back: > > > > > >... > > >Why are lsids empty? Could you fix it please? > >Thanks, >Martin > > > From francis_gibbons at hms.harvard.edu Mon Nov 21 09:46:29 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Mon, 21 Nov 2005 09:46:29 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <2121ED51-4164-4E48-9624-89239815D503@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Congratulations, Pieter, At 08:32 AM 11/21/2005, you wrote: >One more thing. After my changes I tried make test and noticed that >the Config.t is skipped, because it's only required for a local >BioMOBY Central..., but I do have one and I have set my >MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >familiar with the test scripts... I think you just got yourself nominated to be caretaker of the test t/Config.t. I don't have a local registry, so there was no way for me to test its operation. Most users (I think) are in the same position, so this test is skipped by default. For details on how to use the testing framework, you could look at the Perl modules Test::Simple and Test:More. The basic idea is that you execute some MOBY code for which you believe you know the output. You compare actual output to expected output using the is() function. It generates errors if the two don't match. You can also check for correct failure using isnt(), which generates a similar error. Examples might be: is(2+2, 4, "Can't do addition");' # Generates error with this string showing up on output device is(scalar @A, $#A + 1, "Scalar gives incorrect results"); Generally, tests should be symbolic, rather than specific. This leads to tests that are more easy to maintain over time: if an array is built before it is tested, and if it's tested symbolically, it should be possible to alter the array contents at a later point, without breaking that test. Take a look in the Client-Central.t for examples of this: a registration structure is created, services are registered, then the registration object is itself queried, and the results compared symbolically with the original data. This verifies that the information flows through the system correctly. If someone later decides to change a small detail (e.g., a parameter name), the tests should continue to pass without modification. But the tests themselves don't really have to complicated to be useful: check that each module exports the functions it claims to implement, check that set/get methods work correctly, check return types in all contexts (does it return array in list context, scalar in scalar context). All that stuff is important in maintaining a coherent interface over time. It also helps to find inconsistencies. I think it would be really great if you could build some useful, robust, portable tests for the local-registry configuration. This kind of test can be a big help to users trying to install their local registry, so its utility goes beyond merely regression testing the code, it's also useful to debugging local installations with perfectly functioning code. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Tue Nov 22 05:49:49 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Nov 2005 11:49:49 +0100 Subject: [MOBY-dev] Perl API: retrieveObjectDefinition and registerObjectClass call In-Reply-To: <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> Message-ID: <30E59CF1-9CA2-43A8-A219-AACCE4F03E0F@wur.nl> On 4-Nov-2005, at 10:41 PM, Pieter Neerincx wrote: > > On 02Nov2005, at 17:12, Mark Wilkinson wrote: > >> I think you're right - that's a much better data structure to be >> passing >> around. >> >> This does change the external (perl client) API, right? :-/ > > Yep, that's why I'm asking. I have no idea who is currently relying > on the retrieveObjectDefinition call and what might break if I > change it... So far I have heard no complaints, so I suggest I go > ahead and make the change... One more thing. The retrieveObjectDefinition function lists that it returns what you send it when you register an object. In that case it makes sense to change the registerObject a.k.a. registerObjectClass function as well. Summarising this would mean the following changes (changes marked with "->"): registerObject a.k.a registerObjectClass Usage : $REG = $MOBY->registerObject(%args) Usage : $REG = $MOBY->registerObjectClass(%args) Function : register a new type of MOBY Object Returns : MOBY::Registration object Args : objectType => "the name of the Object" description => "a human-readable description of the object" contactEmail => "your at email.address" authURI => "URI of the registrar of this object" OLD Relationships => { relationshipType1 => [ -> [Object1, articleName], -> [Object2, articleName] ], relationshipType2 => [ -> [Object3, articleName] ] } NEW Relationships => { relationshipType1 => [ -> {object => Object1, -> articleName => ArticleName1}, -> {object => Object2, -> articleName => ArticleName2} ], -> relationshipType2 => [ -> {object => Object3, -> articleName => ArticleName3} ] } retrieveObjectDefinition Usage : $DEF = $MOBY->retrieveObjectDefinition($objectType[, $registry]) Function : retrieve the $XML that was used to register an object and its relationships Returns : hashref, similar to the hash sent during Object registration, plus an additional XML hash key that contains the actual XML containing the object definition as sent by MOBY Central (used for a visual overview, rather than parsing all of the hash keys) objectType => "the name of the Object" objectLSID => "urn:lsid:..." description => "a human-readable description of the object" contactEmail => "your at email.address" authURI => "URI of the registrar of this object" OLD Relationships => { relationshipType1 => [ -> [Object1, articleName1, lsid1], -> [Object2, articleName2, lsid2] ], relationshipType2 => [ -> [Object1, articleName3, lsid3] ] } NEW Relationships => { relationshipType1 => [ -> {object => Object1, -> articleName => ArticleName1, -> lsid => lsid1}, -> {object => Object2, -> articleName => ArticleName2, -> lsid => lsid2} ], relationshipType2 => [ -> {object => Object3, -> articleName => ArticleName3, -> lsid => lsid3} ] } XML => <....XML of object registration.../> Args : objectType => the name or LSID URI for an object I have the necessary changes including those to Frank's tests standing by. If I don't receive any complaints during the next days I will commit these changes to the CVS on Friday... Cheers, Pieter > >> >> Really, what the Perl client code needs is a good laundering. The >> CommonSubs.pm module is a total mess after being modified >> piecemeal over >> the past 3 years... >> >> I wonder if we shouldn't just start a new module (or modules) that >> are >> named by their domain of function (RegistryIO, OntologyIO, or >> something >> like that) and have all fresh code? Gradually we could migrate all >> functionality into these modules. Client::Central has been around >> since >> the 0.1 prototype of MOBY in 2001 and has never been re-written >> top-to- >> bottom! > > That would be a good idea to get cleaner code, but for the time > being it's not that bad! It works as advertised and gets my job > done :). Try debugging SOAP::Lite and MIME::Parser... those are the > ones that really need a complete make-over! > >> >> I'm still waiting to hear about the re-funding attempts for MOBY... >> fingers crossed! There will hopefully be a second opportunity >> later in >> the winter, so all is not lost if we fail. > > Good luck! > > Pieter > >> It would be great to have a >> couple of extra hands dedicated to a complete code re-write >> >> M >> >> >> >> >> On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: >>> Hi all, >>> >>> Here is a question for those using the Perl API. In >>> >>> MOBY/Client/Central.pm >>> >>> we have a >>> >>> sub retrieveObjectDefinition >>> >>> which calls >>> >>> sub _ObjectDefinitionPayload { >>> >>> This produces an array for the objects, articleNames and lsids for >>> the relationships of the object whose definition is requested. I'm >>> wondering why this is an array. Currently I have to rely on the >>> order >>> of elements in this array to figure out which element is the object, >>> which one is articleName, etc. These are the lines producing the >>> array: >>> >>> 553 push @{ $relationships{$relationshipType} }, >>> 554 [ $_->toString, $article, $rlsid ]; >>> >>> Is there any reason why this should be an array? I'd rather not have >>> to rely on the order of the elements, so are there people who have >>> any objections when I change this into a hash like in: >>> >>> push @{ $relationships{$relationshipType} }, >>> { object => $_->toString, >>> articleName => $article, >>> lsid => $rlsid }; >>> >>> Cheers, >>> >>> Pieter >>> >>> >>> >>> >>> Wageningen University and Research centre (WUR) >>> Laboratory of Bioinformatics >>> Transitorium (building 312) room 1034 >>> Dreijenlaan 3 >>> 6703 HA Wageningen >>> The Netherlands >>> phone: 0317-483 060 >>> fax: 0317-483 584 >>> mobile: 06-143 66 783 >>> pieter.neerincx at wur.nl >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >> -- >> "Ontologists do it with the edges!" >> >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 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 biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Nov 22 08:01:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 05:01:26 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <438316A6.6040204@illuminae.com> I just changed the code on my own t/* to use environment variables while I was on the plane yesterday so that I could run tests on my own Windows installation - funny that we were all looking at the same piece of code at the same time :-) i'll commit these changes as soon as I have double-checked them. In general it will allow you to test your local registry instead of the remote one by default. M Frank Gibbons wrote: > Congratulations, Pieter, > > At 08:32 AM 11/21/2005, you wrote: > >> One more thing. After my changes I tried make test and noticed that >> the Config.t is skipped, because it's only required for a local >> BioMOBY Central..., but I do have one and I have set my >> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> familiar with the test scripts... > > > I think you just got yourself nominated to be caretaker of the test > t/Config.t. I don't have a local registry, so there was no way for me > to test its operation. Most users (I think) are in the same position, > so this test is skipped by default. > > For details on how to use the testing framework, you could look at > the Perl modules Test::Simple and Test:More. The basic idea is that > you execute some MOBY code for which you believe you know the output. > You compare actual output to expected output using the is() function. > It generates errors if the two don't match. You can also check for > correct failure using isnt(), which generates a similar error. > Examples might be: > > is(2+2, 4, "Can't do addition");' # Generates error with this string > showing up on output device > is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > Generally, tests should be symbolic, rather than specific. This leads > to tests that are more easy to maintain over time: if an array is > built before it is tested, and if it's tested symbolically, it should > be possible to alter the array contents at a later point, without > breaking that test. Take a look in the Client-Central.t for examples > of this: a registration structure is created, services are registered, > then the registration object is itself queried, and the results > compared symbolically with the original data. This verifies that the > information flows through the system correctly. If someone later > decides to change a small detail (e.g., a parameter name), the tests > should continue to pass without modification. > > But the tests themselves don't really have to complicated to be > useful: check that each module exports the functions it claims to > implement, check that set/get methods work correctly, check return > types in all contexts (does it return array in list context, scalar in > scalar context). All that stuff is important in maintaining a coherent > interface over time. It also helps to find inconsistencies. > > I think it would be really great if you could build some useful, > robust, portable tests for the local-registry configuration. This kind > of test can be a big help to users trying to install their local > registry, so its utility goes beyond merely regression testing the > code, it's also useful to debugging local installations with perfectly > functioning code. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From markw at illuminae.com Tue Nov 22 08:01:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 05:01:26 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <438316A6.6040204@illuminae.com> I just changed the code on my own t/* to use environment variables while I was on the plane yesterday so that I could run tests on my own Windows installation - funny that we were all looking at the same piece of code at the same time :-) i'll commit these changes as soon as I have double-checked them. In general it will allow you to test your local registry instead of the remote one by default. M Frank Gibbons wrote: > Congratulations, Pieter, > > At 08:32 AM 11/21/2005, you wrote: > >> One more thing. After my changes I tried make test and noticed that >> the Config.t is skipped, because it's only required for a local >> BioMOBY Central..., but I do have one and I have set my >> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> familiar with the test scripts... > > > I think you just got yourself nominated to be caretaker of the test > t/Config.t. I don't have a local registry, so there was no way for me > to test its operation. Most users (I think) are in the same position, > so this test is skipped by default. > > For details on how to use the testing framework, you could look at > the Perl modules Test::Simple and Test:More. The basic idea is that > you execute some MOBY code for which you believe you know the output. > You compare actual output to expected output using the is() function. > It generates errors if the two don't match. You can also check for > correct failure using isnt(), which generates a similar error. > Examples might be: > > is(2+2, 4, "Can't do addition");' # Generates error with this string > showing up on output device > is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > Generally, tests should be symbolic, rather than specific. This leads > to tests that are more easy to maintain over time: if an array is > built before it is tested, and if it's tested symbolically, it should > be possible to alter the array contents at a later point, without > breaking that test. Take a look in the Client-Central.t for examples > of this: a registration structure is created, services are registered, > then the registration object is itself queried, and the results > compared symbolically with the original data. This verifies that the > information flows through the system correctly. If someone later > decides to change a small detail (e.g., a parameter name), the tests > should continue to pass without modification. > > But the tests themselves don't really have to complicated to be > useful: check that each module exports the functions it claims to > implement, check that set/get methods work correctly, check return > types in all contexts (does it return array in list context, scalar in > scalar context). All that stuff is important in maintaining a coherent > interface over time. It also helps to find inconsistencies. > > I think it would be really great if you could build some useful, > robust, portable tests for the local-registry configuration. This kind > of test can be a big help to users trying to install their local > registry, so its utility goes beyond merely regression testing the > code, it's also useful to debugging local installations with perfectly > functioning code. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From Pieter.Neerincx at wur.nl Tue Nov 22 08:50:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Nov 2005 14:50:41 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <438316A6.6040204@illuminae.com> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> Message-ID: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > I just changed the code on my own t/* to use environment variables > while I was on the plane yesterday so that I could run tests on my > own Windows installation - funny that we were all looking at the > same piece of code at the same time :-) > > i'll commit these changes as soon as I have double-checked them. > In general it will allow you to test your local registry instead of > the remote one by default. That's cool! I'm looking forward to test the tests :) Pieter > > M > > > > Frank Gibbons wrote: > >> Congratulations, Pieter, >> >> At 08:32 AM 11/21/2005, you wrote: >> >>> One more thing. After my changes I tried make test and noticed that >>> the Config.t is skipped, because it's only required for a local >>> BioMOBY Central..., but I do have one and I have set my >>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>> familiar with the test scripts... >> >> >> I think you just got yourself nominated to be caretaker of the >> test t/Config.t. I don't have a local registry, so there was no >> way for me to test its operation. Most users (I think) are in the >> same position, so this test is skipped by default. >> >> For details on how to use the testing framework, you could look >> at the Perl modules Test::Simple and Test:More. The basic idea is >> that you execute some MOBY code for which you believe you know the >> output. You compare actual output to expected output using the is >> () function. It generates errors if the two don't match. You can >> also check for correct failure using isnt(), which generates a >> similar error. Examples might be: >> >> is(2+2, 4, "Can't do addition");' # Generates error with this >> string showing up on output device >> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> >> Generally, tests should be symbolic, rather than specific. This >> leads to tests that are more easy to maintain over time: if an >> array is built before it is tested, and if it's tested >> symbolically, it should be possible to alter the array contents at >> a later point, without breaking that test. Take a look in the >> Client-Central.t for examples of this: a registration structure is >> created, services are registered, then the registration object is >> itself queried, and the results compared symbolically with the >> original data. This verifies that the information flows through >> the system correctly. If someone later decides to change a small >> detail (e.g., a parameter name), the tests should continue to pass >> without modification. >> >> But the tests themselves don't really have to complicated to be >> useful: check that each module exports the functions it claims to >> implement, check that set/get methods work correctly, check return >> types in all contexts (does it return array in list context, >> scalar in scalar context). All that stuff is important in >> maintaining a coherent interface over time. It also helps to find >> inconsistencies. >> >> I think it would be really great if you could build some useful, >> robust, portable tests for the local-registry configuration. This >> kind of test can be a big help to users trying to install their >> local registry, so its utility goes beyond merely regression >> testing the code, it's also useful to debugging local >> installations with perfectly functioning code. >> >> -Frank >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: 617-432-3557 http:// >> llama.med.harvard.edu/~fgibbons >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > 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 Tue Nov 22 15:09:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 12:09:34 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43837AFE.5010901@illuminae.com> Hmmmm... there's still a dependency on the public ontologyserver though... and therefore a dependency on having a network connection. I remember now that this is somethign I wanted to fix a couple of months ago but it got pushed down my TO DO list in favor of keeping my job ;-) I'll try to fix that today - it will make the PlaNet people happy as well! :-) M Pieter Neerincx wrote: > > On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > >> I just changed the code on my own t/* to use environment variables >> while I was on the plane yesterday so that I could run tests on my >> own Windows installation - funny that we were all looking at the >> same piece of code at the same time :-) >> >> i'll commit these changes as soon as I have double-checked them. In >> general it will allow you to test your local registry instead of the >> remote one by default. > > > That's cool! I'm looking forward to test the tests :) > > Pieter > >> >> M >> >> >> >> Frank Gibbons wrote: >> >>> Congratulations, Pieter, >>> >>> At 08:32 AM 11/21/2005, you wrote: >>> >>>> One more thing. After my changes I tried make test and noticed that >>>> the Config.t is skipped, because it's only required for a local >>>> BioMOBY Central..., but I do have one and I have set my >>>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>> familiar with the test scripts... >>> >>> >>> >>> I think you just got yourself nominated to be caretaker of the test >>> t/Config.t. I don't have a local registry, so there was no way for >>> me to test its operation. Most users (I think) are in the same >>> position, so this test is skipped by default. >>> >>> For details on how to use the testing framework, you could look at >>> the Perl modules Test::Simple and Test:More. The basic idea is that >>> you execute some MOBY code for which you believe you know the >>> output. You compare actual output to expected output using the is () >>> function. It generates errors if the two don't match. You can also >>> check for correct failure using isnt(), which generates a similar >>> error. Examples might be: >>> >>> is(2+2, 4, "Can't do addition");' # Generates error with this >>> string showing up on output device >>> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >>> >>> Generally, tests should be symbolic, rather than specific. This >>> leads to tests that are more easy to maintain over time: if an >>> array is built before it is tested, and if it's tested >>> symbolically, it should be possible to alter the array contents at >>> a later point, without breaking that test. Take a look in the >>> Client-Central.t for examples of this: a registration structure is >>> created, services are registered, then the registration object is >>> itself queried, and the results compared symbolically with the >>> original data. This verifies that the information flows through the >>> system correctly. If someone later decides to change a small detail >>> (e.g., a parameter name), the tests should continue to pass without >>> modification. >>> >>> But the tests themselves don't really have to complicated to be >>> useful: check that each module exports the functions it claims to >>> implement, check that set/get methods work correctly, check return >>> types in all contexts (does it return array in list context, scalar >>> in scalar context). All that stuff is important in maintaining a >>> coherent interface over time. It also helps to find inconsistencies. >>> >>> I think it would be really great if you could build some useful, >>> robust, portable tests for the local-registry configuration. This >>> kind of test can be a big help to users trying to install their >>> local registry, so its utility goes beyond merely regression >>> testing the code, it's also useful to debugging local installations >>> with perfectly functioning code. >>> >>> -Frank >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: 617-432-3557 http:// >>> llama.med.harvard.edu/~fgibbons >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From francis_gibbons at hms.harvard.edu Wed Nov 23 10:01:23 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 23 Nov 2005 10:01:23 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <438316A6.6040204@illuminae.com> References: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> At 08:01 AM 11/22/2005, you wrote: >I just changed the code on my own t/* to use environment variables while I >was on the plane yesterday so that I could run tests on my own Windows >installation - funny that we were all looking at the same piece of code at >the same time :-) > >i'll commit these changes as soon as I have double-checked them. In >general it will allow you to test your local registry instead of the >remote one by default. So Mark, if I understand correctly, it should first check to see if the user has defined those environment variables. That should indicate that the user does have a local registry. It should a local registry if available, but fall back to using MOBY Central if it's not available. Right? That'd be awsome! -Frank >M > > > >Frank Gibbons wrote: > >>Congratulations, Pieter, >> >>At 08:32 AM 11/21/2005, you wrote: >> >>>One more thing. After my changes I tried make test and noticed that >>>the Config.t is skipped, because it's only required for a local >>>BioMOBY Central..., but I do have one and I have set my >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>familiar with the test scripts... >> >> >>I think you just got yourself nominated to be caretaker of the test >>t/Config.t. I don't have a local registry, so there was no way for me to >>test its operation. Most users (I think) are in the same position, so >>this test is skipped by default. >> >>For details on how to use the testing framework, you could look at >>the Perl modules Test::Simple and Test:More. The basic idea is that you >>execute some MOBY code for which you believe you know the output. You >>compare actual output to expected output using the is() function. It >>generates errors if the two don't match. You can also check for correct >>failure using isnt(), which generates a similar error. Examples might be: >> >>is(2+2, 4, "Can't do addition");' # Generates error with this string >>showing up on output device >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> >>Generally, tests should be symbolic, rather than specific. This leads to >>tests that are more easy to maintain over time: if an array is built >>before it is tested, and if it's tested symbolically, it should be >>possible to alter the array contents at a later point, without breaking >>that test. Take a look in the Client-Central.t for examples of this: a >>registration structure is created, services are registered, then the >>registration object is itself queried, and the results compared >>symbolically with the original data. This verifies that the information >>flows through the system correctly. If someone later decides to change a >>small detail (e.g., a parameter name), the tests should continue to pass >>without modification. >> >>But the tests themselves don't really have to complicated to be useful: >>check that each module exports the functions it claims to implement, >>check that set/get methods work correctly, check return types in all >>contexts (does it return array in list context, scalar in scalar >>context). All that stuff is important in maintaining a coherent interface >>over time. It also helps to find inconsistencies. >> >>I think it would be really great if you could build some useful, robust, >>portable tests for the local-registry configuration. This kind of test >>can be a big help to users trying to install their local registry, so its >>utility goes beyond merely regression testing the code, it's also useful >>to debugging local installations with perfectly functioning code. >> >>-Frank >> >>PhD, Computational Biologist, >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. >>Tel: 617-432-3555 Fax: 617-432-3557 >>http://llama.med.harvard.edu/~fgibbons >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Nov 22 16:32:36 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 13:32:36 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43838E74.1010100@illuminae.com> Okay, now it is *really* done. by setting the environment variables: MOBY_SERVER MOBY_URI MOBY_ONTOLOGYSERVER you can connect to your own registry and your own ontology server. This also works for the test harness. I need to document the MOBY_ONTOLOGYSERVER information somewhere... I'll get to that soon! M Pieter Neerincx wrote: > > On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > >> I just changed the code on my own t/* to use environment variables >> while I was on the plane yesterday so that I could run tests on my >> own Windows installation - funny that we were all looking at the >> same piece of code at the same time :-) >> >> i'll commit these changes as soon as I have double-checked them. In >> general it will allow you to test your local registry instead of the >> remote one by default. > > > That's cool! I'm looking forward to test the tests :) > > Pieter > >> >> M >> >> >> >> Frank Gibbons wrote: >> >>> Congratulations, Pieter, >>> >>> At 08:32 AM 11/21/2005, you wrote: >>> >>>> One more thing. After my changes I tried make test and noticed that >>>> the Config.t is skipped, because it's only required for a local >>>> BioMOBY Central..., but I do have one and I have set my >>>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>> familiar with the test scripts... >>> >>> >>> >>> I think you just got yourself nominated to be caretaker of the test >>> t/Config.t. I don't have a local registry, so there was no way for >>> me to test its operation. Most users (I think) are in the same >>> position, so this test is skipped by default. >>> >>> For details on how to use the testing framework, you could look at >>> the Perl modules Test::Simple and Test:More. The basic idea is that >>> you execute some MOBY code for which you believe you know the >>> output. You compare actual output to expected output using the is () >>> function. It generates errors if the two don't match. You can also >>> check for correct failure using isnt(), which generates a similar >>> error. Examples might be: >>> >>> is(2+2, 4, "Can't do addition");' # Generates error with this >>> string showing up on output device >>> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >>> >>> Generally, tests should be symbolic, rather than specific. This >>> leads to tests that are more easy to maintain over time: if an >>> array is built before it is tested, and if it's tested >>> symbolically, it should be possible to alter the array contents at >>> a later point, without breaking that test. Take a look in the >>> Client-Central.t for examples of this: a registration structure is >>> created, services are registered, then the registration object is >>> itself queried, and the results compared symbolically with the >>> original data. This verifies that the information flows through the >>> system correctly. If someone later decides to change a small detail >>> (e.g., a parameter name), the tests should continue to pass without >>> modification. >>> >>> But the tests themselves don't really have to complicated to be >>> useful: check that each module exports the functions it claims to >>> implement, check that set/get methods work correctly, check return >>> types in all contexts (does it return array in list context, scalar >>> in scalar context). All that stuff is important in maintaining a >>> coherent interface over time. It also helps to find inconsistencies. >>> >>> I think it would be really great if you could build some useful, >>> robust, portable tests for the local-registry configuration. This >>> kind of test can be a big help to users trying to install their >>> local registry, so its utility goes beyond merely regression >>> testing the code, it's also useful to debugging local installations >>> with perfectly functioning code. >>> >>> -Frank >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: 617-432-3557 http:// >>> llama.med.harvard.edu/~fgibbons >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From markw at illuminae.com Tue Nov 22 15:06:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 12:06:26 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43837A42.3020409@illuminae.com> > That's cool! I'm looking forward to test the tests :) Okay, it's done. MOBY::Client::Central always checks the environment variables MOBY_SERVER and MOBY_URI first unless you tell it otherwise, but it was hard-coded to talk to mobycentral.icapture.ubc.ca in the test suite. I've removed that now, and added an informational message to the test suite output to indicate how to set it up to test other registries. I've also changed the Client::Service test so that it looks for a service that is guaranteed to be there, rather than one that we just chose at random from the public registry. all 391 tests pass on Windows - Hurrah! M From markw at illuminae.com Wed Nov 23 16:05:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 23 Nov 2005 13:05:47 -0800 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> References: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> Message-ID: <1132779947.22071.10.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > So Mark, if I understand correctly, it should first check to see if the > user has defined those environment variables. That should indicate that the > user does have a local registry. Not necessarily local - the environment variables are simply a way of specifying which MOBY Central you wish to talk to by default (i.e. when you don't initialize the MOBY::Client::Central object with a "Registries" parameter). The following statements describe what happens: 1) The MOBY::Client::Central module is hard-coded to default to mobycentral.icapture.ubc.ca as it's default registry 2) When it is initializing, it first checks for the MOBY_SERVER and MOBY_URI environment variables and uses those instead of the defaults if they exist, otherwise it will default. 3) Initializing MOBY::Client::Central using the "Registries" argument will over-ride both of the previous behaviours -> use of this argument also allows you to interact with more than one registry at a time (for **read-only** interactions) ...(note that this latter behaviour has never been adequately tested, since it has never been used AFAIK) > It should a local registry if available, > but fall back to using MOBY Central if it's not available. Right? yup. That behaviour has always been true, actually; however the test harness was hard coded to use the 'Registries' argument when it started- up, so it was over-riding the useful behaviour that MOBY::Client::Central already had :-) The same behaviour is now true for MOBY::Client::OntologyServer - it will first check the environment variable, and if it isn't set, then it will default to call home to mobycentral.icapture.ubc.ca Cheers! M > That'd be awsome! > > -Frank > > > >M > > > > > > > >Frank Gibbons wrote: > > > >>Congratulations, Pieter, > >> > >>At 08:32 AM 11/21/2005, you wrote: > >> > >>>One more thing. After my changes I tried make test and noticed that > >>>the Config.t is skipped, because it's only required for a local > >>>BioMOBY Central..., but I do have one and I have set my > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > >>>familiar with the test scripts... > >> > >> > >>I think you just got yourself nominated to be caretaker of the test > >>t/Config.t. I don't have a local registry, so there was no way for me to > >>test its operation. Most users (I think) are in the same position, so > >>this test is skipped by default. > >> > >>For details on how to use the testing framework, you could look at > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > >>execute some MOBY code for which you believe you know the output. You > >>compare actual output to expected output using the is() function. It > >>generates errors if the two don't match. You can also check for correct > >>failure using isnt(), which generates a similar error. Examples might be: > >> > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > >>showing up on output device > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > >> > >>Generally, tests should be symbolic, rather than specific. This leads to > >>tests that are more easy to maintain over time: if an array is built > >>before it is tested, and if it's tested symbolically, it should be > >>possible to alter the array contents at a later point, without breaking > >>that test. Take a look in the Client-Central.t for examples of this: a > >>registration structure is created, services are registered, then the > >>registration object is itself queried, and the results compared > >>symbolically with the original data. This verifies that the information > >>flows through the system correctly. If someone later decides to change a > >>small detail (e.g., a parameter name), the tests should continue to pass > >>without modification. > >> > >>But the tests themselves don't really have to complicated to be useful: > >>check that each module exports the functions it claims to implement, > >>check that set/get methods work correctly, check return types in all > >>contexts (does it return array in list context, scalar in scalar > >>context). All that stuff is important in maintaining a coherent interface > >>over time. It also helps to find inconsistencies. > >> > >>I think it would be really great if you could build some useful, robust, > >>portable tests for the local-registry configuration. This kind of test > >>can be a big help to users trying to install their local registry, so its > >>utility goes beyond merely regression testing the code, it's also useful > >>to debugging local installations with perfectly functioning code. > >> > >>-Frank > >> > >>PhD, Computational Biologist, > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > >>Tel: 617-432-3555 Fax: 617-432-3557 > >>http://llama.med.harvard.edu/~fgibbons > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From francis_gibbons at hms.harvard.edu Wed Nov 23 16:49:15 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 23 Nov 2005 16:49:15 -0500 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <1132779947.22071.10.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Mark, Just ran the tests. Looks good, except the informational message is somewhat jarring... ideally, the only output that appears is a series of test-file names, with "..........ok" after them. I wonder if developers need to see that message each time they run the tests - perhaps it would help just as well if it were embedded as comments? What do you think? I'll be gone for a few days, as it Thanksgiving down here. -Frank At 04:05 PM 11/23/2005, you wrote: >On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > > > So Mark, if I understand correctly, it should first check to see if the > > user has defined those environment variables. That should indicate that > the > > user does have a local registry. > >Not necessarily local - the environment variables are simply a way of >specifying which MOBY Central you wish to talk to by default (i.e. when >you don't initialize the MOBY::Client::Central object with a >"Registries" parameter). > >The following statements describe what happens: > >1) The MOBY::Client::Central module is hard-coded to default to >mobycentral.icapture.ubc.ca as it's default registry > >2) When it is initializing, it first checks for the MOBY_SERVER and >MOBY_URI environment variables and uses those instead of the defaults if >they exist, otherwise it will default. > >3) Initializing MOBY::Client::Central using the "Registries" argument >will over-ride both of the previous behaviours > -> use of this argument also allows you to interact with more > than one >registry at a time (for **read-only** interactions) ...(note that this >latter behaviour has never been adequately tested, since it has never >been used AFAIK) > > > > > It should a local registry if available, > > but fall back to using MOBY Central if it's not available. Right? > > >yup. That behaviour has always been true, actually; however the test >harness was hard coded to use the 'Registries' argument when it started- >up, so it was over-riding the useful behaviour that >MOBY::Client::Central already had :-) > >The same behaviour is now true for MOBY::Client::OntologyServer - it >will first check the environment variable, and if it isn't set, then it >will default to call home to mobycentral.icapture.ubc.ca > >Cheers! > >M > > > > > > That'd be awsome! > > > > -Frank > > > > > > >M > > > > > > > > > > > >Frank Gibbons wrote: > > > > > >>Congratulations, Pieter, > > >> > > >>At 08:32 AM 11/21/2005, you wrote: > > >> > > >>>One more thing. After my changes I tried make test and noticed that > > >>>the Config.t is skipped, because it's only required for a local > > >>>BioMOBY Central..., but I do have one and I have set my > > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > > >>>familiar with the test scripts... > > >> > > >> > > >>I think you just got yourself nominated to be caretaker of the test > > >>t/Config.t. I don't have a local registry, so there was no way for me to > > >>test its operation. Most users (I think) are in the same position, so > > >>this test is skipped by default. > > >> > > >>For details on how to use the testing framework, you could look at > > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > > >>execute some MOBY code for which you believe you know the output. You > > >>compare actual output to expected output using the is() function. It > > >>generates errors if the two don't match. You can also check for correct > > >>failure using isnt(), which generates a similar error. Examples might be: > > >> > > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > > >>showing up on output device > > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > >> > > >>Generally, tests should be symbolic, rather than specific. This leads to > > >>tests that are more easy to maintain over time: if an array is built > > >>before it is tested, and if it's tested symbolically, it should be > > >>possible to alter the array contents at a later point, without breaking > > >>that test. Take a look in the Client-Central.t for examples of this: a > > >>registration structure is created, services are registered, then the > > >>registration object is itself queried, and the results compared > > >>symbolically with the original data. This verifies that the information > > >>flows through the system correctly. If someone later decides to change a > > >>small detail (e.g., a parameter name), the tests should continue to pass > > >>without modification. > > >> > > >>But the tests themselves don't really have to complicated to be useful: > > >>check that each module exports the functions it claims to implement, > > >>check that set/get methods work correctly, check return types in all > > >>contexts (does it return array in list context, scalar in scalar > > >>context). All that stuff is important in maintaining a coherent > interface > > >>over time. It also helps to find inconsistencies. > > >> > > >>I think it would be really great if you could build some useful, robust, > > >>portable tests for the local-registry configuration. This kind of test > > >>can be a big help to users trying to install their local registry, so > its > > >>utility goes beyond merely regression testing the code, it's also useful > > >>to debugging local installations with perfectly functioning code. > > >> > > >>-Frank > > >> > > >>PhD, Computational Biologist, > > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > > >>Tel: 617-432-3555 Fax: 617-432-3557 > > >>http://llama.med.harvard.edu/~fgibbons > > >>_______________________________________________ > > >>MOBY-dev mailing list > > >>MOBY-dev at biomoby.org > > >>http://www.biomoby.org/mailman/listinfo/moby-dev > > >> > > > > > >_______________________________________________ > > >MOBY-dev mailing list > > >MOBY-dev at biomoby.org > > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > PhD, Computational Biologist, > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > > Tel: 617-432-3555 Fax: > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev >-- >"Ontologists do it with the edges!" > >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 Wed Nov 23 17:34:19 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 23 Nov 2005 14:34:19 -0800 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Message-ID: <1132785259.22071.22.camel@bioinfo.icapture.ubc.ca> It doesn't really bother me so much, but to be honest I think the bigger problem is that "make install" doesn't create a default local registry, and that "make test" would have to be run after "make install", which is even stranger. There was a time when Richard B had set up the Makefile to do this, or at least had set up an install script that would do the default MOBY Central installation and bootstrapping... that might be worth resurrecting. I think the code is still commented out in the Makefile... M On Wed, 2005-11-23 at 16:49 -0500, Frank Gibbons wrote: > Mark, > > Just ran the tests. Looks good, except the informational message is > somewhat jarring... ideally, the only output that appears is a series of > test-file names, with "..........ok" after them. I wonder if developers > need to see that message each time they run the tests - perhaps it would > help just as well if it were embedded as comments? What do you think? > > I'll be gone for a few days, as it Thanksgiving down here. > > -Frank > > At 04:05 PM 11/23/2005, you wrote: > >On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > > > > > So Mark, if I understand correctly, it should first check to see if the > > > user has defined those environment variables. That should indicate that > > the > > > user does have a local registry. > > > >Not necessarily local - the environment variables are simply a way of > >specifying which MOBY Central you wish to talk to by default (i.e. when > >you don't initialize the MOBY::Client::Central object with a > >"Registries" parameter). > > > >The following statements describe what happens: > > > >1) The MOBY::Client::Central module is hard-coded to default to > >mobycentral.icapture.ubc.ca as it's default registry > > > >2) When it is initializing, it first checks for the MOBY_SERVER and > >MOBY_URI environment variables and uses those instead of the defaults if > >they exist, otherwise it will default. > > > >3) Initializing MOBY::Client::Central using the "Registries" argument > >will over-ride both of the previous behaviours > > -> use of this argument also allows you to interact with more > > than one > >registry at a time (for **read-only** interactions) ...(note that this > >latter behaviour has never been adequately tested, since it has never > >been used AFAIK) > > > > > > > > > It should a local registry if available, > > > but fall back to using MOBY Central if it's not available. Right? > > > > > >yup. That behaviour has always been true, actually; however the test > >harness was hard coded to use the 'Registries' argument when it started- > >up, so it was over-riding the useful behaviour that > >MOBY::Client::Central already had :-) > > > >The same behaviour is now true for MOBY::Client::OntologyServer - it > >will first check the environment variable, and if it isn't set, then it > >will default to call home to mobycentral.icapture.ubc.ca > > > >Cheers! > > > >M > > > > > > > > > > > That'd be awsome! > > > > > > -Frank > > > > > > > > > >M > > > > > > > > > > > > > > > >Frank Gibbons wrote: > > > > > > > >>Congratulations, Pieter, > > > >> > > > >>At 08:32 AM 11/21/2005, you wrote: > > > >> > > > >>>One more thing. After my changes I tried make test and noticed that > > > >>>the Config.t is skipped, because it's only required for a local > > > >>>BioMOBY Central..., but I do have one and I have set my > > > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > > > >>>familiar with the test scripts... > > > >> > > > >> > > > >>I think you just got yourself nominated to be caretaker of the test > > > >>t/Config.t. I don't have a local registry, so there was no way for me to > > > >>test its operation. Most users (I think) are in the same position, so > > > >>this test is skipped by default. > > > >> > > > >>For details on how to use the testing framework, you could look at > > > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > > > >>execute some MOBY code for which you believe you know the output. You > > > >>compare actual output to expected output using the is() function. It > > > >>generates errors if the two don't match. You can also check for correct > > > >>failure using isnt(), which generates a similar error. Examples might be: > > > >> > > > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > > > >>showing up on output device > > > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > > >> > > > >>Generally, tests should be symbolic, rather than specific. This leads to > > > >>tests that are more easy to maintain over time: if an array is built > > > >>before it is tested, and if it's tested symbolically, it should be > > > >>possible to alter the array contents at a later point, without breaking > > > >>that test. Take a look in the Client-Central.t for examples of this: a > > > >>registration structure is created, services are registered, then the > > > >>registration object is itself queried, and the results compared > > > >>symbolically with the original data. This verifies that the information > > > >>flows through the system correctly. If someone later decides to change a > > > >>small detail (e.g., a parameter name), the tests should continue to pass > > > >>without modification. > > > >> > > > >>But the tests themselves don't really have to complicated to be useful: > > > >>check that each module exports the functions it claims to implement, > > > >>check that set/get methods work correctly, check return types in all > > > >>contexts (does it return array in list context, scalar in scalar > > > >>context). All that stuff is important in maintaining a coherent > > interface > > > >>over time. It also helps to find inconsistencies. > > > >> > > > >>I think it would be really great if you could build some useful, robust, > > > >>portable tests for the local-registry configuration. This kind of test > > > >>can be a big help to users trying to install their local registry, so > > its > > > >>utility goes beyond merely regression testing the code, it's also useful > > > >>to debugging local installations with perfectly functioning code. > > > >> > > > >>-Frank > > > >> > > > >>PhD, Computational Biologist, > > > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > > 02115, USA. > > > >>Tel: 617-432-3555 Fax: 617-432-3557 > > > >>http://llama.med.harvard.edu/~fgibbons > > > >>_______________________________________________ > > > >>MOBY-dev mailing list > > > >>MOBY-dev at biomoby.org > > > >>http://www.biomoby.org/mailman/listinfo/moby-dev > > > >> > > > > > > > >_______________________________________________ > > > >MOBY-dev mailing list > > > >MOBY-dev at biomoby.org > > > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > PhD, Computational Biologist, > > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > > USA. > > > Tel: 617-432-3555 Fax: > > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > >-- > >"Ontologists do it with the edges!" > > > >Mark Wilkinson > >Asst. Professor > >Dept. of Medical Genetics > >University of British Columbia > >PI in Bioinformatics > >iCAPTURE Centre > >St. Paul's Hospital > >Rm. 166, 1081 Burrard St. > >Vancouver, BC, V6Z 1Y6 > >tel: 604 682 2344 x62129 > >fax: 604 806 9274 > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From jmfernandez at cnb.uam.es Wed Nov 23 17:20:14 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Wed, 23 Nov 2005 23:20:14 +0100 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu><5.2.1. 1.2.20051121093229.010aed90@email.med.harvard.edu><5.2.1.1.2.20051118123741 .0123a990@email.med.harvard.edu><432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.n l><004401c5e94d$ab0c70c0$6600a8c0@notebook><004401c5e94d$ab0c70c0$6600a8c0@ notebook><5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu><432C2FF2 -E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl><5.2.1.1.2.20051118123741.0123a990@emai l.med.harvard.edu><5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Message-ID: <4384EB1E.9080403@cnb.uam.es> Hi everybody, I have installed many Perl packages, and many of them show lots of information when it is done the next invokation: make TEST_VERBOSE=1 test For instance, DBI uses Test::More inside its tests. Best Regards, Jos? Mar?a Frank Gibbons wrote: > Mark, > > Just ran the tests. Looks good, except the informational message is > somewhat jarring... ideally, the only output that appears is a series of > test-file names, with "..........ok" after them. I wonder if developers > need to see that message each time they run the tests - perhaps it would > help just as well if it were embedded as comments? What do you think? > > I'll be gone for a few days, as it Thanksgiving down here. > > -Frank > > At 04:05 PM 11/23/2005, you wrote: > >> On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: >> >> > So Mark, if I understand correctly, it should first check to see if the >> > user has defined those environment variables. That should indicate >> that the >> > user does have a local registry. >> >> Not necessarily local - the environment variables are simply a way of >> specifying which MOBY Central you wish to talk to by default (i.e. when >> you don't initialize the MOBY::Client::Central object with a >> "Registries" parameter). >> >> The following statements describe what happens: >> >> 1) The MOBY::Client::Central module is hard-coded to default to >> mobycentral.icapture.ubc.ca as it's default registry >> >> 2) When it is initializing, it first checks for the MOBY_SERVER and >> MOBY_URI environment variables and uses those instead of the defaults if >> they exist, otherwise it will default. >> >> 3) Initializing MOBY::Client::Central using the "Registries" argument >> will over-ride both of the previous behaviours >> -> use of this argument also allows you to interact with more >> than one >> registry at a time (for **read-only** interactions) ...(note that this >> latter behaviour has never been adequately tested, since it has never >> been used AFAIK) >> >> >> >> > It should a local registry if available, >> > but fall back to using MOBY Central if it's not available. Right? >> >> >> yup. That behaviour has always been true, actually; however the test >> harness was hard coded to use the 'Registries' argument when it started- >> up, so it was over-riding the useful behaviour that >> MOBY::Client::Central already had :-) >> >> The same behaviour is now true for MOBY::Client::OntologyServer - it >> will first check the environment variable, and if it isn't set, then it >> will default to call home to mobycentral.icapture.ubc.ca >> >> Cheers! >> >> M >> >> >> >> >> > That'd be awsome! >> > >> > -Frank >> > >> > >> > >M >> > > >> > > >> > > >> > >Frank Gibbons wrote: >> > > >> > >>Congratulations, Pieter, >> > >> >> > >>At 08:32 AM 11/21/2005, you wrote: >> > >> >> > >>>One more thing. After my changes I tried make test and noticed that >> > >>>the Config.t is skipped, because it's only required for a local >> > >>>BioMOBY Central..., but I do have one and I have set my >> > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> > >>>familiar with the test scripts... >> > >> >> > >> >> > >>I think you just got yourself nominated to be caretaker of the test >> > >>t/Config.t. I don't have a local registry, so there was no way for >> me to >> > >>test its operation. Most users (I think) are in the same position, so >> > >>this test is skipped by default. >> > >> >> > >>For details on how to use the testing framework, you could look at >> > >>the Perl modules Test::Simple and Test:More. The basic idea is >> that you >> > >>execute some MOBY code for which you believe you know the output. You >> > >>compare actual output to expected output using the is() function. It >> > >>generates errors if the two don't match. You can also check for >> correct >> > >>failure using isnt(), which generates a similar error. Examples >> might be: >> > >> >> > >>is(2+2, 4, "Can't do addition");' # Generates error with this string >> > >>showing up on output device >> > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> > >> >> > >>Generally, tests should be symbolic, rather than specific. This >> leads to >> > >>tests that are more easy to maintain over time: if an array is built >> > >>before it is tested, and if it's tested symbolically, it should be >> > >>possible to alter the array contents at a later point, without >> breaking >> > >>that test. Take a look in the Client-Central.t for examples of >> this: a >> > >>registration structure is created, services are registered, then the >> > >>registration object is itself queried, and the results compared >> > >>symbolically with the original data. This verifies that the >> information >> > >>flows through the system correctly. If someone later decides to >> change a >> > >>small detail (e.g., a parameter name), the tests should continue >> to pass >> > >>without modification. >> > >> >> > >>But the tests themselves don't really have to complicated to be >> useful: >> > >>check that each module exports the functions it claims to implement, >> > >>check that set/get methods work correctly, check return types in all >> > >>contexts (does it return array in list context, scalar in scalar >> > >>context). All that stuff is important in maintaining a coherent >> interface >> > >>over time. It also helps to find inconsistencies. >> > >> >> > >>I think it would be really great if you could build some useful, >> robust, >> > >>portable tests for the local-registry configuration. This kind of >> test >> > >>can be a big help to users trying to install their local registry, >> so its >> > >>utility goes beyond merely regression testing the code, it's also >> useful >> > >>to debugging local installations with perfectly functioning code. >> > >> >> > >>-Frank >> > >> >> > >>PhD, Computational Biologist, >> > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> > >>Tel: 617-432-3555 Fax: 617-432-3557 >> > >>http://llama.med.harvard.edu/~fgibbons >> > >>_______________________________________________ >> > >>MOBY-dev mailing list >> > >>MOBY-dev at biomoby.org >> > >>http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> >> > > >> > >_______________________________________________ >> > >MOBY-dev mailing list >> > >MOBY-dev at biomoby.org >> > >http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> > PhD, Computational Biologist, >> > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> > Tel: 617-432-3555 Fax: >> > 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev at biomoby.org >> > http://www.biomoby.org/mailman/listinfo/moby-dev >> -- >> "Ontologists do it with the edges!" >> >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From senger at ebi.ac.uk Thu Nov 24 09:14:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 24 Nov 2005 14:14:41 +0000 (GMT) Subject: [MOBY-dev] Biomoby Dashboard beta release Message-ID: Dear Moby-ists, There is another result (after Moses code generator) of my lucky (lucky for me) involvement with the Generation Challenge Programm and with IRRI particularly: it is my pleasure to announce a beta version of a Biomoby Dashboard (or shortly a Dash, as Eddie already nicknamed it, but I am not sure about English, especially slang English meaning of it :-)). It is for Biomoby service providers, it is potentially extensible also for Biomoby client. We will be adding there new panels shortly, and I hope to get feedback from you so we can improve it. I am sorry that the documentation is (almost) missing, but I wanted to release it so I can get feedback as soon as possible. We are working on documentation, as well. You can find basic instructions and some screen-shots here: http://biomoby.org/moby-live/Java/docs/Dashboard.html. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From rebecca.ernst at gsf.de Fri Nov 25 04:55:13 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri, 25 Nov 2005 10:55:13 +0100 Subject: [MOBY-dev] dashboard Message-ID: <4386DF81.6040500@gsf.de> Hi Martin! I had a first look at dashboard and I really loved it! I makes things so much easier! I also found it quite intuitive to use. In principle everything worked but there were some problems. 1) If I use the planet registry it reads out the datatypes but after finishing reading it doesn't have them anymore. Is it possible that it misses the LSID resolver which we don't have yet? 2) In the Moses-Generator section I couldn't find out how to select a service to generate code for... I have them in the service listing on the left but how do I select one to generate code for?? Cheers, Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Fri Nov 25 11:11:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 25 Nov 2005 08:11:35 -0800 Subject: [moby] [MOBY-dev] dashboard In-Reply-To: <4386DF81.6040500@gsf.de> References: <4386DF81.6040500@gsf.de> Message-ID: <1132935095.27789.21.camel@bioinfo.icapture.ubc.ca> We can help you set up the LSID resolver if you like. The current release of the Perl LSID stack is broken, but in the past week the CVS version is now working - we've asked them to make a release, since this is the last unfinished issue that is preventing us from both starting the RDF agent, and making a new MOBY code release... LSID's in Perl have been problematic for years, and have prevented us from ever becoming dependent on them v.v. the RDF agent, as Martin has pointed out several times! Hopefully this latest release will be stable for the long-term... hopefully! In any case, I suspect that Martin's dashboard is using LSID resolution of MOBY stuff to metadata, since he was asking about it frequently in the past few weeks. If that is the only issue standing between you and success, then please let me know and either Eddie or I will get you up and running quickly! M On Fri, 2005-11-25 at 10:55 +0100, Rebecca Ernst wrote: > Hi Martin! > > I had a first look at dashboard and I really loved it! I makes things so > much easier! I also found it quite intuitive to use. > > In principle everything worked but there were some problems. > > 1) If I use the planet registry it reads out the datatypes but after > finishing reading it doesn't have them anymore. Is it possible that it > misses the LSID resolver which we don't have yet? > > 2) In the Moses-Generator section I couldn't find out how to select a > service to generate code for... I have them in the service listing on > the left but how do I select one to generate code for?? > > Cheers, > Rebecca > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Fri Nov 25 12:45:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 25 Nov 2005 09:45:27 -0800 Subject: [MOBY-dev] biomoby.org moving to new server Message-ID: <1132940727.27789.48.camel@bioinfo.icapture.ubc.ca> Hi all, heads up that the DNS changes are about to start propagating through the net. By tomorrow we should be serving everything from the new server. LSID resolution should not be affected, since the lsid SRV records are held on a different machine entirely... but touch wood in any case. Please let me know ASAP if you notice any problems. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Sat Nov 26 00:19:46 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 26 Nov 2005 05:19:46 +0000 (GMT) Subject: [MOBY-dev] dashboard In-Reply-To: <4386DF81.6040500@gsf.de> Message-ID: > 1) If I use the planet registry it reads out the datatypes but after > finishing reading it doesn't have them anymore. > This would be a serious bug, not a "small thing" :-) You were simply too polite in your answer... Can I try myself, is the plant registry open? If so, please give me th URL and URI. Anyway, what do you mean by "does not have them anymore"? Does it show anything in the data types tree, or nothing at all? Perhaps it is again the bug I have mentioned in the "known bug" about synchronization - I *have* to find what is wrong here, it drives me crazy! > Is it possible that it misses the LSID resolver which we don't have > yet? > No, nothing to do with LSID resolver. Dasboard, and me either, do not use LSID resolver. And will not until it is clearly defined. Biomoby is vague about it. I will respond more specifically about in later when I reply to Mark's email. > 2) In the Moses-Generator section I couldn't find out how to select a > service to generate code for... > In the same way as in any selction list: CTRL and click on selected - and it should unselect (there may be some OS-specific ways but I think that CTRL, or Apple keys usually works). > I have them in the service listing on the left but how do I select one > to generate code for?? > All services that are selected in the tree on the left will be used to generate code for them. You can select either an authority - then all their services will be used, or individual services. Yoy can select more by holding CTRL or SHIFT key (again, this is not Dasboard specific, it is the same with other programs taht allow multiple selection). Below the tree there is a note how many services and authorities are currently selected. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Nov 26 15:15:02 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 26 Nov 2005 20:15:02 +0000 GMT Subject: [MOBY-dev] dashboard Message-ID: <74945373-1133036350-cardhu_blackberry.rim.net-11436-@engine08-cell01> Hi Martin, Can you give me an example of a sentence about the lsid resolver that you would find sufficiently non-vague? The discussion on the website seems quite clear to me, but you have higher standards :-) M -----Original Message----- From: Martin Senger Date: Sat, 26 Nov 2005 05:19:46 To:Rebecca Ernst Cc:moby-dev at biomoby.org Subject: Re: [MOBY-dev] dashboard > 1) If I use the planet registry it reads out the datatypes but after > finishing reading it doesn't have them anymore. > This would be a serious bug, not a "small thing" :-) You were simply too polite in your answer... Can I try myself, is the plant registry open? If so, please give me th URL and URI. Anyway, what do you mean by "does not have them anymore"? Does it show anything in the data types tree, or nothing at all? Perhaps it is again the bug I have mentioned in the "known bug" about synchronization - I *have* to find what is wrong here, it drives me crazy! > Is it possible that it misses the LSID resolver which we don't have > yet? > No, nothing to do with LSID resolver. Dasboard, and me either, do not use LSID resolver. And will not until it is clearly defined. Biomoby is vague about it. I will respond more specifically about in later when I reply to Mark's email. > 2) In the Moses-Generator section I couldn't find out how to select a > service to generate code for... > In the same way as in any selction list: CTRL and click on selected - and it should unselect (there may be some OS-specific ways but I think that CTRL, or Apple keys usually works). > I have them in the service listing on the left but how do I select one > to generate code for?? > All services that are selected in the tree on the left will be used to generate code for them. You can select either an authority - then all their services will be used, or individual services. Yoy can select more by holding CTRL or SHIFT key (again, this is not Dasboard specific, it is the same with other programs taht allow multiple selection). Below the tree there is a note how many services and authorities are currently selected. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Sun Nov 27 00:51:54 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 27 Nov 2005 05:51:54 +0000 (GMT) Subject: [MOBY-dev] Moby API/LSID (Was: dashboard) In-Reply-To: <74945373-1133036350-cardhu_blackberry.rim.net-11436-@engine08-cell01> Message-ID: > Can you give me an example of a sentence about the lsid resolver that > you would find sufficiently non-vague? The discussion on the website > seems quite clear to me, but you have higher standards :-) > Well, as usual, I am confused :-) What discussion? And what website? No, I am not making jokes now, I do not remember any discussion how to use LSIDs in Biomoby. At least no recently. Anyway, here are the remarsks I have promise to send: Biomoby consists of several parts, each of them may have several protocols (or APIs). Some of them are well defined, some of them are just assumed. Here they are as I understand it: 1) An API how to communicate with a Biomoby registry and with Biomoby services, using SOAP and XML messages. This is well defined on the Biomoby website and everybody is cautious to change it only after good discussion happens. It is in good shape, eventhough it may soon ask for some changes, such as asynchonous invocation. The only "problem" with this API is my feeling (just feeling, no evidence at all) that Mark would like to let this API go in the future, and a closer collaboration with S-Moby may be a good excuse for it. But it is just a feeling, we will cross that brige when we come to it. 2) The contents of the RDF document returned when a provider registered a service is part of the API mentioned above, but it is not documented (at least I have not seen any documentation). In theory, providers do not "need to know" the contents, they just get it from the registry and put it somewhere as a token for the RDF agent. But in practice, it was recommended to use it to enhance information about your services. In order to do that a provider needs to know the predicate names (and what they mean) that are there always and that may be there. Such discussion about predicate names started (at least I and Eddie discussed it in Malaga, and people briefly discussed it already in Vancouver) but it was never "officially" approved and made part of the Biomoby well-defined behaviour. 3) And finally, there is an LSID resolver. Which means that any entity that has an LSID (in our case, an LSID assigned by a Biomoby registry when the entity was registered) can be "resolved" by LSID's API. The LSID' API is weel-defined, but it can be still used in several different ways. And I believe that we should define what ways we prefer to have in Biomoby. Here is a list of few things that came to my mind during writing this paragraph but they may be other that I forgot. We surely have not discussed it in such details yet: * LSID API has methods getData and getMetadata. Any of them can return an empty result. What would be recommended for us: an empty getData() or not? For some entities it would be quite good to get something from getData()... * Resolving LSID metadata has more steps than just to make an HTTP connection and to get an RDF file. But I guess that we want to recommend to use just this step. So we are slightly "abusing" (in a possitive way) the LSID spec, but we do not document it. * LSID metadata must have well defined predicates (at least some) - this is the same problem as described in paragraph ad 2). Well, I stop now, too long email. But this is what I called "vague". And I do not think that I have any "higher standard" than it should be usual for a stable and robust software. And we want to have Biomoby a stable and robust software, don't we? Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sun Nov 27 12:05:16 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 27 Nov 2005 09:05:16 -0800 Subject: [MOBY-dev] Moby API/LSID (Was: dashboard) In-Reply-To: References: Message-ID: <4389E74C.4000801@illuminae.com> Martin Senger wrote: > Well, as usual, I am confused :-) What discussion? And what website? > No, I am not making jokes now, I do not remember any discussion how to >use LSIDs in Biomoby. At least no recently. Anyway, here are the remarsks >I have promise to send: > > I pointed you to this a couple of weeks ago and asked for your comments (or at least, I think I did... maybe not to you directly, but to the -dev list): http://biomoby.open-bio.org/index.php/for-developers/moby_extensions > 2) The contents of the RDF document returned when a provider registered >a service is part of the API mentioned above, but it is not documented (at >least I have not seen any documentation). In theory, providers do not >"need to know" the contents, they just get it from the registry and put it >somewhere as a token for the RDF agent. But in practice, it was >recommended to use it to enhance information about your services. In order >to do that a provider needs to know the predicate names (and what they >mean) that are there always and that may be there. Such discussion about >predicate names started (at least I and Eddie discussed it in Malaga, and >people briefly discussed it already in Vancouver) but it was never >"officially" approved and made part of the Biomoby well-defined behaviour. > > The predicates have only recently been defined for Service Instances since we have just finished working with myGrid to merge our data models. They've been defined for longer for the ontologies, but there have been no comments one way or the other on whether or not people like the RDF structure for the ontologies. In any case, I've listed all of the predicates on the new website, and am starting to document them now... slowly! Some of them I cannot document since they are in the mygrid namespace, and they aren't documented there (though I could guess). They are, however, all defined in a machine-readable way within their respective namespaces. The MOBY ones can be resolved to additional explanatory RDF if you resolve the predicate's namespace. I think the mygrid namespace does not currently resolve, but you can get it from some other URL (which escapes me at the moment). > * LSID API has methods getData and getMetadata. Any of them can return >an empty result. What would be recommended for us: an empty getData() or >not? For some entities it would be quite good to get something from >getData()... > > I note this behaviour as being undefined on the website. It may or may not return something, since we are experimenting with what kinds of things are best to return, but it is explicitly stated on the website that you should not rely on what is returned until the behaviour is defined > * Resolving LSID metadata has more steps than just to make an HTTP >connection and to get an RDF file. But I guess that we want to >recommend to use just this step. So we are slightly "abusing" (in a >possitive way) the LSID spec, but we do not document it. > > Can you write a sentence that explains this? I don't really understand what you mean either... > * LSID metadata must have well defined predicates (at least some) - >this is the same problem as described in paragraph ad 2). > > this is done at least in part, but the definitions are not well written yet. The more comments the better, since it would be nice to get this documented in a robust way! M From senger at ebi.ac.uk Sun Nov 27 12:50:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 27 Nov 2005 17:50:11 +0000 (GMT) Subject: [MOBY-dev] Moby API/LSID (Was: dashboard) In-Reply-To: <4389E74C.4000801@illuminae.com> Message-ID: > I pointed you to this a couple of weeks ago and asked for your comments > (or at least, I think I did... maybe not to you directly, but to the > -dev list): > > http://biomoby.open-bio.org/index.php/for-developers/moby_extensions > Okay, this is the page I was hoping for. I am going to read it and make comments. I missed its existence so far. > The predicates have only recently been defined for Service Instances > since we have just finished working with myGrid > Mark, I think the sentence above describes the whole problem: it says "we have just finished". But who are we? That's just you. And perhaps Eddie. But who else is involved in what is going to happen with relationship between myGrid and Biomoby? We, people on moby-dev list, do not know (well, I should talk only for myself, sorry for that: I do not know). You have been talking about myGrid for a long time, but I have not seen any... well, not results, that would be too premature, but anything we can discuss. Mark, you built the Biomoby ideas (your ideas) into a running product, and you convinced people to build services accrodingly. That's good, and you have flowers for it. But the project will die if you keep it that way. You need more people to be involved in the decisions what next - and we have started, not perhaps too succesfully, but still - an RFC process. So why not to put the "myGrid stuff", whatever it means, into a proposal and we can discuss it? But give us some time to digest it. > In any case, I've listed all of the predicates on the new website, and > am starting to document them now... slowly! > Present them as a new RFC, not as something done - that would make me feel better. And an RFC has deadline, so if people do not respond in time, that's their decision, they cannot complain that they were put aside. > Some of them I cannot document since they are in the mygrid namespace, > and they aren't documented there (though I could guess). > Sorry to say that, but it seems like nonsense. We are talking about an interface (in whatever means, not necessarily an API) that will be used by developers, so it must be expressed in a way the humans will understand it. > > * Resolving LSID metadata has more steps than just to make an HTTP > >connection and to get an RDF file. But I guess that we want to > >recommend to use just this step. So we are slightly "abusing" (in a > >possitive way) the LSID spec, but we do not document it. > > > > > Can you write a sentence that explains this? I don't really understand > what you mean either... > Starting point is "I have an LSID". And I want metadata describing it. What are the steps to follow: 1) Resolve the LSID to an endpoint. 2) Call there a method getAvailableServices(myLSID) It gets back URls of all places that have anything to tell about this particular LSID 3) On each of this places you call getMetadata() My guess is that by "resolving LSID to metadata" you mean just the third step, and only if this particular site provides the metadata using a pure HTTP protocol, no SOAP. I am not saying that it is bad, but bad is not to document it properly... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From tmo at ebi.ac.uk Tue Nov 29 11:03:32 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Tue, 29 Nov 2005 16:03:32 +0000 Subject: [MOBY-dev] Error from taverna biomoby plugin Message-ID: <438C7BD4.7010204@ebi.ac.uk> Hi all, I'm getting an error from the biomoby scavenger : org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: Could not retrieve and or process RDF document for BioMoby Objects at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:189) at org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge rLoaderThread.run(ScavengerTree.java:327) Caused by: java.lang.NullPointerException at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:185) ... 1 more Any ideas? Was working until recently. Tom From edward.kawas at gmail.com Tue Nov 29 10:59:46 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 29 Nov 2005 07:59:46 -0800 Subject: [MOBY-dev] Error from taverna biomoby plugin In-Reply-To: <438C7BD4.7010204@ebi.ac.uk> Message-ID: <000001c5f4fd$eccfc5f0$6700a8c0@notebook> Hi Tom, This is probably due to the server switch. I will look into it and get back to you. Thanks, Eddie -----Original Message----- From: moby-dev-bounces at biomoby.org [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Tom Oinn Sent: Tuesday, November 29, 2005 8:04 AM To: mobydev Subject: [MOBY-dev] Error from taverna biomoby plugin Hi all, I'm getting an error from the biomoby scavenger : org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: Could not retrieve and or process RDF document for BioMoby Objects at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:189) at org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge rLoaderThread.run(ScavengerTree.java:327) Caused by: java.lang.NullPointerException at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:185) ... 1 more Any ideas? Was working until recently. Tom _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Nov 29 11:14:20 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 29 Nov 2005 08:14:20 -0800 Subject: [MOBY-dev] [moby] Error from taverna biomoby plugin In-Reply-To: <438C7BD4.7010204@ebi.ac.uk> References: <438C7BD4.7010204@ebi.ac.uk> Message-ID: <1133280860.30604.7.camel@bioinfo.icapture.ubc.ca> I'm on it. a redirect isn't working, but I can't figure out why. M On Tue, 2005-11-29 at 16:03 +0000, Tom Oinn wrote: > Hi all, > > I'm getting an error from the biomoby scavenger : > > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: > Could not retrieve and or process RDF document for BioMoby Objects > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:189) > at > org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge > rLoaderThread.run(ScavengerTree.java:327) > Caused by: java.lang.NullPointerException > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:185) > ... 1 more > > Any ideas? Was working until recently. > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Tue Nov 29 15:23:21 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 29 Nov 2005 12:23:21 -0800 Subject: [MOBY-dev] [moby] Error from taverna biomoby plugin In-Reply-To: <438C7BD4.7010204@ebi.ac.uk> References: <438C7BD4.7010204@ebi.ac.uk> Message-ID: <1133295801.30604.132.camel@bioinfo.icapture.ubc.ca> Should be solved now M On Tue, 2005-11-29 at 16:03 +0000, Tom Oinn wrote: > Hi all, > > I'm getting an error from the biomoby scavenger : > > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: > Could not retrieve and or process RDF document for BioMoby Objects > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:189) > at > org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge > rLoaderThread.run(ScavengerTree.java:327) > Caused by: java.lang.NullPointerException > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:185) > ... 1 more > > Any ideas? Was working until recently. > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Wed Nov 2 12:32:47 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed, 02 Nov 2005 13:32:47 +0100 Subject: [MOBY-dev] parseMobyData Message-ID: <4368B1EF.9060004@gsf.de> Hi Eddie! I had another look into Taverna to see if our workflows now run correctly but found two problems of parseMobyData. The first problem is that parseMobyData can't deal with collections (it never could) the second is that it also can't deal with the new object stucture (e.g. a string object containing a string now) as it only checks the first layer content and never goes into the additional string. Do you know of these problems and if so - are there any plans for fixing it? Cheers, Rebecca From Pieter.Neerincx at wur.nl Wed Nov 2 12:44:21 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 2 Nov 2005 13:44:21 +0100 Subject: [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <4360E4FD.6090202@ucalgary.ca> References: <4360E4FD.6090202@ucalgary.ca> Message-ID: <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> Hi all, Here is a question for those using the Perl API. In MOBY/Client/Central.pm we have a sub retrieveObjectDefinition which calls sub _ObjectDefinitionPayload { This produces an array for the objects, articleNames and lsids for the relationships of the object whose definition is requested. I'm wondering why this is an array. Currently I have to rely on the order of elements in this array to figure out which element is the object, which one is articleName, etc. These are the lines producing the array: 553 push @{ $relationships{$relationshipType} }, 554 [ $_->toString, $article, $rlsid ]; Is there any reason why this should be an array? I'd rather not have to rely on the order of the elements, so are there people who have any objections when I change this into a hash like in: push @{ $relationships{$relationshipType} }, { object => $_->toString, articleName => $article, lsid => $rlsid }; Cheers, Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Wed Nov 2 13:06:16 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 2 Nov 2005 14:06:16 +0100 Subject: [MOBY-dev] parseMobyData In-Reply-To: <4368B1EF.9060004@gsf.de> References: <4368B1EF.9060004@gsf.de> Message-ID: <0B94C244-81D6-4AE5-A457-37E71E0192E5@wur.nl> Hi all, On 2-Nov-2005, at 1:32 PM, Rebecca Ernst wrote: > Hi Eddie! > > I had another look into Taverna to see if our workflows now run > correctly but found two problems of parseMobyData. > The first problem is that parseMobyData can't deal with collections > (it never could) the second is that it also can't deal with the new > object stucture (e.g. a string object containing a string now) as > it only checks the first layer content and never goes into the > additional string. Well as far as I know it never did that either. It's a much bigger problem. It will not decompose any multi-layered objects. Currently it's easy to compile a big object from multiple smaller objects. If you add a complex object to your workflow Taverna will add all the individual parts and create the links between them. But decomposing the big object is something else. The info about the object's relationships are stored in the ontology, so theoretically it should be possible to generate proccessors to decompose the big ones, but I guess that is more like a feature request then a bug :). Currently I create custom services to decompose big objects again as a workaround, but some automated object decomposition in taverna would be really cool... Cheers, Pieter > Do you know of these problems and if so - are there any plans for > fixing it? > > Cheers, > Rebecca > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Wed Nov 2 16:12:56 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 08:12:56 -0800 Subject: [moby] [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> Message-ID: <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> I think you're right - that's a much better data structure to be passing around. This does change the external (perl client) API, right? :-/ Really, what the Perl client code needs is a good laundering. The CommonSubs.pm module is a total mess after being modified piecemeal over the past 3 years... I wonder if we shouldn't just start a new module (or modules) that are named by their domain of function (RegistryIO, OntologyIO, or something like that) and have all fresh code? Gradually we could migrate all functionality into these modules. Client::Central has been around since the 0.1 prototype of MOBY in 2001 and has never been re-written top-to- bottom! I'm still waiting to hear about the re-funding attempts for MOBY... fingers crossed! There will hopefully be a second opportunity later in the winter, so all is not lost if we fail. It would be great to have a couple of extra hands dedicated to a complete code re-write. M On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: > Hi all, > > Here is a question for those using the Perl API. In > > MOBY/Client/Central.pm > > we have a > > sub retrieveObjectDefinition > > which calls > > sub _ObjectDefinitionPayload { > > This produces an array for the objects, articleNames and lsids for > the relationships of the object whose definition is requested. I'm > wondering why this is an array. Currently I have to rely on the order > of elements in this array to figure out which element is the object, > which one is articleName, etc. These are the lines producing the array: > > 553 push @{ $relationships{$relationshipType} }, > 554 [ $_->toString, $article, $rlsid ]; > > Is there any reason why this should be an array? I'd rather not have > to rely on the order of the elements, so are there people who have > any objections when I change this into a hash like in: > > push @{ $relationships{$relationshipType} }, > { object => $_->toString, > articleName => $article, > lsid => $rlsid }; > > Cheers, > > Pieter > > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Wed Nov 2 15:47:45 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 2 Nov 2005 07:47:45 -0800 Subject: [MOBY-dev] RE: parseMobyData In-Reply-To: <4368B1EF.9060004@gsf.de> Message-ID: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Hi Rebecca, I was unaware of those issues, mainly because I didn't touch that widget and I left it as is for compatibility reasons. Also, I think that I could add support for parsing collections. Given a collection, return a list of whatever that widget returns. Moreover, you and Pieter have been talking about retrieving the string (and most likely integers, floats, etc) from the objects. Pieter went as far to say that he creates processors to do that for him. Do you think that it would be worthwhile to add another port to processors that contain the 'primitives' so that you can retrieve them? For example, imagine that you are using a processor blastDB that performs a blast search on some database and returns the blast results in xml. In Moby, this would be a data type called text-xml (I think). Would it be useful to also have an output port that contains only the xml text in it? Let me know what you think. Most likely, you have a better idea. Tell it to me and I will see what I can do. Eddie > -----Original Message----- > From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] > Sent: Wednesday, November 02, 2005 4:33 AM > To: Edward Kawas > Cc: mobydev > Subject: parseMobyData > > Hi Eddie! > > I had another look into Taverna to see if our workflows > now run > correctly but found two problems of parseMobyData. > The first problem is that parseMobyData can't deal with > collections (it > never could) the second is that it also can't deal with > the new object > stucture (e.g. a string object containing a string now) as > it only > checks the first layer content and never goes into the > additional string. > Do you know of these problems and if so - are there any > plans for fixing it? > > Cheers, > Rebecca From markw at illuminae.com Wed Nov 2 17:50:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 09:50:04 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > Also, I think that I could add support for parsing > collections. Given a collection, return a list of whatever > that widget returns. Wow... I didn't realize that this functionality wasn't already in there somewhere. Or am I misunderstanding? Can't Taverna take a collection and pass the individual members one at a time to a downstream service that consumes simples? I guess I've never built a workflow that needs this. It's an interesting "book-keeping" problem for Taverna in that it would have to generate unique queryID's for each of the Simples it passed, since these would not have been provided by the previous service provider... > Moreover, you and Pieter have been talking about retrieving > the string (and most likely integers, floats, etc) from the > objects. Pieter went as far to say that he creates > processors to do that for him. Do you think that it would be > worthwhile to add another port to processors that contain > the 'primitives' so that you can retrieve them? YES! YES! YES! This is critical for interacting with anything other than a MOBY service... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 17:50:04 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 09:50:04 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > Also, I think that I could add support for parsing > collections. Given a collection, return a list of whatever > that widget returns. Wow... I didn't realize that this functionality wasn't already in there somewhere. Or am I misunderstanding? Can't Taverna take a collection and pass the individual members one at a time to a downstream service that consumes simples? I guess I've never built a workflow that needs this. It's an interesting "book-keeping" problem for Taverna in that it would have to generate unique queryID's for each of the Simples it passed, since these would not have been provided by the previous service provider... > Moreover, you and Pieter have been talking about retrieving > the string (and most likely integers, floats, etc) from the > objects. Pieter went as far to say that he creates > processors to do that for him. Do you think that it would be > worthwhile to add another port to processors that contain > the 'primitives' so that you can retrieve them? YES! YES! YES! This is critical for interacting with anything other than a MOBY service... M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 18:44:40 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 10:44:40 -0800 Subject: [MOBY-dev] RFC Voting - message to all core developers In-Reply-To: <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> <5.2.1.1.2.20051027094352.010ce620@email.med.harvard.edu> Message-ID: <1130957080.27282.40.camel@bioinfo.icapture.ubc.ca> So, this just isn't working at all :-/ A couple of frustrating things have happened v.v. RFC 1863: First: a vote was called, and there were some post-call suggestions which resulted in a revision of the document. The vote was subsequently called off. Second: there were some late suggestions from Paul and Martin (Oct 17/18) that were not discussed further by the interested parties (in particular, the group that put forward the RFC in the first place). An indication that the suggested changes are accepted/rejected by the proponents would be a good idea before a vote is called. Third: In the absence of changes to the document, the call for a re-vote was made, but was ignored by all but one of the RFC panel members (including my own local team, so I am just as guilty... but thanks Frank for being conscientious!). Whether it be by bugzilla or by email, it really doesn't matter to me which method people use - since this isn't a high-traffic event I can make notes on a piece of paper to tally the votes - but we need to actually DO it. I don't mean for this to be an accusatory message in any way. I only mean to point out that the RFC process for MOBY isn't working as we are currently implementing it, so we should perhaps come up with a better mechanism that accomplishes what we need to accomplish. There are a LOT of great suggestions currently sitting in Bugzilla that we will need to start addressing quickly. Do we need to set up a more dedicated mailing list or forum for RFC events so that they don't get lost in the general traffic of the -dev mailing list? (which is no longer a "low traffic" list, as it is described in the mailing list documentation ;-) ). Would a once-monthly teleconference solve the problem? What mechanism would the RFC panel find most intuitive and useful? Bugzilla is already in place, but if people are finding it too arcane, I can find a pre-canned or script-up an alternative solution... either way we need to quickly find something that does work, because I'm sure that David and his team in Spain are going nuts by now (especially since it is obvious that their RFC is, in principle, going to pass - we're only negotiating the details now :-) ) M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From tmo at ebi.ac.uk Wed Nov 2 17:58:07 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 02 Nov 2005 17:58:07 +0000 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> Message-ID: <4368FE2F.4070901@ebi.ac.uk> Mark Wilkinson wrote: > On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > > >>Also, I think that I could add support for parsing >>collections. Given a collection, return a list of whatever >>that widget returns. > > > Wow... I didn't realize that this functionality wasn't already in there > somewhere. Or am I misunderstanding? Can't Taverna take a collection > and pass the individual members one at a time to a downstream service > that consumes simples? I guess I've never built a workflow that needs > this. It's an interesting "book-keeping" problem for Taverna in that it > would have to generate unique queryID's for each of the Simples it > passed, since these would not have been provided by the previous service > provider... It _did_ work like that in our original version, yes. We broke all moby collections into Taverna collections of moby simples, using Taverna's type reconciliation layer to reconstitute these into moby collections if required or to iterate over services consuming moby simples. A while ago we agreed that this behaviour should be retained so if it doesn't do that now it's a bug. Tom From tmo at ebi.ac.uk Wed Nov 2 17:58:07 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Wed, 02 Nov 2005 17:58:07 +0000 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> <1130953804.27282.7.camel@bioinfo.icapture.ubc.ca> Message-ID: <4368FE2F.4070901@ebi.ac.uk> Mark Wilkinson wrote: > On Wed, 2005-11-02 at 07:47 -0800, Edward Kawas wrote: > > >>Also, I think that I could add support for parsing >>collections. Given a collection, return a list of whatever >>that widget returns. > > > Wow... I didn't realize that this functionality wasn't already in there > somewhere. Or am I misunderstanding? Can't Taverna take a collection > and pass the individual members one at a time to a downstream service > that consumes simples? I guess I've never built a workflow that needs > this. It's an interesting "book-keeping" problem for Taverna in that it > would have to generate unique queryID's for each of the Simples it > passed, since these would not have been provided by the previous service > provider... It _did_ work like that in our original version, yes. We broke all moby collections into Taverna collections of moby simples, using Taverna's type reconciliation layer to reconstitute these into moby collections if required or to iterate over services consuming moby simples. A while ago we agreed that this behaviour should be retained so if it doesn't do that now it's a bug. Tom From markw at illuminae.com Wed Nov 2 22:03:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 14:03:29 -0800 Subject: [MOBY-dev] A consequence of the new Object inheritence rules... Message-ID: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Hi all, I keep forgetting to mention, but it needs to be said so that people know about it until we have time to code it into the API: The way I see it, one of the consequences of not inheriting from Primitives is that MOBY now has its first "reserved word". The primary content of a given object (i.e. the content that would have been the CDATA, string, or integer content of the node in old-style objects) has now been stuck into a primitive data-type, however there is nothing preventing an object from having two HASA's, one containing the actual content, and the other containing a primitive. For example: AnnotatedFASTA hasa String (content) <--- this is the FASTA hasa String (Description) Back when we were allowing inheritance from primitives, it was obvious where the content was, but it isn't anymore, so we need a reserved word as the articleName of the contained primitive :-/ An alternative route would be to disallow use of primitives for anything *other* than containing 'content'. That would require another extensive re-working of the Object ontology, but we would end up with something like this: AnnotatedFASTA hasa String (content) hasa Description (anotation) hasa String (content) The latter seems more "correct", but it would require us to re-write the ontology again... Comments? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 22:40:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 14:40:34 -0800 Subject: [moby] [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> References: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: <1130971234.27282.83.camel@bioinfo.icapture.ubc.ca> Just a clarification - by saying that the solution below seems more "correct" I was not suggesting that I *support* this solution. This solution leads to a massive proliferation of task-specific objects; every use of String now becomes a first-class MOBY Object, rather than simply a "performs role" relationship as we had with articleName. A pox on the Java-guys who don't like inheritance... ;-) M On Wed, 2005-11-02 at 14:03 -0800, Mark Wilkinson wrote: > An alternative route > would be to disallow use of primitives for anything *other* than > containing 'content'. That would require another extensive re-working > of the Object ontology, but we would end up with something like this: > > AnnotatedFASTA > hasa String (content) > hasa Description (anotation) > hasa String (content) > > The latter seems more "correct", but it would require us to re-write the > ontology again... -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 2 22:40:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 14:40:34 -0800 Subject: [moby] [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> References: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: <1130971234.27282.83.camel@bioinfo.icapture.ubc.ca> Just a clarification - by saying that the solution below seems more "correct" I was not suggesting that I *support* this solution. This solution leads to a massive proliferation of task-specific objects; every use of String now becomes a first-class MOBY Object, rather than simply a "performs role" relationship as we had with articleName. A pox on the Java-guys who don't like inheritance... ;-) M On Wed, 2005-11-02 at 14:03 -0800, Mark Wilkinson wrote: > An alternative route > would be to disallow use of primitives for anything *other* than > containing 'content'. That would require another extensive re-working > of the Object ontology, but we would end up with something like this: > > AnnotatedFASTA > hasa String (content) > hasa Description (anotation) > hasa String (content) > > The latter seems more "correct", but it would require us to re-write the > ontology again... -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Wed Nov 2 23:52:38 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 2 Nov 2005 23:52:38 +0000 (GMT) Subject: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, What the hell are you talking about? :-) It's morning here so I may not be fully awoke... > The way I see it, one of the consequences of not inheriting from > Primitives is that MOBY now has its first "reserved word". > The reserverd words we have are the names of primitive types (String, Integer, Float, DateTime, Boolean, Object), we do not need any reserved word for an article name. You created the name 'content' just because you changed the old ontology to the new one by a script - which is fine (as long as nobody in that time was using the name 'content' for any HAS[A] members - probably was not, or possibly your script could have be clever and check this). But now, it really does not matter how to name it, does it? > The primary content of a given object > There is nothing like "the primary content". And if yes, today is the first time I hear it. I hope we do not need such concept. No, unless you explain it further I do not see any need for having a primary content, and that's why we do not need any reserved word for it. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Wed Nov 2 23:52:38 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 2 Nov 2005 23:52:38 +0000 (GMT) Subject: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: <1130969009.27282.75.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, What the hell are you talking about? :-) It's morning here so I may not be fully awoke... > The way I see it, one of the consequences of not inheriting from > Primitives is that MOBY now has its first "reserved word". > The reserverd words we have are the names of primitive types (String, Integer, Float, DateTime, Boolean, Object), we do not need any reserved word for an article name. You created the name 'content' just because you changed the old ontology to the new one by a script - which is fine (as long as nobody in that time was using the name 'content' for any HAS[A] members - probably was not, or possibly your script could have be clever and check this). But now, it really does not matter how to name it, does it? > The primary content of a given object > There is nothing like "the primary content". And if yes, today is the first time I hear it. I hope we do not need such concept. No, unless you explain it further I do not see any need for having a primary content, and that's why we do not need any reserved word for it. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 3 00:08:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 00:08:49 +0000 (GMT) Subject: [MOBY-dev] RFC Voting - message to all core developers In-Reply-To: <1130957080.27282.40.camel@bioinfo.icapture.ubc.ca> Message-ID: You are right that the voting process was not so smooth as it could have been - but do not be too desperate - it was not that bad. I think it is still better than it was before. I agree with you that the main problems were: * Not always clear where the latest document can be found (that's, for example, why I could not vote the last time). * Not sure where to vote (email or bugzilla). * Not fast enough replies from the voters about suggested changes. I still think that we should conclude this error handling voting now, and try again for other issues: - not in bugzilla, - discussion and document udates driven by the proponents, - keeping deadlines of voting Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Wed Nov 2 23:57:02 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 15:57:02 -0800 Subject: [unclassified] Re: [MOBY-dev] A consequence of the new Object inheritence rules... In-Reply-To: References: Message-ID: <1130975822.27282.90.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-02 at 23:52 +0000, Martin Senger wrote: > Mark, > What the hell are you talking about? :-) > It's morning here so I may not be fully awoke... I'll let you wake up a little more and think about it again before I try to explain it in more detail... it's a tricky one, and I'm multi-tasking right now... :-) M From markw at illuminae.com Thu Nov 3 01:51:11 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 17:51:11 -0800 Subject: [MOBY-dev] Reserved word... perhaps unnecessary... Message-ID: <43696D0F.7010605@illuminae.com> Hi Martin, I love using you as the bellweather for my own thoughts :-) You are seldom wrong, and delight in telling me when I am! ;-) I think I am starting to see your point - I had not been thinking of the object ontology in quite that way, but you've got me reconsidering now. I'm going to bring it up for discussion at my lab meeting tomorrow and try to hash-out with the local guys exactly why I feel the way I do, and whether or not there are any serious adverse effects to thinking about it your way. It certainly makes things easier to do it your way, though I wish now that we had had this discussion while Eddie was writing the database update script because I would have changed the way we approached it... Oh well... I guess that's why MOBY is still considered a research project ;-) Thanks for being so forthright in your opinons - you are an extremely valuable asset to the project! M From markw at illuminae.com Thu Nov 3 02:15:44 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:15:44 -0800 Subject: [MOBY-dev] New website is ready... Message-ID: <436972D0.8020606@illuminae.com> Hi all, I think I'm just about finished moving stuff over to the new website. Please browse it and get back to me or Simon with comments. http://biomoby.open-bio.org M From senger at ebi.ac.uk Thu Nov 3 02:28:48 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 02:28:48 +0000 (GMT) Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> Message-ID: > http://biomoby.open-bio.org > I asked to have there a link to jMoby pages. I cannot find it. Could it be inserted there please? The old link was/is http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move the jMoby pages somewhere else, or you just use to link to that old hyperlink. Thanks, Martin PS. The jMoby pages still use the old stylesheet, but that will be rectified in due time. No time for that now, I am afraid. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Nov 3 02:54:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:54:43 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43697BF3.7040209@illuminae.com> Sorry about that! It's now a link in the deveopers page M Martin Senger wrote: >>http://biomoby.open-bio.org >> >> >> > I asked to have there a link to jMoby pages. I cannot find it. Could it >be inserted there please? The old link was/is >http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move >the jMoby pages somewhere else, or you just use to link to that old >hyperlink. > > Thanks, > Martin > >PS. The jMoby pages still use the old stylesheet, but that will be >rectified in due time. No time for that now, I am afraid. M. > > > From markw at illuminae.com Thu Nov 3 02:56:31 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:56:31 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43697C5F.3020402@illuminae.com> I still don't have the cvs update on a cron... Does anyone know offhand if a cvs update preserves the permissions that I have set on the server, or does it over-write them with the permissions in the CVS repository? M Martin Senger wrote: >>http://biomoby.open-bio.org >> >> >> > I asked to have there a link to jMoby pages. I cannot find it. Could it >be inserted there please? The old link was/is >http://biomoby.org/moby-live/Java/docs/ - I do not know if I should move >the jMoby pages somewhere else, or you just use to link to that old >hyperlink. > > Thanks, > Martin > >PS. The jMoby pages still use the old stylesheet, but that will be >rectified in due time. No time for that now, I am afraid. M. > > > From markw at illuminae.com Thu Nov 3 02:58:39 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 18:58:39 -0800 Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? Message-ID: <43697CDF.5000408@illuminae.com> Under "Clients" on the new homepage is a list of all of the clients and applications that use MOBY that I know about. If I have missed anyone, please say so and I'll add it. M From senger at ebi.ac.uk Thu Nov 3 03:02:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 03:02:41 +0000 (GMT) Subject: [MOBY-dev] New website is ready... In-Reply-To: <43697C5F.3020402@illuminae.com> Message-ID: > I still don't have the cvs update on a cron... > This is what jMoby has for updating its documentation from CVS: #!/bin/bash # PATH=$PATH:/usr/java/j2sdk1.4.2_02/bin export PATH cd /home/websites/biomoby.org/html/moby-live/Java cvs -d :pserver:cvs:cvs at cvs.open-bio.org:/home/repository/moby -q update -dP ./build.sh docs > Does anyone know offhand if a cvs update preserves the permissions that > I have set on the server, or does it over-write them with the > permissions in the CVS repository? > My experiences are: It preserves them - but once they are in the cvs server you cannot change them. So if you commit a script script.pl without executing permissions, it will be always given to the local copies without this flag (unless you change it on the server side I guess). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 3 03:05:44 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 03:05:44 +0000 (GMT) Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <43697CDF.5000408@illuminae.com> Message-ID: > Under "Clients" on the new homepage is a list of all of the clients and > applications that use MOBY that I know about. If I have missed anyone, > please say so and I'll add it. > client title: "command-line clients" source: jMoby platform: Java link: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/CmdLineClients.html Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Nov 3 03:13:56 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 19:13:56 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: References: Message-ID: <43698074.8060708@illuminae.com> > This is what jMoby has for updating its documentation from CVS: > >#!/bin/bash ># >PATH=$PATH:/usr/java/j2sdk1.4.2_02/bin >export PATH >cd /home/websites/biomoby.org/html/moby-live/Java >cvs -d :pserver:cvs:cvs at cvs.open-bio.org:/home/repository/moby -q update -dP >./build.sh docs > > > Is that a script that I can call from the cron? > My experiences are: It preserves them - but once they are in the cvs >server you cannot change them. So if you commit a script script.pl without >executing permissions, it will be always given to the local copies >without this flag (unless you change it on the server side I guess). > > I know that it preserves them over CVS commits (i.e. if I commit without execute permission, and then commit with execute permission, it will still not have it), but I am unsure about whether something that was committed with execute permission will change the permissions of something that I set as non-executable locally and then cvs update over top of it. M > > From senger at ebi.ac.uk Thu Nov 3 03:17:18 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 03:17:18 +0000 (GMT) Subject: [MOBY-dev] New website is ready... In-Reply-To: <43698074.8060708@illuminae.com> Message-ID: > Is that a script that I can call from the cron? > Yes. I am calling it as a cronjob on machine portal.open-bio.org. My crontab item for this script is the following: # update jMoby from CVS and update its documentation # every 3 hours, every day 28 0,3,6,9,12,15,18,21 * * * $HOME/scripts/update-jmoby-docs.sh > /dev/null Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Nov 3 03:30:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 02 Nov 2005 19:30:35 -0800 Subject: [MOBY-dev] jMOBY documentation Message-ID: <4369845B.6000301@illuminae.com> 1) it is now accessible through the new website under "MOBY For Developers" 2) I just read it for the first time... WOW! Martin, you did a really great job on that documentation! Kudo's to you! From bmg at sfu.ca Thu Nov 3 03:59:34 2005 From: bmg at sfu.ca (Benjamin Good) Date: Wed, 2 Nov 2005 19:59:34 -0800 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <3DD0C1BE-C048-4F8D-B104-9391280F6DF0@sfu.ca> I don't see a link to register for the mailing list anywhere? Martin's graphs, Net Nanny on tools and toys? Should there be a contact link on the first page somewhere? Cool possible additions: A listing of project websites that employ moby services. Links to principle developers home pages if they exist. Dynamically updated statistics on services, moby central hits etc. Net Nanny for services! 2c -ben On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From Pieter.Neerincx at wur.nl Thu Nov 3 11:17:28 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 3 Nov 2005 12:17:28 +0100 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> On 03Nov2005, at 03:15, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. Hi Mark and Simon, Nice job! Looks like I found some small permission bugs though: Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Docs/MOBY- S_API/index_API.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Java/docs/ taverna/guide/index.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Forbidden You don't have permission to access /CVS_CONTENT/moby-live/Java/docs/ API/index.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Apache/2.0.52 (CentOS) Server at biomoby.open-bio.org Port 80 Furthermore I added a page to the Docs in the CVS some time ago, but I can not find it anywhere on the new website... I'd love to be able to contribute to the new site, so I also registered for a WordPress account, but so far I haven't been able to do anything useful with it. Sure I can login (and logout), but that's it :(. Cheers, Pieter > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Thu Nov 3 11:56:08 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 3 Nov 2005 12:56:08 +0100 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <0C0A3DE6-E48B-48AA-A62B-163E1DFCFD65@wur.nl> On 27Oct2005, at 24:18, Edward Kawas wrote: > Hi, > > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 I'm in favor of RFC 1863. So I vote yes again. I think it's crucial for the speed of BioMOBY evolution to have have at least some error reporting in place. In the current situation where empty objects are returned if something goes wrong, a user is completely in the dark. Debugging such cases is extremely painful. Currently most users are developers as well so we can look in the log files of the machines where our services are running, but if we want BioMOBY to become more popular with 'normal' users we need some error reporting that makes sense a.s.a.p. I found two small inconsistencies though: Page 4 mentions refqueryID, refQuery and refQueryID attributes. Do I get it right that these are typo's and all the same atribute...? Furtermore I think this: "refElement - refers to the articleName of the offending input Simple or Collection" will be a problem. If it's referring to the articleName it should be called refArticleName. The problem is that articleNames are optional. There is no guarantee they will be present. Furthermore they not need to be unique. In case there are multiple elements of the same type, the articleName attribute can be used to differentiate between them. Hence the combination of element and articleName can be used by a service to find a specific element. If you want to link an execption to a specific element of the input you will need both a refElement and a refArticleName... So instead of: 600 Unable to execute the service I propose something like this: 600 Unable to execute the service Just my 2c, Pieter > > Thanks. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From rebecca.ernst at gsf.de Thu Nov 3 14:58:32 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 03 Nov 2005 15:58:32 +0100 Subject: [MOBY-dev] Re: parseMobyData In-Reply-To: <000901c5dfc4$c6de2b00$6600a8c0@notebook> References: <000901c5dfc4$c6de2b00$6600a8c0@notebook> Message-ID: <436A2598.4050307@gsf.de> Hi Eddie, Mark, Pieter, Tom and others! The problem No.1 (Collections in parsemobydata) is solved resp. it didn't exist. As for every other service or scavenger Taverna decomposes the object into simples! (this is true for Taverna versions up to 1.1 and for 1.3. Not for the 1.2 release though but here Eddie has a bugfix via CVS) The reason we believed it is a collection problem is that parsing of one service output failed which gives back collections. Now we digged into it and found that Taverna doesn't have a problem with the object being a collection: the problem was that the service is registered as giving back simples but gives back collections. In contrast to gbrowse Taverna obviously only decomposes collections when it expects them to be there. We had a look at the second problem (primitives in moby-objects) and think that your suggestion with further ports giving access to the primitives would solve the problem. If we got it right this would replace the 'parseMobyData' scavenger completely - is that right? Cheers, Rebecca and Dirk Edward Kawas wrote: >Hi Rebecca, > >I was unaware of those issues, mainly because I didn't touch >that widget and I left it as is for compatibility reasons. > >Also, I think that I could add support for parsing >collections. Given a collection, return a list of whatever >that widget returns. > >Moreover, you and Pieter have been talking about retrieving >the string (and most likely integers, floats, etc) from the >objects. Pieter went as far to say that he creates >processors to do that for him. Do you think that it would be >worthwhile to add another port to processors that contain >the 'primitives' so that you can retrieve them? > >For example, imagine that you are using a processor blastDB >that performs a blast search on some database and returns >the blast results in xml. In Moby, this would be a data type >called text-xml (I think). Would it be useful to also have >an output port that contains only the xml text in it? > >Let me know what you think. Most likely, you have a better >idea. Tell it to me and I will see what I can do. > >Eddie > > > >>-----Original Message----- >>From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] >>Sent: Wednesday, November 02, 2005 4:33 AM >>To: Edward Kawas >>Cc: mobydev >>Subject: parseMobyData >> >>Hi Eddie! >> >>I had another look into Taverna to see if our workflows >>now run >>correctly but found two problems of parseMobyData. >>The first problem is that parseMobyData can't deal with >>collections (it >>never could) the second is that it also can't deal with >>the new object >>stucture (e.g. a string object containing a string now) as >>it only >>checks the first layer content and never goes into the >>additional string. >>Do you know of these problems and if so - are there any >>plans for fixing it? >> >>Cheers, >>Rebecca >> >> > > > > > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From francis_gibbons at hms.harvard.edu Thu Nov 3 15:00:39 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 03 Nov 2005 10:00:39 -0500 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> Message-ID: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> Mark, Under "For developers", the link to the "latest Perl API" docs doesn't work, because: You don't have permission to access /CVS_CONTENT/moby-live/Docs/MOBY-S_API/index_API.html on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. Also, it struck me that the links to the tutorials are not the same as what's in CVS. I felt like it was important to have all documentation under CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other documentation is in the parent directory (omit the "Perl" above). -Frank At 09:15 PM 11/2/2005, you wrote: >Hi all, > >I think I'm just about finished moving stuff over to the new website. >Please browse it and get back to me or Simon with comments. > >http://biomoby.open-bio.org > >M > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Nov 3 15:23:47 2005 From: markw at illuminae.com (mark wilkinson) Date: Thu, 3 Nov 2005 15:23:47 +0000 GMT Subject: [MOBY-dev] New website is ready... Message-ID: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> Look under "clients" - many websites are there. Look under "about moby" - mailing list info is there. M -----Original Message----- From: Benjamin Good Date: Wed, 2 Nov 2005 19:59:34 To:Core developer announcements Subject: Re: [MOBY-dev] New website is ready... I don't see a link to register for the mailing list anywhere? Martin's graphs, Net Nanny on tools and toys? Should there be a contact link on the first page somewhere? Cool possible additions: A listing of project websites that employ moby services. Links to principle developers home pages if they exist. Dynamically updated statistics on services, moby central hits etc. Net Nanny for services! 2c -ben On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new > website. Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Thu Nov 3 15:00:30 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 3 Nov 2005 07:00:30 -0800 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <0C0A3DE6-E48B-48AA-A62B-163E1DFCFD65@wur.nl> Message-ID: <000101c5e087$56402ba0$6600a8c0@notebook> I vote in favor. Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > Neerincx > Sent: Thursday, November 03, 2005 3:56 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] vote on the RFC discussing Error > Reporting > > On 27Oct2005, at 24:18, Edward Kawas wrote: > > > Hi, > > > > I am calling a vote on the RFC that discusses error > > reporting. > > > > Please refer to the following link: > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > I'm in favor of RFC 1863. So I vote yes again. I think > it's crucial > for the speed of BioMOBY evolution to have have at least > some error > reporting in place. In the current situation where empty > objects are > returned if something goes wrong, a user is completely in > the dark. > Debugging such cases is extremely painful. Currently most > users are > developers as well so we can look in the log files of the > machines > where our services are running, but if we want BioMOBY to > become more > popular with 'normal' users we need some error reporting > that makes > sense a.s.a.p. > > I found two small inconsistencies though: > > Page 4 mentions refqueryID, refQuery and refQueryID > attributes. Do I > get it right that these are typo's and all the same > atribute...? > > Furtermore I think this: > > "refElement - refers to the articleName of the offending > input > Simple or Collection" > > will be a problem. If it's referring to the articleName it > should be > called refArticleName. The problem is that articleNames > are optional. > There is no guarantee they will be present. Furthermore > they not need > to be unique. In case there are multiple elements of the > same type, > the articleName attribute can be used to differentiate > between them. > Hence the combination of element and articleName can be > used by a > service to find a specific element. If you want to link an > execption > to a specific element of the input you will need both a > refElement > and a refArticleName... > > So instead of: > > refQueryID="1" > severity ="error"> > 600 > Unable to execute the > service > > > I propose something like this: > > refArticleName="input1" > refQueryID="1" > severity ="error"> > 600 > Unable to execute the > service > > > Just my 2c, > > Pieter > > > > > > Thanks. > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1038 > Dreijenlaan 3 > 6703 HA Wageningen > phone: 0317-484 706 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Thu Nov 3 16:10:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:10:29 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> References: <479048576-1131031440-cardhu_blackberry.rim.net-20186-@engine20-cell01> Message-ID: <1131034229.31833.16.camel@bioinfo.icapture.ubc.ca> Martin, what is the URL for the NetNanny project? M On Thu, 2005-11-03 at 15:23 +0000, mark wilkinson wrote: > Look under "clients" - many websites are there. > > Look under "about moby" - mailing list info is there. > > M > > > -----Original Message----- > From: Benjamin Good > Date: Wed, 2 Nov 2005 19:59:34 > To:Core developer announcements > Subject: Re: [MOBY-dev] New website is ready... > > I don't see a link to register for the mailing list anywhere? > > Martin's graphs, Net Nanny on tools and toys? > > Should there be a contact link on the first page somewhere? > > Cool possible additions: > A listing of project websites that employ moby services. > Links to principle developers home pages if they exist. > Dynamically updated statistics on services, moby central hits etc. > Net Nanny for services! > > 2c > > -ben > > > > On Nov 2, 2005, at 6:15 PM, Mark Wilkinson wrote: > > > Hi all, > > > > I think I'm just about finished moving stuff over to the new > > website. Please browse it and get back to me or Simon with comments. > > > > http://biomoby.open-bio.org > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- > Mark Wilkinson > ...on the road! > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 16:11:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:11:30 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> Message-ID: <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > Also, it struck me that the links to the tutorials are not the same as > what's in CVS. I felt like it was important to have all documentation under > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > documentation is in the parent directory (omit the "Perl" above). Right, the link in the tutorials is actually cyclic (it eventually leads back to itself), but I forgot to update it last night. I'll do that right away. M From markw at illuminae.com Thu Nov 3 16:11:49 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:11:49 -0800 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <000101c5e087$56402ba0$6600a8c0@notebook> References: <000101c5e087$56402ba0$6600a8c0@notebook> Message-ID: <1131034309.31833.20.camel@bioinfo.icapture.ubc.ca> I vote in favor also. On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > I vote in favor. > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > > dev-bounces at portal.open-bio.org] On Behalf Of Pieter > > Neerincx > > Sent: Thursday, November 03, 2005 3:56 AM > > To: Core developer announcements > > Subject: Re: [MOBY-dev] vote on the RFC discussing Error > > Reporting > > > > On 27Oct2005, at 24:18, Edward Kawas wrote: > > > > > Hi, > > > > > > I am calling a vote on the RFC that discusses error > > > reporting. > > > > > > Please refer to the following link: > > > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > > > I'm in favor of RFC 1863. So I vote yes again. I think > > it's crucial > > for the speed of BioMOBY evolution to have have at least > > some error > > reporting in place. In the current situation where empty > > objects are > > returned if something goes wrong, a user is completely in > > the dark. > > Debugging such cases is extremely painful. Currently most > > users are > > developers as well so we can look in the log files of the > > machines > > where our services are running, but if we want BioMOBY to > > become more > > popular with 'normal' users we need some error reporting > > that makes > > sense a.s.a.p. > > > > I found two small inconsistencies though: > > > > Page 4 mentions refqueryID, refQuery and refQueryID > > attributes. Do I > > get it right that these are typo's and all the same > > atribute...? > > > > Furtermore I think this: > > > > "refElement - refers to the articleName of the offending > > input > > Simple or Collection" > > > > will be a problem. If it's referring to the articleName it > > should be > > called refArticleName. The problem is that articleNames > > are optional. > > There is no guarantee they will be present. Furthermore > > they not need > > to be unique. In case there are multiple elements of the > > same type, > > the articleName attribute can be used to differentiate > > between them. > > Hence the combination of element and articleName can be > > used by a > > service to find a specific element. If you want to link an > > execption > > to a specific element of the input you will need both a > > refElement > > and a refArticleName... > > > > So instead of: > > > > > refQueryID="1" > > severity ="error"> > > 600 > > Unable to execute the > > service > > > > > > I propose something like this: > > > > > refArticleName="input1" > > refQueryID="1" > > severity ="error"> > > 600 > > Unable to execute the > > service > > > > > > Just my 2c, > > > > Pieter > > > > > > > > > > Thanks. > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1038 > > Dreijenlaan 3 > > 6703 HA Wageningen > > phone: 0317-484 706 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Thu Nov 3 16:15:29 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 16:15:29 +0000 (GMT) Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034229.31833.16.camel@bioinfo.icapture.ubc.ca> Message-ID: > Martin, what is the URL for the NetNanny project? > Does not ring any bells. Unless you mean BioNanny - that is http://www.bionanny.org. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 3 16:16:52 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 3 Nov 2005 16:16:52 +0000 (GMT) Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <1131034309.31833.20.camel@bioinfo.icapture.ubc.ca> Message-ID: Could anybody sent me the latest document we are voting on? (But do not sent me a link to bugzilla please). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Nov 3 16:18:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:18:26 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> Message-ID: <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 12:17 +0100, Pieter Neerincx wrote: > Forbidden All these that I can find are now fixed. I was paranoid last night and switched off execute permissions on all folders in the CVS except for the ones that I knew contained documentation because it makes me nervous having end-user-writable executable folders on our website! > Furthermore I added a page to the Docs in the CVS some time ago, but > I can not find it anywhere on the new website... where? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 16:23:00 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:23:00 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> Oh, I see what you mean. You have already ported the TWiki documentation over to the CVS. Super! I'll remove the ones that I moved last night then. M On Thu, 2005-11-03 at 08:11 -0800, Mark Wilkinson wrote: > On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > > > Also, it struck me that the links to the tutorials are not the same as > > what's in CVS. I felt like it was important to have all documentation under > > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > > documentation is in the parent directory (omit the "Perl" above). > > Right, the link in the tutorials is actually cyclic (it eventually leads > back to itself), but I forgot to update it last night. I'll do that > right away. > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Thu Nov 3 16:38:10 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 03 Nov 2005 17:38:10 +0100 Subject: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <43697CDF.5000408@illuminae.com> References: <43697CDF.5000408@illuminae.com> Message-ID: <436A3CF2.3070905@gsf.de> Hi Mark! here are two more clients. maybe you want to include them in the page (but in another table like 'specific clients' as they are not very generic) http://urgi.infobiogen.fr/BioFloWeb/ http://mips.gsf.de/cgi-bin/proj/planet/moby/AtiDBClient.cgi Cheers, Rebecca Mark Wilkinson wrote: > Under "Clients" on the new homepage is a list of all of the clients > and applications that use MOBY that I know about. If I have missed > anyone, please say so and I'll add it. > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Nov 3 16:39:58 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:39:58 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051103095748.01114d38@email.med.harvard.edu> <1131034290.31833.18.camel@bioinfo.icapture.ubc.ca> <1131034980.31833.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131035998.31833.29.camel@bioinfo.icapture.ubc.ca> Done! Thanks again Frank - that was a fantastic effort and it looks great!! M On Thu, 2005-11-03 at 08:23 -0800, Mark Wilkinson wrote: > Oh, I see what you mean. You have already ported the TWiki > documentation over to the CVS. Super! I'll remove the ones that I > moved last night then. > > M > > > On Thu, 2005-11-03 at 08:11 -0800, Mark Wilkinson wrote: > > On Thu, 2005-11-03 at 10:00 -0500, Frank Gibbons wrote: > > > > > Also, it struck me that the links to the tutorials are not the same as > > > what's in CVS. I felt like it was important to have all documentation under > > > CVS control, so I put them in cvs/moby-live/Docs/MOBY-S_API/Perl. The other > > > documentation is in the parent directory (omit the "Perl" above). > > > > Right, the link in the tutorials is actually cyclic (it eventually leads > > back to itself), but I forgot to update it last night. I'll do that > > right away. > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From rebecca.ernst at gsf.de Thu Nov 3 16:31:35 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Thu, 03 Nov 2005 17:31:35 +0100 Subject: [MOBY-dev] New website is ready... In-Reply-To: <436972D0.8020606@illuminae.com> References: <436972D0.8020606@illuminae.com> Message-ID: <436A3B67.5070302@gsf.de> Hi Mark! I had a look on the website and wanted to test the LSID resolver.. (http://mobycentral.icapture.ubc.ca/cgi-bin/LSID_Resolver.pl) I only get internal server errors when trying it with one of the examples you give on that page... Cheers, Rebecca Mark Wilkinson wrote: > Hi all, > > I think I'm just about finished moving stuff over to the new website. > Please browse it and get back to me or Simon with comments. > > http://biomoby.open-bio.org > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Nov 3 16:46:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:46:34 -0800 Subject: [moby] Re: [MOBY-dev] Anyone have a moby client or application that I havent included? In-Reply-To: <436A3CF2.3070905@gsf.de> References: <43697CDF.5000408@illuminae.com> <436A3CF2.3070905@gsf.de> Message-ID: <1131036394.31833.31.camel@bioinfo.icapture.ubc.ca> Done On Thu, 2005-11-03 at 17:38 +0100, Rebecca Ernst wrote: > Hi Mark! > > here are two more clients. maybe you want to include them in the page > (but in another table like 'specific clients' as they are not very generic) > > http://urgi.infobiogen.fr/BioFloWeb/ > http://mips.gsf.de/cgi-bin/proj/planet/moby/AtiDBClient.cgi > > Cheers, > Rebecca > > > > Mark Wilkinson wrote: > > > Under "Clients" on the new homepage is a list of all of the clients > > and applications that use MOBY that I know about. If I have missed > > anyone, please say so and I'll add it. > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Thu Nov 3 15:00:17 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 3 Nov 2005 07:00:17 -0800 Subject: [MOBY-dev] RE: parseMobyData In-Reply-To: <436A2598.4050307@gsf.de> Message-ID: <000001c5e087$4f3a8850$6600a8c0@notebook> HI! > -----Original Message----- > From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] > Sent: Thursday, November 03, 2005 6:59 AM > To: Edward Kawas > Cc: 'Moby Developers' > Subject: Re: parseMobyData > > Hi Eddie, Mark, Pieter, Tom and others! > > The problem No.1 (Collections in parsemobydata) is solved > resp. it > didn't exist. > As for every other service or scavenger Taverna decomposes > the object > into simples! (this is true for Taverna versions up to 1.1 > and for 1.3. > Not for the 1.2 release though but here Eddie has a bugfix > via CVS) > The reason we believed it is a collection problem is that > parsing of one > service output failed which gives back collections. > Now we digged into it and found that Taverna doesn't have > a problem with > the object being a collection: the problem was that the > service is > registered as giving back simples but gives back > collections. In > contrast to gbrowse Taverna obviously only decomposes > collections when > it expects them to be there. > > We had a look at the second problem (primitives in moby- > objects) and > think that your suggestion with further ports giving > access to the > primitives would solve the problem. If we got it right > this would > replace the 'parseMobyData' scavenger completely - is that > right? I think so. But then again, parseMobyData also allows you to retrieve ids, namespaces, etc. I would only give you the primitive information. Eddie > > Cheers, > Rebecca and Dirk > > > > > > > > > Edward Kawas wrote: > > >Hi Rebecca, > > > >I was unaware of those issues, mainly because I didn't > touch > >that widget and I left it as is for compatibility reasons. > > > >Also, I think that I could add support for parsing > >collections. Given a collection, return a list of > whatever > >that widget returns. > > > >Moreover, you and Pieter have been talking about > retrieving > >the string (and most likely integers, floats, etc) from > the > >objects. Pieter went as far to say that he creates > >processors to do that for him. Do you think that it would > be > >worthwhile to add another port to processors that contain > >the 'primitives' so that you can retrieve them? > > > >For example, imagine that you are using a processor > blastDB > >that performs a blast search on some database and returns > >the blast results in xml. In Moby, this would be a data > type > >called text-xml (I think). Would it be useful to also > have > >an output port that contains only the xml text in it? > > > >Let me know what you think. Most likely, you have a > better > >idea. Tell it to me and I will see what I can do. > > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Rebecca Ernst [mailto:rebecca.ernst at gsf.de] > >>Sent: Wednesday, November 02, 2005 4:33 AM > >>To: Edward Kawas > >>Cc: mobydev > >>Subject: parseMobyData > >> > >>Hi Eddie! > >> > >>I had another look into Taverna to see if our workflows > >>now run > >>correctly but found two problems of parseMobyData. > >>The first problem is that parseMobyData can't deal with > >>collections (it > >>never could) the second is that it also can't deal with > >>the new object > >>stucture (e.g. a string object containing a string now) > as > >>it only > >>checks the first layer content and never goes into the > >>additional string. > >>Do you know of these problems and if so - are there any > >>plans for fixing it? > >> > >>Cheers, > >>Rebecca > >> > >> > > > > > > > > > > > > -- > Rebecca Ernst > MIPS, Inst. for Bioinformatics > GSF Research Center for Environment and Health > Ingolstaedter Landstr. 1 > 85764 Neuherberg > fon: +49 89 3187 3583 > email: Rebecca.Ernst at gsf.de From markw at illuminae.com Thu Nov 3 16:48:43 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:48:43 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <436A3B67.5070302@gsf.de> References: <436972D0.8020606@illuminae.com> <436A3B67.5070302@gsf.de> Message-ID: <1131036523.31833.35.camel@bioinfo.icapture.ubc.ca> Hi Rebecca, Yeah, it turns out that the LSID Perl client stack from Sourceforge doesn't handle namespaces on its wsdl documents (ask me how long it took me to debug THAT problem!), so that resolver doesn't work anymore :-/ >>sigh<< The Perl support for XML is **SO** crappy! Anyway, Eddie has written a new one in Java, and I just haven't had time to set up the link to it. I'll do that right now. Thanks for reminding me! M On Thu, 2005-11-03 at 17:31 +0100, Rebecca Ernst wrote: > Hi Mark! > > I had a look on the website and wanted to test the LSID resolver.. > (http://mobycentral.icapture.ubc.ca/cgi-bin/LSID_Resolver.pl) > > I only get internal server errors when trying it with one of the > examples you give on that page... > > Cheers, > Rebecca > > > > > Mark Wilkinson wrote: > > > Hi all, > > > > I think I'm just about finished moving stuff over to the new website. > > Please browse it and get back to me or Simon with comments. > > > > http://biomoby.open-bio.org > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 16:51:41 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:51:41 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000001c5e087$4f3a8850$6600a8c0@notebook> References: <000001c5e087$4f3a8850$6600a8c0@notebook> Message-ID: <1131036701.31833.41.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > > think that your suggestion with further ports giving > > access to the > > primitives would solve the problem. If we got it right > > this would > > replace the 'parseMobyData' scavenger completely - is that > > right? > I think so. But then again, parseMobyData also allows you to > retrieve ids, namespaces, etc. I would only give you the > primitive information. Is there a need to have both, or should they be rolled into one now? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 16:51:41 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 08:51:41 -0800 Subject: [moby] [MOBY-dev] RE: parseMobyData In-Reply-To: <000001c5e087$4f3a8850$6600a8c0@notebook> References: <000001c5e087$4f3a8850$6600a8c0@notebook> Message-ID: <1131036701.31833.41.camel@bioinfo.icapture.ubc.ca> On Thu, 2005-11-03 at 07:00 -0800, Edward Kawas wrote: > > think that your suggestion with further ports giving > > access to the > > primitives would solve the problem. If we got it right > > this would > > replace the 'parseMobyData' scavenger completely - is that > > right? > I think so. But then again, parseMobyData also allows you to > retrieve ids, namespaces, etc. I would only give you the > primitive information. Is there a need to have both, or should they be rolled into one now? M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From dgpisano at cnb.uam.es Thu Nov 3 17:08:18 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 03 Nov 2005 18:08:18 +0100 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: Message-ID: <436A4402.7000209@cnb.uam.es> Martin Senger escribi?: >Could anybody sent me the latest document we are voting on? (But do not >sent me a link to bugzilla please). > >Martin > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0501INB-ExceptionReporting-v2.02.pdf Type: application/pdf Size: 186802 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available URL: From dgpisano at cnb.uam.es Thu Nov 3 17:36:53 2005 From: dgpisano at cnb.uam.es (=?ISO-8859-1?Q?David_Gonz=E1lez_Pisano?=) Date: Thu, 03 Nov 2005 18:36:53 +0100 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: References: Message-ID: <436A4AB5.6050903@cnb.uam.es> Hello Martin, I've just sent you the latest version (2.02, 3rd November 2005) version which includes some of the changes that were discussed during October. The document is also in the bugzilla (http://bugzilla.open-bio.org/attachment.cgi?id=246) My vote is YES, just in case somebody is wondering ;-) Martin Senger escribi?: >Could anybody sent me the latest document we are voting on? (But do not >sent me a link to bugzilla please). > Some comments about this latest version (the author's name and the date the comment was sent to core developers included, plus the request and the action taken and reflected in the 2.02 version). No major changes, the proposal is still the same than 1 month ago with some rewordings and typos corrected: - Mark (29/09/2005) - Request for change the wording of Change 1 to "In the case of an error, failure should raise an exception and an empty mobyData block with the appropriate queryID will be returned" - INCLUDED - Paul (17/10/2005) - Request to rename the proposal to something more meaningful - DONE, now the proposal is called "Exception Reporting in MOBY-S" - Paul (17/10/2005) - Doubts about the error 701 - DONE, the ambiguous example has been removed - Paul (17/10/2005) - Errors 70* suggestions - DONE partially, added the "error" 700 as a generic service intrinsic exception placeholder for any generic situation where the execution was ok and we want to use mobyException. Other codes not added, see next comment - Martin (18/10/2005) - Type "information" in exception reporting - I think it not hurts to leave it there. It could be used to report informative (non erroneous or warning) exceptions about a specific element (Simple or Collection) or mobyData entry in a structured (parseable) way, because mobyException allows us to map the information to that specific element. We still maintain the Notes in serviceNotes to report general unstructured information, and for functional compatibility with old moby versions - Martin (18/10/2005) - Errors 70* suggestions - DONE partially, added the "error" 700 (see above) and removed all the codes but 701 (SERVICE_INTERNAL_ERROR). As Martin suggests, created a 227 INPUT_INCORRECT_NAMESPACE - Pieter (3/11/2005) - typos in the document - DONE, the tag is called refQueryID, reviewed and changed - Pieter (3/11/2005) - refArticlename - NOT INCLUDED. I know this can open a new can of worms about whether rticlenames should be mandatory or not, and we have talked about this in the past. The problem is not with the exception reporting proposal, but with the MOBY specification itself: if Articlenames are not mandatory, and I can send several elements to the same type to my service, how can I differenciate them? If there is no need to differenciate them, or that does not make sense from the point of view of the service execution, then it makes no sense from the point of view of the exception reporting. If I cannot identify them individually, then I cannot report exceptions about them individually and thus I have to say "There is a problem with one or more or the inputs". If I can differenciate them because they have an Articlename, then I use the refElement tag to refer to the problematic element... Does this make sense? -------------- next part -------------- A non-text attachment was scrubbed... Name: dgpisano.vcf Type: text/x-vcard Size: 338 bytes Desc: not available URL: From duncan.hull at cs.man.ac.uk Thu Nov 3 19:42:13 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Thu, 03 Nov 2005 19:42:13 +0000 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436A6815.70201@cs.man.ac.uk> Dear Mark / BioMOBYers Can you advise me on the best way to get the rdf for the service "EMBOSSbacktranseq" I just wanted some examples, and found http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf ...from martins handy client documentation but not sure if the RDF is up to date. Thanks Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From simont at mcw.edu Thu Nov 3 20:17:50 2005 From: simont at mcw.edu (Twigger Simon) Date: Thu, 3 Nov 2005 14:17:50 -0600 Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <002801c5da7b$42e36ac0$6600a8c0@notebook> References: <002801c5da7b$42e36ac0$6600a8c0@notebook> Message-ID: <78883846-6389-4B18-B334-8D0D3FFC1B04@mcw.edu> I vote in favour of RFC 1863. Simon. On Oct 26, 2005, at 5:18 PM, Edward Kawas wrote: > Hi, > > I am calling a vote on the RFC that discusses error > reporting. > > Please refer to the following link: > http://bugzilla.open-bio.org/show_bug.cgi?id=1863 > > Thanks. > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From markw at illuminae.com Thu Nov 3 20:56:29 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 12:56:29 -0800 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <436A6815.70201@cs.man.ac.uk> References: <436A6815.70201@cs.man.ac.uk> Message-ID: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Hi Dunc! I hope you aren't writing another thesis saying nasty things about MOBY! Okay, the main problem is that the RDF is not up to date - we're still negotiating with Pinar about what the RDF representation of MOBY/myGrid services is going to be (in fact, Eddie is here right now and we are going over the final details). As such, when you do what I suggest below, you are going to get RDF that is still changing daily. Having said all that - there are two ways to get MOBY RDF. You can get it from our RESOURCES script, or by LSID resolution to metadata. To get a full dump of MOBY Central as RDF (the old RDF that we will NOT be using) go to: http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances (this takes a while, since it is dynamically generated...) Or for a specific service, resolve the LSID: urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName (e.g. urn:lsid:biomoby.org:serviceinstance:www.illuminae.com,getSHound3DNeighboursFromGi) We'll have the RDF generator updated in the next few days - hopefully today will be the last of our modifications of the RDF structure to be myGrid-compatible. M On Thu, 2005-11-03 at 19:42 +0000, Duncan Hull wrote: > Dear Mark / BioMOBYers > > Can you advise me on the best way to get the rdf for the service > "EMBOSSbacktranseq" > > I just wanted some examples, and found > http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf > > ...from martins handy client documentation but not sure if the RDF is up > to date. > > Thanks > > Duncan > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 20:59:28 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 12:59:28 -0800 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Message-ID: <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> If you like, I will ask Eddie to write to you when the updates are done, and then you will have something stable to play with... M On Thu, 2005-11-03 at 12:56 -0800, Mark Wilkinson wrote: > Hi Dunc! > > I hope you aren't writing another thesis saying nasty things about MOBY! > > Okay, the main problem is that the RDF is not up to date - we're still > negotiating with Pinar about what the RDF representation of MOBY/myGrid > services is going to be (in fact, Eddie is here right now and we are > going over the final details). As such, when you do what I suggest > below, you are going to get RDF that is still changing daily. > > Having said all that - there are two ways to get MOBY RDF. You can get > it from our RESOURCES script, or by LSID resolution to metadata. > > To get a full dump of MOBY Central as RDF (the old RDF that we will NOT > be using) go to: > > http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances > (this takes a while, since it is dynamically generated...) > > Or for a specific service, resolve the LSID: > > urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName > > (e.g. > urn:lsid:biomoby.org:serviceinstance:www.illuminae.com,getSHound3DNeighboursFromGi) > > We'll have the RDF generator updated in the next few days - hopefully > today will be the last of our modifications of the RDF structure to be > myGrid-compatible. > > M > > > > On Thu, 2005-11-03 at 19:42 +0000, Duncan Hull wrote: > > Dear Mark / BioMOBYers > > > > Can you advise me on the best way to get the rdf for the service > > "EMBOSSbacktranseq" > > > > I just wanted some examples, and found > > http://www.biomoby.org/moby-live/Java/docs/Testing_service.rdf > > > > ...from martins handy client documentation but not sure if the RDF is up > > to date. > > > > Thanks > > > > Duncan > > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Thu Nov 3 21:19:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 13:19:30 -0800 Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <43696D0F.7010605@illuminae.com> References: <43696D0F.7010605@illuminae.com> Message-ID: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Okay, I have thought about this now, and discussed it with Eddie and Ben for a while. I can see the way Martin is thinking, and it is certainly different from how I have always "seen" MOBY Objects. Here's how the argument goes: Martin: MOBY Objects are just syntax, so there is no such thing as a "core" data-type for MOBY objects. They don't have an "essense"! Objects are just "stuff" Mark: Yes they do! The ISA hierarchy implies that an object has an "essense". There are two ways to construct an AnnotatedFASTA object: It can either inherit from FASTA, and add an Annotation, or it can inherit from Annotation and add a FASTA. Under the new object creation system, the syntactic outcome of these paths is identical, but they are "qualitatively" different.... it is nonsensical to "FASTA an Annotation", but it is sensible to "Annotate a FASTA". The "essense" of the object is the FASTA sequence it contains, based on its ISA hierarchy. The problem we have now is that, without querying the ontology and traversing back to the most primitive object, I cannot know which contained object represents the "essense" of my in-hand object (i.e. the thing that I would MOST want to represent if I had to represent that object in a hurry). It also causes a problem with rendering... a FASTA sequence and a Genbank record are formatted strings. What happens now that we have contained primitives is that you have to ask the parent tag about its type before you know how to render the child tag. I can't render a string containing a genbank record without paying attention to its formatting, but I don't know that a String is a formatted string until I ask the parent GenBankFlatfile object what it is... :-/ >>sigh<< I dunno... the world just got much harder. M On Wed, 2005-11-02 at 17:51 -0800, Mark Wilkinson wrote: > Hi Martin, > > I love using you as the bellweather for my own thoughts :-) You are > seldom wrong, and delight in telling me when I am! ;-) > > I think I am starting to see your point - I had not been thinking of the > object ontology in quite that way, but you've got me reconsidering now. > I'm going to bring it up for discussion at my lab meeting tomorrow and > try to hash-out with the local guys exactly why I feel the way I do, and > whether or not there are any serious adverse effects to thinking about > it your way. It certainly makes things easier to do it your way, though > I wish now that we had had this discussion while Eddie was writing the > database update script because I would have changed the way we > approached it... > > Oh well... I guess that's why MOBY is still considered a research > project ;-) > > Thanks for being so forthright in your opinons - you are an extremely > valuable asset to the project! > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From edward.kawas at gmail.com Thu Nov 3 20:56:20 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 3 Nov 2005 12:56:20 -0800 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436A6815.70201@cs.man.ac.uk> Message-ID: <000201c5e0b9$0d6d0fb0$2566a8c0@notebook> Hi Duncan, I am reworking the structure of the rdf document that describes Moby services. Right now, if you want to see an outdated version, http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances would be the place to get a document describing all services. Once the structure has been reworked, I will let you know. Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Duncan Hull > Sent: Thursday, November 03, 2005 11:42 AM > To: Core developer announcements; markw at illuminae.com > Subject: [MOBY-dev] Please sir, can I have some more RDF? > > Dear Mark / BioMOBYers > > Can you advise me on the best way to get the rdf for the > service > "EMBOSSbacktranseq" > > I just wanted some examples, and found > http://www.biomoby.org/moby- > live/Java/docs/Testing_service.rdf > > ...from martins handy client documentation but not sure if > the RDF is up > to date. > > Thanks > > Duncan > > -- > Duncan Hull > http://www.cs.man.ac.uk/~hulld/ > Phone: +44 (0) 161 275 0677 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From adf at ncgr.org Fri Nov 4 00:44:54 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Thu, 3 Nov 2005 17:44:54 -0700 (MST) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark and Martin- I can't resist jumping in here from somewhere out of left field (and without much time over the next week to engage very deeply in the discussion), BUT: it seems to me that the argument you are beginning to hash out here gets close to the issue that the semantic moby side of the world has with respect to moby services' MOBY-XML representation of data vs semantic moby's preference to represent the data (not just the ontologies) as RDF (using RDF/XML or some other RDF syntax). The position below that you ascribe to Martin concerning the non-essential nature of the objects would for the semantic web data representation approach be instead better characterized as a "multi-faceted essence"; that is to say that an object can belong to many classes and each of these "types" associated with the object may (or may not) imply a set of properties ("the stuff") to be expected of an instance of the type OR (conversely) an object that has a certain set of properties may be inferred to belong to a class defined in a certain way. The decision about what is "essential" is I believe one determined by the user of the information, and the best systems are those that allow the same "stuff" to be used in many different purposes (since there is no single type of user). I think it is true that MOBY objects can have multiple typing, by reusing the namespace id in a structure with a different "class tag" (apologies if I have the lingo a bit off, it's been a while for me); and yet, I think your insistence that the ISA determines the object's essence is somewhat indicative of the use of XML structure to have the data producer determine intended usage rather than allowing the data consumer to determine how it may be used. (If we wanted to make this discussion more concrete, I have been fooling around with a little OWL ontology ("owl-let") for properties representing mapping/sequence/feature type info; it is in the same conceptual space as your "genericsequence/virtualsequence/etc." stuff, and might be an instructive example of how the two approaches differ in practice.) My 2c, and not necessarily reflective of the opinions of others in the s-moby sphere, but I do think that this is one of the critical areas to resolve in order to be able to bring the two branches of the project back together. Whether or not RDF is appropriate as a representation of all pieces of a message is another question, but in terms of a data payload representation format, I think we should really give it some consideration if and when we are able to move forward on the long promised reunification of the two branches. RDF: it's not just for metadata! Andrew Farmer PS. I hope this message doesn't hit Martin's mailbox before he's had time for tea... ;) PPS I am not clear on the "rendering" issues you allude to at the end, but we have been having some debates around the issue of transmitting data in well-known text formats embedded within (or as some sort of attachment to) the RDF. I would be interested in hearing about your experiences with such things... On Thu, 3 Nov 2005, Mark Wilkinson wrote: > Okay, I have thought about this now, and discussed it with Eddie and Ben > for a while. I can see the way Martin is thinking, and it is certainly > different from how I have always "seen" MOBY Objects. > > Here's how the argument goes: > > Martin: MOBY Objects are just syntax, so there is no such thing as a > "core" data-type for MOBY objects. They don't have an "essense"! > Objects are just "stuff" > > Mark: Yes they do! The ISA hierarchy implies that an object has an > "essense". There are two ways to construct an AnnotatedFASTA object: > It can either inherit from FASTA, and add an Annotation, or it can > inherit from Annotation and add a FASTA. Under the new object creation > system, the syntactic outcome of these paths is identical, but they are > "qualitatively" different.... it is nonsensical to "FASTA an > Annotation", but it is sensible to "Annotate a FASTA". The "essense" of > the object is the FASTA sequence it contains, based on its ISA > hierarchy. The problem we have now is that, without querying the > ontology and traversing back to the most primitive object, I cannot know > which contained object represents the "essense" of my in-hand object > (i.e. the thing that I would MOST want to represent if I had to > represent that object in a hurry). > > It also causes a problem with rendering... a FASTA sequence and a > Genbank record are formatted strings. What happens now that we have > contained primitives is that you have to ask the parent tag about its > type before you know how to render the child tag. I can't render a > string containing a genbank record without paying attention to its > formatting, but I don't know that a String is a formatted string until I > ask the parent GenBankFlatfile object what it is... :-/ > > >>sigh<< > > I dunno... the world just got much harder. > > M > > > > > On Wed, 2005-11-02 at 17:51 -0800, Mark Wilkinson wrote: > > Hi Martin, > > > > I love using you as the bellweather for my own thoughts :-) You are > > seldom wrong, and delight in telling me when I am! ;-) > > > > I think I am starting to see your point - I had not been thinking of the > > object ontology in quite that way, but you've got me reconsidering now. > > I'm going to bring it up for discussion at my lab meeting tomorrow and > > try to hash-out with the local guys exactly why I feel the way I do, and > > whether or not there are any serious adverse effects to thinking about > > it your way. It certainly makes things easier to do it your way, though > > I wish now that we had had this discussion while Eddie was writing the > > database update script because I would have changed the way we > > approached it... > > > > Oh well... I guess that's why MOBY is still considered a research > > project ;-) > > > > Thanks for being so forthright in your opinons - you are an extremely > > valuable asset to the project! > > > > M > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From senger at ebi.ac.uk Fri Nov 4 02:36:04 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 02:36:04 +0000 (GMT) Subject: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <78883846-6389-4B18-B334-8D0D3FFC1B04@mcw.edu> Message-ID: YES. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 4 02:59:00 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 02:59:00 +0000 (GMT) Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> Message-ID: > Having said all that - there are two ways to get MOBY RDF. You can get > it from our RESOURCES script, or by LSID resolution to metadata. > Interesting is that Mark has not mentioned the only "offical" way how to get RDF: use Biomoby API! This gives you, however, back RDF of all services, not only the one you are interested in - so perhaps that's the reason why he has not mentioned it. (But I doubt it :-) - Mark never liked this part of the Moby API.) I am making jokes but I am also getting tired by the endless discussions about RDF and how to get it. Biomoby is killing itself by having so many ways, so many unofficial ways, and still none of them is working properly for years (yes, I am talking now about the RDF agent which is intrinsicaly connected with RDF...) Duncan, in jMoby, call: build/run/run-cmdline-clinet -rdf services -q > services.rdf and you will get all RDF for services. This is the only official way. Because: 1) going directly to URL > http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances > is an unofficial, never made official, hack. If you wish yo use this way, you should at least get the URL first uding Biomoby API, by calling: build/run/run-cmdline-client -lu Resource URLs: -------------- ServiceInstance http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances Object http://biomoby.org/RESOURCES/MOBY-S/Objects Service http://biomoby.org/RESOURCES/MOBY-S/Services Namespace http://biomoby.org/RESOURCES/MOBY-S/Namespaces Full http://biomoby.org/RESOURCES/MOBY-S/FULL 2) using > Or for a specific service, resolve the LSID: > urn:lsid:biomoby.org:serviceinstance:service.uri,serviceName > suffers from the fact that Biomoby LSIDs were not yet documented properly: you do not know (now) if you should resolve it to data or metadata, and what to expect. As I said, tired from this stuff... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Nov 4 05:37:30 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 03 Nov 2005 21:37:30 -0800 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436AF39A.1030104@illuminae.com> >Biomoby is killing itself > In no way is that true, since only a very few people care right now if there is RDF in MOBY or not. > by >having so many ways, so many unofficial ways, and still none of them is >working properly for years (yes, I am talking now about the RDF agent >which is intrinsicaly connected with RDF...) > > The RDF itself has been changing because it is a new standard, and because it is important to get it right rather than ask people to change it every few months. The desire to adopt the same RDF representationas myGrid is laudible (in my opinion), however the myGrid RDF has also been changing, and still is. We have just sent the myGrid folks a copy of what we hope will be a mutually agreeable document. If they sign-off on it as well, then everything else is in place. > is an unofficial, never made official, hack. > I think Duncan got what he needed, through formal or informal means. These (non-API) features of MOBY are documented in part on the new website (http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/moby_metadata), however the full documentation will take considerable time to write, so it isn't complete. Having multiple ways of obtaining information is a good thing, since it gives people a lot of flexibility in how they build their code, so I don't see this as a legitimate criticism. > As I said, tired from this stuff... > > There are a wide variety of ways you can make the situation better, but bitching about it isn't one of them. M From senger at ebi.ac.uk Fri Nov 4 05:58:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 05:58:09 +0000 (GMT) Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: <436AF39A.1030104@illuminae.com> Message-ID: Mark, I am not bitching around... I am trying to make Biomoby clear. It was always the major Biomoby problem: you have a good idea, but you are not so good at presenting it clearly. So other people must take care about that part. You have Frank to make your documentation more precise, and you have me to make your API design better useable. During the last developer meeting, we had concluded that Biomoby is good in its essence but it is badly presented, it is not a "production-level" product, it does not have proper releases, etc. And until this is done, I will continue to claim that "Biomoby is killing itself by not being a real, "from-the-shelf" product. It is not that it cannot change (after all, it was always a research project) but it should change in predicted or well defined intervals and in a usual form. For example, you should not mix "the contents of RDF" and "the way how to get this RDF". The way how to get it should be fixed and relatively unchanged for longer, the contents itself may be labelled as "not-yet-stable", so it can changed more often. But you do not support this if you do not stick always with the API you yourself created. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Nov 4 06:37:49 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 06:37:49 +0000 (GMT) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: <1131052770.31833.90.camel@bioinfo.icapture.ubc.ca> Message-ID: > Martin: MOBY Objects are just syntax, so there is no such thing as a > "core" data-type for MOBY objects. They don't have an "essense"! > Of course, the objects are just syntax (with semantics added by documentation). But let's not play with the words... What you are saying (IMHO) is that you like to have there also an additional attribute that would define an "essence". In your other email, you called it a "primary contents". You are also saying that two objects may have the same structure, but they can differ by this "primary contents" atribute. I can have an object X that has two members: FASTA and Annotation, and an object Y that has the same members. But Object X inherited from Annotation and added FASTA (because I am creating this object for analyzing various kind of annotations, for example), and the object Y inherited from FASTA and added Annotation as a member (because I am using Y for dealing with sequences). [This is what Andrew said about having multiple users of the same data. Yes, Andrew, I had my cup ot tea :-) ] You are right that to find the ISA hierarchy of objects X and Y you need to traverse back. The attribute "primary contents" would help you to find what you need without traversing back. But they may be other members (children) that you wish to know where they come from - so you would need (theoretically) more and more "essence" attributes. In other words, you may be interested in a complete hierarchy without traversing it back using a registry, but you do not have it because the Biomoby XML message is flatten! This situation is actually not a consequence of banning inheriting from primitives but a consequence of a unfortunate (flatten) design of Biomoby XML message from the beginning. (Now you know what I was bitching around, and lobbying in Vancouver meeting.) If the Biomoby message is a "usual" type of XML, you would have all. For example, and simplified, my X and Y objects would be: hello atata atata hello Just for the readers, what you have now is: hello atata hello atata Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From adf at ncgr.org Fri Nov 4 07:18:53 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Fri, 4 Nov 2005 00:18:53 -0700 (MST) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi again- I'm not sure I have completely grasped your example, but the point about XML hierarchy vs "flattening" is I think quite important. I can't speak to the MOBY object structure very much, but with the RDF-graph mentality, you don't flatten everything, i.e. paths between objects can be traversed via properties that connect them, though there is not a single root at which all paths must begin as with XML. My opinion is that the rootedness and guaranteed depth-first traversal of XML streams is quite nice when you are exchanging messages that are designed for a single purpose that is understood by sender and receiver; but, when the point is merely to represent data (not what is to be done with it), there is no reason to believe that one starting point is more privileged than another- this is IMHO one reason why relational dbs are so versatile and powerful. I might benefit from some clarification of your example. I can easily imagine a sensible case of a sequence with an annotation with a sequence (consider the translation of a CDS on a genomic sequence). The two sequences have different relationships to the annotation but are in themselves both the same type of thing (ignoring the protein/DNA difference). But, there is no reason I can see to treat them differently in terms of "hierarchy" until you provide a context for choosing the "root perspective". Have some more tea, I'm relieved that you haven't completely shut out those of us who can't help using the RDF-word... (sounds like there have been a lot of conversations I have been blissfully unaware of). Andrew > Of course, the objects are just syntax (with semantics added by > documentation). But let's not play with the words... > What you are saying (IMHO) is that you like to have there also an > additional attribute that would define an "essence". In your other email, > you called it a "primary contents". > You are also saying that two objects may have the same structure, but > they can differ by this "primary contents" atribute. I can have an object > X that has two members: FASTA and Annotation, and an object Y that has the > same members. But Object X inherited from Annotation and added FASTA > (because I am creating this object for analyzing various kind of > annotations, for example), and the object Y inherited from FASTA and added > Annotation as a member (because I am using Y for dealing with > sequences). [This is what Andrew said about having multiple users of the > same data. Yes, Andrew, I had my cup ot tea :-) ] > You are right that to find the ISA hierarchy of objects X and Y you > need to traverse back. The attribute "primary contents" would help you to > find what you need without traversing back. > But they may be other members (children) that you wish to know where > they come from - so you would need (theoretically) more and more "essence" > attributes. In other words, you may be interested in a complete hierarchy > without traversing it back using a registry, but you do not have it > because the Biomoby XML message is flatten! > This situation is actually not a consequence of banning inheriting from > primitives but a consequence of a unfortunate (flatten) design of Biomoby > XML message from the beginning. (Now you know what I was bitching around, > and lobbying in Vancouver meeting.) If the Biomoby message is a > "usual" type of XML, you would have all. For example, and simplified, my X > and Y objects would be: > > > hello > > atata > > > > > atata > > hello > > > > Just for the readers, what you have now is: > > > hello > atata > > > > hello > atata > > > Cheers, > Martin > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From senger at ebi.ac.uk Fri Nov 4 07:43:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 4 Nov 2005 07:43:11 +0000 (GMT) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi, Nice to hear from you. Yout email helps to clarify the issues. They are (at least for now) two issues: rootedness (not mentioned in my neither Mark's emails) and flatteness. Rootedness (or not rootnedness) can be addressed by choosing pure XML message or RDF-based message. Flatteness is an issue only for pure XML messages (RDF is not flatten by default). So we have (beter: would have) three ways how to pass Biomoby messages: 1) Flatten traditional XML. This is the current situation in Moby-S. Because of this flatteness, Mark finds problems with not knowning the "primary contents" without traversing/contacting Biomoby registry. 2) Hierarchical traditional XML. This creates more complex messages but it is fully in the XML concepts. It carries all parental, ISA relationships. This is what Moby-S does not use. And there is no strong movement to this (except me advocating at least discussion about it). 3) RDF-based message. This would, additionally to not being flat, so keeping ISA hierarchy, add also non-rootedness. There is no discussion whether to move Moby-S this direction. My guess is that if we move Moby-S to any big changes regarding the message structure, it would probably be better to jump here and skip the "hierarchical traditional XML" structure. One last comment regarding rootedness: If you interpres a message, you always need to know when to start, so anyway you define a root node. This is the same for RDBS: you need to know which table to start with. So the rootedness is not about "not having a root" but about "having more roots than just one". But that is very probably what you meant anyway. > I might benefit from some clarification of your example. I can easily imagine > a sensible case of a sequence with an annotation with a sequence > I can clarify further, but it seems to me that you got it already right. Yes, your example is a better way to say what I was expressing. But please let me know if I can clarify better. > Have some more tea, I'm relieved that you haven't completely shut out those > of us who can't help using the RDF-word... > I am not against RDF. I am just against jumping to it without saying why. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Fri Nov 4 10:51:14 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 11:51:14 +0100 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> Message-ID: <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> On 3-Nov-2005, at 5:18 PM, Mark Wilkinson wrote: > On Thu, 2005-11-03 at 12:17 +0100, Pieter Neerincx wrote: > > >> Forbidden > > All these that I can find are now fixed. Thanks! > I was paranoid last night and > switched off execute permissions on all folders in the CVS except for > the ones that I knew contained documentation because it makes me > nervous > having end-user-writable executable folders on our website! > > >> Furthermore I added a page to the Docs in the CVS some time ago, but >> I can not find it anywhere on the new website... > > where? It's in moby-live/Docs/Central/ Pieter > > M > > > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Fri Nov 4 12:12:43 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 13:12:43 +0100 Subject: [moby] RE: [MOBY-dev] vote on the RFC discussing Error Reporting In-Reply-To: <436A4AB5.6050903@cnb.uam.es> References: <436A4AB5.6050903@cnb.uam.es> Message-ID: <781B1075-CF65-4D12-B4A5-5C1AB925C3FF@wur.nl> Hi David, On 3-Nov-2005, at 6:36 PM, David Gonz?lez Pisano wrote: > > - Pieter (3/11/2005) - refArticlename - NOT INCLUDED. I know this > can open a new can of worms about whether articlenames should be > mandatory or not, and we have talked about this in the past. The > problem is not with the exception reporting proposal, but with the > MOBY specification itself: if Articlenames are not mandatory, and I > can send several elements to the same type to my service, how can I > differenciate them? If there is no need to differenciate them, or > that does not make sense from the point of view of the service > execution, then it makes no sense from the point of view of the > exception reporting. If I cannot identify them individually, then I > cannot report exceptions about them individually and thus I have to > say "There is a problem with one or more or the inputs" Good point. It's more clear to me now and I think what you describe above is the best solution for the current BioMOBY spec. > If I can differenciate them because they have an Articlename, then > I use the refElement tag to refer to the problematic element... If you ignore the element name and use the articleName attribute to point to specific elements I do think it makes more sense to name that attribute refArticleName instead of refElement though. Having the refElement attribute contain a articleName adds unnescessary confusion to the error reporting mix. Cheers, Pieter > Does this make sense? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From duncan.hull at cs.man.ac.uk Fri Nov 4 12:28:13 2005 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Fri, 04 Nov 2005 12:28:13 +0000 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> Message-ID: <436B53DD.9070100@cs.man.ac.uk> Mark, Martin and Eddie Thank you all for your rapid and informative responses to my question, I now have what I need. I'd be interested to hear about the RDF updates Eddie is working on, so keep us posted. Mark Wilkinson wrote: > I hope you aren't writing another thesis saying nasty things about MOBY! I hope I've never said nasty things about MOBY, at least not while I was sober... I frequently say nasty things about RDF, but thats a seperate issue :) BTW: We're writing a paper for Dubya Dubya Dubya http://www2006.org/ and BioMOBY is a core part of the related work section, so I needed an RDF example for illustration. If the paper makes it into the 15% of submissions that get accepted, we can add it to the growing list of BioMOBY publications...fingers crossed. Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From markw at illuminae.com Fri Nov 4 14:31:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 06:31:26 -0800 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436B53DD.9070100@cs.man.ac.uk> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> <436B53DD.9070100@cs.man.ac.uk> Message-ID: <436B70BE.2090007@illuminae.com> Hi Duncan! > Thank you all for your rapid and informative responses to my question, > I now have what I need. I'd be interested to hear about the RDF > updates Eddie is working on, so keep us posted. I believe that the LSID resolver and the RESOURCES script are both now outputting our latest version of the Service Instance RDF. We're sending it to Pinar today along with the changes that are required in the myGrid ontology to make it compatible (i.e. things that we think are wrong in the myGrid ontology... cheeky buggers that we are!). Hopefully this will be useful to you in that you will be able to write a single tool to explore both registry systems for your research. >> I hope you aren't writing another thesis saying nasty things about MOBY! > > I hope I've never said nasty things about MOBY, at least not while I > was sober... :-) I know :-) Just teasing. > BTW: We're writing a paper for Dubya Dubya Dubya http://www2006.org/ > and BioMOBY is a core part of the related work section, so I needed an > RDF example for illustration. Excellent! > If the paper makes it into the 15% of submissions that get accepted, > we can add it to the growing list of BioMOBY publications...fingers > crossed. Excellent! Good luck! M > Duncan > From markw at illuminae.com Fri Nov 4 14:55:51 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 06:55:51 -0800 Subject: [MOBY-dev] Please sir, can I have some more RDF? In-Reply-To: <436B70BE.2090007@illuminae.com> References: <436A6815.70201@cs.man.ac.uk> <1131051389.31833.74.camel@bioinfo.icapture.ubc.ca> <1131051568.31833.76.camel@bioinfo.icapture.ubc.ca> <436B53DD.9070100@cs.man.ac.uk> <436B70BE.2090007@illuminae.com> Message-ID: <436B7677.9010301@illuminae.com> > We're sending it to Pinar today along with the changes that are > required in the myGrid ontology to make it compatible (i.e. things > that we think are wrong in the myGrid ontology... cheeky buggers that > we are!). Of course, our suggestions may be complete rubbish... (sorry myGrid folks - the message about sounded MUCH funnier in my head than it came out on paper! :-) ) M > From akerhornou at imim.es Fri Nov 4 15:44:20 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 04 Nov 2005 16:44:20 +0100 Subject: [MOBY-dev] Registrying a moby service that takes an input collection Message-ID: <436B81D4.6040102@imim.es> Hi everyone, I want to register, at icapture registry, a moby service that takes a collection of DNASequence objects (the service is called 'runMatScanGFFCollection') The registration seems fine, but i get this message errors when trying to retrieve information from the registry (using a customised perl script of ours): -------------------------------> ../retrieveService.pl -x 4 -s runMatScanGFFCollection -w genome.imim.es * Name: runMatScanGFFCollection * Contact e-mail: akerhornou at imim.es * Provider: genome.imim.es * URL: http://genome.imim.es/cgi-bin/moby/MobyServices.cgi * Type: Analysis * Category: moby * Description: Promoter regions analysis program. Matscan is a program to search putative binding sites in genomic sequences. You can search for example the Transfac database, but also MEME or jaspar matrices. This service only accepts a collection of DNASequence objects and returns a collection of GFF objects (one GFF object for each DNASequence). If you want to give MatScan output to Meta-alignment program, you MUST use the 'log-likelihood matrix' mode. * Input: articleName: upstream_sequences collection of => articleName: objectType: DNASequence Use of uninitialized value in pattern match (m//) at /home/ug/arnau/cvs/moby-live/Perl/MOBY/Client/CollectionArticle.pm line 189. Use of uninitialized value in pattern match (m//) at /home/ug/arnau/cvs/moby-live/Perl/MOBY/Client/CollectionArticle.pm line 189. No such method: MOBY::Client::CollectionArticle::namespaces at ../retrieveService.pl line 162 <------------------------------------ Does it mean the registration has failed ? Anyway, the service is visible and i have also tried to execute it using taverna 1.3 and it fails (i have attached a workflow). i get this error, ERROR 2005-11-03 17:55:52,228 (org.biomoby.client.taverna.plugin.BiomobyTask:233) - Error invoking biomoby service for biomoby java.lang.ClassCastException at org.biomoby.client.taverna.plugin.BiomobyTask.execute(BiomobyTask.java:95) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.runAndGenerateTemplates(ProcessorTask.java:462) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.doInvocationWithRetryLogic(ProcessorTask.java:407) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeOnce(ProcessorTask.java:329) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invokeWithoutIteration(ProcessorTask.java:521) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.invoke(ProcessorTask.java:261) at uk.ac.soton.itinnovation.taverna.enactor.entities.ProcessorTask.handleRun(ProcessorTask.java:199) at uk.ac.soton.itinnovation.freefluo.core.task.NewState$1.run(NewState.java:67) Any idea why it fails ? thanks, Arnaud -------------- next part -------------- A non-text attachment was scrubbed... Name: iCapture_getUpstreamSeqfromEnsembl_MatScanCollection.xml Type: text/xml Size: 2754 bytes Desc: not available URL: From markw at illuminae.com Fri Nov 4 16:00:24 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 08:00:24 -0800 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> Message-ID: <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> > It's in moby-live/Docs/Central/ Perhaps move it into moby-live/Docs/MOBY-S_API where the other documents are. It's important to have them all in one place. That folder currently doesn't have an index.html file - only an index_API.html. If your document is API related, then you should add a link to it in the index_API.html file. If it isn't, then perhaps make an index.html file with appropriate links to both your document and to the index_API.html file. I'll change the links on the website to make it accessible. these are all in the CVS. M From markw at illuminae.com Fri Nov 4 16:05:52 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 04 Nov 2005 08:05:52 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436B81D4.6040102@imim.es> References: <436B81D4.6040102@imim.es> Message-ID: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> I'll address the first part... > <------------------------------------ > > Does it mean the registration has failed ? You need to check the return value of your registration attempt - a small XML object is returned to you that contans (among other things - see the API) a boolean 1/0 as to success or failure of your registration. Your registration was successful (I just checked the database). The client-side problem is a new one for me. I'll try to duplicate it here later. The Taverna problem I will leave to Eddie to answer (though I think I know what the answer is) M From adf at ncgr.org Fri Nov 4 16:16:09 2005 From: adf at ncgr.org (Andrew D. Farmer) Date: Fri, 4 Nov 2005 09:16:09 -0700 (MST) Subject: [moby] [MOBY-dev] Reserved word... perhaps unnecessary... In-Reply-To: Message-ID: Hi again- > One last comment regarding rootedness: If you interpres a message, you > always need to know when to start, so anyway you define a root node. This > is the same for RDBS: you need to know which table to start with. So the > rootedness is not about "not having a root" but about "having more roots > than just one". But that is very probably what you meant anyway. Well, not exactly. Certainly for RDBMS the theory is that the starting point(s) are irrelevant : which table to start with for a query involving joins is an implementation detail determined not by your query message but by the optimizer; similarly the row in a table that is processed first is immaterial to the sense of the query. In terms of serialization yes, you must pick a first element (otherwise it wouldn't be serial!), but RDF as a data model (not a concrete syntax) seems to be inherently about "random access"; e.g. the ability to ask for all resources having a given property (regardless of what class they belong to) is perhaps even more "unrooted" than RDBMs in which you clearly specify the tables to which your desired instances belong- but it is probably a wrong analogy to pair tables with classes- better would be to think of each property as its own two-element "relation". If pressed to comment on the actual practical implication of taking one attitude rather than another, my thoughts are not entirely clear, but I would claim that it has to do with thinking about "service descriptions" in part as defining queries that extract the data that they will process from a given dataset rather than defining message structures that they expect a client to formulate and send to them. The former approach is along the lines of the data-driven "dynamic discovery" idea of ISYS. This is also the direction I think semantic MOBY is in some ways trying to take. > I am not against RDF. I am just against jumping to it without saying > why. I am in whole-hearted agreement with that attitude. I feel the same way about XML ;) In all seriousness though, I think you are absolutely right to insist on conceptual clarity in these decisions and that there are areas in the MOBY problem space where RDF is NOT the right approach. Regards, -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- "To live in the presence of great truths and eternal laws, to be led by permanent ideals- that is what keeps a man patient when the world ignores him, and calm and unspoiled when the world praises him." -Balzac --- From edward.kawas at gmail.com Fri Nov 4 16:18:03 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 4 Nov 2005 08:18:03 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninput collection In-Reply-To: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <000c01c5e15b$563059d0$6600a8c0@notebook> Hi, The problem is on the side of the service provider: They advertise a collection as the output, yet this is the output: 2000 TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGAAAG TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTTTTT AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGTAGG GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAAGTA AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAGTGG TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAGGGG CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAGACA AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAATCTG GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAGACA CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATGAAG TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACCTCT GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAGGCG CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATGTTG GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAAGTG CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGATTA CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTTTTT TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTTGGC TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGTAGT TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGGGTT TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGGCCT CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGTTTC TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCTAAG GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGGCAG CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGCGAG CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCCTTT TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCCACC GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTGCTC TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCTCCA GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGCTCC ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGAGTG TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGGCCC TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGGCCG AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCCCTG TCCGGCCAGCCCCTCGAAGC 2222:NCBI35:8:11695664:11697663:1 Not a collection. If you are the service provider, you must ensure that you output what you state that you will. Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Friday, November 04, 2005 8:06 AM > To: Arnaud Kerhornou; Core developer announcements > Subject: Re: [moby] [MOBY-dev] Registrying a moby service > that takes aninput collection > > I'll address the first part... > > > > > <------------------------------------ > > > > Does it mean the registration has failed ? > > You need to check the return value of your registration > attempt - a > small XML object is returned to you that contans (among > other things - > see the API) a boolean 1/0 as to success or failure of > your > registration. > > Your registration was successful (I just checked the > database). The > client-side problem is a new one for me. I'll try to > duplicate it here > later. > > The Taverna problem I will leave to Eddie to answer > (though I think I > know what the answer is) > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Fri Nov 4 16:01:33 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Fri, 04 Nov 2005 17:01:33 +0100 Subject: [MOBY-dev] Re: [moby] Please sir, can I have some more RDF? In-Reply-To: References: Message-ID: <436B85DD.7060907@cnb.uam.es> Hi everybody, I think Martin is right about a fixed and relatively unchanged way to obtain the RDF representation for each one of the registered services, objects and namespaces. If you are telling MOBY RDF structure is evolving, then RDF files published by any one of the service providers must be updated each time i changes. And also, there should be some well-known APIs (or procedures) to ease the automation of that process. Currently, the RDFs I have are from the Jurassic MOBY! Best Regards, Jos? Mar?a Martin Senger wrote: > Mark, > I am not bitching around... I am trying to make Biomoby clear. It was > always the major Biomoby problem: you have a good idea, but you are not so > good at presenting it clearly. So other people must take care about that > part. You have Frank to make your documentation more precise, and you have > me to make your API design better useable. > During the last developer meeting, we had concluded that Biomoby is > good in its essence but it is badly presented, it is not a > "production-level" product, it does not have proper releases, etc. And > until this is done, I will continue to claim that "Biomoby is killing > itself by not being a real, "from-the-shelf" product. > It is not that it cannot change (after all, it was always a research > project) but it should change in predicted or well defined intervals and > in a usual form. For example, you should not mix "the contents of RDF" and > "the way how to get this RDF". The way how to get it should be fixed and > relatively unchanged for longer, the contents itself may be labelled as > "not-yet-stable", so it can changed more often. But you do not support > this if you do not stick always with the API you yourself created. > > Martin > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From akerhornou at imim.es Fri Nov 4 16:16:37 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 04 Nov 2005 17:16:37 +0100 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> References: <436B81D4.6040102@imim.es> <1131120352.1416.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <436B8965.9060705@imim.es> Mark Wilkinson wrote: >I'll address the first part... > > >><------------------------------------ >> >>Does it mean the registration has failed ? >> >> > >You need to check the return value of your registration attempt - a >small XML object is returned to you that contans (among other things - >see the API) a boolean 1/0 as to success or failure of your >registration. > > > it actually returned 1 >Your registration was successful (I just checked the database). The >client-side problem is a new one for me. I'll try to duplicate it here >later. > > > ok, thanks Arnaud >The Taverna problem I will leave to Eddie to answer (though I think I >know what the answer is) > >M > > > > > From akerhornou at imim.es Fri Nov 4 17:21:33 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Fri, 04 Nov 2005 18:21:33 +0100 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninput collection In-Reply-To: <000c01c5e15b$563059d0$6600a8c0@notebook> References: <000c01c5e15b$563059d0$6600a8c0@notebook> Message-ID: <436B989D.8040108@imim.es> Hi Eddie, I'm the service provider of getUpstreamSeqfromEnsembl and i've checked the apache log file, and i get a collection back (giving a list of ensembl gene identifiers, 'ENSG00000160087' and 'ENSG00000160182' in a text-formatted object): 2000 ACCCGTGTAAATAAATCATGTCTCCCTAAAATGTATAAAAGCGAGCTGTGCCACATGCACCTTGGGCACCTCCCGAGATGTCATGGGTGTGTCCTTAACCTTGGCAAAACAAACTTTCTAAAGGGACTGAGACCTTCCTCAGTTTGCACCCTCCAGGCTGGGTTCTCTGTCCCTCAAGCATCCCCTGGCCAGACAATCCCTGCTGTTCAGAGGCAGCCAAGGCTTTCTGGTCCAACCCTGGGGGCTGGAGGAGGTGGGGGCAGGAGGTGGTAACTGGGTTGGGGGATGTTTTCTTGGTTGCCAAAGCAGAGGGTGCCCCCCGCTGCTCAAGATGCTGAGGGTGGTCCCTGTTGTCCTATTCCTGAAGCTGCCAGAGGAAGTCCCTCCGGAGGGCTGGCCCACAGCAGAAGGGCTGCTCCTGCCCTCAGAGGGCAATCTCAGGGTTGAGAAGGTTACAGCCACCATCTGCCACCAACCTAGCTGCTTGTGCCGATCCCACTGGCCAAGGCCATCGGCTCTATGGCTAGAGGCCTGGGCAGCCTGTGTCCTGCTTACCAGAAGGCCACAGATGCGGGTGGGTGGGGTGGTGGGGTCTTGGCAAGACGTGCTGGCCACACCTGTCCGGGGCACCTTCTCCCTGGGGTGTGACTCAGCCATGCTCCTGAGCAGGGGCCTCTGAGTTGAGCCTCGCTGCAGTCTTCCCAGCTGCAGGGCCCCCACAGGTGTGCTGTCATCGCACACTACTGAGGGACAGACAAGGCAGAGCGGGCCTCCATCTGCCGCGGGCCACAGCCGTGAGTGTGCATGCGAGTGGATGTGCTGGTGCCTGTATCTGCGGCCGGTGTGGCTTCCCTCACATAACTTTCCATGCTGTGAAAACAGTTTGGCCTGCCCTGCATGGGAACGGCAGAGGCCTGAGAGGAGGCAGAGGAAGGAGGCTGGATGCTGAGATGTTCTCCGAAGGTGGAGCCGGTGACGGCAGTAATGGAGGCAGGCTGGATTCCCACGGGCTGAGGCTGCGTGGACACTCCTCCTGGCTTCTGCCCCACGGCCTGCAGCAACGTCTCAGACCCACCAAGGTGTCCCAGAGGGCCAGAGTCAGGGCTGAGCATGGACACAGCCTGCCCTCTGCCCGTAGCCACAGCGGGACTGACCCTCAATATTCAGCCACCTTGCTGACCTGTGGTTGTTCCTGAGAGGCAGTCAGGGTTGGGGCAAAGGAGAGGGCCACAGGCAGCCAGGTGGCGAGGTCCACCTCCTGATCCCCCACCAGGGGACCACCCTCAGCTCCCCGCTGTCCTCAGCGGCCTCTCAGGGAGGCGGTGGGCTGCGCGCCTGCCCCCAGCGTCCCACCCCAGCGCCCCGCCACCTACCGCTCTCTCCCAATGTGTCTGGGGTCAGAGAGAGGTGGAGAGGACGCAGCGCCCCGCGCTTTCTGCAGTCTGTCCAAGGGGAGGTCAGGGGCATCCCGGGGCTGGGCAGGCACCTGCAGGGGAGGGTGCTGCGGCGCGGACGTGGGTTGCAAAGAGATGCCACGCGTGTCACTCTCGGGTCCCTGAACGAGAGAGCTCTGAGCTCCCTGGAGCCCAACCCTCCACTGAGCCTCCAGGGGCCCGGGACGCTCCATGCCCGGGCCGCGCCGCGCCTCCCCTAAGGGCCGGGTGGGGCGTGGGAGCGGAGGACAAGGCGGGAGCCGGGAGGCGGGAGGGTCGGGGTTCTTTCTCCACCGGGGTCGCCCTCAGCCGGGCCTGCCGCCCTGGGCCGTGGCACATGGGGAGGGAAGCGCGCGGCTTCGGGGTCTGGGGCTCTCGCGCCCACTAACGGTGCCCGGAGCCGCCCGCCAGTGCGCAAGCGCCGCCCCGCCCCCCGCCCCATCCCCCACCCCGGGGTCGACGGCGACAGAGAGTCGTGGGCGCGGTCCGCCAGTCTGCCTAGAGCGGCCAGCCCTCCCCCTCCCTCCTCACCGCCCCGGACCGCGCACCGGAAGCAGAAGCTAGGCT ENSG00000160087:NCBI35:1:1249158:1251157:-1 2000 GGACTTGAGCATTTGTGGATTTTGGCATCCCTGGGTGGGGGGTCCTGAAACCAGTCCCCCAGGGGTACTAAGGGACGACTGCATTGTATTTTAAGTTCATTTTCCCTTTCCCTGGTTAATGAATATTTATTTTGCTTTTCTTTCCCTCCTTTCCTTCCTTCCTTCTTTCCCTGTTTCCAGCTGTTACAAACAATGCTAAAAAGAATATCTTTGCCTGTGTTTTCTTCTGCCCAAGTATGAACATGTTTCTGGGATTAAGAGACCAGGCCTGGAAACAGAAGAATTTGCTGAGCTGTAAAATCTGTATGGCTTAAACCTCACCGAACACTGCCCACCTTTTCTCCAAATGATTGTGCAATTTACATCCCATTTCCAAGAGCCCCCATTTTGATCCGAGAAATTAGAGCAGCGAAAACCACCGTCACTATGAGCACCACCCTGGGCCTGGTGCCCCCGTCCTGTTTTCAATAAACTTAAGCTGACCACAGAGGACACCAGGCCTCGGCCCCTCCCTGGGTCCTGCGGTCAGGCCCCTCCTGGAGACCCTGGCCCAGGAGTGGAGACCCCGGTGCAGGAGTGGCAGCCCTGGAGGAGGGGCTGGGTCCTGGGATGGAGCGAAGAGGAACATGGCCGCCCCCATTCTGGCCCAGGCTCCCCTCCCAGAGGGGCTGCAGAAATGTACTGACTAGGTCACCCAAGAAAAGATAGTACCTTTGTTAGGCTAGCATGCATTTTCCTCAGGGCCTAATTTCTCACTGAAGAAGAAAAGATTTCTCCTGTTGTCCATTTCTTCATGCAGCTCTTCAACAGCTGTTTCTCGAATGCCAATCAAAGCCACTGTTCTAGGGTCTGGGGCCACCTCAAGGCACTAGGAGATGAGGACTTCTGCTCCCATGCGCCCTCCCGTCTGCTGCAGGGAGGAGTGCAATGAATAAATAACCAACATAATGTGTCAGTCACTTGTTTTATCCACCAGGAGGTAATAAGAGCTATGAAAGAGAAAGCTCCGAGCAGGGGAGGGGAGTGAGGCATGGTACAGGAGAGCAGGAGGCTGTCCTCTAAAATACAGGAGTCCAGGGGACCAACTGGGAAGGTGTGGGAGGGGGAGGGAGGGAGCCCCATAGACACAGGGGAGTGAACCACGTTCACTTTGTCAGTTTTTGATGGCAGCTCGTATATACTATTTTTTTCTCCCTCCTGCCCCCAGCCCCTCCCAGAAGGAGACTTAATCTGTCGCTCAGGCTGGAGTGCAGTAGGGTGATCTCGACTCACTGCAACCTCCGCCTCCCAGGTTCAAGTGATTCTCCTGACTTAACCTCCAGAGTAGCTAGGATTACAGGCACCCGCCACCATGCCTGGCTAATTTTTGTATTTTTTTTTTTTGTAGAGACGGGGTTTCGCCATGTTGGCCAGGCTAGTCTCAAACTCCTGACTTTAAGTGATCCGCCTGCTTTGGCCTCCCAAAGTGTTGGGATTACAGGCGTGAGCCACTGCGCCAGGCCTACAATTTCATTATTAAAACAATTCCACTGTAAAAGAATTAGCTTAGGCCTAGACGGAATGGGCTTCATGAGCTCCTTCCCTTCCCCCTGCAAGGTCACGGTGGCCACCCCGTGAGCCACTGTTGTCACGGCCAAGCCTTTTTCCGGCCATCTCTCACTATGAATCACTTCTGCAGTGAGTACAGTATTTACCCTGGCGGGAGGGCCTCTCAGATATGAGTAGGACCTGGATTAAGGTCAGGTTGGAGGAGACTCCCATGGGAAAGAGGGACTTTCTGAATCTCAGATCCCTCAGCCAAGATGACCTCACCACATGTCGTCTCTGTCTATCAGCAAATCCTTCCATGTAGCTTGACCATGTCTAGGAAACACCTTTGATAAAAATCAGTGGAGATTATTGTCTCAGAGGATCCCCGGGCCTCCTTAGGCAAATGTTATCTAACGCTCTTTAAGCAAACAGAGCCTGCCCTATAAAATCCGGGGCTCGGGCGGCCTCTC ENSG00000160182:NCBI35:21:42659714:42661713:-1 but you're right taverna displays a list of two simple DNASequence objects, so i don't understand what i am doing wrong ? cheers, Arnaud Edward Kawas wrote: >Hi, > >The problem is on the side of the service provider: > >They advertise a collection as the output, yet this is the >output: > > > > > > > > id="ENSG00000079459"> > namespace="" id="" articleName="Length"> >2000 > > namespace="" id="" articleName="SequenceString"> >TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGAAAG >TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTTTTT >AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGTAGG >GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAAGTA >AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAGTGG >TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAGGGG >CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAGACA >AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAATCTG >GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAGACA >CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATGAAG >TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACCTCT >GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAGGCG >CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATGTTG >GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAAGTG >CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGATTA >CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTTTTT >TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTTGGC >TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGTAGT >TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGGGTT >TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGGCCT >CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGTTTC >TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCTAAG >GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGGCAG >CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGCGAG >CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCCTTT >TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCCACC >GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTGCTC >TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCTCCA >GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGCTCC >ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGAGTG >TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGGCCC >TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGGCCG >AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCCCTG >TCCGGCCAGCCCCTCGAAGC > > namespace="" id="" articleName="Description"> >2222:NCBI35:8:11695664:11697663:1 > > > > > > > >Not a collection. > >If you are the service provider, you must ensure that you >output what you state that you will. > >Hope this helps, > >Eddie > > > >>-----Original Message----- >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- >>dev-bounces at portal.open-bio.org] On Behalf Of Mark >>Wilkinson >>Sent: Friday, November 04, 2005 8:06 AM >>To: Arnaud Kerhornou; Core developer announcements >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service >>that takes aninput collection >> >>I'll address the first part... >> >> >> >> >> >>><------------------------------------ >>> >>>Does it mean the registration has failed ? >>> >>> >>You need to check the return value of your registration >>attempt - a >>small XML object is returned to you that contans (among >>other things - >>see the API) a boolean 1/0 as to success or failure of >>your >>registration. >> >>Your registration was successful (I just checked the >>database). The >>client-side problem is a new one for me. I'll try to >>duplicate it here >>later. >> >>The Taverna problem I will leave to Eddie to answer >>(though I think I >>know what the answer is) >> >>M >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From Pieter.Neerincx at wur.nl Fri Nov 4 17:23:02 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 18:23:02 +0100 Subject: [moby] Re: [MOBY-dev] New website is ready... In-Reply-To: <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> References: <436972D0.8020606@illuminae.com> <7C384B45-F75E-4DAE-A6A2-221DCFA82BF9@wur.nl> <1131034706.31833.23.camel@bioinfo.icapture.ubc.ca> <6D620E50-9797-457D-AA98-486C97B9DD28@wur.nl> <1131120024.1416.21.camel@bioinfo.icapture.ubc.ca> Message-ID: <775C08CD-2DC3-42DB-85F6-0F2DE5D7F80F@wur.nl> Ok, will do that sometime this weekend ... On 4-Nov-2005, at 5:00 PM, Mark Wilkinson wrote: > >> It's in moby-live/Docs/Central/ > > Perhaps move it into moby-live/Docs/MOBY-S_API where the other > documents > are. It's important to have them all in one place. > > That folder currently doesn't have an index.html file - only an > index_API.html. If your document is API related, then you should > add a > link to it in the index_API.html file. If it isn't, then perhaps make > an index.html file with appropriate links to both your document and to > the index_API.html file. I'll change the links on the website to make > it accessible. > > these are all in the CVS. > > M > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Fri Nov 4 17:49:33 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 4 Nov 2005 09:49:33 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes aninputcollection In-Reply-To: <436B989D.8040108@imim.es> Message-ID: <000d01c5e168$1e0bdef0$6600a8c0@notebook> Sorry, it turns out you did nothing wrong. You found a bug that I have fixed and will commit to the Taverna cvs as soon as I stop getting timeout errors. In the meantime, download the taverna1.3.jar from the following location: http://bioinfo.icapture.ubc.ca/ekawas/jars/ and replace the one in the taverna-workbench-1.3/lib directory. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Arnaud > Kerhornou > Sent: Friday, November 04, 2005 9:22 AM > To: Core developer announcements > Subject: Re: [moby] [MOBY-dev] Registrying a moby service > that takes aninputcollection > > Hi Eddie, > > I'm the service provider of getUpstreamSeqfromEnsembl and > i've checked > the apache log file, and i get a collection back (giving a > list of > ensembl gene identifiers, 'ENSG00000160087' and > 'ENSG00000160182' in a > text-formatted object): > > > moby:articleName='upstream_sequences'> > > namespace='ENSEMBL' id='ENSG00000160087'> > articleName="Length">2000 > articleName="SequenceString">ACCCGTGTAAATAAATCATGTCTCCCTAA > AATGTATAAAAGCGAGCTGTGCCACATGCACCTTGGGCACCTCCCGAGATGTCATGGG > TGTGTCCTTAACCTTGGCAAAACAAACTTTCTAAAGGGACTGAGACCTTCCTCAGTTT > GCACCCTCCAGGCTGGGTTCTCTGTCCCTCAAGCATCCCCTGGCCAGACAATCCCTGC > TGTTCAGAGGCAGCCAAGGCTTTCTGGTCCAACCCTGGGGGCTGGAGGAGGTGGGGGC > AGGAGGTGGTAACTGGGTTGGGGGATGTTTTCTTGGTTGCCAAAGCAGAGGGTGCCCC > CCGCTGCTCAAGATGCTGAGGGTGGTCCCTGTTGTCCTATTCCTGAAGCTGCCAGAGG > AAGTCCCTCCGGAGGGCTGGCCCACAGCAGAAGGGCTGCTCCTGCCCTCAGAGGGCAA > TCTCAGGGTTGAGAAGGTTACAGCCACCATCTGCCACCAACCTAGCTGCTTGTGCCGA > TCCCACTGGCCAAGGCCATCGGCTCTATGGCTAGAGGCCTGGGCAGCCTGTGTCCTGC > TTACCAGAAGGCCACAGATGCGGGTGGGTGGGGTGGTGGGGTCTTGGCAAGACGTGCT > GGCCACACCTGTCCGGGGCACCTTCTCCCTGGGGTGTGACTCAGCCATGCTCCTGAGC > AGGGGCCTCTGAGTTGAGCCTCGCTGCAGTCTTCCCAGCTGCAGGGCCCCCACAGGTG > TGCTGTCATCGCACACTACTGAGGGACAGACAAGGCAGAGCGGGCCTCCATCTGCCGC > GGGCCACAGCCGTGAGTGTGCATGCGAGTGGATGTGCTGGTGCCTGTATCTGCGGCCG > GTGTGGCTTCCCTCACATAACTTTCCATGCTGTGAAAACAGTTTGGCCTGCCCTGCAT > GGGAACGGCAGAGGCCTGAGAGGAGGCAGAGGAAGGAGGCTGGATGCTGAGATGTTCT > CCG! > AAGGTGGAGCCGGTGACGGCAGTAATGGAGGCAGGCTGGATTCCCACGGGCTGAGGCT > GCGTGGACACTCCTCCTGGCTTCTGCCCCACGGCCTGCAGCAACGTCTCAGACCCACC > AAGGTGTCCCAGAGGGCCAGAGTCAGGGCTGAGCATGGACACAGCCTGCCCTCTGCCC > GTAGCCACAGCGGGACTGACCCTCAATATTCAGCCACCTTGCTGACCTGTGGTTGTTC > CTGAGAGGCAGTCAGGGTTGGGGCAAAGGAGAGGGCCACAGGCAGCCAGGTGGCGAGG > TCCACCTCCTGATCCCCCACCAGGGGACCACCCTCAGCTCCCCGCTGTCCTCAGCGGC > CTCTCAGGGAGGCGGTGGGCTGCGCGCCTGCCCCCAGCGTCCCACCCCAGCGCCCCGC > CACCTACCGCTCTCTCCCAATGTGTCTGGGGTCAGAGAGAGGTGGAGAGGACGCAGCG > CCCCGCGCTTTCTGCAGTCTGTCCAAGGGGAGGTCAGGGGCATCCCGGGGCTGGGCAG > GCACCTGCAGGGGAGGGTGCTGCGGCGCGGACGTGGGTTGCAAAGAGATGCCACGCGT > GTCACTCTCGGGTCCCTGAACGAGAGAGCTCTGAGCTCCCTGGAGCCCAACCCTCCAC > TGAGCCTCCAGGGGCCCGGGACGCTCCATGCCCGGGCCGCGCCGCGCCTCCCCTAAGG > GCCGGGTGGGGCGTGGGAGCGGAGGACAAGGCGGGAGCCGGGAGGCGGGAGGGTCGGG > GTTCTTTCTCCACCGGGGTCGCCCTCAGCCGGGCCTGCCGCCCTGGGCCGTGGCACAT > GGGGAGGGAAGCGCGCGGCTTCGGGGTCTGGGGCTCTCGCGCCCACTAACGGTGCCCG > GAGCCGCCCGCCAGTGCGCAAGCGCCGCCCCGCCCCCCGCCCCATCCCCCACCCCGGG > GTCGACGGCGACAGAGAGTCGTGGGCGCGGTCCGCCAGTCTGCCTAGAGCGGCCAGCC > CTC! > CCCCTCCCTCCTCACCGCCCCGGACCGCGCACCGGAAGCAGAAGCTAGGCT g> > articleName="Description">ENSG00000160087:NCBI35:1:1249158 > :1251157:-1 > > > > namespace='ENSEMBL' id='ENSG00000160182'> > articleName="Length">2000 > articleName="SequenceString">GGACTTGAGCATTTGTGGATTTTGGCATC > CCTGGGTGGGGGGTCCTGAAACCAGTCCCCCAGGGGTACTAAGGGACGACTGCATTGT > ATTTTAAGTTCATTTTCCCTTTCCCTGGTTAATGAATATTTATTTTGCTTTTCTTTCC > CTCCTTTCCTTCCTTCCTTCTTTCCCTGTTTCCAGCTGTTACAAACAATGCTAAAAAG > AATATCTTTGCCTGTGTTTTCTTCTGCCCAAGTATGAACATGTTTCTGGGATTAAGAG > ACCAGGCCTGGAAACAGAAGAATTTGCTGAGCTGTAAAATCTGTATGGCTTAAACCTC > ACCGAACACTGCCCACCTTTTCTCCAAATGATTGTGCAATTTACATCCCATTTCCAAG > AGCCCCCATTTTGATCCGAGAAATTAGAGCAGCGAAAACCACCGTCACTATGAGCACC > ACCCTGGGCCTGGTGCCCCCGTCCTGTTTTCAATAAACTTAAGCTGACCACAGAGGAC > ACCAGGCCTCGGCCCCTCCCTGGGTCCTGCGGTCAGGCCCCTCCTGGAGACCCTGGCC > CAGGAGTGGAGACCCCGGTGCAGGAGTGGCAGCCCTGGAGGAGGGGCTGGGTCCTGGG > ATGGAGCGAAGAGGAACATGGCCGCCCCCATTCTGGCCCAGGCTCCCCTCCCAGAGGG > GCTGCAGAAATGTACTGACTAGGTCACCCAAGAAAAGATAGTACCTTTGTTAGGCTAG > CATGCATTTTCCTCAGGGCCTAATTTCTCACTGAAGAAGAAAAGATTTCTCCTGTTGT > CCATTTCTTCATGCAGCTCTTCAACAGCTGTTTCTCGAATGCCAATCAAAGCCACTGT > TCTAGGGTCTGGGGCCACCTCAAGGCACTAGGAGATGAGGACTTCTGCTCCCATGCGC > CCTCCCGTCTGCTGCAGGGAGGAGTGCAATGAATAAATAACCAACATAATGTGTCAGT > CAC! > TTGTTTTATCCACCAGGAGGTAATAAGAGCTATGAAAGAGAAAGCTCCGAGCAGGGGA > GGGGAGTGAGGCATGGTACAGGAGAGCAGGAGGCTGTCCTCTAAAATACAGGAGTCCA > GGGGACCAACTGGGAAGGTGTGGGAGGGGGAGGGAGGGAGCCCCATAGACACAGGGGA > GTGAACCACGTTCACTTTGTCAGTTTTTGATGGCAGCTCGTATATACTATTTTTTTCT > CCCTCCTGCCCCCAGCCCCTCCCAGAAGGAGACTTAATCTGTCGCTCAGGCTGGAGTG > CAGTAGGGTGATCTCGACTCACTGCAACCTCCGCCTCCCAGGTTCAAGTGATTCTCCT > GACTTAACCTCCAGAGTAGCTAGGATTACAGGCACCCGCCACCATGCCTGGCTAATTT > TTGTATTTTTTTTTTTTGTAGAGACGGGGTTTCGCCATGTTGGCCAGGCTAGTCTCAA > ACTCCTGACTTTAAGTGATCCGCCTGCTTTGGCCTCCCAAAGTGTTGGGATTACAGGC > GTGAGCCACTGCGCCAGGCCTACAATTTCATTATTAAAACAATTCCACTGTAAAAGAA > TTAGCTTAGGCCTAGACGGAATGGGCTTCATGAGCTCCTTCCCTTCCCCCTGCAAGGT > CACGGTGGCCACCCCGTGAGCCACTGTTGTCACGGCCAAGCCTTTTTCCGGCCATCTC > TCACTATGAATCACTTCTGCAGTGAGTACAGTATTTACCCTGGCGGGAGGGCCTCTCA > GATATGAGTAGGACCTGGATTAAGGTCAGGTTGGAGGAGACTCCCATGGGAAAGAGGG > ACTTTCTGAATCTCAGATCCCTCAGCCAAGATGACCTCACCACATGTCGTCTCTGTCT > ATCAGCAAATCCTTCCATGTAGCTTGACCATGTCTAGGAAACACCTTTGATAAAAATC > AGTGGAGATTATTGTCTCAGAGGATCCCCGGGCCTCCTTAGGCAAATGTTATCTAACG > CTC! > TTTAAGCAAACAGAGCCTGCCCTATAAAATCCGGGGCTCGGGCGGCCTCTC g> > articleName="Description">ENSG00000160182:NCBI35:21:426597 > 14:42661713:-1 > > > > > > > > but you're right taverna displays a list of two simple > DNASequence > objects, so i don't understand what i am doing wrong ? > > cheers, > Arnaud > > Edward Kawas wrote: > > >Hi, > > > >The problem is on the side of the service provider: > > > >They advertise a collection as the output, yet this is > the > >output: > > > > > > > > > > > > > > > > namespace="ENSEMBL" > >id="ENSG00000079459"> > > xmlns="http://www.biomoby.org/moby" > >namespace="" id="" articleName="Length"> > >2000 > > > > >namespace="" id="" articleName="SequenceString"> > >TGAATAAAGTTTGCTTCTAAGAGAAGTTACTATTTATTCCTAATTAAATGGGGAGGA > AAG > >TCTTTGAAGAGGAACCTCTACTTTACTTTTTATACCGTCATGGCTGGAAACTAAGTT > TTT > >AAGATTTTTCTGGGGTTCCCTTGGCCGAGGTGGGGAGTGGGAGGGCTGTCCAGTGGT > AGG > >GACTTAGGATTTTTAGTTTACAGTAGTAGGGGAAACACTCTGTAATCTAATACATAA > GTA > >AATGATGTATTAGAATATGGTAAATATAGGCAAGTAGACCCCCACTGGGATTAGCAG > TGG > >TGGAAATGTGAGAGAGGGCAAACAGGTGGGTCTAGATGAGGTGTGAGCAGACTCGAG > GGG > >CACAGGAGTTAGTCAAGCCAGTATCTGGGGGATAGTGCAGGAATAGTGAACAGCTAG > ACA > >AAAAGTCCTAGGGCCAGAGAAAGCAAAAGCATAAGAGATGGAGGCCAGAGAGGTAAT > CTG > >GGTGGAAGGCTGCAGCCTCTCAGGATCCCTATAGGTGCTTTGGCTTTTGTTGGAGAG > ACA > >CTGAACAGCTTTGGGCAGTGAACGTACCTGACAGGTTTCCTGTTTGTTTTTGAGATG > AAG > >TCTCGCTCTTGTCCCCCAGGCTGGAGTGCAATAGCGCGATCTCAGCTCACTGCAACC > TCT > >GCCTCCTGTGTTCAAGCGATTCTCCTGCCTCAGCCTCCCAGGTAGCTGGGATTATAG > GCG > >CCTGCCACCATGCCTGGCTAATTTTTGTATTTTTAGTAGAGACGCAGTTTCAGCATG > TTG > >GCCAGGCTGGTCTTGAACTCCAGACCTCAGGTGATCCGCCCGCCTTGGCCTCCCAAA > GTG > >CTGGGATTACAGGCATGAGCCACCGCGCTCGGCTAGACCTGACAGGTTTTAAAAGGA > TTA > >CTGGTTGCTGTGTTAAAACAGACTGCAGGATGGCTTAGGTAGCCAGTAGGTTTTTTT > TTT > >TTTTTGGAGACGTAGTCTTGCTCTGTTGGCCTGGCTGGAGTGCAGCGGTGTCATCTT > GGC > >TCACTGCAAACTCCGCTTCCCGGGTTCAAGTGATTCTCCTGCCTCAGCCTCCGGAGT > AGT > >TGGGACTACAGGCGCCCACCACCACACTCGGCTTTTTTGTATTTTTAGTAGAGACGG > GTT > >TCACCATGTTGGCCAGGATGGTCTCGATCTCTTGACCTCGTGATCCACCCGCCTTGG > CCT > >CCCAAAGTGTTGCGATTACAGGCGTGAGCCACCACGCCTGGACGGGTAGCCAGTAGT > TTC > >TAGGGCTGGAGAGATCTAGGATGAGAGAAGTTTCCACATTCCTGTTACAGGCTCTCT > AAG > >GCTTCAGCTCCTTTTTCTAGGACTAAGCTGGATCTCAAGTAAACACTAGAGAGGGGG > CAG > >CTGAAGCTCCAGGAGTGTGTGGGGCTCCCTGGGGCTGGATGGCGGTGGCGGGCAGGC > GAG > >CTGGGCTGTGCTCGGGTGTGTTACAGTAAAGACGCCCAGCTTGGCGCTGGCCCGGCC > TTT > >TCACGGTTTTAGGCTCTACAGAGAGCGGCTGCAGAGCTCACCCGGCTGGCAGGAGCC > ACC > >GAGGCCGGACACGTGGGCGACTTATTGACCAAGTGGGGAGGAAGCAGCCCCGCACTG > CTC > >TCCCGACTGCGGACCACCGTTGGGCTCCTGCGCATCCTAAGCCCCACCGCCTCACCT > CCA > >GTCCCCACAGCGTTCGCGCTCCCAGCCGGGGTAAGCGGAAGAAAACAAAGGCCCGGC > TCC > >ATCAGGGCACCAATCCCGCTCGTCGGCCTCTTTCTCGGCCTCCAATGAGCTTCTAGA > GTG > >TTATCACGCCAGTCTCCTTCCGCGACTGATTGGCCGGGGTCTTCCTAGTGTGAGCGG > CCC > >TGGCCAATCAGCGCCCGTCAGCCCACCCCACGAGGCCGCAGCTAGCCCCGCTGGCGG > CCG > >AGGCCGGTTGAAGTGGGCGGAGCGGCGGGCGGGGCGTCGCCGTACTAGGCCTGCCCC > CTG > >TCCGGCCAGCCCCTCGAAGC > > > > >namespace="" id="" articleName="Description"> > >2222:NCBI35:8:11695664:11697663:1 > > > > > > > > > > > > > > > >Not a collection. > > > >If you are the service provider, you must ensure that you > >output what you state that you will. > > > >Hope this helps, > > > >Eddie > > > > > > > >>-----Original Message----- > >>From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > >>dev-bounces at portal.open-bio.org] On Behalf Of Mark > >>Wilkinson > >>Sent: Friday, November 04, 2005 8:06 AM > >>To: Arnaud Kerhornou; Core developer announcements > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby > service > >>that takes aninput collection > >> > >>I'll address the first part... > >> > >> > >> > >> > >> > >>><------------------------------------ > >>> > >>>Does it mean the registration has failed ? > >>> > >>> > >>You need to check the return value of your registration > >>attempt - a > >>small XML object is returned to you that contans (among > >>other things - > >>see the API) a boolean 1/0 as to success or failure of > >>your > >>registration. > >> > >>Your registration was successful (I just checked the > >>database). The > >>client-side problem is a new one for me. I'll try to > >>duplicate it here > >>later. > >> > >>The Taverna problem I will leave to Eddie to answer > >>(though I think I > >>know what the answer is) > >> > >>M > >> > >> > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://www.biomoby.org/mailman/listinfo/moby-dev > >> > >> > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From Pieter.Neerincx at wur.nl Fri Nov 4 21:41:50 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 4 Nov 2005 22:41:50 +0100 Subject: [moby] [MOBY-dev] Perl API: retrieveObjectDefinition call In-Reply-To: <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> Message-ID: <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> On 02Nov2005, at 17:12, Mark Wilkinson wrote: > I think you're right - that's a much better data structure to be > passing > around. > > This does change the external (perl client) API, right? :-/ Yep, that's why I'm asking. I have no idea who is currently relying on the retrieveObjectDefinition call and what might break if I change it... So far I have heard no complaints, so I suggest I go ahead and make the change... > > Really, what the Perl client code needs is a good laundering. The > CommonSubs.pm module is a total mess after being modified piecemeal > over > the past 3 years... > > I wonder if we shouldn't just start a new module (or modules) that are > named by their domain of function (RegistryIO, OntologyIO, or > something > like that) and have all fresh code? Gradually we could migrate all > functionality into these modules. Client::Central has been around > since > the 0.1 prototype of MOBY in 2001 and has never been re-written top- > to- > bottom! That would be a good idea to get cleaner code, but for the time being it's not that bad! It works as advertised and gets my job done :). Try debugging SOAP::Lite and MIME::Parser... those are the ones that really need a complete make-over! > > I'm still waiting to hear about the re-funding attempts for MOBY... > fingers crossed! There will hopefully be a second opportunity > later in > the winter, so all is not lost if we fail. Good luck! Pieter > It would be great to have a > couple of extra hands dedicated to a complete code re-write > > M > > > > > On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: >> Hi all, >> >> Here is a question for those using the Perl API. In >> >> MOBY/Client/Central.pm >> >> we have a >> >> sub retrieveObjectDefinition >> >> which calls >> >> sub _ObjectDefinitionPayload { >> >> This produces an array for the objects, articleNames and lsids for >> the relationships of the object whose definition is requested. I'm >> wondering why this is an array. Currently I have to rely on the order >> of elements in this array to figure out which element is the object, >> which one is articleName, etc. These are the lines producing the >> array: >> >> 553 push @{ $relationships{$relationshipType} }, >> 554 [ $_->toString, $article, $rlsid ]; >> >> Is there any reason why this should be an array? I'd rather not have >> to rely on the order of the elements, so are there people who have >> any objections when I change this into a hash like in: >> >> push @{ $relationships{$relationshipType} }, >> { object => $_->toString, >> articleName => $article, >> lsid => $rlsid }; >> >> Cheers, >> >> Pieter >> >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 Sat Nov 5 09:03:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 5 Nov 2005 09:03:10 +0000 (GMT) Subject: [MOBY-dev] Biomoby registry down? Message-ID: ...or it just not reachable from here at IRRI now? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Sat Nov 5 11:56:27 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Sat, 5 Nov 2005 12:56:27 +0100 Subject: [MOBY-dev] Biomoby registry down? In-Reply-To: References: Message-ID: <9E523DCF-FFF4-4460-936D-D9A7841934AA@wur.nl> I get connection time-outs as well at WUR, so it looks like it's down :(. Pieter On 05Nov2005, at 10:03, Martin Senger wrote: > ...or it just not reachable from here at IRRI now? > > Thanks, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 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 Phillip.Lord at newcastle.ac.uk Fri Nov 4 15:26:48 2005 From: Phillip.Lord at newcastle.ac.uk (Phillip Lord) Date: Fri, 4 Nov 2005 15:26:48 -0000 Subject: [MOBY-dev] Please sir, can I have some more RDF? Message-ID: <6942EE35B530F84EAD432959F5E4DAB581BF67@largo.campus.ncl.ac.uk> Mark Wilkinson wrote: >> We're sending it to Pinar today along with the changes that are >> required in the myGrid ontology to make it compatible (i.e. things >> that we think are wrong in the myGrid ontology... cheeky buggers that >> we are!). > > Of course, our suggestions may be complete rubbish... (sorry myGrid > folks - the message about sounded MUCH funnier in my head than it > came out on paper! :-) ) I thought it was funny on paper. Besides which, it's true. There are things wrong with the mygrid ontology! Phil From akerhornou at imim.es Mon Nov 7 15:37:59 2005 From: akerhornou at imim.es (Arnaud Kerhornou) Date: Mon, 07 Nov 2005 16:37:59 +0100 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> Message-ID: <436F74D7.1010809@imim.es> Edward Kawas wrote: >Hi, > >This is happening, because Taverna is expecting an object >type of DNASequence, yet CommentedDNASequence is being >passed in. > > > okay, maybe i should have asked this before, the service returns CommentedDNASequence objects, and the service specs say DNASequence objects, but CommentedDNASequence is-a DNASequence. I designed the service to return DNASequence objects. Then a user asked me to add a description foreach sequence the service returns, so i just changed the type of object the service returns to CommentedDNASequence and I didn't changed the specification of the service because i thought i didn't have to. Does it mean it is not allowed to do so ? I have a similar problem with the next service in my workflow. This service analyzes DNASequence objects. But i get CommentedDNASequence objects from the retrieval service. Again i can not do that ? Arnaud >Eddie > > > >>-----Original Message----- >>From: Arnaud Kerhornou [mailto:akerhornou at imim.es] >>Sent: Monday, November 07, 2005 6:47 AM >>To: Edward Kawas >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service >>that takes an input collection >> >>ok, so i could modify my workflow to connect the >>DNASequence >>(Collection) output port to the input port of the next >>node. >> >>but why, in the case i use the port that says collection, >>do i get an >>empty collection tag, >> >>* "DNASequence (Collection)" gives me: >> >> >> >> >> > moby:articleName="upstream_sequences" /> >> >> >> >> >>why are the simples missing ? >> >>Arnaud >> >> >> >> > > From markw at illuminae.com Mon Nov 7 15:55:37 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 07 Nov 2005 07:55:37 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436F74D7.1010809@imim.es> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> <436F74D7.1010809@imim.es> Message-ID: <1131378937.15487.22.camel@bioinfo.icapture.ubc.ca> Strictly speaking, so long as you return an object that is an ISA child of what you have registered, you are compliant with the API. Having said that, if you *always* return a CommentedDNASequence, then you should probably re-register your service, since the intention is to register the most complex object type that you can guarantee to return in every case. Either way, you are API compliant, so if this is what is causing the problem, then it is a bug at our end. M On Mon, 2005-11-07 at 16:37 +0100, Arnaud Kerhornou wrote: > > Edward Kawas wrote: > > >Hi, > > > >This is happening, because Taverna is expecting an object > >type of DNASequence, yet CommentedDNASequence is being > >passed in. > > > > > > > okay, maybe i should have asked this before, the service returns > CommentedDNASequence objects, and the service specs say DNASequence > objects, but CommentedDNASequence is-a DNASequence. > > I designed the service to return DNASequence objects. Then a user asked > me to add a description foreach sequence the service returns, so i just > changed the type of object the service returns to CommentedDNASequence > and I didn't changed the specification of the service because i thought > i didn't have to. > > Does it mean it is not allowed to do so ? > > I have a similar problem with the next service in my workflow. This > service analyzes DNASequence objects. But i get CommentedDNASequence > objects from the retrieval service. Again i can not do that ? > > Arnaud > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Arnaud Kerhornou [mailto:akerhornou at imim.es] > >>Sent: Monday, November 07, 2005 6:47 AM > >>To: Edward Kawas > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service > >>that takes an input collection > >> > >>ok, so i could modify my workflow to connect the > >>DNASequence > >>(Collection) output port to the input port of the next > >>node. > >> > >>but why, in the case i use the port that says collection, > >>do i get an > >>empty collection tag, > >> > >>* "DNASequence (Collection)" gives me: > >> > >> > >> > >> > >> >> moby:articleName="upstream_sequences" /> > >> > >> > >> > >> > >>why are the simples missing ? > >> > >>Arnaud > >> > >> > >> > >> > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Nov 7 15:55:37 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 07 Nov 2005 07:55:37 -0800 Subject: [moby] [MOBY-dev] Registrying a moby service that takes an input collection In-Reply-To: <436F74D7.1010809@imim.es> References: <001701c5e3ac$fc2bb4d0$6600a8c0@notebook> <436F74D7.1010809@imim.es> Message-ID: <1131378937.15487.22.camel@bioinfo.icapture.ubc.ca> Strictly speaking, so long as you return an object that is an ISA child of what you have registered, you are compliant with the API. Having said that, if you *always* return a CommentedDNASequence, then you should probably re-register your service, since the intention is to register the most complex object type that you can guarantee to return in every case. Either way, you are API compliant, so if this is what is causing the problem, then it is a bug at our end. M On Mon, 2005-11-07 at 16:37 +0100, Arnaud Kerhornou wrote: > > Edward Kawas wrote: > > >Hi, > > > >This is happening, because Taverna is expecting an object > >type of DNASequence, yet CommentedDNASequence is being > >passed in. > > > > > > > okay, maybe i should have asked this before, the service returns > CommentedDNASequence objects, and the service specs say DNASequence > objects, but CommentedDNASequence is-a DNASequence. > > I designed the service to return DNASequence objects. Then a user asked > me to add a description foreach sequence the service returns, so i just > changed the type of object the service returns to CommentedDNASequence > and I didn't changed the specification of the service because i thought > i didn't have to. > > Does it mean it is not allowed to do so ? > > I have a similar problem with the next service in my workflow. This > service analyzes DNASequence objects. But i get CommentedDNASequence > objects from the retrieval service. Again i can not do that ? > > Arnaud > > >Eddie > > > > > > > >>-----Original Message----- > >>From: Arnaud Kerhornou [mailto:akerhornou at imim.es] > >>Sent: Monday, November 07, 2005 6:47 AM > >>To: Edward Kawas > >>Subject: Re: [moby] [MOBY-dev] Registrying a moby service > >>that takes an input collection > >> > >>ok, so i could modify my workflow to connect the > >>DNASequence > >>(Collection) output port to the input port of the next > >>node. > >> > >>but why, in the case i use the port that says collection, > >>do i get an > >>empty collection tag, > >> > >>* "DNASequence (Collection)" gives me: > >> > >> > >> > >> > >> >> moby:articleName="upstream_sequences" /> > >> > >> > >> > >> > >>why are the simples missing ? > >> > >>Arnaud > >> > >> > >> > >> > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Mon Nov 7 16:04:45 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 07 Nov 2005 08:04:45 -0800 Subject: [MOBY-dev] starting website redirect... Message-ID: <1131379485.15487.29.camel@bioinfo.icapture.ubc.ca> Hi MOBYers, I'm soon going to start re-directing HTTP traffic to the new website by default. This will give us the chance to port-over anything from the old site that we might have forgotten before it disappears. If there are things on the old site that you want/need, please grab them, or let me know and I'll grab them. Cheers! M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Mon Nov 7 16:13:13 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 7 Nov 2005 16:13:13 +0000 (GMT) Subject: [MOBY-dev] starting website redirect... In-Reply-To: <1131379485.15487.29.camel@bioinfo.icapture.ubc.ca> Message-ID: > I'm soon going to start re-directing HTTP traffic to the new website by > default. This will give us the chance to port-over anything from the > old site that we might have forgotten before it disappears. > I lost the track... My feeling was that we are making a better web page. But now it seems that *in the same time* we are also changing a physical server. Is that correct? Is it also true that after moving to the new server, the new server will get (back) the old URL biomoby.org? > If there are things on the old site that you want/need, please grab > them, or let me know and I'll grab them. > With whom should I talked to give me enought priviledges to make the same what is cronning now for jMoby? And what time schedule for this should I plan? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Nov 7 23:42:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 7 Nov 2005 23:42:10 +0000 (GMT) Subject: [MOBY-dev] jMoby (AGAIN!) not compilable Message-ID: Please, correct it asap - whoever committed file ServiceDescrParser.java. Nobody can work if this happens. Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Nov 9 22:10:19 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 9 Nov 2005 14:10:19 -0800 Subject: [MOBY-dev] rdf agent Message-ID: <003001c5e57a$604d32d0$6600a8c0@notebook> Hi, If anyone received any messages from the rdf agent, please disregard them! I was testing the agents ability to clone the registry and all services that were not (legal) may have caused the agent to send you a message. If you were affected, sorry about that. Sincerely, An extremely red in the face Eddie From markw at illuminae.com Wed Nov 9 23:07:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 09 Nov 2005 15:07:47 -0800 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <003001c5e57a$604d32d0$6600a8c0@notebook> References: <003001c5e57a$604d32d0$6600a8c0@notebook> Message-ID: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> They were all sent to me... thanks!!! ;-) M On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > Hi, > > If anyone received any messages from the rdf agent, please > disregard them! I was testing the agents ability to clone > the registry and all services that were not (legal) may have > caused the agent to send you a message. > > If you were affected, sorry about that. > > Sincerely, > > An extremely red in the face Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Wed Nov 9 23:07:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 09 Nov 2005 15:07:47 -0800 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <003001c5e57a$604d32d0$6600a8c0@notebook> References: <003001c5e57a$604d32d0$6600a8c0@notebook> Message-ID: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> They were all sent to me... thanks!!! ;-) M On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > Hi, > > If anyone received any messages from the rdf agent, please > disregard them! I was testing the agents ability to clone > the registry and all services that were not (legal) may have > caused the agent to send you a message. > > If you were affected, sorry about that. > > Sincerely, > > An extremely red in the face Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Thu Nov 10 00:26:26 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 10 Nov 2005 00:26:26 +0000 (GMT) Subject: [MOBY-dev] Moby registry down...? Message-ID: ...or just my corner-of-the-world network problem? Thanks for letting me know. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Nov 10 00:37:55 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 10 Nov 2005 00:37:55 +0000 (GMT) Subject: [MOBY-dev] Moby registry down...? In-Reply-To: Message-ID: Solved. Sorry to disturb you. Probablt just a small hiccup on our network. Works fine now. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Thu Nov 10 00:05:42 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 9 Nov 2005 16:05:42 -0800 Subject: [moby] [MOBY-dev] rdf agent In-Reply-To: <1131577667.22613.37.camel@bioinfo.icapture.ubc.ca> Message-ID: <003f01c5e58a$7eb3fe60$6600a8c0@notebook> Hi Mark, As an aside, there were over 320 services and about 174 made it (were legal). That has got to be good news! I think that the agent is good to go. I had to code the logic where a user submits a URL and the services are sucked into the registry. The only thing that I haven't done yet is add the rdf to the report. I will do this now and then try it out again (making sure that the email is sent to me ;-) ). Sounds like today may have been a good day after all! Eddie > -----Original Message----- > From: moby-dev-bounces at portal.open-bio.org [mailto:moby- > dev-bounces at portal.open-bio.org] On Behalf Of Mark > Wilkinson > Sent: Wednesday, November 09, 2005 3:08 PM > To: Core developer announcements > Cc: 'Moby Developers' > Subject: Re: [moby] [MOBY-dev] rdf agent > > They were all sent to me... > > thanks!!! ;-) > > M > > > On Wed, 2005-11-09 at 14:10 -0800, Edward Kawas wrote: > > Hi, > > > > If anyone received any messages from the rdf agent, > please > > disregard them! I was testing the agents ability to > clone > > the registry and all services that were not (legal) may > have > > caused the agent to send you a message. > > > > If you were affected, sorry about that. > > > > Sincerely, > > > > An extremely red in the face Eddie > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > "Ontologists do it with the edges!" > > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Sat Nov 12 13:15:05 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 12 Nov 2005 13:15:05 +0000 (GMT) Subject: [MOBY-dev] different types of results Message-ID: I wonder why moby register returned for two almost identical calls different result type: once a String, once an array of bytes: At the end of this message you will find two xml files, they differ only in the authority: senger at sherekhan:~/jMoby$ diff q1.xml q2.xml 11c11 < samples.jmoby.net --- > www.iris.irri.org 18d17 < When I call "findService" for authority samples.jmoby.net, I get results as a String. When I call it for www.iris.irri.org, I am getting it as an array of bytes. In both cases the contents of the reasult is correct but I wonder if this is the bug. Does it perhaps depend on the special unicode characters that are used in the services? (Not that I am awaee of any of those in these services.) I understand that biomoby services and clients are supposed to understand both String and byte arrays, but it was never (AFAIK) mentioned that also biomoby registry has this behaviour. I can fix it in jMoby (actually I am fixing it as I speak) but I think that such behaviour is not good. Any comment on that? Thanks, Martin q1.xml ------ moby samples.jmoby.net 1 1 0 q2.xml ------ moby www.iris.irri.org 1 1 0 -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Nov 12 21:38:51 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 12 Nov 2005 13:38:51 -0800 Subject: [MOBY-dev] different types of results In-Reply-To: References: Message-ID: <437660EB.9060604@illuminae.com> That's bizarre...??!? There is no reason for that to happen as far as I can tell. Both calls go through the same subroutine, and at least when they leave the MOBY Central code modules they are being returned as String's. I haven't had a chance to duplicate your result here (I'll try to get to that when I have finished what I am doing), but my first suspicon is that the SOAP::Lite library itself is somehow looking at the content of the document it is about to pass, and making the choice to send it one way or the other. Certainly the decision is not being made by MOBY code... I'll look into this more deeply later today. Hey Martin, we're almost in the same time-zone! Greetings from Sydney! Mark Martin Senger wrote: >I wonder why moby register returned for two almost identical calls >different result type: once a String, once an array of bytes: > >At the end of this message you will find two xml files, they differ only >in the authority: > >senger at sherekhan:~/jMoby$ diff q1.xml q2.xml >11c11 >< samples.jmoby.net >--- > > >>www.iris.irri.org >> >> >18d17 >< > >When I call "findService" for authority samples.jmoby.net, I get results >as a String. When I call it for www.iris.irri.org, I am getting it as an >array of bytes. > >In both cases the contents of the reasult is correct but I wonder if this >is the bug. Does it perhaps depend on the special unicode characters that >are used in the services? (Not that I am awaee of any of those in these >services.) > >I understand that biomoby services and clients are supposed to understand >both String and byte arrays, but it was never (AFAIK) mentioned that also >biomoby registry has this behaviour. I can fix it in jMoby (actually I am >fixing it as I speak) but I think that such behaviour is not good. Any >comment on that? > >Thanks, >Martin > >q1.xml >------ > > > > > > > > > >moby >samples.jmoby.net >1 >1 >0 > > > > >q2.xml >------ > > > > > > > > > >moby >www.iris.irri.org >1 >1 >0 > > > > > > > > From senger at ebi.ac.uk Sun Nov 13 03:25:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 13 Nov 2005 03:25:14 +0000 (GMT) Subject: [MOBY-dev] different types of results In-Reply-To: <437660EB.9060604@illuminae.com> Message-ID: Hi to Sydney (and to others, as well, of course), > That's bizarre...??!? > We exchanged emails with Eddie about it yesterday. It seems that we all, Mark including, concluded that SOAP::Lite is the "culprit". I said it in quotes because actually SOAP::Lite tries to help. I found that some of the IRRI services used some (probably) non-ascii characters in the description - and that fact probably triggered SOAP::Lite to switch to byte array. I think that it could be switched off (using something like: SOAP::Data->type (string => $result) but perhaps it is a good think to have there byte array. Anyway, I have fixed the jMoby library (CentralImpl.java) so it accepts now both types. Still it is an interesting thing... Cheers, Martin PS: I love Sydney - I wish you the best there, and be prepared when you go home: Eddie has for you a present from us, the Richard's Moby group here in Los Banos... (Don't worry, nothing nasty...). M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sun Nov 13 03:27:24 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 13 Nov 2005 03:27:24 +0000 GMT Subject: [MOBY-dev] different types of results Message-ID: <1749433976-1131852476-cardhu_blackberry.rim.net-23911-@engine19-cell01> I'm glad it wasn't me :-) M -----Original Message----- From: Martin Senger Date: Sun, 13 Nov 2005 03:25:14 To:Mark Wilkinson Cc:Moby Developers Subject: Re: [MOBY-dev] different types of results Hi to Sydney (and to others, as well, of course), > That's bizarre...??!? > We exchanged emails with Eddie about it yesterday. It seems that we all, Mark including, concluded that SOAP::Lite is the "culprit". I said it in quotes because actually SOAP::Lite tries to help. I found that some of the IRRI services used some (probably) non-ascii characters in the description - and that fact probably triggered SOAP::Lite to switch to byte array. I think that it could be switched off (using something like: SOAP::Data->type (string => $result) but perhaps it is a good think to have there byte array. Anyway, I have fixed the jMoby library (CentralImpl.java) so it accepts now both types. Still it is an interesting thing... Cheers, Martin PS: I love Sydney - I wish you the best there, and be prepared when you go home: Eddie has for you a present from us, the Richard's Moby group here in Los Banos... (Don't worry, nothing nasty...). M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From edward.kawas at gmail.com Mon Nov 14 19:00:22 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 14 Nov 2005 11:00:22 -0800 Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <1864146826-1131994113-cardhu_blackberry.rim.net-30532-@engine20-cell01> Message-ID: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Hi, Mark and I were talking about what we feel is the need to create a CommonSubs interface that would be implemented in both Java and Perl. Currently, CommonSubs.pm has the following methods: genericServiceInputParser complexServiceInputParser getArticles genericServiceInputParserAsObject getSimpleArticleIDs getSimpleArticleNamespaceURI simpleResponse collectionResponse responseHeader responseFooter getInputs getInputID getArticlesAsObjects getCollectedSimples getInputArticles isSimpleArticle isCollectionArticle isSecondaryArticle extractRawContent getNodeContentWithArticle validateNamespaces validateThisNamespace getResponseArticles (a.k.a. extractResponseArticles) getServiceNotes getCrossReferences whichDeepestParentObject _rearrange (stolen from BioPerl ;-) ) The subroutine descriptions can be found at http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html We need functions that will, among other things: 1) Get enumerated invocations from an incoming message 2) Add enumerated outputs to an outgoing message 3) Add an error message to the header 4) Read error messages from the header 5) Extract individual inputs from an invocation... ... etc So this is a call out to service providers to tell us what functions they believe would be useful to have (i.e. make their lives much easier). Thanks, Eddie From senger at ebi.ac.uk Mon Nov 14 23:52:23 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 14 Nov 2005 23:52:23 +0000 (GMT) Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: > Mark and I were talking about what we feel is the need to > create a CommonSubs interface that would be implemented in > both Java and Perl. > In Java, it is implemented already. Regarding Perl, I was rather thinking about having a Perl version of Moses (generator of Perl modules representing services), but it is not high priority in my calendar at the moment. But Moses was designed very modularly, so it should not be that hard to generated Perl code. If anyone is willing to try I am happy to help... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Tue Nov 15 09:15:02 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 15 Nov 2005 10:15:02 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: Hi Mark, I noticed that complexResponse is not listed in CommonSubs.html. I thought it might get created automatically from the comments/ descriptions in CommonSubs.pm..., but apparently it's not. Can I run some tool to recreate CommonSubs.html or do I have to add the description manually or...? Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but is in @EXPORT_OK", but it's not there either: our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); Without complexResponse it's no longer possible to send secondary articles back to a client :(. Cheers, Pieter On 14-Nov-2005, at 8:00 PM, Edward Kawas wrote: > Hi, > > Currently, CommonSubs.pm has the following methods: > > genericServiceInputParser > complexServiceInputParser > getArticles > genericServiceInputParserAsObject > getSimpleArticleIDs > getSimpleArticleNamespaceURI > simpleResponse > collectionResponse > responseHeader > responseFooter > getInputs > getInputID > getArticlesAsObjects > getCollectedSimples > getInputArticles > isSimpleArticle > isCollectionArticle > isSecondaryArticle > extractRawContent > getNodeContentWithArticle > validateNamespaces > validateThisNamespace > getResponseArticles (a.k.a. extractResponseArticles) > getServiceNotes > getCrossReferences > whichDeepestParentObject > _rearrange (stolen from BioPerl ;-) ) > > The subroutine descriptions can be found at > http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Tue Nov 15 11:12:24 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 15 Nov 2005 12:12:24 +0100 Subject: [MOBY-dev] CommonSubs -> creating a common Java and Perl interface In-Reply-To: <004401c5e94d$ab0c70c0$6600a8c0@notebook> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <505C05C8-65D7-45E6-AD7F-C96D65C3F946@wur.nl> Hi, On 14-Nov-2005, at 8:00 PM, Edward Kawas wrote: > Hi, > > Mark and I were talking about what we feel is the need to > create a CommonSubs interface that would be implemented in > both Java and Perl. Sounds like a good plan to me :). I'm not using the Python API, but wouldn't it be a good idea to do the same thing for Python as well then? > > Currently, CommonSubs.pm has the following methods: > > genericServiceInputParser > complexServiceInputParser > getArticles > genericServiceInputParserAsObject > getSimpleArticleIDs > getSimpleArticleNamespaceURI > simpleResponse > collectionResponse > responseHeader > responseFooter > getInputs > getInputID > getArticlesAsObjects > getCollectedSimples > getInputArticles > isSimpleArticle > isCollectionArticle > isSecondaryArticle > extractRawContent > getNodeContentWithArticle > validateNamespaces > validateThisNamespace > getResponseArticles (a.k.a. extractResponseArticles) > getServiceNotes > getCrossReferences > whichDeepestParentObject > _rearrange (stolen from BioPerl ;-) ) > > The subroutine descriptions can be found at > http://biomoby.org/moby-live/Perl/MOBY/CommonSubs.html > > We need functions that will, among other things: > > 1) Get enumerated invocations from an incoming > message > > 2) Add enumerated outputs to an outgoing message Currently (in Perl) we have 3 *ServiceInputParser functions and another 3 *Response functions. To keeps things simple I would rather like to see just 1 serviceInputParser and 1 serviceResponse function. The current complex* functions are not that hard to use :), the other ones are just crippled and don't support the complete BioMOBY specs. > 3) Add an error message to the header > > 4) Read error messages from the header Do you mean the SOAP header? In that case it would be good also to think of functions to handle errors in the ServiceNotes part. So far I have only seen votes in favour of RFC 1863 :). > > 5) Extract individual inputs from an invocation... > > ... The rest of what I need is already there :). My only problem with the current functions is that it doesn't work well for large objects due to DOM parsing. I know it's not going to be easy to change to stream or chunk based parsing, but if it would be possible to improve the scalability it would make my life even easier :). Just my 0.02 ?, Pieter > > etc > > So this is a call out to service providers to tell us what > functions they believe would be useful to have (i.e. make > their lives much easier). > > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From francis_gibbons at hms.harvard.edu Wed Nov 16 14:49:17 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 16 Nov 2005 09:49:17 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> Hi Pieter, >Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. >There is a comment "complexResponse is *not* here, but >is in @EXPORT_OK", but it's not there either: >our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); > >Without complexResponse it's no longer possible to send secondary >articles back to a client :(. I'm the one who put that comment in there. The code had two long lists containing almost the same things, but as you see, there was one component which was lacking. I guess I mistyped the name, putting "collectionResponse" instead of "complexResponse". My bad! One reason for the confusion is that as I was writing the unit tests, I just couldn't figure out what the purpose of complexResponse was, how it was different from collectionResponse. Now that I look at it again, it seems not so puzzling (I guess I was fairly punchy after writing so many tests), but it would help a great deal to have someone who actually uses write an explanation of why it's useful. CommonSubs contains lots of routines that appear almost identical in their functionality, yet are subtly different (for example, pulling out parts of the moby:MOBY message at different levels). We need good explanations for why it is useful to do each of these. How about this: I've fixed that line defining EXPORT_OK, and checked it back in. Could you add some useful explanation of complexReponse's purpose and usage to the POD? I'm thinking specifics - the current text is way too generic (e.g., "function: wraps articles in the appropriate (mobyData) structure") We also need an example showing what exactly this routine should do, so that we can add it to the test suite. If you want to just send me an example, I can construct the test. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From francis_gibbons at hms.harvard.edu Wed Nov 16 14:54:32 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 16 Nov 2005 09:54:32 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> Message-ID: <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> Of course, I should also have asked why complexResponse was singled out in this way - why is it NOT in @EXPORT? Just a typo/omission? -Frank At 04:15 AM 11/15/2005, you wrote: >Hi Mark, > >I noticed that complexResponse is not listed in CommonSubs.html. I >thought it might get created automatically from the comments/ descriptions >in CommonSubs.pm..., but apparently it's not. Can I run >some tool to recreate CommonSubs.html or do I have to add the >description manually or...? > >Furthermore in CommonSubs.pm complexResponse is gone from '% EXPORT_TAGS'. >There is a comment "complexResponse is *not* here, but >is in @EXPORT_OK", but it's not there either: >our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); > >Without complexResponse it's no longer possible to send secondary >articles back to a client :(. >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Wed Nov 16 22:38:44 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 16 Nov 2005 23:38:44 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> Message-ID: <46FF29A8-FD3C-4EF6-AFDC-FECE0919553A@wur.nl> Hi Frank, On 16Nov2005, at 15:49, Frank Gibbons wrote: > Hi Pieter, > >> Furthermore in CommonSubs.pm complexResponse is gone from '% >> EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but >> is in @EXPORT_OK", but it's not there either: >> our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); >> >> Without complexResponse it's no longer possible to send secondary >> articles back to a client :(. > > I'm the one who put that comment in there. The code had two long > lists containing almost the same things, but as you see, there was > one component which was lacking. I guess I mistyped the name, > putting "collectionResponse" instead of "complexResponse". My bad! > > One reason for the confusion is that as I was writing the unit > tests, I just couldn't figure out what the purpose of > complexResponse was, how it was different from collectionResponse. > Now that I look at it again, it seems not so puzzling (I guess I > was fairly punchy after writing so many tests), but it would help a > great deal to have someone who actually uses write an explanation > of why it's useful. CommonSubs contains lots of routines that > appear almost identical in their functionality, yet are subtly > different (for example, pulling out parts of the moby:MOBY message > at different levels). We need good explanations for why it is > useful to do each of these. > > How about this: I've fixed that line defining EXPORT_OK, and > checked it back in. Thanks! > Could you add some useful explanation of complexReponse's purpose > and usage to the POD? I'm thinking specifics - the current text is > way too generic (e.g., "function: wraps articles in the appropriate > (mobyData) structure") Ok I'll add that. > We also need an example showing what exactly this routine should > do, so that we can add it to the test suite. If you want to just > send me an example, I can construct the test. I'll send you an example too... Cheers, Pi > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev 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 Nov 16 22:42:47 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 16 Nov 2005 23:42:47 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> References: <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116095304.011fee60@email.med.harvard.edu> Message-ID: <0F7F19F4-5401-4FD1-9518-FCAFC225559C@wur.nl> On 16Nov2005, at 15:54, Frank Gibbons wrote: > Of course, I should also have asked why complexResponse was singled > out in this way - why is it NOT in @EXPORT? Just a typo/omission? That was puzzling me too. I think I put it there... at least I should have! I'll put it there now. If someone deliberately removed for whatever reason, please let me know. Pieter > -Frank > > At 04:15 AM 11/15/2005, you wrote: >> Hi Mark, >> >> I noticed that complexResponse is not listed in CommonSubs.html. I >> thought it might get created automatically from the comments/ >> descriptions in CommonSubs.pm..., but apparently it's not. Can I run >> some tool to recreate CommonSubs.html or do I have to add the >> description manually or...? >> >> Furthermore in CommonSubs.pm complexResponse is gone from '% >> EXPORT_TAGS'. There is a comment "complexResponse is *not* here, but >> is in @EXPORT_OK", but it's not there either: >> our @EXPORT_OK = ("collectionResponse", @{$EXPORT_TAGS{'all'}}); >> >> Without complexResponse it's no longer possible to send secondary >> articles back to a client :(. >> http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 http:// > llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Mon Nov 14 17:18:23 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 14 Nov 2005 09:18:23 -0800 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object Message-ID: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Hi, I was unable to find a method that parses xml similar to the registerService (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY -S_API/XMLPayloads.html) xml and returns a MobyService object. I did notice the method in CentralImpl called extractServices(string) but the it parses a different message structure than the registerService xml. Does anyone know of a method that does what I need? Thanks, Eddie From gordonp at ucalgary.ca Fri Nov 18 18:13:06 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 18 Nov 2005 11:13:06 -0700 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <002701c5e93f$6c3b3c40$6600a8c0@notebook> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Message-ID: <437E19B2.4050505@ucalgary.ca> > CentralImpl.findService CentralImpl.findService() obviously parses the XML at some point to give you the service object. Ah, yes. MobyServices[] CentralImpl.extractServices(String) >I was unable to find a method that parses xml similar to the >registerService >(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >-S_API/XMLPayloads.html) xml and returns a MobyService >object. > >I did notice the method in CentralImpl called >extractServices(string) but the it parses a different >message structure than the registerService xml. > >Does anyone know of a method that does what I need? > >Thanks, > >Eddie > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From gordonp at ucalgary.ca Fri Nov 18 19:53:44 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 18 Nov 2005 12:53:44 -0700 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E19B2.4050505@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> Message-ID: <437E3148.9070105@ucalgary.ca> I am stupid. Time to go home for the weekend. :-) I don't think the method you are looking for exists in Java yet. > > > CentralImpl.findService() obviously parses the XML at some point to > give you the service object. > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > >> I was unable to find a method that parses xml similar to the >> registerService >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >> -S_API/XMLPayloads.html) xml and returns a MobyService >> object. >> >> I did notice the method in CentralImpl called >> extractServices(string) but the it parses a different >> message structure than the registerService xml. >> >> Does anyone know of a method that does what I need? >> >> Thanks, >> >> Eddie >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Fri Nov 18 19:09:18 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 18 Nov 2005 11:09:18 -0800 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E19B2.4050505@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> Message-ID: Hi Paul, I did notice the method in CentralImpl called extractServices(string) but the it parses a different message structure than the registerService xml. Do you know of any others? Thanks, Eddie On 11/18/05, Paul Gordon wrote: > > > CentralImpl.findService > > > CentralImpl.findService() obviously parses the XML at some point to give > you the service object. > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > > >I was unable to find a method that parses xml similar to the > >registerService > >(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY > >-S_API/XMLPayloads.html) xml and returns a MobyService > >object. > > > >I did notice the method in CentralImpl called > >extractServices(string) but the it parses a different > >message structure than the registerService xml. > > > >Does anyone know of a method that does what I need? > > > >Thanks, > > > >Eddie > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From edward.kawas at gmail.com Fri Nov 18 19:56:21 2005 From: edward.kawas at gmail.com (Eddie Kawas) Date: Fri, 18 Nov 2005 11:56:21 -0800 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E3148.9070105@ucalgary.ca> References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> <437E3148.9070105@ucalgary.ca> Message-ID: Do you think that it is a useful method for me to create? I have my own use for it, but do you think that others would find it useful? Thanks, Eddie On 11/18/05, Paul Gordon wrote: > > I am stupid. Time to go home for the weekend. :-) > I don't think the method you are looking for exists in Java yet. > > > > > > > CentralImpl.findService() obviously parses the XML at some point to > > give you the service object. > > Ah, yes. MobyServices[] CentralImpl.extractServices(String) > > > >> I was unable to find a method that parses xml similar to the > >> registerService > >> (http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY > >> -S_API/XMLPayloads.html) xml and returns a MobyService > >> object. > >> > >> I did notice the method in CentralImpl called > >> extractServices(string) but the it parses a different > >> message structure than the registerService xml. > >> > >> Does anyone know of a method that does what I need? > >> > >> Thanks, > >> > >> Eddie > >> > >> _______________________________________________ > >> MOBY-dev mailing list > >> MOBY-dev at biomoby.org > >> http://www.biomoby.org/mailman/listinfo/moby-dev > >> > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From gordonp at ucalgary.ca Fri Nov 18 20:29:44 2005 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 18 Nov 2005 13:29:44 -0700 Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: References: <002701c5e93f$6c3b3c40$6600a8c0@notebook> <437E19B2.4050505@ucalgary.ca> <437E3148.9070105@ucalgary.ca> Message-ID: <437E39B8.3020108@ucalgary.ca> If some one wants to implement moby central in Java, this would be very handy. To prepare for that eventuality, perhaps you could write this as a static method in a new server utility class, say org.biomoby.registry.requestParser or something of the like. >Do you think that it is a useful method for me to create? I have my own use >for it, but do you think that others would find it useful? > Thanks, > Eddie > > On 11/18/05, Paul Gordon wrote: > > >>I am stupid. Time to go home for the weekend. :-) >>I don't think the method you are looking for exists in Java yet. >> >> >> >>>CentralImpl.findService() obviously parses the XML at some point to >>>give you the service object. >>>Ah, yes. MobyServices[] CentralImpl.extractServices(String) >>> >>> >>> >>>>I was unable to find a method that parses xml similar to the >>>>registerService >>>>(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY >>>>-S_API/XMLPayloads.html) xml and returns a MobyService >>>>object. >>>> >>>>I did notice the method in CentralImpl called >>>>extractServices(string) but the it parses a different >>>>message structure than the registerService xml. >>>> >>>>Does anyone know of a method that does what I need? >>>> >>>>Thanks, >>>> >>>>Eddie >>>> >>>>_______________________________________________ >>>>MOBY-dev mailing list >>>>MOBY-dev at biomoby.org >>>>http://www.biomoby.org/mailman/listinfo/moby-dev >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>MOBY-dev mailing list >>>MOBY-dev at biomoby.org >>>http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > From senger at ebi.ac.uk Sat Nov 19 00:00:47 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 19 Nov 2005 00:00:47 +0000 (GMT) Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <002701c5e93f$6c3b3c40$6600a8c0@notebook> Message-ID: > I was unable to find a method that parses xml similar to the > registerService > jMoby does not contain stuff that is needed to write a biomoby register in Java; and the XML structure for 'registerService' is exactly that type of stuff: it has not use for clients, but only for server; if you are starting to add these things to jMoby, I suggest you create a new Java interface (e.g. Registry.java) in package org.biomoby.registry for that. But I am curious what you are working on that you need this... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Nov 19 00:03:10 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 19 Nov 2005 00:03:10 +0000 (GMT) Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: <437E39B8.3020108@ucalgary.ca> Message-ID: Interestingly I have read this Paul's answer only I have sent my own answer, and I am pleased that we came to almost identical suggestion :-) > If some one wants to implement moby central in Java, this would be very > handy. To prepare for that eventuality, perhaps you could write this as > a static method in a new server utility class, say > org.biomoby.registry.requestParser or something of the like. > Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Nov 19 00:23:14 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 19 Nov 2005 00:23:14 +0000 (GMT) Subject: [MOBY-dev] jMoby: method that parses service xml and returns MobyService object In-Reply-To: Message-ID: > Interestingly I have read this Paul's answer only I have sent my own > answer, and I am pleased that we came to almost identical suggestion :-) > And more interestingly: I was wrong. There *is* such service in jMoby - because I needed it for biomoby dashboard (that will be announced next week). So last week I have extracted from the existing method registerService() this part and created in CentralImpl.java a new method public String getRegisterServiceXML (MobyService service) that does exactly what Eddie is looking for (the same was done for other moby entities, such as data types, service types and namespaces) as well. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 06:55:09 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 20 Nov 2005 06:55:09 +0000 (GMT) Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: I am calling: retrieveServiceNames and I am getting back: ... Why are lsids empty? Could you fix it please? Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 16:21:56 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 20 Nov 2005 16:21:56 +0000 (GMT) Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: <4380A101.9040504@illuminae.com> Message-ID: > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sun Nov 20 16:21:56 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 20 Nov 2005 16:21:56 +0000 (GMT) Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: <4380A101.9040504@illuminae.com> Message-ID: > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sun Nov 20 16:31:57 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 20 Nov 2005 16:31:57 +0000 GMT Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: <443899406-1132504485-cardhu_blackberry.rim.net-29404-@engine18-cell01> My pleasure. Greetings from Vancouver airport! (thank goodness for wireless...) M -----Original Message----- From: Martin Senger Date: Sun, 20 Nov 2005 16:21:56 To:Mark Wilkinson Cc:Core developer announcements , Martin Senger , Moby Developers Subject: Re: [MOBY-dev] why a list of services does not have lsid filled? > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Sun Nov 20 16:31:57 2005 From: markw at illuminae.com (mark wilkinson) Date: Sun, 20 Nov 2005 16:31:57 +0000 GMT Subject: [MOBY-dev] why a list of services does not have lsid filled? Message-ID: <443899406-1132504485-cardhu_blackberry.rim.net-29404-@engine18-cell01> My pleasure. Greetings from Vancouver airport! (thank goodness for wireless...) M -----Original Message----- From: Martin Senger Date: Sun, 20 Nov 2005 16:21:56 To:Mark Wilkinson Cc:Core developer announcements , Martin Senger , Moby Developers Subject: Re: [MOBY-dev] why a list of services does not have lsid filled? > should be fixed now. Please confirm. > Confirmed, fixed! Many thanks for an immediate action. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From markw at illuminae.com Sun Nov 20 16:14:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 20 Nov 2005 08:14:57 -0800 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: References: Message-ID: <4380A101.9040504@illuminae.com> should be fixed now. Please confirm. I've also added a test for this case to the harness. M Martin Senger wrote: >I am calling: > retrieveServiceNames >and I am getting back: > > > > > >... > > >Why are lsids empty? Could you fix it please? > >Thanks, >Martin > > > From markw at illuminae.com Sun Nov 20 16:14:57 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 20 Nov 2005 08:14:57 -0800 Subject: [MOBY-dev] why a list of services does not have lsid filled? In-Reply-To: References: Message-ID: <4380A101.9040504@illuminae.com> should be fixed now. Please confirm. I've also added a test for this case to the harness. M Martin Senger wrote: >I am calling: > retrieveServiceNames >and I am getting back: > > > > > >... > > >Why are lsids empty? Could you fix it please? > >Thanks, >Martin > > > From francis_gibbons at hms.harvard.edu Mon Nov 21 14:46:29 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Mon, 21 Nov 2005 09:46:29 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <2121ED51-4164-4E48-9624-89239815D503@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Congratulations, Pieter, At 08:32 AM 11/21/2005, you wrote: >One more thing. After my changes I tried make test and noticed that >the Config.t is skipped, because it's only required for a local >BioMOBY Central..., but I do have one and I have set my >MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >familiar with the test scripts... I think you just got yourself nominated to be caretaker of the test t/Config.t. I don't have a local registry, so there was no way for me to test its operation. Most users (I think) are in the same position, so this test is skipped by default. For details on how to use the testing framework, you could look at the Perl modules Test::Simple and Test:More. The basic idea is that you execute some MOBY code for which you believe you know the output. You compare actual output to expected output using the is() function. It generates errors if the two don't match. You can also check for correct failure using isnt(), which generates a similar error. Examples might be: is(2+2, 4, "Can't do addition");' # Generates error with this string showing up on output device is(scalar @A, $#A + 1, "Scalar gives incorrect results"); Generally, tests should be symbolic, rather than specific. This leads to tests that are more easy to maintain over time: if an array is built before it is tested, and if it's tested symbolically, it should be possible to alter the array contents at a later point, without breaking that test. Take a look in the Client-Central.t for examples of this: a registration structure is created, services are registered, then the registration object is itself queried, and the results compared symbolically with the original data. This verifies that the information flows through the system correctly. If someone later decides to change a small detail (e.g., a parameter name), the tests should continue to pass without modification. But the tests themselves don't really have to complicated to be useful: check that each module exports the functions it claims to implement, check that set/get methods work correctly, check return types in all contexts (does it return array in list context, scalar in scalar context). All that stuff is important in maintaining a coherent interface over time. It also helps to find inconsistencies. I think it would be really great if you could build some useful, robust, portable tests for the local-registry configuration. This kind of test can be a big help to users trying to install their local registry, so its utility goes beyond merely regression testing the code, it's also useful to debugging local installations with perfectly functioning code. -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Tue Nov 22 10:49:49 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Nov 2005 11:49:49 +0100 Subject: [MOBY-dev] Perl API: retrieveObjectDefinition and registerObjectClass call In-Reply-To: <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> References: <4360E4FD.6090202@ucalgary.ca> <64CA7871-7702-4E38-BC3B-7387F57ED3E6@wur.nl> <1130947976.26846.12.camel@bioinfo.icapture.ubc.ca> <71D58747-B144-4E8B-8171-DD65A957F4B0@wur.nl> Message-ID: <30E59CF1-9CA2-43A8-A219-AACCE4F03E0F@wur.nl> On 4-Nov-2005, at 10:41 PM, Pieter Neerincx wrote: > > On 02Nov2005, at 17:12, Mark Wilkinson wrote: > >> I think you're right - that's a much better data structure to be >> passing >> around. >> >> This does change the external (perl client) API, right? :-/ > > Yep, that's why I'm asking. I have no idea who is currently relying > on the retrieveObjectDefinition call and what might break if I > change it... So far I have heard no complaints, so I suggest I go > ahead and make the change... One more thing. The retrieveObjectDefinition function lists that it returns what you send it when you register an object. In that case it makes sense to change the registerObject a.k.a. registerObjectClass function as well. Summarising this would mean the following changes (changes marked with "->"): registerObject a.k.a registerObjectClass Usage : $REG = $MOBY->registerObject(%args) Usage : $REG = $MOBY->registerObjectClass(%args) Function : register a new type of MOBY Object Returns : MOBY::Registration object Args : objectType => "the name of the Object" description => "a human-readable description of the object" contactEmail => "your at email.address" authURI => "URI of the registrar of this object" OLD Relationships => { relationshipType1 => [ -> [Object1, articleName], -> [Object2, articleName] ], relationshipType2 => [ -> [Object3, articleName] ] } NEW Relationships => { relationshipType1 => [ -> {object => Object1, -> articleName => ArticleName1}, -> {object => Object2, -> articleName => ArticleName2} ], -> relationshipType2 => [ -> {object => Object3, -> articleName => ArticleName3} ] } retrieveObjectDefinition Usage : $DEF = $MOBY->retrieveObjectDefinition($objectType[, $registry]) Function : retrieve the $XML that was used to register an object and its relationships Returns : hashref, similar to the hash sent during Object registration, plus an additional XML hash key that contains the actual XML containing the object definition as sent by MOBY Central (used for a visual overview, rather than parsing all of the hash keys) objectType => "the name of the Object" objectLSID => "urn:lsid:..." description => "a human-readable description of the object" contactEmail => "your at email.address" authURI => "URI of the registrar of this object" OLD Relationships => { relationshipType1 => [ -> [Object1, articleName1, lsid1], -> [Object2, articleName2, lsid2] ], relationshipType2 => [ -> [Object1, articleName3, lsid3] ] } NEW Relationships => { relationshipType1 => [ -> {object => Object1, -> articleName => ArticleName1, -> lsid => lsid1}, -> {object => Object2, -> articleName => ArticleName2, -> lsid => lsid2} ], relationshipType2 => [ -> {object => Object3, -> articleName => ArticleName3, -> lsid => lsid3} ] } XML => <....XML of object registration.../> Args : objectType => the name or LSID URI for an object I have the necessary changes including those to Frank's tests standing by. If I don't receive any complaints during the next days I will commit these changes to the CVS on Friday... Cheers, Pieter > >> >> Really, what the Perl client code needs is a good laundering. The >> CommonSubs.pm module is a total mess after being modified >> piecemeal over >> the past 3 years... >> >> I wonder if we shouldn't just start a new module (or modules) that >> are >> named by their domain of function (RegistryIO, OntologyIO, or >> something >> like that) and have all fresh code? Gradually we could migrate all >> functionality into these modules. Client::Central has been around >> since >> the 0.1 prototype of MOBY in 2001 and has never been re-written >> top-to- >> bottom! > > That would be a good idea to get cleaner code, but for the time > being it's not that bad! It works as advertised and gets my job > done :). Try debugging SOAP::Lite and MIME::Parser... those are the > ones that really need a complete make-over! > >> >> I'm still waiting to hear about the re-funding attempts for MOBY... >> fingers crossed! There will hopefully be a second opportunity >> later in >> the winter, so all is not lost if we fail. > > Good luck! > > Pieter > >> It would be great to have a >> couple of extra hands dedicated to a complete code re-write >> >> M >> >> >> >> >> On Wed, 2005-11-02 at 13:44 +0100, Pieter Neerincx wrote: >>> Hi all, >>> >>> Here is a question for those using the Perl API. In >>> >>> MOBY/Client/Central.pm >>> >>> we have a >>> >>> sub retrieveObjectDefinition >>> >>> which calls >>> >>> sub _ObjectDefinitionPayload { >>> >>> This produces an array for the objects, articleNames and lsids for >>> the relationships of the object whose definition is requested. I'm >>> wondering why this is an array. Currently I have to rely on the >>> order >>> of elements in this array to figure out which element is the object, >>> which one is articleName, etc. These are the lines producing the >>> array: >>> >>> 553 push @{ $relationships{$relationshipType} }, >>> 554 [ $_->toString, $article, $rlsid ]; >>> >>> Is there any reason why this should be an array? I'd rather not have >>> to rely on the order of the elements, so are there people who have >>> any objections when I change this into a hash like in: >>> >>> push @{ $relationships{$relationshipType} }, >>> { object => $_->toString, >>> articleName => $article, >>> lsid => $rlsid }; >>> >>> Cheers, >>> >>> Pieter >>> >>> >>> >>> >>> Wageningen University and Research centre (WUR) >>> Laboratory of Bioinformatics >>> Transitorium (building 312) room 1034 >>> Dreijenlaan 3 >>> 6703 HA Wageningen >>> The Netherlands >>> phone: 0317-483 060 >>> fax: 0317-483 584 >>> mobile: 06-143 66 783 >>> pieter.neerincx at wur.nl >>> >>> >>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >> -- >> "Ontologists do it with the edges!" >> >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 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 biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Nov 22 13:01:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 05:01:26 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <438316A6.6040204@illuminae.com> I just changed the code on my own t/* to use environment variables while I was on the plane yesterday so that I could run tests on my own Windows installation - funny that we were all looking at the same piece of code at the same time :-) i'll commit these changes as soon as I have double-checked them. In general it will allow you to test your local registry instead of the remote one by default. M Frank Gibbons wrote: > Congratulations, Pieter, > > At 08:32 AM 11/21/2005, you wrote: > >> One more thing. After my changes I tried make test and noticed that >> the Config.t is skipped, because it's only required for a local >> BioMOBY Central..., but I do have one and I have set my >> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> familiar with the test scripts... > > > I think you just got yourself nominated to be caretaker of the test > t/Config.t. I don't have a local registry, so there was no way for me > to test its operation. Most users (I think) are in the same position, > so this test is skipped by default. > > For details on how to use the testing framework, you could look at > the Perl modules Test::Simple and Test:More. The basic idea is that > you execute some MOBY code for which you believe you know the output. > You compare actual output to expected output using the is() function. > It generates errors if the two don't match. You can also check for > correct failure using isnt(), which generates a similar error. > Examples might be: > > is(2+2, 4, "Can't do addition");' # Generates error with this string > showing up on output device > is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > Generally, tests should be symbolic, rather than specific. This leads > to tests that are more easy to maintain over time: if an array is > built before it is tested, and if it's tested symbolically, it should > be possible to alter the array contents at a later point, without > breaking that test. Take a look in the Client-Central.t for examples > of this: a registration structure is created, services are registered, > then the registration object is itself queried, and the results > compared symbolically with the original data. This verifies that the > information flows through the system correctly. If someone later > decides to change a small detail (e.g., a parameter name), the tests > should continue to pass without modification. > > But the tests themselves don't really have to complicated to be > useful: check that each module exports the functions it claims to > implement, check that set/get methods work correctly, check return > types in all contexts (does it return array in list context, scalar in > scalar context). All that stuff is important in maintaining a coherent > interface over time. It also helps to find inconsistencies. > > I think it would be really great if you could build some useful, > robust, portable tests for the local-registry configuration. This kind > of test can be a big help to users trying to install their local > registry, so its utility goes beyond merely regression testing the > code, it's also useful to debugging local installations with perfectly > functioning code. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From markw at illuminae.com Tue Nov 22 13:01:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 05:01:26 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <438316A6.6040204@illuminae.com> I just changed the code on my own t/* to use environment variables while I was on the plane yesterday so that I could run tests on my own Windows installation - funny that we were all looking at the same piece of code at the same time :-) i'll commit these changes as soon as I have double-checked them. In general it will allow you to test your local registry instead of the remote one by default. M Frank Gibbons wrote: > Congratulations, Pieter, > > At 08:32 AM 11/21/2005, you wrote: > >> One more thing. After my changes I tried make test and noticed that >> the Config.t is skipped, because it's only required for a local >> BioMOBY Central..., but I do have one and I have set my >> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> familiar with the test scripts... > > > I think you just got yourself nominated to be caretaker of the test > t/Config.t. I don't have a local registry, so there was no way for me > to test its operation. Most users (I think) are in the same position, > so this test is skipped by default. > > For details on how to use the testing framework, you could look at > the Perl modules Test::Simple and Test:More. The basic idea is that > you execute some MOBY code for which you believe you know the output. > You compare actual output to expected output using the is() function. > It generates errors if the two don't match. You can also check for > correct failure using isnt(), which generates a similar error. > Examples might be: > > is(2+2, 4, "Can't do addition");' # Generates error with this string > showing up on output device > is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > Generally, tests should be symbolic, rather than specific. This leads > to tests that are more easy to maintain over time: if an array is > built before it is tested, and if it's tested symbolically, it should > be possible to alter the array contents at a later point, without > breaking that test. Take a look in the Client-Central.t for examples > of this: a registration structure is created, services are registered, > then the registration object is itself queried, and the results > compared symbolically with the original data. This verifies that the > information flows through the system correctly. If someone later > decides to change a small detail (e.g., a parameter name), the tests > should continue to pass without modification. > > But the tests themselves don't really have to complicated to be > useful: check that each module exports the functions it claims to > implement, check that set/get methods work correctly, check return > types in all contexts (does it return array in list context, scalar in > scalar context). All that stuff is important in maintaining a coherent > interface over time. It also helps to find inconsistencies. > > I think it would be really great if you could build some useful, > robust, portable tests for the local-registry configuration. This kind > of test can be a big help to users trying to install their local > registry, so its utility goes beyond merely regression testing the > code, it's also useful to debugging local installations with perfectly > functioning code. > > -Frank > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From Pieter.Neerincx at wur.nl Tue Nov 22 13:50:41 2005 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 22 Nov 2005 14:50:41 +0100 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <438316A6.6040204@illuminae.com> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> Message-ID: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > I just changed the code on my own t/* to use environment variables > while I was on the plane yesterday so that I could run tests on my > own Windows installation - funny that we were all looking at the > same piece of code at the same time :-) > > i'll commit these changes as soon as I have double-checked them. > In general it will allow you to test your local registry instead of > the remote one by default. That's cool! I'm looking forward to test the tests :) Pieter > > M > > > > Frank Gibbons wrote: > >> Congratulations, Pieter, >> >> At 08:32 AM 11/21/2005, you wrote: >> >>> One more thing. After my changes I tried make test and noticed that >>> the Config.t is skipped, because it's only required for a local >>> BioMOBY Central..., but I do have one and I have set my >>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>> familiar with the test scripts... >> >> >> I think you just got yourself nominated to be caretaker of the >> test t/Config.t. I don't have a local registry, so there was no >> way for me to test its operation. Most users (I think) are in the >> same position, so this test is skipped by default. >> >> For details on how to use the testing framework, you could look >> at the Perl modules Test::Simple and Test:More. The basic idea is >> that you execute some MOBY code for which you believe you know the >> output. You compare actual output to expected output using the is >> () function. It generates errors if the two don't match. You can >> also check for correct failure using isnt(), which generates a >> similar error. Examples might be: >> >> is(2+2, 4, "Can't do addition");' # Generates error with this >> string showing up on output device >> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> >> Generally, tests should be symbolic, rather than specific. This >> leads to tests that are more easy to maintain over time: if an >> array is built before it is tested, and if it's tested >> symbolically, it should be possible to alter the array contents at >> a later point, without breaking that test. Take a look in the >> Client-Central.t for examples of this: a registration structure is >> created, services are registered, then the registration object is >> itself queried, and the results compared symbolically with the >> original data. This verifies that the information flows through >> the system correctly. If someone later decides to change a small >> detail (e.g., a parameter name), the tests should continue to pass >> without modification. >> >> But the tests themselves don't really have to complicated to be >> useful: check that each module exports the functions it claims to >> implement, check that set/get methods work correctly, check return >> types in all contexts (does it return array in list context, >> scalar in scalar context). All that stuff is important in >> maintaining a coherent interface over time. It also helps to find >> inconsistencies. >> >> I think it would be really great if you could build some useful, >> robust, portable tests for the local-registry configuration. This >> kind of test can be a big help to users trying to install their >> local registry, so its utility goes beyond merely regression >> testing the code, it's also useful to debugging local >> installations with perfectly functioning code. >> >> -Frank >> >> PhD, Computational Biologist, >> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> Tel: 617-432-3555 Fax: 617-432-3557 http:// >> llama.med.harvard.edu/~fgibbons >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> >> > 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 Tue Nov 22 20:09:34 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 12:09:34 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43837AFE.5010901@illuminae.com> Hmmmm... there's still a dependency on the public ontologyserver though... and therefore a dependency on having a network connection. I remember now that this is somethign I wanted to fix a couple of months ago but it got pushed down my TO DO list in favor of keeping my job ;-) I'll try to fix that today - it will make the PlaNet people happy as well! :-) M Pieter Neerincx wrote: > > On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > >> I just changed the code on my own t/* to use environment variables >> while I was on the plane yesterday so that I could run tests on my >> own Windows installation - funny that we were all looking at the >> same piece of code at the same time :-) >> >> i'll commit these changes as soon as I have double-checked them. In >> general it will allow you to test your local registry instead of the >> remote one by default. > > > That's cool! I'm looking forward to test the tests :) > > Pieter > >> >> M >> >> >> >> Frank Gibbons wrote: >> >>> Congratulations, Pieter, >>> >>> At 08:32 AM 11/21/2005, you wrote: >>> >>>> One more thing. After my changes I tried make test and noticed that >>>> the Config.t is skipped, because it's only required for a local >>>> BioMOBY Central..., but I do have one and I have set my >>>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>> familiar with the test scripts... >>> >>> >>> >>> I think you just got yourself nominated to be caretaker of the test >>> t/Config.t. I don't have a local registry, so there was no way for >>> me to test its operation. Most users (I think) are in the same >>> position, so this test is skipped by default. >>> >>> For details on how to use the testing framework, you could look at >>> the Perl modules Test::Simple and Test:More. The basic idea is that >>> you execute some MOBY code for which you believe you know the >>> output. You compare actual output to expected output using the is () >>> function. It generates errors if the two don't match. You can also >>> check for correct failure using isnt(), which generates a similar >>> error. Examples might be: >>> >>> is(2+2, 4, "Can't do addition");' # Generates error with this >>> string showing up on output device >>> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >>> >>> Generally, tests should be symbolic, rather than specific. This >>> leads to tests that are more easy to maintain over time: if an >>> array is built before it is tested, and if it's tested >>> symbolically, it should be possible to alter the array contents at >>> a later point, without breaking that test. Take a look in the >>> Client-Central.t for examples of this: a registration structure is >>> created, services are registered, then the registration object is >>> itself queried, and the results compared symbolically with the >>> original data. This verifies that the information flows through the >>> system correctly. If someone later decides to change a small detail >>> (e.g., a parameter name), the tests should continue to pass without >>> modification. >>> >>> But the tests themselves don't really have to complicated to be >>> useful: check that each module exports the functions it claims to >>> implement, check that set/get methods work correctly, check return >>> types in all contexts (does it return array in list context, scalar >>> in scalar context). All that stuff is important in maintaining a >>> coherent interface over time. It also helps to find inconsistencies. >>> >>> I think it would be really great if you could build some useful, >>> robust, portable tests for the local-registry configuration. This >>> kind of test can be a big help to users trying to install their >>> local registry, so its utility goes beyond merely regression >>> testing the code, it's also useful to debugging local installations >>> with perfectly functioning code. >>> >>> -Frank >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: 617-432-3557 http:// >>> llama.med.harvard.edu/~fgibbons >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From francis_gibbons at hms.harvard.edu Wed Nov 23 15:01:23 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 23 Nov 2005 10:01:23 -0500 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <438316A6.6040204@illuminae.com> References: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> At 08:01 AM 11/22/2005, you wrote: >I just changed the code on my own t/* to use environment variables while I >was on the plane yesterday so that I could run tests on my own Windows >installation - funny that we were all looking at the same piece of code at >the same time :-) > >i'll commit these changes as soon as I have double-checked them. In >general it will allow you to test your local registry instead of the >remote one by default. So Mark, if I understand correctly, it should first check to see if the user has defined those environment variables. That should indicate that the user does have a local registry. It should a local registry if available, but fall back to using MOBY Central if it's not available. Right? That'd be awsome! -Frank >M > > > >Frank Gibbons wrote: > >>Congratulations, Pieter, >> >>At 08:32 AM 11/21/2005, you wrote: >> >>>One more thing. After my changes I tried make test and noticed that >>>the Config.t is skipped, because it's only required for a local >>>BioMOBY Central..., but I do have one and I have set my >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>familiar with the test scripts... >> >> >>I think you just got yourself nominated to be caretaker of the test >>t/Config.t. I don't have a local registry, so there was no way for me to >>test its operation. Most users (I think) are in the same position, so >>this test is skipped by default. >> >>For details on how to use the testing framework, you could look at >>the Perl modules Test::Simple and Test:More. The basic idea is that you >>execute some MOBY code for which you believe you know the output. You >>compare actual output to expected output using the is() function. It >>generates errors if the two don't match. You can also check for correct >>failure using isnt(), which generates a similar error. Examples might be: >> >>is(2+2, 4, "Can't do addition");' # Generates error with this string >>showing up on output device >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> >>Generally, tests should be symbolic, rather than specific. This leads to >>tests that are more easy to maintain over time: if an array is built >>before it is tested, and if it's tested symbolically, it should be >>possible to alter the array contents at a later point, without breaking >>that test. Take a look in the Client-Central.t for examples of this: a >>registration structure is created, services are registered, then the >>registration object is itself queried, and the results compared >>symbolically with the original data. This verifies that the information >>flows through the system correctly. If someone later decides to change a >>small detail (e.g., a parameter name), the tests should continue to pass >>without modification. >> >>But the tests themselves don't really have to complicated to be useful: >>check that each module exports the functions it claims to implement, >>check that set/get methods work correctly, check return types in all >>contexts (does it return array in list context, scalar in scalar >>context). All that stuff is important in maintaining a coherent interface >>over time. It also helps to find inconsistencies. >> >>I think it would be really great if you could build some useful, robust, >>portable tests for the local-registry configuration. This kind of test >>can be a big help to users trying to install their local registry, so its >>utility goes beyond merely regression testing the code, it's also useful >>to debugging local installations with perfectly functioning code. >> >>-Frank >> >>PhD, Computational Biologist, >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. >>Tel: 617-432-3555 Fax: 617-432-3557 >>http://llama.med.harvard.edu/~fgibbons >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Tue Nov 22 21:32:36 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 13:32:36 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43838E74.1010100@illuminae.com> Okay, now it is *really* done. by setting the environment variables: MOBY_SERVER MOBY_URI MOBY_ONTOLOGYSERVER you can connect to your own registry and your own ontology server. This also works for the test harness. I need to document the MOBY_ONTOLOGYSERVER information somewhere... I'll get to that soon! M Pieter Neerincx wrote: > > On 22-Nov-2005, at 2:01 PM, Mark Wilkinson wrote: > >> I just changed the code on my own t/* to use environment variables >> while I was on the plane yesterday so that I could run tests on my >> own Windows installation - funny that we were all looking at the >> same piece of code at the same time :-) >> >> i'll commit these changes as soon as I have double-checked them. In >> general it will allow you to test your local registry instead of the >> remote one by default. > > > That's cool! I'm looking forward to test the tests :) > > Pieter > >> >> M >> >> >> >> Frank Gibbons wrote: >> >>> Congratulations, Pieter, >>> >>> At 08:32 AM 11/21/2005, you wrote: >>> >>>> One more thing. After my changes I tried make test and noticed that >>>> the Config.t is skipped, because it's only required for a local >>>> BioMOBY Central..., but I do have one and I have set my >>>> MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >>>> familiar with the test scripts... >>> >>> >>> >>> I think you just got yourself nominated to be caretaker of the test >>> t/Config.t. I don't have a local registry, so there was no way for >>> me to test its operation. Most users (I think) are in the same >>> position, so this test is skipped by default. >>> >>> For details on how to use the testing framework, you could look at >>> the Perl modules Test::Simple and Test:More. The basic idea is that >>> you execute some MOBY code for which you believe you know the >>> output. You compare actual output to expected output using the is () >>> function. It generates errors if the two don't match. You can also >>> check for correct failure using isnt(), which generates a similar >>> error. Examples might be: >>> >>> is(2+2, 4, "Can't do addition");' # Generates error with this >>> string showing up on output device >>> is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >>> >>> Generally, tests should be symbolic, rather than specific. This >>> leads to tests that are more easy to maintain over time: if an >>> array is built before it is tested, and if it's tested >>> symbolically, it should be possible to alter the array contents at >>> a later point, without breaking that test. Take a look in the >>> Client-Central.t for examples of this: a registration structure is >>> created, services are registered, then the registration object is >>> itself queried, and the results compared symbolically with the >>> original data. This verifies that the information flows through the >>> system correctly. If someone later decides to change a small detail >>> (e.g., a parameter name), the tests should continue to pass without >>> modification. >>> >>> But the tests themselves don't really have to complicated to be >>> useful: check that each module exports the functions it claims to >>> implement, check that set/get methods work correctly, check return >>> types in all contexts (does it return array in list context, scalar >>> in scalar context). All that stuff is important in maintaining a >>> coherent interface over time. It also helps to find inconsistencies. >>> >>> I think it would be really great if you could build some useful, >>> robust, portable tests for the local-registry configuration. This >>> kind of test can be a big help to users trying to install their >>> local registry, so its utility goes beyond merely regression >>> testing the code, it's also useful to debugging local installations >>> with perfectly functioning code. >>> >>> -Frank >>> >>> PhD, Computational Biologist, >>> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >>> 02115, USA. >>> Tel: 617-432-3555 Fax: 617-432-3557 http:// >>> llama.med.harvard.edu/~fgibbons >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at biomoby.org >>> http://www.biomoby.org/mailman/listinfo/moby-dev >>> >>> >> > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > From markw at illuminae.com Tue Nov 22 20:06:26 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 22 Nov 2005 12:06:26 -0800 Subject: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> References: <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <438316A6.6040204@illuminae.com> <47D35600-D8C3-4CAD-80C5-0FA8C402F928@wur.nl> Message-ID: <43837A42.3020409@illuminae.com> > That's cool! I'm looking forward to test the tests :) Okay, it's done. MOBY::Client::Central always checks the environment variables MOBY_SERVER and MOBY_URI first unless you tell it otherwise, but it was hard-coded to talk to mobycentral.icapture.ubc.ca in the test suite. I've removed that now, and added an informational message to the test suite output to indicate how to set it up to test other registries. I've also changed the Client::Service test so that it looks for a service that is guaranteed to be there, rather than one that we just chose at random from the public registry. all 391 tests pass on Windows - Hurrah! M From markw at illuminae.com Wed Nov 23 21:05:47 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 23 Nov 2005 13:05:47 -0800 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> References: <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> Message-ID: <1132779947.22071.10.camel@bioinfo.icapture.ubc.ca> On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > So Mark, if I understand correctly, it should first check to see if the > user has defined those environment variables. That should indicate that the > user does have a local registry. Not necessarily local - the environment variables are simply a way of specifying which MOBY Central you wish to talk to by default (i.e. when you don't initialize the MOBY::Client::Central object with a "Registries" parameter). The following statements describe what happens: 1) The MOBY::Client::Central module is hard-coded to default to mobycentral.icapture.ubc.ca as it's default registry 2) When it is initializing, it first checks for the MOBY_SERVER and MOBY_URI environment variables and uses those instead of the defaults if they exist, otherwise it will default. 3) Initializing MOBY::Client::Central using the "Registries" argument will over-ride both of the previous behaviours -> use of this argument also allows you to interact with more than one registry at a time (for **read-only** interactions) ...(note that this latter behaviour has never been adequately tested, since it has never been used AFAIK) > It should a local registry if available, > but fall back to using MOBY Central if it's not available. Right? yup. That behaviour has always been true, actually; however the test harness was hard coded to use the 'Registries' argument when it started- up, so it was over-riding the useful behaviour that MOBY::Client::Central already had :-) The same behaviour is now true for MOBY::Client::OntologyServer - it will first check the environment variable, and if it isn't set, then it will default to call home to mobycentral.icapture.ubc.ca Cheers! M > That'd be awsome! > > -Frank > > > >M > > > > > > > >Frank Gibbons wrote: > > > >>Congratulations, Pieter, > >> > >>At 08:32 AM 11/21/2005, you wrote: > >> > >>>One more thing. After my changes I tried make test and noticed that > >>>the Config.t is skipped, because it's only required for a local > >>>BioMOBY Central..., but I do have one and I have set my > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > >>>familiar with the test scripts... > >> > >> > >>I think you just got yourself nominated to be caretaker of the test > >>t/Config.t. I don't have a local registry, so there was no way for me to > >>test its operation. Most users (I think) are in the same position, so > >>this test is skipped by default. > >> > >>For details on how to use the testing framework, you could look at > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > >>execute some MOBY code for which you believe you know the output. You > >>compare actual output to expected output using the is() function. It > >>generates errors if the two don't match. You can also check for correct > >>failure using isnt(), which generates a similar error. Examples might be: > >> > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > >>showing up on output device > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > >> > >>Generally, tests should be symbolic, rather than specific. This leads to > >>tests that are more easy to maintain over time: if an array is built > >>before it is tested, and if it's tested symbolically, it should be > >>possible to alter the array contents at a later point, without breaking > >>that test. Take a look in the Client-Central.t for examples of this: a > >>registration structure is created, services are registered, then the > >>registration object is itself queried, and the results compared > >>symbolically with the original data. This verifies that the information > >>flows through the system correctly. If someone later decides to change a > >>small detail (e.g., a parameter name), the tests should continue to pass > >>without modification. > >> > >>But the tests themselves don't really have to complicated to be useful: > >>check that each module exports the functions it claims to implement, > >>check that set/get methods work correctly, check return types in all > >>contexts (does it return array in list context, scalar in scalar > >>context). All that stuff is important in maintaining a coherent interface > >>over time. It also helps to find inconsistencies. > >> > >>I think it would be really great if you could build some useful, robust, > >>portable tests for the local-registry configuration. This kind of test > >>can be a big help to users trying to install their local registry, so its > >>utility goes beyond merely regression testing the code, it's also useful > >>to debugging local installations with perfectly functioning code. > >> > >>-Frank > >> > >>PhD, Computational Biologist, > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > >>Tel: 617-432-3555 Fax: 617-432-3557 > >>http://llama.med.harvard.edu/~fgibbons > >>_______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://www.biomoby.org/mailman/listinfo/moby-dev > >> > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From francis_gibbons at hms.harvard.edu Wed Nov 23 21:49:15 2005 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 23 Nov 2005 16:49:15 -0500 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <1132779947.22071.10.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Mark, Just ran the tests. Looks good, except the informational message is somewhat jarring... ideally, the only output that appears is a series of test-file names, with "..........ok" after them. I wonder if developers need to see that message each time they run the tests - perhaps it would help just as well if it were embedded as comments? What do you think? I'll be gone for a few days, as it Thanksgiving down here. -Frank At 04:05 PM 11/23/2005, you wrote: >On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > > > So Mark, if I understand correctly, it should first check to see if the > > user has defined those environment variables. That should indicate that > the > > user does have a local registry. > >Not necessarily local - the environment variables are simply a way of >specifying which MOBY Central you wish to talk to by default (i.e. when >you don't initialize the MOBY::Client::Central object with a >"Registries" parameter). > >The following statements describe what happens: > >1) The MOBY::Client::Central module is hard-coded to default to >mobycentral.icapture.ubc.ca as it's default registry > >2) When it is initializing, it first checks for the MOBY_SERVER and >MOBY_URI environment variables and uses those instead of the defaults if >they exist, otherwise it will default. > >3) Initializing MOBY::Client::Central using the "Registries" argument >will over-ride both of the previous behaviours > -> use of this argument also allows you to interact with more > than one >registry at a time (for **read-only** interactions) ...(note that this >latter behaviour has never been adequately tested, since it has never >been used AFAIK) > > > > > It should a local registry if available, > > but fall back to using MOBY Central if it's not available. Right? > > >yup. That behaviour has always been true, actually; however the test >harness was hard coded to use the 'Registries' argument when it started- >up, so it was over-riding the useful behaviour that >MOBY::Client::Central already had :-) > >The same behaviour is now true for MOBY::Client::OntologyServer - it >will first check the environment variable, and if it isn't set, then it >will default to call home to mobycentral.icapture.ubc.ca > >Cheers! > >M > > > > > > That'd be awsome! > > > > -Frank > > > > > > >M > > > > > > > > > > > >Frank Gibbons wrote: > > > > > >>Congratulations, Pieter, > > >> > > >>At 08:32 AM 11/21/2005, you wrote: > > >> > > >>>One more thing. After my changes I tried make test and noticed that > > >>>the Config.t is skipped, because it's only required for a local > > >>>BioMOBY Central..., but I do have one and I have set my > > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > > >>>familiar with the test scripts... > > >> > > >> > > >>I think you just got yourself nominated to be caretaker of the test > > >>t/Config.t. I don't have a local registry, so there was no way for me to > > >>test its operation. Most users (I think) are in the same position, so > > >>this test is skipped by default. > > >> > > >>For details on how to use the testing framework, you could look at > > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > > >>execute some MOBY code for which you believe you know the output. You > > >>compare actual output to expected output using the is() function. It > > >>generates errors if the two don't match. You can also check for correct > > >>failure using isnt(), which generates a similar error. Examples might be: > > >> > > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > > >>showing up on output device > > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > >> > > >>Generally, tests should be symbolic, rather than specific. This leads to > > >>tests that are more easy to maintain over time: if an array is built > > >>before it is tested, and if it's tested symbolically, it should be > > >>possible to alter the array contents at a later point, without breaking > > >>that test. Take a look in the Client-Central.t for examples of this: a > > >>registration structure is created, services are registered, then the > > >>registration object is itself queried, and the results compared > > >>symbolically with the original data. This verifies that the information > > >>flows through the system correctly. If someone later decides to change a > > >>small detail (e.g., a parameter name), the tests should continue to pass > > >>without modification. > > >> > > >>But the tests themselves don't really have to complicated to be useful: > > >>check that each module exports the functions it claims to implement, > > >>check that set/get methods work correctly, check return types in all > > >>contexts (does it return array in list context, scalar in scalar > > >>context). All that stuff is important in maintaining a coherent > interface > > >>over time. It also helps to find inconsistencies. > > >> > > >>I think it would be really great if you could build some useful, robust, > > >>portable tests for the local-registry configuration. This kind of test > > >>can be a big help to users trying to install their local registry, so > its > > >>utility goes beyond merely regression testing the code, it's also useful > > >>to debugging local installations with perfectly functioning code. > > >> > > >>-Frank > > >> > > >>PhD, Computational Biologist, > > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > > >>Tel: 617-432-3555 Fax: 617-432-3557 > > >>http://llama.med.harvard.edu/~fgibbons > > >>_______________________________________________ > > >>MOBY-dev mailing list > > >>MOBY-dev at biomoby.org > > >>http://www.biomoby.org/mailman/listinfo/moby-dev > > >> > > > > > >_______________________________________________ > > >MOBY-dev mailing list > > >MOBY-dev at biomoby.org > > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > PhD, Computational Biologist, > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > > Tel: 617-432-3555 Fax: > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev >-- >"Ontologists do it with the edges!" > >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev 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 Wed Nov 23 22:34:19 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 23 Nov 2005 14:34:19 -0800 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <004401c5e94d$ab0c70c0$6600a8c0@notebook> <5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu> <432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl> <5.2.1.1.2.20051118123741.0123a990@email.med.harvard.edu> <5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Message-ID: <1132785259.22071.22.camel@bioinfo.icapture.ubc.ca> It doesn't really bother me so much, but to be honest I think the bigger problem is that "make install" doesn't create a default local registry, and that "make test" would have to be run after "make install", which is even stranger. There was a time when Richard B had set up the Makefile to do this, or at least had set up an install script that would do the default MOBY Central installation and bootstrapping... that might be worth resurrecting. I think the code is still commented out in the Makefile... M On Wed, 2005-11-23 at 16:49 -0500, Frank Gibbons wrote: > Mark, > > Just ran the tests. Looks good, except the informational message is > somewhat jarring... ideally, the only output that appears is a series of > test-file names, with "..........ok" after them. I wonder if developers > need to see that message each time they run the tests - perhaps it would > help just as well if it were embedded as comments? What do you think? > > I'll be gone for a few days, as it Thanksgiving down here. > > -Frank > > At 04:05 PM 11/23/2005, you wrote: > >On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: > > > > > So Mark, if I understand correctly, it should first check to see if the > > > user has defined those environment variables. That should indicate that > > the > > > user does have a local registry. > > > >Not necessarily local - the environment variables are simply a way of > >specifying which MOBY Central you wish to talk to by default (i.e. when > >you don't initialize the MOBY::Client::Central object with a > >"Registries" parameter). > > > >The following statements describe what happens: > > > >1) The MOBY::Client::Central module is hard-coded to default to > >mobycentral.icapture.ubc.ca as it's default registry > > > >2) When it is initializing, it first checks for the MOBY_SERVER and > >MOBY_URI environment variables and uses those instead of the defaults if > >they exist, otherwise it will default. > > > >3) Initializing MOBY::Client::Central using the "Registries" argument > >will over-ride both of the previous behaviours > > -> use of this argument also allows you to interact with more > > than one > >registry at a time (for **read-only** interactions) ...(note that this > >latter behaviour has never been adequately tested, since it has never > >been used AFAIK) > > > > > > > > > It should a local registry if available, > > > but fall back to using MOBY Central if it's not available. Right? > > > > > >yup. That behaviour has always been true, actually; however the test > >harness was hard coded to use the 'Registries' argument when it started- > >up, so it was over-riding the useful behaviour that > >MOBY::Client::Central already had :-) > > > >The same behaviour is now true for MOBY::Client::OntologyServer - it > >will first check the environment variable, and if it isn't set, then it > >will default to call home to mobycentral.icapture.ubc.ca > > > >Cheers! > > > >M > > > > > > > > > > > That'd be awsome! > > > > > > -Frank > > > > > > > > > >M > > > > > > > > > > > > > > > >Frank Gibbons wrote: > > > > > > > >>Congratulations, Pieter, > > > >> > > > >>At 08:32 AM 11/21/2005, you wrote: > > > >> > > > >>>One more thing. After my changes I tried make test and noticed that > > > >>>the Config.t is skipped, because it's only required for a local > > > >>>BioMOBY Central..., but I do have one and I have set my > > > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very > > > >>>familiar with the test scripts... > > > >> > > > >> > > > >>I think you just got yourself nominated to be caretaker of the test > > > >>t/Config.t. I don't have a local registry, so there was no way for me to > > > >>test its operation. Most users (I think) are in the same position, so > > > >>this test is skipped by default. > > > >> > > > >>For details on how to use the testing framework, you could look at > > > >>the Perl modules Test::Simple and Test:More. The basic idea is that you > > > >>execute some MOBY code for which you believe you know the output. You > > > >>compare actual output to expected output using the is() function. It > > > >>generates errors if the two don't match. You can also check for correct > > > >>failure using isnt(), which generates a similar error. Examples might be: > > > >> > > > >>is(2+2, 4, "Can't do addition");' # Generates error with this string > > > >>showing up on output device > > > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); > > > >> > > > >>Generally, tests should be symbolic, rather than specific. This leads to > > > >>tests that are more easy to maintain over time: if an array is built > > > >>before it is tested, and if it's tested symbolically, it should be > > > >>possible to alter the array contents at a later point, without breaking > > > >>that test. Take a look in the Client-Central.t for examples of this: a > > > >>registration structure is created, services are registered, then the > > > >>registration object is itself queried, and the results compared > > > >>symbolically with the original data. This verifies that the information > > > >>flows through the system correctly. If someone later decides to change a > > > >>small detail (e.g., a parameter name), the tests should continue to pass > > > >>without modification. > > > >> > > > >>But the tests themselves don't really have to complicated to be useful: > > > >>check that each module exports the functions it claims to implement, > > > >>check that set/get methods work correctly, check return types in all > > > >>contexts (does it return array in list context, scalar in scalar > > > >>context). All that stuff is important in maintaining a coherent > > interface > > > >>over time. It also helps to find inconsistencies. > > > >> > > > >>I think it would be really great if you could build some useful, robust, > > > >>portable tests for the local-registry configuration. This kind of test > > > >>can be a big help to users trying to install their local registry, so > > its > > > >>utility goes beyond merely regression testing the code, it's also useful > > > >>to debugging local installations with perfectly functioning code. > > > >> > > > >>-Frank > > > >> > > > >>PhD, Computational Biologist, > > > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > > 02115, USA. > > > >>Tel: 617-432-3555 Fax: 617-432-3557 > > > >>http://llama.med.harvard.edu/~fgibbons > > > >>_______________________________________________ > > > >>MOBY-dev mailing list > > > >>MOBY-dev at biomoby.org > > > >>http://www.biomoby.org/mailman/listinfo/moby-dev > > > >> > > > > > > > >_______________________________________________ > > > >MOBY-dev mailing list > > > >MOBY-dev at biomoby.org > > > >http://www.biomoby.org/mailman/listinfo/moby-dev > > > > > > PhD, Computational Biologist, > > > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > > USA. > > > Tel: 617-432-3555 Fax: > > > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > >-- > >"Ontologists do it with the edges!" > > > >Mark Wilkinson > >Asst. Professor > >Dept. of Medical Genetics > >University of British Columbia > >PI in Bioinformatics > >iCAPTURE Centre > >St. Paul's Hospital > >Rm. 166, 1081 Burrard St. > >Vancouver, BC, V6Z 1Y6 > >tel: 604 682 2344 x62129 > >fax: 604 806 9274 > > > >_______________________________________________ > >MOBY-dev mailing list > >MOBY-dev at biomoby.org > >http://www.biomoby.org/mailman/listinfo/moby-dev > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. > Tel: 617-432-3555 Fax: > 617-432-3557 http://llama.med.harvard.edu/~fgibbons > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From jmfernandez at cnb.uam.es Wed Nov 23 22:20:14 2005 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Wed, 23 Nov 2005 23:20:14 +0100 Subject: [moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse In-Reply-To: <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> References: <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu><5.2.1. 1.2.20051121093229.010aed90@email.med.harvard.edu><5.2.1.1.2.20051118123741 .0123a990@email.med.harvard.edu><432C2FF2-E1C2-4E3F-AB83-0D78DFB6BA62@wur.n l><004401c5e94d$ab0c70c0$6600a8c0@notebook><004401c5e94d$ab0c70c0$6600a8c0@ notebook><5.2.1.1.2.20051116093755.01173880@email.med.harvard.edu><432C2FF2 -E1C2-4E3F-AB83-0D78DFB6BA62@wur.nl><5.2.1.1.2.20051118123741.0123a990@emai l.med.harvard.edu><5.2.1.1.2.20051121093229.010aed90@email.med.harvard.edu> <5.2.1.1.2.20051123095913.0124ae68@email.med.harvard.edu> <5.2.1.1.2.20051123164724.010d0ff0@email.med.harvard.edu> Message-ID: <4384EB1E.9080403@cnb.uam.es> Hi everybody, I have installed many Perl packages, and many of them show lots of information when it is done the next invokation: make TEST_VERBOSE=1 test For instance, DBI uses Test::More inside its tests. Best Regards, Jos? Mar?a Frank Gibbons wrote: > Mark, > > Just ran the tests. Looks good, except the informational message is > somewhat jarring... ideally, the only output that appears is a series of > test-file names, with "..........ok" after them. I wonder if developers > need to see that message each time they run the tests - perhaps it would > help just as well if it were embedded as comments? What do you think? > > I'll be gone for a few days, as it Thanksgiving down here. > > -Frank > > At 04:05 PM 11/23/2005, you wrote: > >> On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote: >> >> > So Mark, if I understand correctly, it should first check to see if the >> > user has defined those environment variables. That should indicate >> that the >> > user does have a local registry. >> >> Not necessarily local - the environment variables are simply a way of >> specifying which MOBY Central you wish to talk to by default (i.e. when >> you don't initialize the MOBY::Client::Central object with a >> "Registries" parameter). >> >> The following statements describe what happens: >> >> 1) The MOBY::Client::Central module is hard-coded to default to >> mobycentral.icapture.ubc.ca as it's default registry >> >> 2) When it is initializing, it first checks for the MOBY_SERVER and >> MOBY_URI environment variables and uses those instead of the defaults if >> they exist, otherwise it will default. >> >> 3) Initializing MOBY::Client::Central using the "Registries" argument >> will over-ride both of the previous behaviours >> -> use of this argument also allows you to interact with more >> than one >> registry at a time (for **read-only** interactions) ...(note that this >> latter behaviour has never been adequately tested, since it has never >> been used AFAIK) >> >> >> >> > It should a local registry if available, >> > but fall back to using MOBY Central if it's not available. Right? >> >> >> yup. That behaviour has always been true, actually; however the test >> harness was hard coded to use the 'Registries' argument when it started- >> up, so it was over-riding the useful behaviour that >> MOBY::Client::Central already had :-) >> >> The same behaviour is now true for MOBY::Client::OntologyServer - it >> will first check the environment variable, and if it isn't set, then it >> will default to call home to mobycentral.icapture.ubc.ca >> >> Cheers! >> >> M >> >> >> >> >> > That'd be awsome! >> > >> > -Frank >> > >> > >> > >M >> > > >> > > >> > > >> > >Frank Gibbons wrote: >> > > >> > >>Congratulations, Pieter, >> > >> >> > >>At 08:32 AM 11/21/2005, you wrote: >> > >> >> > >>>One more thing. After my changes I tried make test and noticed that >> > >>>the Config.t is skipped, because it's only required for a local >> > >>>BioMOBY Central..., but I do have one and I have set my >> > >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very >> > >>>familiar with the test scripts... >> > >> >> > >> >> > >>I think you just got yourself nominated to be caretaker of the test >> > >>t/Config.t. I don't have a local registry, so there was no way for >> me to >> > >>test its operation. Most users (I think) are in the same position, so >> > >>this test is skipped by default. >> > >> >> > >>For details on how to use the testing framework, you could look at >> > >>the Perl modules Test::Simple and Test:More. The basic idea is >> that you >> > >>execute some MOBY code for which you believe you know the output. You >> > >>compare actual output to expected output using the is() function. It >> > >>generates errors if the two don't match. You can also check for >> correct >> > >>failure using isnt(), which generates a similar error. Examples >> might be: >> > >> >> > >>is(2+2, 4, "Can't do addition");' # Generates error with this string >> > >>showing up on output device >> > >>is(scalar @A, $#A + 1, "Scalar gives incorrect results"); >> > >> >> > >>Generally, tests should be symbolic, rather than specific. This >> leads to >> > >>tests that are more easy to maintain over time: if an array is built >> > >>before it is tested, and if it's tested symbolically, it should be >> > >>possible to alter the array contents at a later point, without >> breaking >> > >>that test. Take a look in the Client-Central.t for examples of >> this: a >> > >>registration structure is created, services are registered, then the >> > >>registration object is itself queried, and the results compared >> > >>symbolically with the original data. This verifies that the >> information >> > >>flows through the system correctly. If someone later decides to >> change a >> > >>small detail (e.g., a parameter name), the tests should continue >> to pass >> > >>without modification. >> > >> >> > >>But the tests themselves don't really have to complicated to be >> useful: >> > >>check that each module exports the functions it claims to implement, >> > >>check that set/get methods work correctly, check return types in all >> > >>contexts (does it return array in list context, scalar in scalar >> > >>context). All that stuff is important in maintaining a coherent >> interface >> > >>over time. It also helps to find inconsistencies. >> > >> >> > >>I think it would be really great if you could build some useful, >> robust, >> > >>portable tests for the local-registry configuration. This kind of >> test >> > >>can be a big help to users trying to install their local registry, >> so its >> > >>utility goes beyond merely regression testing the code, it's also >> useful >> > >>to debugging local installations with perfectly functioning code. >> > >> >> > >>-Frank >> > >> >> > >>PhD, Computational Biologist, >> > >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> > >>Tel: 617-432-3555 Fax: 617-432-3557 >> > >>http://llama.med.harvard.edu/~fgibbons >> > >>_______________________________________________ >> > >>MOBY-dev mailing list >> > >>MOBY-dev at biomoby.org >> > >>http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> >> > > >> > >_______________________________________________ >> > >MOBY-dev mailing list >> > >MOBY-dev at biomoby.org >> > >http://www.biomoby.org/mailman/listinfo/moby-dev >> > >> > PhD, Computational Biologist, >> > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA >> 02115, USA. >> > Tel: 617-432-3555 Fax: >> > 617-432-3557 http://llama.med.harvard.edu/~fgibbons >> > >> > _______________________________________________ >> > MOBY-dev mailing list >> > MOBY-dev at biomoby.org >> > http://www.biomoby.org/mailman/listinfo/moby-dev >> -- >> "Ontologists do it with the edges!" >> >> Mark Wilkinson >> Asst. Professor >> Dept. of Medical Genetics >> University of British Columbia >> PI in Bioinformatics >> iCAPTURE Centre >> St. Paul's Hospital >> Rm. 166, 1081 Burrard St. >> Vancouver, BC, V6Z 1Y6 >> tel: 604 682 2344 x62129 >> fax: 604 806 9274 >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, > USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From senger at ebi.ac.uk Thu Nov 24 14:14:41 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 24 Nov 2005 14:14:41 +0000 (GMT) Subject: [MOBY-dev] Biomoby Dashboard beta release Message-ID: Dear Moby-ists, There is another result (after Moses code generator) of my lucky (lucky for me) involvement with the Generation Challenge Programm and with IRRI particularly: it is my pleasure to announce a beta version of a Biomoby Dashboard (or shortly a Dash, as Eddie already nicknamed it, but I am not sure about English, especially slang English meaning of it :-)). It is for Biomoby service providers, it is potentially extensible also for Biomoby client. We will be adding there new panels shortly, and I hope to get feedback from you so we can improve it. I am sorry that the documentation is (almost) missing, but I wanted to release it so I can get feedback as soon as possible. We are working on documentation, as well. You can find basic instructions and some screen-shots here: http://biomoby.org/moby-live/Java/docs/Dashboard.html. With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From rebecca.ernst at gsf.de Fri Nov 25 09:55:13 2005 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Fri, 25 Nov 2005 10:55:13 +0100 Subject: [MOBY-dev] dashboard Message-ID: <4386DF81.6040500@gsf.de> Hi Martin! I had a first look at dashboard and I really loved it! I makes things so much easier! I also found it quite intuitive to use. In principle everything worked but there were some problems. 1) If I use the planet registry it reads out the datatypes but after finishing reading it doesn't have them anymore. Is it possible that it misses the LSID resolver which we don't have yet? 2) In the Moses-Generator section I couldn't find out how to select a service to generate code for... I have them in the service listing on the left but how do I select one to generate code for?? Cheers, Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Fri Nov 25 16:11:35 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 25 Nov 2005 08:11:35 -0800 Subject: [moby] [MOBY-dev] dashboard In-Reply-To: <4386DF81.6040500@gsf.de> References: <4386DF81.6040500@gsf.de> Message-ID: <1132935095.27789.21.camel@bioinfo.icapture.ubc.ca> We can help you set up the LSID resolver if you like. The current release of the Perl LSID stack is broken, but in the past week the CVS version is now working - we've asked them to make a release, since this is the last unfinished issue that is preventing us from both starting the RDF agent, and making a new MOBY code release... LSID's in Perl have been problematic for years, and have prevented us from ever becoming dependent on them v.v. the RDF agent, as Martin has pointed out several times! Hopefully this latest release will be stable for the long-term... hopefully! In any case, I suspect that Martin's dashboard is using LSID resolution of MOBY stuff to metadata, since he was asking about it frequently in the past few weeks. If that is the only issue standing between you and success, then please let me know and either Eddie or I will get you up and running quickly! M On Fri, 2005-11-25 at 10:55 +0100, Rebecca Ernst wrote: > Hi Martin! > > I had a first look at dashboard and I really loved it! I makes things so > much easier! I also found it quite intuitive to use. > > In principle everything worked but there were some problems. > > 1) If I use the planet registry it reads out the datatypes but after > finishing reading it doesn't have them anymore. Is it possible that it > misses the LSID resolver which we don't have yet? > > 2) In the Moses-Generator section I couldn't find out how to select a > service to generate code for... I have them in the service listing on > the left but how do I select one to generate code for?? > > Cheers, > Rebecca > -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Fri Nov 25 17:45:27 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 25 Nov 2005 09:45:27 -0800 Subject: [MOBY-dev] biomoby.org moving to new server Message-ID: <1132940727.27789.48.camel@bioinfo.icapture.ubc.ca> Hi all, heads up that the DNS changes are about to start propagating through the net. By tomorrow we should be serving everything from the new server. LSID resolution should not be affected, since the lsid SRV records are held on a different machine entirely... but touch wood in any case. Please let me know ASAP if you notice any problems. M -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From senger at ebi.ac.uk Sat Nov 26 05:19:46 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 26 Nov 2005 05:19:46 +0000 (GMT) Subject: [MOBY-dev] dashboard In-Reply-To: <4386DF81.6040500@gsf.de> Message-ID: > 1) If I use the planet registry it reads out the datatypes but after > finishing reading it doesn't have them anymore. > This would be a serious bug, not a "small thing" :-) You were simply too polite in your answer... Can I try myself, is the plant registry open? If so, please give me th URL and URI. Anyway, what do you mean by "does not have them anymore"? Does it show anything in the data types tree, or nothing at all? Perhaps it is again the bug I have mentioned in the "known bug" about synchronization - I *have* to find what is wrong here, it drives me crazy! > Is it possible that it misses the LSID resolver which we don't have > yet? > No, nothing to do with LSID resolver. Dasboard, and me either, do not use LSID resolver. And will not until it is clearly defined. Biomoby is vague about it. I will respond more specifically about in later when I reply to Mark's email. > 2) In the Moses-Generator section I couldn't find out how to select a > service to generate code for... > In the same way as in any selction list: CTRL and click on selected - and it should unselect (there may be some OS-specific ways but I think that CTRL, or Apple keys usually works). > I have them in the service listing on the left but how do I select one > to generate code for?? > All services that are selected in the tree on the left will be used to generate code for them. You can select either an authority - then all their services will be used, or individual services. Yoy can select more by holding CTRL or SHIFT key (again, this is not Dasboard specific, it is the same with other programs taht allow multiple selection). Below the tree there is a note how many services and authorities are currently selected. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Nov 26 20:15:02 2005 From: markw at illuminae.com (mark wilkinson) Date: Sat, 26 Nov 2005 20:15:02 +0000 GMT Subject: [MOBY-dev] dashboard Message-ID: <74945373-1133036350-cardhu_blackberry.rim.net-11436-@engine08-cell01> Hi Martin, Can you give me an example of a sentence about the lsid resolver that you would find sufficiently non-vague? The discussion on the website seems quite clear to me, but you have higher standards :-) M -----Original Message----- From: Martin Senger Date: Sat, 26 Nov 2005 05:19:46 To:Rebecca Ernst Cc:moby-dev at biomoby.org Subject: Re: [MOBY-dev] dashboard > 1) If I use the planet registry it reads out the datatypes but after > finishing reading it doesn't have them anymore. > This would be a serious bug, not a "small thing" :-) You were simply too polite in your answer... Can I try myself, is the plant registry open? If so, please give me th URL and URI. Anyway, what do you mean by "does not have them anymore"? Does it show anything in the data types tree, or nothing at all? Perhaps it is again the bug I have mentioned in the "known bug" about synchronization - I *have* to find what is wrong here, it drives me crazy! > Is it possible that it misses the LSID resolver which we don't have > yet? > No, nothing to do with LSID resolver. Dasboard, and me either, do not use LSID resolver. And will not until it is clearly defined. Biomoby is vague about it. I will respond more specifically about in later when I reply to Mark's email. > 2) In the Moses-Generator section I couldn't find out how to select a > service to generate code for... > In the same way as in any selction list: CTRL and click on selected - and it should unselect (there may be some OS-specific ways but I think that CTRL, or Apple keys usually works). > I have them in the service listing on the left but how do I select one > to generate code for?? > All services that are selected in the tree on the left will be used to generate code for them. You can select either an authority - then all their services will be used, or individual services. Yoy can select more by holding CTRL or SHIFT key (again, this is not Dasboard specific, it is the same with other programs taht allow multiple selection). Below the tree there is a note how many services and authorities are currently selected. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Sun Nov 27 05:51:54 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 27 Nov 2005 05:51:54 +0000 (GMT) Subject: [MOBY-dev] Moby API/LSID (Was: dashboard) In-Reply-To: <74945373-1133036350-cardhu_blackberry.rim.net-11436-@engine08-cell01> Message-ID: > Can you give me an example of a sentence about the lsid resolver that > you would find sufficiently non-vague? The discussion on the website > seems quite clear to me, but you have higher standards :-) > Well, as usual, I am confused :-) What discussion? And what website? No, I am not making jokes now, I do not remember any discussion how to use LSIDs in Biomoby. At least no recently. Anyway, here are the remarsks I have promise to send: Biomoby consists of several parts, each of them may have several protocols (or APIs). Some of them are well defined, some of them are just assumed. Here they are as I understand it: 1) An API how to communicate with a Biomoby registry and with Biomoby services, using SOAP and XML messages. This is well defined on the Biomoby website and everybody is cautious to change it only after good discussion happens. It is in good shape, eventhough it may soon ask for some changes, such as asynchonous invocation. The only "problem" with this API is my feeling (just feeling, no evidence at all) that Mark would like to let this API go in the future, and a closer collaboration with S-Moby may be a good excuse for it. But it is just a feeling, we will cross that brige when we come to it. 2) The contents of the RDF document returned when a provider registered a service is part of the API mentioned above, but it is not documented (at least I have not seen any documentation). In theory, providers do not "need to know" the contents, they just get it from the registry and put it somewhere as a token for the RDF agent. But in practice, it was recommended to use it to enhance information about your services. In order to do that a provider needs to know the predicate names (and what they mean) that are there always and that may be there. Such discussion about predicate names started (at least I and Eddie discussed it in Malaga, and people briefly discussed it already in Vancouver) but it was never "officially" approved and made part of the Biomoby well-defined behaviour. 3) And finally, there is an LSID resolver. Which means that any entity that has an LSID (in our case, an LSID assigned by a Biomoby registry when the entity was registered) can be "resolved" by LSID's API. The LSID' API is weel-defined, but it can be still used in several different ways. And I believe that we should define what ways we prefer to have in Biomoby. Here is a list of few things that came to my mind during writing this paragraph but they may be other that I forgot. We surely have not discussed it in such details yet: * LSID API has methods getData and getMetadata. Any of them can return an empty result. What would be recommended for us: an empty getData() or not? For some entities it would be quite good to get something from getData()... * Resolving LSID metadata has more steps than just to make an HTTP connection and to get an RDF file. But I guess that we want to recommend to use just this step. So we are slightly "abusing" (in a possitive way) the LSID spec, but we do not document it. * LSID metadata must have well defined predicates (at least some) - this is the same problem as described in paragraph ad 2). Well, I stop now, too long email. But this is what I called "vague". And I do not think that I have any "higher standard" than it should be usual for a stable and robust software. And we want to have Biomoby a stable and robust software, don't we? Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sun Nov 27 17:05:16 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Sun, 27 Nov 2005 09:05:16 -0800 Subject: [MOBY-dev] Moby API/LSID (Was: dashboard) In-Reply-To: References: Message-ID: <4389E74C.4000801@illuminae.com> Martin Senger wrote: > Well, as usual, I am confused :-) What discussion? And what website? > No, I am not making jokes now, I do not remember any discussion how to >use LSIDs in Biomoby. At least no recently. Anyway, here are the remarsks >I have promise to send: > > I pointed you to this a couple of weeks ago and asked for your comments (or at least, I think I did... maybe not to you directly, but to the -dev list): http://biomoby.open-bio.org/index.php/for-developers/moby_extensions > 2) The contents of the RDF document returned when a provider registered >a service is part of the API mentioned above, but it is not documented (at >least I have not seen any documentation). In theory, providers do not >"need to know" the contents, they just get it from the registry and put it >somewhere as a token for the RDF agent. But in practice, it was >recommended to use it to enhance information about your services. In order >to do that a provider needs to know the predicate names (and what they >mean) that are there always and that may be there. Such discussion about >predicate names started (at least I and Eddie discussed it in Malaga, and >people briefly discussed it already in Vancouver) but it was never >"officially" approved and made part of the Biomoby well-defined behaviour. > > The predicates have only recently been defined for Service Instances since we have just finished working with myGrid to merge our data models. They've been defined for longer for the ontologies, but there have been no comments one way or the other on whether or not people like the RDF structure for the ontologies. In any case, I've listed all of the predicates on the new website, and am starting to document them now... slowly! Some of them I cannot document since they are in the mygrid namespace, and they aren't documented there (though I could guess). They are, however, all defined in a machine-readable way within their respective namespaces. The MOBY ones can be resolved to additional explanatory RDF if you resolve the predicate's namespace. I think the mygrid namespace does not currently resolve, but you can get it from some other URL (which escapes me at the moment). > * LSID API has methods getData and getMetadata. Any of them can return >an empty result. What would be recommended for us: an empty getData() or >not? For some entities it would be quite good to get something from >getData()... > > I note this behaviour as being undefined on the website. It may or may not return something, since we are experimenting with what kinds of things are best to return, but it is explicitly stated on the website that you should not rely on what is returned until the behaviour is defined > * Resolving LSID metadata has more steps than just to make an HTTP >connection and to get an RDF file. But I guess that we want to >recommend to use just this step. So we are slightly "abusing" (in a >possitive way) the LSID spec, but we do not document it. > > Can you write a sentence that explains this? I don't really understand what you mean either... > * LSID metadata must have well defined predicates (at least some) - >this is the same problem as described in paragraph ad 2). > > this is done at least in part, but the definitions are not well written yet. The more comments the better, since it would be nice to get this documented in a robust way! M From senger at ebi.ac.uk Sun Nov 27 17:50:11 2005 From: senger at ebi.ac.uk (Martin Senger) Date: Sun, 27 Nov 2005 17:50:11 +0000 (GMT) Subject: [MOBY-dev] Moby API/LSID (Was: dashboard) In-Reply-To: <4389E74C.4000801@illuminae.com> Message-ID: > I pointed you to this a couple of weeks ago and asked for your comments > (or at least, I think I did... maybe not to you directly, but to the > -dev list): > > http://biomoby.open-bio.org/index.php/for-developers/moby_extensions > Okay, this is the page I was hoping for. I am going to read it and make comments. I missed its existence so far. > The predicates have only recently been defined for Service Instances > since we have just finished working with myGrid > Mark, I think the sentence above describes the whole problem: it says "we have just finished". But who are we? That's just you. And perhaps Eddie. But who else is involved in what is going to happen with relationship between myGrid and Biomoby? We, people on moby-dev list, do not know (well, I should talk only for myself, sorry for that: I do not know). You have been talking about myGrid for a long time, but I have not seen any... well, not results, that would be too premature, but anything we can discuss. Mark, you built the Biomoby ideas (your ideas) into a running product, and you convinced people to build services accrodingly. That's good, and you have flowers for it. But the project will die if you keep it that way. You need more people to be involved in the decisions what next - and we have started, not perhaps too succesfully, but still - an RFC process. So why not to put the "myGrid stuff", whatever it means, into a proposal and we can discuss it? But give us some time to digest it. > In any case, I've listed all of the predicates on the new website, and > am starting to document them now... slowly! > Present them as a new RFC, not as something done - that would make me feel better. And an RFC has deadline, so if people do not respond in time, that's their decision, they cannot complain that they were put aside. > Some of them I cannot document since they are in the mygrid namespace, > and they aren't documented there (though I could guess). > Sorry to say that, but it seems like nonsense. We are talking about an interface (in whatever means, not necessarily an API) that will be used by developers, so it must be expressed in a way the humans will understand it. > > * Resolving LSID metadata has more steps than just to make an HTTP > >connection and to get an RDF file. But I guess that we want to > >recommend to use just this step. So we are slightly "abusing" (in a > >possitive way) the LSID spec, but we do not document it. > > > > > Can you write a sentence that explains this? I don't really understand > what you mean either... > Starting point is "I have an LSID". And I want metadata describing it. What are the steps to follow: 1) Resolve the LSID to an endpoint. 2) Call there a method getAvailableServices(myLSID) It gets back URls of all places that have anything to tell about this particular LSID 3) On each of this places you call getMetadata() My guess is that by "resolving LSID to metadata" you mean just the third step, and only if this particular site provides the metadata using a pure HTTP protocol, no SOAP. I am not saying that it is bad, but bad is not to document it properly... Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From tmo at ebi.ac.uk Tue Nov 29 16:03:32 2005 From: tmo at ebi.ac.uk (Tom Oinn) Date: Tue, 29 Nov 2005 16:03:32 +0000 Subject: [MOBY-dev] Error from taverna biomoby plugin Message-ID: <438C7BD4.7010204@ebi.ac.uk> Hi all, I'm getting an error from the biomoby scavenger : org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: Could not retrieve and or process RDF document for BioMoby Objects at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:189) at org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge rLoaderThread.run(ScavengerTree.java:327) Caused by: java.lang.NullPointerException at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:185) ... 1 more Any ideas? Was working until recently. Tom From edward.kawas at gmail.com Tue Nov 29 15:59:46 2005 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 29 Nov 2005 07:59:46 -0800 Subject: [MOBY-dev] Error from taverna biomoby plugin In-Reply-To: <438C7BD4.7010204@ebi.ac.uk> Message-ID: <000001c5f4fd$eccfc5f0$6700a8c0@notebook> Hi Tom, This is probably due to the server switch. I will look into it and get back to you. Thanks, Eddie -----Original Message----- From: moby-dev-bounces at biomoby.org [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Tom Oinn Sent: Tuesday, November 29, 2005 8:04 AM To: mobydev Subject: [MOBY-dev] Error from taverna biomoby plugin Hi all, I'm getting an error from the biomoby scavenger : org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: Could not retrieve and or process RDF document for BioMoby Objects at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:189) at org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge rLoaderThread.run(ScavengerTree.java:327) Caused by: java.lang.NullPointerException at org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav enger.java:185) ... 1 more Any ideas? Was working until recently. Tom _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Nov 29 16:14:20 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 29 Nov 2005 08:14:20 -0800 Subject: [MOBY-dev] [moby] Error from taverna biomoby plugin In-Reply-To: <438C7BD4.7010204@ebi.ac.uk> References: <438C7BD4.7010204@ebi.ac.uk> Message-ID: <1133280860.30604.7.camel@bioinfo.icapture.ubc.ca> I'm on it. a redirect isn't working, but I can't figure out why. M On Tue, 2005-11-29 at 16:03 +0000, Tom Oinn wrote: > Hi all, > > I'm getting an error from the biomoby scavenger : > > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: > Could not retrieve and or process RDF document for BioMoby Objects > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:189) > at > org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge > rLoaderThread.run(ScavengerTree.java:327) > Caused by: java.lang.NullPointerException > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:185) > ... 1 more > > Any ideas? Was working until recently. > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 From markw at illuminae.com Tue Nov 29 20:23:21 2005 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 29 Nov 2005 12:23:21 -0800 Subject: [MOBY-dev] [moby] Error from taverna biomoby plugin In-Reply-To: <438C7BD4.7010204@ebi.ac.uk> References: <438C7BD4.7010204@ebi.ac.uk> Message-ID: <1133295801.30604.132.camel@bioinfo.icapture.ubc.ca> Should be solved now M On Tue, 2005-11-29 at 16:03 +0000, Tom Oinn wrote: > Hi all, > > I'm getting an error from the biomoby scavenger : > > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: > Could not retrieve and or process RDF document for BioMoby Objects > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:189) > at > org.embl.ebi.escience.scuflui.workbench.ScavengerTree$DefaultScavenge > rLoaderThread.run(ScavengerTree.java:327) > Caused by: java.lang.NullPointerException > at > org.biomoby.client.taverna.plugin.BiomobyScavenger.(BiomobyScav > enger.java:185) > ... 1 more > > Any ideas? Was working until recently. > > Tom > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev -- "Ontologists do it with the edges!" Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274