From markw at illuminae.com Fri Sep 1 02:03:01 2006 From: markw at illuminae.com (mark wilkinson) Date: Fri, 1 Sep 2006 06:03:01 +0000 GMT Subject: [MOBY-dev] Cleaning out the test registry Message-ID: <851341673-1157090602-cardhu_blackberry.rim.net-13953-@engine19-cell01> Is anyone using the test registry (bioinfo.icapture.ubc.ca) in the next couple of weeks? I'm teaching a course on moby/taverna from the 10th to the 14th and I'd like to purge the test registry and bring the registry code and the test ontologies into sync with the real ones before that. Let me know if this is going to disrupt anyone elses courses or activities. It isn't necessary, but it's easier for the students to see what is going on if they have a clean slate to work with. (By the way, I'm happy to do this for ANYONE who asks!! Please feel free to request thius if you are teaching a workshop or something) Mark -- Mark Wilkinson ...on the road! From d.haase at gsf.de Mon Sep 4 05:07:33 2006 From: d.haase at gsf.de (Dirk Haase) Date: Mon, 4 Sep 2006 11:07:33 +0200 Subject: [MOBY-dev] MOBY Namespace URI confusion Message-ID: <200609041107.33524.d.haase@gsf.de> Hi all, this morning I learned that two different URIs in the definition of the 'moby' namespace are in use: 1 - xmlns:moby="http://www.biomoby.org/moby" 2 - xmlns:moby="http://www.biomoby.org/moby-s" The latter one is - as far as I see - only used by the Perl module MOBY::Client::Service for sending out service invocation messages. I would not bother about it, but it seems that MoSeS generated Services just can not deal with this, they require the first version. So I'm wondering, is this - a bug in the MoSeS XML parsers, which should not rely on a certain URI? - is the second URI version just wrong and the mentioned Perl module has to be changed? Or both? Best, dirk From markw at illuminae.com Mon Sep 4 10:36:46 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 4 Sep 2006 14:36:46 +0000 GMT Subject: [MOBY-dev] MOBY Namespace URI confusion In-Reply-To: <200609041107.33524.d.haase@gsf.de> References: <200609041107.33524.d.haase@gsf.de> Message-ID: <955595035-1157380635-cardhu_blackberry.rim.net-1275-@engine24-cell01> I'll change the moby-s one to "moby". Eddie and I discovered a couple of weeks ago that the SOAP::Lite parser fails to properly parse URI's containing a "-" character!! What a nightmare... Thanks for the heads-up about this one! M -- Mark Wilkinson ...on the road! -----Original Message----- From: Dirk Haase Date: Mon, 4 Sep 2006 11:07:33 To:Moby-dev at biomoby.org Subject: [MOBY-dev] MOBY Namespace URI confusion Hi all, this morning I learned that two different URIs in the definition of the 'moby' namespace are in use: 1 - xmlns:moby="http://www.biomoby.org/moby" 2 - xmlns:moby="http://www.biomoby.org/moby-s" The latter one is - as far as I see - only used by the Perl module MOBY::Client::Service for sending out service invocation messages. I would not bother about it, but it seems that MoSeS generated Services just can not deal with this, they require the first version. So I'm wondering, is this - a bug in the MoSeS XML parsers, which should not rely on a certain URI? - is the second URI version just wrong and the mentioned Perl module has to be changed? Or both? Best, dirk _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Sep 4 10:36:46 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 4 Sep 2006 14:36:46 +0000 GMT Subject: [MOBY-dev] MOBY Namespace URI confusion In-Reply-To: <200609041107.33524.d.haase@gsf.de> References: <200609041107.33524.d.haase@gsf.de> Message-ID: <955595035-1157380635-cardhu_blackberry.rim.net-1275-@engine24-cell01> I'll change the moby-s one to "moby". Eddie and I discovered a couple of weeks ago that the SOAP::Lite parser fails to properly parse URI's containing a "-" character!! What a nightmare... Thanks for the heads-up about this one! M -- Mark Wilkinson ...on the road! -----Original Message----- From: Dirk Haase Date: Mon, 4 Sep 2006 11:07:33 To:Moby-dev at biomoby.org Subject: [MOBY-dev] MOBY Namespace URI confusion Hi all, this morning I learned that two different URIs in the definition of the 'moby' namespace are in use: 1 - xmlns:moby="http://www.biomoby.org/moby" 2 - xmlns:moby="http://www.biomoby.org/moby-s" The latter one is - as far as I see - only used by the Perl module MOBY::Client::Service for sending out service invocation messages. I would not bother about it, but it seems that MoSeS generated Services just can not deal with this, they require the first version. So I'm wondering, is this - a bug in the MoSeS XML parsers, which should not rely on a certain URI? - is the second URI version just wrong and the mentioned Perl module has to be changed? Or both? Best, dirk _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From Yogaraj.Khanal at usd.edu Mon Sep 4 21:33:51 2006 From: Yogaraj.Khanal at usd.edu (Yogaraj Khanal) Date: Mon, 04 Sep 2006 20:33:51 -0500 Subject: [MOBY-dev] hi Message-ID: <44FCD3FF.50307@usd.edu> i am new developer of jMoby.Please suggest me the fastest way to do so. Regards, Yogaraj From markw at illuminae.com Tue Sep 5 11:50:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 05 Sep 2006 08:50:51 -0700 Subject: [MOBY-dev] [moby] MOBY Namespace URI confusion In-Reply-To: <200609041107.33524.d.haase@gsf.de> References: <200609041107.33524.d.haase@gsf.de> Message-ID: <1157471451.1578.27.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-09-04 at 11:07 +0200, Dirk Haase wrote: > Hi all, > > this morning I learned that two different URIs in the definition of the 'moby' > namespace are in use: > 1 - xmlns:moby="http://www.biomoby.org/moby" > 2 - xmlns:moby="http://www.biomoby.org/moby-s" > > The latter one is - as far as I see - only used by the Perl module > MOBY::Client::Service for sending out service invocation messages. I've just looked at the code and the only line in MOBY::Client::Service that uses it is commented-out...?? I don't think that namespace URI is used at all in the Perl MOBY code anymore. If you do find it somewhere please let me know. M From gordonp at ucalgary.ca Tue Sep 5 12:25:07 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 05 Sep 2006 10:25:07 -0600 Subject: [MOBY-dev] hi In-Reply-To: <44FCD3FF.50307@usd.edu> References: <44FCD3FF.50307@usd.edu> Message-ID: <44FDA4E3.3020302@ucalgary.ca> Hi Yogaraj, If mean that you want to be a new service provider, I think The Extremely Lazy Programmer guide is what you need: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html You should be able to deploy a test service in less than 30 minutes, starting with nothing but a JDK... Regards, Paul Yogaraj Khanal wrote: > i am new developer of jMoby.Please suggest me the fastest way to do so. > Regards, > Yogaraj > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From edward.kawas at gmail.com Tue Sep 5 12:08:47 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 5 Sep 2006 09:08:47 -0700 Subject: [MOBY-dev] hi In-Reply-To: <44FCD3FF.50307@usd.edu> Message-ID: <000701c6d105$92894870$756fa8c0@notebook> The best place to start is: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/ Good luck, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Yogaraj Khanal > Sent: Monday, September 04, 2006 6:34 PM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] hi > > i am new developer of jMoby.Please suggest me the fastest way > to do so. > Regards, > Yogaraj > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Sep 5 15:14:39 2006 From: d.haase at gsf.de (Haase, Dirk) Date: Tue, 5 Sep 2006 21:14:39 +0200 Subject: [MOBY-dev] [moby] MOBY Namespace URI confusion References: <200609041107.33524.d.haase@gsf.de> <1157471451.1578.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <1D78CE9FD586024AB0E0102F6F9A7CF86A0895@sw-rz010.gsf.de> Oh, I'm so sorry, I missed that CVS update... OK, it's rather new (8 weeks) but I should have checked before writing to the list :-| However, thanks for assist, dirk -----Original Message----- From: moby-dev-bounces at lists.open-bio.org on behalf of Mark Wilkinson Sent: Tue 9/5/2006 5:50 PM To: Core developer announcements Subject: Re: [MOBY-dev] [moby] MOBY Namespace URI confusion On Mon, 2006-09-04 at 11:07 +0200, Dirk Haase wrote: > Hi all, > > this morning I learned that two different URIs in the definition of the 'moby' > namespace are in use: > 1 - xmlns:moby="http://www.biomoby.org/moby" > 2 - xmlns:moby="http://www.biomoby.org/moby-s" > > The latter one is - as far as I see - only used by the Perl module > MOBY::Client::Service for sending out service invocation messages. I've just looked at the code and the only line in MOBY::Client::Service that uses it is commented-out...?? I don't think that namespace URI is used at all in the Perl MOBY code anymore. If you do find it somewhere please let me know. M _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Tue Sep 5 15:42:17 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 5 Sep 2006 12:42:17 -0700 Subject: [MOBY-dev] RDF agent Message-ID: <001701c6d123$6600d930$756fa8c0@notebook> Hi Again, The agent has been updated once again and the updates have been deployed. Key changes to the agent include: 1. LSIDs are ignored by the agent. So the old prerequisite of having to modify the services LSID to cause the agent to process an update is gone. 2. Services that have null signature urls are considered test services and are not processed. 3. Messages received from the agent are more concise (hopefully) and to the point. 4. One message is sent to a single address outlining the changes to all services mapped to that address, instead of one message per service being sent out. 5. Services found to be described by 2 different signatureURL are not processed (security reasons). Hopefully the agent wont upset anyone this time and I wont have to spend too much time filtering out the hate mail ;-) On Friday, I will invoke the agent on the registry and service providers may get a message regarding their services if their services have been updated, removed or if new services have been found in their RDF documents. If you have already downloaded the service description RDF, I would encourage you to use the agent test page at: http://bioinfo.icapture.ubc.ca/ekawas/agent/RDFAgent_test.html. I have noticed during the testing of the agent, that some peoples default/max/min values for secondary parameters are not in sync with the registry. This may be on purpose, but I wanted to give you all a heads up. Using the test page, you can verify the inputs/outputs for your service. If you have any concerns, please let me know! Thanks, Eddie From d.haase at gsf.de Wed Sep 6 02:59:06 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 6 Sep 2006 08:59:06 +0200 Subject: [MOBY-dev] hi In-Reply-To: <44FCD3FF.50307@usd.edu> References: <44FCD3FF.50307@usd.edu> Message-ID: <200609060859.06434.d.haase@gsf.de> Hello Yogaraj, On Tuesday 05 September 2006 03:33, Yogaraj Khanal wrote: > i am new developer of jMoby.Please suggest me the fastest way to do so. In addition to the places already mentioned here, you may also have a look at http://bioinfo.mpiz-koeln.mpg.de/araws/documentation/help/jmoby-step-by-step/ Some real-world example code is here: https://biomoby.tigr.org/wiki/index.php/Code_Examples_-_Java Regards, dirk From gordonp at ucalgary.ca Wed Sep 6 10:02:46 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 06 Sep 2006 08:02:46 -0600 Subject: [MOBY-dev] hi In-Reply-To: <200609060859.06434.d.haase@gsf.de> References: <44FCD3FF.50307@usd.edu> <200609060859.06434.d.haase@gsf.de> Message-ID: <44FED506.5090007@ucalgary.ca> Hi Dirk, Maybe you should link to these from the jMOBY homepage: I'm sure they'd be useful to other developers, as they are not Arabidopsis specific... Regards, Paul > Hello Yogaraj, > > On Tuesday 05 September 2006 03:33, Yogaraj Khanal wrote: > >> i am new developer of jMoby.Please suggest me the fastest way to do so. >> > > In addition to the places already mentioned here, you may also have a look at > http://bioinfo.mpiz-koeln.mpg.de/araws/documentation/help/jmoby-step-by-step/ > > Some real-world example code is here: > https://biomoby.tigr.org/wiki/index.php/Code_Examples_-_Java > > Regards, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From johan at ac.uma.es Wed Sep 6 10:13:27 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Wed, 06 Sep 2006 16:13:27 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - The location of queryIDs In-Reply-To: References: Message-ID: <44FED787.5010002@ac.uma.es> Pieter, Thank you for a well written letter (and sorry for the delay in answering). > There is only one thing that I don't like about the current proposal: > the location of queryID. For our current synchronous services it's an > attribute of the mobyData element. In the current async services > proposal the queryID jumps around the XML taking several identities: > * in status_queryID01 it > is part of raw text. > * in lsae:status_queryID01> it is part of an element name in the lsae > namespace. > (By the way: Should this element really be in the lsae namespace? I > don't think our status_queryIDxx elements are part of the LSAE specs...) > True, we need to put a better namespace, moby? > It would be > much more convenient if the result from a asynchronous service > invocation would contain both the ServiceInvocationID *AND* the > associated queryIDs. In that case I only have to parse the service > response to create GetResourceProperty requests. Therefore I propose > to supply the queryIDs as wsa:ReferenceParameters just like the > ServiceInvocationID. > I am not sure that I understand the problem completely... The clients must internally store, somehow, the connection between the input (identified by the queryID) and the output? The jobs could, potentially, take a very long time to finish and without knowing the input, getting the output would not be so interesting. Anyway, it is not so complicated to handle the queryIDs for the client (see some of the example code of the client at the prototype page). Maybe it is another situation that you are describing than the one in the example? Can you give some examples where it would be necessary to return the queryIDs? Again, not sure if I understand. http://bioinfo.pcm.uam.es/prototype/ > 2. > WSRF contains an *optional* method to request a resource properties > document. With this method a client can figure out which resource > properties are available and hence what it can request. Although this > method is optional and the current proposal doesn't mention it, I > think it would good to keep the option open to supply such a method. > WSRF does not put any limitations on how a service generates and > provides such a document, so you can generate it dynamically or it > can be a static thing. If we would want to supply such a resource > properties document in the future it would be the easiest if it can > be a static one. However in the current proposal the queryIDs are > part of the resource properties (status_queryIDxx and > result_queryIDxx). This means that the available resource properties > depend on the amount of queries/jobs that were sent to a service and > hence we can not use a static resource properties document. It would > be more convenient if we can strip the queryIDs from the resource > properties and provide them as wsa:ReferenceParameters. In that case > there are only two resource properties (status and result) and we can > describe those in a static resource properties document. At least until now, we have tried to only include exactly what is needed and avoid many, potentially, useful but maybe more complicated WSRF methods. Yes, the WSRF method GetResourcePropertyDocument could be useful but it is possible to manage without it since the clients would always be able to construct the property qnames as long as they keep track of the queryIDs. But of course, if there is a great demand for this optional WSRF-method we could add it to the documentation. > Therefore I propose a translocation of BioMOBY queryIDs from the > resource properties to wsa:ReferenceParameters. As far as I > understand, with all the specifications involved this would be legal, > but please correct me if I am wrong. Below I included some examples > of what the XML might look like when the queryIDs are moved to the > SOAP header as wsa:ReferenceParameters. Let me know what you think.... The problem (?) is that the EPR is supposed to be opaque, or in particular, the ReferenceParameter () should be "assumed to be opaque" for the clients. "Reference parameters are also provided by the issuer of the endpoint reference and are otherwise assumed to be opaque to consuming applications." (quoting from the WS-Addressing standard that WSRF builds upon) At least my interpretation of this is that clients are not supposed to understand or parse or manipulate the reference-parameter but instead just echo it back (if I am confused please correct me)? Yes, the reference-parameter can be given as XML but this XML should not be modified by the clients (I assume that you mean that the clients should just include the tags that they need to find status or results for particular jobs in the batch-call). The issuer of the endpoint reference naturally must handle the EPR but the clients should not try to understand the EPR. Also, conceptually, the EPR refers to a specific resource (in this case what we call "batch-call", many jobs). If we manipulate the EPR we "change" its original reference. We tried to clearly define in the proposal what the EPR refered to (what the "resource" was). Manipulating the EPR in some way confuses what it refers to. ------------------- Regarding "dynamic" property names (status_{queryID}); the official WSRF specification mandates that all properties of a resource MUST be described by a XML Schema but this is not strictly enforced in the library we used for the Perl examples (WSRF::Lite) (or at least, in the examples of WSRF::Lite that I have seen there is no such XML schema file) . Just to give an example to give an idea of what I am talking about (non BioMOBY...): This resource has four properties (tns:NumberOfBlocks, tns:BlockSize, tns:Manufacturer and finally tns:StorageCapability). The qnames of these four properties are pre-defined/fixed and not like what we need "status_q1", "status_q2" etc etc. We would need that the resource properties schema allows open content (using a xsd:any element). This means that the list of valid qnames for the resource properties is "open". See "3.3.1.1 Establishing a List of Valid Resource Properties" in "WSRF Application Notes" (http://docs.oasis-open.org/wsrf/wsrf-application_notes-1.2-cd-02.pdf) for more information. Kind regards, Johan Karlsson -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From d.haase at gsf.de Thu Sep 7 05:26:57 2006 From: d.haase at gsf.de (Dirk Haase) Date: Thu, 7 Sep 2006 11:26:57 +0200 Subject: [MOBY-dev] hi In-Reply-To: <44FED506.5090007@ucalgary.ca> References: <44FCD3FF.50307@usd.edu> <200609060859.06434.d.haase@gsf.de> <44FED506.5090007@ucalgary.ca> Message-ID: <200609071126.58026.d.haase@gsf.de> On Wednesday 06 September 2006 16:02, Paul Gordon wrote: > Hi Dirk, > > Maybe you should link to these from the jMOBY homepage: I'm sure they'd > be useful to other developers, as they are not Arabidopsis specific... Yes, of course, this was on my to-do list for a long time... Now it's done. Thanks for reminder! dirk From edward.kawas at gmail.com Thu Sep 7 18:22:39 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 7 Sep 2006 15:22:39 -0700 Subject: [MOBY-dev] Articlenames Message-ID: <001901c6d2cc$21f82630$6400a8c0@notebook> Hi, I have just committed code that prohibits the registry from registering services and datatypes that have articlenames that contain spaces or special characters `~!@#$%^&*()=+;:'"<,>./?\|. I did this because having those characters prohibits us from expressing the Datatype ontology in OWL. There are a few offending datatypes that currently make use of these characters and hopefully I can track down the people who registered them and ask them to re-register the datatypes. If you know offhand that you may have done this, could you fix your datatypes. Thanks, Eddie From markw at illuminae.com Thu Sep 7 19:29:55 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 07 Sep 2006 16:29:55 -0700 Subject: [MOBY-dev] [moby] Articlenames In-Reply-To: <001901c6d2cc$21f82630$6400a8c0@notebook> References: <001901c6d2cc$21f82630$6400a8c0@notebook> Message-ID: <1157671795.8831.26.camel@bioinfo.icapture.ubc.ca> Hi all, If you have any objections to this, please flame me, not Eddie. He asked me, and I told him to go ahead without properly thinking about it; however now I am having second thoughts. MOBY Central is still using the old codebase, so no worries there. For data-types, it is clear that we have to follow the rules for data- typing that XML places on us. Since data-types in MOBY become XML tags, those rules are pretty restrictive, but generally speaking there aren't any troublesome ones in the registry right now. We do have a problem with some of the Gene Ontology-created namespaces having a second ":" character in them, but I am going to talk to Midori about this ASAP! Hopefully we can get rid of those. However, for articleNames, the XML rules are a lot looser, since these are represented in MOBY as XML attribute values. There are already some articleNames in the object ontology that contain spaces, and those don't particularly concern me (are they causing problems for anyone else?); however other unusual characters might cause problems if the code isn't expecting them. It would be a change in the API if we were to impose limitations on the articleName character-set at this point, but it wont affect most (any?) existing objects or services. Does anyone object to putting a restriction on the characters that can be used in articleNames? Either way, we should probably make an explicit note in the API about what characters are acceptable, even if we simply say "any". M On Thu, 2006-09-07 at 15:22 -0700, Edward Kawas wrote: > Hi, > > I have just committed code that prohibits the registry from registering services > and datatypes that have articlenames that contain spaces or special characters > `~!@#$%^&*()=+;:'"<,>./?\|. > > I did this because having those characters prohibits us from expressing the > Datatype ontology in OWL. > > There are a few offending datatypes that currently make use of these characters > and hopefully I can track down the people who registered them and ask them to > re-register the datatypes. > > If you know offhand that you may have done this, could you fix your datatypes. > > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Fri Sep 8 10:06:37 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 08 Sep 2006 08:06:37 -0600 Subject: [MOBY-dev] [moby] Articlenames In-Reply-To: <1157671795.8831.26.camel@bioinfo.icapture.ubc.ca> References: <001901c6d2cc$21f82630$6400a8c0@notebook> <1157671795.8831.26.camel@bioinfo.icapture.ubc.ca> Message-ID: <450178ED.90508@ucalgary.ca> No complaints here! Both ampersand and blackslash seem like they could have especially nasty consequences in downstream code... > Hi all, > > If you have any objections to this, please flame me, not Eddie. He > asked me, and I told him to go ahead without properly thinking about it; > however now I am having second thoughts. MOBY Central is still using > the old codebase, so no worries there. > > For data-types, it is clear that we have to follow the rules for data- > typing that XML places on us. Since data-types in MOBY become XML tags, > those rules are pretty restrictive, but generally speaking there aren't > any troublesome ones in the registry right now. We do have a problem > with some of the Gene Ontology-created namespaces having a second ":" > character in them, but I am going to talk to Midori about this ASAP! > Hopefully we can get rid of those. > > However, for articleNames, the XML rules are a lot looser, since these > are represented in MOBY as XML attribute values. There are already some > articleNames in the object ontology that contain spaces, and those don't > particularly concern me (are they causing problems for anyone else?); > however other unusual characters might cause problems if the code isn't > expecting them. > > It would be a change in the API if we were to impose limitations on the > articleName character-set at this point, but it wont affect most (any?) > existing objects or services. Does anyone object to putting a > restriction on the characters that can be used in articleNames? Either > way, we should probably make an explicit note in the API about what > characters are acceptable, even if we simply say "any". > > M > > > > > On Thu, 2006-09-07 at 15:22 -0700, Edward Kawas wrote: > >> Hi, >> >> I have just committed code that prohibits the registry from registering services >> and datatypes that have articlenames that contain spaces or special characters >> `~!@#$%^&*()=+;:'"<,>./?\|. >> >> I did this because having those characters prohibits us from expressing the >> Datatype ontology in OWL. >> >> There are a few offending datatypes that currently make use of these characters >> and hopefully I can track down the people who registered them and ask them to >> re-register the datatypes. >> >> If you know offhand that you may have done this, could you fix your datatypes. >> >> Thanks, >> >> Eddie >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From jatorre at gmail.com Sat Sep 16 07:40:43 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Sat, 16 Sep 2006 13:40:43 +0200 Subject: [MOBY-dev] Registering a MOBY service Message-ID: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> Hi, I am trying to register a service on the BioMOBY registry and I am having some troubles. I am using Dashboard for this. Everything goes right if I try to register the service with this service endpoint: http://synthesys.csic.es:8080/tapir/pywrapper?dsa=training But if I try it to register this one: http://synthesys.csic.es:8080/tapir/pywrapper? dsa=training&protocol=biomoby&serviceName=getCoordinatesOfTaxon Then I get an empty error from the registry, just a "null" Seems that the problem has to do with the & on the url. Is this by purpose? Why I need to register such an ugle end point is another discussion, but not very relevant. Thanks in advance. Javier. From martin.senger at gmail.com Sat Sep 16 08:01:38 2006 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 16 Sep 2006 09:01:38 -0300 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> Message-ID: <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> Javier, Seems that the problem has to do with the & on the url. If the problem is with &, then it may be that the dashboard does not properly escape it in the registration request. I will look at it but I am still "on the move", so I have still only a limited access to dashboard to test it. Sorry again for the delay. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Sat Sep 16 10:13:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 16 Sep 2006 11:13:36 -0300 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <44F2F7D8.1050905@ucalgary.ca> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <44F072E9.5050206@ebi.ac.uk> <44F2F7D8.1050905@ucalgary.ca> Message-ID: <4d93f07c0609160713q4ce5c3f5r5a9c5e0da90b6762@mail.gmail.com> > With regards to Martin's mail, I don't think usurping the Service type > is a good idea (if I understand the idea correctly, which I may not). Yes, you don't :-) I have not been talking about a Service type.I meant a "category". An attribute used in a registration request. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Sat Sep 16 21:22:48 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Sun, 17 Sep 2006 03:22:48 +0200 Subject: [MOBY-dev] Example of a response message with SOAP envelope Message-ID: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> Hi all, I am encountering some problems creating my services. I am not using any SOAP library so I have to deal with the details of the xml messages being sent. In the BioMOBY website there are some example of request/responses of moby services, but only with the payload, that is starting with MOBY. I was wondering if someone could send me an example response from a MOBY service including the SOAP envelope. Thanks in advance. Javier. From johan at ac.uma.es Mon Sep 18 05:40:59 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Mon, 18 Sep 2006 11:40:59 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Message-ID: <450E69AB.2000104@ac.uma.es> Martin Senger wrote: > Sorry, I was not able to read the new proposal when it came. I am still not > able to read it in all details (I am traveling and will be actually > completely off-line next two weeks) - but I think that the proposal is fine > and I would for with it. Thanks for creating it. > > Just two comments: > > I agree that storing the fact that a service is able to be called > asynchronously should be part of the service registration process. That > would simplify everything. But I do not fully understand why it cannot be > done only by registering a service with a new category (moby-async, as > suggested). Why do we need a new boolean parameter for it? Why do we need > 'hasCallingDetail" - here again a new category should be enough. What am I > missing? > Sorry, missed to answer this comment. Yes, you are right, in the RDF for service instances there is a predicate called dc:format. Currently, the only allowed value is "BioMoby_service" (I guess this is related to the allowed _three_ values in the registration 'moby', 'cgi' and 'soap'). Could someone with good insight of how this was originally designed let us know if it is ok to add another allowed value to this predicate (dc:format)? It says something that this is an ontology term from the myGrid ontology? http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/moby_metadata Or is there a good argument for keeping the 'hasCallingDetail'? Kind regards, Johan -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From markw at illuminae.com Mon Sep 18 10:47:17 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 07:47:17 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <450E69AB.2000104@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <450E69AB.2000104@ac.uma.es> Message-ID: > Yes, you are right, in the RDF for service instances there is a > predicate called dc:format. Currently, the only allowed value is > "BioMoby_service" (I guess this is related to the allowed _three_ values > in the registration 'moby', 'cgi' and 'soap'). It is related. When we first proposed this predicate to myGrid we suggested moby, cgi, and soap; however myGrid already had a terminology for the predecessor to that predicate. Since we (moby) had not been using RDF up to that point, and thus had no "legacy" to support, we agreed to their terminology without hesitation. > let us know if it is ok to > add another allowed value to this predicate (dc:format)? It says > something that this is an ontology term from the myGrid ontology? I believe it is in the myGrid ontology somewhere. Give me a minute or two and I'll see if I can find it. If necessary, we only need to let the Manchester group know that we want to add a new value and I'm sure there will be no argument from them. Mark -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From markw at illuminae.com Mon Sep 18 10:47:17 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 07:47:17 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <450E69AB.2000104@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <450E69AB.2000104@ac.uma.es> Message-ID: > Yes, you are right, in the RDF for service instances there is a > predicate called dc:format. Currently, the only allowed value is > "BioMoby_service" (I guess this is related to the allowed _three_ values > in the registration 'moby', 'cgi' and 'soap'). It is related. When we first proposed this predicate to myGrid we suggested moby, cgi, and soap; however myGrid already had a terminology for the predecessor to that predicate. Since we (moby) had not been using RDF up to that point, and thus had no "legacy" to support, we agreed to their terminology without hesitation. > let us know if it is ok to > add another allowed value to this predicate (dc:format)? It says > something that this is an ontology term from the myGrid ontology? I believe it is in the myGrid ontology somewhere. Give me a minute or two and I'll see if I can find it. If necessary, we only need to let the Manchester group know that we want to add a new value and I'm sure there will be no argument from them. Mark -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From markw at illuminae.com Mon Sep 18 13:32:26 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 10:32:26 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> Message-ID: <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> INPUT AND OUTPUT EXAMPLE: INPUT: SOAP::Transport::HTTP::Client::send_receive: POST http://mobycentral.icapture.ubc.ca/cgi-bin/Services/Services.cgi HTTP/1.1 Accept: text/xml Accept: multipart/* Content-Length: 930 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://biomoby.org/#getDragonAllelesByKeyword" <?xml version='1.0' encoding='UTF-8'?> <moby:MOBY xmlns:moby='http://www.biomoby.org/moby' moby:smessageVersion='0.87'> <moby:mobyContent> <moby:mobyData queryID='1'><moby:Simple moby:articleName=''> <Object namespace="Global_Keyword" id="petal"/> </moby:Simple> </moby:mobyData> </moby:mobyContent> </moby:MOBY> SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK Connection: close OUTPUT ( content is base64 encoded) Server: Apache/2.0.54 (Unix) DAV/2 mod_perl/2.0.1 Perl/v5.8.5 Content-Length: 885 Content-Type: text/xml; charset=utf-8 Client-Date: Mon, 18 Sep 2006 17:30:06 GMT Client-Peer: 127.0.0.1:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.60 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48bW9ieTpNT0JZIHhtbG5zOm1vYnk9J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieScgeG1sbnM9J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieSc+PG1vYnk6bW9ieUNvbnRlbnQgbW9ieTphdXRob3JpdHk9J2lsbHVtaW5hZS5jb20nPjxtb2J5Om1vYnlEYXRhIG1vYnk6cXVlcnlJRD0nMScvPjwvbW9ieTptb2J5Q29udGVudD48L21vYnk6TU9CWT4= On Sun, 2006-09-17 at 03:22 +0200, Javier de la Torre wrote: > Hi all, > > I am encountering some problems creating my services. I am not using > any SOAP library so I have to deal with the details of the xml > messages being sent. In the BioMOBY website there are some example of > request/responses of moby services, but only with the payload, that > is starting with MOBY. > > I was wondering if someone could send me an example response from a > MOBY service including the SOAP envelope. > > Thanks in advance. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Mon Sep 18 14:10:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 11:10:02 -0700 Subject: [MOBY-dev] MOBY Central going down for 15 minutes for a RAM upgrade Message-ID: <1158603002.18578.20.camel@bioinfo.icapture.ubc.ca> Hi all, In one hour we're going to shut-down MOBY Central for just long enough to stick another 2Gig of RAM in it. Shouldn't be more than 15 minutes. Please scream if this is a problem for you! M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From jatorre at gmail.com Mon Sep 18 18:16:07 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 00:16:07 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> Hi Mark, Thanks for this. I finally used a tracing program to see the interaction with some services. Now I am happy to announce that our software, PyWrapper, can serve BioMOBY services based on templates. We will have a release of the software with BioMOBY support by the end of the month, and then probably, and hopefully!, you will start seeing lot of new services appearing on the registry. But I have to ask... why are you sending the MOBY xml as an escaped string? I understand that you can not create a fix XML schema for the whole thing but at least you can have a simple schema with a mobyContent element and a xsd:any on it right? In any case, why are you using SOAP? Just for the error handling? The services like this does not look very interoperable with anything but BioMOBY clients. Is actually just curiosity.... Javier. On 18/09/2006, at 19:32, Mark Wilkinson wrote: > INPUT AND OUTPUT EXAMPLE: > > INPUT: > > > SOAP::Transport::HTTP::Client::send_receive: POST > http://mobycentral.icapture.ubc.ca/cgi-bin/Services/Services.cgi > HTTP/1.1 > Accept: text/xml > Accept: multipart/* > Content-Length: 930 > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://biomoby.org/#getDragonAllelesByKeyword" > > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP- > ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- > ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP- > ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> ENV:Body> xmlns:namesp3="http://biomoby.org/"> xsi:type="xsd:string"><?xml > version='1.0' encoding='UTF-8'?> > <moby:MOBY xmlns:moby='http://www.biomoby.org/moby' > moby:smessageVersion='0.87'> > <moby:mobyContent> > <moby:mobyData queryID='1'><moby:Simple > moby:articleName=''> > > <Object namespace="Global_Keyword" id="petal"/> > > </moby:Simple> > </moby:mobyData> > > </moby:mobyContent> > > </moby:MOBY> ENV:Body> > SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK > Connection: close > > > > > > > > OUTPUT ( content is base64 encoded) > > > Server: Apache/2.0.54 (Unix) DAV/2 mod_perl/2.0.1 Perl/v5.8.5 > Content-Length: 885 > Content-Type: text/xml; charset=utf-8 > Client-Date: Mon, 18 Sep 2006 17:30:06 GMT > Client-Peer: 127.0.0.1:80 > Client-Response-Num: 1 > SOAPServer: SOAP::Lite/Perl/0.60 > > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP- > ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- > ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP- > ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> ENV:Body> xmlns:namesp1="http://biomoby.org/">PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48bW9ieT > pNT0JZIHhtbG5zOm1vYnk9J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieScgeG1sbnM9 > J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieSc > +PG1vYnk6bW9ieUNvbnRlbnQgbW9ieTphdXRob3JpdHk9J2lsbHVtaW5hZS5jb20nPjxtb > 2J5Om1vYnlEYXRhIG1vYnk6cXVlcnlJRD0nMScvPjwvbW9ieTptb2J5Q29udGVudD48L21 > vYnk6TU9CWT4= namesp1:getDragonAllelesByKeywordResponse> ENV:Envelope> > > > > > > > > > > > > > > On Sun, 2006-09-17 at 03:22 +0200, Javier de la Torre wrote: >> Hi all, >> >> I am encountering some problems creating my services. I am not using >> any SOAP library so I have to deal with the details of the xml >> messages being sent. In the BioMOBY website there are some example of >> request/responses of moby services, but only with the payload, that >> is starting with MOBY. >> >> I was wondering if someone could send me an example response from a >> MOBY service including the SOAP envelope. >> >> Thanks in advance. >> >> Javier. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Sep 18 19:20:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 16:20:58 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> Message-ID: <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> Hi Javier! > end of the month, and then probably, and hopefully!, you will start > seeing lot of new services appearing on the registry. Fantastic! Looking forward to it! > But I have to ask... why are you sending the MOBY xml as an escaped > string? Because it is illegal to have an tag in the middle of an XML document. (API notes: http://biomoby.open-bio.org/CVS_CONTENT/moby- live/Docs/MOBY-S_API/InputMessage.html and the bottom of http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY- S_API/MessageStructure.html) we either escape it, or we base64 encode it. Either way, what you get from the SOAP payload is a fully-qualified XML document including the XML header such that you can simply pass it to an XML parser verbatim. When I wrote that part of the API I was thinking about future extensibility into non-SOAP messages, where there would be the need for an XML header... it never happened, of course... > In any case, why are you using SOAP? LOL! I often wish we weren't! ;-) It's all historical - Web Services are historically described as a triad of the SOAP/WSDL/UDDI technologies. It seems that UDDI has been more or less lost from this triad, but SOAP/WSDL are still part of the most widely-used definition. Several years ago, for my own amusement, I constructed a pure-CGI version of MOBY, and it worked just fine... so there's no good argument for using SOAP (especially since we can't model MOBY messages in XML schema, so the WSDL standard isn't particularly useful to us either!) > Just for the error handling? The > services like this does not look very interoperable with anything but > BioMOBY clients. Well... In my opinion, Web Services aren't particularly interoperable, period. It is only by our syntactic agreement that MOBY services become interoperable, which is what puts us one step ahead of other interoperability projects. Take any two arbitrary Web Services out there and try to automatically feed the output of one into the input of another :-) Kaboom! As such, I don't see that MOBY is any less interoperable with non-MOBY web services than they are with each other, with the exception that we pass XML rather than raw data. M From markw at illuminae.com Mon Sep 18 23:19:45 2006 From: markw at illuminae.com (markw at illuminae.com) Date: Mon, 18 Sep 2006 23:19:45 -0400 Subject: [MOBY-dev] post-memory-upgrade check Message-ID: <20060918231945.uzwp9x04tw8gc0s4@webmail.illuminae.com> Hi all, MOBY Central (in Vancouver) is now working on its memory upgrade. Please let me know ASAP if you experience anything yucky! I noticed during my last workshop that if you tell all 30 students to hit the "query" button at the same time the registry machine crashes with an "out of memory" error in the system logs, so that's not good! Hopefully it will be more robust from now on. The solution, of course, is to improve on the existing codebase... as many MOBYers have pointed out, I'm "just a biologist" and really shouldn't be coding production systems under *any* circumstances! :-) I agree entirely! Now that we have implemented a (distributed) RDF representation of the registry, there are all sorts of new paradigms we could imagine for registry implementation, and these are best done in Java, since there is only minimal support for RDF in Perl at the moment... I'm going to ask Eddie to consider the possibilities for re-writing the entire registry in Java using an RDF store as the underlying database. We will NOT do this without having a face-to-face meeting with the curent (5?) registry providers to ensure that the migration is painless, but I do think that it is perhaps the best way to move the project forward. In particular, we want to move it out of the current Perl implementation into Java, which seems to be more familiar for most developers (and more powerful at the end of the day). Still, no need to panic. We can talk about this at the next developers meeting. I'm trying to find the funds to help host this meeting... stay tuned! Anyway, please test the registry using whatever mechanism you usually use to access it and let me know ASAP if you notice any problems. Hopefully the new memory is sufficient to get us through the next few months. Nevertheless, the hits on the registry are still increasing monthly, so a new architecture will have to be implemented soon... Best wishes all! Mark From d.haase at gsf.de Tue Sep 19 04:13:30 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 19 Sep 2006 10:13:30 +0200 Subject: [MOBY-dev] post-memory-upgrade check In-Reply-To: <20060918231945.uzwp9x04tw8gc0s4@webmail.illuminae.com> References: <20060918231945.uzwp9x04tw8gc0s4@webmail.illuminae.com> Message-ID: <200609191013.30969.d.haase@gsf.de> On Tuesday 19 September 2006 05:19, markw at illuminae.com wrote: > Hi all, > > MOBY Central (in Vancouver) is now working on its memory upgrade. > Please let me know ASAP if you experience anything yucky! Taverma is not able to load the Biomoby scavenger. It fails with the following error: Failed: Server returned HTTP response code: 400 for URL: http://mobycentral.icapture.ubc.ca/RESOURCES/MOBY-S/Objects [Ljava.lang.StackTraceElement;@1f99e90 ERROR 2006-09-19 10:08:04,838 (org.embl.ebi.escience.scuflui.workbench.ScavengerTree:341) - org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: Could not retrieve and or process RDF document for BioMoby Objects Best, dirk From jatorre at gmail.com Tue Sep 19 08:37:41 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 14:37:41 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> Message-ID: <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> Hi Mark, > > Because it is illegal to have an tag in the middle of an XML > document. (API notes: http://biomoby.open-bio.org/CVS_CONTENT/moby- > live/Docs/MOBY-S_API/InputMessage.html and the bottom of > http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY- > S_API/MessageStructure.html) > Yes, I know that, but I was wondering why you need to have a full XML message as the payload and not rather the normal way of integrating your xml inside with a different namespace. You could actually have a simple mobyMessage type that defines the mobyContent. And actually you go further because, as far as I understood every moby response message will have then a mobyData element and then a simple or collection element... (By the way! wouldnt be bad to include at least one full xml messages, with the SOAP envelope, on the documentation) > we either escape it, or we base64 encode it. Either way, what you get > from the SOAP payload is a fully-qualified XML document including the > XML header such that you can simply pass it to an XML parser verbatim. > When I wrote that part of the API I was thinking about future > extensibility into non-SOAP messages, where there would be the need > for > an XML header... it never happened, of course... > But this is also possible. In a WSDL file you can define other things than SOAP. For example RESTful services can be described with WSDL files too. > > Several years ago, for my own amusement, I constructed a pure-CGI > version of MOBY, and it worked just fine... so there's no good > argument > for using SOAP (especially since we can't model MOBY messages in XML > schema, so the WSDL standard isn't particularly useful to us either!) > The kind of MOBY services we create can very well described using a WSDL file because our outputs will always be the same and therefore could be typed with xml schema. And a way to produce MOBY services in a RESTful way would make it very easy to create these kind of MOBY services... In general the request services will always accept the same object and parameters and produce the same object as a result... and create a service like this in any language is really simple! And in some cases you could give potential simple-request-service-type moby providers a WSDL file that they can implement. > As such, I don't see that MOBY is any less interoperable with non-MOBY > web services than they are with each other, with the exception that we > pass XML rather than raw data. Well, I see some MOBY services that can be well defined with a WSDL file and that someone outside from the MOBY world could be interested in using... Someone will maybe want to program an interface to these moby services, that are all of the same type (the exact WSDL file), and does not want to worry about BIOMOBY at all (apart of using the registry for discovery and understanding the little semantics of this specific service template). What I am more interested now is on another topic. If you remeber Mark we discussed more than one year ago the need for a paging mechanism for our services in BioMOBY. Now that I am implementing this I took Martin Singer approach to include this functionality on the service: the services always have a two parameters: maxPages and startPage that are used for paging... What is your opinion on this? I think we need an agreement on how this work so that future BioMOBY clients could make use of paging. I dont know if it would be better to move these parameters somewhere inside the MOBY API as they are more operational parameters for lot of services than actual parameters only for my specific service. Is there anybody out there who was implemented paging on any MOBY service? For the time being I am happy with Martin approach and this is the way we are doing it. Best regards. Javier. From gordonp at ucalgary.ca Tue Sep 19 09:51:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 19 Sep 2006 07:51:50 -0600 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> Message-ID: <450FF5F6.3080607@ucalgary.ca> > And a way to produce MOBY services in a RESTful way would make it > very easy to create these kind of MOBY services... In general the > request services will always accept the same object and parameters > and produce the same object as a result... and create a service like > this in any language is really simple! I can submit a CommentedDNASequence to a service that accepts a VirtualSequence (or a blast-text to a service that accepts Object), and if I remember correctly this is where things started to break down in traditional Web Services descriptions... From jatorre at gmail.com Tue Sep 19 10:06:20 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 16:06:20 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <450FF5F6.3080607@ucalgary.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> Message-ID: Right, Thats why BioMOBY is so interesting I suppose. But some services will always accept one, and only one, moby object. For example the first service I created consumes a ScientificName, that is a string. I dont think I can understand any other object as input for this service. Then BioMOBY acts as a simple web service, right? On 19/09/2006, at 15:51, Paul Gordon wrote: > >> And a way to produce MOBY services in a RESTful way would make it >> very easy to create these kind of MOBY services... In general the >> request services will always accept the same object and parameters >> and produce the same object as a result... and create a service like >> this in any language is really simple! > I can submit a CommentedDNASequence to a service that accepts a > VirtualSequence (or a blast-text to a service that accepts Object), > and > if I remember correctly this is where things started to break down in > traditional Web Services descriptions... > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Tue Sep 19 10:13:16 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 19 Sep 2006 08:13:16 -0600 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> Message-ID: <450FFAFC.3080301@ucalgary.ca> No, the beauty of BioMOBY is that it combines Web Services with the Semantic Web. So I can subclass your ScientificName in the ontology, and I MUST be allowed to submit an instance of MyScientificName it to your service. The shared ontology is the key to automagic interoperability... > Right, > > Thats why BioMOBY is so interesting I suppose. But some services will > always accept one, and only one, moby object. For example the first > service I created consumes a ScientificName, that is a string. I dont > think I can understand any other object as input for this service. > Then BioMOBY acts as a simple web service, right? > > On 19/09/2006, at 15:51, Paul Gordon wrote: > > >>> And a way to produce MOBY services in a RESTful way would make it >>> very easy to create these kind of MOBY services... In general the >>> request services will always accept the same object and parameters >>> and produce the same object as a result... and create a service like >>> this in any language is really simple! >>> >> I can submit a CommentedDNASequence to a service that accepts a >> VirtualSequence (or a blast-text to a service that accepts Object), >> and >> if I remember correctly this is where things started to break down in >> traditional Web Services descriptions... >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From edward.kawas at gmail.com Tue Sep 19 09:35:47 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 19 Sep 2006 06:35:47 -0700 Subject: [MOBY-dev] post-memory-upgrade check In-Reply-To: <200609191013.30969.d.haase@gsf.de> Message-ID: <003f01c6dbf0$84a8d950$6900a8c0@notebook> Hi Dirk, It's working now. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, September 19, 2006 1:14 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] post-memory-upgrade check > > On Tuesday 19 September 2006 05:19, markw at illuminae.com wrote: > > Hi all, > > > > MOBY Central (in Vancouver) is now working on its memory upgrade. > > Please let me know ASAP if you experience anything yucky! > > Taverma is not able to load the Biomoby scavenger. It fails > with the following error: > > Failed: Server returned HTTP response code: 400 for URL: > http://mobycentral.icapture.ubc.ca/RESOURCES/MOBY-S/Objects > [Ljava.lang.StackTraceElement;@1f99e90 > ERROR 2006-09-19 > 10:08:04,838 > (org.embl.ebi.escience.scuflui.workbench.ScavengerTree:341) - > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationExcep > tion: Could not retrieve and or process RDF document for > BioMoby Objects > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 10:44:45 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 19 Sep 2006 14:44:45 +0000 GMT Subject: [MOBY-dev] [moby] Example of a responsemessage with SOAP envelope In-Reply-To: <450FFAFC.3080301@ucalgary.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> Message-ID: <1345293324-1158677122-cardhu_blackberry.rim.net-15136-@engine13-cell01> Precisely :-) it is for this reason that we so strongly emphasise that service providers should not validate incoming requests based on the object name. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Paul Gordon Date: Tue, 19 Sep 2006 08:13:16 To:Core developer announcements Subject: Re: [MOBY-dev] [moby] Example of a response message with SOAP envelope No, the beauty of BioMOBY is that it combines Web Services with the Semantic Web. So I can subclass your ScientificName in the ontology, and I MUST be allowed to submit an instance of MyScientificName it to your service. The shared ontology is the key to automagic interoperability... > Right, > > Thats why BioMOBY is so interesting I suppose. But some services will > always accept one, and only one, moby object. For example the first > service I created consumes a ScientificName, that is a string. I dont > think I can understand any other object as input for this service. > Then BioMOBY acts as a simple web service, right? > > On 19/09/2006, at 15:51, Paul Gordon wrote: > > >>> And a way to produce MOBY services in a RESTful way would make it >>> very easy to create these kind of MOBY services... In general the >>> request services will always accept the same object and parameters >>> and produce the same object as a result... and create a service like >>> this in any language is really simple! >>> >> I can submit a CommentedDNASequence to a service that accepts a >> VirtualSequence (or a blast-text to a service that accepts Object), >> and >> if I remember correctly this is where things started to break down in >> traditional Web Services descriptions... >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 10:56:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 19 Sep 2006 14:56:51 +0000 GMT Subject: [MOBY-dev] post-memory-upgrade check In-Reply-To: <003f01c6dbf0$84a8d950$6900a8c0@notebook> References: <200609191013.30969.d.haase@gsf.de> <003f01c6dbf0$84a8d950$6900a8c0@notebook> Message-ID: <1182033175-1158677848-cardhu_blackberry.rim.net-17283-@engine25-cell01> Did Tomcat not come-up by itself after the reboot? -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Tue, 19 Sep 2006 06:35:47 To:"'Core developer announcements'" Subject: Re: [MOBY-dev] post-memory-upgrade check Hi Dirk, It's working now. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, September 19, 2006 1:14 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] post-memory-upgrade check > > On Tuesday 19 September 2006 05:19, markw at illuminae.com wrote: > > Hi all, > > > > MOBY Central (in Vancouver) is now working on its memory upgrade. > > Please let me know ASAP if you experience anything yucky! > > Taverma is not able to load the Biomoby scavenger. It fails > with the following error: > > Failed: Server returned HTTP response code: 400 for URL: > http://mobycentral.icapture.ubc.ca/RESOURCES/MOBY-S/Objects > [Ljava.lang.StackTraceElement;@1f99e90 > ERROR 2006-09-19 > 10:08:04,838 > (org.embl.ebi.escience.scuflui.workbench.ScavengerTree:341) - > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationExcep > tion: Could not retrieve and or process RDF document for > BioMoby Objects > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From jatorre at gmail.com Tue Sep 19 12:22:07 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 18:22:07 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <450FFAFC.3080301@ucalgary.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> Message-ID: <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> Ups, Right, so my service can be considered a normal web service + a biomoby service. Somehow a MOBY service like mine can be described as a normal web service PLUS: -It does not validate incoming messages, it only make use of the piece it understand Apart of this, the service can be described in a WSDL file. Well, one way to use it, somehow the "canonical" model that represent the object that was used to create it. Uhmmm I still have to think about this more in detail, sorry if I dont understand very well some things and I am just thinking loud. And I also have to probe that my service will not crash when you send your MyScientificName. I am actually using XSLT to take the information I need so I think I am safe because inside your MyScientificName there will still be a ScientificName. I dont mind where in the XML it is because XSLT will find it, hopefully! Javier. On 19/09/2006, at 16:13, Paul Gordon wrote: > No, the beauty of BioMOBY is that it combines Web Services with the > Semantic Web. So I can subclass your ScientificName in the ontology, > and I MUST be allowed to submit an instance of MyScientificName it to > your service. The shared ontology is the key to automagic > interoperability... >> Right, >> >> Thats why BioMOBY is so interesting I suppose. But some services will >> always accept one, and only one, moby object. For example the first >> service I created consumes a ScientificName, that is a string. I dont >> think I can understand any other object as input for this service. >> Then BioMOBY acts as a simple web service, right? >> >> On 19/09/2006, at 15:51, Paul Gordon wrote: >> >> >>>> And a way to produce MOBY services in a RESTful way would make it >>>> very easy to create these kind of MOBY services... In general the >>>> request services will always accept the same object and parameters >>>> and produce the same object as a result... and create a service >>>> like >>>> this in any language is really simple! >>>> >>> I can submit a CommentedDNASequence to a service that accepts a >>> VirtualSequence (or a blast-text to a service that accepts Object), >>> and >>> if I remember correctly this is where things started to break >>> down in >>> traditional Web Services descriptions... >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 12:26:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 19 Sep 2006 09:26:25 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> Message-ID: <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: > information I need so I think I am safe because inside your > MyScientificName there will still be a ScientificName. I dont mind > where in the XML it is because XSLT will find it, hopefully! Nope, not quite :-) ScientificName (as a tag name) will not be inside of MyScientificName; however the *content* of MyScientificName will include all of the same elements as the *content* of ScientificName MyScientificName to ScientificName is an inheritence relationship, not a container relationship M From jatorre at gmail.com Tue Sep 19 12:34:39 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 18:34:39 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> Message-ID: <0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> Ups! And how does the services work? I mean, do they have to connect to the registry to check the relations of the objects they serve with what other people might be sending them? Or is it that they just take the string, in my case, and do something with it? If it is the second then a user, stupidly, could be sending an object to a service that is not necessarily inheritanced from the data type he understands and he will be using it. Of course there is nothing wrong to provide stupid answers to stupid questions, but, is it like this? The, can I just take the content from the in the income message and expect that it is actually a ScientificName? Thanks. Javier. On 19/09/2006, at 18:26, Mark Wilkinson wrote: > On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: >> information I need so I think I am safe because inside your >> MyScientificName there will still be a ScientificName. I dont mind >> where in the XML it is because XSLT will find it, hopefully! > > > Nope, not quite :-) ScientificName (as a tag name) will not be inside > of MyScientificName; however the *content* of MyScientificName will > include all of the same elements as the *content* of ScientificName > > MyScientificName to ScientificName is an inheritence relationship, > not a > container relationship > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 12:53:33 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 19 Sep 2006 09:53:33 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> <0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> Message-ID: <1158684813.22263.2.camel@bioinfo.icapture.ubc.ca> Well, I don't know how other service providers do it, but I seldom validate the incoming XML *at all*. I simply use an XPath query or something like that to reach into the XML document to get the pieces that I expect to be in there (based on whatever I registered as my input data type). If they are not there, I throw an error. It is possible, of course, to query the ontology to make sure that what you have received is a child of what you registered as consuming... but that's a lot of overhead, and besides, what are you going to do if it isn't a child? fail with an error :-) so I simply fail with an error if I don't find what I want, and skip the expensive validation step altogether. M On Tue, 2006-09-19 at 18:34 +0200, Javier de la Torre wrote: > Ups! > > And how does the services work? I mean, do they have to connect to > the registry to check the relations of the objects they serve with > what other people might be sending them? Or is it that they just take > the string, in my case, and do something with it? If it is the second > then a user, stupidly, could be sending an object to a service that > is not necessarily inheritanced from the data type he understands and > he will be using it. Of course there is nothing wrong to provide > stupid answers to stupid questions, but, is it like this? > > The, can I just take the content from the in the income > message and expect that it is actually a ScientificName? > > Thanks. > > Javier. > > > On 19/09/2006, at 18:26, Mark Wilkinson wrote: > > > On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: > >> information I need so I think I am safe because inside your > >> MyScientificName there will still be a ScientificName. I dont mind > >> where in the XML it is because XSLT will find it, hopefully! > > > > > > Nope, not quite :-) ScientificName (as a tag name) will not be inside > > of MyScientificName; however the *content* of MyScientificName will > > include all of the same elements as the *content* of ScientificName > > > > MyScientificName to ScientificName is an inheritence relationship, > > not a > > container relationship > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From ots at ac.uma.es Wed Sep 20 04:39:36 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Wed, 20 Sep 2006 10:39:36 +0200 Subject: [MOBY-dev] [moby] Example ofa response message with SOAP envelope References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com><1158600746.18578.1.camel@bioinfo.icapture.ubc.ca><5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com><1158621658.19646.9.camel@bioinfo.icapture.ubc.ca><07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com><450FF5F6.3080607@ucalgary.ca><450FFAFC.3080301@ucalgary.ca><77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com><1158683185.21783.74.camel@bioinfo.icapture.ubc.ca><0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> <1158684813.22263.2.camel@bioinfo.icapture.ubc.ca> Message-ID: <004401c6dc90$4f459780$346dd696@ac.uma.es> I agree with Mark in this is a programmer decision. In our case, the INB-client only accepts the input (and descendants) declared during service's registration. A similar situation arise when you ask for services able to manage a given object type. In this case the client recognise as valid object the registered type and its descendants O. ----- Original Message ----- From: "Mark Wilkinson" To: "Javier de la Torre" Cc: "Core developer announcements" Sent: Tuesday, September 19, 2006 6:53 PM Subject: Re: [MOBY-dev] [moby] Example ofa response message with SOAP envelope > Well, I don't know how other service providers do it, but I seldom > validate the incoming XML *at all*. I simply use an XPath query or > something like that to reach into the XML document to get the pieces > that I expect to be in there (based on whatever I registered as my input > data type). If they are not there, I throw an error. > > It is possible, of course, to query the ontology to make sure that what > you have received is a child of what you registered as consuming... but > that's a lot of overhead, and besides, what are you going to do if it > isn't a child? fail with an error :-) so I simply fail with an error > if I don't find what I want, and skip the expensive validation step > altogether. > > M > > > > > On Tue, 2006-09-19 at 18:34 +0200, Javier de la Torre wrote: > > Ups! > > > > And how does the services work? I mean, do they have to connect to > > the registry to check the relations of the objects they serve with > > what other people might be sending them? Or is it that they just take > > the string, in my case, and do something with it? If it is the second > > then a user, stupidly, could be sending an object to a service that > > is not necessarily inheritanced from the data type he understands and > > he will be using it. Of course there is nothing wrong to provide > > stupid answers to stupid questions, but, is it like this? > > > > The, can I just take the content from the in the income > > message and expect that it is actually a ScientificName? > > > > Thanks. > > > > Javier. > > > > > > On 19/09/2006, at 18:26, Mark Wilkinson wrote: > > > > > On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: > > >> information I need so I think I am safe because inside your > > >> MyScientificName there will still be a ScientificName. I dont mind > > >> where in the XML it is because XSLT will find it, hopefully! > > > > > > > > > Nope, not quite :-) ScientificName (as a tag name) will not be inside > > > of MyScientificName; however the *content* of MyScientificName will > > > include all of the same elements as the *content* of ScientificName > > > > > > MyScientificName to ScientificName is an inheritence relationship, > > > not a > > > container relationship > > > > > > M > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at lists.open-bio.org > > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From johan at ac.uma.es Thu Sep 21 05:28:58 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 21 Sep 2006 11:28:58 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 Message-ID: <45125B5A.1070402@ac.uma.es> For an updated version of the proposal for asynchronous services: http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf Changes: - Added missing parts to the XML examples (thanks Pieter) - Removed hasCallingDetail, now instead suggesting a new value for dc:format (thanks Martin). Because allowed value in dc:format comes from the MyGrid ontology we should coordinate with them to find exactly what value to put there. If there are no major issues left to discuss, could the RFC committee please call a vote on the proposal for October 1st? Kind regards, Johan -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From edward.kawas at gmail.com Thu Sep 21 16:42:41 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 21 Sep 2006 13:42:41 -0700 Subject: [MOBY-dev] Verifying data Message-ID: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> Hi, What are the opinions regarding the following situation: User A uses a service that, among other things, specifies that a float is returned. This service is then connected to a downstream service B. The service runs and returns the empty string instead of a float (all other items are filled in correctly). What should service B do? Should it fail since the empty string is not a float or should the service quietly ignore this. I am asking this because I just came across this using a service created using Perl MoSes. Thanks, Eddie From martin.senger at gmail.com Thu Sep 21 17:34:29 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 21 Sep 2006 22:34:29 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> Message-ID: <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> My 2c's: An empty output means no output. Which may not be an error but which definitely means that we have nothing to pass to a downstream service. Also a case when a service A returns an exception indicates that there is no much sense to call a downstream service B. My conclusion is therefore: Each service should check first that it gets an input (well, each services that expects an input, of course). If if does not, it should stop and again produce no output (potentially, adding its own exception to those already existing in the service notes). I can add this strict behaviour to Moses, or to Perl Moses. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 09:46:33 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 07:46:33 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> Message-ID: <4513E939.5010907@ucalgary.ca> I agree with Martin. My MobyServlet will throw an exception if the float is blank. The stricter we are, the better off MOBY-S is in the long run. Support for broken HTML tags since Netscape 1.0 still haunts the Web... > My 2c's: > > An empty output means no output. Which may not be an error but which > definitely means that we have nothing to pass to a downstream service. > > Also a case when a service A returns an exception indicates that there is no > much sense to call a downstream service B. > > My conclusion is therefore: Each service should check first that it gets an > input (well, each services that expects an input, of course). If if does > not, it should stop and again produce no output (potentially, adding its own > exception to those already existing in the service notes). > > I can add this strict behaviour to Moses, or to Perl Moses. > > Cheers, > Martin > > From martin.senger at gmail.com Fri Sep 22 12:45:53 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 17:45:53 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <45125B5A.1070402@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> Message-ID: <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> > If there are no major issues left to discuss, could the RFC committee > please call a vote on the proposal for October 1st? There is really no such thing as an RFC committee... But yes, I agree to have a vote - if the political issue (regardinr using a SOAP-specific technology) is considered to be solved. How is it, Mark? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Sep 22 13:51:14 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 10:51:14 -0700 Subject: [MOBY-dev] [moby] Re: BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> References: <45125B5A.1070402@ac.uma.es> <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> Message-ID: <1158947474.5704.30.camel@bioinfo.icapture.ubc.ca> > There is really no such thing as an RFC committee... Well... there is a group of us who have agreed to be "the deciders" (to quote George Bush... I'll never do that again, I promise!) > But yes, I agree to > have a vote - if the political issue (regardinr using a SOAP-specific > technology) is considered to be solved. How is it, Mark? There was no significant discussion of this issue beyond the brief conversation that we had on the mailing list. My own opinion is that we have (possibly regrettably) already bought-in to the SOAP infrastructure, so using a SOAP-specific technology is a reasonable thing to do at this point. It does make it more difficult to change our minds later on, but I suspect that any mind-changing in the future is going to be on an much larger scale than just the transport protocol, so this small detail is not particularly relevant in that context. In my opinion, that discussion is resolved. Does anyone disagree? v.v. the Asynch proposal - let's call for the vote right now. All voting members please read the proposal carefully and submit your vote by October 1. M From martin.senger at gmail.com Fri Sep 22 12:45:53 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 17:45:53 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <45125B5A.1070402@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> Message-ID: <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> > If there are no major issues left to discuss, could the RFC committee > please call a vote on the proposal for October 1st? There is really no such thing as an RFC committee... But yes, I agree to have a vote - if the political issue (regardinr using a SOAP-specific technology) is considered to be solved. How is it, Mark? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 17:11:27 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:11:27 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4513E939.5010907@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> Message-ID: <4514517F.5030105@ucalgary.ca> On another note, last month we talked about a "ping". Can we enshrine this in the API? The current service input doc: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/InputMessage.html implies you need at least one input. Anyone mind if a I add a little paragraph saying how a blank mobyContent must be replied with mobyData-less response? Or does someone object to enforcing this? Should we do an RFC intsead? I realize it might not be backward compatible for a few working services, but it'll be SO useful to get rid of all the dead links in clients...the RDF isAlive could be based on this... Paul Gordon wrote: > I agree with Martin. My MobyServlet will throw an exception if the > float is blank. The stricter we are, the better off MOBY-S is in the > long run. Support for broken HTML tags since Netscape 1.0 still haunts > the Web... > >> My 2c's: >> >> An empty output means no output. Which may not be an error but which >> definitely means that we have nothing to pass to a downstream service. >> >> Also a case when a service A returns an exception indicates that there is no >> much sense to call a downstream service B. >> >> My conclusion is therefore: Each service should check first that it gets an >> input (well, each services that expects an input, of course). If if does >> not, it should stop and again produce no output (potentially, adding its own >> exception to those already existing in the service notes). >> >> I can add this strict behaviour to Moses, or to Perl Moses. >> >> Cheers, >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From gordonp at ucalgary.ca Fri Sep 22 17:33:23 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:33:23 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <45125B5A.1070402@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> Message-ID: <451456A3.8010702@ucalgary.ca> Hi all, Sorry I'm getting into this discussion so late, but it would seem to me that it would be helpful to add a ResourceProperty that gives the client a hint as to how often they should check back for an answer. The server would have a much better idea of the appropriate interval than the client, no? If my client software generally checks every minute for async job responses, but the process always takes a day, that's a lot (1440) of useless polling requests. A bit like the Refresh header in HTTP... Cheers, Paul > For an updated version of the proposal for asynchronous services: > > http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf > > Changes: > - Added missing parts to the XML examples (thanks Pieter) > - Removed hasCallingDetail, now instead suggesting a new value for > dc:format (thanks Martin). Because allowed value in dc:format comes from > the MyGrid ontology we should coordinate with them to find exactly what > value to put there. > > If there are no major issues left to discuss, could the RFC committee > please call a vote on the proposal for October 1st? > > Kind regards, > Johan > > From martin.senger at gmail.com Fri Sep 22 17:49:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 22:49:36 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <4514517F.5030105@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> Message-ID: <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> > On another note, last month we talked about a "ping". Can we enshrine > this in the API? I considered this already agreed on :-) (Perl Moses services have it already, Java Moses will follow this week.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 17:50:54 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:50:54 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> Message-ID: <45145ABE.1050907@ucalgary.ca> So did I, but it's not in the API yet... :-) >> On another note, last month we talked about a "ping". Can we enshrine >> this in the API? >> > > > I considered this already agreed on :-) (Perl Moses services have it > already, Java Moses will follow this week.) > > Martin > > > From edward.kawas at gmail.com Fri Sep 22 17:22:11 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 22 Sep 2006 14:22:11 -0700 Subject: [MOBY-dev] Verifying data In-Reply-To: <4514517F.5030105@ucalgary.ca> Message-ID: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> I was thinking about this today. I would like to be able to retrieve this type of information via the API. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Friday, September 22, 2006 2:11 PM > To: Core developer announcements > Subject: Re: [MOBY-dev] Verifying data > > On another note, last month we talked about a "ping". Can we > enshrine this in the API? The current service input doc: > > http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_ > API/InputMessage.html > > implies you need at least one input. Anyone mind if a I add > a little paragraph saying how a blank mobyContent must be > replied with mobyData-less response? Or does someone object > to enforcing this? > Should we do an RFC intsead? I realize it might not be > backward compatible for a few working services, but it'll be > SO useful to get rid of all the dead links in clients...the > RDF isAlive could be based on this... > > Paul Gordon wrote: > > I agree with Martin. My MobyServlet will throw an exception if the > > float is blank. The stricter we are, the better off MOBY-S > is in the > > long run. Support for broken HTML tags since Netscape 1.0 still > > haunts the Web... > > > >> My 2c's: > >> > >> An empty output means no output. Which may not be an error > but which > >> definitely means that we have nothing to pass to a > downstream service. > >> > >> Also a case when a service A returns an exception indicates that > >> there is no much sense to call a downstream service B. > >> > >> My conclusion is therefore: Each service should check > first that it > >> gets an input (well, each services that expects an input, > of course). > >> If if does not, it should stop and again produce no output > >> (potentially, adding its own exception to those already > existing in the service notes). > >> > >> I can add this strict behaviour to Moses, or to Perl Moses. > >> > >> Cheers, > >> Martin > >> > >> > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri Sep 22 17:52:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 14:52:32 -0700 Subject: [MOBY-dev] [moby] Re: Verifying data In-Reply-To: <4514517F.5030105@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> Message-ID: <1158961952.6569.5.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-09-22 at 15:11 -0600, Paul Gordon wrote: > Or does someone object to enforcing this? > Should we do an RFC intsead? I realize it might not be backward > compatible for a few working services, but it'll be SO useful to get rid > of all the dead links in clients...the RDF isAlive could be based on this... You're likely right that it isn't backward-compatible... chances are that most services will not handle this situation *at all* and will need to be tweaked somehow... Do you know what services do at the moment if you hit them with no mobyData block? I agree, however, that it would be REALLY useful to have this functionality! M From markw at illuminae.com Fri Sep 22 17:56:42 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 14:56:42 -0700 Subject: [MOBY-dev] [moby] Re: Verifying data In-Reply-To: <45145ABE.1050907@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> <45145ABE.1050907@ucalgary.ca> Message-ID: <1158962202.6569.9.camel@bioinfo.icapture.ubc.ca> I'm pretty sure that there was ~unanimous support for the idea on the list. If you have time, please go ahead and add it to the documentation. M On Fri, 2006-09-22 at 15:50 -0600, Paul Gordon wrote: > So did I, but it's not in the API yet... :-) > >> On another note, last month we talked about a "ping". Can we enshrine > >> this in the API? > >> > > > > > > I considered this already agreed on :-) (Perl Moses services have it > > already, Java Moses will follow this week.) > > > > Martin > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Fri Sep 22 17:59:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:59:50 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> Message-ID: <45145CD6.7010506@ucalgary.ca> I think the ideal solution is to base the Service RDF's "isAlive" tag on whether the service pings or not. This won't "break" anything. If the person actively reads this list, they'll update their service. If they don't update their service, it works just as before, only isAlive=false. I can then turn isAlive filtering on or off in my client software according to my whim. If you're really hung up on semantics, we could add a isAPICompatible or something of the sort instead of usurping isAlive... > I was thinking about this today. I would like to be able to retrieve this type > of information via the API. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Friday, September 22, 2006 2:11 PM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Verifying data >> >> On another note, last month we talked about a "ping". Can we >> enshrine this in the API? The current service input doc: >> >> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_ >> API/InputMessage.html >> >> implies you need at least one input. Anyone mind if a I add >> a little paragraph saying how a blank mobyContent must be >> replied with mobyData-less response? Or does someone object >> to enforcing this? >> Should we do an RFC intsead? I realize it might not be >> backward compatible for a few working services, but it'll be >> SO useful to get rid of all the dead links in clients...the >> RDF isAlive could be based on this... >> >> Paul Gordon wrote: >> >>> I agree with Martin. My MobyServlet will throw an exception if the >>> float is blank. The stricter we are, the better off MOBY-S >>> >> is in the >> >>> long run. Support for broken HTML tags since Netscape 1.0 still >>> haunts the Web... >>> >>> >>>> My 2c's: >>>> >>>> An empty output means no output. Which may not be an error >>>> >> but which >> >>>> definitely means that we have nothing to pass to a >>>> >> downstream service. >> >>>> Also a case when a service A returns an exception indicates that >>>> there is no much sense to call a downstream service B. >>>> >>>> My conclusion is therefore: Each service should check >>>> >> first that it >> >>>> gets an input (well, each services that expects an input, >>>> >> of course). >> >>>> If if does not, it should stop and again produce no output >>>> (potentially, adding its own exception to those already >>>> >> existing in the service notes). >> >>>> I can add this strict behaviour to Moses, or to Perl Moses. >>>> >>>> Cheers, >>>> Martin >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From martin.senger at gmail.com Fri Sep 22 18:00:54 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 23:00:54 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> References: <4514517F.5030105@ucalgary.ca> <008101c6de8d$2c5a2ca0$6400a8c0@notebook> Message-ID: <4d93f07c0609221500l55363c6eqfc766d66d15821a9@mail.gmail.com> > I was thinking about this today. I would like to be able to retrieve this > type > of information via the API. Do not make things complicated... 1) Ping: Send an empty mobyContent and get back the same. 2) Service that does not have any input (e.g. HelloWorld service): Send an empty mobyData and get back whatever service produces. (Of course, one can send several empty mobyData within a single network request.) 3) Otherwise there should be a non-empty mobyData. If it is not, there is something wrong with the input (possibly caused by an upstream service) - so this service should no nothing, and return again an empty mobyData (and - I think - it should propagate the exceptions in service notes, possibly adding its own exception). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Fri Sep 22 18:11:14 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 23:11:14 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <45145CD6.7010506@ucalgary.ca> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> Message-ID: <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> I prefer an empty mobyContent (for a ping). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 18:13:57 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 16:13:57 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> Message-ID: <45146025.9080509@ucalgary.ca> Versus what? Did anyone suggest anything else? > I prefer an empty mobyContent (for a ping). > > Martin > > From martin.senger at gmail.com Fri Sep 22 18:18:38 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 23:18:38 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <45146025.9080509@ucalgary.ca> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> <45146025.9080509@ucalgary.ca> Message-ID: <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> > Versus what? Did anyone suggest anything else? I understood that you suggested to use a new XML tag isAlive... M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 18:26:17 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 16:26:17 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> <45146025.9080509@ucalgary.ca> <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> Message-ID: <45146309.8040504@ucalgary.ca> Ah, no. I was talking about the isAlive tag found in each service description in the service instance RDF http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances If this was based on the ping, I wouldn't have to send out 600 pings myself every time... In any case, the API doc is now up to date in CVS, it will take a while to propagate to the Web site... >> Versus what? Did anyone suggest anything else? >> > > > I understood that you suggested to use a new XML tag isAlive... > M. > > > > From markw at illuminae.com Fri Sep 22 19:30:59 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 16:30:59 -0700 Subject: [MOBY-dev] [moby] Re: Verifying data In-Reply-To: <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> <45146025.9080509@ucalgary.ca> <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> Message-ID: <1158967859.7688.2.camel@bioinfo.icapture.ubc.ca> I think Paul was referring to the isAlive tag in the LSID metadata. M On Fri, 2006-09-22 at 23:18 +0100, Martin Senger wrote: > > Versus what? Did anyone suggest anything else? > > > I understood that you suggested to use a new XML tag isAlive... > M. > > > -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From johan at ac.uma.es Mon Sep 25 06:25:36 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Mon, 25 Sep 2006 12:25:36 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <451456A3.8010702@ucalgary.ca> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> Message-ID: <4517AEA0.5070507@ac.uma.es> Hi Paul, Well, it depends on the particular service? So, any such property must be optional. a) For a service that returns a "Percent progress" or similar event, a client could "guess" when to do the next polling (would not be totally accurate, of course, but still). Here the service would basically do the same "intelligent" guessing that the client would do and create this property. b) For a service that returns a "Heartbeat" or similar event, a client cannot guess when it is appropriate to do the next polling (since not even the service knows when it will finish). Here, no property could be created. Not sure if it is necessary with a new property. If a service wants to help the client to do such "prediction", the service can already use LSAE event blocks when it returns status to "communicate" with the client; step progress event and percent progress? Comments from others? Kind regards, Johan Paul Gordon wrote: > Hi all, > > Sorry I'm getting into this discussion so late, but it would seem to me > that it would be helpful to add a ResourceProperty that gives the client > a hint as to how often they should check back for an answer. The server > would have a much better idea of the appropriate interval than the > client, no? If my client software generally checks every minute for > async job responses, but the process always takes a day, that's a lot > (1440) of useless polling requests. A bit like the Refresh header in > HTTP... > > Cheers, > > Paul > >> For an updated version of the proposal for asynchronous services: >> >> http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf >> >> Changes: >> - Added missing parts to the XML examples (thanks Pieter) >> - Removed hasCallingDetail, now instead suggesting a new value for >> dc:format (thanks Martin). Because allowed value in dc:format comes from >> the MyGrid ontology we should coordinate with them to find exactly what >> value to put there. >> >> If there are no major issues left to discuss, could the RFC committee >> please call a vote on the proposal for October 1st? >> >> Kind regards, >> Johan >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From gordonp at ucalgary.ca Mon Sep 25 11:00:18 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 25 Sep 2006 09:00:18 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517AEA0.5070507@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> Message-ID: <4517EF02.10507@ucalgary.ca> Yeah, I'd looked at the LSAE events, but was surprised to see that there wasn't anything about refresh rates in it. I guess the only mechanism available to us in the current framework is your suggestion (a) to extrapolate based on the % done so far? An oversight on the OMG group's part I think... > Hi Paul, > > Well, it depends on the particular service? So, any such property must > be optional. > > a) For a service that returns a "Percent progress" or similar event, a > client could "guess" when to do the next polling (would not be totally > accurate, of course, but still). Here the service would basically do the > same "intelligent" guessing that the client would do and create this > property. > b) For a service that returns a "Heartbeat" or similar event, a client > cannot guess when it is appropriate to do the next polling (since not > even the service knows when it will finish). Here, no property could be > created. > > Not sure if it is necessary with a new property. If a service wants to > help the client to do such "prediction", the service can already use > LSAE event blocks when it returns status to "communicate" with the > client; step progress event and percent progress? > > Comments from others? > > Kind regards, > Johan > > Paul Gordon wrote: > >> Hi all, >> >> Sorry I'm getting into this discussion so late, but it would seem to me >> that it would be helpful to add a ResourceProperty that gives the client >> a hint as to how often they should check back for an answer. The server >> would have a much better idea of the appropriate interval than the >> client, no? If my client software generally checks every minute for >> async job responses, but the process always takes a day, that's a lot >> (1440) of useless polling requests. A bit like the Refresh header in >> HTTP... >> >> Cheers, >> >> Paul >> >> >>> For an updated version of the proposal for asynchronous services: >>> >>> http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf >>> >>> Changes: >>> - Added missing parts to the XML examples (thanks Pieter) >>> - Removed hasCallingDetail, now instead suggesting a new value for >>> dc:format (thanks Martin). Because allowed value in dc:format comes from >>> the MyGrid ontology we should coordinate with them to find exactly what >>> value to put there. >>> >>> If there are no major issues left to discuss, could the RFC committee >>> please call a vote on the proposal for October 1st? >>> >>> Kind regards, >>> Johan >>> >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> > > From martin.senger at gmail.com Mon Sep 25 11:38:26 2006 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 25 Sep 2006 16:38:26 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517EF02.10507@ucalgary.ca> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> <4517EF02.10507@ucalgary.ca> Message-ID: <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> Paul, > Yeah, I'd looked at the LSAE events, but was surprised to see that there > wasn't anything about refresh rates in it. And why should it? If you need a special event that can deliver an information about a refresh rate, you can extend an existing event. An oversight on the OMG group's part I think... No oversight here, just this was not the primary purpose (and I should know because what you call an "OMG group" was actually me :-)). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Mon Sep 25 11:00:18 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 25 Sep 2006 09:00:18 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517AEA0.5070507@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> Message-ID: <4517EF02.10507@ucalgary.ca> Yeah, I'd looked at the LSAE events, but was surprised to see that there wasn't anything about refresh rates in it. I guess the only mechanism available to us in the current framework is your suggestion (a) to extrapolate based on the % done so far? An oversight on the OMG group's part I think... > Hi Paul, > > Well, it depends on the particular service? So, any such property must > be optional. > > a) For a service that returns a "Percent progress" or similar event, a > client could "guess" when to do the next polling (would not be totally > accurate, of course, but still). Here the service would basically do the > same "intelligent" guessing that the client would do and create this > property. > b) For a service that returns a "Heartbeat" or similar event, a client > cannot guess when it is appropriate to do the next polling (since not > even the service knows when it will finish). Here, no property could be > created. > > Not sure if it is necessary with a new property. If a service wants to > help the client to do such "prediction", the service can already use > LSAE event blocks when it returns status to "communicate" with the > client; step progress event and percent progress? > > Comments from others? > > Kind regards, > Johan > > Paul Gordon wrote: > >> Hi all, >> >> Sorry I'm getting into this discussion so late, but it would seem to me >> that it would be helpful to add a ResourceProperty that gives the client >> a hint as to how often they should check back for an answer. The server >> would have a much better idea of the appropriate interval than the >> client, no? If my client software generally checks every minute for >> async job responses, but the process always takes a day, that's a lot >> (1440) of useless polling requests. A bit like the Refresh header in >> HTTP... >> >> Cheers, >> >> Paul >> >> >>> For an updated version of the proposal for asynchronous services: >>> >>> http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf >>> >>> Changes: >>> - Added missing parts to the XML examples (thanks Pieter) >>> - Removed hasCallingDetail, now instead suggesting a new value for >>> dc:format (thanks Martin). Because allowed value in dc:format comes from >>> the MyGrid ontology we should coordinate with them to find exactly what >>> value to put there. >>> >>> If there are no major issues left to discuss, could the RFC committee >>> please call a vote on the proposal for October 1st? >>> >>> Kind regards, >>> Johan >>> >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> > > From gordonp at ucalgary.ca Mon Sep 25 12:11:37 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 25 Sep 2006 10:11:37 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> <4517EF02.10507@ucalgary.ca> <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> Message-ID: <4517FFB9.3090202@ucalgary.ca> Hi Martin, Extending is never a technical problem, only a social problem. I can add a new tag easily, but unless most people use it, it isn't too useful. That's why I was suggesting that MOBY-S define (or at least strongly suggests) some common name for this...whether we put it in the LSAE events or WSRF is inconsequential to me. Regards, Paul > Paul, > > >> Yeah, I'd looked at the LSAE events, but was surprised to see that there >> wasn't anything about refresh rates in it. >> > > > And why should it? If you need a special event that can deliver an > information about a refresh rate, you can extend an existing event. > > An oversight on the OMG group's part I think... > > > No oversight here, just this was not the primary purpose (and I should know > because what you call an "OMG group" was actually me :-)). > > Martin > No disrespect intended :-) From johan at ac.uma.es Tue Sep 26 05:02:09 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Tue, 26 Sep 2006 11:02:09 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517FFB9.3090202@ucalgary.ca> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> <4517EF02.10507@ucalgary.ca> <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> <4517FFB9.3090202@ucalgary.ca> Message-ID: <4518EC91.8020407@ac.uma.es> One simple way for a service to indicate the next "recommended" time for a client to poll for status is to use the time progress event from LSAE (already defined in LSAE and included in the proposal, so a client should be able to understand it). Quoting from the Life Sciences Analysis Engine specification at http://www.omg.org/cgi-bin/doc?dtc/2005-04-01 --------------- Time progress event Time progress event indicates the estimated number of seconds before the job is completed. There is no requirement that the estimated completion time decreases. An example: This is a TIME PROGRESS analysis event. --------------- In that example, the service estimates that it will take 324 seconds until it completes the analysis, so a client could use that information to decide the next poll-time? Kind regards, Johan Paul Gordon wrote: > Hi Martin, > > Extending is never a technical problem, only a social problem. I can > add a new tag easily, but unless most people use it, it isn't too > useful. That's why I was suggesting that MOBY-S define (or at least > strongly suggests) some common name for this...whether we put it in the > LSAE events or WSRF is inconsequential to me. > > Regards, > > Paul > >> Paul, >> >> >> >>> Yeah, I'd looked at the LSAE events, but was surprised to see that there >>> wasn't anything about refresh rates in it. >>> >>> >> And why should it? If you need a special event that can deliver an >> information about a refresh rate, you can extend an existing event. >> >> An oversight on the OMG group's part I think... >> >> >> No oversight here, just this was not the primary purpose (and I should know >> because what you call an "OMG group" was actually me :-)). >> >> Martin >> >> > No disrespect intended :-) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From martin.senger at gmail.com Wed Sep 27 05:40:20 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 10:40:20 +0100 Subject: [MOBY-dev] Paging mechanism Message-ID: <4d93f07c0609270240g67bccb10y99e20ba518ff3cc1@mail.gmail.com> Javier wrote: What I am more interested now is on another topic. If you remeber > Mark we discussed more than one year ago the need for a paging > mechanism for our services in BioMOBY. Now that I am implementing > this I took Martin Singer approach to include this functionality on > the service: the services always have a two parameters: maxPages and > startPage that are used for paging... I am interested, as well. I used two secondary parameters because it was an immediate solution. But we should think about it now in the same way as we did with asynchronous invocation, meaning to put this information in an envelope (BioMoby or SOAP) - as Javier already proposed. Could anybody more familar with these envelopes suggest where to put it please? Actually, make a real RFC for it... Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Wed Sep 27 09:01:45 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 27 Sep 2006 15:01:45 +0200 Subject: [MOBY-dev] RDF deregistration Message-ID: <200609271501.46324.d.haase@gsf.de> Eddie, is it possible that the deregistration of services by removing it from an RDF document does not work currently? I deleted the section for a service called getGeneticElementNamesByFreeText from http://mips.gsf.de/proj/planet/moby/RDF/all_mips_services.rdf and called the agent but it's not removed from MOBY central yet. Best, dirk From jatorre at gmail.com Wed Sep 27 05:54:39 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 27 Sep 2006 11:54:39 +0200 Subject: [MOBY-dev] Paging mechanism In-Reply-To: <4d93f07c0609270240g67bccb10y99e20ba518ff3cc1@mail.gmail.com> References: <4d93f07c0609270240g67bccb10y99e20ba518ff3cc1@mail.gmail.com> Message-ID: Hi Martin, Would be nice. For the time being I have created a new service type under Retrieval called TapirProvider and I will register all my services with this service type. All of them will support he paging mechanism. I think we need a better name for this than TapirProvider, but couldnt think of anything better. Here is the description for this Service Type: ---- TAPIR providers are normally biological collection databases. The most common operation is to retrieve data from them to be used in analysis. They always implement two secondary inputs, a start and next parameter to do paging. Please read http://trac.pywrapper.org/pywrapper/wiki/BioMOBYSupport --- At least if you are constructing a client to query all these services that support paging you know hot to get to them. If you dont mind I have changed the parameter names to start and next so that it fits with the TAPIR specifications. Javier. On 9/27/06, Martin Senger wrote: > Javier wrote: > > > > What I am more interested now is on another topic. If you remeber > > Mark we discussed more than one year ago the need for a paging > > mechanism for our services in BioMOBY. Now that I am implementing > > this I took Martin Singer approach to include this functionality on > > the service: the services always have a two parameters: maxPages and > > startPage that are used for paging... > > I am interested, as well. I used two secondary parameters because it was an > immediate solution. But we should think about it now in the same way as we > did with asynchronous invocation, meaning to put this information in an > envelope (BioMoby or SOAP) - as Javier already proposed. Could anybody more > familar with these envelopes suggest where to put it please? Actually, make > a real RFC for it... > > Thanks, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger From Pieter.Neerincx at wur.nl Wed Sep 27 11:15:33 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 27 Sep 2006 17:15:33 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: <44FED787.5010002@ac.uma.es> References: <44FED787.5010002@ac.uma.es> Message-ID: Hi Johan et al., Thanks for the updated proposal and sorry for the late response. I've been very busy and also wanted to think this over for a while... On 6-Sep-2006, at 4:13 PM, Johan Karlsson wrote: > Pieter, > > Thank you for a well written letter (and sorry for the delay in > answering). >> There is only one thing that I don't like about the current proposal: >> the location of queryID. For our current synchronous services it's an >> attribute of the mobyData element. In the current async services >> proposal the queryID jumps around the XML taking several identities: >> * in status_queryID01 it >> is part of raw text. >> * in > lsae:status_queryID01> it is part of an element name in the lsae >> namespace. >> (By the way: Should this element really be in the lsae namespace? I >> don't think our status_queryIDxx elements are part of the LSAE >> specs...) >> > True, we need to put a better namespace, moby? moby would be fine I guess... >> It would be >> much more convenient if the result from a asynchronous service >> invocation would contain both the ServiceInvocationID *AND* the >> associated queryIDs. In that case I only have to parse the service >> response to create GetResourceProperty requests. Therefore I propose >> to supply the queryIDs as wsa:ReferenceParameters just like the >> ServiceInvocationID. >> > I am not sure that I understand the problem completely... The clients > must internally store, somehow, the connection between the input > (identified by the queryID) and the output? The jobs could, > potentially, > take a very long time to finish and without knowing the input, getting > the output would not be so interesting. Not necessarily. Somehow you have to keep track of what conditions were used in an experiment, so you know how you got to the results and you make sure you can reproduce it. Either the client stores the inputs and parameters used for service execution and combines it with the results or the service output contains all the information about how the results were produced. This can be a combination of echoing inputs back and/or providing provisioning blocks and/or service notes to create an "e-labjournal". In the latter case you can forget about the XML of the original service invocation and you only need the output. Both approaches work, but in the latter case you keep the information about an experiment together and hence you can not "lose" the experimental conditions. > Anyway, it is not so complicated > to handle the queryIDs for the client (see some of the example code of > the client at the prototype page). Maybe it is another situation that > you are describing than the one in the example? Can you give some > examples where it would be necessary to return the queryIDs? Again, > not > sure if I understand. > > http://bioinfo.pcm.uam.es/prototype/ I'm sure it's not "rocket science" to store the queryIDs on the client, but it's simply not necessary. IMHO it's easier to return the queryIDs to the client as compared to storing them on the client. That's all. > >> 2. >> WSRF contains an *optional* method to request a resource properties >> document. With this method a client can figure out which resource >> properties are available and hence what it can request. Although this >> method is optional and the current proposal doesn't mention it, I >> think it would good to keep the option open to supply such a method. >> WSRF does not put any limitations on how a service generates and >> provides such a document, so you can generate it dynamically or it >> can be a static thing. If we would want to supply such a resource >> properties document in the future it would be the easiest if it can >> be a static one. However in the current proposal the queryIDs are >> part of the resource properties (status_queryIDxx and >> result_queryIDxx). This means that the available resource properties >> depend on the amount of queries/jobs that were sent to a service and >> hence we can not use a static resource properties document. It would >> be more convenient if we can strip the queryIDs from the resource >> properties and provide them as wsa:ReferenceParameters. In that case >> there are only two resource properties (status and result) and we can >> describe those in a static resource properties document. > > At least until now, we have tried to only include exactly what is > needed > and avoid many, potentially, useful but maybe more complicated WSRF > methods. I totally agree and I'm happy you have chosen such an approach. I'm not arguing to add the GetResourcePropertyDocument method right now, but I feel it would be good to keep the option open to do so in the future. If the queryIDs are moved to the SOAP header as ReferenceParameters it is much easier to add such functionality later, because the ResourceProperties are static and hence the ResourcePropertiesDocument can be static. With the current proposal the ResourceProperties are dynamic and a service provider would have to generate ResourcePropertiesDocuments dynamically for each service incocation. Again this won't be "rocket science", but I think it's unnecessary overhead. > Yes, the WSRF method GetResourcePropertyDocument could be useful > but it > is possible to manage without it since the clients would always be > able > to construct the property qnames as long as they keep track of the > queryIDs. But of course, if there is a great demand for this optional > WSRF-method we could add it to the documentation. > >> Therefore I propose a translocation of BioMOBY queryIDs from the >> resource properties to wsa:ReferenceParameters. As far as I >> understand, with all the specifications involved this would be legal, >> but please correct me if I am wrong. Below I included some examples >> of what the XML might look like when the queryIDs are moved to the >> SOAP header as wsa:ReferenceParameters. Let me know what you >> think.... > The problem (?) is that the EPR is supposed to be opaque, or in > particular, the ReferenceParameter () > should be > "assumed to be opaque" for the clients. > > "Reference parameters are also provided by the issuer of the endpoint > reference and are otherwise assumed to be opaque to consuming > applications." > > (quoting from the WS-Addressing standard that WSRF builds upon) > > At least my interpretation of this is that clients are not supposed to > understand or parse or manipulate the reference-parameter but instead > just echo it back (if I am confused please correct me)? I think you are right, but in that case I think moving the queryIDs to the EPR is more opaque than the current proposal. The EPR from the SOAP header together with ResourceProperties contains the information required for retrieving status or results. In the current proposal the client can echo back the EPR, but it still has to create the ResourceProperties *dynamically*. If the queryIDs move to the EPR and are returned by a service on invocation, the client can echo back the EPR (containing both the batch ID and the job IDs) and only needs to append one *static* ResourceProperty (either the one to get the status or the one to get the results). Hence the client doesn't have to create anything dynamically, requires less logic and you will only request one resource property at a time, so we even would not need the GetMultipleResourceProperties method anymore. (I assume it doesn't make sense to request the status and the results at the same time.) If a client wants to manipulate the the EPR by stripping out some queryIDs to retrieve a ResourceProperty only for a subset of queryIDs, they *can* do that. This doesn't make life more complex for the service and as far as I understand the specs it is legal. It should not be required to manipulate the EPR and it isn't. If clients lack the logic to request resources for a specific queryID from a batch-job, they can always echo back the whole EPR as ReferenceParameter and get the resource for all the queryIDs of the batch. So moving the queryIDs to the EPR requires less logic on the client side and therefore I think it is a more elegant solution. > Yes, the > reference-parameter can be given as XML but this XML should not be > modified by the clients (I assume that you mean that the clients > should > just include the tags that they need to find status or > results for particular jobs in the batch-call). The issuer of the > endpoint reference naturally must handle the EPR but the clients > should > not try to understand the EPR. > > Also, conceptually, the EPR refers to a specific resource (in this > case > what we call "batch-call", many jobs). If we manipulate the EPR we > "change" its original reference. We tried to clearly define in the > proposal what the EPR refered to (what the "resource" was). > Manipulating > the EPR in some way confuses what it refers to. I disagree. If the queryIDs move to the EPR, the EPR will simply consist of multiple parts. It remains clear what the EPR refers to. The EPR as a whole remains a reference to a specific service invocation. It's perfectly normal according to the specs to have multiple ReferenceParameters in an EPR, so I fail to see how this will be confusing.... > > ------------------- > > Regarding "dynamic" property names (status_{queryID}); the official > WSRF > specification mandates that all properties of a resource MUST be > described by a XML Schema but this is not strictly enforced in the > library we used for the Perl examples (WSRF::Lite) (or at least, in > the > examples of WSRF::Lite that I have seen there is no such XML schema > file) . > > Just to give an example to give an idea of what I am talking about > (non > BioMOBY...): > > > > > > > > > > > > > > > > maxOccurs="unbounded" /> > > > > > This resource has four properties (tns:NumberOfBlocks, tns:BlockSize, > tns:Manufacturer and finally tns:StorageCapability). The qnames of > these > four properties are pre-defined/fixed and not like what we need > "status_q1", "status_q2" etc etc. > > We would need that the resource properties schema allows open content > (using a xsd:any element). This means that the list of valid qnames > for > the resource properties is "open". See "3.3.1.1 Establishing a List of > Valid Resource Properties" in "WSRF Application Notes" > (http://docs.oasis-open.org/wsrf/wsrf-application_notes-1.2-cd-02.pdf) > for more information. I understand it is possible to use a schema that allows open content, but it's not necessary. So why make life more complicated? With kind regards, Pieter > > Kind regards, > Johan Karlsson > > -- > Johan Karlsson > Instituto Nacional de Bioinform?tica (INB) > Integrated Bioinformatics Node (GNV-5) > Dpto. de Arquitectura de Computadores > Campus Universitario de Teatinos, despacho 2.3.9a > 29071 M?laga (Spain) > +34 95 213 3387 > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Wed Sep 27 10:38:26 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 27 Sep 2006 07:38:26 -0700 Subject: [MOBY-dev] RDF deregistration In-Reply-To: <200609271501.46324.d.haase@gsf.de> Message-ID: <002401c6e242$996cc880$6400a8c0@notebook> Hi Dirk, So the agent, right now, is configured to only remove services when it is called by registerService with only the signatureURL portion of the message filled in. When the agent runs off the cron, it is configured only to update services and not to remove them. This was done as a preventative measure, but I don't think that it is still necessary to do this. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Wednesday, September 27, 2006 6:02 AM > To: 'Core developer announcements' > Subject: [MOBY-dev] RDF deregistration > > Eddie, > > is it possible that the deregistration of services by > removing it from an RDF document does not work currently? I > deleted the section for a service called > getGeneticElementNamesByFreeText from > http://mips.gsf.de/proj/planet/moby/RDF/all_mips_services.rdf > and called the agent but it's not removed from MOBY central yet. > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed Sep 27 12:29:54 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:29:54 -0700 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <002401c6e242$996cc880$6400a8c0@notebook> References: <002401c6e242$996cc880$6400a8c0@notebook> Message-ID: <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> I guess before we switch on that last bit of functionality we should ask if anyone has noticed anything unusual in the Agent behaviour that they haven't said anything about on the list. I've been using it for my own services for the past couple of weeks, and it seems to be well-behaved so far, but if anyone has noticed anything nasty, now is the time to say so! Cheers all! M On Wed, 2006-09-27 at 07:38 -0700, Edward Kawas wrote: > Hi Dirk, > > So the agent, right now, is configured to only remove services when it is called > by registerService with only the signatureURL portion of the message filled in. > When the agent runs off the cron, it is configured only to update services and > not to remove them. This was done as a preventative measure, but I don't think > that it is still necessary to do this. > > Thanks, > > Eddie > > > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > > Sent: Wednesday, September 27, 2006 6:02 AM > > To: 'Core developer announcements' > > Subject: [MOBY-dev] RDF deregistration > > > > Eddie, > > > > is it possible that the deregistration of services by > > removing it from an RDF document does not work currently? I > > deleted the section for a service called > > getGeneticElementNamesByFreeText from > > http://mips.gsf.de/proj/planet/moby/RDF/all_mips_services.rdf > > and called the agent but it's not removed from MOBY central yet. > > > > Best, > > dirk > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Sep 27 12:33:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:33:53 -0700 Subject: [MOBY-dev] [spam] Re: BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: References: <44FED787.5010002@ac.uma.es> Message-ID: <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-09-27 at 17:15 +0200, Pieter Neerincx wrote: > > you are describing than the one in the example? Can you give some > > examples where it would be necessary to return the queryIDs? Again, > > not > > sure if I understand It's a part of the API: The queryID has no intrinsic meaning Enumeration of mobyData elements is achieved by the queryID attribute of the mobyData element, whose value has no intrinsic meaning. The client program should choose it be any legal XML attribute value, such that it is unique to each mobyData in the message. Service providers should not attempt to interpret the value of queryID; it is simply an identifier. The service provider must assign the same queryID to the associated mobyData element in their response message (described below). This allows the client program to match each query with its corresponding response. The articleName attribute of the Simple and/or Collection elements is optional (it may or may not be there, and if there, it may or may not have a non-null value), and is used to invoke services that have named arguments; a single queryInput may contain multiple Simple and/or Collection articles that need to be differentiated by name. (from http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY- S_API/InputMessage.html) M From markw at illuminae.com Wed Sep 27 12:41:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:41:02 -0700 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> Message-ID: <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> The agent de-registering services that have been removed from an RDF document since it's last visit. M On Wed, 2006-09-27 at 17:37 +0100, Martin Senger wrote: > Mark, > > I guess before we switch on that last bit of functionality > > What bit of functionality, please? > > Martin > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Sep 27 12:45:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:45:48 -0700 Subject: [MOBY-dev] [moby] Re: [spam] Re: BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: <4d93f07c0609270941icd21a87j75bff0e7926ecc8d@mail.gmail.com> References: <44FED787.5010002@ac.uma.es> <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270941icd21a87j75bff0e7926ecc8d@mail.gmail.com> Message-ID: <1159375548.27141.51.camel@bioinfo.icapture.ubc.ca> Correct, this is now mandatory. Gbrowse_moby is forgiving when it receives output data from non- compliant services, but is API-compliant by always sending an articleName when it passes data to a service (regardless of whether or not that service checks it). Newer versions of Taverna are *not* forgiving at all - both input and output must have articleNames. I don't know about other clients... M On Wed, 2006-09-27 at 17:41 +0100, Martin Senger wrote: > > The articleName attribute of the Simple and/or Collection > elements is > optional (it may or may not be there, and if there, it may or > may not > have a non-null value), > > I remember that this was the case at the beginning - but now it is > mandatory. (Even though many services and clients are still forgiving > about it.) Am I right? > > Martin > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From martin.senger at gmail.com Wed Sep 27 12:41:00 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:41:00 +0100 Subject: [MOBY-dev] [spam] Re: BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> References: <44FED787.5010002@ac.uma.es> <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0609270941icd21a87j75bff0e7926ecc8d@mail.gmail.com> > The articleName attribute of the Simple and/or Collection elements is > optional (it may or may not be there, and if there, it may or may not > have a non-null value), I remember that this was the case at the beginning - but now it is mandatory. (Even though many services and clients are still forgiving about it.) Am I right? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed Sep 27 12:48:30 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:48:30 -0700 Subject: [MOBY-dev] [personal] Re: [moby] Re: RDF deregistration In-Reply-To: <4d93f07c0609270944kb959b6ep41f2d159a76eef7a@mail.gmail.com> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270944kb959b6ep41f2d159a76eef7a@mail.gmail.com> Message-ID: <1159375710.27141.55.camel@bioinfo.icapture.ubc.ca> I don't know if it is the "main" part, but it was one of the three primary functions - register, edit, deregister - that the agent can accomplish. Call it being overly cautious :-) If there were a bug in the agent that we hadn't noticed during testing, we didn't want to wipe-out the registry (though it is backed-up daily, so we could recover anyway). It looks like there are no obvious bugs... M On Wed, 2006-09-27 at 17:44 +0100, Martin Senger wrote: > > The agent de-registering services that have been removed from > an RDF > document since it's last visit. > > Mark, I thought that this was the *main* part of the agent > functionality. Why else we should have an agent (except some automatic > cleaning perhaps)? > > I am again a bit surprise (which is quite normal, when there is a talk > about our mysterious agent :-)). > > Martin > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From martin.senger at gmail.com Wed Sep 27 12:44:04 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:44:04 +0100 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0609270944kb959b6ep41f2d159a76eef7a@mail.gmail.com> > The agent de-registering services that have been removed from an RDF > document since it's last visit. Mark, I thought that this was the *main* part of the agent functionality. Why else we should have an agent (except some automatic cleaning perhaps)? I am again a bit surprise (which is quite normal, when there is a talk about our mysterious agent :-)). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Wed Sep 27 12:37:14 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:37:14 +0100 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> Mark, I guess before we switch on that last bit of functionality What bit of functionality, please? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Wed Sep 27 12:35:43 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:35:43 +0100 Subject: [MOBY-dev] RDF deregistration In-Reply-To: <002401c6e242$996cc880$6400a8c0@notebook> References: <200609271501.46324.d.haase@gsf.de> <002401c6e242$996cc880$6400a8c0@notebook> Message-ID: <4d93f07c0609270935o2916f00dsb739e263658e4f5c@mail.gmail.com> Eddie, So the agent, right now, is configured to only remove services when it is > called > by registerService with only the signatureURL portion of the message > filled in. > When the agent runs off the cron, it is configured only to update services > and > not to remove them. What are you talking about please? Why a cron job matters how the agent behaves. The agent is a part of BioMoby API so it should behave consistenly and accordingly the documentation. But perhaps I am again missing something... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Thu Sep 28 08:02:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 13:02:36 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> Message-ID: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Mark, Eddie, I think there is a bug (also) in Central in XML escaping. Javier found that he was not able to register a service with a URL containing ampersand. I replied: it may be that the dashboard does not properly escape it in the registration > request > and, indeed, it is true. Today, I have fixed it in Dashboard (actually in CentralImpl.java) but found that it seems to be a double-error. Also the Central does not properly escape XML characters. This is my registration request: mobyHelloBiomobyWorld_TMP_4Testing samples.jmoby.net http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=no martin.senger at gmail.com1 Object (you may noticed that the URL has now a properly escaped ampersand). The service was registered successfully - but when I asked for it (findService) I got back this: Testing 1 moby martin.senger at gmail.com http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=no Object (you may notice that here the URL has wrongly an un-escaped ampersand). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Thu Sep 28 10:58:08 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 15:58:08 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Message-ID: <4d93f07c0609280758n49cf3fd0o3325420126b4f33b@mail.gmail.com> > Ah! It also has a default url for the moby registry that does not > exist anymore, so updating this could also be nice. Who has the wrong default? Dashboard? It does not (as far as I see it), dashboard uses: URL: http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.p URI: http://mobycentral.icapture.ubc.ca/MOBY/Central Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Thu Sep 28 11:19:59 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 28 Sep 2006 08:19:59 -0700 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Message-ID: <002b01c6e311$91b78330$6400a8c0@notebook> Hi Martin, Just my thoughts on this, but because this is text content of an xml element, should central really be escaping ampersands? My question, I guess, is should this be the job of the client or the registry? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Thursday, September 28, 2006 5:03 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Registering a MOBY service > > Mark, Eddie, > I think there is a bug (also) in Central in XML escaping. > > Javier found that he was not able to register a service > with a URL containing ampersand. I replied: > > it may be that the dashboard does not properly escape it in > the registration > > request > > > > and, indeed, it is true. Today, I have fixed it in Dashboard > (actually in > CentralImpl.java) but found that it seems to be a > double-error. Also the Central does not properly escape XML > characters. > > This is my registration request: > > mobyHelloBi > omobyWorld_TMP_4Testing e> > samples.jmoby.net > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > mobyWorld?abc=def&yes=no > martin.senger at gmail.com1 you can unregister this service anytime...]]> > > Object > > > > > > > > > (you may noticed that the URL has now a properly escaped > ampersand). The service was registered successfully - but > when I asked for it (findService) I got back this: > > > serviceName='HelloBiomobyWorld_TMP_4' lsid='urn:lsid: > biomoby.org:serviceinstance:samples.jmoby.net > ,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > Testing< > /serviceType> > 1 > moby > service anytime...]]> > martin.senger at gmail.com > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > mobyWorld?abc=def&yes=no > > > > Object bjectType> > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped > ampersand). > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From martin.senger at gmail.com Thu Sep 28 11:32:28 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 16:32:28 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <002b01c6e311$91b78330$6400a8c0@notebook> References: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> <002b01c6e311$91b78330$6400a8c0@notebook> Message-ID: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> Eddie, Just my thoughts on this, but because this is text content of an xml > element, > should central really be escaping ampersands? My question, I guess, is > should > this be the job of the client or the registry? One of us does not understand the point :-) The client sends properly escaped XML. Registry stores it. Later a client asks "find the service". Registry retrieves it from the database, converts it into XML and sends it back. But it converts it wrongly - it should conform with the XML spec - which it does not. Cheers, Martin Thanks, > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > > Martin Senger > > Sent: Thursday, September 28, 2006 5:03 AM > > To: Core developer announcements > > Subject: Re: [MOBY-dev] Registering a MOBY service > > > > Mark, Eddie, > > I think there is a bug (also) in Central in XML escaping. > > > > Javier found that he was not able to register a service > > with a URL containing ampersand. I replied: > > > > it may be that the dashboard does not properly escape it in > > the registration > > > request > > > > > > > and, indeed, it is true. Today, I have fixed it in Dashboard > > (actually in > > CentralImpl.java) but found that it seems to be a > > double-error. Also the Central does not properly escape XML > > characters. > > > > This is my registration request: > > > > mobyHelloBi > > omobyWorld_TMP_4Testing > e> > > samples.jmoby.net > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > mobyWorld?abc=def&yes=no > > martin.senger at gmail.com horitativeService>1 > you can unregister this service anytime...]]> > > > > Object > > > > > > > > > > > > > > > > > > (you may noticed that the URL has now a properly escaped > > ampersand). The service was registered successfully - but > > when I asked for it (findService) I got back this: > > > > > > > serviceName='HelloBiomobyWorld_TMP_4' lsid='urn:lsid: > > biomoby.org:serviceinstance:samples.jmoby.net > > ,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > > Testing< > > /serviceType> > > 1 > > moby > > > service anytime...]]> > > martin.senger at gmail.com > > > > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > mobyWorld?abc=def&yes=no > > > > > > > > Object > bjectType> > > > > > > > > > > > > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped > > ampersand). > > > > Cheers, > > Martin > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Thu Sep 28 10:53:00 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Thu, 28 Sep 2006 16:53:00 +0200 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Message-ID: Good to know that. PyBiomoby also suffer from this bug. I will provide a fix for that when I am ready, apart of this, the interaction with the registry using PyBiomoby is really nice. Ah! It also has a default url for the moby registry that does not exist anymore, so updating this could also be nice. Javier. On 9/28/06, Martin Senger wrote: > Mark, Eddie, > I think there is a bug (also) in Central in XML escaping. > > Javier found that he was not able to register a service with a URL > containing ampersand. I replied: > > > > > > > > it may be that the dashboard does not properly escape it in the > registration request > > and, indeed, it is true. Today, I have fixed it in Dashboard (actually in > CentralImpl.java) but found that it seems to be a double-error. Also the > Central does not properly escape XML characters. > > This is my registration request: > > mobyHelloBiomobyWorld_TMP_4Testing > samples.jmoby.net > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=nomartin.senger at gmail.com1 you can unregister this service > anytime...]]> > > Object > > > > > > > > > (you may noticed that the URL has now a properly escaped ampersand). The > service was registered successfully - but when I asked for it (findService) > I got back this: > > > serviceName='HelloBiomobyWorld_TMP_4' > lsid='urn:lsid:biomoby.org:serviceinstance:samples.jmoby.net,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > lsid='urn:lsid:biomoby.org:servicetype:Testing:2006-02-25T12-49-15Z'>Testing > 1 > moby > anytime...]]> > martin.senger at gmail.com > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=no > > > > lsid='urn:lsid:biomoby.org:objectclass:Object:2001-09-21T16-00-00Z'>Object > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped ampersand). > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger From jatorre at gmail.com Thu Sep 28 11:04:48 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Thu, 28 Sep 2006 17:04:48 +0200 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280758n49cf3fd0o3325420126b4f33b@mail.gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> <4d93f07c0609280758n49cf3fd0o3325420126b4f33b@mail.gmail.com> Message-ID: No, no. It is PyBiomoby. It uses URL: http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl URI: http://mobycentral.cbr.nrc.ca/MOBY/Central As you can see here: http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/moby-live/Python/bioMoby/mobyClient.py?rev=1.6&cvsroot=biomoby&content-type=text/vnd.viewcvs-markup Javier. On 9/28/06, Martin Senger wrote: > > > > Ah! It also has a default url for the moby registry that does not > > exist anymore, so updating this could also be nice. > > Who has the wrong default? Dashboard? It does not (as far as I see it), > dashboard uses: > > URL: > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.p > URI: http://mobycentral.icapture.ubc.ca/MOBY/Central > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger From edward.kawas at gmail.com Thu Sep 28 12:59:36 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 28 Sep 2006 09:59:36 -0700 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> Message-ID: <004201c6e31f$7c6ac060$6400a8c0@notebook> Okay, I have noticed something else: If I try to register a service in dashboard where I escape the &, dashboard does the following: Given-> &, dashboard shows the raw XML as-> &amp; Anyways, if I register a service with &, a find service (using a perl client) returns &. If I register a service with a &, a find service returns the & What am I missing? Is the problem that dashboard escapes the & in both cases and central doesn't? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Thursday, September 28, 2006 8:32 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Registering a MOBY service > > Eddie, > > Just my thoughts on this, but because this is text content of an xml > > element, > > should central really be escaping ampersands? My question, > I guess, is > > should this be the job of the client or the registry? > > > One of us does not understand the point :-) > > The client sends properly escaped XML. Registry stores it. > Later a client > asks "find the service". Registry retrieves it from the > database, converts > it into XML and sends it back. But it converts it wrongly - it should > conform with the XML spec - which it does not. > > Cheers, > Martin > > > Thanks, > > > > Eddie > > > > > -----Original Message----- > > > From: moby-dev-bounces at lists.open-bio.org > > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > > > Martin Senger > > > Sent: Thursday, September 28, 2006 5:03 AM > > > To: Core developer announcements > > > Subject: Re: [MOBY-dev] Registering a MOBY service > > > > > > Mark, Eddie, > > > I think there is a bug (also) in Central in XML escaping. > > > > > > Javier found that he was not able to register a service > > > with a URL containing ampersand. I replied: > > > > > > it may be that the dashboard does not properly escape it in > > > the registration > > > > request > > > > > > > > > > and, indeed, it is true. Today, I have fixed it in Dashboard > > > (actually in > > > CentralImpl.java) but found that it seems to be a > > > double-error. Also the Central does not properly escape XML > > > characters. > > > > > > This is my registration request: > > > > > > mobyHelloBi > > > omobyWorld_TMP_4Testing > > e> > > > samples.jmoby.net > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > > mobyWorld?abc=def&yes=no > > > martin.senger at gmail.com > horitativeService>1 > > you can unregister this service anytime...]]> > > > > > > Object > > > > > > > > > > > > > > > > > > > > > > > > > > > (you may noticed that the URL has now a properly escaped > > > ampersand). The service was registered successfully - but > > > when I asked for it (findService) I got back this: > > > > > > > > > > > serviceName='HelloBiomobyWorld_TMP_4' lsid='urn:lsid: > > > biomoby.org:serviceinstance:samples.jmoby.net > > > ,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > > > Testing< > > > /serviceType> > > > 1 > > > moby > > > > > service anytime...]]> > > > martin.senger at gmail.com > > > > > > > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > > mobyWorld?abc=def&yes=no > > > > > > > > > > > > Object > > bjectType> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped > > > ampersand). > > > > > > Cheers, > > > Martin > > > > > > > > > -- > > > Martin Senger > > > email: martin.senger at gmail.com > > > skype: martinsenger > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at lists.open-bio.org > > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: findservicetest.pl_EDDIE Type: application/octet-stream Size: 1537 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/moby-dev/attachments/20060928/af13db3e/attachment-0001.obj From martin.senger at gmail.com Thu Sep 28 13:43:52 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 18:43:52 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <004201c6e31f$7c6ac060$6400a8c0@notebook> References: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> <004201c6e31f$7c6ac060$6400a8c0@notebook> Message-ID: <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> > If I try to register a service in dashboard where I escape the & You are not supposed to escape anything. Whatever you put in the text field with the sevice URL, will be delivered, properly escaped, to the registry. So if you want to have an ampersand in the URL, you put there just ampersand. If you - from whatever reasons - want to have a strange UYL that contains something like: http://what.com/strange?yes&dear you put it there and it is again delivers properly to the registry (btw, as: http://what.com/strange?yes&amp;dear which is correct). > Anyways, if I register a service with &, a find service (using a perl > client) > returns & But it should not. It should return a valid XML string - and a string with a un-escaped ampersand is not a valid XML string. The rgistry should return & instead. What am I missing? Perhaps someone else can enter this discussion and try to explain it better than I do. (Unless, of course, I am missing something). Or skype me... (user name 'thesengers'). But the problem is important to be solved soon. I would say, it is utgent. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Thu Sep 28 13:56:57 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Thu, 28 Sep 2006 19:56:57 +0200 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> References: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> <004201c6e31f$7c6ac060$6400a8c0@notebook> <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> Message-ID: Hi Martin, Well if I can help a bit... Martin is right and I think what you exposed is clear. Ampersand are not allowed within xml documents and must be scaped. So when a client comunicates with the moby registry if somehwere inside the message there is an ampersand it will have to be scaped. And pyBiomoby does it correctly by the way (I was wrong in my last email). My service got registered correctly, and I suppose is correctly inside the biomoby registry database. But then when I connect to the registry, let say with dashboard and try to retrieve the list of services, the registry takes the data from its database (there is a database behind right?) and produces and XML with the services registered. This XML is wrong, it does not scape the ampersand and therefore is a wrong xml document/message. When dashboard tries to open, the parser complains because it finds a non-valid xml document and refuse to open it. The conslussion. Because there is an ampersand in a service end point in the registry right now registered, every message that includes this service with the end point produces an invalid XML document. Why is this urgent? Every user that dowloads, for example, dashboard, and try to browse the registry will not be able to do it because dashboard see that the messages coming from the registry are malformed. So, although is not dashboard issue, dashboard has become unusuable because the registry is producing malformed xml. Hope this helps. Javier. On 9/28/06, Martin Senger wrote: > > If I try to register a service in dashboard where I escape the & > > > You are not supposed to escape anything. Whatever you put in the text field > with the sevice URL, will be delivered, properly escaped, to the registry. > So if you want to have an ampersand in the URL, you put there just > ampersand. If you - from whatever reasons - want to have a strange UYL that > contains something like: > > http://what.com/strange?yes&dear > > you put it there and it is again delivers properly to the registry (btw, as: > > http://what.com/strange?yes&amp;dear > > which is correct). > > > > Anyways, if I register a service with &, a find service (using a perl > > client) > > returns & > > > But it should not. It should return a valid XML string - and a string with a > un-escaped ampersand is not a valid XML string. The rgistry should return > & instead. > > > What am I missing? > > > Perhaps someone else can enter this discussion and try to explain it better > than I do. (Unless, of course, I am missing something). Or skype me... (user > name 'thesengers'). > > But the problem is important to be solved soon. I would say, it is utgent. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From edward.kawas at gmail.com Thu Sep 28 13:58:42 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 28 Sep 2006 10:58:42 -0700 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> Message-ID: <004c01c6e327$be01b350$6400a8c0@notebook> > > Anyways, if I register a service with &, a find service > (using a perl > > client) > > returns & > > > But it should not. It should return a valid XML string - and > a string with a un-escaped ampersand is not a valid XML > string. The rgistry should return & instead. Okay, I see the problem now. I will attempt to fix it! Thanks, Eddie From johan at ac.uma.es Fri Sep 29 12:12:55 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Fri, 29 Sep 2006 18:12:55 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: References: <44FED787.5010002@ac.uma.es> Message-ID: <451D4607.1090602@ac.uma.es> Hi Pieter, Thank you for your help and suggestions. From what we can understand, no new functionality would be possible by moving the position of the queryIDs. Really, it is just a question of where to put the information, the same information is sent in both cases. We would like to keep the proposal as it is and to have a standard that provides a much needed functionality in BioMOBY. > Not necessarily. Somehow you have to keep track of what conditions > were used in an experiment, so you know how you got to the results > and you make sure you can reproduce it. Either the client stores the > inputs and parameters used for service execution and combines it with > the results or the service output contains all the information about > how the results were produced. This can be a combination of echoing > inputs back and/or providing provisioning blocks and/or service notes > to create an "e-labjournal". In the latter case you can forget about > the XML of the original service invocation and you only need the > output. Both approaches work, but in the latter case you keep the > information about an experiment together and hence you can not "lose" > the experimental conditions. > Well, an "e-labjournal" is a nice idea but it is outside of the scope of this proposal. Of course, it is not necessary that the service saves the input (async services would temporarily keep the results depending on the policies of the service provider) because the client could keep track of the input, results, provisioning blocks and service notes. >> Anyway, it is not so complicated >> to handle the queryIDs for the client (see some of the example code of >> the client at the prototype page). Maybe it is another situation that >> you are describing than the one in the example? Can you give some >> examples where it would be necessary to return the queryIDs? Again, >> not >> sure if I understand. >> >> http://bioinfo.pcm.uam.es/prototype/ >> > > I'm sure it's not "rocket science" to store the queryIDs on the > client, but it's simply not necessary. IMHO it's easier to return the > queryIDs to the client as compared to storing them on the client. > That's all. > As you say, it is simply a difference of approach. Following either approach, it is possible to ask for status and results for jobs. We have chosen one way that is implemented in the Perl libraries and (hopefully) well specified in the proposal. > I'm not arguing to add the GetResourcePropertyDocument method right > now, but I feel it would be good to keep the option open to do so in > the future. Nothing stops this from being added in the future with the current proposal. > If the queryIDs move to the EPR and are returned by a service on > invocation, the client can echo back the EPR (containing both the > batch ID and the job IDs) and only needs to append one *static* > ResourceProperty (either the one to get the status or the one to get > the results). Hence the client doesn't have to create anything > dynamically, requires less logic and you will only request one > resource property at a time, so we even would not need the > GetMultipleResourceProperties method anymore. (I assume it doesn't > make sense to request the status and the results at the same time.) > Well, no, it would not make much sense for the same job(s). There is nothing that stops a client from doing it, though (but asking for not existing properties (results) would return an WSRF error, of course). However, some clients could want to request (in the same message) status for one job "q1" (property status_q1) and the result for another job "q2" (property result_q2). This is probably not a very common situation but a client could choose to only ask for only status/result properties or for a mix. > If a client wants to manipulate the the EPR by stripping out some > queryIDs to retrieve a ResourceProperty only for a subset of > queryIDs, they *can* do that. This doesn't make life more complex for > the service and as far as I understand the specs it is legal. It > should not be required to manipulate the EPR and it isn't. If clients > lack the logic to request resources for a specific queryID from a > batch-job, they can always echo back the whole EPR as > ReferenceParameter and get the resource for all the queryIDs of the > batch. So moving the queryIDs to the EPR requires less logic on the > client side and therefore I think it is a more elegant solution. Well, such clients (that lack logic to edit the EPR) would (potentially) waste bandwidth or be very limited. If a client can only ask for the results of all jobs and the first job is finished after 5 minutes and the second job is finished after 10 hours, this client would not be very useful (either you have to wait 10 hours to get the result of the 5-minute job or you retrieve the result of the 5-minute job twice). In summary, we think that it is not necessary to change the proposal, it can do what is needed and we have a working implementation. Anyway, thank you for your suggestions. Kind regards, Johan -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From markw at illuminae.com Fri Sep 1 06:03:01 2006 From: markw at illuminae.com (mark wilkinson) Date: Fri, 1 Sep 2006 06:03:01 +0000 GMT Subject: [MOBY-dev] Cleaning out the test registry Message-ID: <851341673-1157090602-cardhu_blackberry.rim.net-13953-@engine19-cell01> Is anyone using the test registry (bioinfo.icapture.ubc.ca) in the next couple of weeks? I'm teaching a course on moby/taverna from the 10th to the 14th and I'd like to purge the test registry and bring the registry code and the test ontologies into sync with the real ones before that. Let me know if this is going to disrupt anyone elses courses or activities. It isn't necessary, but it's easier for the students to see what is going on if they have a clean slate to work with. (By the way, I'm happy to do this for ANYONE who asks!! Please feel free to request thius if you are teaching a workshop or something) Mark -- Mark Wilkinson ...on the road! From d.haase at gsf.de Mon Sep 4 09:07:33 2006 From: d.haase at gsf.de (Dirk Haase) Date: Mon, 4 Sep 2006 11:07:33 +0200 Subject: [MOBY-dev] MOBY Namespace URI confusion Message-ID: <200609041107.33524.d.haase@gsf.de> Hi all, this morning I learned that two different URIs in the definition of the 'moby' namespace are in use: 1 - xmlns:moby="http://www.biomoby.org/moby" 2 - xmlns:moby="http://www.biomoby.org/moby-s" The latter one is - as far as I see - only used by the Perl module MOBY::Client::Service for sending out service invocation messages. I would not bother about it, but it seems that MoSeS generated Services just can not deal with this, they require the first version. So I'm wondering, is this - a bug in the MoSeS XML parsers, which should not rely on a certain URI? - is the second URI version just wrong and the mentioned Perl module has to be changed? Or both? Best, dirk From markw at illuminae.com Mon Sep 4 14:36:46 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 4 Sep 2006 14:36:46 +0000 GMT Subject: [MOBY-dev] MOBY Namespace URI confusion In-Reply-To: <200609041107.33524.d.haase@gsf.de> References: <200609041107.33524.d.haase@gsf.de> Message-ID: <955595035-1157380635-cardhu_blackberry.rim.net-1275-@engine24-cell01> I'll change the moby-s one to "moby". Eddie and I discovered a couple of weeks ago that the SOAP::Lite parser fails to properly parse URI's containing a "-" character!! What a nightmare... Thanks for the heads-up about this one! M -- Mark Wilkinson ...on the road! -----Original Message----- From: Dirk Haase Date: Mon, 4 Sep 2006 11:07:33 To:Moby-dev at biomoby.org Subject: [MOBY-dev] MOBY Namespace URI confusion Hi all, this morning I learned that two different URIs in the definition of the 'moby' namespace are in use: 1 - xmlns:moby="http://www.biomoby.org/moby" 2 - xmlns:moby="http://www.biomoby.org/moby-s" The latter one is - as far as I see - only used by the Perl module MOBY::Client::Service for sending out service invocation messages. I would not bother about it, but it seems that MoSeS generated Services just can not deal with this, they require the first version. So I'm wondering, is this - a bug in the MoSeS XML parsers, which should not rely on a certain URI? - is the second URI version just wrong and the mentioned Perl module has to be changed? Or both? Best, dirk _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Sep 4 14:36:46 2006 From: markw at illuminae.com (mark wilkinson) Date: Mon, 4 Sep 2006 14:36:46 +0000 GMT Subject: [MOBY-dev] MOBY Namespace URI confusion In-Reply-To: <200609041107.33524.d.haase@gsf.de> References: <200609041107.33524.d.haase@gsf.de> Message-ID: <955595035-1157380635-cardhu_blackberry.rim.net-1275-@engine24-cell01> I'll change the moby-s one to "moby". Eddie and I discovered a couple of weeks ago that the SOAP::Lite parser fails to properly parse URI's containing a "-" character!! What a nightmare... Thanks for the heads-up about this one! M -- Mark Wilkinson ...on the road! -----Original Message----- From: Dirk Haase Date: Mon, 4 Sep 2006 11:07:33 To:Moby-dev at biomoby.org Subject: [MOBY-dev] MOBY Namespace URI confusion Hi all, this morning I learned that two different URIs in the definition of the 'moby' namespace are in use: 1 - xmlns:moby="http://www.biomoby.org/moby" 2 - xmlns:moby="http://www.biomoby.org/moby-s" The latter one is - as far as I see - only used by the Perl module MOBY::Client::Service for sending out service invocation messages. I would not bother about it, but it seems that MoSeS generated Services just can not deal with this, they require the first version. So I'm wondering, is this - a bug in the MoSeS XML parsers, which should not rely on a certain URI? - is the second URI version just wrong and the mentioned Perl module has to be changed? Or both? Best, dirk _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From Yogaraj.Khanal at usd.edu Tue Sep 5 01:33:51 2006 From: Yogaraj.Khanal at usd.edu (Yogaraj Khanal) Date: Mon, 04 Sep 2006 20:33:51 -0500 Subject: [MOBY-dev] hi Message-ID: <44FCD3FF.50307@usd.edu> i am new developer of jMoby.Please suggest me the fastest way to do so. Regards, Yogaraj From markw at illuminae.com Tue Sep 5 15:50:51 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 05 Sep 2006 08:50:51 -0700 Subject: [MOBY-dev] [moby] MOBY Namespace URI confusion In-Reply-To: <200609041107.33524.d.haase@gsf.de> References: <200609041107.33524.d.haase@gsf.de> Message-ID: <1157471451.1578.27.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-09-04 at 11:07 +0200, Dirk Haase wrote: > Hi all, > > this morning I learned that two different URIs in the definition of the 'moby' > namespace are in use: > 1 - xmlns:moby="http://www.biomoby.org/moby" > 2 - xmlns:moby="http://www.biomoby.org/moby-s" > > The latter one is - as far as I see - only used by the Perl module > MOBY::Client::Service for sending out service invocation messages. I've just looked at the code and the only line in MOBY::Client::Service that uses it is commented-out...?? I don't think that namespace URI is used at all in the Perl MOBY code anymore. If you do find it somewhere please let me know. M From gordonp at ucalgary.ca Tue Sep 5 16:25:07 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 05 Sep 2006 10:25:07 -0600 Subject: [MOBY-dev] hi In-Reply-To: <44FCD3FF.50307@usd.edu> References: <44FCD3FF.50307@usd.edu> Message-ID: <44FDA4E3.3020302@ucalgary.ca> Hi Yogaraj, If mean that you want to be a new service provider, I think The Extremely Lazy Programmer guide is what you need: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html You should be able to deploy a test service in less than 30 minutes, starting with nothing but a JDK... Regards, Paul Yogaraj Khanal wrote: > i am new developer of jMoby.Please suggest me the fastest way to do so. > Regards, > Yogaraj > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From edward.kawas at gmail.com Tue Sep 5 16:08:47 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 5 Sep 2006 09:08:47 -0700 Subject: [MOBY-dev] hi In-Reply-To: <44FCD3FF.50307@usd.edu> Message-ID: <000701c6d105$92894870$756fa8c0@notebook> The best place to start is: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/ Good luck, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Yogaraj Khanal > Sent: Monday, September 04, 2006 6:34 PM > To: moby-dev at lists.open-bio.org > Subject: [MOBY-dev] hi > > i am new developer of jMoby.Please suggest me the fastest way > to do so. > Regards, > Yogaraj > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Sep 5 19:14:39 2006 From: d.haase at gsf.de (Haase, Dirk) Date: Tue, 5 Sep 2006 21:14:39 +0200 Subject: [MOBY-dev] [moby] MOBY Namespace URI confusion References: <200609041107.33524.d.haase@gsf.de> <1157471451.1578.27.camel@bioinfo.icapture.ubc.ca> Message-ID: <1D78CE9FD586024AB0E0102F6F9A7CF86A0895@sw-rz010.gsf.de> Oh, I'm so sorry, I missed that CVS update... OK, it's rather new (8 weeks) but I should have checked before writing to the list :-| However, thanks for assist, dirk -----Original Message----- From: moby-dev-bounces at lists.open-bio.org on behalf of Mark Wilkinson Sent: Tue 9/5/2006 5:50 PM To: Core developer announcements Subject: Re: [MOBY-dev] [moby] MOBY Namespace URI confusion On Mon, 2006-09-04 at 11:07 +0200, Dirk Haase wrote: > Hi all, > > this morning I learned that two different URIs in the definition of the 'moby' > namespace are in use: > 1 - xmlns:moby="http://www.biomoby.org/moby" > 2 - xmlns:moby="http://www.biomoby.org/moby-s" > > The latter one is - as far as I see - only used by the Perl module > MOBY::Client::Service for sending out service invocation messages. I've just looked at the code and the only line in MOBY::Client::Service that uses it is commented-out...?? I don't think that namespace URI is used at all in the Perl MOBY code anymore. If you do find it somewhere please let me know. M _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From edward.kawas at gmail.com Tue Sep 5 19:42:17 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 5 Sep 2006 12:42:17 -0700 Subject: [MOBY-dev] RDF agent Message-ID: <001701c6d123$6600d930$756fa8c0@notebook> Hi Again, The agent has been updated once again and the updates have been deployed. Key changes to the agent include: 1. LSIDs are ignored by the agent. So the old prerequisite of having to modify the services LSID to cause the agent to process an update is gone. 2. Services that have null signature urls are considered test services and are not processed. 3. Messages received from the agent are more concise (hopefully) and to the point. 4. One message is sent to a single address outlining the changes to all services mapped to that address, instead of one message per service being sent out. 5. Services found to be described by 2 different signatureURL are not processed (security reasons). Hopefully the agent wont upset anyone this time and I wont have to spend too much time filtering out the hate mail ;-) On Friday, I will invoke the agent on the registry and service providers may get a message regarding their services if their services have been updated, removed or if new services have been found in their RDF documents. If you have already downloaded the service description RDF, I would encourage you to use the agent test page at: http://bioinfo.icapture.ubc.ca/ekawas/agent/RDFAgent_test.html. I have noticed during the testing of the agent, that some peoples default/max/min values for secondary parameters are not in sync with the registry. This may be on purpose, but I wanted to give you all a heads up. Using the test page, you can verify the inputs/outputs for your service. If you have any concerns, please let me know! Thanks, Eddie From d.haase at gsf.de Wed Sep 6 06:59:06 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 6 Sep 2006 08:59:06 +0200 Subject: [MOBY-dev] hi In-Reply-To: <44FCD3FF.50307@usd.edu> References: <44FCD3FF.50307@usd.edu> Message-ID: <200609060859.06434.d.haase@gsf.de> Hello Yogaraj, On Tuesday 05 September 2006 03:33, Yogaraj Khanal wrote: > i am new developer of jMoby.Please suggest me the fastest way to do so. In addition to the places already mentioned here, you may also have a look at http://bioinfo.mpiz-koeln.mpg.de/araws/documentation/help/jmoby-step-by-step/ Some real-world example code is here: https://biomoby.tigr.org/wiki/index.php/Code_Examples_-_Java Regards, dirk From gordonp at ucalgary.ca Wed Sep 6 14:02:46 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Wed, 06 Sep 2006 08:02:46 -0600 Subject: [MOBY-dev] hi In-Reply-To: <200609060859.06434.d.haase@gsf.de> References: <44FCD3FF.50307@usd.edu> <200609060859.06434.d.haase@gsf.de> Message-ID: <44FED506.5090007@ucalgary.ca> Hi Dirk, Maybe you should link to these from the jMOBY homepage: I'm sure they'd be useful to other developers, as they are not Arabidopsis specific... Regards, Paul > Hello Yogaraj, > > On Tuesday 05 September 2006 03:33, Yogaraj Khanal wrote: > >> i am new developer of jMoby.Please suggest me the fastest way to do so. >> > > In addition to the places already mentioned here, you may also have a look at > http://bioinfo.mpiz-koeln.mpg.de/araws/documentation/help/jmoby-step-by-step/ > > Some real-world example code is here: > https://biomoby.tigr.org/wiki/index.php/Code_Examples_-_Java > > Regards, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From johan at ac.uma.es Wed Sep 6 14:13:27 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Wed, 06 Sep 2006 16:13:27 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - The location of queryIDs In-Reply-To: References: Message-ID: <44FED787.5010002@ac.uma.es> Pieter, Thank you for a well written letter (and sorry for the delay in answering). > There is only one thing that I don't like about the current proposal: > the location of queryID. For our current synchronous services it's an > attribute of the mobyData element. In the current async services > proposal the queryID jumps around the XML taking several identities: > * in status_queryID01 it > is part of raw text. > * in lsae:status_queryID01> it is part of an element name in the lsae > namespace. > (By the way: Should this element really be in the lsae namespace? I > don't think our status_queryIDxx elements are part of the LSAE specs...) > True, we need to put a better namespace, moby? > It would be > much more convenient if the result from a asynchronous service > invocation would contain both the ServiceInvocationID *AND* the > associated queryIDs. In that case I only have to parse the service > response to create GetResourceProperty requests. Therefore I propose > to supply the queryIDs as wsa:ReferenceParameters just like the > ServiceInvocationID. > I am not sure that I understand the problem completely... The clients must internally store, somehow, the connection between the input (identified by the queryID) and the output? The jobs could, potentially, take a very long time to finish and without knowing the input, getting the output would not be so interesting. Anyway, it is not so complicated to handle the queryIDs for the client (see some of the example code of the client at the prototype page). Maybe it is another situation that you are describing than the one in the example? Can you give some examples where it would be necessary to return the queryIDs? Again, not sure if I understand. http://bioinfo.pcm.uam.es/prototype/ > 2. > WSRF contains an *optional* method to request a resource properties > document. With this method a client can figure out which resource > properties are available and hence what it can request. Although this > method is optional and the current proposal doesn't mention it, I > think it would good to keep the option open to supply such a method. > WSRF does not put any limitations on how a service generates and > provides such a document, so you can generate it dynamically or it > can be a static thing. If we would want to supply such a resource > properties document in the future it would be the easiest if it can > be a static one. However in the current proposal the queryIDs are > part of the resource properties (status_queryIDxx and > result_queryIDxx). This means that the available resource properties > depend on the amount of queries/jobs that were sent to a service and > hence we can not use a static resource properties document. It would > be more convenient if we can strip the queryIDs from the resource > properties and provide them as wsa:ReferenceParameters. In that case > there are only two resource properties (status and result) and we can > describe those in a static resource properties document. At least until now, we have tried to only include exactly what is needed and avoid many, potentially, useful but maybe more complicated WSRF methods. Yes, the WSRF method GetResourcePropertyDocument could be useful but it is possible to manage without it since the clients would always be able to construct the property qnames as long as they keep track of the queryIDs. But of course, if there is a great demand for this optional WSRF-method we could add it to the documentation. > Therefore I propose a translocation of BioMOBY queryIDs from the > resource properties to wsa:ReferenceParameters. As far as I > understand, with all the specifications involved this would be legal, > but please correct me if I am wrong. Below I included some examples > of what the XML might look like when the queryIDs are moved to the > SOAP header as wsa:ReferenceParameters. Let me know what you think.... The problem (?) is that the EPR is supposed to be opaque, or in particular, the ReferenceParameter () should be "assumed to be opaque" for the clients. "Reference parameters are also provided by the issuer of the endpoint reference and are otherwise assumed to be opaque to consuming applications." (quoting from the WS-Addressing standard that WSRF builds upon) At least my interpretation of this is that clients are not supposed to understand or parse or manipulate the reference-parameter but instead just echo it back (if I am confused please correct me)? Yes, the reference-parameter can be given as XML but this XML should not be modified by the clients (I assume that you mean that the clients should just include the tags that they need to find status or results for particular jobs in the batch-call). The issuer of the endpoint reference naturally must handle the EPR but the clients should not try to understand the EPR. Also, conceptually, the EPR refers to a specific resource (in this case what we call "batch-call", many jobs). If we manipulate the EPR we "change" its original reference. We tried to clearly define in the proposal what the EPR refered to (what the "resource" was). Manipulating the EPR in some way confuses what it refers to. ------------------- Regarding "dynamic" property names (status_{queryID}); the official WSRF specification mandates that all properties of a resource MUST be described by a XML Schema but this is not strictly enforced in the library we used for the Perl examples (WSRF::Lite) (or at least, in the examples of WSRF::Lite that I have seen there is no such XML schema file) . Just to give an example to give an idea of what I am talking about (non BioMOBY...): This resource has four properties (tns:NumberOfBlocks, tns:BlockSize, tns:Manufacturer and finally tns:StorageCapability). The qnames of these four properties are pre-defined/fixed and not like what we need "status_q1", "status_q2" etc etc. We would need that the resource properties schema allows open content (using a xsd:any element). This means that the list of valid qnames for the resource properties is "open". See "3.3.1.1 Establishing a List of Valid Resource Properties" in "WSRF Application Notes" (http://docs.oasis-open.org/wsrf/wsrf-application_notes-1.2-cd-02.pdf) for more information. Kind regards, Johan Karlsson -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From d.haase at gsf.de Thu Sep 7 09:26:57 2006 From: d.haase at gsf.de (Dirk Haase) Date: Thu, 7 Sep 2006 11:26:57 +0200 Subject: [MOBY-dev] hi In-Reply-To: <44FED506.5090007@ucalgary.ca> References: <44FCD3FF.50307@usd.edu> <200609060859.06434.d.haase@gsf.de> <44FED506.5090007@ucalgary.ca> Message-ID: <200609071126.58026.d.haase@gsf.de> On Wednesday 06 September 2006 16:02, Paul Gordon wrote: > Hi Dirk, > > Maybe you should link to these from the jMOBY homepage: I'm sure they'd > be useful to other developers, as they are not Arabidopsis specific... Yes, of course, this was on my to-do list for a long time... Now it's done. Thanks for reminder! dirk From edward.kawas at gmail.com Thu Sep 7 22:22:39 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 7 Sep 2006 15:22:39 -0700 Subject: [MOBY-dev] Articlenames Message-ID: <001901c6d2cc$21f82630$6400a8c0@notebook> Hi, I have just committed code that prohibits the registry from registering services and datatypes that have articlenames that contain spaces or special characters `~!@#$%^&*()=+;:'"<,>./?\|. I did this because having those characters prohibits us from expressing the Datatype ontology in OWL. There are a few offending datatypes that currently make use of these characters and hopefully I can track down the people who registered them and ask them to re-register the datatypes. If you know offhand that you may have done this, could you fix your datatypes. Thanks, Eddie From markw at illuminae.com Thu Sep 7 23:29:55 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 07 Sep 2006 16:29:55 -0700 Subject: [MOBY-dev] [moby] Articlenames In-Reply-To: <001901c6d2cc$21f82630$6400a8c0@notebook> References: <001901c6d2cc$21f82630$6400a8c0@notebook> Message-ID: <1157671795.8831.26.camel@bioinfo.icapture.ubc.ca> Hi all, If you have any objections to this, please flame me, not Eddie. He asked me, and I told him to go ahead without properly thinking about it; however now I am having second thoughts. MOBY Central is still using the old codebase, so no worries there. For data-types, it is clear that we have to follow the rules for data- typing that XML places on us. Since data-types in MOBY become XML tags, those rules are pretty restrictive, but generally speaking there aren't any troublesome ones in the registry right now. We do have a problem with some of the Gene Ontology-created namespaces having a second ":" character in them, but I am going to talk to Midori about this ASAP! Hopefully we can get rid of those. However, for articleNames, the XML rules are a lot looser, since these are represented in MOBY as XML attribute values. There are already some articleNames in the object ontology that contain spaces, and those don't particularly concern me (are they causing problems for anyone else?); however other unusual characters might cause problems if the code isn't expecting them. It would be a change in the API if we were to impose limitations on the articleName character-set at this point, but it wont affect most (any?) existing objects or services. Does anyone object to putting a restriction on the characters that can be used in articleNames? Either way, we should probably make an explicit note in the API about what characters are acceptable, even if we simply say "any". M On Thu, 2006-09-07 at 15:22 -0700, Edward Kawas wrote: > Hi, > > I have just committed code that prohibits the registry from registering services > and datatypes that have articlenames that contain spaces or special characters > `~!@#$%^&*()=+;:'"<,>./?\|. > > I did this because having those characters prohibits us from expressing the > Datatype ontology in OWL. > > There are a few offending datatypes that currently make use of these characters > and hopefully I can track down the people who registered them and ask them to > re-register the datatypes. > > If you know offhand that you may have done this, could you fix your datatypes. > > Thanks, > > Eddie > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Fri Sep 8 14:06:37 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 08 Sep 2006 08:06:37 -0600 Subject: [MOBY-dev] [moby] Articlenames In-Reply-To: <1157671795.8831.26.camel@bioinfo.icapture.ubc.ca> References: <001901c6d2cc$21f82630$6400a8c0@notebook> <1157671795.8831.26.camel@bioinfo.icapture.ubc.ca> Message-ID: <450178ED.90508@ucalgary.ca> No complaints here! Both ampersand and blackslash seem like they could have especially nasty consequences in downstream code... > Hi all, > > If you have any objections to this, please flame me, not Eddie. He > asked me, and I told him to go ahead without properly thinking about it; > however now I am having second thoughts. MOBY Central is still using > the old codebase, so no worries there. > > For data-types, it is clear that we have to follow the rules for data- > typing that XML places on us. Since data-types in MOBY become XML tags, > those rules are pretty restrictive, but generally speaking there aren't > any troublesome ones in the registry right now. We do have a problem > with some of the Gene Ontology-created namespaces having a second ":" > character in them, but I am going to talk to Midori about this ASAP! > Hopefully we can get rid of those. > > However, for articleNames, the XML rules are a lot looser, since these > are represented in MOBY as XML attribute values. There are already some > articleNames in the object ontology that contain spaces, and those don't > particularly concern me (are they causing problems for anyone else?); > however other unusual characters might cause problems if the code isn't > expecting them. > > It would be a change in the API if we were to impose limitations on the > articleName character-set at this point, but it wont affect most (any?) > existing objects or services. Does anyone object to putting a > restriction on the characters that can be used in articleNames? Either > way, we should probably make an explicit note in the API about what > characters are acceptable, even if we simply say "any". > > M > > > > > On Thu, 2006-09-07 at 15:22 -0700, Edward Kawas wrote: > >> Hi, >> >> I have just committed code that prohibits the registry from registering services >> and datatypes that have articlenames that contain spaces or special characters >> `~!@#$%^&*()=+;:'"<,>./?\|. >> >> I did this because having those characters prohibits us from expressing the >> Datatype ontology in OWL. >> >> There are a few offending datatypes that currently make use of these characters >> and hopefully I can track down the people who registered them and ask them to >> re-register the datatypes. >> >> If you know offhand that you may have done this, could you fix your datatypes. >> >> Thanks, >> >> Eddie >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> From jatorre at gmail.com Sat Sep 16 11:40:43 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Sat, 16 Sep 2006 13:40:43 +0200 Subject: [MOBY-dev] Registering a MOBY service Message-ID: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> Hi, I am trying to register a service on the BioMOBY registry and I am having some troubles. I am using Dashboard for this. Everything goes right if I try to register the service with this service endpoint: http://synthesys.csic.es:8080/tapir/pywrapper?dsa=training But if I try it to register this one: http://synthesys.csic.es:8080/tapir/pywrapper? dsa=training&protocol=biomoby&serviceName=getCoordinatesOfTaxon Then I get an empty error from the registry, just a "null" Seems that the problem has to do with the & on the url. Is this by purpose? Why I need to register such an ugle end point is another discussion, but not very relevant. Thanks in advance. Javier. From martin.senger at gmail.com Sat Sep 16 12:01:38 2006 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 16 Sep 2006 09:01:38 -0300 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> Message-ID: <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> Javier, Seems that the problem has to do with the & on the url. If the problem is with &, then it may be that the dashboard does not properly escape it in the registration request. I will look at it but I am still "on the move", so I have still only a limited access to dashboard to test it. Sorry again for the delay. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Sat Sep 16 14:13:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Sat, 16 Sep 2006 11:13:36 -0300 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <44F2F7D8.1050905@ucalgary.ca> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <44F072E9.5050206@ebi.ac.uk> <44F2F7D8.1050905@ucalgary.ca> Message-ID: <4d93f07c0609160713q4ce5c3f5r5a9c5e0da90b6762@mail.gmail.com> > With regards to Martin's mail, I don't think usurping the Service type > is a good idea (if I understand the idea correctly, which I may not). Yes, you don't :-) I have not been talking about a Service type.I meant a "category". An attribute used in a registration request. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Sun Sep 17 01:22:48 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Sun, 17 Sep 2006 03:22:48 +0200 Subject: [MOBY-dev] Example of a response message with SOAP envelope Message-ID: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> Hi all, I am encountering some problems creating my services. I am not using any SOAP library so I have to deal with the details of the xml messages being sent. In the BioMOBY website there are some example of request/responses of moby services, but only with the payload, that is starting with MOBY. I was wondering if someone could send me an example response from a MOBY service including the SOAP envelope. Thanks in advance. Javier. From johan at ac.uma.es Mon Sep 18 09:40:59 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Mon, 18 Sep 2006 11:40:59 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> Message-ID: <450E69AB.2000104@ac.uma.es> Martin Senger wrote: > Sorry, I was not able to read the new proposal when it came. I am still not > able to read it in all details (I am traveling and will be actually > completely off-line next two weeks) - but I think that the proposal is fine > and I would for with it. Thanks for creating it. > > Just two comments: > > I agree that storing the fact that a service is able to be called > asynchronously should be part of the service registration process. That > would simplify everything. But I do not fully understand why it cannot be > done only by registering a service with a new category (moby-async, as > suggested). Why do we need a new boolean parameter for it? Why do we need > 'hasCallingDetail" - here again a new category should be enough. What am I > missing? > Sorry, missed to answer this comment. Yes, you are right, in the RDF for service instances there is a predicate called dc:format. Currently, the only allowed value is "BioMoby_service" (I guess this is related to the allowed _three_ values in the registration 'moby', 'cgi' and 'soap'). Could someone with good insight of how this was originally designed let us know if it is ok to add another allowed value to this predicate (dc:format)? It says something that this is an ontology term from the myGrid ontology? http://biomoby.open-bio.org/index.php/for-developers/moby_extensions/moby_metadata Or is there a good argument for keeping the 'hasCallingDetail'? Kind regards, Johan -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From markw at illuminae.com Mon Sep 18 14:47:17 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 07:47:17 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <450E69AB.2000104@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <450E69AB.2000104@ac.uma.es> Message-ID: > Yes, you are right, in the RDF for service instances there is a > predicate called dc:format. Currently, the only allowed value is > "BioMoby_service" (I guess this is related to the allowed _three_ values > in the registration 'moby', 'cgi' and 'soap'). It is related. When we first proposed this predicate to myGrid we suggested moby, cgi, and soap; however myGrid already had a terminology for the predecessor to that predicate. Since we (moby) had not been using RDF up to that point, and thus had no "legacy" to support, we agreed to their terminology without hesitation. > let us know if it is ok to > add another allowed value to this predicate (dc:format)? It says > something that this is an ontology term from the myGrid ontology? I believe it is in the myGrid ontology somewhere. Give me a minute or two and I'll see if I can find it. If necessary, we only need to let the Manchester group know that we want to add a new value and I'm sure there will be no argument from them. Mark -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From markw at illuminae.com Mon Sep 18 14:47:17 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 07:47:17 -0700 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2 - tag missing for GetResourceProperty requests In-Reply-To: <450E69AB.2000104@ac.uma.es> References: <1154976083.44d78953058fb@webmail.cs.umu.se> <31D744C5-1D0D-48AC-A812-8C1D96A417CF@wur.nl> <44EF09DF.6020808@ac.uma.es> <4d93f07c0608251621u33a1da5du3ba093bd260e890a@mail.gmail.com> <450E69AB.2000104@ac.uma.es> Message-ID: > Yes, you are right, in the RDF for service instances there is a > predicate called dc:format. Currently, the only allowed value is > "BioMoby_service" (I guess this is related to the allowed _three_ values > in the registration 'moby', 'cgi' and 'soap'). It is related. When we first proposed this predicate to myGrid we suggested moby, cgi, and soap; however myGrid already had a terminology for the predecessor to that predicate. Since we (moby) had not been using RDF up to that point, and thus had no "legacy" to support, we agreed to their terminology without hesitation. > let us know if it is ok to > add another allowed value to this predicate (dc:format)? It says > something that this is an ontology term from the myGrid ontology? I believe it is in the myGrid ontology somewhere. Give me a minute or two and I'll see if I can find it. If necessary, we only need to let the Manchester group know that we want to add a new value and I'm sure there will be no argument from them. Mark -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From markw at illuminae.com Mon Sep 18 17:32:26 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 10:32:26 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> Message-ID: <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> INPUT AND OUTPUT EXAMPLE: INPUT: SOAP::Transport::HTTP::Client::send_receive: POST http://mobycentral.icapture.ubc.ca/cgi-bin/Services/Services.cgi HTTP/1.1 Accept: text/xml Accept: multipart/* Content-Length: 930 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://biomoby.org/#getDragonAllelesByKeyword" <?xml version='1.0' encoding='UTF-8'?> <moby:MOBY xmlns:moby='http://www.biomoby.org/moby' moby:smessageVersion='0.87'> <moby:mobyContent> <moby:mobyData queryID='1'><moby:Simple moby:articleName=''> <Object namespace="Global_Keyword" id="petal"/> </moby:Simple> </moby:mobyData> </moby:mobyContent> </moby:MOBY> SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK Connection: close OUTPUT ( content is base64 encoded) Server: Apache/2.0.54 (Unix) DAV/2 mod_perl/2.0.1 Perl/v5.8.5 Content-Length: 885 Content-Type: text/xml; charset=utf-8 Client-Date: Mon, 18 Sep 2006 17:30:06 GMT Client-Peer: 127.0.0.1:80 Client-Response-Num: 1 SOAPServer: SOAP::Lite/Perl/0.60 PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48bW9ieTpNT0JZIHhtbG5zOm1vYnk9J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieScgeG1sbnM9J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieSc+PG1vYnk6bW9ieUNvbnRlbnQgbW9ieTphdXRob3JpdHk9J2lsbHVtaW5hZS5jb20nPjxtb2J5Om1vYnlEYXRhIG1vYnk6cXVlcnlJRD0nMScvPjwvbW9ieTptb2J5Q29udGVudD48L21vYnk6TU9CWT4= On Sun, 2006-09-17 at 03:22 +0200, Javier de la Torre wrote: > Hi all, > > I am encountering some problems creating my services. I am not using > any SOAP library so I have to deal with the details of the xml > messages being sent. In the BioMOBY website there are some example of > request/responses of moby services, but only with the payload, that > is starting with MOBY. > > I was wondering if someone could send me an example response from a > MOBY service including the SOAP envelope. > > Thanks in advance. > > Javier. > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Mon Sep 18 18:10:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 11:10:02 -0700 Subject: [MOBY-dev] MOBY Central going down for 15 minutes for a RAM upgrade Message-ID: <1158603002.18578.20.camel@bioinfo.icapture.ubc.ca> Hi all, In one hour we're going to shut-down MOBY Central for just long enough to stick another 2Gig of RAM in it. Shouldn't be more than 15 minutes. Please scream if this is a problem for you! M -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From jatorre at gmail.com Mon Sep 18 22:16:07 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 00:16:07 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> Hi Mark, Thanks for this. I finally used a tracing program to see the interaction with some services. Now I am happy to announce that our software, PyWrapper, can serve BioMOBY services based on templates. We will have a release of the software with BioMOBY support by the end of the month, and then probably, and hopefully!, you will start seeing lot of new services appearing on the registry. But I have to ask... why are you sending the MOBY xml as an escaped string? I understand that you can not create a fix XML schema for the whole thing but at least you can have a simple schema with a mobyContent element and a xsd:any on it right? In any case, why are you using SOAP? Just for the error handling? The services like this does not look very interoperable with anything but BioMOBY clients. Is actually just curiosity.... Javier. On 18/09/2006, at 19:32, Mark Wilkinson wrote: > INPUT AND OUTPUT EXAMPLE: > > INPUT: > > > SOAP::Transport::HTTP::Client::send_receive: POST > http://mobycentral.icapture.ubc.ca/cgi-bin/Services/Services.cgi > HTTP/1.1 > Accept: text/xml > Accept: multipart/* > Content-Length: 930 > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://biomoby.org/#getDragonAllelesByKeyword" > > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP- > ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- > ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP- > ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> ENV:Body> xmlns:namesp3="http://biomoby.org/"> xsi:type="xsd:string"><?xml > version='1.0' encoding='UTF-8'?> > <moby:MOBY xmlns:moby='http://www.biomoby.org/moby' > moby:smessageVersion='0.87'> > <moby:mobyContent> > <moby:mobyData queryID='1'><moby:Simple > moby:articleName=''> > > <Object namespace="Global_Keyword" id="petal"/> > > </moby:Simple> > </moby:mobyData> > > </moby:mobyContent> > > </moby:MOBY> ENV:Body> > SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK > Connection: close > > > > > > > > OUTPUT ( content is base64 encoded) > > > Server: Apache/2.0.54 (Unix) DAV/2 mod_perl/2.0.1 Perl/v5.8.5 > Content-Length: 885 > Content-Type: text/xml; charset=utf-8 > Client-Date: Mon, 18 Sep 2006 17:30:06 GMT > Client-Peer: 127.0.0.1:80 > Client-Response-Num: 1 > SOAPServer: SOAP::Lite/Perl/0.60 > > xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP- > ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- > ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP- > ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> ENV:Body> xmlns:namesp1="http://biomoby.org/">PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48bW9ieT > pNT0JZIHhtbG5zOm1vYnk9J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieScgeG1sbnM9 > J2h0dHA6Ly93d3cuYmlvbW9ieS5vcmcvbW9ieSc > +PG1vYnk6bW9ieUNvbnRlbnQgbW9ieTphdXRob3JpdHk9J2lsbHVtaW5hZS5jb20nPjxtb > 2J5Om1vYnlEYXRhIG1vYnk6cXVlcnlJRD0nMScvPjwvbW9ieTptb2J5Q29udGVudD48L21 > vYnk6TU9CWT4= namesp1:getDragonAllelesByKeywordResponse> ENV:Envelope> > > > > > > > > > > > > > > On Sun, 2006-09-17 at 03:22 +0200, Javier de la Torre wrote: >> Hi all, >> >> I am encountering some problems creating my services. I am not using >> any SOAP library so I have to deal with the details of the xml >> messages being sent. In the BioMOBY website there are some example of >> request/responses of moby services, but only with the payload, that >> is starting with MOBY. >> >> I was wondering if someone could send me an example response from a >> MOBY service including the SOAP envelope. >> >> Thanks in advance. >> >> Javier. >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a > term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the > term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Sep 18 23:20:58 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 18 Sep 2006 16:20:58 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> Message-ID: <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> Hi Javier! > end of the month, and then probably, and hopefully!, you will start > seeing lot of new services appearing on the registry. Fantastic! Looking forward to it! > But I have to ask... why are you sending the MOBY xml as an escaped > string? Because it is illegal to have an tag in the middle of an XML document. (API notes: http://biomoby.open-bio.org/CVS_CONTENT/moby- live/Docs/MOBY-S_API/InputMessage.html and the bottom of http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY- S_API/MessageStructure.html) we either escape it, or we base64 encode it. Either way, what you get from the SOAP payload is a fully-qualified XML document including the XML header such that you can simply pass it to an XML parser verbatim. When I wrote that part of the API I was thinking about future extensibility into non-SOAP messages, where there would be the need for an XML header... it never happened, of course... > In any case, why are you using SOAP? LOL! I often wish we weren't! ;-) It's all historical - Web Services are historically described as a triad of the SOAP/WSDL/UDDI technologies. It seems that UDDI has been more or less lost from this triad, but SOAP/WSDL are still part of the most widely-used definition. Several years ago, for my own amusement, I constructed a pure-CGI version of MOBY, and it worked just fine... so there's no good argument for using SOAP (especially since we can't model MOBY messages in XML schema, so the WSDL standard isn't particularly useful to us either!) > Just for the error handling? The > services like this does not look very interoperable with anything but > BioMOBY clients. Well... In my opinion, Web Services aren't particularly interoperable, period. It is only by our syntactic agreement that MOBY services become interoperable, which is what puts us one step ahead of other interoperability projects. Take any two arbitrary Web Services out there and try to automatically feed the output of one into the input of another :-) Kaboom! As such, I don't see that MOBY is any less interoperable with non-MOBY web services than they are with each other, with the exception that we pass XML rather than raw data. M From markw at illuminae.com Tue Sep 19 03:19:45 2006 From: markw at illuminae.com (markw at illuminae.com) Date: Mon, 18 Sep 2006 23:19:45 -0400 Subject: [MOBY-dev] post-memory-upgrade check Message-ID: <20060918231945.uzwp9x04tw8gc0s4@webmail.illuminae.com> Hi all, MOBY Central (in Vancouver) is now working on its memory upgrade. Please let me know ASAP if you experience anything yucky! I noticed during my last workshop that if you tell all 30 students to hit the "query" button at the same time the registry machine crashes with an "out of memory" error in the system logs, so that's not good! Hopefully it will be more robust from now on. The solution, of course, is to improve on the existing codebase... as many MOBYers have pointed out, I'm "just a biologist" and really shouldn't be coding production systems under *any* circumstances! :-) I agree entirely! Now that we have implemented a (distributed) RDF representation of the registry, there are all sorts of new paradigms we could imagine for registry implementation, and these are best done in Java, since there is only minimal support for RDF in Perl at the moment... I'm going to ask Eddie to consider the possibilities for re-writing the entire registry in Java using an RDF store as the underlying database. We will NOT do this without having a face-to-face meeting with the curent (5?) registry providers to ensure that the migration is painless, but I do think that it is perhaps the best way to move the project forward. In particular, we want to move it out of the current Perl implementation into Java, which seems to be more familiar for most developers (and more powerful at the end of the day). Still, no need to panic. We can talk about this at the next developers meeting. I'm trying to find the funds to help host this meeting... stay tuned! Anyway, please test the registry using whatever mechanism you usually use to access it and let me know ASAP if you notice any problems. Hopefully the new memory is sufficient to get us through the next few months. Nevertheless, the hits on the registry are still increasing monthly, so a new architecture will have to be implemented soon... Best wishes all! Mark From d.haase at gsf.de Tue Sep 19 08:13:30 2006 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 19 Sep 2006 10:13:30 +0200 Subject: [MOBY-dev] post-memory-upgrade check In-Reply-To: <20060918231945.uzwp9x04tw8gc0s4@webmail.illuminae.com> References: <20060918231945.uzwp9x04tw8gc0s4@webmail.illuminae.com> Message-ID: <200609191013.30969.d.haase@gsf.de> On Tuesday 19 September 2006 05:19, markw at illuminae.com wrote: > Hi all, > > MOBY Central (in Vancouver) is now working on its memory upgrade. > Please let me know ASAP if you experience anything yucky! Taverma is not able to load the Biomoby scavenger. It fails with the following error: Failed: Server returned HTTP response code: 400 for URL: http://mobycentral.icapture.ubc.ca/RESOURCES/MOBY-S/Objects [Ljava.lang.StackTraceElement;@1f99e90 ERROR 2006-09-19 10:08:04,838 (org.embl.ebi.escience.scuflui.workbench.ScavengerTree:341) - org.embl.ebi.escience.scuflui.workbench.ScavengerCreationException: Could not retrieve and or process RDF document for BioMoby Objects Best, dirk From jatorre at gmail.com Tue Sep 19 12:37:41 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 14:37:41 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> Message-ID: <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> Hi Mark, > > Because it is illegal to have an tag in the middle of an XML > document. (API notes: http://biomoby.open-bio.org/CVS_CONTENT/moby- > live/Docs/MOBY-S_API/InputMessage.html and the bottom of > http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY- > S_API/MessageStructure.html) > Yes, I know that, but I was wondering why you need to have a full XML message as the payload and not rather the normal way of integrating your xml inside with a different namespace. You could actually have a simple mobyMessage type that defines the mobyContent. And actually you go further because, as far as I understood every moby response message will have then a mobyData element and then a simple or collection element... (By the way! wouldnt be bad to include at least one full xml messages, with the SOAP envelope, on the documentation) > we either escape it, or we base64 encode it. Either way, what you get > from the SOAP payload is a fully-qualified XML document including the > XML header such that you can simply pass it to an XML parser verbatim. > When I wrote that part of the API I was thinking about future > extensibility into non-SOAP messages, where there would be the need > for > an XML header... it never happened, of course... > But this is also possible. In a WSDL file you can define other things than SOAP. For example RESTful services can be described with WSDL files too. > > Several years ago, for my own amusement, I constructed a pure-CGI > version of MOBY, and it worked just fine... so there's no good > argument > for using SOAP (especially since we can't model MOBY messages in XML > schema, so the WSDL standard isn't particularly useful to us either!) > The kind of MOBY services we create can very well described using a WSDL file because our outputs will always be the same and therefore could be typed with xml schema. And a way to produce MOBY services in a RESTful way would make it very easy to create these kind of MOBY services... In general the request services will always accept the same object and parameters and produce the same object as a result... and create a service like this in any language is really simple! And in some cases you could give potential simple-request-service-type moby providers a WSDL file that they can implement. > As such, I don't see that MOBY is any less interoperable with non-MOBY > web services than they are with each other, with the exception that we > pass XML rather than raw data. Well, I see some MOBY services that can be well defined with a WSDL file and that someone outside from the MOBY world could be interested in using... Someone will maybe want to program an interface to these moby services, that are all of the same type (the exact WSDL file), and does not want to worry about BIOMOBY at all (apart of using the registry for discovery and understanding the little semantics of this specific service template). What I am more interested now is on another topic. If you remeber Mark we discussed more than one year ago the need for a paging mechanism for our services in BioMOBY. Now that I am implementing this I took Martin Singer approach to include this functionality on the service: the services always have a two parameters: maxPages and startPage that are used for paging... What is your opinion on this? I think we need an agreement on how this work so that future BioMOBY clients could make use of paging. I dont know if it would be better to move these parameters somewhere inside the MOBY API as they are more operational parameters for lot of services than actual parameters only for my specific service. Is there anybody out there who was implemented paging on any MOBY service? For the time being I am happy with Martin approach and this is the way we are doing it. Best regards. Javier. From gordonp at ucalgary.ca Tue Sep 19 13:51:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 19 Sep 2006 07:51:50 -0600 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> Message-ID: <450FF5F6.3080607@ucalgary.ca> > And a way to produce MOBY services in a RESTful way would make it > very easy to create these kind of MOBY services... In general the > request services will always accept the same object and parameters > and produce the same object as a result... and create a service like > this in any language is really simple! I can submit a CommentedDNASequence to a service that accepts a VirtualSequence (or a blast-text to a service that accepts Object), and if I remember correctly this is where things started to break down in traditional Web Services descriptions... From jatorre at gmail.com Tue Sep 19 14:06:20 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 16:06:20 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <450FF5F6.3080607@ucalgary.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> Message-ID: Right, Thats why BioMOBY is so interesting I suppose. But some services will always accept one, and only one, moby object. For example the first service I created consumes a ScientificName, that is a string. I dont think I can understand any other object as input for this service. Then BioMOBY acts as a simple web service, right? On 19/09/2006, at 15:51, Paul Gordon wrote: > >> And a way to produce MOBY services in a RESTful way would make it >> very easy to create these kind of MOBY services... In general the >> request services will always accept the same object and parameters >> and produce the same object as a result... and create a service like >> this in any language is really simple! > I can submit a CommentedDNASequence to a service that accepts a > VirtualSequence (or a blast-text to a service that accepts Object), > and > if I remember correctly this is where things started to break down in > traditional Web Services descriptions... > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From gordonp at ucalgary.ca Tue Sep 19 14:13:16 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Tue, 19 Sep 2006 08:13:16 -0600 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> Message-ID: <450FFAFC.3080301@ucalgary.ca> No, the beauty of BioMOBY is that it combines Web Services with the Semantic Web. So I can subclass your ScientificName in the ontology, and I MUST be allowed to submit an instance of MyScientificName it to your service. The shared ontology is the key to automagic interoperability... > Right, > > Thats why BioMOBY is so interesting I suppose. But some services will > always accept one, and only one, moby object. For example the first > service I created consumes a ScientificName, that is a string. I dont > think I can understand any other object as input for this service. > Then BioMOBY acts as a simple web service, right? > > On 19/09/2006, at 15:51, Paul Gordon wrote: > > >>> And a way to produce MOBY services in a RESTful way would make it >>> very easy to create these kind of MOBY services... In general the >>> request services will always accept the same object and parameters >>> and produce the same object as a result... and create a service like >>> this in any language is really simple! >>> >> I can submit a CommentedDNASequence to a service that accepts a >> VirtualSequence (or a blast-text to a service that accepts Object), >> and >> if I remember correctly this is where things started to break down in >> traditional Web Services descriptions... >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From edward.kawas at gmail.com Tue Sep 19 13:35:47 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Tue, 19 Sep 2006 06:35:47 -0700 Subject: [MOBY-dev] post-memory-upgrade check In-Reply-To: <200609191013.30969.d.haase@gsf.de> Message-ID: <003f01c6dbf0$84a8d950$6900a8c0@notebook> Hi Dirk, It's working now. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, September 19, 2006 1:14 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] post-memory-upgrade check > > On Tuesday 19 September 2006 05:19, markw at illuminae.com wrote: > > Hi all, > > > > MOBY Central (in Vancouver) is now working on its memory upgrade. > > Please let me know ASAP if you experience anything yucky! > > Taverma is not able to load the Biomoby scavenger. It fails > with the following error: > > Failed: Server returned HTTP response code: 400 for URL: > http://mobycentral.icapture.ubc.ca/RESOURCES/MOBY-S/Objects > [Ljava.lang.StackTraceElement;@1f99e90 > ERROR 2006-09-19 > 10:08:04,838 > (org.embl.ebi.escience.scuflui.workbench.ScavengerTree:341) - > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationExcep > tion: Could not retrieve and or process RDF document for > BioMoby Objects > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 14:44:45 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 19 Sep 2006 14:44:45 +0000 GMT Subject: [MOBY-dev] [moby] Example of a responsemessage with SOAP envelope In-Reply-To: <450FFAFC.3080301@ucalgary.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> Message-ID: <1345293324-1158677122-cardhu_blackberry.rim.net-15136-@engine13-cell01> Precisely :-) it is for this reason that we so strongly emphasise that service providers should not validate incoming requests based on the object name. M -- Mark Wilkinson ...on the road! -----Original Message----- From: Paul Gordon Date: Tue, 19 Sep 2006 08:13:16 To:Core developer announcements Subject: Re: [MOBY-dev] [moby] Example of a response message with SOAP envelope No, the beauty of BioMOBY is that it combines Web Services with the Semantic Web. So I can subclass your ScientificName in the ontology, and I MUST be allowed to submit an instance of MyScientificName it to your service. The shared ontology is the key to automagic interoperability... > Right, > > Thats why BioMOBY is so interesting I suppose. But some services will > always accept one, and only one, moby object. For example the first > service I created consumes a ScientificName, that is a string. I dont > think I can understand any other object as input for this service. > Then BioMOBY acts as a simple web service, right? > > On 19/09/2006, at 15:51, Paul Gordon wrote: > > >>> And a way to produce MOBY services in a RESTful way would make it >>> very easy to create these kind of MOBY services... In general the >>> request services will always accept the same object and parameters >>> and produce the same object as a result... and create a service like >>> this in any language is really simple! >>> >> I can submit a CommentedDNASequence to a service that accepts a >> VirtualSequence (or a blast-text to a service that accepts Object), >> and >> if I remember correctly this is where things started to break down in >> traditional Web Services descriptions... >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 14:56:51 2006 From: markw at illuminae.com (mark wilkinson) Date: Tue, 19 Sep 2006 14:56:51 +0000 GMT Subject: [MOBY-dev] post-memory-upgrade check In-Reply-To: <003f01c6dbf0$84a8d950$6900a8c0@notebook> References: <200609191013.30969.d.haase@gsf.de> <003f01c6dbf0$84a8d950$6900a8c0@notebook> Message-ID: <1182033175-1158677848-cardhu_blackberry.rim.net-17283-@engine25-cell01> Did Tomcat not come-up by itself after the reboot? -- Mark Wilkinson ...on the road! -----Original Message----- From: "Edward Kawas" Date: Tue, 19 Sep 2006 06:35:47 To:"'Core developer announcements'" Subject: Re: [MOBY-dev] post-memory-upgrade check Hi Dirk, It's working now. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Tuesday, September 19, 2006 1:14 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] post-memory-upgrade check > > On Tuesday 19 September 2006 05:19, markw at illuminae.com wrote: > > Hi all, > > > > MOBY Central (in Vancouver) is now working on its memory upgrade. > > Please let me know ASAP if you experience anything yucky! > > Taverma is not able to load the Biomoby scavenger. It fails > with the following error: > > Failed: Server returned HTTP response code: 400 for URL: > http://mobycentral.icapture.ubc.ca/RESOURCES/MOBY-S/Objects > [Ljava.lang.StackTraceElement;@1f99e90 > ERROR 2006-09-19 > 10:08:04,838 > (org.embl.ebi.escience.scuflui.workbench.ScavengerTree:341) - > org.embl.ebi.escience.scuflui.workbench.ScavengerCreationExcep > tion: Could not retrieve and or process RDF document for > BioMoby Objects > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev _______________________________________________ MOBY-dev mailing list MOBY-dev at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/moby-dev From jatorre at gmail.com Tue Sep 19 16:22:07 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 18:22:07 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <450FFAFC.3080301@ucalgary.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> Message-ID: <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> Ups, Right, so my service can be considered a normal web service + a biomoby service. Somehow a MOBY service like mine can be described as a normal web service PLUS: -It does not validate incoming messages, it only make use of the piece it understand Apart of this, the service can be described in a WSDL file. Well, one way to use it, somehow the "canonical" model that represent the object that was used to create it. Uhmmm I still have to think about this more in detail, sorry if I dont understand very well some things and I am just thinking loud. And I also have to probe that my service will not crash when you send your MyScientificName. I am actually using XSLT to take the information I need so I think I am safe because inside your MyScientificName there will still be a ScientificName. I dont mind where in the XML it is because XSLT will find it, hopefully! Javier. On 19/09/2006, at 16:13, Paul Gordon wrote: > No, the beauty of BioMOBY is that it combines Web Services with the > Semantic Web. So I can subclass your ScientificName in the ontology, > and I MUST be allowed to submit an instance of MyScientificName it to > your service. The shared ontology is the key to automagic > interoperability... >> Right, >> >> Thats why BioMOBY is so interesting I suppose. But some services will >> always accept one, and only one, moby object. For example the first >> service I created consumes a ScientificName, that is a string. I dont >> think I can understand any other object as input for this service. >> Then BioMOBY acts as a simple web service, right? >> >> On 19/09/2006, at 15:51, Paul Gordon wrote: >> >> >>>> And a way to produce MOBY services in a RESTful way would make it >>>> very easy to create these kind of MOBY services... In general the >>>> request services will always accept the same object and parameters >>>> and produce the same object as a result... and create a service >>>> like >>>> this in any language is really simple! >>>> >>> I can submit a CommentedDNASequence to a service that accepts a >>> VirtualSequence (or a blast-text to a service that accepts Object), >>> and >>> if I remember correctly this is where things started to break >>> down in >>> traditional Web Services descriptions... >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 16:26:25 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 19 Sep 2006 09:26:25 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> Message-ID: <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: > information I need so I think I am safe because inside your > MyScientificName there will still be a ScientificName. I dont mind > where in the XML it is because XSLT will find it, hopefully! Nope, not quite :-) ScientificName (as a tag name) will not be inside of MyScientificName; however the *content* of MyScientificName will include all of the same elements as the *content* of ScientificName MyScientificName to ScientificName is an inheritence relationship, not a container relationship M From jatorre at gmail.com Tue Sep 19 16:34:39 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Tue, 19 Sep 2006 18:34:39 +0200 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> Message-ID: <0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> Ups! And how does the services work? I mean, do they have to connect to the registry to check the relations of the objects they serve with what other people might be sending them? Or is it that they just take the string, in my case, and do something with it? If it is the second then a user, stupidly, could be sending an object to a service that is not necessarily inheritanced from the data type he understands and he will be using it. Of course there is nothing wrong to provide stupid answers to stupid questions, but, is it like this? The, can I just take the content from the in the income message and expect that it is actually a ScientificName? Thanks. Javier. On 19/09/2006, at 18:26, Mark Wilkinson wrote: > On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: >> information I need so I think I am safe because inside your >> MyScientificName there will still be a ScientificName. I dont mind >> where in the XML it is because XSLT will find it, hopefully! > > > Nope, not quite :-) ScientificName (as a tag name) will not be inside > of MyScientificName; however the *content* of MyScientificName will > include all of the same elements as the *content* of ScientificName > > MyScientificName to ScientificName is an inheritence relationship, > not a > container relationship > > M > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Sep 19 16:53:33 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 19 Sep 2006 09:53:33 -0700 Subject: [MOBY-dev] [moby] Example of a response message with SOAP envelope In-Reply-To: <0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com> <1158600746.18578.1.camel@bioinfo.icapture.ubc.ca> <5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com> <1158621658.19646.9.camel@bioinfo.icapture.ubc.ca> <07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com> <450FF5F6.3080607@ucalgary.ca> <450FFAFC.3080301@ucalgary.ca> <77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com> <1158683185.21783.74.camel@bioinfo.icapture.ubc.ca> <0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> Message-ID: <1158684813.22263.2.camel@bioinfo.icapture.ubc.ca> Well, I don't know how other service providers do it, but I seldom validate the incoming XML *at all*. I simply use an XPath query or something like that to reach into the XML document to get the pieces that I expect to be in there (based on whatever I registered as my input data type). If they are not there, I throw an error. It is possible, of course, to query the ontology to make sure that what you have received is a child of what you registered as consuming... but that's a lot of overhead, and besides, what are you going to do if it isn't a child? fail with an error :-) so I simply fail with an error if I don't find what I want, and skip the expensive validation step altogether. M On Tue, 2006-09-19 at 18:34 +0200, Javier de la Torre wrote: > Ups! > > And how does the services work? I mean, do they have to connect to > the registry to check the relations of the objects they serve with > what other people might be sending them? Or is it that they just take > the string, in my case, and do something with it? If it is the second > then a user, stupidly, could be sending an object to a service that > is not necessarily inheritanced from the data type he understands and > he will be using it. Of course there is nothing wrong to provide > stupid answers to stupid questions, but, is it like this? > > The, can I just take the content from the in the income > message and expect that it is actually a ScientificName? > > Thanks. > > Javier. > > > On 19/09/2006, at 18:26, Mark Wilkinson wrote: > > > On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: > >> information I need so I think I am safe because inside your > >> MyScientificName there will still be a ScientificName. I dont mind > >> where in the XML it is because XSLT will find it, hopefully! > > > > > > Nope, not quite :-) ScientificName (as a tag name) will not be inside > > of MyScientificName; however the *content* of MyScientificName will > > include all of the same elements as the *content* of ScientificName > > > > MyScientificName to ScientificName is an inheritence relationship, > > not a > > container relationship > > > > M > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From ots at ac.uma.es Wed Sep 20 08:39:36 2006 From: ots at ac.uma.es (Oswaldo Trelles) Date: Wed, 20 Sep 2006 10:39:36 +0200 Subject: [MOBY-dev] [moby] Example ofa response message with SOAP envelope References: <53133F95-7213-4D45-A46F-F4E476DF700D@gmail.com><1158600746.18578.1.camel@bioinfo.icapture.ubc.ca><5600CB27-1995-41DF-93DA-7F75346A0C7E@gmail.com><1158621658.19646.9.camel@bioinfo.icapture.ubc.ca><07D23959-3F71-4D87-945C-78266FF5B2B0@gmail.com><450FF5F6.3080607@ucalgary.ca><450FFAFC.3080301@ucalgary.ca><77B61AE4-98FB-4F74-9D24-75325920A891@gmail.com><1158683185.21783.74.camel@bioinfo.icapture.ubc.ca><0B6C87B0-2DC1-46B3-9D01-30230378071E@gmail.com> <1158684813.22263.2.camel@bioinfo.icapture.ubc.ca> Message-ID: <004401c6dc90$4f459780$346dd696@ac.uma.es> I agree with Mark in this is a programmer decision. In our case, the INB-client only accepts the input (and descendants) declared during service's registration. A similar situation arise when you ask for services able to manage a given object type. In this case the client recognise as valid object the registered type and its descendants O. ----- Original Message ----- From: "Mark Wilkinson" To: "Javier de la Torre" Cc: "Core developer announcements" Sent: Tuesday, September 19, 2006 6:53 PM Subject: Re: [MOBY-dev] [moby] Example ofa response message with SOAP envelope > Well, I don't know how other service providers do it, but I seldom > validate the incoming XML *at all*. I simply use an XPath query or > something like that to reach into the XML document to get the pieces > that I expect to be in there (based on whatever I registered as my input > data type). If they are not there, I throw an error. > > It is possible, of course, to query the ontology to make sure that what > you have received is a child of what you registered as consuming... but > that's a lot of overhead, and besides, what are you going to do if it > isn't a child? fail with an error :-) so I simply fail with an error > if I don't find what I want, and skip the expensive validation step > altogether. > > M > > > > > On Tue, 2006-09-19 at 18:34 +0200, Javier de la Torre wrote: > > Ups! > > > > And how does the services work? I mean, do they have to connect to > > the registry to check the relations of the objects they serve with > > what other people might be sending them? Or is it that they just take > > the string, in my case, and do something with it? If it is the second > > then a user, stupidly, could be sending an object to a service that > > is not necessarily inheritanced from the data type he understands and > > he will be using it. Of course there is nothing wrong to provide > > stupid answers to stupid questions, but, is it like this? > > > > The, can I just take the content from the in the income > > message and expect that it is actually a ScientificName? > > > > Thanks. > > > > Javier. > > > > > > On 19/09/2006, at 18:26, Mark Wilkinson wrote: > > > > > On Tue, 2006-09-19 at 18:22 +0200, Javier de la Torre wrote: > > >> information I need so I think I am safe because inside your > > >> MyScientificName there will still be a ScientificName. I dont mind > > >> where in the XML it is because XSLT will find it, hopefully! > > > > > > > > > Nope, not quite :-) ScientificName (as a tag name) will not be inside > > > of MyScientificName; however the *content* of MyScientificName will > > > include all of the same elements as the *content* of ScientificName > > > > > > MyScientificName to ScientificName is an inheritence relationship, > > > not a > > > container relationship > > > > > > M > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at lists.open-bio.org > > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > -- > Mark Wilkinson > Asst. Professor, Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics, iCAPTURE Centre > St. Paul's Hospital, Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "Since the point of a definition is to explain the meaning of a term to > someone who is unfamiliar with its proper application, the use of > language that doesn't help such a person learn how to apply the term is > pointless. Thus, "happiness is a warm puppy" may be a lovely thought, > but it is a lousy definition." > K?hler et al, 2006 > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From johan at ac.uma.es Thu Sep 21 09:28:58 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 21 Sep 2006 11:28:58 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 Message-ID: <45125B5A.1070402@ac.uma.es> For an updated version of the proposal for asynchronous services: http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf Changes: - Added missing parts to the XML examples (thanks Pieter) - Removed hasCallingDetail, now instead suggesting a new value for dc:format (thanks Martin). Because allowed value in dc:format comes from the MyGrid ontology we should coordinate with them to find exactly what value to put there. If there are no major issues left to discuss, could the RFC committee please call a vote on the proposal for October 1st? Kind regards, Johan -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From edward.kawas at gmail.com Thu Sep 21 20:42:41 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 21 Sep 2006 13:42:41 -0700 Subject: [MOBY-dev] Verifying data Message-ID: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> Hi, What are the opinions regarding the following situation: User A uses a service that, among other things, specifies that a float is returned. This service is then connected to a downstream service B. The service runs and returns the empty string instead of a float (all other items are filled in correctly). What should service B do? Should it fail since the empty string is not a float or should the service quietly ignore this. I am asking this because I just came across this using a service created using Perl MoSes. Thanks, Eddie From martin.senger at gmail.com Thu Sep 21 21:34:29 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 21 Sep 2006 22:34:29 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> Message-ID: <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> My 2c's: An empty output means no output. Which may not be an error but which definitely means that we have nothing to pass to a downstream service. Also a case when a service A returns an exception indicates that there is no much sense to call a downstream service B. My conclusion is therefore: Each service should check first that it gets an input (well, each services that expects an input, of course). If if does not, it should stop and again produce no output (potentially, adding its own exception to those already existing in the service notes). I can add this strict behaviour to Moses, or to Perl Moses. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 13:46:33 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 07:46:33 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> Message-ID: <4513E939.5010907@ucalgary.ca> I agree with Martin. My MobyServlet will throw an exception if the float is blank. The stricter we are, the better off MOBY-S is in the long run. Support for broken HTML tags since Netscape 1.0 still haunts the Web... > My 2c's: > > An empty output means no output. Which may not be an error but which > definitely means that we have nothing to pass to a downstream service. > > Also a case when a service A returns an exception indicates that there is no > much sense to call a downstream service B. > > My conclusion is therefore: Each service should check first that it gets an > input (well, each services that expects an input, of course). If if does > not, it should stop and again produce no output (potentially, adding its own > exception to those already existing in the service notes). > > I can add this strict behaviour to Moses, or to Perl Moses. > > Cheers, > Martin > > From martin.senger at gmail.com Fri Sep 22 16:45:53 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 17:45:53 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <45125B5A.1070402@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> Message-ID: <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> > If there are no major issues left to discuss, could the RFC committee > please call a vote on the proposal for October 1st? There is really no such thing as an RFC committee... But yes, I agree to have a vote - if the political issue (regardinr using a SOAP-specific technology) is considered to be solved. How is it, Mark? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Fri Sep 22 17:51:14 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 10:51:14 -0700 Subject: [MOBY-dev] [moby] Re: BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> References: <45125B5A.1070402@ac.uma.es> <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> Message-ID: <1158947474.5704.30.camel@bioinfo.icapture.ubc.ca> > There is really no such thing as an RFC committee... Well... there is a group of us who have agreed to be "the deciders" (to quote George Bush... I'll never do that again, I promise!) > But yes, I agree to > have a vote - if the political issue (regardinr using a SOAP-specific > technology) is considered to be solved. How is it, Mark? There was no significant discussion of this issue beyond the brief conversation that we had on the mailing list. My own opinion is that we have (possibly regrettably) already bought-in to the SOAP infrastructure, so using a SOAP-specific technology is a reasonable thing to do at this point. It does make it more difficult to change our minds later on, but I suspect that any mind-changing in the future is going to be on an much larger scale than just the transport protocol, so this small detail is not particularly relevant in that context. In my opinion, that discussion is resolved. Does anyone disagree? v.v. the Asynch proposal - let's call for the vote right now. All voting members please read the proposal carefully and submit your vote by October 1. M From martin.senger at gmail.com Fri Sep 22 16:45:53 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 17:45:53 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <45125B5A.1070402@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> Message-ID: <4d93f07c0609220945l2fadb6f5tc2bca1820f0f44ad@mail.gmail.com> > If there are no major issues left to discuss, could the RFC committee > please call a vote on the proposal for October 1st? There is really no such thing as an RFC committee... But yes, I agree to have a vote - if the political issue (regardinr using a SOAP-specific technology) is considered to be solved. How is it, Mark? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 21:11:27 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:11:27 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4513E939.5010907@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> Message-ID: <4514517F.5030105@ucalgary.ca> On another note, last month we talked about a "ping". Can we enshrine this in the API? The current service input doc: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/InputMessage.html implies you need at least one input. Anyone mind if a I add a little paragraph saying how a blank mobyContent must be replied with mobyData-less response? Or does someone object to enforcing this? Should we do an RFC intsead? I realize it might not be backward compatible for a few working services, but it'll be SO useful to get rid of all the dead links in clients...the RDF isAlive could be based on this... Paul Gordon wrote: > I agree with Martin. My MobyServlet will throw an exception if the > float is blank. The stricter we are, the better off MOBY-S is in the > long run. Support for broken HTML tags since Netscape 1.0 still haunts > the Web... > >> My 2c's: >> >> An empty output means no output. Which may not be an error but which >> definitely means that we have nothing to pass to a downstream service. >> >> Also a case when a service A returns an exception indicates that there is no >> much sense to call a downstream service B. >> >> My conclusion is therefore: Each service should check first that it gets an >> input (well, each services that expects an input, of course). If if does >> not, it should stop and again produce no output (potentially, adding its own >> exception to those already existing in the service notes). >> >> I can add this strict behaviour to Moses, or to Perl Moses. >> >> Cheers, >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From gordonp at ucalgary.ca Fri Sep 22 21:33:23 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:33:23 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <45125B5A.1070402@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> Message-ID: <451456A3.8010702@ucalgary.ca> Hi all, Sorry I'm getting into this discussion so late, but it would seem to me that it would be helpful to add a ResourceProperty that gives the client a hint as to how often they should check back for an answer. The server would have a much better idea of the appropriate interval than the client, no? If my client software generally checks every minute for async job responses, but the process always takes a day, that's a lot (1440) of useless polling requests. A bit like the Refresh header in HTTP... Cheers, Paul > For an updated version of the proposal for asynchronous services: > > http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf > > Changes: > - Added missing parts to the XML examples (thanks Pieter) > - Removed hasCallingDetail, now instead suggesting a new value for > dc:format (thanks Martin). Because allowed value in dc:format comes from > the MyGrid ontology we should coordinate with them to find exactly what > value to put there. > > If there are no major issues left to discuss, could the RFC committee > please call a vote on the proposal for October 1st? > > Kind regards, > Johan > > From martin.senger at gmail.com Fri Sep 22 21:49:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 22:49:36 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <4514517F.5030105@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> Message-ID: <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> > On another note, last month we talked about a "ping". Can we enshrine > this in the API? I considered this already agreed on :-) (Perl Moses services have it already, Java Moses will follow this week.) Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 21:50:54 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:50:54 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> Message-ID: <45145ABE.1050907@ucalgary.ca> So did I, but it's not in the API yet... :-) >> On another note, last month we talked about a "ping". Can we enshrine >> this in the API? >> > > > I considered this already agreed on :-) (Perl Moses services have it > already, Java Moses will follow this week.) > > Martin > > > From edward.kawas at gmail.com Fri Sep 22 21:22:11 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Fri, 22 Sep 2006 14:22:11 -0700 Subject: [MOBY-dev] Verifying data In-Reply-To: <4514517F.5030105@ucalgary.ca> Message-ID: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> I was thinking about this today. I would like to be able to retrieve this type of information via the API. Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon > Sent: Friday, September 22, 2006 2:11 PM > To: Core developer announcements > Subject: Re: [MOBY-dev] Verifying data > > On another note, last month we talked about a "ping". Can we > enshrine this in the API? The current service input doc: > > http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_ > API/InputMessage.html > > implies you need at least one input. Anyone mind if a I add > a little paragraph saying how a blank mobyContent must be > replied with mobyData-less response? Or does someone object > to enforcing this? > Should we do an RFC intsead? I realize it might not be > backward compatible for a few working services, but it'll be > SO useful to get rid of all the dead links in clients...the > RDF isAlive could be based on this... > > Paul Gordon wrote: > > I agree with Martin. My MobyServlet will throw an exception if the > > float is blank. The stricter we are, the better off MOBY-S > is in the > > long run. Support for broken HTML tags since Netscape 1.0 still > > haunts the Web... > > > >> My 2c's: > >> > >> An empty output means no output. Which may not be an error > but which > >> definitely means that we have nothing to pass to a > downstream service. > >> > >> Also a case when a service A returns an exception indicates that > >> there is no much sense to call a downstream service B. > >> > >> My conclusion is therefore: Each service should check > first that it > >> gets an input (well, each services that expects an input, > of course). > >> If if does not, it should stop and again produce no output > >> (potentially, adding its own exception to those already > existing in the service notes). > >> > >> I can add this strict behaviour to Moses, or to Perl Moses. > >> > >> Cheers, > >> Martin > >> > >> > >> > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Fri Sep 22 21:52:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 14:52:32 -0700 Subject: [MOBY-dev] [moby] Re: Verifying data In-Reply-To: <4514517F.5030105@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> Message-ID: <1158961952.6569.5.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-09-22 at 15:11 -0600, Paul Gordon wrote: > Or does someone object to enforcing this? > Should we do an RFC intsead? I realize it might not be backward > compatible for a few working services, but it'll be SO useful to get rid > of all the dead links in clients...the RDF isAlive could be based on this... You're likely right that it isn't backward-compatible... chances are that most services will not handle this situation *at all* and will need to be tweaked somehow... Do you know what services do at the moment if you hit them with no mobyData block? I agree, however, that it would be REALLY useful to have this functionality! M From markw at illuminae.com Fri Sep 22 21:56:42 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 14:56:42 -0700 Subject: [MOBY-dev] [moby] Re: Verifying data In-Reply-To: <45145ABE.1050907@ucalgary.ca> References: <00a601c6ddbe$7c5e2ff0$6400a8c0@notebook> <4d93f07c0609211434u7057aafdl3446e38633fe3826@mail.gmail.com> <4513E939.5010907@ucalgary.ca> <4514517F.5030105@ucalgary.ca> <4d93f07c0609221449y4da6adbamc6d507411f1df4fb@mail.gmail.com> <45145ABE.1050907@ucalgary.ca> Message-ID: <1158962202.6569.9.camel@bioinfo.icapture.ubc.ca> I'm pretty sure that there was ~unanimous support for the idea on the list. If you have time, please go ahead and add it to the documentation. M On Fri, 2006-09-22 at 15:50 -0600, Paul Gordon wrote: > So did I, but it's not in the API yet... :-) > >> On another note, last month we talked about a "ping". Can we enshrine > >> this in the API? > >> > > > > > > I considered this already agreed on :-) (Perl Moses services have it > > already, Java Moses will follow this week.) > > > > Martin > > > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From gordonp at ucalgary.ca Fri Sep 22 21:59:50 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 15:59:50 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> Message-ID: <45145CD6.7010506@ucalgary.ca> I think the ideal solution is to base the Service RDF's "isAlive" tag on whether the service pings or not. This won't "break" anything. If the person actively reads this list, they'll update their service. If they don't update their service, it works just as before, only isAlive=false. I can then turn isAlive filtering on or off in my client software according to my whim. If you're really hung up on semantics, we could add a isAPICompatible or something of the sort instead of usurping isAlive... > I was thinking about this today. I would like to be able to retrieve this type > of information via the API. > > Eddie > > >> -----Original Message----- >> From: moby-dev-bounces at lists.open-bio.org >> [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Paul Gordon >> Sent: Friday, September 22, 2006 2:11 PM >> To: Core developer announcements >> Subject: Re: [MOBY-dev] Verifying data >> >> On another note, last month we talked about a "ping". Can we >> enshrine this in the API? The current service input doc: >> >> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_ >> API/InputMessage.html >> >> implies you need at least one input. Anyone mind if a I add >> a little paragraph saying how a blank mobyContent must be >> replied with mobyData-less response? Or does someone object >> to enforcing this? >> Should we do an RFC intsead? I realize it might not be >> backward compatible for a few working services, but it'll be >> SO useful to get rid of all the dead links in clients...the >> RDF isAlive could be based on this... >> >> Paul Gordon wrote: >> >>> I agree with Martin. My MobyServlet will throw an exception if the >>> float is blank. The stricter we are, the better off MOBY-S >>> >> is in the >> >>> long run. Support for broken HTML tags since Netscape 1.0 still >>> haunts the Web... >>> >>> >>>> My 2c's: >>>> >>>> An empty output means no output. Which may not be an error >>>> >> but which >> >>>> definitely means that we have nothing to pass to a >>>> >> downstream service. >> >>>> Also a case when a service A returns an exception indicates that >>>> there is no much sense to call a downstream service B. >>>> >>>> My conclusion is therefore: Each service should check >>>> >> first that it >> >>>> gets an input (well, each services that expects an input, >>>> >> of course). >> >>>> If if does not, it should stop and again produce no output >>>> (potentially, adding its own exception to those already >>>> >> existing in the service notes). >> >>>> I can add this strict behaviour to Moses, or to Perl Moses. >>>> >>>> Cheers, >>>> Martin >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> MOBY-dev mailing list >>> MOBY-dev at lists.open-bio.org >>> http://lists.open-bio.org/mailman/listinfo/moby-dev >>> >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > From martin.senger at gmail.com Fri Sep 22 22:00:54 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 23:00:54 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> References: <4514517F.5030105@ucalgary.ca> <008101c6de8d$2c5a2ca0$6400a8c0@notebook> Message-ID: <4d93f07c0609221500l55363c6eqfc766d66d15821a9@mail.gmail.com> > I was thinking about this today. I would like to be able to retrieve this > type > of information via the API. Do not make things complicated... 1) Ping: Send an empty mobyContent and get back the same. 2) Service that does not have any input (e.g. HelloWorld service): Send an empty mobyData and get back whatever service produces. (Of course, one can send several empty mobyData within a single network request.) 3) Otherwise there should be a non-empty mobyData. If it is not, there is something wrong with the input (possibly caused by an upstream service) - so this service should no nothing, and return again an empty mobyData (and - I think - it should propagate the exceptions in service notes, possibly adding its own exception). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Fri Sep 22 22:11:14 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 23:11:14 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <45145CD6.7010506@ucalgary.ca> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> Message-ID: <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> I prefer an empty mobyContent (for a ping). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 22:13:57 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 16:13:57 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> Message-ID: <45146025.9080509@ucalgary.ca> Versus what? Did anyone suggest anything else? > I prefer an empty mobyContent (for a ping). > > Martin > > From martin.senger at gmail.com Fri Sep 22 22:18:38 2006 From: martin.senger at gmail.com (Martin Senger) Date: Fri, 22 Sep 2006 23:18:38 +0100 Subject: [MOBY-dev] Verifying data In-Reply-To: <45146025.9080509@ucalgary.ca> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> <45146025.9080509@ucalgary.ca> Message-ID: <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> > Versus what? Did anyone suggest anything else? I understood that you suggested to use a new XML tag isAlive... M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Fri Sep 22 22:26:17 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Fri, 22 Sep 2006 16:26:17 -0600 Subject: [MOBY-dev] Verifying data In-Reply-To: <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> <45146025.9080509@ucalgary.ca> <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> Message-ID: <45146309.8040504@ucalgary.ca> Ah, no. I was talking about the isAlive tag found in each service description in the service instance RDF http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances If this was based on the ping, I wouldn't have to send out 600 pings myself every time... In any case, the API doc is now up to date in CVS, it will take a while to propagate to the Web site... >> Versus what? Did anyone suggest anything else? >> > > > I understood that you suggested to use a new XML tag isAlive... > M. > > > > From markw at illuminae.com Fri Sep 22 23:30:59 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 22 Sep 2006 16:30:59 -0700 Subject: [MOBY-dev] [moby] Re: Verifying data In-Reply-To: <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> References: <008101c6de8d$2c5a2ca0$6400a8c0@notebook> <45145CD6.7010506@ucalgary.ca> <4d93f07c0609221511t1ad74cc8ta415c0575224c1a4@mail.gmail.com> <45146025.9080509@ucalgary.ca> <4d93f07c0609221518p35752234wb7bca6556fe5d18d@mail.gmail.com> Message-ID: <1158967859.7688.2.camel@bioinfo.icapture.ubc.ca> I think Paul was referring to the isAlive tag in the LSID metadata. M On Fri, 2006-09-22 at 23:18 +0100, Martin Senger wrote: > > Versus what? Did anyone suggest anything else? > > > I understood that you suggested to use a new XML tag isAlive... > M. > > > -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From johan at ac.uma.es Mon Sep 25 10:25:36 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Mon, 25 Sep 2006 12:25:36 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <451456A3.8010702@ucalgary.ca> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> Message-ID: <4517AEA0.5070507@ac.uma.es> Hi Paul, Well, it depends on the particular service? So, any such property must be optional. a) For a service that returns a "Percent progress" or similar event, a client could "guess" when to do the next polling (would not be totally accurate, of course, but still). Here the service would basically do the same "intelligent" guessing that the client would do and create this property. b) For a service that returns a "Heartbeat" or similar event, a client cannot guess when it is appropriate to do the next polling (since not even the service knows when it will finish). Here, no property could be created. Not sure if it is necessary with a new property. If a service wants to help the client to do such "prediction", the service can already use LSAE event blocks when it returns status to "communicate" with the client; step progress event and percent progress? Comments from others? Kind regards, Johan Paul Gordon wrote: > Hi all, > > Sorry I'm getting into this discussion so late, but it would seem to me > that it would be helpful to add a ResourceProperty that gives the client > a hint as to how often they should check back for an answer. The server > would have a much better idea of the appropriate interval than the > client, no? If my client software generally checks every minute for > async job responses, but the process always takes a day, that's a lot > (1440) of useless polling requests. A bit like the Refresh header in > HTTP... > > Cheers, > > Paul > >> For an updated version of the proposal for asynchronous services: >> >> http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf >> >> Changes: >> - Added missing parts to the XML examples (thanks Pieter) >> - Removed hasCallingDetail, now instead suggesting a new value for >> dc:format (thanks Martin). Because allowed value in dc:format comes from >> the MyGrid ontology we should coordinate with them to find exactly what >> value to put there. >> >> If there are no major issues left to discuss, could the RFC committee >> please call a vote on the proposal for October 1st? >> >> Kind regards, >> Johan >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From gordonp at ucalgary.ca Mon Sep 25 15:00:18 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 25 Sep 2006 09:00:18 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517AEA0.5070507@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> Message-ID: <4517EF02.10507@ucalgary.ca> Yeah, I'd looked at the LSAE events, but was surprised to see that there wasn't anything about refresh rates in it. I guess the only mechanism available to us in the current framework is your suggestion (a) to extrapolate based on the % done so far? An oversight on the OMG group's part I think... > Hi Paul, > > Well, it depends on the particular service? So, any such property must > be optional. > > a) For a service that returns a "Percent progress" or similar event, a > client could "guess" when to do the next polling (would not be totally > accurate, of course, but still). Here the service would basically do the > same "intelligent" guessing that the client would do and create this > property. > b) For a service that returns a "Heartbeat" or similar event, a client > cannot guess when it is appropriate to do the next polling (since not > even the service knows when it will finish). Here, no property could be > created. > > Not sure if it is necessary with a new property. If a service wants to > help the client to do such "prediction", the service can already use > LSAE event blocks when it returns status to "communicate" with the > client; step progress event and percent progress? > > Comments from others? > > Kind regards, > Johan > > Paul Gordon wrote: > >> Hi all, >> >> Sorry I'm getting into this discussion so late, but it would seem to me >> that it would be helpful to add a ResourceProperty that gives the client >> a hint as to how often they should check back for an answer. The server >> would have a much better idea of the appropriate interval than the >> client, no? If my client software generally checks every minute for >> async job responses, but the process always takes a day, that's a lot >> (1440) of useless polling requests. A bit like the Refresh header in >> HTTP... >> >> Cheers, >> >> Paul >> >> >>> For an updated version of the proposal for asynchronous services: >>> >>> http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf >>> >>> Changes: >>> - Added missing parts to the XML examples (thanks Pieter) >>> - Removed hasCallingDetail, now instead suggesting a new value for >>> dc:format (thanks Martin). Because allowed value in dc:format comes from >>> the MyGrid ontology we should coordinate with them to find exactly what >>> value to put there. >>> >>> If there are no major issues left to discuss, could the RFC committee >>> please call a vote on the proposal for October 1st? >>> >>> Kind regards, >>> Johan >>> >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> > > From martin.senger at gmail.com Mon Sep 25 15:38:26 2006 From: martin.senger at gmail.com (Martin Senger) Date: Mon, 25 Sep 2006 16:38:26 +0100 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517EF02.10507@ucalgary.ca> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> <4517EF02.10507@ucalgary.ca> Message-ID: <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> Paul, > Yeah, I'd looked at the LSAE events, but was surprised to see that there > wasn't anything about refresh rates in it. And why should it? If you need a special event that can deliver an information about a refresh rate, you can extend an existing event. An oversight on the OMG group's part I think... No oversight here, just this was not the primary purpose (and I should know because what you call an "OMG group" was actually me :-)). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From gordonp at ucalgary.ca Mon Sep 25 15:00:18 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 25 Sep 2006 09:00:18 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517AEA0.5070507@ac.uma.es> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> Message-ID: <4517EF02.10507@ucalgary.ca> Yeah, I'd looked at the LSAE events, but was surprised to see that there wasn't anything about refresh rates in it. I guess the only mechanism available to us in the current framework is your suggestion (a) to extrapolate based on the % done so far? An oversight on the OMG group's part I think... > Hi Paul, > > Well, it depends on the particular service? So, any such property must > be optional. > > a) For a service that returns a "Percent progress" or similar event, a > client could "guess" when to do the next polling (would not be totally > accurate, of course, but still). Here the service would basically do the > same "intelligent" guessing that the client would do and create this > property. > b) For a service that returns a "Heartbeat" or similar event, a client > cannot guess when it is appropriate to do the next polling (since not > even the service knows when it will finish). Here, no property could be > created. > > Not sure if it is necessary with a new property. If a service wants to > help the client to do such "prediction", the service can already use > LSAE event blocks when it returns status to "communicate" with the > client; step progress event and percent progress? > > Comments from others? > > Kind regards, > Johan > > Paul Gordon wrote: > >> Hi all, >> >> Sorry I'm getting into this discussion so late, but it would seem to me >> that it would be helpful to add a ResourceProperty that gives the client >> a hint as to how often they should check back for an answer. The server >> would have a much better idea of the appropriate interval than the >> client, no? If my client software generally checks every minute for >> async job responses, but the process always takes a day, that's a lot >> (1440) of useless polling requests. A bit like the Refresh header in >> HTTP... >> >> Cheers, >> >> Paul >> >> >>> For an updated version of the proposal for asynchronous services: >>> >>> http://twiki.inab.org/twiki/pub/INB/INBDocsRoot/BioMOBY_Asynchronous_Service_Call_Proposal_WSRF_v2.3.pdf >>> >>> Changes: >>> - Added missing parts to the XML examples (thanks Pieter) >>> - Removed hasCallingDetail, now instead suggesting a new value for >>> dc:format (thanks Martin). Because allowed value in dc:format comes from >>> the MyGrid ontology we should coordinate with them to find exactly what >>> value to put there. >>> >>> If there are no major issues left to discuss, could the RFC committee >>> please call a vote on the proposal for October 1st? >>> >>> Kind regards, >>> Johan >>> >>> >>> >>> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at lists.open-bio.org >> http://lists.open-bio.org/mailman/listinfo/moby-dev >> >> >> > > From gordonp at ucalgary.ca Mon Sep 25 16:11:37 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 25 Sep 2006 10:11:37 -0600 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> <4517EF02.10507@ucalgary.ca> <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> Message-ID: <4517FFB9.3090202@ucalgary.ca> Hi Martin, Extending is never a technical problem, only a social problem. I can add a new tag easily, but unless most people use it, it isn't too useful. That's why I was suggesting that MOBY-S define (or at least strongly suggests) some common name for this...whether we put it in the LSAE events or WSRF is inconsequential to me. Regards, Paul > Paul, > > >> Yeah, I'd looked at the LSAE events, but was surprised to see that there >> wasn't anything about refresh rates in it. >> > > > And why should it? If you need a special event that can deliver an > information about a refresh rate, you can extend an existing event. > > An oversight on the OMG group's part I think... > > > No oversight here, just this was not the primary purpose (and I should know > because what you call an "OMG group" was actually me :-)). > > Martin > No disrespect intended :-) From johan at ac.uma.es Tue Sep 26 09:02:09 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Tue, 26 Sep 2006 11:02:09 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.3 In-Reply-To: <4517FFB9.3090202@ucalgary.ca> References: <45125B5A.1070402@ac.uma.es> <451456A3.8010702@ucalgary.ca> <4517AEA0.5070507@ac.uma.es> <4517EF02.10507@ucalgary.ca> <4d93f07c0609250838nbae6736i897a64b138ba1915@mail.gmail.com> <4517FFB9.3090202@ucalgary.ca> Message-ID: <4518EC91.8020407@ac.uma.es> One simple way for a service to indicate the next "recommended" time for a client to poll for status is to use the time progress event from LSAE (already defined in LSAE and included in the proposal, so a client should be able to understand it). Quoting from the Life Sciences Analysis Engine specification at http://www.omg.org/cgi-bin/doc?dtc/2005-04-01 --------------- Time progress event Time progress event indicates the estimated number of seconds before the job is completed. There is no requirement that the estimated completion time decreases. An example: This is a TIME PROGRESS analysis event. --------------- In that example, the service estimates that it will take 324 seconds until it completes the analysis, so a client could use that information to decide the next poll-time? Kind regards, Johan Paul Gordon wrote: > Hi Martin, > > Extending is never a technical problem, only a social problem. I can > add a new tag easily, but unless most people use it, it isn't too > useful. That's why I was suggesting that MOBY-S define (or at least > strongly suggests) some common name for this...whether we put it in the > LSAE events or WSRF is inconsequential to me. > > Regards, > > Paul > >> Paul, >> >> >> >>> Yeah, I'd looked at the LSAE events, but was surprised to see that there >>> wasn't anything about refresh rates in it. >>> >>> >> And why should it? If you need a special event that can deliver an >> information about a refresh rate, you can extend an existing event. >> >> An oversight on the OMG group's part I think... >> >> >> No oversight here, just this was not the primary purpose (and I should know >> because what you call an "OMG group" was actually me :-)). >> >> Martin >> >> > No disrespect intended :-) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387 From martin.senger at gmail.com Wed Sep 27 09:40:20 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 10:40:20 +0100 Subject: [MOBY-dev] Paging mechanism Message-ID: <4d93f07c0609270240g67bccb10y99e20ba518ff3cc1@mail.gmail.com> Javier wrote: What I am more interested now is on another topic. If you remeber > Mark we discussed more than one year ago the need for a paging > mechanism for our services in BioMOBY. Now that I am implementing > this I took Martin Singer approach to include this functionality on > the service: the services always have a two parameters: maxPages and > startPage that are used for paging... I am interested, as well. I used two secondary parameters because it was an immediate solution. But we should think about it now in the same way as we did with asynchronous invocation, meaning to put this information in an envelope (BioMoby or SOAP) - as Javier already proposed. Could anybody more familar with these envelopes suggest where to put it please? Actually, make a real RFC for it... Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From d.haase at gsf.de Wed Sep 27 13:01:45 2006 From: d.haase at gsf.de (Dirk Haase) Date: Wed, 27 Sep 2006 15:01:45 +0200 Subject: [MOBY-dev] RDF deregistration Message-ID: <200609271501.46324.d.haase@gsf.de> Eddie, is it possible that the deregistration of services by removing it from an RDF document does not work currently? I deleted the section for a service called getGeneticElementNamesByFreeText from http://mips.gsf.de/proj/planet/moby/RDF/all_mips_services.rdf and called the agent but it's not removed from MOBY central yet. Best, dirk From jatorre at gmail.com Wed Sep 27 09:54:39 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Wed, 27 Sep 2006 11:54:39 +0200 Subject: [MOBY-dev] Paging mechanism In-Reply-To: <4d93f07c0609270240g67bccb10y99e20ba518ff3cc1@mail.gmail.com> References: <4d93f07c0609270240g67bccb10y99e20ba518ff3cc1@mail.gmail.com> Message-ID: Hi Martin, Would be nice. For the time being I have created a new service type under Retrieval called TapirProvider and I will register all my services with this service type. All of them will support he paging mechanism. I think we need a better name for this than TapirProvider, but couldnt think of anything better. Here is the description for this Service Type: ---- TAPIR providers are normally biological collection databases. The most common operation is to retrieve data from them to be used in analysis. They always implement two secondary inputs, a start and next parameter to do paging. Please read http://trac.pywrapper.org/pywrapper/wiki/BioMOBYSupport --- At least if you are constructing a client to query all these services that support paging you know hot to get to them. If you dont mind I have changed the parameter names to start and next so that it fits with the TAPIR specifications. Javier. On 9/27/06, Martin Senger wrote: > Javier wrote: > > > > What I am more interested now is on another topic. If you remeber > > Mark we discussed more than one year ago the need for a paging > > mechanism for our services in BioMOBY. Now that I am implementing > > this I took Martin Singer approach to include this functionality on > > the service: the services always have a two parameters: maxPages and > > startPage that are used for paging... > > I am interested, as well. I used two secondary parameters because it was an > immediate solution. But we should think about it now in the same way as we > did with asynchronous invocation, meaning to put this information in an > envelope (BioMoby or SOAP) - as Javier already proposed. Could anybody more > familar with these envelopes suggest where to put it please? Actually, make > a real RFC for it... > > Thanks, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger From Pieter.Neerincx at wur.nl Wed Sep 27 15:15:33 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 27 Sep 2006 17:15:33 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: <44FED787.5010002@ac.uma.es> References: <44FED787.5010002@ac.uma.es> Message-ID: Hi Johan et al., Thanks for the updated proposal and sorry for the late response. I've been very busy and also wanted to think this over for a while... On 6-Sep-2006, at 4:13 PM, Johan Karlsson wrote: > Pieter, > > Thank you for a well written letter (and sorry for the delay in > answering). >> There is only one thing that I don't like about the current proposal: >> the location of queryID. For our current synchronous services it's an >> attribute of the mobyData element. In the current async services >> proposal the queryID jumps around the XML taking several identities: >> * in status_queryID01 it >> is part of raw text. >> * in > lsae:status_queryID01> it is part of an element name in the lsae >> namespace. >> (By the way: Should this element really be in the lsae namespace? I >> don't think our status_queryIDxx elements are part of the LSAE >> specs...) >> > True, we need to put a better namespace, moby? moby would be fine I guess... >> It would be >> much more convenient if the result from a asynchronous service >> invocation would contain both the ServiceInvocationID *AND* the >> associated queryIDs. In that case I only have to parse the service >> response to create GetResourceProperty requests. Therefore I propose >> to supply the queryIDs as wsa:ReferenceParameters just like the >> ServiceInvocationID. >> > I am not sure that I understand the problem completely... The clients > must internally store, somehow, the connection between the input > (identified by the queryID) and the output? The jobs could, > potentially, > take a very long time to finish and without knowing the input, getting > the output would not be so interesting. Not necessarily. Somehow you have to keep track of what conditions were used in an experiment, so you know how you got to the results and you make sure you can reproduce it. Either the client stores the inputs and parameters used for service execution and combines it with the results or the service output contains all the information about how the results were produced. This can be a combination of echoing inputs back and/or providing provisioning blocks and/or service notes to create an "e-labjournal". In the latter case you can forget about the XML of the original service invocation and you only need the output. Both approaches work, but in the latter case you keep the information about an experiment together and hence you can not "lose" the experimental conditions. > Anyway, it is not so complicated > to handle the queryIDs for the client (see some of the example code of > the client at the prototype page). Maybe it is another situation that > you are describing than the one in the example? Can you give some > examples where it would be necessary to return the queryIDs? Again, > not > sure if I understand. > > http://bioinfo.pcm.uam.es/prototype/ I'm sure it's not "rocket science" to store the queryIDs on the client, but it's simply not necessary. IMHO it's easier to return the queryIDs to the client as compared to storing them on the client. That's all. > >> 2. >> WSRF contains an *optional* method to request a resource properties >> document. With this method a client can figure out which resource >> properties are available and hence what it can request. Although this >> method is optional and the current proposal doesn't mention it, I >> think it would good to keep the option open to supply such a method. >> WSRF does not put any limitations on how a service generates and >> provides such a document, so you can generate it dynamically or it >> can be a static thing. If we would want to supply such a resource >> properties document in the future it would be the easiest if it can >> be a static one. However in the current proposal the queryIDs are >> part of the resource properties (status_queryIDxx and >> result_queryIDxx). This means that the available resource properties >> depend on the amount of queries/jobs that were sent to a service and >> hence we can not use a static resource properties document. It would >> be more convenient if we can strip the queryIDs from the resource >> properties and provide them as wsa:ReferenceParameters. In that case >> there are only two resource properties (status and result) and we can >> describe those in a static resource properties document. > > At least until now, we have tried to only include exactly what is > needed > and avoid many, potentially, useful but maybe more complicated WSRF > methods. I totally agree and I'm happy you have chosen such an approach. I'm not arguing to add the GetResourcePropertyDocument method right now, but I feel it would be good to keep the option open to do so in the future. If the queryIDs are moved to the SOAP header as ReferenceParameters it is much easier to add such functionality later, because the ResourceProperties are static and hence the ResourcePropertiesDocument can be static. With the current proposal the ResourceProperties are dynamic and a service provider would have to generate ResourcePropertiesDocuments dynamically for each service incocation. Again this won't be "rocket science", but I think it's unnecessary overhead. > Yes, the WSRF method GetResourcePropertyDocument could be useful > but it > is possible to manage without it since the clients would always be > able > to construct the property qnames as long as they keep track of the > queryIDs. But of course, if there is a great demand for this optional > WSRF-method we could add it to the documentation. > >> Therefore I propose a translocation of BioMOBY queryIDs from the >> resource properties to wsa:ReferenceParameters. As far as I >> understand, with all the specifications involved this would be legal, >> but please correct me if I am wrong. Below I included some examples >> of what the XML might look like when the queryIDs are moved to the >> SOAP header as wsa:ReferenceParameters. Let me know what you >> think.... > The problem (?) is that the EPR is supposed to be opaque, or in > particular, the ReferenceParameter () > should be > "assumed to be opaque" for the clients. > > "Reference parameters are also provided by the issuer of the endpoint > reference and are otherwise assumed to be opaque to consuming > applications." > > (quoting from the WS-Addressing standard that WSRF builds upon) > > At least my interpretation of this is that clients are not supposed to > understand or parse or manipulate the reference-parameter but instead > just echo it back (if I am confused please correct me)? I think you are right, but in that case I think moving the queryIDs to the EPR is more opaque than the current proposal. The EPR from the SOAP header together with ResourceProperties contains the information required for retrieving status or results. In the current proposal the client can echo back the EPR, but it still has to create the ResourceProperties *dynamically*. If the queryIDs move to the EPR and are returned by a service on invocation, the client can echo back the EPR (containing both the batch ID and the job IDs) and only needs to append one *static* ResourceProperty (either the one to get the status or the one to get the results). Hence the client doesn't have to create anything dynamically, requires less logic and you will only request one resource property at a time, so we even would not need the GetMultipleResourceProperties method anymore. (I assume it doesn't make sense to request the status and the results at the same time.) If a client wants to manipulate the the EPR by stripping out some queryIDs to retrieve a ResourceProperty only for a subset of queryIDs, they *can* do that. This doesn't make life more complex for the service and as far as I understand the specs it is legal. It should not be required to manipulate the EPR and it isn't. If clients lack the logic to request resources for a specific queryID from a batch-job, they can always echo back the whole EPR as ReferenceParameter and get the resource for all the queryIDs of the batch. So moving the queryIDs to the EPR requires less logic on the client side and therefore I think it is a more elegant solution. > Yes, the > reference-parameter can be given as XML but this XML should not be > modified by the clients (I assume that you mean that the clients > should > just include the tags that they need to find status or > results for particular jobs in the batch-call). The issuer of the > endpoint reference naturally must handle the EPR but the clients > should > not try to understand the EPR. > > Also, conceptually, the EPR refers to a specific resource (in this > case > what we call "batch-call", many jobs). If we manipulate the EPR we > "change" its original reference. We tried to clearly define in the > proposal what the EPR refered to (what the "resource" was). > Manipulating > the EPR in some way confuses what it refers to. I disagree. If the queryIDs move to the EPR, the EPR will simply consist of multiple parts. It remains clear what the EPR refers to. The EPR as a whole remains a reference to a specific service invocation. It's perfectly normal according to the specs to have multiple ReferenceParameters in an EPR, so I fail to see how this will be confusing.... > > ------------------- > > Regarding "dynamic" property names (status_{queryID}); the official > WSRF > specification mandates that all properties of a resource MUST be > described by a XML Schema but this is not strictly enforced in the > library we used for the Perl examples (WSRF::Lite) (or at least, in > the > examples of WSRF::Lite that I have seen there is no such XML schema > file) . > > Just to give an example to give an idea of what I am talking about > (non > BioMOBY...): > > > > > > > > > > > > > > > > maxOccurs="unbounded" /> > > > > > This resource has four properties (tns:NumberOfBlocks, tns:BlockSize, > tns:Manufacturer and finally tns:StorageCapability). The qnames of > these > four properties are pre-defined/fixed and not like what we need > "status_q1", "status_q2" etc etc. > > We would need that the resource properties schema allows open content > (using a xsd:any element). This means that the list of valid qnames > for > the resource properties is "open". See "3.3.1.1 Establishing a List of > Valid Resource Properties" in "WSRF Application Notes" > (http://docs.oasis-open.org/wsrf/wsrf-application_notes-1.2-cd-02.pdf) > for more information. I understand it is possible to use a schema that allows open content, but it's not necessary. So why make life more complicated? With kind regards, Pieter > > Kind regards, > Johan Karlsson > > -- > Johan Karlsson > Instituto Nacional de Bioinform?tica (INB) > Integrated Bioinformatics Node (GNV-5) > Dpto. de Arquitectura de Computadores > Campus Universitario de Teatinos, despacho 2.3.9a > 29071 M?laga (Spain) > +34 95 213 3387 > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From edward.kawas at gmail.com Wed Sep 27 14:38:26 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 27 Sep 2006 07:38:26 -0700 Subject: [MOBY-dev] RDF deregistration In-Reply-To: <200609271501.46324.d.haase@gsf.de> Message-ID: <002401c6e242$996cc880$6400a8c0@notebook> Hi Dirk, So the agent, right now, is configured to only remove services when it is called by registerService with only the signatureURL portion of the message filled in. When the agent runs off the cron, it is configured only to update services and not to remove them. This was done as a preventative measure, but I don't think that it is still necessary to do this. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > Sent: Wednesday, September 27, 2006 6:02 AM > To: 'Core developer announcements' > Subject: [MOBY-dev] RDF deregistration > > Eddie, > > is it possible that the deregistration of services by > removing it from an RDF document does not work currently? I > deleted the section for a service called > getGeneticElementNamesByFreeText from > http://mips.gsf.de/proj/planet/moby/RDF/all_mips_services.rdf > and called the agent but it's not removed from MOBY central yet. > > Best, > dirk > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed Sep 27 16:29:54 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:29:54 -0700 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <002401c6e242$996cc880$6400a8c0@notebook> References: <002401c6e242$996cc880$6400a8c0@notebook> Message-ID: <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> I guess before we switch on that last bit of functionality we should ask if anyone has noticed anything unusual in the Agent behaviour that they haven't said anything about on the list. I've been using it for my own services for the past couple of weeks, and it seems to be well-behaved so far, but if anyone has noticed anything nasty, now is the time to say so! Cheers all! M On Wed, 2006-09-27 at 07:38 -0700, Edward Kawas wrote: > Hi Dirk, > > So the agent, right now, is configured to only remove services when it is called > by registerService with only the signatureURL portion of the message filled in. > When the agent runs off the cron, it is configured only to update services and > not to remove them. This was done as a preventative measure, but I don't think > that it is still necessary to do this. > > Thanks, > > Eddie > > > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Dirk Haase > > Sent: Wednesday, September 27, 2006 6:02 AM > > To: 'Core developer announcements' > > Subject: [MOBY-dev] RDF deregistration > > > > Eddie, > > > > is it possible that the deregistration of services by > > removing it from an RDF document does not work currently? I > > deleted the section for a service called > > getGeneticElementNamesByFreeText from > > http://mips.gsf.de/proj/planet/moby/RDF/all_mips_services.rdf > > and called the agent but it's not removed from MOBY central yet. > > > > Best, > > dirk > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Sep 27 16:33:53 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:33:53 -0700 Subject: [MOBY-dev] [spam] Re: BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: References: <44FED787.5010002@ac.uma.es> Message-ID: <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-09-27 at 17:15 +0200, Pieter Neerincx wrote: > > you are describing than the one in the example? Can you give some > > examples where it would be necessary to return the queryIDs? Again, > > not > > sure if I understand It's a part of the API: The queryID has no intrinsic meaning Enumeration of mobyData elements is achieved by the queryID attribute of the mobyData element, whose value has no intrinsic meaning. The client program should choose it be any legal XML attribute value, such that it is unique to each mobyData in the message. Service providers should not attempt to interpret the value of queryID; it is simply an identifier. The service provider must assign the same queryID to the associated mobyData element in their response message (described below). This allows the client program to match each query with its corresponding response. The articleName attribute of the Simple and/or Collection elements is optional (it may or may not be there, and if there, it may or may not have a non-null value), and is used to invoke services that have named arguments; a single queryInput may contain multiple Simple and/or Collection articles that need to be differentiated by name. (from http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY- S_API/InputMessage.html) M From markw at illuminae.com Wed Sep 27 16:41:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:41:02 -0700 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> Message-ID: <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> The agent de-registering services that have been removed from an RDF document since it's last visit. M On Wed, 2006-09-27 at 17:37 +0100, Martin Senger wrote: > Mark, > > I guess before we switch on that last bit of functionality > > What bit of functionality, please? > > Martin > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From markw at illuminae.com Wed Sep 27 16:45:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:45:48 -0700 Subject: [MOBY-dev] [moby] Re: [spam] Re: BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: <4d93f07c0609270941icd21a87j75bff0e7926ecc8d@mail.gmail.com> References: <44FED787.5010002@ac.uma.es> <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270941icd21a87j75bff0e7926ecc8d@mail.gmail.com> Message-ID: <1159375548.27141.51.camel@bioinfo.icapture.ubc.ca> Correct, this is now mandatory. Gbrowse_moby is forgiving when it receives output data from non- compliant services, but is API-compliant by always sending an articleName when it passes data to a service (regardless of whether or not that service checks it). Newer versions of Taverna are *not* forgiving at all - both input and output must have articleNames. I don't know about other clients... M On Wed, 2006-09-27 at 17:41 +0100, Martin Senger wrote: > > The articleName attribute of the Simple and/or Collection > elements is > optional (it may or may not be there, and if there, it may or > may not > have a non-null value), > > I remember that this was the case at the beginning - but now it is > mandatory. (Even though many services and clients are still forgiving > about it.) Am I right? > > Martin > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From martin.senger at gmail.com Wed Sep 27 16:41:00 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:41:00 +0100 Subject: [MOBY-dev] [spam] Re: BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> References: <44FED787.5010002@ac.uma.es> <1159374833.27141.41.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0609270941icd21a87j75bff0e7926ecc8d@mail.gmail.com> > The articleName attribute of the Simple and/or Collection elements is > optional (it may or may not be there, and if there, it may or may not > have a non-null value), I remember that this was the case at the beginning - but now it is mandatory. (Even though many services and clients are still forgiving about it.) Am I right? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From markw at illuminae.com Wed Sep 27 16:48:30 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 27 Sep 2006 09:48:30 -0700 Subject: [MOBY-dev] [personal] Re: [moby] Re: RDF deregistration In-Reply-To: <4d93f07c0609270944kb959b6ep41f2d159a76eef7a@mail.gmail.com> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270944kb959b6ep41f2d159a76eef7a@mail.gmail.com> Message-ID: <1159375710.27141.55.camel@bioinfo.icapture.ubc.ca> I don't know if it is the "main" part, but it was one of the three primary functions - register, edit, deregister - that the agent can accomplish. Call it being overly cautious :-) If there were a bug in the agent that we hadn't noticed during testing, we didn't want to wipe-out the registry (though it is backed-up daily, so we could recover anyway). It looks like there are no obvious bugs... M On Wed, 2006-09-27 at 17:44 +0100, Martin Senger wrote: > > The agent de-registering services that have been removed from > an RDF > document since it's last visit. > > Mark, I thought that this was the *main* part of the agent > functionality. Why else we should have an agent (except some automatic > cleaning perhaps)? > > I am again a bit surprise (which is quite normal, when there is a talk > about our mysterious agent :-)). > > Martin > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger -- Mark Wilkinson Asst. Professor, Dept. of Medical Genetics University of British Columbia PI in Bioinformatics, iCAPTURE Centre St. Paul's Hospital, Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "Since the point of a definition is to explain the meaning of a term to someone who is unfamiliar with its proper application, the use of language that doesn't help such a person learn how to apply the term is pointless. Thus, "happiness is a warm puppy" may be a lovely thought, but it is a lousy definition." K?hler et al, 2006 From martin.senger at gmail.com Wed Sep 27 16:44:04 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:44:04 +0100 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> <1159375262.27141.43.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0609270944kb959b6ep41f2d159a76eef7a@mail.gmail.com> > The agent de-registering services that have been removed from an RDF > document since it's last visit. Mark, I thought that this was the *main* part of the agent functionality. Why else we should have an agent (except some automatic cleaning perhaps)? I am again a bit surprise (which is quite normal, when there is a talk about our mysterious agent :-)). Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Wed Sep 27 16:37:14 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:37:14 +0100 Subject: [MOBY-dev] [moby] Re: RDF deregistration In-Reply-To: <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> References: <002401c6e242$996cc880$6400a8c0@notebook> <1159374594.27141.38.camel@bioinfo.icapture.ubc.ca> Message-ID: <4d93f07c0609270937u542a7b93pcbd9d24ca2e6e340@mail.gmail.com> Mark, I guess before we switch on that last bit of functionality What bit of functionality, please? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Wed Sep 27 16:35:43 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 27 Sep 2006 17:35:43 +0100 Subject: [MOBY-dev] RDF deregistration In-Reply-To: <002401c6e242$996cc880$6400a8c0@notebook> References: <200609271501.46324.d.haase@gsf.de> <002401c6e242$996cc880$6400a8c0@notebook> Message-ID: <4d93f07c0609270935o2916f00dsb739e263658e4f5c@mail.gmail.com> Eddie, So the agent, right now, is configured to only remove services when it is > called > by registerService with only the signatureURL portion of the message > filled in. > When the agent runs off the cron, it is configured only to update services > and > not to remove them. What are you talking about please? Why a cron job matters how the agent behaves. The agent is a part of BioMoby API so it should behave consistenly and accordingly the documentation. But perhaps I am again missing something... Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Thu Sep 28 12:02:36 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 13:02:36 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> Message-ID: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Mark, Eddie, I think there is a bug (also) in Central in XML escaping. Javier found that he was not able to register a service with a URL containing ampersand. I replied: it may be that the dashboard does not properly escape it in the registration > request > and, indeed, it is true. Today, I have fixed it in Dashboard (actually in CentralImpl.java) but found that it seems to be a double-error. Also the Central does not properly escape XML characters. This is my registration request: mobyHelloBiomobyWorld_TMP_4Testing samples.jmoby.net http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=no martin.senger at gmail.com1 Object (you may noticed that the URL has now a properly escaped ampersand). The service was registered successfully - but when I asked for it (findService) I got back this: Testing 1 moby martin.senger at gmail.com http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=no Object (you may notice that here the URL has wrongly an un-escaped ampersand). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From martin.senger at gmail.com Thu Sep 28 14:58:08 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 15:58:08 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Message-ID: <4d93f07c0609280758n49cf3fd0o3325420126b4f33b@mail.gmail.com> > Ah! It also has a default url for the moby registry that does not > exist anymore, so updating this could also be nice. Who has the wrong default? Dashboard? It does not (as far as I see it), dashboard uses: URL: http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.p URI: http://mobycentral.icapture.ubc.ca/MOBY/Central Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From edward.kawas at gmail.com Thu Sep 28 15:19:59 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 28 Sep 2006 08:19:59 -0700 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Message-ID: <002b01c6e311$91b78330$6400a8c0@notebook> Hi Martin, Just my thoughts on this, but because this is text content of an xml element, should central really be escaping ampersands? My question, I guess, is should this be the job of the client or the registry? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Thursday, September 28, 2006 5:03 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Registering a MOBY service > > Mark, Eddie, > I think there is a bug (also) in Central in XML escaping. > > Javier found that he was not able to register a service > with a URL containing ampersand. I replied: > > it may be that the dashboard does not properly escape it in > the registration > > request > > > > and, indeed, it is true. Today, I have fixed it in Dashboard > (actually in > CentralImpl.java) but found that it seems to be a > double-error. Also the Central does not properly escape XML > characters. > > This is my registration request: > > mobyHelloBi > omobyWorld_TMP_4Testing e> > samples.jmoby.net > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > mobyWorld?abc=def&yes=no > martin.senger at gmail.com1 you can unregister this service anytime...]]> > > Object > > > > > > > > > (you may noticed that the URL has now a properly escaped > ampersand). The service was registered successfully - but > when I asked for it (findService) I got back this: > > > serviceName='HelloBiomobyWorld_TMP_4' lsid='urn:lsid: > biomoby.org:serviceinstance:samples.jmoby.net > ,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > Testing< > /serviceType> > 1 > moby > service anytime...]]> > martin.senger at gmail.com > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > mobyWorld?abc=def&yes=no > > > > Object bjectType> > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped > ampersand). > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev From martin.senger at gmail.com Thu Sep 28 15:32:28 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 16:32:28 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <002b01c6e311$91b78330$6400a8c0@notebook> References: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> <002b01c6e311$91b78330$6400a8c0@notebook> Message-ID: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> Eddie, Just my thoughts on this, but because this is text content of an xml > element, > should central really be escaping ampersands? My question, I guess, is > should > this be the job of the client or the registry? One of us does not understand the point :-) The client sends properly escaped XML. Registry stores it. Later a client asks "find the service". Registry retrieves it from the database, converts it into XML and sends it back. But it converts it wrongly - it should conform with the XML spec - which it does not. Cheers, Martin Thanks, > > Eddie > > > -----Original Message----- > > From: moby-dev-bounces at lists.open-bio.org > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > > Martin Senger > > Sent: Thursday, September 28, 2006 5:03 AM > > To: Core developer announcements > > Subject: Re: [MOBY-dev] Registering a MOBY service > > > > Mark, Eddie, > > I think there is a bug (also) in Central in XML escaping. > > > > Javier found that he was not able to register a service > > with a URL containing ampersand. I replied: > > > > it may be that the dashboard does not properly escape it in > > the registration > > > request > > > > > > > and, indeed, it is true. Today, I have fixed it in Dashboard > > (actually in > > CentralImpl.java) but found that it seems to be a > > double-error. Also the Central does not properly escape XML > > characters. > > > > This is my registration request: > > > > mobyHelloBi > > omobyWorld_TMP_4Testing > e> > > samples.jmoby.net > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > mobyWorld?abc=def&yes=no > > martin.senger at gmail.com horitativeService>1 > you can unregister this service anytime...]]> > > > > Object > > > > > > > > > > > > > > > > > > (you may noticed that the URL has now a properly escaped > > ampersand). The service was registered successfully - but > > when I asked for it (findService) I got back this: > > > > > > > serviceName='HelloBiomobyWorld_TMP_4' lsid='urn:lsid: > > biomoby.org:serviceinstance:samples.jmoby.net > > ,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > > Testing< > > /serviceType> > > 1 > > moby > > > service anytime...]]> > > martin.senger at gmail.com > > > > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > mobyWorld?abc=def&yes=no > > > > > > > > Object > bjectType> > > > > > > > > > > > > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped > > ampersand). > > > > Cheers, > > Martin > > > > > > -- > > Martin Senger > > email: martin.senger at gmail.com > > skype: martinsenger > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > > -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Thu Sep 28 14:53:00 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Thu, 28 Sep 2006 16:53:00 +0200 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> Message-ID: Good to know that. PyBiomoby also suffer from this bug. I will provide a fix for that when I am ready, apart of this, the interaction with the registry using PyBiomoby is really nice. Ah! It also has a default url for the moby registry that does not exist anymore, so updating this could also be nice. Javier. On 9/28/06, Martin Senger wrote: > Mark, Eddie, > I think there is a bug (also) in Central in XML escaping. > > Javier found that he was not able to register a service with a URL > containing ampersand. I replied: > > > > > > > > it may be that the dashboard does not properly escape it in the > registration request > > and, indeed, it is true. Today, I have fixed it in Dashboard (actually in > CentralImpl.java) but found that it seems to be a double-error. Also the > Central does not properly escape XML characters. > > This is my registration request: > > mobyHelloBiomobyWorld_TMP_4Testing > samples.jmoby.net > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=nomartin.senger at gmail.com1 you can unregister this service > anytime...]]> > > Object > > > > > > > > > (you may noticed that the URL has now a properly escaped ampersand). The > service was registered successfully - but when I asked for it (findService) > I got back this: > > > serviceName='HelloBiomobyWorld_TMP_4' > lsid='urn:lsid:biomoby.org:serviceinstance:samples.jmoby.net,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > lsid='urn:lsid:biomoby.org:servicetype:Testing:2006-02-25T12-49-15Z'>Testing > 1 > moby > anytime...]]> > martin.senger at gmail.com > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBiomobyWorld?abc=def&yes=no > > > > lsid='urn:lsid:biomoby.org:objectclass:Object:2001-09-21T16-00-00Z'>Object > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped ampersand). > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger From jatorre at gmail.com Thu Sep 28 15:04:48 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Thu, 28 Sep 2006 17:04:48 +0200 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280758n49cf3fd0o3325420126b4f33b@mail.gmail.com> References: <81C71324-1836-4970-9A8A-D6E8F44A16F4@gmail.com> <4d93f07c0609160501x79c4c423hf80e6a2a16bfa269@mail.gmail.com> <4d93f07c0609280502o77dc417s672ede71bcefb4a6@mail.gmail.com> <4d93f07c0609280758n49cf3fd0o3325420126b4f33b@mail.gmail.com> Message-ID: No, no. It is PyBiomoby. It uses URL: http://mobycentral.cbr.nrc.ca/cgi-bin/MOBY05/mobycentral.pl URI: http://mobycentral.cbr.nrc.ca/MOBY/Central As you can see here: http://cvs.open-bio.org/cgi-bin/viewcvs/viewcvs.cgi/moby-live/Python/bioMoby/mobyClient.py?rev=1.6&cvsroot=biomoby&content-type=text/vnd.viewcvs-markup Javier. On 9/28/06, Martin Senger wrote: > > > > Ah! It also has a default url for the moby registry that does not > > exist anymore, so updating this could also be nice. > > Who has the wrong default? Dashboard? It does not (as far as I see it), > dashboard uses: > > URL: > http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.p > URI: http://mobycentral.icapture.ubc.ca/MOBY/Central > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger From edward.kawas at gmail.com Thu Sep 28 16:59:36 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 28 Sep 2006 09:59:36 -0700 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> Message-ID: <004201c6e31f$7c6ac060$6400a8c0@notebook> Okay, I have noticed something else: If I try to register a service in dashboard where I escape the &, dashboard does the following: Given-> &, dashboard shows the raw XML as-> &amp; Anyways, if I register a service with &, a find service (using a perl client) returns &. If I register a service with a &, a find service returns the & What am I missing? Is the problem that dashboard escapes the & in both cases and central doesn't? Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at lists.open-bio.org > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > Martin Senger > Sent: Thursday, September 28, 2006 8:32 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Registering a MOBY service > > Eddie, > > Just my thoughts on this, but because this is text content of an xml > > element, > > should central really be escaping ampersands? My question, > I guess, is > > should this be the job of the client or the registry? > > > One of us does not understand the point :-) > > The client sends properly escaped XML. Registry stores it. > Later a client > asks "find the service". Registry retrieves it from the > database, converts > it into XML and sends it back. But it converts it wrongly - it should > conform with the XML spec - which it does not. > > Cheers, > Martin > > > Thanks, > > > > Eddie > > > > > -----Original Message----- > > > From: moby-dev-bounces at lists.open-bio.org > > > [mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of > > > Martin Senger > > > Sent: Thursday, September 28, 2006 5:03 AM > > > To: Core developer announcements > > > Subject: Re: [MOBY-dev] Registering a MOBY service > > > > > > Mark, Eddie, > > > I think there is a bug (also) in Central in XML escaping. > > > > > > Javier found that he was not able to register a service > > > with a URL containing ampersand. I replied: > > > > > > it may be that the dashboard does not properly escape it in > > > the registration > > > > request > > > > > > > > > > and, indeed, it is true. Today, I have fixed it in Dashboard > > > (actually in > > > CentralImpl.java) but found that it seems to be a > > > double-error. Also the Central does not properly escape XML > > > characters. > > > > > > This is my registration request: > > > > > > mobyHelloBi > > > omobyWorld_TMP_4Testing > > e> > > > samples.jmoby.net > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > > mobyWorld?abc=def&yes=no > > > martin.senger at gmail.com > horitativeService>1 > > you can unregister this service anytime...]]> > > > > > > Object > > > > > > > > > > > > > > > > > > > > > > > > > > > (you may noticed that the URL has now a properly escaped > > > ampersand). The service was registered successfully - but > > > when I asked for it (findService) I got back this: > > > > > > > > > > > serviceName='HelloBiomobyWorld_TMP_4' lsid='urn:lsid: > > > biomoby.org:serviceinstance:samples.jmoby.net > > > ,HelloBiomobyWorld_TMP_4:2006-09-28T11-52-07Z'> > > > Testing< > > > /serviceType> > > > 1 > > > moby > > > > > service anytime...]]> > > > martin.senger at gmail.com > > > > > > > > > http://mobycentral.icapture.ubc.ca:8090/axis/services/HelloBio > > > mobyWorld?abc=def&yes=no > > > > > > > > > > > > Object > > bjectType> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (you may notice that here the URL has wrongly an un-escaped > > > ampersand). > > > > > > Cheers, > > > Martin > > > > > > > > > -- > > > Martin Senger > > > email: martin.senger at gmail.com > > > skype: martinsenger > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at lists.open-bio.org > > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at lists.open-bio.org > > http://lists.open-bio.org/mailman/listinfo/moby-dev > > > > > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: findservicetest.pl_EDDIE Type: application/octet-stream Size: 1537 bytes Desc: not available URL: From martin.senger at gmail.com Thu Sep 28 17:43:52 2006 From: martin.senger at gmail.com (Martin Senger) Date: Thu, 28 Sep 2006 18:43:52 +0100 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <004201c6e31f$7c6ac060$6400a8c0@notebook> References: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> <004201c6e31f$7c6ac060$6400a8c0@notebook> Message-ID: <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> > If I try to register a service in dashboard where I escape the & You are not supposed to escape anything. Whatever you put in the text field with the sevice URL, will be delivered, properly escaped, to the registry. So if you want to have an ampersand in the URL, you put there just ampersand. If you - from whatever reasons - want to have a strange UYL that contains something like: http://what.com/strange?yes&dear you put it there and it is again delivers properly to the registry (btw, as: http://what.com/strange?yes&amp;dear which is correct). > Anyways, if I register a service with &, a find service (using a perl > client) > returns & But it should not. It should return a valid XML string - and a string with a un-escaped ampersand is not a valid XML string. The rgistry should return & instead. What am I missing? Perhaps someone else can enter this discussion and try to explain it better than I do. (Unless, of course, I am missing something). Or skype me... (user name 'thesengers'). But the problem is important to be solved soon. I would say, it is utgent. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger From jatorre at gmail.com Thu Sep 28 17:56:57 2006 From: jatorre at gmail.com (Javier de la Torre) Date: Thu, 28 Sep 2006 19:56:57 +0200 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> References: <4d93f07c0609280832p4bfc245dvea8372fa6005cd0f@mail.gmail.com> <004201c6e31f$7c6ac060$6400a8c0@notebook> <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> Message-ID: Hi Martin, Well if I can help a bit... Martin is right and I think what you exposed is clear. Ampersand are not allowed within xml documents and must be scaped. So when a client comunicates with the moby registry if somehwere inside the message there is an ampersand it will have to be scaped. And pyBiomoby does it correctly by the way (I was wrong in my last email). My service got registered correctly, and I suppose is correctly inside the biomoby registry database. But then when I connect to the registry, let say with dashboard and try to retrieve the list of services, the registry takes the data from its database (there is a database behind right?) and produces and XML with the services registered. This XML is wrong, it does not scape the ampersand and therefore is a wrong xml document/message. When dashboard tries to open, the parser complains because it finds a non-valid xml document and refuse to open it. The conslussion. Because there is an ampersand in a service end point in the registry right now registered, every message that includes this service with the end point produces an invalid XML document. Why is this urgent? Every user that dowloads, for example, dashboard, and try to browse the registry will not be able to do it because dashboard see that the messages coming from the registry are malformed. So, although is not dashboard issue, dashboard has become unusuable because the registry is producing malformed xml. Hope this helps. Javier. On 9/28/06, Martin Senger wrote: > > If I try to register a service in dashboard where I escape the & > > > You are not supposed to escape anything. Whatever you put in the text field > with the sevice URL, will be delivered, properly escaped, to the registry. > So if you want to have an ampersand in the URL, you put there just > ampersand. If you - from whatever reasons - want to have a strange UYL that > contains something like: > > http://what.com/strange?yes&dear > > you put it there and it is again delivers properly to the registry (btw, as: > > http://what.com/strange?yes&amp;dear > > which is correct). > > > > Anyways, if I register a service with &, a find service (using a perl > > client) > > returns & > > > But it should not. It should return a valid XML string - and a string with a > un-escaped ampersand is not a valid XML string. The rgistry should return > & instead. > > > What am I missing? > > > Perhaps someone else can enter this discussion and try to explain it better > than I do. (Unless, of course, I am missing something). Or skype me... (user > name 'thesengers'). > > But the problem is important to be solved soon. I would say, it is utgent. > > Cheers, > Martin > > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/moby-dev > From edward.kawas at gmail.com Thu Sep 28 17:58:42 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 28 Sep 2006 10:58:42 -0700 Subject: [MOBY-dev] Registering a MOBY service In-Reply-To: <4d93f07c0609281043n516d4c15p9f90550b6621ccaa@mail.gmail.com> Message-ID: <004c01c6e327$be01b350$6400a8c0@notebook> > > Anyways, if I register a service with &, a find service > (using a perl > > client) > > returns & > > > But it should not. It should return a valid XML string - and > a string with a un-escaped ampersand is not a valid XML > string. The rgistry should return & instead. Okay, I see the problem now. I will attempt to fix it! Thanks, Eddie From johan at ac.uma.es Fri Sep 29 16:12:55 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Fri, 29 Sep 2006 18:12:55 +0200 Subject: [MOBY-dev] BioMOBY Asynchronous Service Call Proposal v2.2/3 - The location of queryIDs In-Reply-To: References: <44FED787.5010002@ac.uma.es> Message-ID: <451D4607.1090602@ac.uma.es> Hi Pieter, Thank you for your help and suggestions. From what we can understand, no new functionality would be possible by moving the position of the queryIDs. Really, it is just a question of where to put the information, the same information is sent in both cases. We would like to keep the proposal as it is and to have a standard that provides a much needed functionality in BioMOBY. > Not necessarily. Somehow you have to keep track of what conditions > were used in an experiment, so you know how you got to the results > and you make sure you can reproduce it. Either the client stores the > inputs and parameters used for service execution and combines it with > the results or the service output contains all the information about > how the results were produced. This can be a combination of echoing > inputs back and/or providing provisioning blocks and/or service notes > to create an "e-labjournal". In the latter case you can forget about > the XML of the original service invocation and you only need the > output. Both approaches work, but in the latter case you keep the > information about an experiment together and hence you can not "lose" > the experimental conditions. > Well, an "e-labjournal" is a nice idea but it is outside of the scope of this proposal. Of course, it is not necessary that the service saves the input (async services would temporarily keep the results depending on the policies of the service provider) because the client could keep track of the input, results, provisioning blocks and service notes. >> Anyway, it is not so complicated >> to handle the queryIDs for the client (see some of the example code of >> the client at the prototype page). Maybe it is another situation that >> you are describing than the one in the example? Can you give some >> examples where it would be necessary to return the queryIDs? Again, >> not >> sure if I understand. >> >> http://bioinfo.pcm.uam.es/prototype/ >> > > I'm sure it's not "rocket science" to store the queryIDs on the > client, but it's simply not necessary. IMHO it's easier to return the > queryIDs to the client as compared to storing them on the client. > That's all. > As you say, it is simply a difference of approach. Following either approach, it is possible to ask for status and results for jobs. We have chosen one way that is implemented in the Perl libraries and (hopefully) well specified in the proposal. > I'm not arguing to add the GetResourcePropertyDocument method right > now, but I feel it would be good to keep the option open to do so in > the future. Nothing stops this from being added in the future with the current proposal. > If the queryIDs move to the EPR and are returned by a service on > invocation, the client can echo back the EPR (containing both the > batch ID and the job IDs) and only needs to append one *static* > ResourceProperty (either the one to get the status or the one to get > the results). Hence the client doesn't have to create anything > dynamically, requires less logic and you will only request one > resource property at a time, so we even would not need the > GetMultipleResourceProperties method anymore. (I assume it doesn't > make sense to request the status and the results at the same time.) > Well, no, it would not make much sense for the same job(s). There is nothing that stops a client from doing it, though (but asking for not existing properties (results) would return an WSRF error, of course). However, some clients could want to request (in the same message) status for one job "q1" (property status_q1) and the result for another job "q2" (property result_q2). This is probably not a very common situation but a client could choose to only ask for only status/result properties or for a mix. > If a client wants to manipulate the the EPR by stripping out some > queryIDs to retrieve a ResourceProperty only for a subset of > queryIDs, they *can* do that. This doesn't make life more complex for > the service and as far as I understand the specs it is legal. It > should not be required to manipulate the EPR and it isn't. If clients > lack the logic to request resources for a specific queryID from a > batch-job, they can always echo back the whole EPR as > ReferenceParameter and get the resource for all the queryIDs of the > batch. So moving the queryIDs to the EPR requires less logic on the > client side and therefore I think it is a more elegant solution. Well, such clients (that lack logic to edit the EPR) would (potentially) waste bandwidth or be very limited. If a client can only ask for the results of all jobs and the first job is finished after 5 minutes and the second job is finished after 10 hours, this client would not be very useful (either you have to wait 10 hours to get the result of the 5-minute job or you retrieve the result of the 5-minute job twice). In summary, we think that it is not necessary to change the proposal, it can do what is needed and we have a working implementation. Anyway, thank you for your suggestions. Kind regards, Johan -- Johan Karlsson Instituto Nacional de Bioinform?tica (INB) Integrated Bioinformatics Node (GNV-5) Dpto. de Arquitectura de Computadores Campus Universitario de Teatinos, despacho 2.3.9a 29071 M?laga (Spain) +34 95 213 3387