From rroyo at lsi.upc.edu Tue Jan 3 05:01:26 2006 From: rroyo at lsi.upc.edu (rroyo@lsi.upc.edu) Date: Tue, 3 Jan 2006 11:01:26 +0100 (MET) Subject: [MOBY-dev] freefluo-xscufl with collections, upgrading to taverna 1.2, 1.3 Message-ID: <2833313544rroyo@lsi.upc.es> Hello, We need to execute taverna workflows from the command line. We've tried to use freefluo, but we had some trouble.. Although it was possible to launch most of our simple workflows, some of them, which take advantage of features from Taverna 1.2 ( collections ), gave error or simply returned void results. Is there a way to improve freefluo to match the capabilities of Taverna 1.2, or even further? Or does anyone know any other way to execute Taverna workflows from the commandline? Thank you very much! Alexis & Romina, INB From duncan.hull at cs.man.ac.uk Thu Jan 5 10:48:01 2006 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Thu, 05 Jan 2006 15:48:01 +0000 Subject: [MOBY-dev] freefluo-xscufl with collections, executing Taverna workflows from the command line In-Reply-To: <2833313544rroyo@lsi.upc.es> References: <2833313544rroyo@lsi.upc.es> Message-ID: <43BD3FB1.3040702@cs.man.ac.uk> Alexis and Romina This sort of question stands a better chance of being answered on the taverna-hackers mailing list...so I've cc'ed it to that list. Duncan rroyo at lsi.upc.edu wrote: >Hello, > >We need to execute taverna workflows from the command line. We've tried >to use freefluo, but we had some trouble.. >Although it was possible to launch most of our simple workflows, some of >them, which take advantage of features from Taverna 1.2 ( collections ), >gave error or simply returned void results. > >Is there a way to improve freefluo to match the capabilities of Taverna >1.2, or even further? > >Or does anyone know any other way to execute Taverna workflows from the >commandline? > >Thank you very much! > >Alexis & Romina, INB > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > > -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From tmo at ebi.ac.uk Thu Jan 5 10:59:13 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu, 05 Jan 2006 15:59:13 +0000 Subject: [MOBY-dev] [Taverna-hackers] Re: freefluo-xscufl with collections, executing Taverna workflows from the command line In-Reply-To: <43BD3FB1.3040702@cs.man.ac.uk> References: <2833313544rroyo@lsi.upc.es> <43BD3FB1.3040702@cs.man.ac.uk> Message-ID: <43BD4251.2030503@ebi.ac.uk> Duncan Hull wrote: > Alexis and Romina > > This sort of question stands a better chance of being answered on the > taverna-hackers mailing list...so I've cc'ed it to that list. And in fact it _was_ answered in those lists ;) I think it's safe to stop cross posting between moby and taverna lists, the appropriate people are on both. Tom From markw at illuminae.com Tue Jan 10 11:57:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 10 Jan 2006 08:57:10 -0800 Subject: [MOBY-dev] RFC #1914 - change & call for vote Message-ID: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> In response to requests from myGrid: mygrid:hasServiceType -> removed because it is redundant to dc:format dc:format -> changed from string literal to ontology term. For MOBY the value has changed from 'moby' to 'BioMoby_service' mygrid:hasOperationNameText -> added as a property of mygrid:operation. String Literal describing the service name. For MOBY services, this is identical to the mygrid:hasServiceNameText since MOBY services can only have one operation. I have made the above changes to the document online. Can we call for a vote on RFC 1913 and 1914 by Monday 16th? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Wed Jan 11 10:12:09 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 11 Jan 2006 16:12:09 +0100 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: <31AB896A0E7ED211BFBE0008C7283D13DE706C@inibapnt1.inibap.org> References: <31AB896A0E7ED211BFBE0008C7283D13DE706C@inibapnt1.inibap.org> Message-ID: Hi, Hi all, I was wondering if Mathieu's question about the secondaries was already answered? I can not find the answer in my mail archive and am currently running into the same problem. Furthermore: How do I use secondaries in Taverna? Is there documented example somewhere? I couldn't find one. I also looked at the WSDL produced for several services and do see input and output listed, but not the optional secondaries... The MOBY-S API documentation on the new site is a bit limited. I can guess what min, max and default are for, but how do I use enum? Do I simply list all the allowed values? That could become a rather lengthy list for some of my secondaries :). Cheers, Pi On 21-Oct-2005, at 8:09 PM, Rouard, Mathieu (INIBAP - Montpellier) wrote: > Hello, > > I am looking for some guidelines about the xml tags allowed in > secondary > articles. > Until now, I have found those tags in the documentation > > datatype > default > max > min > enum > > Is there a tag allowing to describe the paramater? > I think it would be helpful when the parameter name (or the value > expected) > is clear for the end user of the service. > -- snip -- > > Thanks for your help. > > Cheers, > Mathieu > > -- > Mathieu Rouard > IPGRI-INIBAP < www.inibap.org > > Parc Scientifique Agropolis II > 34397 Montpellier - Cedex 5 - France > Tel: +33 (0)467 61 13 02 > Fax: +33 (0)467 61 03 34 > > > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l 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 Jan 11 10:18:48 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 11 Jan 2006 07:18:48 -0800 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: Message-ID: <000301c616c2$53497f70$6500a8c0@notebook> Hi Pieter, Currently, Taverna does not support secondary parameters. I do plan on adding support at a later date. If you have any thoughts about how secondarys should be added to Taverna (UI), please don't hesitate to let me know so that I can consider your input during the design. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx > Sent: Wednesday, January 11, 2006 7:12 AM > To: mobydev > Subject: Re: [MOBY-dev] [MOBY-l] Tags for secondary articles > > Hi, > Hi all, > > I was wondering if Mathieu's question about the secondaries > was already answered? I can not find the answer in my mail > archive and am currently running into the same problem. > Furthermore: How do I use secondaries in Taverna? Is there > documented example somewhere? I couldn't find one. I also > looked at the WSDL produced for several services and do see > input and output listed, but not the optional secondaries... > The MOBY-S API documentation on the new site is a bit > limited. I can guess what min, max and default are for, but > how do I use enum? Do I simply list all the allowed values? > That could become a rather lengthy list for some of my secondaries :). > > Cheers, > > Pi > > On 21-Oct-2005, at 8:09 PM, Rouard, Mathieu (INIBAP - Montpellier) > wrote: > > > Hello, > > > > I am looking for some guidelines about the xml tags allowed in > > secondary articles. > > Until now, I have found those tags in the documentation > > > > datatype > > default > > max > > min > > enum > > > > Is there a tag allowing to describe the paramater? > > I think it would be helpful when the parameter name (or the value > > expected) > > is clear for the end user of the service. > > > -- snip -- > > > > Thanks for your help. > > > > Cheers, > > Mathieu > > > > -- > > Mathieu Rouard > > IPGRI-INIBAP < www.inibap.org > > > Parc Scientifique Agropolis II > > 34397 Montpellier - Cedex 5 - France > > Tel: +33 (0)467 61 13 02 > > Fax: +33 (0)467 61 03 34 > > > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > > Wageningen University and Research centre (WUR) Laboratory of > Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed Jan 11 11:12:04 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 11 Jan 2006 08:12:04 -0800 Subject: [MOBY-dev] RFC #1914 - change & call for vote In-Reply-To: <43C4E45E.8010005@gmail.com> References: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> <43C4E45E.8010005@gmail.com> Message-ID: <43C52E54.702@illuminae.com> Hi Martin, You're right, I should have been more explicit. There were some last minute changes to the RDF model (one predicate removed, one added, and one given a range-change) for a Service Instance that were required to allow it to be reasoned-over by the myGrid registry. I detailed what those changes were in the previous message. The changes had no "semantic" consequence to us v.v. what we are intending to describe with the Service Instance RDF. This is the RDF that is retrieved by the getMetaData call on an LSID representing a service instance, and hence these changes affected the relevant RFC. v.v. your suggested changes, I think I addressed most of them in the version of the RFC that I announced; if you recall, I gave you a preview of the proposals, and you commented on that preview, so I made those modifications before making the public RFC announcement. v.v. what is returned by a getData call on an LSID? This is currently still an open issue. The RFC describes (and is titled) how to retrieve metadata about MOBY entities. What is returned by a getData call can be addressed in another RFC(s) if anyone can think of a useful behaviour in the case of object, namespace, servicetype, and serviceinstance LSID's (collectively or respectively). Since there is no requirement in the LSID specification that an LSID *must* resolve with a getData call, we are not out-of-compliance with the specification by not addressing this right now. My initial thoughts were that, for Object LSID's, we would return the XML Schema of the object, however that turns out to be impossible. I had also thought that we could return the WSDL for a service from a getData call on a Service Instance LSID, however you rejected that idea as being redundant. Since that time, I've had no other ideas, and no other suggestions have been raised, so... it's an open question., but a question that does not prevent us from carrying on with this RFC vote. I will delay the vote until the following Monday (23rd), since I suspect that many people didn't spend their Christmas holidays reading the RFC documents ;-) In the meantime, let's have some debate about this, since it forms the basis for the long-fabled RDF agent registration/deregistration system that is written, but we haven't switched on yet because the RDF itself is still in flux. M Martin Senger wrote: > Mark, > I am sorry that I m dumb but your message is completely cryptic, > and I have no clue what you are suggesting. Could you be please more > verbose? I apologize if i am the only one who do not understand. > >> Can we call for a vote on RFC 1913 and 1914 by Monday 16th? >> > I think that the deadline for (any) voting should be set more then > five days ahead. I know that your RFCs were posted long time ago, but > I have not get any answer from you for my first comments (especially > the one about what getData() method should/could return). > > With regards, > Martin > From senger at ebi.ac.uk Wed Jan 11 11:37:23 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 11 Jan 2006 16:37:23 +0000 (GMT) Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: <000301c616c2$53497f70$6500a8c0@notebook> Message-ID: > If you have any thoughts about how secondarys should be added to Taverna > (UI), please don't hesitate to let me know so that I can consider your input > during the design. > Eddie, I did not want to be pre-mature with my suggestion because it is not yet fully implemented. But this email is an opportunity: I have created a user interface for entering quite complex moby data type (it is a combination of a table and a tree). I plan to use it in Dashboard. But doing that I relized that it would be also very suitable for taverna (perhaps even without a need to have all moby data types listed there in a scavenger list). I still need to finish it - two things are mising: the sceondary parameters - but it's simple, and the ability to add and remove more HAS members. I have already solution for both these things on my laptop but I will not be able to finish and to commit it before next two weeks time (having my family visiting me at Philippines). Please take a look for the so-far commit status by calling a testing client: build/run/run-any-client CreateMobyInput -h build/run/run-any-client CreateMobyInput -data \ -cachedir In Taverna, the -cachedit functionality will be replced by reading the RDf document with moby data types (as it is now). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Jan 11 11:39:35 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 11 Jan 2006 08:39:35 -0800 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: Message-ID: <000401c616cd$9c1eaa80$6500a8c0@notebook> Thanks Martin, I will look at it soon. Eddie > -----Original Message----- > From: Martin Senger [mailto:senger at ebi.ac.uk] > Sent: Wednesday, January 11, 2006 8:37 AM > To: Edward Kawas > Cc: 'Core developer announcements' > Subject: Re: [MOBY-dev] [MOBY-l] Tags for secondary articles > > > If you have any thoughts about how secondarys should be added to > > Taverna (UI), please don't hesitate to let me know so that I can > > consider your input during the design. > > > Eddie, I did not want to be pre-mature with my suggestion > because it is not yet fully implemented. But this email is an > opportunity: I have created a user interface for entering > quite complex moby data type (it is a combination of a table > and a tree). I plan to use it in Dashboard. But doing that I > relized that it would be also very suitable for taverna > (perhaps even without a need to have all moby data types > listed there in a scavenger list). I still need to finish it > - two things are mising: the sceondary parameters - but it's > simple, and the ability to add and remove more HAS members. I > have already solution for both these things on my laptop but > I will not be able to finish and to commit it before next two > weeks time (having my family visiting me at Philippines). > Please take a look for the so-far commit status by calling a > testing client: > > build/run/run-any-client CreateMobyInput -h > build/run/run-any-client CreateMobyInput -data \ > -cachedir > > In Taverna, the -cachedit functionality will be replced by > reading the RDf document with moby data types (as it is now). > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > From martin.senger at gmail.com Wed Jan 11 05:56:30 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 11 Jan 2006 18:56:30 +0800 Subject: [MOBY-dev] RFC #1914 - change & call for vote In-Reply-To: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> References: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> Message-ID: <43C4E45E.8010005@gmail.com> Mark, I am sorry that I m dumb but your message is completely cryptic, and I have no clue what you are suggesting. Could you be please more verbose? I apologize if i am the only one who do not understand. > Can we call for a vote on RFC 1913 and 1914 by Monday 16th? > I think that the deadline for (any) voting should be set more then five days ahead. I know that your RFCs were posted long time ago, but I have not get any answer from you for my first comments (especially the one about what getData() method should/could return). With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Thu Jan 12 05:31:40 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 12 Jan 2006 11:31:40 +0100 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: <000301c616c2$53497f70$6500a8c0@notebook> References: <000301c616c2$53497f70$6500a8c0@notebook> Message-ID: <2B1A8814-6493-4245-9273-E8F6466D8845@wur.nl> Hi Eddie, Thanks for the - as ususal - quick feedback! Support for secondary articles would be welcome :). For the implementation I think secondaries could be treated similar to primary inputs. To me secondaries are simply optional inputs without has or hasa relationships. I'm not sure wether it can also be implemented that simple though ... Cheers, Pi On 11Jan2006, at 16:18, Edward Kawas wrote: > Hi Pieter, > > Currently, Taverna does not support secondary parameters. I do plan on > adding support at a later date. > > If you have any thoughts about how secondarys should be added to > Taverna > (UI), please don't hesitate to let me know so that I can consider > your input > during the design. > > Thanks, > > Eddie > >> -----Original Message----- >> From: moby-dev-bounces at biomoby.org >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx >> Sent: Wednesday, January 11, 2006 7:12 AM >> To: mobydev >> Subject: Re: [MOBY-dev] [MOBY-l] Tags for secondary articles >> >> Hi, >> Hi all, >> >> I was wondering if Mathieu's question about the secondaries >> was already answered? I can not find the answer in my mail >> archive and am currently running into the same problem. >> Furthermore: How do I use secondaries in Taverna? Is there >> documented example somewhere? I couldn't find one. I also >> looked at the WSDL produced for several services and do see >> input and output listed, but not the optional secondaries... >> The MOBY-S API documentation on the new site is a bit >> limited. I can guess what min, max and default are for, but >> how do I use enum? Do I simply list all the allowed values? >> That could become a rather lengthy list for some of my >> secondaries :). >> >> Cheers, >> >> Pi >> >> On 21-Oct-2005, at 8:09 PM, Rouard, Mathieu (INIBAP - Montpellier) >> wrote: >> >>> Hello, >>> >>> I am looking for some guidelines about the xml tags allowed in >>> secondary articles. >>> Until now, I have found those tags in the documentation >>> >>> datatype >>> default >>> max >>> min >>> enum >>> >>> Is there a tag allowing to describe the paramater? >>> I think it would be helpful when the parameter name (or the value >>> expected) >>> is clear for the end user of the service. >>> >> -- snip -- >>> >>> Thanks for your help. >>> >>> Cheers, >>> Mathieu >>> >>> -- >>> Mathieu Rouard >>> IPGRI-INIBAP < www.inibap.org > >>> Parc Scientifique Agropolis II >>> 34397 Montpellier - Cedex 5 - France >>> Tel: +33 (0)467 61 13 02 >>> Fax: +33 (0)467 61 03 34 >>> >>> >>> >>> _______________________________________________ >>> moby-l mailing list >>> moby-l at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-l >> >> >> Wageningen University and Research centre (WUR) Laboratory of >> Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Jan 13 02:44:59 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 13 Jan 2006 07:44:59 +0000 (GMT) Subject: [MOBY-dev] RFC #1914 - change & call for vote In-Reply-To: <43C52E54.702@illuminae.com> Message-ID: Mark, Many thanks for the explanation. > v.v. your suggested changes, I think I addressed most of them in the > version of the RFC that I announced; if you recall, I gave you a preview > of the proposals, and you commented on that preview, so I made those > modifications before making the public RFC announcement. > No doubts about it, yes you did. But getData() were of the few not addressed and they are very impotant for me and perhaps for others (see more below). > v.v. what is returned by a getData call on an LSID? This is currently > still an open issue. The RFC describes (and is titled) how to retrieve > metadata about MOBY entities. > Well, there are two RFCs (1913 and 1914) and they both are related to LSIDs, so it is perhaps wise to discuss them both, or to merge them together, before we start voting on any of them. > What is returned by a getData call can be addressed in another RFC(s) > if anyone can think of a useful behaviour in the case of object, > namespace, servicetype, and serviceinstance LSID's (collectively or > respectively). > I definitely think about a useful behaviour (we discussed in with Ediie already in summer in Malaga). And the behaviour is very important - can make the real and immediate impact on the moby use, so I would like to see it on the table soon, whatever RFC issue to use it for. Here is what we spoke about with Eddit (slightly updated by the development of Dashboard): Practically all general moby clients need to have access to all data types (and perhaps also to all service instances). This is a consequence of the moby design, and I do not argue that. Examples are: Taverna, Ahab (I guess), Moses, Moby Graphs. (Anti-example is , I think, gbrowse that works differently.) Because of that, these clients rapidly move to RDF resources because that way they get all information faster. But still not fast enough. That's why I started to use local cache in Moses/Dasboard and in few other clients. The local cache needs, however, ability to be updated and synchronize with its moby registry. At the moment, it is possible to recognize completely new entries (and download them), or deleted entries (and remove them). But without re-loading the whole ontology it is not possible to recognize that a moby entity is of a newer version (such that somebody deregistered a service and registered it again slighly changed). But we have LSIDs for all moby entities already! So I would like to use it. Actually, I do not need to use getData(), but I need to have version in the LSIDs. But once you start to add a version there, you almost automatically imply what should be returned by getData() - because you need to know what represents a version. So I think that version should be assigned whenever a moby entity of the same name (and authority, etc.) is registered. I do not ask to keep all versions (simply the old LSIDs will not be resolvable if somebody asked for it - and its metadata may point to its latest version). Having versions in LSIDs can make a real impact on all clients using cache - and they can significantly help users. I can imagine Taverna starting like a breezy for biomoby. In jMoby, we have already software doing cacheing, and we can easily improve it to take versions into account. I also plan (in February) to reease for windows users a "package" (using commercial softawre InstallAnywhere) with some of jMoby software (especially Dashboard with a simple client for service invocation) and a snapshot of a moby registry. So normal users (not developers, and not Taverna users) will have finally one-stop to take everything - and having advanced caching there (advanced = using versions) would be a perfect. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 13 12:00:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 09:00:35 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: <1137171635.11074.29.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-01-13 at 07:44 +0000, Martin Senger wrote: > But once you start to add a version there, you almost > automatically imply what should be returned by getData() - because you > need to know what represents a version. ...almost automatically imply what should be returned... but not explicitly enough for my tiny brain :-) Explicitly, what do you want getData to return? Other than this confusion, I agree with most observations in your message, on first reading. Versioning of LSID's creates added complexity at the database end of things (since we need to keep track of all objects that have been deleted... forever!), but we are all familiar with these complexities and I guess there's no way around it once you start using the LSID standard. What isn't clear to me, however, is how this solves the problem that you are saying it will solve. If you have cached the RDF for all objects locally, how does a versioned LSID save you any time? It seems that it would actually make things *slower*, since it is then necessary to resolve every individual LSID to see if it were still up-to-date, rather than simply loading the entire ontology from scratch. Am I misunderstanding how you intend to use the versioned LSID? (Maybe if I understood what you are expecting getData to return, it will be obvious to me how it fixes the problem?) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Jan 13 17:51:35 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 13 Jan 2006 22:51:35 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <1137171635.11074.29.camel@bioinfo.icapture.ubc.ca> Message-ID: > ...almost automatically imply what should be returned... but not > explicitly enough for my tiny brain :-) Explicitly, what do you want > getData to return? > Your brain is fine - I actually did not say what to return. :-) The idea is that if you put a version to something, you know to what you are putting it, so you know what could be returned by getData(). But let me step back a bit: I started to talk about getData() and finished by talking about versioning. I admit that these two topics are closely related but they do not need to be solved both in the same time. What I really wish to have (sooner the better) is versioning. > Versioning of LSID's creates added complexity at the database end of > things (since we need to keep track of all objects that have been > deleted... forever!) > Yes and no. Definitely, some complexity must be added, but not perhaps that much. Because we do not need to return old objects - we can just refuse to resolve them. LSID spec does not allow to reuse the same LSID for something else, but does not require to resolve data with old version forever. So, for example, my naive implementation would be soemthing like this (I am probably still missing some situations): * add columns "version" and "active" to moby entities, * when a moby entity is being registered, find if you have it already in database with the flag "active" set to false: - if yes, update its version (and replace all other fields with the new registration data), - if not, create a new record, set "version" to 1 and "active" to true, * when an entity is being deregistered, set its "active" to false", * when to return entities, return only "active" once. (I guess that you can optimize by keping old (unregistered) entities in a separate table just with their last-used version number - this will substitute the "active" flag.) (Or, perhaps much better and simpler: just assign time of registration as a version field - so everytime you register an entity it gets new version. This seems the bestsolution... where is the catch? Is there any?) > What isn't clear to me, however, is how this solves the problem that you > are saying it will solve. If you have cached the RDF for all objects > locally, how does a versioned LSID save you any time? > The RDF is not fine grained - one RDF document contains, for example, all data types. But I want to get only one data type - in case I know that this data type has been changed. Perhapd the best explanation is to tell you how the current caching works in jMoby: For each type of entities (data types, service types, services and namespace) I keep one file (called "list") with all their names (and their LSIDs). When a user want to update a cache, these files are always created newly from a registry (there are four API methods to get them; eventhough it would be faster to have one method for getting all of them in one go, but that's another story). Then, the caching software reads the list and compare what it has in local cache. The entities that are in local cache but not in the list are removed from the local cache. The entities that are in the list but not in the local cache are aksed for (by a normal API call for one entity). But, this mechanism cannot recognize if an existing entity was changed. If the LSIDs have versions, the caching mechanism can also compare the LSIDs of the local entities and those in the list - and when the version in the list is newer, it can fetch the updated version. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 13 18:29:52 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 15:29:52 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: <1137194992.11875.34.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-01-13 at 22:51 +0000, Martin Senger wrote: > > Versioning of LSID's creates added complexity at the database end of > > things (since we need to keep track of all objects that have been > > deleted... forever!) > > > Yes and no. Definitely, some complexity must be added, but not perhaps > that much. I guess I was thinking exactly along the lines of your "active" flag - even inactive objects need to be stored forever. I admit, I was over- playing the complexity of that ;-) > (Or, perhaps much better and simpler: just assign time of registration as > a version field - so everytime you register an entity it gets new > version. This seems the bestsolution... where is the catch? Is there any?) I was also thinking along these lines. So long as our tooling never *shows* the version number to the user (or at least, not unless they ask for it), then it really doesn't matter how comlpex the version number format is. I don't know if adding a timestamp is any more complex than incrementing a version number... but it might be more informative?? > The RDF is not fine grained - one RDF document contains, for example, > all data types. But I want to get only one data type - in case I know that > this data type has been changed. Perhapd the best explanation is to tell > you how the current caching works in jMoby: I see - so jMoby would not automatically know about any newly registered objects unless you explicitly asked for a refresh of the entire RDF; however you WOULD be guaranteed of always having the latest version of whatever object you were working with, because as soon as you "selected" it, that PARTICULAR object would be validated against the registry. Is that correct? That all sounds great! Do you want to write up an addition to the RFC? (we still don't know what you want to be returned by a getData call - you are keeping us in suspense! ;-) ) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Jan 13 19:04:17 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 14 Jan 2006 00:04:17 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <1137194992.11875.34.camel@bioinfo.icapture.ubc.ca> Message-ID: > I was also thinking along these lines. So long as our tooling never > *shows* the version number to the user (or at least, not unless they ask > for it), then it really doesn't matter how comlpex the version number > format is. I don't know if adding a timestamp is any more complex than > incrementing a version number... but it might be more informative?? > Timestamp can be a number of elapsed second/millisecond from the beginning of an epoche. So it is a long integer - not that different from a usual version number. Important is that it is always the same unless/until the entity is re-registered. Incrementing a version number is more complex than timestamp because in order to increment you need to know an old value (that will be incremented). With a timestamp you do not need to keep unregistered objects at all. You need just to add a new column "timestamp" and fill it with the current time when an object is registered. And to add this "timestamp" field as version to the created LSID. That seems all you need to do (but perhaps I am still missing some catch). > I see - so jMoby would not automatically know about any newly registered > objects unless you explicitly asked for a refresh of the entire RDF; > (Almost) correct. jMoby (its caching mechanism) does not know about any newly registered objects automatically, the user has to ask for update (the "user" can be, however, a cron job, or whatever). But for refreshing, jMoby does not use RDF - but it asks for a list of entities using normal API call (such as getServiceNames - or whatever the method is called, I can't remember now). There is no such RDF document to give me "only" a list of object names (and I am not asking for that, the API is fine). > however you WOULD be guaranteed of always having the latest version of > whatever object you were working with, because as soon as you "selected" > it, that PARTICULAR object would be validated against the registry. Is > that correct? > Yes, it could be done this way. The "selection" can trigger the update mechanism. But it does not - the users (of dashboard, for example) have to click on a button 'update' if they feel that their cache is not up-to-date. This does not seem to be a problem in the real life. > Do you want to write up an addition to the RFC? > Well, adding a version number to the LSIDs is not really a change that needs an RFC I guess. It is just making current existing features better - and without breaking existing software. I would suggest that you just ask Eddie to add versioning and then you both can announce it as a improved feature. I would really love it to have - and I can at once make use of it in Dashboard (and slightly later, and with coordination with Eddie, in Taverna). > (we still don't know what you want to be returned by a getData call - > you are keeping us in suspense! ;-) ) > I said: I am stepping back a bit. Talk about getData() brought me to versioning - and that's what I wish to have. Forget getData() for now :-) (Mainly because what I would return by getData() is identical to what normal old-fashioned moby API calls do quite well now (such as retrieveObjectDefinition()) ). Martin PS. TW, Mylah from IRRI is just finishing her mirroring scripts (to regularly update our local/testing GCP registry from the central one) - and she would definitely welcome the versions as well - mirroring is just another example (additional to my local caching usage) where LSIDs with versions would be tremendously and immediately useful. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Jan 13 21:17:52 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 14 Jan 2006 02:17:52 +0000 (GMT) Subject: [MOBY-dev] error handling in MoSeS Message-ID: I have implemented (thanks to Ivan Garcia from MMB in Spain) the new biomoby error handling in Moses. In your implementation classes, now you can add exceptions and they will appear in their proper place in the service notes. As far as I know, the changes I have done do not break any existing code. Well, except if you still send to a new Moses-based service an old XML with something like this: ABCD the text ABCD will be simply ignored. (Note that the new way how to incorporate human-readable message in service notes is: ABCD.) I have also updated the Moses documentation concerning with error handling. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 13 22:39:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 19:39:48 -0800 Subject: [MOBY-dev] error handling in MoSeS In-Reply-To: References: Message-ID: <43C87284.5010709@illuminae.com> Martin you totally rock! Give us a couple of weeks to catch up on the Perl side of things - poor Eddie is re-writing a large portion of my code to give it the same architecture and API as the Java modules, so it is taking a while. He's also writing the Perl plugin to dashboard, and making a trip down to TAIR next week to help them get started MOBYing, so he's a busy fellow! I think it is about time to start writing "the big manuscript" with all the core developers as authors... Martin, do you want to include tools like Dashboard in this publication, or are you planning to write an independent publication (or both?). I'm thinking that I still may be able to get the gbrowse_moby interface published as an application note or something like that. It isn't very powerful, but the interesting part of it from the CS point of view is how the rendering system works - it strikes me as being a very sensible way to deal with MOBY object data in a world where you can never predict what data you are going to have in-hand... though it may no longer be novel enough to be publishable. I should have written that paper years ago... >>sigh<< Anyway, I'm going to start on the "big" manuscript but I will no doubt be asking for the various key parties to describe their own contributions, so please keep an eye on your inboxes for paragraph requests! Cheers all! M Martin Senger wrote: >I have implemented (thanks to Ivan Garcia from MMB in Spain) the new >biomoby error handling in Moses. In your implementation classes, now you >can add exceptions and they will appear in their proper place in the >service notes. > As far as I know, the changes I have done do not break any existing >code. Well, except if you still send to a new Moses-based service an old >XML with something like this: > ABCD >the text ABCD will be simply ignored. (Note that the new way how to >incorporate human-readable message in service notes is: > ABCD.) > > I have also updated the Moses documentation concerning with error >handling. > > Cheers, > Martin > > > From senger at ebi.ac.uk Fri Jan 13 22:47:01 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 14 Jan 2006 03:47:01 +0000 (GMT) Subject: [MOBY-dev] error handling in MoSeS In-Reply-To: <43C87284.5010709@illuminae.com> Message-ID: > Eddie is re-writing a large portion of my code to give it the same > architecture and API as the Java modules > Yes, I know - he is frequently in touch with me. And I am supposed to contribute to this Perl code in the beginning of February, as well! > the core developers as authors... Martin, do you want to include tools > like Dashboard in this publication, or are you planning to write an > independent publication (or both?). > It would nice to include Moses/Dashboard there. Tell me (in due time) what I can do for it. I am planning to introduce Moses/Dashboard (and perhaps other tools used in GCP) in BOSC 2006 (if it happens) - but it hopefully will not prevent to participate in your "big manuscript" - will it not? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 13 23:02:56 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 20:02:56 -0800 Subject: [MOBY-dev] error handling in MoSeS In-Reply-To: References: Message-ID: <43C877F0.9060401@illuminae.com> Martin Senger wrote: >>Eddie is re-writing a large portion of my code to give it the same >>architecture and API as the Java modules >> >> >> > Yes, I know - he is frequently in touch with me. And I am supposed to >contribute to this Perl code in the beginning of February, as well! > > > Excellent! I'm so pleased that you are remaining as involved in MOBY development as you always have been - many thanks to you, and to Richard for your ongoing support and enthusiasm! M From Pieter.Neerincx at wur.nl Tue Jan 17 14:38:04 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 17 Jan 2006 20:38:04 +0100 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> Hi Martin, So far I really like your idea for versioning of the LSIDs and a timestamp is fine. Basically I wouldn't care what exact version number I am working with. The only thing most of us will care about is whether the LSID is up to date. Major and minor version number increments are more something for a marketing department to make a difference in free updates and payed upgrades :). I do think you should write a small update for the RFC though. It's important we all know what exactly those new versioned LSIDs will look like. Will it be ...MyObject_timestamp, ...MyObject:timestamp, or .... and what is the format of your timestamp. It doesn't really matter which format it will be as long as we all know what it looks like. Therefore it should be written down somewhere and preferably documented on the BioMOBY website. One thing I was wondering about is the following: If a service is registered, we specify the input and output. Lets say for example I register service A with as input a simple Object SomeObject_version1. Some time later somebody else decides to update SomeObject, maybe for something as simple as a typo in the description. The up-to-date version of SomeObject now becomes SomeObject_version2. What happens to my service? Do I have to reregister it with SomeObject_version2 as input? SomeObject_version1 is no longer "available", so my service is registered with an outdated => not LSID resolvable => invalid input .... Another thing I was wondering about is relationships. What happens if I have SomeObject_v1 hasa AnotherObject_v1 and AnotherObject is updated? If this happens SomeObject has a child that is no longer LSID resolvable => no longer valid. I guess the parent will need to be updated too, or am I missing something? Currently the object ontology in BioMOBY Central is still rather flat, but when a lot of objects with a complex structures are registered, updating one object might result in updating half the registry, because of all the relationships.... Cheers, Pi On 14-Jan-2006, at 1:04 AM, Martin Senger wrote: >> I was also thinking along these lines. So long as our tooling never >> *shows* the version number to the user (or at least, not unless >> they ask >> for it), then it really doesn't matter how comlpex the version number >> format is. I don't know if adding a timestamp is any more complex >> than >> incrementing a version number... but it might be more informative?? >> > Timestamp can be a number of elapsed second/millisecond from the > beginning of an epoche. So it is a long integer - not that > different from > a usual version number. Important is that it is always the same > unless/until the entity is re-registered. > Incrementing a version number is more complex than timestamp > because in > order to increment you need to know an old value (that will be > incremented). With a timestamp you do not need to keep unregistered > objects at all. You need just to add a new column "timestamp" and > fill it > with the current time when an object is registered. And to add this > "timestamp" field as version to the created LSID. That seems all > you need > to do (but perhaps I am still missing some catch). > >> I see - so jMoby would not automatically know about any newly >> registered >> objects unless you explicitly asked for a refresh of the entire RDF; >> > (Almost) correct. jMoby (its caching mechanism) does not know > about any > newly registered objects automatically, the user has to ask for update > (the "user" can be, however, a cron job, or whatever). But for > refreshing, > jMoby does not use RDF - but it asks for a list of entities using > normal > API call (such as getServiceNames - or whatever the method is > called, I > can't remember now). There is no such RDF document to give me "only" a > list of object names (and I am not asking for that, the API is fine). > >> however you WOULD be guaranteed of always having the latest >> version of >> whatever object you were working with, because as soon as you >> "selected" >> it, that PARTICULAR object would be validated against the >> registry. Is >> that correct? >> > Yes, it could be done this way. The "selection" can trigger the > update > mechanism. But it does not - the users (of dashboard, for example) > have to > click on a button 'update' if they feel that their cache is not > up-to-date. This does not seem to be a problem in the real life. > >> Do you want to write up an addition to the RFC? >> > Well, adding a version number to the LSIDs is not really a > change that > needs an RFC I guess. It is just making current existing features > better - > and without breaking existing software. I would suggest that you > just ask > Eddie to add versioning and then you both can announce it as a > improved > feature. I would really love it to have - and I can at once make > use of it > in Dashboard (and slightly later, and with coordination with Eddie, in > Taverna). > >> (we still don't know what you want to be returned by a getData call - >> you are keeping us in suspense! ;-) ) >> > I said: I am stepping back a bit. Talk about getData() brought > me to > versioning - and that's what I wish to have. Forget getData() for > now :-) > (Mainly because what I would return by getData() is identical to > what > normal old-fashioned moby API calls do quite well now (such as > retrieveObjectDefinition()) ). > > Martin > > PS. TW, Mylah from IRRI is just finishing her mirroring scripts (to > regularly update our local/testing GCP registry from the central > one) - > and she would definitely welcome the versions as well - mirroring > is just > another example (additional to my local caching usage) where LSIDs > with > versions would be tremendously and immediately useful. M. > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Jan 17 15:55:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 Jan 2006 12:55:40 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> References: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> Message-ID: <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-01-17 at 20:38 +0100, Pieter Neerincx wrote: > I do think you > should write a small update for the RFC though. Martin and I agreed offline that I would do this update - after Wednesday when I have finished lecturing for the week. > It's important we all > know what exactly those new versioned LSIDs will look like. Will it > be ...MyObject_timestamp, ...MyObject:timestamp It will follow the proper LSID format, where the version is after teh final ':' urn:lsid:some.organization.urn:namespace:id:version > it will be as long as we all know what it looks like. Therefore it > should be written down somewhere and preferably documented on the > BioMOBY website. I will do that shortly - as an addendum to teh RFC for discussion. > Some time later somebody else decides to update SomeObject, maybe for > something as simple as a typo in the description. They cannot. MOBY Central will not allow this to happen (at least in its current codebase). An ontology term that is being used by a service CANNOT be deleted or modified. > Another thing I was wondering about is relationships. What happens if > I have SomeObject_v1 hasa AnotherObject_v1 and AnotherObject is > updated? Also cannot happen. An object that is being used in the definition of another object cannot be modified or deleted. Both of these cases are tested and enforced at the code level. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Tue Jan 17 18:06:06 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 18 Jan 2006 00:06:06 +0100 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> References: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, Looks like the RFC is getting a solid proposal. Looking forward to the final one :). On 17Jan2006, at 21:55, Mark Wilkinson wrote: > On Tue, 2006-01-17 at 20:38 +0100, Pieter Neerincx wrote: > >> Some time later somebody else decides to update SomeObject, maybe for >> something as simple as a typo in the description. > > They cannot. MOBY Central will not allow this to happen (at least in > its current codebase). An ontology term that is being used by a > service > CANNOT be deleted or modified. Hmmm true. Maybe this is getting a bit to theoretical. I have to admit I have never tried this before, but what if you deregister the service fist. Nobody checks if it's me who is deregistering my service or somebody else. After that it would be possible to update the object (or deregister the old one and register the new version). Is that possible? >> Another thing I was wondering about is relationships. What happens if >> I have SomeObject_v1 hasa AnotherObject_v1 and AnotherObject is >> updated? > > Also cannot happen. An object that is being used in the definition of > another object cannot be modified or deleted. Same thing. What about deleting the childs first, then the parent and afterwards reregistering the whole bunch (childs first of course). Pi > > Both of these cases are tested and enforced at the code level. > > M > > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Jan 17 18:53:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 Jan 2006 15:53:20 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> Message-ID: <1137542000.1730.29.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-01-18 at 00:06 +0100, Pieter Neerincx wrote: > if you deregister the > service fist. If an object has nothing depending on it, then it is available for deregistration and potential re-registration. Note that this excludes the possibility that you mentioned, which is that a service can be "tricked" by someone changing the object definition. > Nobody checks if it's me who is deregistering my > service or somebody else. SSSSHHSHHhhhhh!! Don't say that too loudly! :-) This is *exactly* the reason we are moving to an agent-based deregistration system. It will be impossible for someone else to deregister your service. > Same thing. What about deleting the childs first, then the parent and > afterwards reregistering the whole bunch (childs first of course). Yes, that's possible... but it doesn't matter. If nothing is using an object, then you can't do any harm by changing its definition... and you can't change the definition if something is using it. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Sat Jan 21 01:43:10 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 21 Jan 2006 06:43:10 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> Message-ID: Hi, Thanks for supporting the idea of having version in LSIDs. I think that Mark answered all your questions. Just perhaps one small explanation: > registered, we specify the input and output. Lets say for example I > register service A with as input a simple Object SomeObject_version1. > Your assumption here is not correct: a service is not registered as having a simple Object SomeObject_version1, but as having a simple Object SomeObject. We are not proposing to use version in registration - we are registering data types by their names (not by their LSIDs). Versions in LSIDs are good for finding that the object itself was or was not re-registerd (and therefore perhap changed). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From jmfernandez at cnb.uam.es Mon Jan 23 11:19:21 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Mon, 23 Jan 2006 17:19:21 +0100 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation Message-ID: <43D50209.2000308@cnb.uam.es> Hi everybody, I have been browsing the developers documentation hanging on the (now not so) new BioMOBY web site, and I have realized that there is no information about serviceNotes and ProvisionInformation tags! Ye olde documentation contained that information (snif, snif). Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From edward.kawas at gmail.com Mon Jan 23 11:30:13 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 23 Jan 2006 08:30:13 -0800 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <43D50209.2000308@cnb.uam.es> Message-ID: <000101c6203a$4c3b3b20$6b00a8c0@notebook> Hi Jose Maria, The documentation is there, somewhere (I cant seem to connect to the site right now ...). In the cvs, the file is ObjectStructure.html. Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > Fern?ndez > Sent: Monday, January 23, 2006 8:19 AM > To: mobydev > Subject: [MOBY-dev] BioMOBY web doesn't contain documentation > about serviceNotes and ProvisionInformation > > Hi everybody, > I have been browsing the developers documentation > hanging on the (now not so) new BioMOBY web site, and I have > realized that there is no information about serviceNotes and > ProvisionInformation tags! Ye olde documentation contained > that information (snif, snif). > > Best Regards, > Jos? Mar?a > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Mon Jan 23 13:25:23 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Mon, 23 Jan 2006 19:25:23 +0100 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <000101c6203a$4c3b3b20$6b00a8c0@notebook> References: <000101c6203a$4c3b3b20$6b00a8c0@notebook> Message-ID: <43D51F93.2090602@cnb.uam.es> Thanks Eddie! I have found where you told the documentation about ProvisionInformation (I didn't see it, I'm blind!) ... ... but serviceNotes information is still missing. Best Regards, Jos? Mar?a Edward Kawas wrote: > Hi Jose Maria, > > The documentation is there, somewhere (I cant seem to connect to the site > right now ...). > > In the cvs, the file is ObjectStructure.html. > > Hope this helps, > > Eddie > > >>-----Original Message----- >>From: moby-dev-bounces at biomoby.org >>[mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a >>Fern?ndez >>Sent: Monday, January 23, 2006 8:19 AM >>To: mobydev >>Subject: [MOBY-dev] BioMOBY web doesn't contain documentation >>about serviceNotes and ProvisionInformation >> >>Hi everybody, >> I have been browsing the developers documentation >>hanging on the (now not so) new BioMOBY web site, and I have >>realized that there is no information about serviceNotes and >>ProvisionInformation tags! Ye olde documentation contained >>that information (snif, snif). >> >> Best Regards, >> Jos? Mar?a >>-- >>Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es >>Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 >>Grupo de Dise?o de Proteinas Protein Design Group >>Centro Nacional de Biotecnolog?a National Center of Biotechnology >>C.P.: 28049 Zip Code: 28049 >>C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid >>(Spain) _______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From francis_gibbons at hms.harvard.edu Mon Jan 23 17:38:08 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Mon, 23 Jan 2006 17:38:08 -0500 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <43D51F93.2090602@cnb.uam.es> References: <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> Message-ID: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Jos? Mar?a, Part of the reason it was missing is that there was so little to say, until the Exception reporting RFC. From the moby-live/Docs/MOBY-S_API/MessageStructure.html documentation file: "The serviceNotes block is only loosely defined in this version of the API, and is currently meant to contain human-readable freetext. serviceNotes are optional. " That's pretty much all one could say until recently, so it's hard to find any mention of it unless you grep all the files. What are your plans for integrating the exception-reporting into the main codebase? Will it be Java first, Java only, or Perl? The Provision Information Block (PIB) is mentioned in ObjectStructure.html, again a one-liner. As the code begins to reflect the implementation of the Exception-RFC, we should add documentation to reflect that. Mark, there's also the question of how the website gets updated. The best way to do it in my view, would be to have the website updated nightly and automatically to reflect the documentation (both from static HTML) for the non-language-specific parts of the API, and also from the POD/javadoc in the language-specific parts. Seems like it shouldn't be too hard to run it from cron, nor take too long to run (perhaps we could even do it hourly, instead of daily?). -Frank At 01:25 PM 1/23/2006, you wrote: >Thanks Eddie! > > I have found where you told the documentation about >ProvisionInformation (I didn't see it, I'm blind!) ... > >... but serviceNotes information is still missing. > > Best Regards, > Jos? Mar?a > >Edward Kawas wrote: > > Hi Jose Maria, > > > > The documentation is there, somewhere (I cant seem to connect to the site > > right now ...). > > > > In the cvs, the file is ObjectStructure.html. > > > > Hope this helps, > > > > Eddie > > > > > >>-----Original Message----- > >>From: moby-dev-bounces at biomoby.org > >>[mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > >>Fern?ndez > >>Sent: Monday, January 23, 2006 8:19 AM > >>To: mobydev > >>Subject: [MOBY-dev] BioMOBY web doesn't contain documentation > >>about serviceNotes and ProvisionInformation > >> > >>Hi everybody, > >> I have been browsing the developers documentation > >>hanging on the (now not so) new BioMOBY web site, and I have > >>realized that there is no information about serviceNotes and > >>ProvisionInformation tags! Ye olde documentation contained > >>that information (snif, snif). > >> > >> Best Regards, > >> Jos? Mar?a > >>-- > >>Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > >>Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > >>Grupo de Dise?o de Proteinas Protein Design Group > >>Centro Nacional de Biotecnolog?a National Center of Biotechnology > >>C.P.: 28049 Zip Code: 28049 > >>C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > >>(Spain) _______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://biomoby.org/mailman/listinfo/moby-dev > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > >-- >Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es >Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 >Grupo de Dise?o de Proteinas Protein Design Group >Centro Nacional de Biotecnolog?a National Center of Biotechnology >C.P.: 28049 Zip Code: 28049 >C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Mon Jan 23 17:41:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 23 Jan 2006 14:41:36 -0800 Subject: [MOBY-dev] [moby] Re: BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> References: <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-01-23 at 17:38 -0500, Frank Gibbons wrote: > Mark, there's also the question of how the website gets updated. The best > way to do it in my view, would be to have the website updated nightly and > automatically to reflect the documentation (both from static HTML) for the > non-language-specific parts of the API, and also from the POD/javadoc in > the language-specific parts. Seems like it shouldn't be too hard to run it > from cron, nor take too long to run (perhaps we could even do it hourly, > instead of daily?). I think both of these things are being done hourly already... or?? AFAIK Martin has a cron running that rebuilds the javadoc, and the same cron runs a script that does a CVS update of the general docuentation part of the site If this isn't working, let me know. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Mon Jan 23 18:24:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 23 Jan 2006 15:24:48 -0800 Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition Message-ID: <1138058688.17515.96.camel@bioinfo.icapture.ubc.ca> Hi all, v.v. LSID versioning - I've put together code that handles LSID versioning in the follwing way: Namespaces, Objects, ServiceTypes, and ServiceInstances all get an LSID exactly as before, with the addition of a Version field (as defined in the LSID spec a ":" followed by the version number). The version format I'm going with is very similar to a full ISO 8601 timestamp, except that it replaces the ":" between the hour, min, sec with "-" as follows: yyyy-mm-ddThh-mm-ss For example: urn:lsid:biomoby.org:objectclass:Object:2006-01-23T12-01-59 ***** Since this is an update to the RFC, can anyone with an interest please give me a "yes" or a "no" on this new format? We aren't committed to it, it was just for my own testing purposes ***** I've also written a script that, I think, should update any registry database such that all LSID's in all tables are identically timestamped (since the LSID is often used in the database as the primary key!) ****** Is anyone dependent on the main registry being funny functional this week? Once I hear back from people v.v. this change to the RFC, I'd like to run the script on the main registry. Chances are this will go smoothly, but I will have to take it down for a few minutes while I do the update, so if anyone is critically depending on it being active please let me know. ****** Cheers all! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Tue Jan 24 01:11:16 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 23 Jan 2006 22:11:16 -0800 Subject: [MOBY-dev] The Canadian Elections & MOBY funding Message-ID: We have just had a significant change in government in Canada - the election was today. The extreme-right won a minority government! I don't know how/if this will change the funding for MOBY here in Canada, but it might... Stay tuned! The proverb "may you live in interesting times" is definitely applicable tonight! Mark From francis_gibbons at hms.harvard.edu Tue Jan 24 10:27:02 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 24 Jan 2006 10:27:02 -0500 Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060124101843.011d7d00@email.med.harvard.edu> Mark, Can't speak for the javadoc, but updating the online API docs from CVS appears to work. I checked in a slight modification to one of the files at 6pm yesterday. When I checked at 9pm that evening, the modification was visible on the website, so I think we can assume that it's being done hourly. Martin doesn't do things by halves, so I assume the rest is workign too - nice job, Martin. It would be useful if we could have a link on the website to the POD, which could also be auto-updated from CVS, so that potential future users could browse the perl documentation online, without having to check out the code and run perldoc on it. I'll work on making the API documentation look more integrated into the website, and try to provide better navigation so that the various pages are easier to see/find. On a related note, when I type "servicenotes" or "provision" into the search widget and hit the button, I get back "Error 404 - not found". In fact, I just realised that even searching for "MOBY" returns this - could the search utility possibly be mis-configured? Search would be a useful feature, particularly until we can get the docs more organised, but even afterwards too. -Frank At 05:41 PM 1/23/2006, you wrote: >On Mon, 2006-01-23 at 17:38 -0500, Frank Gibbons wrote: > > > Mark, there's also the question of how the website gets updated. The best > > way to do it in my view, would be to have the website updated nightly and > > automatically to reflect the documentation (both from static HTML) for the > > non-language-specific parts of the API, and also from the POD/javadoc in > > the language-specific parts. Seems like it shouldn't be too hard to run it > > from cron, nor take too long to run (perhaps we could even do it hourly, > > instead of daily?). > >I think both of these things are being done hourly already... or?? > >AFAIK Martin has a cron running that rebuilds the javadoc, and the same >cron runs a script that does a CVS update of the general docuentation >part of the site > >If this isn't working, let me know. > >M > > > >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Tue Jan 24 15:47:03 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 24 Jan 2006 21:47:03 +0100 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: Hi Martin, On 21Jan2006, at 07:43, Martin Senger wrote: > Hi, > Thanks for supporting the idea of having version in LSIDs. > I think that Mark answered all your questions. Just perhaps one > small > explanation: > >> registered, we specify the input and output. Lets say for example I >> register service A with as input a simple Object SomeObject_version1. >> > Your assumption here is not correct: a service is not registered as > having a simple Object SomeObject_version1, but as having a simple > Object > SomeObject. We are not proposing to use version in registration - > we are > registering data types by their names (not by their LSIDs). > Versions in > LSIDs are good for finding that the object itself was or was not > re-registerd (and therefore perhap changed). Thanks for the explanation. This wasn't clear to me yet, so I made some wrong assumptions. Leaving the LSIDs and therefore version numbers out for the objects when registering services makes life much easier :). Bring on the version numbered LSIDs! Pi > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From m.anacleto at cgiar.org Wed Jan 25 04:15:21 2006 From: m.anacleto at cgiar.org (Anacleto, Mylah Rystie (IRRI)) Date: Wed, 25 Jan 2006 17:15:21 +0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote Message-ID: Hi, We have a local registry, I followed the steps on how to create/populate the database and am expecting that the contents of our db now contains the same datatypes, service types, namespaces, services as in moby central. I am running a script that mirrors the moby central database (also regularly updates our local registry here at IRRI). Since the db has just been refreshed, I expect no discrepancies(the script traps discrepancies in LSIDs, IDs, inputs, outputs, etc..) but I did get a lot reported with different LSIDs. I am still looking into it but I guess it's not the mirroring program. Must be the dump perl script? (java api has one that calls the perl dump script and that's the one I used) Thanks, Mylah -----Original Message----- From: moby-dev-bounces at biomoby.org [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx Sent: Wednesday, January 25, 2006 4:47 AM To: Core developer announcements Subject: Re: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote Hi Martin, On 21Jan2006, at 07:43, Martin Senger wrote: > Hi, > Thanks for supporting the idea of having version in LSIDs. > I think that Mark answered all your questions. Just perhaps one > small > explanation: > >> registered, we specify the input and output. Lets say for example I >> register service A with as input a simple Object SomeObject_version1. >> > Your assumption here is not correct: a service is not registered as > having a simple Object SomeObject_version1, but as having a simple > Object > SomeObject. We are not proposing to use version in registration - > we are > registering data types by their names (not by their LSIDs). > Versions in > LSIDs are good for finding that the object itself was or was not > re-registerd (and therefore perhap changed). Thanks for the explanation. This wasn't clear to me yet, so I made some wrong assumptions. Leaving the LSIDs and therefore version numbers out for the objects when registering services makes life much easier :). Bring on the version numbered LSIDs! Pi > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev From francis_gibbons at hms.harvard.edu Thu Jan 26 10:57:33 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 26 Jan 2006 10:57:33 -0500 Subject: [MOBY-dev] Updated MOBY-S API docs on website In-Reply-To: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060126105252.06db0258@email.med.harvard.edu> Just FYI: I updated the MOBY API docs somewhat last night, they're now visible on the MOBY website. I did notice some small glitches in the style, which I've corrected but not yet checked in. Still, I'd appreciated feedback on what's been done so far. At this point, there is little new content, but at least I think it's becoming easier to find what you need. -Frank At 05:41 PM 1/23/2006, you wrote: >On Mon, 2006-01-23 at 17:38 -0500, Frank Gibbons wrote: > > > Mark, there's also the question of how the website gets updated. The best > > way to do it in my view, would be to have the website updated nightly and > > automatically to reflect the documentation (both from static HTML) for the > > non-language-specific parts of the API, and also from the POD/javadoc in > > the language-specific parts. Seems like it shouldn't be too hard to run it > > from cron, nor take too long to run (perhaps we could even do it hourly, > > instead of daily?). > >I think both of these things are being done hourly already... or?? > >AFAIK Martin has a cron running that rebuilds the javadoc, and the same >cron runs a script that does a CVS update of the general docuentation >part of the site > >If this isn't working, let me know. > >M > > > >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Jan 26 12:27:03 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Jan 2006 09:27:03 -0800 Subject: [MOBY-dev] Vote on RFC#1913 #1914 Message-ID: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> Could the core voting group please vote on the LSID RFC's over the weekend, or request changes. Thanks! M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jan 26 14:38:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Jan 2006 11:38:40 -0800 Subject: [MOBY-dev] I vote YES to RFC 1913 & 1914 Message-ID: <1138304320.23818.1.camel@bioinfo.icapture.ubc.ca> :-) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From johan at ac.uma.es Thu Jan 26 14:21:24 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 26 Jan 2006 20:21:24 +0100 Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal Message-ID: <43D92134.2060708@ac.uma.es> Dear all, First of all, let me introduce myself. My name is Johan Karlsson and I work at the Department of Computer Architecture at the University of M?laga, Spain within the group GNV-5 (part of the Spanish organization INB). Our group deals with different aspects of "Integrated Bioinformatics" at the INB. Attached to this email you can find the INB proposal (RFC) on asynchronous service calls. This proposal is a result of discussions during the INB meeting in M?laga during July 2005 with the participation of Martin Senger and Edward Kawas and further discussions in the INB mailing lists. Kind regards, Johan Karlsson Department of Computer Architecture University of M?laga johan at ac.uma.es -------------- next part -------------- A non-text attachment was scrubbed... Name: BioMOBY Asynchronous Service Call Proposal.pdf Type: application/pdf Size: 182904 bytes Desc: not available Url : http://biomoby.org/pipermail/moby-dev/attachments/20060126/26d43f0f/attachment-0001.pdf From senger at ebi.ac.uk Thu Jan 26 19:57:44 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 00:57:44 +0000 (GMT) Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: > any mention of it unless you grep all the files. What are your plans for > integrating the exception-reporting into the main codebase? Will it be Java > first, Java only, or Perl? > jMoby (at least the part that generate Moses-based service skeletons) has done it. It is also documented in the javadoc (see, for example: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/API/org/biomoby/shared/parser/ServiceException.html. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Thu Jan 26 20:00:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Jan 2006 17:00:36 -0800 Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition In-Reply-To: References: Message-ID: On Thu, 26 Jan 2006 16:52:04 -0800, Martin Senger wrote: > I am happy with your versioning. But if I choose I would choose just a > number of elapsed milisecond from the beginning of epoch (1/1/1970). This > would prevent of need to parse the formatted string in version (if one > decides to do so - I know that LSIDs are opaque :-)). :-) Yes, they are! I'm easy either way - I thought it would be nice to put it in ISO format just so that people could easily see the approximate date the object/service was created "by eye", but I suspect that there will be few opportunities for someone to actually SEE a MOBY LSID, so that may not be a big benefit. Does anyone else have an opinion? I'm not fussy... > It also prevents a > need to specify what format the string is in. > But this is only a detail. Having versions in any format is the most > important. > In both alternatives (ISO 8601 or ellapsed time), however, we need to > say what timezone the date is in, I guess. I guess it will be in whatever time-zone that particular registry is in... but since LSID's are supposed to be opaque, we shouldn't be worrying about it ;-) M From senger at ebi.ac.uk Thu Jan 26 19:54:55 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 00:54:55 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> Message-ID: > I think both of these things are being done hourly already... or?? > Yes, that's correct. If anybody sees that something is not beig updated please let me know and I will look at it. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Jan 26 19:52:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 00:52:04 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition In-Reply-To: <1138058688.17515.96.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, Thanks for doing this. I was not on-line this week and I am reading my mailbox from the bottom - so perhaps later I will find some reactions to your plans (I apologize if I am suggesting now things that had been already decided and solved). I am happy with your versioning. But if I choose I would choose just a number of elapsed milisecond from the beginning of epoch (1/1/1970). This would prevent of need to parse the formatted string in version (if one decides to do so - I know that LSIDs are opaque :-)). It also prevents a need to specify what format the string is in. But this is only a detail. Having versions in any format is the most important. In both alternatives (ISO 8601 or ellapsed time), however, we need to say what timezone the date is in, I guess. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Jan 26 20:34:13 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 01:34:13 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition In-Reply-To: Message-ID: > I guess it will be in whatever time-zone that particular registry is > in... > I think that if you go ISO way, the 'Z' should be present (if not GMT) - at least that what I vaguely remember about this date/time spec. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Thu Jan 26 20:31:18 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 01:31:18 +0000 (GMT) Subject: [MOBY-dev] Vote on RFC#1913 #1914 In-Reply-To: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> Message-ID: I vote YES on both 1913/14. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Thu Jan 26 18:15:12 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 26 Jan 2006 15:15:12 -0800 Subject: [MOBY-dev] I vote YES to RFC 1913 & 1914 In-Reply-To: <1138304320.23818.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <000c01c622ce$5ed71880$7666a8c0@notebook> Eddie From jmfernandez at cnb.uam.es Fri Jan 27 06:29:05 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Fri, 27 Jan 2006 12:29:05 +0100 Subject: [MOBY-dev] Versioning of LSID's and brief registry outagesduring transition In-Reply-To: References: Message-ID: <43DA0401.8010007@cnb.uam.es> Hi everybody, AFAICR Z is the 'separator' for the timezone. MOBY services are spread over the world, so timestamps should be referenced to UTC. Best Regards, Jos? Mar?a Martin Senger wrote: >> I guess it will be in whatever time-zone that particular registry is >> in... >> > I think that if you go ISO way, the 'Z' should be present (if not > GMT) - at least that what I vaguely remember about this date/time spec. > > Martin > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From Pieter.Neerincx at wur.nl Fri Jan 27 08:07:29 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 27 Jan 2006 14:07:29 +0100 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: References: Message-ID: <7A5B61FB-EFD2-44AC-9A23-550E5F4CF90A@wur.nl> From the W3C profile of the ISO-8601 specification: "This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. A standard referencing this profile should permit one or both of these ways of handling time zone offsets. Examples 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 1994-11-05T13:15:30Z corresponds to the same instant." So we should choose whether to permit time in UTC (with the "Z"), time in local time (+/-hh:mm) or both... I don't have any specific preference for either of the two but I guess supporting only one of them makes lief easier as compared to supporting both. Whatever the choice is I vote YES on both RFC 1913 and 1914. Cheers, Pieter. On 27-Jan-2006, at 2:34 AM, Martin Senger wrote: >> I guess it will be in whatever time-zone that particular registry is >> in... >> > I think that if you go ISO way, the 'Z' should be present (if not > GMT) - at least that what I vaguely remember about this date/time > spec. > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Jan 27 11:03:13 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 Jan 2006 08:03:13 -0800 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <7A5B61FB-EFD2-44AC-9A23-550E5F4CF90A@wur.nl> References: <7A5B61FB-EFD2-44AC-9A23-550E5F4CF90A@wur.nl> Message-ID: A question for Martin - does the "milliseconds since epoch" number tell us which time zone the milliseconds were measured in? If not, then the discussion is somewhat moot... All we're trying to generate is a unique string. If that unique string has some interpretable value, then maybe we gain something, maybe not (but we shouldn't be coding as if it did either way, since we're not supposed to interpret LSID fields) M On Fri, 27 Jan 2006 05:07:29 -0800, Pieter Neerincx wrote: > From the W3C profile of the ISO-8601 specification: > "This profile defines two ways of handling time zone offsets: > > 1. Times are expressed in UTC (Coordinated Universal Time), with a > special UTC designator ("Z"). > 2. Times are expressed in local time, together with a time zone > offset in hours and minutes. A time zone offset of "+hh:mm" indicates > that the date/time uses a local time zone which is "hh" hours and > "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates > that the date/time uses a local time zone which is "hh" hours and > "mm" minutes behind UTC. > A standard referencing this profile should permit one or both of > these ways of handling time zone offsets. > > Examples > > 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 > am, US Eastern Standard Time. > > 1994-11-05T13:15:30Z corresponds to the same instant." > > So we should choose whether to permit time in UTC (with the "Z"), > time in local time (+/-hh:mm) or both... I don't have any specific > preference for either of the two but I guess supporting only one of > them makes lief easier as compared to supporting both. Whatever the > choice is I vote YES on both RFC 1913 and 1914. > > Cheers, > > Pieter. > > > On 27-Jan-2006, at 2:34 AM, Martin Senger wrote: > >>> I guess it will be in whatever time-zone that particular registry is >>> in... >>> >> I think that if you go ISO way, the 'Z' should be present (if not >> GMT) - at least that what I vaguely remember about this date/time >> spec. >> >> Martin >> >> -- >> Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >> consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From dgpisano at cnb.uam.es Fri Jan 27 12:41:27 2006 From: dgpisano at cnb.uam.es (David Gonzalez Pisano) Date: Fri, 27 Jan 2006 18:41:27 +0100 Subject: [MOBY-dev] I vote YES to RFC 1913 and 1914 Message-ID: <43DA5B47.2020706@cnb.uam.es> As INB representative, my vote is YES to the RFCs 1913 and 1914 David (my laptop has died, sorry for the delay) From senger at ebi.ac.uk Fri Jan 27 23:03:46 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 28 Jan 2006 04:03:46 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: Message-ID: > A question for Martin - does the "milliseconds since epoch" number tell us > which time zone the milliseconds were measured in? > No, it does not. > If not, then the discussion is somewhat moot... > As I said at the beginning, any of these two ways needs to know which time zone is used. The string has advantage that you do not need to parse it (if you want to find its meaning - see further comment on it below), the formatted date has advantage that you see at once - without looking into a separate documentation - what time zone it was created in (because it should always use the 'Z' separator). > value, then maybe we gain something, maybe not (but we shouldn't be coding > as if it did either way, since we're not supposed to interpret LSID fields) > I think that we do not need to be that rigid. If we document what our LSIDs contain, we can still interpret it. LSIDs are here for us, not vice versa :-). The LSID spec says: "The users of the LSIDs are permitted to use individual components (as specified elsewhere in this document) of LSIDs - although the LSID component parts themselves should be treated as opaque pieces of the identifier." So we are permitted to use version, eventhough we are not supposed to interpret it - but as I said rigidness is not an issue here. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 27 23:11:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 Jan 2006 20:11:32 -0800 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: References: Message-ID: I still don't see how the "ms since epoch" option tells us the time-zone... is there a formal way to express this in that string? ...but I also don't see why it is *critical* to know this at all... I guess, formally, if we are going to record time, then we should record it as accurately as possible; however what we are really trying to do here is generate a unique string, not record time... M On Fri, 27 Jan 2006 20:03:46 -0800, Martin Senger wrote: >> A question for Martin - does the "milliseconds since epoch" number tell >> us >> which time zone the milliseconds were measured in? >> > No, it does not. > >> If not, then the discussion is somewhat moot... >> > As I said at the beginning, any of these two ways needs to know which > time zone is used. The string has advantage that you do not need to parse > it (if you want to find its meaning - see further comment on it below), > the formatted date has advantage that you see at once - without looking > into a separate documentation - what time zone it was created in (because > it should always use the 'Z' separator). > >> value, then maybe we gain something, maybe not (but we shouldn't be >> coding >> as if it did either way, since we're not supposed to interpret LSID >> fields) >> > I think that we do not need to be that rigid. If we document what our > LSIDs contain, we can still interpret it. LSIDs are here for us, not vice > versa :-). The LSID spec says: "The users of the LSIDs are permitted to > use individual components (as specified elsewhere in this document) of > LSIDs - although the LSID component parts themselves should be treated as > opaque pieces of the identifier." So we are permitted to use version, > eventhough we are not supposed to interpret it - but as I said rigidness > is not an issue here. > > Cheers, > Martin > From senger at ebi.ac.uk Sat Jan 28 00:50:24 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 28 Jan 2006 05:50:24 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: Message-ID: > I still don't see how the "ms since epoch" option tells us the > time-zone... > It does not. If we use "ms since epoch" we must document it and say "this is ms since epoch in UTC". And in the perl code you will use function 'time' and not 'localtime' (and you will multiply it by 1000 because perl gives you only seconds - unless you use Time:HiRes module). > ...but I also don't see why it is *critical* to know this at all... I > It is not critical. You are right that the critical is only to uniquely identify a version. But as a side-effect we may use this version for findng when an object was registered ( and display it nicely in various clients). In order to do this properly, we need to know what time is used in the version field. > however what we are really trying to do here is generate a unique > string, not record time... > As said above, generating a unique string is important/critical, but if we can in the same time to record time, why not to do it usefully. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Jan 28 01:31:04 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 28 Jan 2006 06:31:04 +0000 GMT Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 Message-ID: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> Well... I'm only arguing for the sake of arguing now, because it's fun! :-) An epoch or a timestamp assumes than the machine is set to the correct time and zone! Though a much rarer case, it isn't impossible... The *fact* is that we cannot trust the timestamp to be correct. But it doesn't matter :-). Let me see how easy it is to extract the TZ from the OS or an environment variable. If it is unreliable over the different OS's I'll just retrieve the epoch and use that as Martin suggests. If I can reliably get the TZ information on all OS's, then I'll add it to the current timestamp. M -----Original Message----- From: Martin Senger Date: Sat, 28 Jan 2006 05:50:24 To:Mark Wilkinson Cc:Core developer announcements Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 > I still don't see how the "ms since epoch" option tells us the > time-zone... > It does not. If we use "ms since epoch" we must document it and say "this is ms since epoch in UTC". And in the perl code you will use function 'time' and not 'localtime' (and you will multiply it by 1000 because perl gives you only seconds - unless you use Time:HiRes module). > ...but I also don't see why it is *critical* to know this at all... I > It is not critical. You are right that the critical is only to uniquely identify a version. But as a side-effect we may use this version for findng when an object was registered ( and display it nicely in various clients). In order to do this properly, we need to know what time is used in the version field. > however what we are really trying to do here is generate a unique > string, not record time... > As said above, generating a unique string is important/critical, but if we can in the same time to record time, why not to do it usefully. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Jan 30 05:04:46 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 30 Jan 2006 10:04:46 +0000 (GMT) Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: <5.2.1.1.2.20060124101843.011d7d00@email.med.harvard.edu> Message-ID: > It would be useful if we could have a link on the website to the POD, > which could also be auto-updated from CVS, so that potential future > users could browse the perl documentation online, without having to > check out the code and run perldoc on it. > Mark, let me know what lines I should add to the cronjob so it generates a perl doc on a proper place (something like using pod2html program I guess). Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Mon Jan 30 08:32:04 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 Jan 2006 14:32:04 +0100 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: References: Message-ID: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Hi all, After quite some time there is finally an updated SOAP::Lite. I never got the BioMOBY stuff working with the previous beta's, so I was stuck on S::L 0.60. But now there is 0.66 and 0.67 was already submitted to CPAN. And 0.68 might be there by the time you read this. It's been a while since the last "stable" versions of S::L and now they are popping up like mushrooms :). Unfortunately they don't work with BioMOBY. I found 2 issues. One of them is clearly a S::L problem, so I mailed to the corresponding list (And for those who are interested, there's a temporary fix in that post as well). For the other one I'm not sure, but I do now it can be fixed easily by a small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem with the WSDL that BioMOBY Central generates. There are several namespaces in this WSDL and on them is prefixed with "soap": $WSDL_TEMPLATE = < etc. As far as I understand it (after browsing the specs for the different versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) the "soap" prefixed namespace is for the SOAP binding described by the WSDL document. Unfortunately when S::L is processing the response from BioMOBY Central it thinks the "soap" prefixed namespace is for the SOAP message eventhough the WSDL is wrapped in a CDATA block. Since this namespace is not the valid one for SOAP version 1.1 or 1.2 S::L complains that the entire response is in an unsupported version of SOAP :(. Either something has to change in S::L, or we change the prefix of the namespace. As far as I understand the prefixes for namespaces are not standardised and could be anything. In lots of examples I found on the net I saw: xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" instead of: xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" So what do the others think. Should this be patched in S::L or can we change the prefix for this namespace from soap to for example wsoap? Cheers, Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From gordonp at ucalgary.ca Mon Jan 30 09:55:40 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 30 Jan 2006 07:55:40 -0700 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> References: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> Message-ID: <43DE28EC.7020002@ucalgary.ca> Actually, when you use ms since the epoch, it doesn't matter what time zone you are in, because the epoch is defined as Jan 1 00:00 Greenwich Mean Time. So if I'm Mountain Standard Time, the epoch was Dec 31 17:00 1969. Any date I calculate today will be set back 7 hours to reflect my time zone, but so is the epoch. Even-Steven. >Well... I'm only arguing for the sake of arguing now, because it's fun! :-) > >An epoch or a timestamp assumes than the machine is set to the correct time and zone! Though a much rarer case, it isn't impossible... The *fact* is that we cannot trust the timestamp to be correct. > >But it doesn't matter :-). Let me see how easy it is to extract the TZ from the OS or an environment variable. If it is unreliable over the different OS's I'll just retrieve the epoch and use that as Martin suggests. If I can reliably get the TZ information on all OS's, then I'll add it to the current timestamp. > >M > > >-----Original Message----- >From: Martin Senger >Date: Sat, 28 Jan 2006 05:50:24 >To:Mark Wilkinson >Cc:Core developer announcements >Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 > > > >>I still don't see how the "ms since epoch" option tells us the >>time-zone... >> >> >> > It does not. If we use "ms since epoch" we must document it and say >"this is ms since epoch in UTC". And in the perl code you will use >function 'time' and not 'localtime' (and you will multiply it by 1000 >because perl gives you only seconds - unless you use Time:HiRes module). > > > >>...but I also don't see why it is *critical* to know this at all... I >> >> >> > It is not critical. You are right that the critical is only to uniquely >identify a version. But as a side-effect we may use this version for >findng when an object was registered ( and display it nicely in various >clients). In order to do this properly, we need to know what time is used >in the version field. > > > >>however what we are really trying to do here is generate a unique >>string, not record time... >> >> >> > As said above, generating a unique string is important/critical, but if >we can in the same time to record time, why not to do it usefully. > > Cheers, > Martin > > > From markw at illuminae.com Mon Jan 30 10:40:12 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 07:40:12 -0800 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <43DE28EC.7020002@ucalgary.ca> References: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> <43DE28EC.7020002@ucalgary.ca> Message-ID: So long as the time zone on your computer is set correctly, that's all I'm saying. What concerns me is that we're pulling our hair out trying to get a number that has some enormous degree of precision when in fact we cannot rely on it anyway, and moreover, we shouldn't even be parsing it out of the string in the first place... M On Mon, 30 Jan 2006 06:55:40 -0800, Paul Gordon wrote: > Actually, when you use ms since the epoch, it doesn't matter what time > zone you are in, because the epoch is defined as Jan 1 00:00 Greenwich > Mean Time. So if I'm Mountain Standard Time, the epoch was Dec 31 17:00 > 1969. Any date I calculate today will be set back 7 hours to reflect my > time zone, but so is the epoch. Even-Steven. > >> Well... I'm only arguing for the sake of arguing now, because it's fun! >> :-) >> >> An epoch or a timestamp assumes than the machine is set to the correct >> time and zone! Though a much rarer case, it isn't impossible... The >> *fact* is that we cannot trust the timestamp to be correct. >> >> But it doesn't matter :-). Let me see how easy it is to extract the TZ >> from the OS or an environment variable. If it is unreliable over the >> different OS's I'll just retrieve the epoch and use that as Martin >> suggests. If I can reliably get the TZ information on all OS's, then >> I'll add it to the current timestamp. >> >> M >> >> >> -----Original Message----- >> From: Martin Senger >> Date: Sat, 28 Jan 2006 05:50:24 >> To:Mark Wilkinson >> Cc:Core developer announcements >> Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 >> >> >> >>> I still don't see how the "ms since epoch" option tells us the >>> time-zone... >>> >>> >>> >> It does not. If we use "ms since epoch" we must document it and say >> "this is ms since epoch in UTC". And in the perl code you will use >> function 'time' and not 'localtime' (and you will multiply it by 1000 >> because perl gives you only seconds - unless you use Time:HiRes module). >> >> >> >>> ...but I also don't see why it is *critical* to know this at all... I >>> >>> >>> >> It is not critical. You are right that the critical is only to >> uniquely >> identify a version. But as a side-effect we may use this version for >> findng when an object was registered ( and display it nicely in various >> clients). In order to do this properly, we need to know what time is >> used >> in the version field. >> >> >> >>> however what we are really trying to do here is generate a unique >>> string, not record time... >>> >>> >>> >> As said above, generating a unique string is important/critical, but >> if >> we can in the same time to record time, why not to do it usefully. >> >> Cheers, >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Jan 30 10:52:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 07:52:40 -0800 Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: References: Message-ID: I don't know of any standard way of dumping POD documentation from a directory tree... I think it would have to be done file-by-file, which isn't a good solution... Does anyone else know of a way? M On Mon, 30 Jan 2006 02:04:46 -0800, Martin Senger wrote: >> It would be useful if we could have a link on the website to the POD, >> which could also be auto-updated from CVS, so that potential future >> users could browse the perl documentation online, without having to >> check out the code and run perldoc on it. >> > Mark, let me know what lines I should add to the cronjob so it > generates a perl doc on a proper place (something like using pod2html > program I guess). > > Thanks, > Martin > From markw at illuminae.com Mon Jan 30 11:03:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 08:03:02 -0800 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Message-ID: Sounds to me like SOAP::Lite is not using namespaces correctly... they're supposed to determine the meaning of the namespace from the document, rather than imposing it on the document. If that interpretation of the problem were true, then the fix should be in S::L, not Moby::Central... Am I mis-interpreting your bug report? I read your post on the SOAP::Lite group - Eddie and I have noticed that error before (though it was in the context of service-instance response errors, not registry errors. I can't recall how we fixed it... it was in mid-october sometime (we were not having the conversation on-list, however...) Eddie, can you go back in time and see what we did to solve the anyURI problem? M On Mon, 30 Jan 2006 05:32:04 -0800, Pieter Neerincx wrote: > Hi all, > > After quite some time there is finally an updated SOAP::Lite. I never > got the BioMOBY stuff working with the previous beta's, so I was > stuck on S::L 0.60. But now there is 0.66 and 0.67 was already > submitted to CPAN. And 0.68 might be there by the time you read this. > It's been a while since the last "stable" versions of S::L and now > they are popping up like mushrooms :). Unfortunately they don't work > with BioMOBY. I found 2 issues. One of them is clearly a S::L > problem, so I mailed to the corresponding list (And for those who are > interested, there's a temporary fix in that post as well). For the > other one I'm not sure, but I do now it can be fixed easily by a > small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem > with the WSDL that BioMOBY Central generates. There are several > namespaces in this WSDL and on them is prefixed with "soap": > > $WSDL_TEMPLATE = < > targetNamespace="http://biomoby.org/Central.wsdl" > xmlns:tns="http://biomoby.org/Central.wsdl" > xmlns:xsd1="http://biomoby.org/CentralXSDs.xsd" > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > xmlns:xsd="http://www.w3.org/1999/XMLSchema" > xmlns="http://schemas.xmlsoap.org/wsdl/" > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> > etc. > > As far as I understand it (after browsing the specs for the different > versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) > the "soap" prefixed namespace is for the SOAP binding described by > the WSDL document. Unfortunately when S::L is processing the response > from BioMOBY Central it thinks the "soap" prefixed namespace is for > the SOAP message eventhough the WSDL is wrapped in a CDATA block. > Since this namespace is not the valid one for SOAP version 1.1 or 1.2 > S::L complains that the entire response is in an unsupported version > of SOAP :(. Either something has to change in S::L, or we change the > prefix of the namespace. As far as I understand the prefixes for > namespaces are not standardised and could be anything. In lots of > examples I found on the net I saw: > xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", > xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or > xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" > instead of: > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > So what do the others think. Should this be patched in S::L or can we > change the prefix for this namespace from soap to for example wsoap? > > Cheers, > > Pieter > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Mon Jan 30 11:06:56 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 30 Jan 2006 17:06:56 +0100 Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: References: Message-ID: <43DE39A0.20903@cnb.uam.es> I haven't done the exercise, but a combination of Pod::Find (http://perldoc.perl.org/Pod/Find.html) and Pod::Html (http://search.cpan.org/~nwclark/perl-5.8.7/lib/Pod/Html.pm) modules could be the answer... Best Regards, Jos? Mar?a Mark Wilkinson wrote: > I don't know of any standard way of dumping POD documentation from a > directory tree... I think it would have to be done file-by-file, which > isn't a good solution... > > Does anyone else know of a way? > > M > > > > On Mon, 30 Jan 2006 02:04:46 -0800, Martin Senger wrote: > >>> It would be useful if we could have a link on the website to the POD, >>> which could also be auto-updated from CVS, so that potential future >>> users could browse the perl documentation online, without having to >>> check out the code and run perldoc on it. >>> >> Mark, let me know what lines I should add to the cronjob so it >> generates a perl doc on a proper place (something like using pod2html >> program I guess). >> >> Thanks, >> Martin >> > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From senger at ebi.ac.uk Mon Jan 30 11:14:31 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 30 Jan 2006 16:14:31 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <43DE28EC.7020002@ucalgary.ca> Message-ID: > Actually, when you use ms since the epoch, it doesn't matter what time > zone you are in, because the epoch is defined as Jan 1 00:00 Greenwich > Mean Time. > Thanks, Paul. This is exactly the answer I was talking about. I said: we have to document what time zone we mean - but now you said that it is already well documented (I did not know it). So the problem solved, I guess. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Mon Jan 30 11:09:57 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 30 Jan 2006 08:09:57 -0800 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new"stable" SOAP::Lite broken... In-Reply-To: Message-ID: <000201c625b7$9e565a20$6700a8c0@notebook> Hi, I think that our problem was solved by modifying the url portion of xmlns="http://www.w3.org/2000/10/XMLSchema" to xmlns:xsd="http://www.w3.org/1999/XMLSchema" Is this the 'fix' you are asking about? Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Mark Wilkinson > Sent: Monday, January 30, 2006 8:03 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Perl API and BioMOBY Central WSDL: > BioMOBY with new"stable" SOAP::Lite broken... > > Sounds to me like SOAP::Lite is not using namespaces > correctly... they're supposed to determine the meaning of the > namespace from the document, rather than imposing it on the document. > > If that interpretation of the problem were true, then the fix > should be in S::L, not Moby::Central... Am I > mis-interpreting your bug report? > > I read your post on the SOAP::Lite group - Eddie and I have > noticed that error before (though it was in the context of > service-instance response errors, not registry errors. I > can't recall how we fixed it... it was in mid-october > sometime (we were not having the conversation on-list, > however...) > > Eddie, can you go back in time and see what we did to solve > the anyURI problem? > > M > > > > > > On Mon, 30 Jan 2006 05:32:04 -0800, Pieter Neerincx > wrote: > > > Hi all, > > > > After quite some time there is finally an updated > SOAP::Lite. I never > > got the BioMOBY stuff working with the previous beta's, so I was > > stuck on S::L 0.60. But now there is 0.66 and 0.67 was already > > submitted to CPAN. And 0.68 might be there by the time you > read this. > > It's been a while since the last "stable" versions of S::L and now > > they are popping up like mushrooms :). Unfortunately they don't work > > with BioMOBY. I found 2 issues. One of them is clearly a S::L > > problem, so I mailed to the corresponding list (And for > those who are > > interested, there's a temporary fix in that post as well). For the > > other one I'm not sure, but I do now it can be fixed easily by a > > small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem > > with the WSDL that BioMOBY Central generates. There are several > > namespaces in this WSDL and on them is prefixed with "soap": > > > > $WSDL_TEMPLATE = < > > > > targetNamespace="http://biomoby.org/Central.wsdl" > > xmlns:tns="http://biomoby.org/Central.wsdl" > > xmlns:xsd1="http://biomoby.org/CentralXSDs.xsd" > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > xmlns:xsd="http://www.w3.org/1999/XMLSchema" > > xmlns="http://schemas.xmlsoap.org/wsdl/" > > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> > > etc. > > > > As far as I understand it (after browsing the specs for the > different > > versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) > > the "soap" prefixed namespace is for the SOAP binding described by > > the WSDL document. Unfortunately when S::L is processing > the response > > from BioMOBY Central it thinks the "soap" prefixed namespace is for > > the SOAP message eventhough the WSDL is wrapped in a CDATA block. > > Since this namespace is not the valid one for SOAP version > 1.1 or 1.2 > > S::L complains that the entire response is in an unsupported version > > of SOAP :(. Either something has to change in S::L, or we change the > > prefix of the namespace. As far as I understand the prefixes for > > namespaces are not standardised and could be anything. In lots of > > examples I found on the net I saw: > > xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", > > xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or > > xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" > > instead of: > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > > > So what do the others think. Should this be patched in S::L > or can we > > change the prefix for this namespace from soap to for example wsoap? > > > > Cheers, > > > > Pieter > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Mon Jan 30 11:21:16 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 30 Jan 2006 16:21:16 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: Message-ID: > So long as the time zone on your computer is set correctly > It has nothing to do with my computer - because you and me have different timezone on our computers, but we do not know what time zones we are using. Just make sure that what you (meaning: your software) put in the version is always well defined (e.g. for elapsed time, use always UTC, for your formatted string put 'Z' and your current - and correct - zone). > What concerns me is that we're pulling our hair > ...c'mon, Mark, this is a trivial issue. Why are you still arguing about it? > a number that has some enormous degree of precision when in fact we cannot > rely on it anyway > ...of course, we can (and we want). Perhaps I don't understand your problem... > and moreover, we shouldn't even be parsing it out of the string in the > first place... > ...that's a low argument. LSID is not a dogma. It is here to help us. Last time I am saying: why not to put there a meaning if it is free and useful. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Mon Jan 30 11:34:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 Jan 2006 17:34:37 +0100 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: References: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> <43DE28EC.7020002@ucalgary.ca> Message-ID: On 30-Jan-2006, at 4:40 PM, Mark Wilkinson wrote: > So long as the time zone on your computer is set correctly, that's > all I'm > saying. What concerns me is that we're pulling our hair out trying > to get > a number that has some enormous degree of precision when in fact we > cannot > rely on it anyway, Depends on how it's implemented. We can have the clients create the version number for the new LSID when they try to register something, but I think it would be better to leave that to BioMOBY Central. I that case only BioMOBY Central needs to be ticking in the correct time (-zone). Clients only need to compare LSIDs. They can be running in the wrong zone without problems for BioMOBY functionality. So the question is can we rely on Mark for keeping BioMOBY Central online with the clock set to the correct time(-zone)? If BioMOBY Central is misconfigured we're all screwed anyway, so adding this additional dependency doesn't worry me. Pi > and moreover, we shouldn't even be parsing it out of > the string in the first place... > > M > > > > On Mon, 30 Jan 2006 06:55:40 -0800, Paul Gordon > wrote: > >> Actually, when you use ms since the epoch, it doesn't matter what >> time >> zone you are in, because the epoch is defined as Jan 1 00:00 >> Greenwich >> Mean Time. So if I'm Mountain Standard Time, the epoch was Dec 31 >> 17:00 >> 1969. Any date I calculate today will be set back 7 hours to >> reflect my >> time zone, but so is the epoch. Even-Steven. >> >>> Well... I'm only arguing for the sake of arguing now, because >>> it's fun! >>> :-) >>> >>> An epoch or a timestamp assumes than the machine is set to the >>> correct >>> time and zone! Though a much rarer case, it isn't impossible... The >>> *fact* is that we cannot trust the timestamp to be correct. >>> >>> But it doesn't matter :-). Let me see how easy it is to extract >>> the TZ >>> from the OS or an environment variable. If it is unreliable over >>> the >>> different OS's I'll just retrieve the epoch and use that as Martin >>> suggests. If I can reliably get the TZ information on all OS's, >>> then >>> I'll add it to the current timestamp. >>> >>> M >>> >>> >>> -----Original Message----- >>> From: Martin Senger >>> Date: Sat, 28 Jan 2006 05:50:24 >>> To:Mark Wilkinson >>> Cc:Core developer announcements >>> Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & >>> 1914 >>> >>> >>> >>>> I still don't see how the "ms since epoch" option tells us the >>>> time-zone... >>>> >>>> >>>> >>> It does not. If we use "ms since epoch" we must document it >>> and say >>> "this is ms since epoch in UTC". And in the perl code you will use >>> function 'time' and not 'localtime' (and you will multiply it by >>> 1000 >>> because perl gives you only seconds - unless you use Time:HiRes >>> module). >>> >>> >>> >>>> ...but I also don't see why it is *critical* to know this at >>>> all... I >>>> >>>> >>>> >>> It is not critical. You are right that the critical is only to >>> uniquely >>> identify a version. But as a side-effect we may use this version for >>> findng when an object was registered ( and display it nicely in >>> various >>> clients). In order to do this properly, we need to know what time is >>> used >>> in the version field. >>> >>> >>> >>>> however what we are really trying to do here is generate a unique >>>> string, not record time... >>>> >>>> >>>> >>> As said above, generating a unique string is important/ >>> critical, but >>> if >>> we can in the same time to record time, why not to do it usefully. >>> >>> Cheers, >>> Martin >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Mon Jan 30 11:53:09 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 Jan 2006 17:53:09 +0100 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Message-ID: On 30-Jan-2006, at 5:03 PM, Mark Wilkinson wrote: > Sounds to me like SOAP::Lite is not using namespaces correctly... > they're > supposed to determine the meaning of the namespace from the document, > rather than imposing it on the document. > > If that interpretation of the problem were true, then the fix > should be in > S::L, not Moby::Central... Am I mis-interpreting your bug report? No I think you got it right. S::L shouldn't mess it up, but I can predict that fixing it by changing the prefix in BioMOBY is much faster than trying to get a fix into the next "stable" release of S::L. So unless changing this namespace prefix causes problems for BioMOBY, we might do it both... Anyone with objections! > > I read your post on the SOAP::Lite group - Eddie and I have noticed > that > error before (though it was in the context of service-instance > response > errors, not registry errors. I can't recall how we fixed it... it > was in > mid-october sometime (we were not having the conversation on-list, > however...) > > Eddie, can you go back in time and see what we did to solve the anyURI > problem? I thought I had it up and running now, but found yet another issue :(. S::L 0.66 and up now encodes <, >, &, etc. in strings. The execute sub in MOBY/Client/Service.pm does it as well: $data =~ s"&"&"g; # encode content in case it has CDATA $data =~ s"\<"<"g; $data =~ s"\]\]\>"\]\]>"g; So now the data is encoded twice resulting in things like: &lt; which makes the parser choke. The simple solution is removing the 3 lines mentioned above, but off course in that case it will no longer work with older versions of S::L and I don't think everyone has already welcomed S::L 0.66+ on their disks. Cheers, Pi > M > > > > > > On Mon, 30 Jan 2006 05:32:04 -0800, Pieter Neerincx > wrote: > >> Hi all, >> >> After quite some time there is finally an updated SOAP::Lite. I never >> got the BioMOBY stuff working with the previous beta's, so I was >> stuck on S::L 0.60. But now there is 0.66 and 0.67 was already >> submitted to CPAN. And 0.68 might be there by the time you read this. >> It's been a while since the last "stable" versions of S::L and now >> they are popping up like mushrooms :). Unfortunately they don't work >> with BioMOBY. I found 2 issues. One of them is clearly a S::L >> problem, so I mailed to the corresponding list (And for those who are >> interested, there's a temporary fix in that post as well). For the >> other one I'm not sure, but I do now it can be fixed easily by a >> small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem >> with the WSDL that BioMOBY Central generates. There are several >> namespaces in this WSDL and on them is prefixed with "soap": >> >> $WSDL_TEMPLATE = <> >> > targetNamespace="http://biomoby.org/Central.wsdl" >> xmlns:tns="http://biomoby.org/Central.wsdl" >> xmlns:xsd1="http://biomoby.org/CentralXSDs.xsd" >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" >> xmlns:xsd="http://www.w3.org/1999/XMLSchema" >> xmlns="http://schemas.xmlsoap.org/wsdl/" >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> >> etc. >> >> As far as I understand it (after browsing the specs for the different >> versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) >> the "soap" prefixed namespace is for the SOAP binding described by >> the WSDL document. Unfortunately when S::L is processing the response >> from BioMOBY Central it thinks the "soap" prefixed namespace is for >> the SOAP message eventhough the WSDL is wrapped in a CDATA block. >> Since this namespace is not the valid one for SOAP version 1.1 or 1.2 >> S::L complains that the entire response is in an unsupported version >> of SOAP :(. Either something has to change in S::L, or we change the >> prefix of the namespace. As far as I understand the prefixes for >> namespaces are not standardised and could be anything. In lots of >> examples I found on the net I saw: >> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", >> xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or >> xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" >> instead of: >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" >> >> So what do the others think. Should this be patched in S::L or can we >> change the prefix for this namespace from soap to for example wsoap? >> >> Cheers, >> >> Pieter >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From simont at hmgc.mcw.edu Mon Jan 30 15:56:55 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Mon, 30 Jan 2006 14:56:55 -0600 Subject: [MOBY-dev] Vote on RFC#1913 #1914 In-Reply-To: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> References: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> Message-ID: <9958A0BC-939B-4EE8-83D2-4B59BA127D0A@hmgc.mcw.edu> Looks good to me. Yes for 1913/14 S. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Jan 26, 2006, at 11:27 AM, Mark Wilkinson wrote: > Could the core voting group please vote on the LSID RFC's over the > weekend, or request changes. > > Thanks! > > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Jan 30 19:51:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 16:51:40 -0800 Subject: [MOBY-dev] Last minute change to RFC1913 Message-ID: <1138668700.27364.67.camel@bioinfo.icapture.ubc.ca> Hiya, I've changed the 1913 RFC such that the timestamp is in GMT (suffixed with a "Z"). At the level of the MOBY::Central code, it is using the following call to generate the timestamp: gmtime(time()) However, the time() function returns different values on Mac vs Windows/*nix OS's (the Epoch is not the same in the Mac world, apparently!) Can someone with a Mac please confirm that the gmtime function in Perl will correctly report GMT on a Mac (or is this problem solved with OS- X?)? I want to be sure that the MOBY Central code is portable, and reporting correctly if we are going to start suggesting that people can actually use this timestamp for anything important. I take it that nobody has any objections in principle to this change? M P.S. to report gmtime(time) in a human-readable form retrieve it as a scalar rather than in list context - print scalar(gmtime(time)) -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Mon Jan 30 20:06:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 17:06:35 -0800 Subject: [MOBY-dev] What with the mobyoch be? Message-ID: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> Any preferences on what the starting timestamp should be for all MOBY entities when I update the database? The "mobyoch" :-) we should make it something creative, since it will have a great deal of legacy (e.g. the "Object" object will probably never get edited...) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Mon Jan 30 23:16:14 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 31 Jan 2006 04:16:14 +0000 (GMT) Subject: [MOBY-dev] Urgent: jMoby does not compile In-Reply-To: <000401c61eb0$ef971090$6500a8c0@notebook> Message-ID: Eddie, Your last commit breaks things. Please do something soon... Thanks, Martin [javac] Found 1 semantic error and issued 1 warning compiling "/home/senger/moby-live/Java/src/main/org/biomoby/shared/extended/ServiceInstanceParser.java": [javac] <------ [javac] 190. service.setAuthoritative(Boolean [javac] 191. .parseBoolean(authoritative)); [javac] -----------------------------------------------------------------------------------> [javac] *** Semantic Error: No accessible method with signature "parseBoolean(java.lang.String)" was found in type "java.lang.Boolean". [javac] 197. String url = resource.getProperty(FetaVocabulary.locationURI) [javac] ^-^ [javac] *** Semantic Warning: Local "url" shadows a field of the same name in "org.biomoby.shared.extended.ServiceInstanceParser". -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Mon Jan 30 23:48:14 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 31 Jan 2006 04:48:14 +0000 (GMT) Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: <43D92134.2060708@ac.uma.es> Message-ID: > Attached to this email you can find the INB proposal (RFC) on > asynchronous service calls. > Thank you for putting together the proposal. I am going to read it thoroughly. But it would help me/us if you give us a planned time schedule when you expect our comments to be back. Could you suggest a sort of deadline please? Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Tue Jan 31 05:48:33 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 31 Jan 2006 11:48:33 +0100 Subject: [MOBY-dev] Last minute change to RFC1913 In-Reply-To: <1138668700.27364.67.camel@bioinfo.icapture.ubc.ca> References: <1138668700.27364.67.camel@bioinfo.icapture.ubc.ca> Message-ID: <3D7456E2-94C1-44F1-85E9-2A7639FD0563@wur.nl> On 31-Jan-2006, at 1:51 AM, Mark Wilkinson wrote: > Hiya, > > I've changed the 1913 RFC such that the timestamp is in GMT (suffixed > with a "Z"). > > At the level of the MOBY::Central code, it is using the following call > to generate the timestamp: > > gmtime(time()) > > However, the time() function returns different values on Mac vs > Windows/*nix OS's (the Epoch is not the same in the Mac world, > apparently!) > > Can someone with a Mac please confirm that the gmtime function in Perl > will correctly report GMT on a Mac (or is this problem solved with OS- > X?)? I want to be sure that the MOBY Central code is portable, and > reporting correctly if we are going to start suggesting that people > can > actually use this timestamp for anything important. Hi Mark, Just checked it on a Mac running OS X. Both time() and gmtime() work exactly the same as on my Linux box :). Remember OS X is a nice custom Apple GUI, but on top of a Free BSD clone. The old OS 9 and before might be a completely different story, but I haven't used it in years :). I don't think there is a single vendor that still supports OS 9, so I don't think we should worry about it either: OS 9 is museum-ware :). Cheers, Pi > > I take it that nobody has any objections in principle to this change? > > M > P.S. to report gmtime(time) in a human-readable form retrieve it as a > scalar rather than in list context - print scalar(gmtime(time)) > > > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jmfernandez at cnb.uam.es Tue Jan 31 08:29:10 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Tue, 31 Jan 2006 14:29:10 +0100 Subject: [MOBY-dev] What with the mobyoch be? In-Reply-To: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> References: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> Message-ID: <43DF6626.5070104@cnb.uam.es> Perhaps the date of the first MOBY DIC? Mark Wilkinson wrote: > Any preferences on what the starting timestamp should be for all MOBY > entities when I update the database? The "mobyoch" :-) > > we should make it something creative, since it will have a great deal of > legacy (e.g. the "Object" object will probably never get edited...) > > M > > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From markw at illuminae.com Tue Jan 31 10:58:22 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 31 Jan 2006 07:58:22 -0800 Subject: [MOBY-dev] What with the mobyoch be? In-Reply-To: <43DF6626.5070104@cnb.uam.es> References: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> <43DF6626.5070104@cnb.uam.es> Message-ID: 2001-09-21T16-00-00Z On Tue, 31 Jan 2006 05:29:10 -0800, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Perhaps the date of the first MOBY DIC? > > Mark Wilkinson wrote: >> Any preferences on what the starting timestamp should be for all MOBY >> entities when I update the database? The "mobyoch" :-) >> >> we should make it something creative, since it will have a great deal of >> legacy (e.g. the "Object" object will probably never get edited...) >> >> M >> >> >> > From markw at illuminae.com Tue Jan 31 20:22:37 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 31 Jan 2006 17:22:37 -0800 Subject: [MOBY-dev] RFC1913 & 1914 passed Message-ID: <1138756957.30488.10.camel@bioinfo.icapture.ubc.ca> Hi all, Just a confirmation that, by my count, 1913 and 1914 have now reached a majority, and so are passed. The initial timestamp (lsid version has been suggested as 2001-09-21T16-00-00Z. That's okay with me unless anyone has objections. I'll do the database update later this week, and will make the update script available in the CVS moby-live/Database folder for others to use. Cheers! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From rroyo at lsi.upc.edu Tue Jan 3 10:01:26 2006 From: rroyo at lsi.upc.edu (rroyo at lsi.upc.edu) Date: Tue, 3 Jan 2006 11:01:26 +0100 (MET) Subject: [MOBY-dev] freefluo-xscufl with collections, upgrading to taverna 1.2, 1.3 Message-ID: <2833313544rroyo@lsi.upc.es> Hello, We need to execute taverna workflows from the command line. We've tried to use freefluo, but we had some trouble.. Although it was possible to launch most of our simple workflows, some of them, which take advantage of features from Taverna 1.2 ( collections ), gave error or simply returned void results. Is there a way to improve freefluo to match the capabilities of Taverna 1.2, or even further? Or does anyone know any other way to execute Taverna workflows from the commandline? Thank you very much! Alexis & Romina, INB From duncan.hull at cs.man.ac.uk Thu Jan 5 15:48:01 2006 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Thu, 05 Jan 2006 15:48:01 +0000 Subject: [MOBY-dev] freefluo-xscufl with collections, executing Taverna workflows from the command line In-Reply-To: <2833313544rroyo@lsi.upc.es> References: <2833313544rroyo@lsi.upc.es> Message-ID: <43BD3FB1.3040702@cs.man.ac.uk> Alexis and Romina This sort of question stands a better chance of being answered on the taverna-hackers mailing list...so I've cc'ed it to that list. Duncan rroyo at lsi.upc.edu wrote: >Hello, > >We need to execute taverna workflows from the command line. We've tried >to use freefluo, but we had some trouble.. >Although it was possible to launch most of our simple workflows, some of >them, which take advantage of features from Taverna 1.2 ( collections ), >gave error or simply returned void results. > >Is there a way to improve freefluo to match the capabilities of Taverna >1.2, or even further? > >Or does anyone know any other way to execute Taverna workflows from the >commandline? > >Thank you very much! > >Alexis & Romina, INB > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev > > > -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From tmo at ebi.ac.uk Thu Jan 5 15:59:13 2006 From: tmo at ebi.ac.uk (Tom Oinn) Date: Thu, 05 Jan 2006 15:59:13 +0000 Subject: [MOBY-dev] [Taverna-hackers] Re: freefluo-xscufl with collections, executing Taverna workflows from the command line In-Reply-To: <43BD3FB1.3040702@cs.man.ac.uk> References: <2833313544rroyo@lsi.upc.es> <43BD3FB1.3040702@cs.man.ac.uk> Message-ID: <43BD4251.2030503@ebi.ac.uk> Duncan Hull wrote: > Alexis and Romina > > This sort of question stands a better chance of being answered on the > taverna-hackers mailing list...so I've cc'ed it to that list. And in fact it _was_ answered in those lists ;) I think it's safe to stop cross posting between moby and taverna lists, the appropriate people are on both. Tom From markw at illuminae.com Tue Jan 10 16:57:10 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 10 Jan 2006 08:57:10 -0800 Subject: [MOBY-dev] RFC #1914 - change & call for vote Message-ID: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> In response to requests from myGrid: mygrid:hasServiceType -> removed because it is redundant to dc:format dc:format -> changed from string literal to ontology term. For MOBY the value has changed from 'moby' to 'BioMoby_service' mygrid:hasOperationNameText -> added as a property of mygrid:operation. String Literal describing the service name. For MOBY services, this is identical to the mygrid:hasServiceNameText since MOBY services can only have one operation. I have made the above changes to the document online. Can we call for a vote on RFC 1913 and 1914 by Monday 16th? M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Wed Jan 11 15:12:09 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 11 Jan 2006 16:12:09 +0100 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: <31AB896A0E7ED211BFBE0008C7283D13DE706C@inibapnt1.inibap.org> References: <31AB896A0E7ED211BFBE0008C7283D13DE706C@inibapnt1.inibap.org> Message-ID: Hi, Hi all, I was wondering if Mathieu's question about the secondaries was already answered? I can not find the answer in my mail archive and am currently running into the same problem. Furthermore: How do I use secondaries in Taverna? Is there documented example somewhere? I couldn't find one. I also looked at the WSDL produced for several services and do see input and output listed, but not the optional secondaries... The MOBY-S API documentation on the new site is a bit limited. I can guess what min, max and default are for, but how do I use enum? Do I simply list all the allowed values? That could become a rather lengthy list for some of my secondaries :). Cheers, Pi On 21-Oct-2005, at 8:09 PM, Rouard, Mathieu (INIBAP - Montpellier) wrote: > Hello, > > I am looking for some guidelines about the xml tags allowed in > secondary > articles. > Until now, I have found those tags in the documentation > > datatype > default > max > min > enum > > Is there a tag allowing to describe the paramater? > I think it would be helpful when the parameter name (or the value > expected) > is clear for the end user of the service. > -- snip -- > > Thanks for your help. > > Cheers, > Mathieu > > -- > Mathieu Rouard > IPGRI-INIBAP < www.inibap.org > > Parc Scientifique Agropolis II > 34397 Montpellier - Cedex 5 - France > Tel: +33 (0)467 61 13 02 > Fax: +33 (0)467 61 03 34 > > > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l 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 Jan 11 15:18:48 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 11 Jan 2006 07:18:48 -0800 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: Message-ID: <000301c616c2$53497f70$6500a8c0@notebook> Hi Pieter, Currently, Taverna does not support secondary parameters. I do plan on adding support at a later date. If you have any thoughts about how secondarys should be added to Taverna (UI), please don't hesitate to let me know so that I can consider your input during the design. Thanks, Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx > Sent: Wednesday, January 11, 2006 7:12 AM > To: mobydev > Subject: Re: [MOBY-dev] [MOBY-l] Tags for secondary articles > > Hi, > Hi all, > > I was wondering if Mathieu's question about the secondaries > was already answered? I can not find the answer in my mail > archive and am currently running into the same problem. > Furthermore: How do I use secondaries in Taverna? Is there > documented example somewhere? I couldn't find one. I also > looked at the WSDL produced for several services and do see > input and output listed, but not the optional secondaries... > The MOBY-S API documentation on the new site is a bit > limited. I can guess what min, max and default are for, but > how do I use enum? Do I simply list all the allowed values? > That could become a rather lengthy list for some of my secondaries :). > > Cheers, > > Pi > > On 21-Oct-2005, at 8:09 PM, Rouard, Mathieu (INIBAP - Montpellier) > wrote: > > > Hello, > > > > I am looking for some guidelines about the xml tags allowed in > > secondary articles. > > Until now, I have found those tags in the documentation > > > > datatype > > default > > max > > min > > enum > > > > Is there a tag allowing to describe the paramater? > > I think it would be helpful when the parameter name (or the value > > expected) > > is clear for the end user of the service. > > > -- snip -- > > > > Thanks for your help. > > > > Cheers, > > Mathieu > > > > -- > > Mathieu Rouard > > IPGRI-INIBAP < www.inibap.org > > > Parc Scientifique Agropolis II > > 34397 Montpellier - Cedex 5 - France > > Tel: +33 (0)467 61 13 02 > > Fax: +33 (0)467 61 03 34 > > > > > > > > _______________________________________________ > > moby-l mailing list > > moby-l at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > > Wageningen University and Research centre (WUR) Laboratory of > Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Wed Jan 11 16:12:04 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 11 Jan 2006 08:12:04 -0800 Subject: [MOBY-dev] RFC #1914 - change & call for vote In-Reply-To: <43C4E45E.8010005@gmail.com> References: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> <43C4E45E.8010005@gmail.com> Message-ID: <43C52E54.702@illuminae.com> Hi Martin, You're right, I should have been more explicit. There were some last minute changes to the RDF model (one predicate removed, one added, and one given a range-change) for a Service Instance that were required to allow it to be reasoned-over by the myGrid registry. I detailed what those changes were in the previous message. The changes had no "semantic" consequence to us v.v. what we are intending to describe with the Service Instance RDF. This is the RDF that is retrieved by the getMetaData call on an LSID representing a service instance, and hence these changes affected the relevant RFC. v.v. your suggested changes, I think I addressed most of them in the version of the RFC that I announced; if you recall, I gave you a preview of the proposals, and you commented on that preview, so I made those modifications before making the public RFC announcement. v.v. what is returned by a getData call on an LSID? This is currently still an open issue. The RFC describes (and is titled) how to retrieve metadata about MOBY entities. What is returned by a getData call can be addressed in another RFC(s) if anyone can think of a useful behaviour in the case of object, namespace, servicetype, and serviceinstance LSID's (collectively or respectively). Since there is no requirement in the LSID specification that an LSID *must* resolve with a getData call, we are not out-of-compliance with the specification by not addressing this right now. My initial thoughts were that, for Object LSID's, we would return the XML Schema of the object, however that turns out to be impossible. I had also thought that we could return the WSDL for a service from a getData call on a Service Instance LSID, however you rejected that idea as being redundant. Since that time, I've had no other ideas, and no other suggestions have been raised, so... it's an open question., but a question that does not prevent us from carrying on with this RFC vote. I will delay the vote until the following Monday (23rd), since I suspect that many people didn't spend their Christmas holidays reading the RFC documents ;-) In the meantime, let's have some debate about this, since it forms the basis for the long-fabled RDF agent registration/deregistration system that is written, but we haven't switched on yet because the RDF itself is still in flux. M Martin Senger wrote: > Mark, > I am sorry that I m dumb but your message is completely cryptic, > and I have no clue what you are suggesting. Could you be please more > verbose? I apologize if i am the only one who do not understand. > >> Can we call for a vote on RFC 1913 and 1914 by Monday 16th? >> > I think that the deadline for (any) voting should be set more then > five days ahead. I know that your RFCs were posted long time ago, but > I have not get any answer from you for my first comments (especially > the one about what getData() method should/could return). > > With regards, > Martin > From senger at ebi.ac.uk Wed Jan 11 16:37:23 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 11 Jan 2006 16:37:23 +0000 (GMT) Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: <000301c616c2$53497f70$6500a8c0@notebook> Message-ID: > If you have any thoughts about how secondarys should be added to Taverna > (UI), please don't hesitate to let me know so that I can consider your input > during the design. > Eddie, I did not want to be pre-mature with my suggestion because it is not yet fully implemented. But this email is an opportunity: I have created a user interface for entering quite complex moby data type (it is a combination of a table and a tree). I plan to use it in Dashboard. But doing that I relized that it would be also very suitable for taverna (perhaps even without a need to have all moby data types listed there in a scavenger list). I still need to finish it - two things are mising: the sceondary parameters - but it's simple, and the ability to add and remove more HAS members. I have already solution for both these things on my laptop but I will not be able to finish and to commit it before next two weeks time (having my family visiting me at Philippines). Please take a look for the so-far commit status by calling a testing client: build/run/run-any-client CreateMobyInput -h build/run/run-any-client CreateMobyInput -data \ -cachedir In Taverna, the -cachedit functionality will be replced by reading the RDf document with moby data types (as it is now). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Wed Jan 11 16:39:35 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Wed, 11 Jan 2006 08:39:35 -0800 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: Message-ID: <000401c616cd$9c1eaa80$6500a8c0@notebook> Thanks Martin, I will look at it soon. Eddie > -----Original Message----- > From: Martin Senger [mailto:senger at ebi.ac.uk] > Sent: Wednesday, January 11, 2006 8:37 AM > To: Edward Kawas > Cc: 'Core developer announcements' > Subject: Re: [MOBY-dev] [MOBY-l] Tags for secondary articles > > > If you have any thoughts about how secondarys should be added to > > Taverna (UI), please don't hesitate to let me know so that I can > > consider your input during the design. > > > Eddie, I did not want to be pre-mature with my suggestion > because it is not yet fully implemented. But this email is an > opportunity: I have created a user interface for entering > quite complex moby data type (it is a combination of a table > and a tree). I plan to use it in Dashboard. But doing that I > relized that it would be also very suitable for taverna > (perhaps even without a need to have all moby data types > listed there in a scavenger list). I still need to finish it > - two things are mising: the sceondary parameters - but it's > simple, and the ability to add and remove more HAS members. I > have already solution for both these things on my laptop but > I will not be able to finish and to commit it before next two > weeks time (having my family visiting me at Philippines). > Please take a look for the so-far commit status by calling a > testing client: > > build/run/run-any-client CreateMobyInput -h > build/run/run-any-client CreateMobyInput -data \ > -cachedir > > In Taverna, the -cachedit functionality will be replced by > reading the RDf document with moby data types (as it is now). > > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > From martin.senger at gmail.com Wed Jan 11 10:56:30 2006 From: martin.senger at gmail.com (Martin Senger) Date: Wed, 11 Jan 2006 18:56:30 +0800 Subject: [MOBY-dev] RFC #1914 - change & call for vote In-Reply-To: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> References: <1136912230.11404.22.camel@bioinfo.icapture.ubc.ca> Message-ID: <43C4E45E.8010005@gmail.com> Mark, I am sorry that I m dumb but your message is completely cryptic, and I have no clue what you are suggesting. Could you be please more verbose? I apologize if i am the only one who do not understand. > Can we call for a vote on RFC 1913 and 1914 by Monday 16th? > I think that the deadline for (any) voting should be set more then five days ahead. I know that your RFCs were posted long time ago, but I have not get any answer from you for my first comments (especially the one about what getData() method should/could return). With regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Thu Jan 12 10:31:40 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Thu, 12 Jan 2006 11:31:40 +0100 Subject: [MOBY-dev] [MOBY-l] Tags for secondary articles In-Reply-To: <000301c616c2$53497f70$6500a8c0@notebook> References: <000301c616c2$53497f70$6500a8c0@notebook> Message-ID: <2B1A8814-6493-4245-9273-E8F6466D8845@wur.nl> Hi Eddie, Thanks for the - as ususal - quick feedback! Support for secondary articles would be welcome :). For the implementation I think secondaries could be treated similar to primary inputs. To me secondaries are simply optional inputs without has or hasa relationships. I'm not sure wether it can also be implemented that simple though ... Cheers, Pi On 11Jan2006, at 16:18, Edward Kawas wrote: > Hi Pieter, > > Currently, Taverna does not support secondary parameters. I do plan on > adding support at a later date. > > If you have any thoughts about how secondarys should be added to > Taverna > (UI), please don't hesitate to let me know so that I can consider > your input > during the design. > > Thanks, > > Eddie > >> -----Original Message----- >> From: moby-dev-bounces at biomoby.org >> [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx >> Sent: Wednesday, January 11, 2006 7:12 AM >> To: mobydev >> Subject: Re: [MOBY-dev] [MOBY-l] Tags for secondary articles >> >> Hi, >> Hi all, >> >> I was wondering if Mathieu's question about the secondaries >> was already answered? I can not find the answer in my mail >> archive and am currently running into the same problem. >> Furthermore: How do I use secondaries in Taverna? Is there >> documented example somewhere? I couldn't find one. I also >> looked at the WSDL produced for several services and do see >> input and output listed, but not the optional secondaries... >> The MOBY-S API documentation on the new site is a bit >> limited. I can guess what min, max and default are for, but >> how do I use enum? Do I simply list all the allowed values? >> That could become a rather lengthy list for some of my >> secondaries :). >> >> Cheers, >> >> Pi >> >> On 21-Oct-2005, at 8:09 PM, Rouard, Mathieu (INIBAP - Montpellier) >> wrote: >> >>> Hello, >>> >>> I am looking for some guidelines about the xml tags allowed in >>> secondary articles. >>> Until now, I have found those tags in the documentation >>> >>> datatype >>> default >>> max >>> min >>> enum >>> >>> Is there a tag allowing to describe the paramater? >>> I think it would be helpful when the parameter name (or the value >>> expected) >>> is clear for the end user of the service. >>> >> -- snip -- >>> >>> Thanks for your help. >>> >>> Cheers, >>> Mathieu >>> >>> -- >>> Mathieu Rouard >>> IPGRI-INIBAP < www.inibap.org > >>> Parc Scientifique Agropolis II >>> 34397 Montpellier - Cedex 5 - France >>> Tel: +33 (0)467 61 13 02 >>> Fax: +33 (0)467 61 03 34 >>> >>> >>> >>> _______________________________________________ >>> moby-l mailing list >>> moby-l at biomoby.org >>> http://biomoby.org/mailman/listinfo/moby-l >> >> >> Wageningen University and Research centre (WUR) Laboratory of >> Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From senger at ebi.ac.uk Fri Jan 13 07:44:59 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 13 Jan 2006 07:44:59 +0000 (GMT) Subject: [MOBY-dev] RFC #1914 - change & call for vote In-Reply-To: <43C52E54.702@illuminae.com> Message-ID: Mark, Many thanks for the explanation. > v.v. your suggested changes, I think I addressed most of them in the > version of the RFC that I announced; if you recall, I gave you a preview > of the proposals, and you commented on that preview, so I made those > modifications before making the public RFC announcement. > No doubts about it, yes you did. But getData() were of the few not addressed and they are very impotant for me and perhaps for others (see more below). > v.v. what is returned by a getData call on an LSID? This is currently > still an open issue. The RFC describes (and is titled) how to retrieve > metadata about MOBY entities. > Well, there are two RFCs (1913 and 1914) and they both are related to LSIDs, so it is perhaps wise to discuss them both, or to merge them together, before we start voting on any of them. > What is returned by a getData call can be addressed in another RFC(s) > if anyone can think of a useful behaviour in the case of object, > namespace, servicetype, and serviceinstance LSID's (collectively or > respectively). > I definitely think about a useful behaviour (we discussed in with Ediie already in summer in Malaga). And the behaviour is very important - can make the real and immediate impact on the moby use, so I would like to see it on the table soon, whatever RFC issue to use it for. Here is what we spoke about with Eddit (slightly updated by the development of Dashboard): Practically all general moby clients need to have access to all data types (and perhaps also to all service instances). This is a consequence of the moby design, and I do not argue that. Examples are: Taverna, Ahab (I guess), Moses, Moby Graphs. (Anti-example is , I think, gbrowse that works differently.) Because of that, these clients rapidly move to RDF resources because that way they get all information faster. But still not fast enough. That's why I started to use local cache in Moses/Dasboard and in few other clients. The local cache needs, however, ability to be updated and synchronize with its moby registry. At the moment, it is possible to recognize completely new entries (and download them), or deleted entries (and remove them). But without re-loading the whole ontology it is not possible to recognize that a moby entity is of a newer version (such that somebody deregistered a service and registered it again slighly changed). But we have LSIDs for all moby entities already! So I would like to use it. Actually, I do not need to use getData(), but I need to have version in the LSIDs. But once you start to add a version there, you almost automatically imply what should be returned by getData() - because you need to know what represents a version. So I think that version should be assigned whenever a moby entity of the same name (and authority, etc.) is registered. I do not ask to keep all versions (simply the old LSIDs will not be resolvable if somebody asked for it - and its metadata may point to its latest version). Having versions in LSIDs can make a real impact on all clients using cache - and they can significantly help users. I can imagine Taverna starting like a breezy for biomoby. In jMoby, we have already software doing cacheing, and we can easily improve it to take versions into account. I also plan (in February) to reease for windows users a "package" (using commercial softawre InstallAnywhere) with some of jMoby software (especially Dashboard with a simple client for service invocation) and a snapshot of a moby registry. So normal users (not developers, and not Taverna users) will have finally one-stop to take everything - and having advanced caching there (advanced = using versions) would be a perfect. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 13 17:00:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 09:00:35 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: <1137171635.11074.29.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-01-13 at 07:44 +0000, Martin Senger wrote: > But once you start to add a version there, you almost > automatically imply what should be returned by getData() - because you > need to know what represents a version. ...almost automatically imply what should be returned... but not explicitly enough for my tiny brain :-) Explicitly, what do you want getData to return? Other than this confusion, I agree with most observations in your message, on first reading. Versioning of LSID's creates added complexity at the database end of things (since we need to keep track of all objects that have been deleted... forever!), but we are all familiar with these complexities and I guess there's no way around it once you start using the LSID standard. What isn't clear to me, however, is how this solves the problem that you are saying it will solve. If you have cached the RDF for all objects locally, how does a versioned LSID save you any time? It seems that it would actually make things *slower*, since it is then necessary to resolve every individual LSID to see if it were still up-to-date, rather than simply loading the entire ontology from scratch. Am I misunderstanding how you intend to use the versioned LSID? (Maybe if I understood what you are expecting getData to return, it will be obvious to me how it fixes the problem?) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Fri Jan 13 22:51:35 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 13 Jan 2006 22:51:35 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <1137171635.11074.29.camel@bioinfo.icapture.ubc.ca> Message-ID: > ...almost automatically imply what should be returned... but not > explicitly enough for my tiny brain :-) Explicitly, what do you want > getData to return? > Your brain is fine - I actually did not say what to return. :-) The idea is that if you put a version to something, you know to what you are putting it, so you know what could be returned by getData(). But let me step back a bit: I started to talk about getData() and finished by talking about versioning. I admit that these two topics are closely related but they do not need to be solved both in the same time. What I really wish to have (sooner the better) is versioning. > Versioning of LSID's creates added complexity at the database end of > things (since we need to keep track of all objects that have been > deleted... forever!) > Yes and no. Definitely, some complexity must be added, but not perhaps that much. Because we do not need to return old objects - we can just refuse to resolve them. LSID spec does not allow to reuse the same LSID for something else, but does not require to resolve data with old version forever. So, for example, my naive implementation would be soemthing like this (I am probably still missing some situations): * add columns "version" and "active" to moby entities, * when a moby entity is being registered, find if you have it already in database with the flag "active" set to false: - if yes, update its version (and replace all other fields with the new registration data), - if not, create a new record, set "version" to 1 and "active" to true, * when an entity is being deregistered, set its "active" to false", * when to return entities, return only "active" once. (I guess that you can optimize by keping old (unregistered) entities in a separate table just with their last-used version number - this will substitute the "active" flag.) (Or, perhaps much better and simpler: just assign time of registration as a version field - so everytime you register an entity it gets new version. This seems the bestsolution... where is the catch? Is there any?) > What isn't clear to me, however, is how this solves the problem that you > are saying it will solve. If you have cached the RDF for all objects > locally, how does a versioned LSID save you any time? > The RDF is not fine grained - one RDF document contains, for example, all data types. But I want to get only one data type - in case I know that this data type has been changed. Perhapd the best explanation is to tell you how the current caching works in jMoby: For each type of entities (data types, service types, services and namespace) I keep one file (called "list") with all their names (and their LSIDs). When a user want to update a cache, these files are always created newly from a registry (there are four API methods to get them; eventhough it would be faster to have one method for getting all of them in one go, but that's another story). Then, the caching software reads the list and compare what it has in local cache. The entities that are in local cache but not in the list are removed from the local cache. The entities that are in the list but not in the local cache are aksed for (by a normal API call for one entity). But, this mechanism cannot recognize if an existing entity was changed. If the LSIDs have versions, the caching mechanism can also compare the LSIDs of the local entities and those in the list - and when the version in the list is newer, it can fetch the updated version. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 13 23:29:52 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 15:29:52 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: <1137194992.11875.34.camel@bioinfo.icapture.ubc.ca> On Fri, 2006-01-13 at 22:51 +0000, Martin Senger wrote: > > Versioning of LSID's creates added complexity at the database end of > > things (since we need to keep track of all objects that have been > > deleted... forever!) > > > Yes and no. Definitely, some complexity must be added, but not perhaps > that much. I guess I was thinking exactly along the lines of your "active" flag - even inactive objects need to be stored forever. I admit, I was over- playing the complexity of that ;-) > (Or, perhaps much better and simpler: just assign time of registration as > a version field - so everytime you register an entity it gets new > version. This seems the bestsolution... where is the catch? Is there any?) I was also thinking along these lines. So long as our tooling never *shows* the version number to the user (or at least, not unless they ask for it), then it really doesn't matter how comlpex the version number format is. I don't know if adding a timestamp is any more complex than incrementing a version number... but it might be more informative?? > The RDF is not fine grained - one RDF document contains, for example, > all data types. But I want to get only one data type - in case I know that > this data type has been changed. Perhapd the best explanation is to tell > you how the current caching works in jMoby: I see - so jMoby would not automatically know about any newly registered objects unless you explicitly asked for a refresh of the entire RDF; however you WOULD be guaranteed of always having the latest version of whatever object you were working with, because as soon as you "selected" it, that PARTICULAR object would be validated against the registry. Is that correct? That all sounds great! Do you want to write up an addition to the RFC? (we still don't know what you want to be returned by a getData call - you are keeping us in suspense! ;-) ) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Sat Jan 14 00:04:17 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 14 Jan 2006 00:04:17 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <1137194992.11875.34.camel@bioinfo.icapture.ubc.ca> Message-ID: > I was also thinking along these lines. So long as our tooling never > *shows* the version number to the user (or at least, not unless they ask > for it), then it really doesn't matter how comlpex the version number > format is. I don't know if adding a timestamp is any more complex than > incrementing a version number... but it might be more informative?? > Timestamp can be a number of elapsed second/millisecond from the beginning of an epoche. So it is a long integer - not that different from a usual version number. Important is that it is always the same unless/until the entity is re-registered. Incrementing a version number is more complex than timestamp because in order to increment you need to know an old value (that will be incremented). With a timestamp you do not need to keep unregistered objects at all. You need just to add a new column "timestamp" and fill it with the current time when an object is registered. And to add this "timestamp" field as version to the created LSID. That seems all you need to do (but perhaps I am still missing some catch). > I see - so jMoby would not automatically know about any newly registered > objects unless you explicitly asked for a refresh of the entire RDF; > (Almost) correct. jMoby (its caching mechanism) does not know about any newly registered objects automatically, the user has to ask for update (the "user" can be, however, a cron job, or whatever). But for refreshing, jMoby does not use RDF - but it asks for a list of entities using normal API call (such as getServiceNames - or whatever the method is called, I can't remember now). There is no such RDF document to give me "only" a list of object names (and I am not asking for that, the API is fine). > however you WOULD be guaranteed of always having the latest version of > whatever object you were working with, because as soon as you "selected" > it, that PARTICULAR object would be validated against the registry. Is > that correct? > Yes, it could be done this way. The "selection" can trigger the update mechanism. But it does not - the users (of dashboard, for example) have to click on a button 'update' if they feel that their cache is not up-to-date. This does not seem to be a problem in the real life. > Do you want to write up an addition to the RFC? > Well, adding a version number to the LSIDs is not really a change that needs an RFC I guess. It is just making current existing features better - and without breaking existing software. I would suggest that you just ask Eddie to add versioning and then you both can announce it as a improved feature. I would really love it to have - and I can at once make use of it in Dashboard (and slightly later, and with coordination with Eddie, in Taverna). > (we still don't know what you want to be returned by a getData call - > you are keeping us in suspense! ;-) ) > I said: I am stepping back a bit. Talk about getData() brought me to versioning - and that's what I wish to have. Forget getData() for now :-) (Mainly because what I would return by getData() is identical to what normal old-fashioned moby API calls do quite well now (such as retrieveObjectDefinition()) ). Martin PS. TW, Mylah from IRRI is just finishing her mirroring scripts (to regularly update our local/testing GCP registry from the central one) - and she would definitely welcome the versions as well - mirroring is just another example (additional to my local caching usage) where LSIDs with versions would be tremendously and immediately useful. M. -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Sat Jan 14 02:17:52 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 14 Jan 2006 02:17:52 +0000 (GMT) Subject: [MOBY-dev] error handling in MoSeS Message-ID: I have implemented (thanks to Ivan Garcia from MMB in Spain) the new biomoby error handling in Moses. In your implementation classes, now you can add exceptions and they will appear in their proper place in the service notes. As far as I know, the changes I have done do not break any existing code. Well, except if you still send to a new Moses-based service an old XML with something like this: ABCD the text ABCD will be simply ignored. (Note that the new way how to incorporate human-readable message in service notes is: ABCD.) I have also updated the Moses documentation concerning with error handling. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Jan 14 03:39:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 19:39:48 -0800 Subject: [MOBY-dev] error handling in MoSeS In-Reply-To: References: Message-ID: <43C87284.5010709@illuminae.com> Martin you totally rock! Give us a couple of weeks to catch up on the Perl side of things - poor Eddie is re-writing a large portion of my code to give it the same architecture and API as the Java modules, so it is taking a while. He's also writing the Perl plugin to dashboard, and making a trip down to TAIR next week to help them get started MOBYing, so he's a busy fellow! I think it is about time to start writing "the big manuscript" with all the core developers as authors... Martin, do you want to include tools like Dashboard in this publication, or are you planning to write an independent publication (or both?). I'm thinking that I still may be able to get the gbrowse_moby interface published as an application note or something like that. It isn't very powerful, but the interesting part of it from the CS point of view is how the rendering system works - it strikes me as being a very sensible way to deal with MOBY object data in a world where you can never predict what data you are going to have in-hand... though it may no longer be novel enough to be publishable. I should have written that paper years ago... >>sigh<< Anyway, I'm going to start on the "big" manuscript but I will no doubt be asking for the various key parties to describe their own contributions, so please keep an eye on your inboxes for paragraph requests! Cheers all! M Martin Senger wrote: >I have implemented (thanks to Ivan Garcia from MMB in Spain) the new >biomoby error handling in Moses. In your implementation classes, now you >can add exceptions and they will appear in their proper place in the >service notes. > As far as I know, the changes I have done do not break any existing >code. Well, except if you still send to a new Moses-based service an old >XML with something like this: > ABCD >the text ABCD will be simply ignored. (Note that the new way how to >incorporate human-readable message in service notes is: > ABCD.) > > I have also updated the Moses documentation concerning with error >handling. > > Cheers, > Martin > > > From senger at ebi.ac.uk Sat Jan 14 03:47:01 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 14 Jan 2006 03:47:01 +0000 (GMT) Subject: [MOBY-dev] error handling in MoSeS In-Reply-To: <43C87284.5010709@illuminae.com> Message-ID: > Eddie is re-writing a large portion of my code to give it the same > architecture and API as the Java modules > Yes, I know - he is frequently in touch with me. And I am supposed to contribute to this Perl code in the beginning of February, as well! > the core developers as authors... Martin, do you want to include tools > like Dashboard in this publication, or are you planning to write an > independent publication (or both?). > It would nice to include Moses/Dashboard there. Tell me (in due time) what I can do for it. I am planning to introduce Moses/Dashboard (and perhaps other tools used in GCP) in BOSC 2006 (if it happens) - but it hopefully will not prevent to participate in your "big manuscript" - will it not? Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Jan 14 04:02:56 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 13 Jan 2006 20:02:56 -0800 Subject: [MOBY-dev] error handling in MoSeS In-Reply-To: References: Message-ID: <43C877F0.9060401@illuminae.com> Martin Senger wrote: >>Eddie is re-writing a large portion of my code to give it the same >>architecture and API as the Java modules >> >> >> > Yes, I know - he is frequently in touch with me. And I am supposed to >contribute to this Perl code in the beginning of February, as well! > > > Excellent! I'm so pleased that you are remaining as involved in MOBY development as you always have been - many thanks to you, and to Richard for your ongoing support and enthusiasm! M From Pieter.Neerincx at wur.nl Tue Jan 17 19:38:04 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 17 Jan 2006 20:38:04 +0100 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> Hi Martin, So far I really like your idea for versioning of the LSIDs and a timestamp is fine. Basically I wouldn't care what exact version number I am working with. The only thing most of us will care about is whether the LSID is up to date. Major and minor version number increments are more something for a marketing department to make a difference in free updates and payed upgrades :). I do think you should write a small update for the RFC though. It's important we all know what exactly those new versioned LSIDs will look like. Will it be ...MyObject_timestamp, ...MyObject:timestamp, or .... and what is the format of your timestamp. It doesn't really matter which format it will be as long as we all know what it looks like. Therefore it should be written down somewhere and preferably documented on the BioMOBY website. One thing I was wondering about is the following: If a service is registered, we specify the input and output. Lets say for example I register service A with as input a simple Object SomeObject_version1. Some time later somebody else decides to update SomeObject, maybe for something as simple as a typo in the description. The up-to-date version of SomeObject now becomes SomeObject_version2. What happens to my service? Do I have to reregister it with SomeObject_version2 as input? SomeObject_version1 is no longer "available", so my service is registered with an outdated => not LSID resolvable => invalid input .... Another thing I was wondering about is relationships. What happens if I have SomeObject_v1 hasa AnotherObject_v1 and AnotherObject is updated? If this happens SomeObject has a child that is no longer LSID resolvable => no longer valid. I guess the parent will need to be updated too, or am I missing something? Currently the object ontology in BioMOBY Central is still rather flat, but when a lot of objects with a complex structures are registered, updating one object might result in updating half the registry, because of all the relationships.... Cheers, Pi On 14-Jan-2006, at 1:04 AM, Martin Senger wrote: >> I was also thinking along these lines. So long as our tooling never >> *shows* the version number to the user (or at least, not unless >> they ask >> for it), then it really doesn't matter how comlpex the version number >> format is. I don't know if adding a timestamp is any more complex >> than >> incrementing a version number... but it might be more informative?? >> > Timestamp can be a number of elapsed second/millisecond from the > beginning of an epoche. So it is a long integer - not that > different from > a usual version number. Important is that it is always the same > unless/until the entity is re-registered. > Incrementing a version number is more complex than timestamp > because in > order to increment you need to know an old value (that will be > incremented). With a timestamp you do not need to keep unregistered > objects at all. You need just to add a new column "timestamp" and > fill it > with the current time when an object is registered. And to add this > "timestamp" field as version to the created LSID. That seems all > you need > to do (but perhaps I am still missing some catch). > >> I see - so jMoby would not automatically know about any newly >> registered >> objects unless you explicitly asked for a refresh of the entire RDF; >> > (Almost) correct. jMoby (its caching mechanism) does not know > about any > newly registered objects automatically, the user has to ask for update > (the "user" can be, however, a cron job, or whatever). But for > refreshing, > jMoby does not use RDF - but it asks for a list of entities using > normal > API call (such as getServiceNames - or whatever the method is > called, I > can't remember now). There is no such RDF document to give me "only" a > list of object names (and I am not asking for that, the API is fine). > >> however you WOULD be guaranteed of always having the latest >> version of >> whatever object you were working with, because as soon as you >> "selected" >> it, that PARTICULAR object would be validated against the >> registry. Is >> that correct? >> > Yes, it could be done this way. The "selection" can trigger the > update > mechanism. But it does not - the users (of dashboard, for example) > have to > click on a button 'update' if they feel that their cache is not > up-to-date. This does not seem to be a problem in the real life. > >> Do you want to write up an addition to the RFC? >> > Well, adding a version number to the LSIDs is not really a > change that > needs an RFC I guess. It is just making current existing features > better - > and without breaking existing software. I would suggest that you > just ask > Eddie to add versioning and then you both can announce it as a > improved > feature. I would really love it to have - and I can at once make > use of it > in Dashboard (and slightly later, and with coordination with Eddie, in > Taverna). > >> (we still don't know what you want to be returned by a getData call - >> you are keeping us in suspense! ;-) ) >> > I said: I am stepping back a bit. Talk about getData() brought > me to > versioning - and that's what I wish to have. Forget getData() for > now :-) > (Mainly because what I would return by getData() is identical to > what > normal old-fashioned moby API calls do quite well now (such as > retrieveObjectDefinition()) ). > > Martin > > PS. TW, Mylah from IRRI is just finishing her mirroring scripts (to > regularly update our local/testing GCP registry from the central > one) - > and she would definitely welcome the versions as well - mirroring > is just > another example (additional to my local caching usage) where LSIDs > with > versions would be tremendously and immediately useful. M. > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Jan 17 20:55:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 Jan 2006 12:55:40 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> References: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> Message-ID: <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> On Tue, 2006-01-17 at 20:38 +0100, Pieter Neerincx wrote: > I do think you > should write a small update for the RFC though. Martin and I agreed offline that I would do this update - after Wednesday when I have finished lecturing for the week. > It's important we all > know what exactly those new versioned LSIDs will look like. Will it > be ...MyObject_timestamp, ...MyObject:timestamp It will follow the proper LSID format, where the version is after teh final ':' urn:lsid:some.organization.urn:namespace:id:version > it will be as long as we all know what it looks like. Therefore it > should be written down somewhere and preferably documented on the > BioMOBY website. I will do that shortly - as an addendum to teh RFC for discussion. > Some time later somebody else decides to update SomeObject, maybe for > something as simple as a typo in the description. They cannot. MOBY Central will not allow this to happen (at least in its current codebase). An ontology term that is being used by a service CANNOT be deleted or modified. > Another thing I was wondering about is relationships. What happens if > I have SomeObject_v1 hasa AnotherObject_v1 and AnotherObject is > updated? Also cannot happen. An object that is being used in the definition of another object cannot be modified or deleted. Both of these cases are tested and enforced at the code level. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From Pieter.Neerincx at wur.nl Tue Jan 17 23:06:06 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Wed, 18 Jan 2006 00:06:06 +0100 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> References: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> Message-ID: Hi Mark, Looks like the RFC is getting a solid proposal. Looking forward to the final one :). On 17Jan2006, at 21:55, Mark Wilkinson wrote: > On Tue, 2006-01-17 at 20:38 +0100, Pieter Neerincx wrote: > >> Some time later somebody else decides to update SomeObject, maybe for >> something as simple as a typo in the description. > > They cannot. MOBY Central will not allow this to happen (at least in > its current codebase). An ontology term that is being used by a > service > CANNOT be deleted or modified. Hmmm true. Maybe this is getting a bit to theoretical. I have to admit I have never tried this before, but what if you deregister the service fist. Nobody checks if it's me who is deregistering my service or somebody else. After that it would be possible to update the object (or deregister the old one and register the new version). Is that possible? >> Another thing I was wondering about is relationships. What happens if >> I have SomeObject_v1 hasa AnotherObject_v1 and AnotherObject is >> updated? > > Also cannot happen. An object that is being used in the definition of > another object cannot be modified or deleted. Same thing. What about deleting the childs first, then the parent and afterwards reregistering the whole bunch (childs first of course). Pi > > Both of these cases are tested and enforced at the code level. > > M > > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Tue Jan 17 23:53:20 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 17 Jan 2006 15:53:20 -0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> <1137531340.23498.11.camel@bioinfo.icapture.ubc.ca> Message-ID: <1137542000.1730.29.camel@bioinfo.icapture.ubc.ca> On Wed, 2006-01-18 at 00:06 +0100, Pieter Neerincx wrote: > if you deregister the > service fist. If an object has nothing depending on it, then it is available for deregistration and potential re-registration. Note that this excludes the possibility that you mentioned, which is that a service can be "tricked" by someone changing the object definition. > Nobody checks if it's me who is deregistering my > service or somebody else. SSSSHHSHHhhhhh!! Don't say that too loudly! :-) This is *exactly* the reason we are moving to an agent-based deregistration system. It will be impossible for someone else to deregister your service. > Same thing. What about deleting the childs first, then the parent and > afterwards reregistering the whole bunch (childs first of course). Yes, that's possible... but it doesn't matter. If nothing is using an object, then you can't do any harm by changing its definition... and you can't change the definition if something is using it. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Sat Jan 21 06:43:10 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 21 Jan 2006 06:43:10 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: <56B53127-7926-4F6B-8D01-C5C924090FA7@wur.nl> Message-ID: Hi, Thanks for supporting the idea of having version in LSIDs. I think that Mark answered all your questions. Just perhaps one small explanation: > registered, we specify the input and output. Lets say for example I > register service A with as input a simple Object SomeObject_version1. > Your assumption here is not correct: a service is not registered as having a simple Object SomeObject_version1, but as having a simple Object SomeObject. We are not proposing to use version in registration - we are registering data types by their names (not by their LSIDs). Versions in LSIDs are good for finding that the object itself was or was not re-registerd (and therefore perhap changed). Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From jmfernandez at cnb.uam.es Mon Jan 23 16:19:21 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Mon, 23 Jan 2006 17:19:21 +0100 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation Message-ID: <43D50209.2000308@cnb.uam.es> Hi everybody, I have been browsing the developers documentation hanging on the (now not so) new BioMOBY web site, and I have realized that there is no information about serviceNotes and ProvisionInformation tags! Ye olde documentation contained that information (snif, snif). Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From edward.kawas at gmail.com Mon Jan 23 16:30:13 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 23 Jan 2006 08:30:13 -0800 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <43D50209.2000308@cnb.uam.es> Message-ID: <000101c6203a$4c3b3b20$6b00a8c0@notebook> Hi Jose Maria, The documentation is there, somewhere (I cant seem to connect to the site right now ...). In the cvs, the file is ObjectStructure.html. Hope this helps, Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > Fern?ndez > Sent: Monday, January 23, 2006 8:19 AM > To: mobydev > Subject: [MOBY-dev] BioMOBY web doesn't contain documentation > about serviceNotes and ProvisionInformation > > Hi everybody, > I have been browsing the developers documentation > hanging on the (now not so) new BioMOBY web site, and I have > realized that there is no information about serviceNotes and > ProvisionInformation tags! Ye olde documentation contained > that information (snif, snif). > > Best Regards, > Jos? Mar?a > -- > Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > Grupo de Dise?o de Proteinas Protein Design Group > Centro Nacional de Biotecnolog?a National Center of Biotechnology > C.P.: 28049 Zip Code: 28049 > C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > (Spain) _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Mon Jan 23 18:25:23 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Mon, 23 Jan 2006 19:25:23 +0100 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <000101c6203a$4c3b3b20$6b00a8c0@notebook> References: <000101c6203a$4c3b3b20$6b00a8c0@notebook> Message-ID: <43D51F93.2090602@cnb.uam.es> Thanks Eddie! I have found where you told the documentation about ProvisionInformation (I didn't see it, I'm blind!) ... ... but serviceNotes information is still missing. Best Regards, Jos? Mar?a Edward Kawas wrote: > Hi Jose Maria, > > The documentation is there, somewhere (I cant seem to connect to the site > right now ...). > > In the cvs, the file is ObjectStructure.html. > > Hope this helps, > > Eddie > > >>-----Original Message----- >>From: moby-dev-bounces at biomoby.org >>[mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a >>Fern?ndez >>Sent: Monday, January 23, 2006 8:19 AM >>To: mobydev >>Subject: [MOBY-dev] BioMOBY web doesn't contain documentation >>about serviceNotes and ProvisionInformation >> >>Hi everybody, >> I have been browsing the developers documentation >>hanging on the (now not so) new BioMOBY web site, and I have >>realized that there is no information about serviceNotes and >>ProvisionInformation tags! Ye olde documentation contained >>that information (snif, snif). >> >> Best Regards, >> Jos? Mar?a >>-- >>Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es >>Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 >>Grupo de Dise?o de Proteinas Protein Design Group >>Centro Nacional de Biotecnolog?a National Center of Biotechnology >>C.P.: 28049 Zip Code: 28049 >>C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid >>(Spain) _______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-dev > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From francis_gibbons at hms.harvard.edu Mon Jan 23 22:38:08 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Mon, 23 Jan 2006 17:38:08 -0500 Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <43D51F93.2090602@cnb.uam.es> References: <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> Message-ID: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Jos? Mar?a, Part of the reason it was missing is that there was so little to say, until the Exception reporting RFC. From the moby-live/Docs/MOBY-S_API/MessageStructure.html documentation file: "The serviceNotes block is only loosely defined in this version of the API, and is currently meant to contain human-readable freetext. serviceNotes are optional. " That's pretty much all one could say until recently, so it's hard to find any mention of it unless you grep all the files. What are your plans for integrating the exception-reporting into the main codebase? Will it be Java first, Java only, or Perl? The Provision Information Block (PIB) is mentioned in ObjectStructure.html, again a one-liner. As the code begins to reflect the implementation of the Exception-RFC, we should add documentation to reflect that. Mark, there's also the question of how the website gets updated. The best way to do it in my view, would be to have the website updated nightly and automatically to reflect the documentation (both from static HTML) for the non-language-specific parts of the API, and also from the POD/javadoc in the language-specific parts. Seems like it shouldn't be too hard to run it from cron, nor take too long to run (perhaps we could even do it hourly, instead of daily?). -Frank At 01:25 PM 1/23/2006, you wrote: >Thanks Eddie! > > I have found where you told the documentation about >ProvisionInformation (I didn't see it, I'm blind!) ... > >... but serviceNotes information is still missing. > > Best Regards, > Jos? Mar?a > >Edward Kawas wrote: > > Hi Jose Maria, > > > > The documentation is there, somewhere (I cant seem to connect to the site > > right now ...). > > > > In the cvs, the file is ObjectStructure.html. > > > > Hope this helps, > > > > Eddie > > > > > >>-----Original Message----- > >>From: moby-dev-bounces at biomoby.org > >>[mailto:moby-dev-bounces at biomoby.org] On Behalf Of Jos? Mar?a > >>Fern?ndez > >>Sent: Monday, January 23, 2006 8:19 AM > >>To: mobydev > >>Subject: [MOBY-dev] BioMOBY web doesn't contain documentation > >>about serviceNotes and ProvisionInformation > >> > >>Hi everybody, > >> I have been browsing the developers documentation > >>hanging on the (now not so) new BioMOBY web site, and I have > >>realized that there is no information about serviceNotes and > >>ProvisionInformation tags! Ye olde documentation contained > >>that information (snif, snif). > >> > >> Best Regards, > >> Jos? Mar?a > >>-- > >>Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es > >>Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 > >>Grupo de Dise?o de Proteinas Protein Design Group > >>Centro Nacional de Biotecnolog?a National Center of Biotechnology > >>C.P.: 28049 Zip Code: 28049 > >>C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid > >>(Spain) _______________________________________________ > >>MOBY-dev mailing list > >>MOBY-dev at biomoby.org > >>http://biomoby.org/mailman/listinfo/moby-dev > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > >-- >Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es >Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 >Grupo de Dise?o de Proteinas Protein Design Group >Centro Nacional de Biotecnolog?a National Center of Biotechnology >C.P.: 28049 Zip Code: 28049 >C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Mon Jan 23 22:41:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 23 Jan 2006 14:41:36 -0800 Subject: [MOBY-dev] [moby] Re: BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> References: <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> On Mon, 2006-01-23 at 17:38 -0500, Frank Gibbons wrote: > Mark, there's also the question of how the website gets updated. The best > way to do it in my view, would be to have the website updated nightly and > automatically to reflect the documentation (both from static HTML) for the > non-language-specific parts of the API, and also from the POD/javadoc in > the language-specific parts. Seems like it shouldn't be too hard to run it > from cron, nor take too long to run (perhaps we could even do it hourly, > instead of daily?). I think both of these things are being done hourly already... or?? AFAIK Martin has a cron running that rebuilds the javadoc, and the same cron runs a script that does a CVS update of the general docuentation part of the site If this isn't working, let me know. M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Mon Jan 23 23:24:48 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 23 Jan 2006 15:24:48 -0800 Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition Message-ID: <1138058688.17515.96.camel@bioinfo.icapture.ubc.ca> Hi all, v.v. LSID versioning - I've put together code that handles LSID versioning in the follwing way: Namespaces, Objects, ServiceTypes, and ServiceInstances all get an LSID exactly as before, with the addition of a Version field (as defined in the LSID spec a ":" followed by the version number). The version format I'm going with is very similar to a full ISO 8601 timestamp, except that it replaces the ":" between the hour, min, sec with "-" as follows: yyyy-mm-ddThh-mm-ss For example: urn:lsid:biomoby.org:objectclass:Object:2006-01-23T12-01-59 ***** Since this is an update to the RFC, can anyone with an interest please give me a "yes" or a "no" on this new format? We aren't committed to it, it was just for my own testing purposes ***** I've also written a script that, I think, should update any registry database such that all LSID's in all tables are identically timestamped (since the LSID is often used in the database as the primary key!) ****** Is anyone dependent on the main registry being funny functional this week? Once I hear back from people v.v. this change to the RFC, I'd like to run the script on the main registry. Chances are this will go smoothly, but I will have to take it down for a few minutes while I do the update, so if anyone is critically depending on it being active please let me know. ****** Cheers all! Mark -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Tue Jan 24 06:11:16 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 23 Jan 2006 22:11:16 -0800 Subject: [MOBY-dev] The Canadian Elections & MOBY funding Message-ID: We have just had a significant change in government in Canada - the election was today. The extreme-right won a minority government! I don't know how/if this will change the funding for MOBY here in Canada, but it might... Stay tuned! The proverb "may you live in interesting times" is definitely applicable tonight! Mark From francis_gibbons at hms.harvard.edu Tue Jan 24 15:27:02 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 24 Jan 2006 10:27:02 -0500 Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060124101843.011d7d00@email.med.harvard.edu> Mark, Can't speak for the javadoc, but updating the online API docs from CVS appears to work. I checked in a slight modification to one of the files at 6pm yesterday. When I checked at 9pm that evening, the modification was visible on the website, so I think we can assume that it's being done hourly. Martin doesn't do things by halves, so I assume the rest is workign too - nice job, Martin. It would be useful if we could have a link on the website to the POD, which could also be auto-updated from CVS, so that potential future users could browse the perl documentation online, without having to check out the code and run perldoc on it. I'll work on making the API documentation look more integrated into the website, and try to provide better navigation so that the various pages are easier to see/find. On a related note, when I type "servicenotes" or "provision" into the search widget and hit the button, I get back "Error 404 - not found". In fact, I just realised that even searching for "MOBY" returns this - could the search utility possibly be mis-configured? Search would be a useful feature, particularly until we can get the docs more organised, but even afterwards too. -Frank At 05:41 PM 1/23/2006, you wrote: >On Mon, 2006-01-23 at 17:38 -0500, Frank Gibbons wrote: > > > Mark, there's also the question of how the website gets updated. The best > > way to do it in my view, would be to have the website updated nightly and > > automatically to reflect the documentation (both from static HTML) for the > > non-language-specific parts of the API, and also from the POD/javadoc in > > the language-specific parts. Seems like it shouldn't be too hard to run it > > from cron, nor take too long to run (perhaps we could even do it hourly, > > instead of daily?). > >I think both of these things are being done hourly already... or?? > >AFAIK Martin has a cron running that rebuilds the javadoc, and the same >cron runs a script that does a CVS update of the general docuentation >part of the site > >If this isn't working, let me know. > >M > > > >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From Pieter.Neerincx at wur.nl Tue Jan 24 20:47:03 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 24 Jan 2006 21:47:03 +0100 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote In-Reply-To: References: Message-ID: Hi Martin, On 21Jan2006, at 07:43, Martin Senger wrote: > Hi, > Thanks for supporting the idea of having version in LSIDs. > I think that Mark answered all your questions. Just perhaps one > small > explanation: > >> registered, we specify the input and output. Lets say for example I >> register service A with as input a simple Object SomeObject_version1. >> > Your assumption here is not correct: a service is not registered as > having a simple Object SomeObject_version1, but as having a simple > Object > SomeObject. We are not proposing to use version in registration - > we are > registering data types by their names (not by their LSIDs). > Versions in > LSIDs are good for finding that the object itself was or was not > re-registerd (and therefore perhap changed). Thanks for the explanation. This wasn't clear to me yet, so I made some wrong assumptions. Leaving the LSIDs and therefore version numbers out for the objects when registering services makes life much easier :). Bring on the version numbered LSIDs! Pi > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From m.anacleto at cgiar.org Wed Jan 25 09:15:21 2006 From: m.anacleto at cgiar.org (Anacleto, Mylah Rystie (IRRI)) Date: Wed, 25 Jan 2006 17:15:21 +0800 Subject: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote Message-ID: Hi, We have a local registry, I followed the steps on how to create/populate the database and am expecting that the contents of our db now contains the same datatypes, service types, namespaces, services as in moby central. I am running a script that mirrors the moby central database (also regularly updates our local registry here at IRRI). Since the db has just been refreshed, I expect no discrepancies(the script traps discrepancies in LSIDs, IDs, inputs, outputs, etc..) but I did get a lot reported with different LSIDs. I am still looking into it but I guess it's not the mirroring program. Must be the dump perl script? (java api has one that calls the perl dump script and that's the one I used) Thanks, Mylah -----Original Message----- From: moby-dev-bounces at biomoby.org [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Pieter Neerincx Sent: Wednesday, January 25, 2006 4:47 AM To: Core developer announcements Subject: Re: [MOBY-dev] [moby] Re: RFC #1914 - change & call for vote Hi Martin, On 21Jan2006, at 07:43, Martin Senger wrote: > Hi, > Thanks for supporting the idea of having version in LSIDs. > I think that Mark answered all your questions. Just perhaps one > small > explanation: > >> registered, we specify the input and output. Lets say for example I >> register service A with as input a simple Object SomeObject_version1. >> > Your assumption here is not correct: a service is not registered as > having a simple Object SomeObject_version1, but as having a simple > Object > SomeObject. We are not proposing to use version in registration - > we are > registering data types by their names (not by their LSIDs). > Versions in > LSIDs are good for finding that the object itself was or was not > re-registerd (and therefore perhap changed). Thanks for the explanation. This wasn't clear to me yet, so I made some wrong assumptions. Leaving the LSIDs and therefore version numbers out for the objects when registering services makes life much easier :). Bring on the version numbered LSIDs! Pi > Cheers, > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1038 Dreijenlaan 3 6703 HA Wageningen phone: 0317-484 706 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev From francis_gibbons at hms.harvard.edu Thu Jan 26 15:57:33 2006 From: francis_gibbons at hms.harvard.edu (Frank Gibbons) Date: Thu, 26 Jan 2006 10:57:33 -0500 Subject: [MOBY-dev] Updated MOBY-S API docs on website In-Reply-To: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> References: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <000101c6203a$4c3b3b20$6b00a8c0@notebook> <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20060126105252.06db0258@email.med.harvard.edu> Just FYI: I updated the MOBY API docs somewhat last night, they're now visible on the MOBY website. I did notice some small glitches in the style, which I've corrected but not yet checked in. Still, I'd appreciated feedback on what's been done so far. At this point, there is little new content, but at least I think it's becoming easier to find what you need. -Frank At 05:41 PM 1/23/2006, you wrote: >On Mon, 2006-01-23 at 17:38 -0500, Frank Gibbons wrote: > > > Mark, there's also the question of how the website gets updated. The best > > way to do it in my view, would be to have the website updated nightly and > > automatically to reflect the documentation (both from static HTML) for the > > non-language-specific parts of the API, and also from the POD/javadoc in > > the language-specific parts. Seems like it shouldn't be too hard to run it > > from cron, nor take too long to run (perhaps we could even do it hourly, > > instead of daily?). > >I think both of these things are being done hourly already... or?? > >AFAIK Martin has a cron running that rebuilds the javadoc, and the same >cron runs a script that does a CVS update of the general docuentation >part of the site > >If this isn't working, let me know. > >M > > > >-- >-- >...his last words were 'Hey guys! Watch this!' >-- >Mark Wilkinson >Asst. Professor >Dept. of Medical Genetics >University of British Columbia >PI in Bioinformatics >iCAPTURE Centre >St. Paul's Hospital >Rm. 166, 1081 Burrard St. >Vancouver, BC, V6Z 1Y6 >tel: 604 682 2344 x62129 >fax: 604 806 9274 > >"For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. >What's happened now is that the conduit has become so big and interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://biomoby.org/mailman/listinfo/moby-dev PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From markw at illuminae.com Thu Jan 26 17:27:03 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Jan 2006 09:27:03 -0800 Subject: [MOBY-dev] Vote on RFC#1913 #1914 Message-ID: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> Could the core voting group please vote on the LSID RFC's over the weekend, or request changes. Thanks! M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Thu Jan 26 19:38:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Jan 2006 11:38:40 -0800 Subject: [MOBY-dev] I vote YES to RFC 1913 & 1914 Message-ID: <1138304320.23818.1.camel@bioinfo.icapture.ubc.ca> :-) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From johan at ac.uma.es Thu Jan 26 19:21:24 2006 From: johan at ac.uma.es (Johan Karlsson) Date: Thu, 26 Jan 2006 20:21:24 +0100 Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal Message-ID: <43D92134.2060708@ac.uma.es> Dear all, First of all, let me introduce myself. My name is Johan Karlsson and I work at the Department of Computer Architecture at the University of M?laga, Spain within the group GNV-5 (part of the Spanish organization INB). Our group deals with different aspects of "Integrated Bioinformatics" at the INB. Attached to this email you can find the INB proposal (RFC) on asynchronous service calls. This proposal is a result of discussions during the INB meeting in M?laga during July 2005 with the participation of Martin Senger and Edward Kawas and further discussions in the INB mailing lists. Kind regards, Johan Karlsson Department of Computer Architecture University of M?laga johan at ac.uma.es -------------- next part -------------- A non-text attachment was scrubbed... Name: BioMOBY Asynchronous Service Call Proposal.pdf Type: application/pdf Size: 182904 bytes Desc: not available URL: From senger at ebi.ac.uk Fri Jan 27 00:57:44 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 00:57:44 +0000 (GMT) Subject: [MOBY-dev] BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <5.2.1.1.2.20060123172950.0114fe20@email.med.harvard.edu> Message-ID: > any mention of it unless you grep all the files. What are your plans for > integrating the exception-reporting into the main codebase? Will it be Java > first, Java only, or Perl? > jMoby (at least the part that generate Moses-based service skeletons) has done it. It is also documented in the javadoc (see, for example: http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/API/org/biomoby/shared/parser/ServiceException.html. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Fri Jan 27 01:00:36 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Thu, 26 Jan 2006 17:00:36 -0800 Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition In-Reply-To: References: Message-ID: On Thu, 26 Jan 2006 16:52:04 -0800, Martin Senger wrote: > I am happy with your versioning. But if I choose I would choose just a > number of elapsed milisecond from the beginning of epoch (1/1/1970). This > would prevent of need to parse the formatted string in version (if one > decides to do so - I know that LSIDs are opaque :-)). :-) Yes, they are! I'm easy either way - I thought it would be nice to put it in ISO format just so that people could easily see the approximate date the object/service was created "by eye", but I suspect that there will be few opportunities for someone to actually SEE a MOBY LSID, so that may not be a big benefit. Does anyone else have an opinion? I'm not fussy... > It also prevents a > need to specify what format the string is in. > But this is only a detail. Having versions in any format is the most > important. > In both alternatives (ISO 8601 or ellapsed time), however, we need to > say what timezone the date is in, I guess. I guess it will be in whatever time-zone that particular registry is in... but since LSID's are supposed to be opaque, we shouldn't be worrying about it ;-) M From senger at ebi.ac.uk Fri Jan 27 00:54:55 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 00:54:55 +0000 (GMT) Subject: [MOBY-dev] [moby] Re: BioMOBY web doesn't contain documentation about serviceNotes and ProvisionInformation In-Reply-To: <1138056096.17515.81.camel@bioinfo.icapture.ubc.ca> Message-ID: > I think both of these things are being done hourly already... or?? > Yes, that's correct. If anybody sees that something is not beig updated please let me know and I will look at it. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Jan 27 00:52:04 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 00:52:04 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition In-Reply-To: <1138058688.17515.96.camel@bioinfo.icapture.ubc.ca> Message-ID: Mark, Thanks for doing this. I was not on-line this week and I am reading my mailbox from the bottom - so perhaps later I will find some reactions to your plans (I apologize if I am suggesting now things that had been already decided and solved). I am happy with your versioning. But if I choose I would choose just a number of elapsed milisecond from the beginning of epoch (1/1/1970). This would prevent of need to parse the formatted string in version (if one decides to do so - I know that LSIDs are opaque :-)). It also prevents a need to specify what format the string is in. But this is only a detail. Having versions in any format is the most important. In both alternatives (ISO 8601 or ellapsed time), however, we need to say what timezone the date is in, I guess. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Jan 27 01:34:13 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 01:34:13 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's and brief registry outages during transition In-Reply-To: Message-ID: > I guess it will be in whatever time-zone that particular registry is > in... > I think that if you go ISO way, the 'Z' should be present (if not GMT) - at least that what I vaguely remember about this date/time spec. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Fri Jan 27 01:31:18 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 27 Jan 2006 01:31:18 +0000 (GMT) Subject: [MOBY-dev] Vote on RFC#1913 #1914 In-Reply-To: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> Message-ID: I vote YES on both 1913/14. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Thu Jan 26 23:15:12 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Thu, 26 Jan 2006 15:15:12 -0800 Subject: [MOBY-dev] I vote YES to RFC 1913 & 1914 In-Reply-To: <1138304320.23818.1.camel@bioinfo.icapture.ubc.ca> Message-ID: <000c01c622ce$5ed71880$7666a8c0@notebook> Eddie From jmfernandez at cnb.uam.es Fri Jan 27 11:29:05 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez?=) Date: Fri, 27 Jan 2006 12:29:05 +0100 Subject: [MOBY-dev] Versioning of LSID's and brief registry outagesduring transition In-Reply-To: References: Message-ID: <43DA0401.8010007@cnb.uam.es> Hi everybody, AFAICR Z is the 'separator' for the timezone. MOBY services are spread over the world, so timestamps should be referenced to UTC. Best Regards, Jos? Mar?a Martin Senger wrote: >> I guess it will be in whatever time-zone that particular registry is >> in... >> > I think that if you go ISO way, the 'Z' should be present (if not > GMT) - at least that what I vaguely remember about this date/time spec. > > Martin > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From Pieter.Neerincx at wur.nl Fri Jan 27 13:07:29 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Fri, 27 Jan 2006 14:07:29 +0100 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: References: Message-ID: <7A5B61FB-EFD2-44AC-9A23-550E5F4CF90A@wur.nl> From the W3C profile of the ISO-8601 specification: "This profile defines two ways of handling time zone offsets: 1. Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator ("Z"). 2. Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of "+hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates that the date/time uses a local time zone which is "hh" hours and "mm" minutes behind UTC. A standard referencing this profile should permit one or both of these ways of handling time zone offsets. Examples 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 1994-11-05T13:15:30Z corresponds to the same instant." So we should choose whether to permit time in UTC (with the "Z"), time in local time (+/-hh:mm) or both... I don't have any specific preference for either of the two but I guess supporting only one of them makes lief easier as compared to supporting both. Whatever the choice is I vote YES on both RFC 1913 and 1914. Cheers, Pieter. On 27-Jan-2006, at 2:34 AM, Martin Senger wrote: >> I guess it will be in whatever time-zone that particular registry is >> in... >> > I think that if you go ISO way, the 'Z' should be present (if not > GMT) - at least that what I vaguely remember about this date/time > spec. > > Martin > > -- > Martin Senger > email: martin.senger at gmail.com > skype: martinsenger > consulting for: > International Rice Research Institute > Biometrics and Bioinformatics Unit > DAPO BOX 7777, Metro Manila > Philippines, phone: +63-2-580-5600 (ext.2324) > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From markw at illuminae.com Fri Jan 27 16:03:13 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 Jan 2006 08:03:13 -0800 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <7A5B61FB-EFD2-44AC-9A23-550E5F4CF90A@wur.nl> References: <7A5B61FB-EFD2-44AC-9A23-550E5F4CF90A@wur.nl> Message-ID: A question for Martin - does the "milliseconds since epoch" number tell us which time zone the milliseconds were measured in? If not, then the discussion is somewhat moot... All we're trying to generate is a unique string. If that unique string has some interpretable value, then maybe we gain something, maybe not (but we shouldn't be coding as if it did either way, since we're not supposed to interpret LSID fields) M On Fri, 27 Jan 2006 05:07:29 -0800, Pieter Neerincx wrote: > From the W3C profile of the ISO-8601 specification: > "This profile defines two ways of handling time zone offsets: > > 1. Times are expressed in UTC (Coordinated Universal Time), with a > special UTC designator ("Z"). > 2. Times are expressed in local time, together with a time zone > offset in hours and minutes. A time zone offset of "+hh:mm" indicates > that the date/time uses a local time zone which is "hh" hours and > "mm" minutes ahead of UTC. A time zone offset of "-hh:mm" indicates > that the date/time uses a local time zone which is "hh" hours and > "mm" minutes behind UTC. > A standard referencing this profile should permit one or both of > these ways of handling time zone offsets. > > Examples > > 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 > am, US Eastern Standard Time. > > 1994-11-05T13:15:30Z corresponds to the same instant." > > So we should choose whether to permit time in UTC (with the "Z"), > time in local time (+/-hh:mm) or both... I don't have any specific > preference for either of the two but I guess supporting only one of > them makes lief easier as compared to supporting both. Whatever the > choice is I vote YES on both RFC 1913 and 1914. > > Cheers, > > Pieter. > > > On 27-Jan-2006, at 2:34 AM, Martin Senger wrote: > >>> I guess it will be in whatever time-zone that particular registry is >>> in... >>> >> I think that if you go ISO way, the 'Z' should be present (if not >> GMT) - at least that what I vaguely remember about this date/time >> spec. >> >> Martin >> >> -- >> Martin Senger >> email: martin.senger at gmail.com >> skype: martinsenger >> consulting for: >> International Rice Research Institute >> Biometrics and Bioinformatics Unit >> DAPO BOX 7777, Metro Manila >> Philippines, phone: +63-2-580-5600 (ext.2324) >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From dgpisano at cnb.uam.es Fri Jan 27 17:41:27 2006 From: dgpisano at cnb.uam.es (David Gonzalez Pisano) Date: Fri, 27 Jan 2006 18:41:27 +0100 Subject: [MOBY-dev] I vote YES to RFC 1913 and 1914 Message-ID: <43DA5B47.2020706@cnb.uam.es> As INB representative, my vote is YES to the RFCs 1913 and 1914 David (my laptop has died, sorry for the delay) From senger at ebi.ac.uk Sat Jan 28 04:03:46 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 28 Jan 2006 04:03:46 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: Message-ID: > A question for Martin - does the "milliseconds since epoch" number tell us > which time zone the milliseconds were measured in? > No, it does not. > If not, then the discussion is somewhat moot... > As I said at the beginning, any of these two ways needs to know which time zone is used. The string has advantage that you do not need to parse it (if you want to find its meaning - see further comment on it below), the formatted date has advantage that you see at once - without looking into a separate documentation - what time zone it was created in (because it should always use the 'Z' separator). > value, then maybe we gain something, maybe not (but we shouldn't be coding > as if it did either way, since we're not supposed to interpret LSID fields) > I think that we do not need to be that rigid. If we document what our LSIDs contain, we can still interpret it. LSIDs are here for us, not vice versa :-). The LSID spec says: "The users of the LSIDs are permitted to use individual components (as specified elsewhere in this document) of LSIDs - although the LSID component parts themselves should be treated as opaque pieces of the identifier." So we are permitted to use version, eventhough we are not supposed to interpret it - but as I said rigidness is not an issue here. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Jan 28 04:11:32 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 27 Jan 2006 20:11:32 -0800 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: References: Message-ID: I still don't see how the "ms since epoch" option tells us the time-zone... is there a formal way to express this in that string? ...but I also don't see why it is *critical* to know this at all... I guess, formally, if we are going to record time, then we should record it as accurately as possible; however what we are really trying to do here is generate a unique string, not record time... M On Fri, 27 Jan 2006 20:03:46 -0800, Martin Senger wrote: >> A question for Martin - does the "milliseconds since epoch" number tell >> us >> which time zone the milliseconds were measured in? >> > No, it does not. > >> If not, then the discussion is somewhat moot... >> > As I said at the beginning, any of these two ways needs to know which > time zone is used. The string has advantage that you do not need to parse > it (if you want to find its meaning - see further comment on it below), > the formatted date has advantage that you see at once - without looking > into a separate documentation - what time zone it was created in (because > it should always use the 'Z' separator). > >> value, then maybe we gain something, maybe not (but we shouldn't be >> coding >> as if it did either way, since we're not supposed to interpret LSID >> fields) >> > I think that we do not need to be that rigid. If we document what our > LSIDs contain, we can still interpret it. LSIDs are here for us, not vice > versa :-). The LSID spec says: "The users of the LSIDs are permitted to > use individual components (as specified elsewhere in this document) of > LSIDs - although the LSID component parts themselves should be treated as > opaque pieces of the identifier." So we are permitted to use version, > eventhough we are not supposed to interpret it - but as I said rigidness > is not an issue here. > > Cheers, > Martin > From senger at ebi.ac.uk Sat Jan 28 05:50:24 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Sat, 28 Jan 2006 05:50:24 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: Message-ID: > I still don't see how the "ms since epoch" option tells us the > time-zone... > It does not. If we use "ms since epoch" we must document it and say "this is ms since epoch in UTC". And in the perl code you will use function 'time' and not 'localtime' (and you will multiply it by 1000 because perl gives you only seconds - unless you use Time:HiRes module). > ...but I also don't see why it is *critical* to know this at all... I > It is not critical. You are right that the critical is only to uniquely identify a version. But as a side-effect we may use this version for findng when an object was registered ( and display it nicely in various clients). In order to do this properly, we need to know what time is used in the version field. > however what we are really trying to do here is generate a unique > string, not record time... > As said above, generating a unique string is important/critical, but if we can in the same time to record time, why not to do it usefully. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From markw at illuminae.com Sat Jan 28 06:31:04 2006 From: markw at illuminae.com (mark wilkinson) Date: Sat, 28 Jan 2006 06:31:04 +0000 GMT Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 Message-ID: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> Well... I'm only arguing for the sake of arguing now, because it's fun! :-) An epoch or a timestamp assumes than the machine is set to the correct time and zone! Though a much rarer case, it isn't impossible... The *fact* is that we cannot trust the timestamp to be correct. But it doesn't matter :-). Let me see how easy it is to extract the TZ from the OS or an environment variable. If it is unreliable over the different OS's I'll just retrieve the epoch and use that as Martin suggests. If I can reliably get the TZ information on all OS's, then I'll add it to the current timestamp. M -----Original Message----- From: Martin Senger Date: Sat, 28 Jan 2006 05:50:24 To:Mark Wilkinson Cc:Core developer announcements Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 > I still don't see how the "ms since epoch" option tells us the > time-zone... > It does not. If we use "ms since epoch" we must document it and say "this is ms since epoch in UTC". And in the perl code you will use function 'time' and not 'localtime' (and you will multiply it by 1000 because perl gives you only seconds - unless you use Time:HiRes module). > ...but I also don't see why it is *critical* to know this at all... I > It is not critical. You are right that the critical is only to uniquely identify a version. But as a side-effect we may use this version for findng when an object was registered ( and display it nicely in various clients). In order to do this properly, we need to know what time is used in the version field. > however what we are really trying to do here is generate a unique > string, not record time... > As said above, generating a unique string is important/critical, but if we can in the same time to record time, why not to do it usefully. Cheers, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson ...on the road! From senger at ebi.ac.uk Mon Jan 30 10:04:46 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 30 Jan 2006 10:04:46 +0000 (GMT) Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: <5.2.1.1.2.20060124101843.011d7d00@email.med.harvard.edu> Message-ID: > It would be useful if we could have a link on the website to the POD, > which could also be auto-updated from CVS, so that potential future > users could browse the perl documentation online, without having to > check out the code and run perldoc on it. > Mark, let me know what lines I should add to the cronjob so it generates a perl doc on a proper place (something like using pod2html program I guess). Thanks, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Mon Jan 30 13:32:04 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 Jan 2006 14:32:04 +0100 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: References: Message-ID: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Hi all, After quite some time there is finally an updated SOAP::Lite. I never got the BioMOBY stuff working with the previous beta's, so I was stuck on S::L 0.60. But now there is 0.66 and 0.67 was already submitted to CPAN. And 0.68 might be there by the time you read this. It's been a while since the last "stable" versions of S::L and now they are popping up like mushrooms :). Unfortunately they don't work with BioMOBY. I found 2 issues. One of them is clearly a S::L problem, so I mailed to the corresponding list (And for those who are interested, there's a temporary fix in that post as well). For the other one I'm not sure, but I do now it can be fixed easily by a small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem with the WSDL that BioMOBY Central generates. There are several namespaces in this WSDL and on them is prefixed with "soap": $WSDL_TEMPLATE = < etc. As far as I understand it (after browsing the specs for the different versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) the "soap" prefixed namespace is for the SOAP binding described by the WSDL document. Unfortunately when S::L is processing the response from BioMOBY Central it thinks the "soap" prefixed namespace is for the SOAP message eventhough the WSDL is wrapped in a CDATA block. Since this namespace is not the valid one for SOAP version 1.1 or 1.2 S::L complains that the entire response is in an unsupported version of SOAP :(. Either something has to change in S::L, or we change the prefix of the namespace. As far as I understand the prefixes for namespaces are not standardised and could be anything. In lots of examples I found on the net I saw: xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" instead of: xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" So what do the others think. Should this be patched in S::L or can we change the prefix for this namespace from soap to for example wsoap? Cheers, Pieter Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From gordonp at ucalgary.ca Mon Jan 30 14:55:40 2006 From: gordonp at ucalgary.ca (Paul Gordon) Date: Mon, 30 Jan 2006 07:55:40 -0700 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> References: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> Message-ID: <43DE28EC.7020002@ucalgary.ca> Actually, when you use ms since the epoch, it doesn't matter what time zone you are in, because the epoch is defined as Jan 1 00:00 Greenwich Mean Time. So if I'm Mountain Standard Time, the epoch was Dec 31 17:00 1969. Any date I calculate today will be set back 7 hours to reflect my time zone, but so is the epoch. Even-Steven. >Well... I'm only arguing for the sake of arguing now, because it's fun! :-) > >An epoch or a timestamp assumes than the machine is set to the correct time and zone! Though a much rarer case, it isn't impossible... The *fact* is that we cannot trust the timestamp to be correct. > >But it doesn't matter :-). Let me see how easy it is to extract the TZ from the OS or an environment variable. If it is unreliable over the different OS's I'll just retrieve the epoch and use that as Martin suggests. If I can reliably get the TZ information on all OS's, then I'll add it to the current timestamp. > >M > > >-----Original Message----- >From: Martin Senger >Date: Sat, 28 Jan 2006 05:50:24 >To:Mark Wilkinson >Cc:Core developer announcements >Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 > > > >>I still don't see how the "ms since epoch" option tells us the >>time-zone... >> >> >> > It does not. If we use "ms since epoch" we must document it and say >"this is ms since epoch in UTC". And in the perl code you will use >function 'time' and not 'localtime' (and you will multiply it by 1000 >because perl gives you only seconds - unless you use Time:HiRes module). > > > >>...but I also don't see why it is *critical* to know this at all... I >> >> >> > It is not critical. You are right that the critical is only to uniquely >identify a version. But as a side-effect we may use this version for >findng when an object was registered ( and display it nicely in various >clients). In order to do this properly, we need to know what time is used >in the version field. > > > >>however what we are really trying to do here is generate a unique >>string, not record time... >> >> >> > As said above, generating a unique string is important/critical, but if >we can in the same time to record time, why not to do it usefully. > > Cheers, > Martin > > > From markw at illuminae.com Mon Jan 30 15:40:12 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 07:40:12 -0800 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <43DE28EC.7020002@ucalgary.ca> References: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> <43DE28EC.7020002@ucalgary.ca> Message-ID: So long as the time zone on your computer is set correctly, that's all I'm saying. What concerns me is that we're pulling our hair out trying to get a number that has some enormous degree of precision when in fact we cannot rely on it anyway, and moreover, we shouldn't even be parsing it out of the string in the first place... M On Mon, 30 Jan 2006 06:55:40 -0800, Paul Gordon wrote: > Actually, when you use ms since the epoch, it doesn't matter what time > zone you are in, because the epoch is defined as Jan 1 00:00 Greenwich > Mean Time. So if I'm Mountain Standard Time, the epoch was Dec 31 17:00 > 1969. Any date I calculate today will be set back 7 hours to reflect my > time zone, but so is the epoch. Even-Steven. > >> Well... I'm only arguing for the sake of arguing now, because it's fun! >> :-) >> >> An epoch or a timestamp assumes than the machine is set to the correct >> time and zone! Though a much rarer case, it isn't impossible... The >> *fact* is that we cannot trust the timestamp to be correct. >> >> But it doesn't matter :-). Let me see how easy it is to extract the TZ >> from the OS or an environment variable. If it is unreliable over the >> different OS's I'll just retrieve the epoch and use that as Martin >> suggests. If I can reliably get the TZ information on all OS's, then >> I'll add it to the current timestamp. >> >> M >> >> >> -----Original Message----- >> From: Martin Senger >> Date: Sat, 28 Jan 2006 05:50:24 >> To:Mark Wilkinson >> Cc:Core developer announcements >> Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 >> >> >> >>> I still don't see how the "ms since epoch" option tells us the >>> time-zone... >>> >>> >>> >> It does not. If we use "ms since epoch" we must document it and say >> "this is ms since epoch in UTC". And in the perl code you will use >> function 'time' and not 'localtime' (and you will multiply it by 1000 >> because perl gives you only seconds - unless you use Time:HiRes module). >> >> >> >>> ...but I also don't see why it is *critical* to know this at all... I >>> >>> >>> >> It is not critical. You are right that the critical is only to >> uniquely >> identify a version. But as a side-effect we may use this version for >> findng when an object was registered ( and display it nicely in various >> clients). In order to do this properly, we need to know what time is >> used >> in the version field. >> >> >> >>> however what we are really trying to do here is generate a unique >>> string, not record time... >>> >>> >>> >> As said above, generating a unique string is important/critical, but >> if >> we can in the same time to record time, why not to do it usefully. >> >> Cheers, >> Martin >> >> >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Mon Jan 30 15:52:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 07:52:40 -0800 Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: References: Message-ID: I don't know of any standard way of dumping POD documentation from a directory tree... I think it would have to be done file-by-file, which isn't a good solution... Does anyone else know of a way? M On Mon, 30 Jan 2006 02:04:46 -0800, Martin Senger wrote: >> It would be useful if we could have a link on the website to the POD, >> which could also be auto-updated from CVS, so that potential future >> users could browse the perl documentation online, without having to >> check out the code and run perldoc on it. >> > Mark, let me know what lines I should add to the cronjob so it > generates a perl doc on a proper place (something like using pod2html > program I guess). > > Thanks, > Martin > From markw at illuminae.com Mon Jan 30 16:03:02 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 08:03:02 -0800 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Message-ID: Sounds to me like SOAP::Lite is not using namespaces correctly... they're supposed to determine the meaning of the namespace from the document, rather than imposing it on the document. If that interpretation of the problem were true, then the fix should be in S::L, not Moby::Central... Am I mis-interpreting your bug report? I read your post on the SOAP::Lite group - Eddie and I have noticed that error before (though it was in the context of service-instance response errors, not registry errors. I can't recall how we fixed it... it was in mid-october sometime (we were not having the conversation on-list, however...) Eddie, can you go back in time and see what we did to solve the anyURI problem? M On Mon, 30 Jan 2006 05:32:04 -0800, Pieter Neerincx wrote: > Hi all, > > After quite some time there is finally an updated SOAP::Lite. I never > got the BioMOBY stuff working with the previous beta's, so I was > stuck on S::L 0.60. But now there is 0.66 and 0.67 was already > submitted to CPAN. And 0.68 might be there by the time you read this. > It's been a while since the last "stable" versions of S::L and now > they are popping up like mushrooms :). Unfortunately they don't work > with BioMOBY. I found 2 issues. One of them is clearly a S::L > problem, so I mailed to the corresponding list (And for those who are > interested, there's a temporary fix in that post as well). For the > other one I'm not sure, but I do now it can be fixed easily by a > small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem > with the WSDL that BioMOBY Central generates. There are several > namespaces in this WSDL and on them is prefixed with "soap": > > $WSDL_TEMPLATE = < > targetNamespace="http://biomoby.org/Central.wsdl" > xmlns:tns="http://biomoby.org/Central.wsdl" > xmlns:xsd1="http://biomoby.org/CentralXSDs.xsd" > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > xmlns:xsd="http://www.w3.org/1999/XMLSchema" > xmlns="http://schemas.xmlsoap.org/wsdl/" > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> > etc. > > As far as I understand it (after browsing the specs for the different > versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) > the "soap" prefixed namespace is for the SOAP binding described by > the WSDL document. Unfortunately when S::L is processing the response > from BioMOBY Central it thinks the "soap" prefixed namespace is for > the SOAP message eventhough the WSDL is wrapped in a CDATA block. > Since this namespace is not the valid one for SOAP version 1.1 or 1.2 > S::L complains that the entire response is in an unsupported version > of SOAP :(. Either something has to change in S::L, or we change the > prefix of the namespace. As far as I understand the prefixes for > namespaces are not standardised and could be anything. In lots of > examples I found on the net I saw: > xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", > xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or > xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" > instead of: > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > So what do the others think. Should this be patched in S::L or can we > change the prefix for this namespace from soap to for example wsoap? > > Cheers, > > Pieter > > > > Wageningen University and Research centre (WUR) > Laboratory of Bioinformatics > Transitorium (building 312) room 1034 > Dreijenlaan 3 > 6703 HA Wageningen > The Netherlands > phone: 0317-483 060 > fax: 0317-483 584 > mobile: 06-143 66 783 > pieter.neerincx at wur.nl > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From jmfernandez at cnb.uam.es Mon Jan 30 16:06:56 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Mon, 30 Jan 2006 17:06:56 +0100 Subject: [MOBY-dev] auto-updating documentation works fine (hourly); 'search' may be broken In-Reply-To: References: Message-ID: <43DE39A0.20903@cnb.uam.es> I haven't done the exercise, but a combination of Pod::Find (http://perldoc.perl.org/Pod/Find.html) and Pod::Html (http://search.cpan.org/~nwclark/perl-5.8.7/lib/Pod/Html.pm) modules could be the answer... Best Regards, Jos? Mar?a Mark Wilkinson wrote: > I don't know of any standard way of dumping POD documentation from a > directory tree... I think it would have to be done file-by-file, which > isn't a good solution... > > Does anyone else know of a way? > > M > > > > On Mon, 30 Jan 2006 02:04:46 -0800, Martin Senger wrote: > >>> It would be useful if we could have a link on the website to the POD, >>> which could also be auto-updated from CVS, so that potential future >>> users could browse the perl documentation online, without having to >>> check out the code and run perldoc on it. >>> >> Mark, let me know what lines I should add to the cronjob so it >> generates a perl doc on a proper place (something like using pod2html >> program I guess). >> >> Thanks, >> Martin >> > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From senger at ebi.ac.uk Mon Jan 30 16:14:31 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 30 Jan 2006 16:14:31 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: <43DE28EC.7020002@ucalgary.ca> Message-ID: > Actually, when you use ms since the epoch, it doesn't matter what time > zone you are in, because the epoch is defined as Jan 1 00:00 Greenwich > Mean Time. > Thanks, Paul. This is exactly the answer I was talking about. I said: we have to document what time zone we mean - but now you said that it is already well documented (I did not know it). So the problem solved, I guess. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From edward.kawas at gmail.com Mon Jan 30 16:09:57 2006 From: edward.kawas at gmail.com (Edward Kawas) Date: Mon, 30 Jan 2006 08:09:57 -0800 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new"stable" SOAP::Lite broken... In-Reply-To: Message-ID: <000201c625b7$9e565a20$6700a8c0@notebook> Hi, I think that our problem was solved by modifying the url portion of xmlns="http://www.w3.org/2000/10/XMLSchema" to xmlns:xsd="http://www.w3.org/1999/XMLSchema" Is this the 'fix' you are asking about? Eddie > -----Original Message----- > From: moby-dev-bounces at biomoby.org > [mailto:moby-dev-bounces at biomoby.org] On Behalf Of Mark Wilkinson > Sent: Monday, January 30, 2006 8:03 AM > To: Core developer announcements > Subject: Re: [MOBY-dev] Perl API and BioMOBY Central WSDL: > BioMOBY with new"stable" SOAP::Lite broken... > > Sounds to me like SOAP::Lite is not using namespaces > correctly... they're supposed to determine the meaning of the > namespace from the document, rather than imposing it on the document. > > If that interpretation of the problem were true, then the fix > should be in S::L, not Moby::Central... Am I > mis-interpreting your bug report? > > I read your post on the SOAP::Lite group - Eddie and I have > noticed that error before (though it was in the context of > service-instance response errors, not registry errors. I > can't recall how we fixed it... it was in mid-october > sometime (we were not having the conversation on-list, > however...) > > Eddie, can you go back in time and see what we did to solve > the anyURI problem? > > M > > > > > > On Mon, 30 Jan 2006 05:32:04 -0800, Pieter Neerincx > wrote: > > > Hi all, > > > > After quite some time there is finally an updated > SOAP::Lite. I never > > got the BioMOBY stuff working with the previous beta's, so I was > > stuck on S::L 0.60. But now there is 0.66 and 0.67 was already > > submitted to CPAN. And 0.68 might be there by the time you > read this. > > It's been a while since the last "stable" versions of S::L and now > > they are popping up like mushrooms :). Unfortunately they don't work > > with BioMOBY. I found 2 issues. One of them is clearly a S::L > > problem, so I mailed to the corresponding list (And for > those who are > > interested, there's a temporary fix in that post as well). For the > > other one I'm not sure, but I do now it can be fixed easily by a > > small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem > > with the WSDL that BioMOBY Central generates. There are several > > namespaces in this WSDL and on them is prefixed with "soap": > > > > $WSDL_TEMPLATE = < > > > > targetNamespace="http://biomoby.org/Central.wsdl" > > xmlns:tns="http://biomoby.org/Central.wsdl" > > xmlns:xsd1="http://biomoby.org/CentralXSDs.xsd" > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > xmlns:xsd="http://www.w3.org/1999/XMLSchema" > > xmlns="http://schemas.xmlsoap.org/wsdl/" > > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> > > etc. > > > > As far as I understand it (after browsing the specs for the > different > > versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) > > the "soap" prefixed namespace is for the SOAP binding described by > > the WSDL document. Unfortunately when S::L is processing > the response > > from BioMOBY Central it thinks the "soap" prefixed namespace is for > > the SOAP message eventhough the WSDL is wrapped in a CDATA block. > > Since this namespace is not the valid one for SOAP version > 1.1 or 1.2 > > S::L complains that the entire response is in an unsupported version > > of SOAP :(. Either something has to change in S::L, or we change the > > prefix of the namespace. As far as I understand the prefixes for > > namespaces are not standardised and could be anything. In lots of > > examples I found on the net I saw: > > xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", > > xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or > > xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" > > instead of: > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > > > So what do the others think. Should this be patched in S::L > or can we > > change the prefix for this namespace from soap to for example wsoap? > > > > Cheers, > > > > Pieter > > > > > > > > Wageningen University and Research centre (WUR) > > Laboratory of Bioinformatics > > Transitorium (building 312) room 1034 > > Dreijenlaan 3 > > 6703 HA Wageningen > > The Netherlands > > phone: 0317-483 060 > > fax: 0317-483 584 > > mobile: 06-143 66 783 > > pieter.neerincx at wur.nl > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From senger at ebi.ac.uk Mon Jan 30 16:21:16 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 30 Jan 2006 16:21:16 +0000 (GMT) Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: Message-ID: > So long as the time zone on your computer is set correctly > It has nothing to do with my computer - because you and me have different timezone on our computers, but we do not know what time zones we are using. Just make sure that what you (meaning: your software) put in the version is always well defined (e.g. for elapsed time, use always UTC, for your formatted string put 'Z' and your current - and correct - zone). > What concerns me is that we're pulling our hair > ...c'mon, Mark, this is a trivial issue. Why are you still arguing about it? > a number that has some enormous degree of precision when in fact we cannot > rely on it anyway > ...of course, we can (and we want). Perhaps I don't understand your problem... > and moreover, we shouldn't even be parsing it out of the string in the > first place... > ...that's a low argument. LSID is not a dogma. It is here to help us. Last time I am saying: why not to put there a meaning if it is free and useful. Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Mon Jan 30 16:34:37 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 Jan 2006 17:34:37 +0100 Subject: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & 1914 In-Reply-To: References: <513215776-1138429934-cardhu_blackberry.rim.net-25396-@engine03-cell01> <43DE28EC.7020002@ucalgary.ca> Message-ID: On 30-Jan-2006, at 4:40 PM, Mark Wilkinson wrote: > So long as the time zone on your computer is set correctly, that's > all I'm > saying. What concerns me is that we're pulling our hair out trying > to get > a number that has some enormous degree of precision when in fact we > cannot > rely on it anyway, Depends on how it's implemented. We can have the clients create the version number for the new LSID when they try to register something, but I think it would be better to leave that to BioMOBY Central. I that case only BioMOBY Central needs to be ticking in the correct time (-zone). Clients only need to compare LSIDs. They can be running in the wrong zone without problems for BioMOBY functionality. So the question is can we rely on Mark for keeping BioMOBY Central online with the clock set to the correct time(-zone)? If BioMOBY Central is misconfigured we're all screwed anyway, so adding this additional dependency doesn't worry me. Pi > and moreover, we shouldn't even be parsing it out of > the string in the first place... > > M > > > > On Mon, 30 Jan 2006 06:55:40 -0800, Paul Gordon > wrote: > >> Actually, when you use ms since the epoch, it doesn't matter what >> time >> zone you are in, because the epoch is defined as Jan 1 00:00 >> Greenwich >> Mean Time. So if I'm Mountain Standard Time, the epoch was Dec 31 >> 17:00 >> 1969. Any date I calculate today will be set back 7 hours to >> reflect my >> time zone, but so is the epoch. Even-Steven. >> >>> Well... I'm only arguing for the sake of arguing now, because >>> it's fun! >>> :-) >>> >>> An epoch or a timestamp assumes than the machine is set to the >>> correct >>> time and zone! Though a much rarer case, it isn't impossible... The >>> *fact* is that we cannot trust the timestamp to be correct. >>> >>> But it doesn't matter :-). Let me see how easy it is to extract >>> the TZ >>> from the OS or an environment variable. If it is unreliable over >>> the >>> different OS's I'll just retrieve the epoch and use that as Martin >>> suggests. If I can reliably get the TZ information on all OS's, >>> then >>> I'll add it to the current timestamp. >>> >>> M >>> >>> >>> -----Original Message----- >>> From: Martin Senger >>> Date: Sat, 28 Jan 2006 05:50:24 >>> To:Mark Wilkinson >>> Cc:Core developer announcements >>> Subject: Re: [MOBY-dev] Versioning of LSID's + vote on RFC 1913 & >>> 1914 >>> >>> >>> >>>> I still don't see how the "ms since epoch" option tells us the >>>> time-zone... >>>> >>>> >>>> >>> It does not. If we use "ms since epoch" we must document it >>> and say >>> "this is ms since epoch in UTC". And in the perl code you will use >>> function 'time' and not 'localtime' (and you will multiply it by >>> 1000 >>> because perl gives you only seconds - unless you use Time:HiRes >>> module). >>> >>> >>> >>>> ...but I also don't see why it is *critical* to know this at >>>> all... I >>>> >>>> >>>> >>> It is not critical. You are right that the critical is only to >>> uniquely >>> identify a version. But as a side-effect we may use this version for >>> findng when an object was registered ( and display it nicely in >>> various >>> clients). In order to do this properly, we need to know what time is >>> used >>> in the version field. >>> >>> >>> >>>> however what we are really trying to do here is generate a unique >>>> string, not record time... >>>> >>>> >>>> >>> As said above, generating a unique string is important/ >>> critical, but >>> if >>> we can in the same time to record time, why not to do it usefully. >>> >>> Cheers, >>> Martin >>> >>> >>> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From Pieter.Neerincx at wur.nl Mon Jan 30 16:53:09 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Mon, 30 Jan 2006 17:53:09 +0100 Subject: [MOBY-dev] Perl API and BioMOBY Central WSDL: BioMOBY with new "stable" SOAP::Lite broken... In-Reply-To: References: <7F97B65E-2B92-4634-8DAC-F91E9550EE27@wur.nl> Message-ID: On 30-Jan-2006, at 5:03 PM, Mark Wilkinson wrote: > Sounds to me like SOAP::Lite is not using namespaces correctly... > they're > supposed to determine the meaning of the namespace from the document, > rather than imposing it on the document. > > If that interpretation of the problem were true, then the fix > should be in > S::L, not Moby::Central... Am I mis-interpreting your bug report? No I think you got it right. S::L shouldn't mess it up, but I can predict that fixing it by changing the prefix in BioMOBY is much faster than trying to get a fix into the next "stable" release of S::L. So unless changing this namespace prefix causes problems for BioMOBY, we might do it both... Anyone with objections! > > I read your post on the SOAP::Lite group - Eddie and I have noticed > that > error before (though it was in the context of service-instance > response > errors, not registry errors. I can't recall how we fixed it... it > was in > mid-october sometime (we were not having the conversation on-list, > however...) > > Eddie, can you go back in time and see what we did to solve the anyURI > problem? I thought I had it up and running now, but found yet another issue :(. S::L 0.66 and up now encodes <, >, &, etc. in strings. The execute sub in MOBY/Client/Service.pm does it as well: $data =~ s"&"&"g; # encode content in case it has CDATA $data =~ s"\<"<"g; $data =~ s"\]\]\>"\]\]>"g; So now the data is encoded twice resulting in things like: &lt; which makes the parser choke. The simple solution is removing the 3 lines mentioned above, but off course in that case it will no longer work with older versions of S::L and I don't think everyone has already welcomed S::L 0.66+ on their disks. Cheers, Pi > M > > > > > > On Mon, 30 Jan 2006 05:32:04 -0800, Pieter Neerincx > wrote: > >> Hi all, >> >> After quite some time there is finally an updated SOAP::Lite. I never >> got the BioMOBY stuff working with the previous beta's, so I was >> stuck on S::L 0.60. But now there is 0.66 and 0.67 was already >> submitted to CPAN. And 0.68 might be there by the time you read this. >> It's been a while since the last "stable" versions of S::L and now >> they are popping up like mushrooms :). Unfortunately they don't work >> with BioMOBY. I found 2 issues. One of them is clearly a S::L >> problem, so I mailed to the corresponding list (And for those who are >> interested, there's a temporary fix in that post as well). For the >> other one I'm not sure, but I do now it can be fixed easily by a >> small change in ~moby-live/Perl/MOBY/Central.pm. There is a problem >> with the WSDL that BioMOBY Central generates. There are several >> namespaces in this WSDL and on them is prefixed with "soap": >> >> $WSDL_TEMPLATE = <> >> > targetNamespace="http://biomoby.org/Central.wsdl" >> xmlns:tns="http://biomoby.org/Central.wsdl" >> xmlns:xsd1="http://biomoby.org/CentralXSDs.xsd" >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" >> xmlns:xsd="http://www.w3.org/1999/XMLSchema" >> xmlns="http://schemas.xmlsoap.org/wsdl/" >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> >> etc. >> >> As far as I understand it (after browsing the specs for the different >> versions of WSDL, SOAP, WSDL SOAP binding etc. that drove me nuts) >> the "soap" prefixed namespace is for the SOAP binding described by >> the WSDL document. Unfortunately when S::L is processing the response >> from BioMOBY Central it thinks the "soap" prefixed namespace is for >> the SOAP message eventhough the WSDL is wrapped in a CDATA block. >> Since this namespace is not the valid one for SOAP version 1.1 or 1.2 >> S::L complains that the entire response is in an unsupported version >> of SOAP :(. Either something has to change in S::L, or we change the >> prefix of the namespace. As far as I understand the prefixes for >> namespaces are not standardised and could be anything. In lots of >> examples I found on the net I saw: >> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/", >> xmlns:soapwsdl="http://schemas.xmlsoap.org/wsdl/soap/" or >> xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/" >> instead of: >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" >> >> So what do the others think. Should this be patched in S::L or can we >> change the prefix for this namespace from soap to for example wsoap? >> >> Cheers, >> >> Pieter >> >> >> >> Wageningen University and Research centre (WUR) >> Laboratory of Bioinformatics >> Transitorium (building 312) room 1034 >> Dreijenlaan 3 >> 6703 HA Wageningen >> The Netherlands >> phone: 0317-483 060 >> fax: 0317-483 584 >> mobile: 06-143 66 783 >> pieter.neerincx at wur.nl >> >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From simont at hmgc.mcw.edu Mon Jan 30 20:56:55 2006 From: simont at hmgc.mcw.edu (Twigger Simon) Date: Mon, 30 Jan 2006 14:56:55 -0600 Subject: [MOBY-dev] Vote on RFC#1913 #1914 In-Reply-To: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> References: <1138296423.23542.2.camel@bioinfo.icapture.ubc.ca> Message-ID: <9958A0BC-939B-4EE8-83D2-4B59BA127D0A@hmgc.mcw.edu> Looks good to me. Yes for 1913/14 S. -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw On Jan 26, 2006, at 11:27 AM, Mark Wilkinson wrote: > Could the core voting group please vote on the LSID RFC's over the > weekend, or request changes. > > Thanks! > > M > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Tue Jan 31 00:51:40 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 16:51:40 -0800 Subject: [MOBY-dev] Last minute change to RFC1913 Message-ID: <1138668700.27364.67.camel@bioinfo.icapture.ubc.ca> Hiya, I've changed the 1913 RFC such that the timestamp is in GMT (suffixed with a "Z"). At the level of the MOBY::Central code, it is using the following call to generate the timestamp: gmtime(time()) However, the time() function returns different values on Mac vs Windows/*nix OS's (the Epoch is not the same in the Mac world, apparently!) Can someone with a Mac please confirm that the gmtime function in Perl will correctly report GMT on a Mac (or is this problem solved with OS- X?)? I want to be sure that the MOBY Central code is portable, and reporting correctly if we are going to start suggesting that people can actually use this timestamp for anything important. I take it that nobody has any objections in principle to this change? M P.S. to report gmtime(time) in a human-readable form retrieve it as a scalar rather than in list context - print scalar(gmtime(time)) -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From markw at illuminae.com Tue Jan 31 01:06:35 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 30 Jan 2006 17:06:35 -0800 Subject: [MOBY-dev] What with the mobyoch be? Message-ID: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> Any preferences on what the starting timestamp should be for all MOBY entities when I update the database? The "mobyoch" :-) we should make it something creative, since it will have a great deal of legacy (e.g. the "Object" object will probably never get edited...) M -- -- ...his last words were 'Hey guys! Watch this!' -- Mark Wilkinson Asst. Professor Dept. of Medical Genetics University of British Columbia PI in Bioinformatics iCAPTURE Centre St. Paul's Hospital Rm. 166, 1081 Burrard St. Vancouver, BC, V6Z 1Y6 tel: 604 682 2344 x62129 fax: 604 806 9274 "For most of this century we have viewed communications as a conduit, a pipe between physical locations on the planet. What's happened now is that the conduit has become so big and interesting that communication has become more than a conduit, it has become a destination in its own right..." Paul Saffo - Director, Institute for the Future From senger at ebi.ac.uk Tue Jan 31 04:16:14 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 31 Jan 2006 04:16:14 +0000 (GMT) Subject: [MOBY-dev] Urgent: jMoby does not compile In-Reply-To: <000401c61eb0$ef971090$6500a8c0@notebook> Message-ID: Eddie, Your last commit breaks things. Please do something soon... Thanks, Martin [javac] Found 1 semantic error and issued 1 warning compiling "/home/senger/moby-live/Java/src/main/org/biomoby/shared/extended/ServiceInstanceParser.java": [javac] <------ [javac] 190. service.setAuthoritative(Boolean [javac] 191. .parseBoolean(authoritative)); [javac] -----------------------------------------------------------------------------------> [javac] *** Semantic Error: No accessible method with signature "parseBoolean(java.lang.String)" was found in type "java.lang.Boolean". [javac] 197. String url = resource.getProperty(FetaVocabulary.locationURI) [javac] ^-^ [javac] *** Semantic Warning: Local "url" shadows a field of the same name in "org.biomoby.shared.extended.ServiceInstanceParser". -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From senger at ebi.ac.uk Tue Jan 31 04:48:14 2006 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 31 Jan 2006 04:48:14 +0000 (GMT) Subject: [MOBY-dev] RFC - Asynchronous Service Call Proposal In-Reply-To: <43D92134.2060708@ac.uma.es> Message-ID: > Attached to this email you can find the INB proposal (RFC) on > asynchronous service calls. > Thank you for putting together the proposal. I am going to read it thoroughly. But it would help me/us if you give us a planned time schedule when you expect our comments to be back. Could you suggest a sort of deadline please? Regards, Martin -- Martin Senger email: martin.senger at gmail.com skype: martinsenger consulting for: International Rice Research Institute Biometrics and Bioinformatics Unit DAPO BOX 7777, Metro Manila Philippines, phone: +63-2-580-5600 (ext.2324) From Pieter.Neerincx at wur.nl Tue Jan 31 10:48:33 2006 From: Pieter.Neerincx at wur.nl (Pieter Neerincx) Date: Tue, 31 Jan 2006 11:48:33 +0100 Subject: [MOBY-dev] Last minute change to RFC1913 In-Reply-To: <1138668700.27364.67.camel@bioinfo.icapture.ubc.ca> References: <1138668700.27364.67.camel@bioinfo.icapture.ubc.ca> Message-ID: <3D7456E2-94C1-44F1-85E9-2A7639FD0563@wur.nl> On 31-Jan-2006, at 1:51 AM, Mark Wilkinson wrote: > Hiya, > > I've changed the 1913 RFC such that the timestamp is in GMT (suffixed > with a "Z"). > > At the level of the MOBY::Central code, it is using the following call > to generate the timestamp: > > gmtime(time()) > > However, the time() function returns different values on Mac vs > Windows/*nix OS's (the Epoch is not the same in the Mac world, > apparently!) > > Can someone with a Mac please confirm that the gmtime function in Perl > will correctly report GMT on a Mac (or is this problem solved with OS- > X?)? I want to be sure that the MOBY Central code is portable, and > reporting correctly if we are going to start suggesting that people > can > actually use this timestamp for anything important. Hi Mark, Just checked it on a Mac running OS X. Both time() and gmtime() work exactly the same as on my Linux box :). Remember OS X is a nice custom Apple GUI, but on top of a Free BSD clone. The old OS 9 and before might be a completely different story, but I haven't used it in years :). I don't think there is a single vendor that still supports OS 9, so I don't think we should worry about it either: OS 9 is museum-ware :). Cheers, Pi > > I take it that nobody has any objections in principle to this change? > > M > P.S. to report gmtime(time) in a human-readable form retrieve it as a > scalar rather than in list context - print scalar(gmtime(time)) > > > > > -- > -- > ...his last words were 'Hey guys! Watch this!' > -- > Mark Wilkinson > Asst. Professor > Dept. of Medical Genetics > University of British Columbia > PI in Bioinformatics > iCAPTURE Centre > St. Paul's Hospital > Rm. 166, 1081 Burrard St. > Vancouver, BC, V6Z 1Y6 > tel: 604 682 2344 x62129 > fax: 604 806 9274 > > "For most of this century we have viewed communications as a conduit, > a pipe between physical locations on the planet. > What's happened now is that the conduit has become so big and > interesting > that communication has become more than a conduit, > it has become a destination in its own right..." > > Paul Saffo - Director, Institute for the Future > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://biomoby.org/mailman/listinfo/moby-dev Wageningen University and Research centre (WUR) Laboratory of Bioinformatics Transitorium (building 312) room 1034 Dreijenlaan 3 6703 HA Wageningen The Netherlands phone: 0317-483 060 fax: 0317-483 584 mobile: 06-143 66 783 pieter.neerincx at wur.nl From jmfernandez at cnb.uam.es Tue Jan 31 13:29:10 2006 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Tue, 31 Jan 2006 14:29:10 +0100 Subject: [MOBY-dev] What with the mobyoch be? In-Reply-To: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> References: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> Message-ID: <43DF6626.5070104@cnb.uam.es> Perhaps the date of the first MOBY DIC? Mark Wilkinson wrote: > Any preferences on what the starting timestamp should be for all MOBY > entities when I update the database? The "mobyoch" :-) > > we should make it something creative, since it will have a great deal of > legacy (e.g. the "Object" object will probably never get edited...) > > M > > > -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 54 50 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From markw at illuminae.com Tue Jan 31 15:58:22 2006 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 31 Jan 2006 07:58:22 -0800 Subject: [MOBY-dev] What with the mobyoch be? In-Reply-To: <43DF6626.5070104@cnb.uam.es> References: <1138669595.27364.76.camel@bioinfo.icapture.ubc.ca> <43DF6626.5070104@cnb.uam.es> Message-ID: 2001-09-21T16-00-00Z On Tue, 31 Jan 2006 05:29:10 -0800, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Perhaps the date of the first MOBY DIC? > > Mark Wilkinson wrote: >> Any preferences on what the starting timestamp should be for all MOBY >> entities when I update the database? The "mobyoch" :-) >> >> we should make it something creative, since it will have a great deal of >> legacy (e.g. the "Object" object will probably never get edited...) >> >> M >> >> >> >