From yanwong at ebgm.jussieu.fr Thu Jun 3 08:24:59 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: Thu Jun 3 08:28:12 2004 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <1086265499.19817.24.camel@prot1.rpbs.jussieu.fr> I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! From mwilkinson at mobile.rogers.com Thu Jun 3 08:43:58 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu Jun 3 10:52:54 2004 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <200406031253.i53CrCKr019215@portal.open-bio.org> That's fantastic! Would you like to add this to the biomoby CVS? M -----Original Message----- From: Yan Wong Date: 03 Jun 2004 14:24:59 To:moby-dev@biomoby.org Subject: [MOBY-dev] a bioMoby Python API I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Thu Jun 3 08:43:58 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu Jun 3 10:52:54 2004 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <200406031253.i53CrDKr019219@portal.open-bio.org> That's fantastic! Would you like to add this to the biomoby CVS? M -----Original Message----- From: Yan Wong Date: 03 Jun 2004 14:24:59 To:moby-dev@biomoby.org Subject: [MOBY-dev] a bioMoby Python API I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mrl.ubc.ca Thu Jun 3 15:38:53 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Jun 3 15:43:02 2004 Subject: [MOBY-dev] the rate of growth of MOBY Message-ID: <1086291533.1617.316.camel@myhost.mydomain> Hi all, I found these statistics quite interesting, so I thought I'd share them: The total number of hits on the public mobycentral machine (registry, ontology servers, and my own services) has quadrupled since January, and the number of calls to the MOBY Central API alone has now reached >40K per month! There are a lot of closet MOBYers out there!! What is reassuring is that, given our small messages, we have only transferred 1.1Gig since January, so that leaves a lot of room for expansion :-) Cheers all! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Jun 3 18:21:08 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Jun 3 18:25:24 2004 Subject: [MOBY-dev] Bug Reports now accepted Message-ID: <1086301268.8080.13.camel@myhost.mydomain> Hi all, Someone (I forget who) requested a more formal bug-reporting procedure for the MOBY project, and that is now done. We're piggybacking on the open-bio "bugzilla" reporting system, and have our own little piece of that pie. I've set up a few slots for various MOBY-S components (Damian, please go ahead and set up whatever slots you wish). If you click on the new "BUGS" link on the homepage it will take you to the bug reporting/browsing page where you can submit your bug report and follow its progress to being squashed. Hopefully this will help us keep track of what still needs to be written/fixed, and give others incentive to jump in a do some bug-squashing themselves :-) Cheers all! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From yanwong at ebgm.jussieu.fr Fri Jun 4 04:22:40 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: Fri Jun 4 04:25:50 2004 Subject: [MOBY-dev] How to add the bioMoby-python API to the CVS? Message-ID: <1086337360.1961.4.camel@prot1.rpbs.jussieu.fr> Yes, I can add the API to the CVS, How should I post it? From mwilkinson at mrl.ubc.ca Tue Jun 8 11:40:43 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Jun 8 11:45:05 2004 Subject: [MOBY-dev] RDF descriptions of MOBY services Message-ID: <1086709242.2691.58.camel@myhost.mydomain> Hi all, Nina and I are debating the most appropriate way to represent a MOBY service signature in RDF. The main source of controversy is with the inputs and outputs, in particular when it comes to collections. In the current draft, I have the input as a bnode type:Bag, with individual input articles coming off of it. Input articles in MOBY are either Simple or Collection, however at the moment I have made this distinction implicit - if the article is type:Bag, then it must be a Collection, and if it is not type:Bag, then it represents a Simple, and has various information (object_type, namespace, etc.) predicated to it. What concerns me is this: If we make the interpretation implicit, then we don't need additional predicates, whereas if we explicitly define the edge to an article as "has_simple", or "has_collection", then these predicates need to be defined. The data structure (Bag) is semantically identical (IMO) to what a Collection article is in MOBY, so I don't see a *need* to explicitly define this... but under either circumstance the person designing a query or a parser would need to understand how to interpret either the "shape" of the graph (if we leave it implicit), or the meanings of the predicates (if we make it explicit). ...?? This never ceases to befuddle me. It seems that, even with RDF, we can not get away from the requirement of community agreement on interpretation. I guess this reminds me of Phil's recurring statement "ontologies are only useful if they are shared"... ...but from those of you with more experience in RDF than I have, could you advise me which of these two options is "more correct"? Is it better to be explicit, and define new project-specific predicates, or is it better to let the data structure implicitly speak for itself using existing RDF/S predicates? Your wisdom is welcome! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From p.lord at russet.org.uk Tue Jun 8 12:36:44 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Jun 8 12:43:20 2004 Subject: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: <1086709242.2691.58.camel@myhost.mydomain> References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Hi all, Mark> Nina and I are debating the most appropriate way to represent Mark> a MOBY service signature in RDF. The main source of Mark> controversy is with the inputs and outputs, in particular when Mark> it comes to collections. Mark> In the current draft, I have the input as a bnode type:Bag, Mark> with individual input articles coming off of it. Input Mark> articles in MOBY are either Simple or Collection, however at Mark> the moment I have made this distinction implicit - if the Mark> article is type:Bag, then it must be a Collection, and if it Mark> is not type:Bag, then it represents a Simple, and has various Mark> information (object_type, namespace, etc.) predicated to it. Mark> What concerns me is this: If we make the interpretation Mark> implicit, then we don't need additional predicates, whereas if Mark> we explicitly define the edge to an article as "has_simple", Mark> or "has_collection", then these predicates need to be defined. Mark> The data structure (Bag) is semantically identical (IMO) to Mark> what a Collection article is in MOBY, so I don't see a *need* Mark> to explicitly define this... but under either circumstance the Mark> person designing a query or a parser would need to understand Mark> how to interpret either the "shape" of the graph (if we leave Mark> it implicit), or the meanings of the predicates (if we make it Mark> explicit). Mark> ...?? This never ceases to befuddle me. It seems that, even Mark> with RDF, we can not get away from the requirement of Mark> community agreement on interpretation. I guess this reminds Mark> me of Phil's recurring statement "ontologies are only useful Mark> if they are shared"... Mark> ...but from those of you with more experience in RDF than I Mark> have, could you advise me which of these two options is "more Mark> correct"? Is it better to be explicit, and define new Mark> project-specific predicates, or is it better to let the data Mark> structure implicitly speak for itself using existing RDF/S Mark> predicates? Mark I'm not convinced that it makes any difference. Either way you have to have an interpretation of the RDF wrt to the application at hand. This is the same with all uses of RDF; the RDF serialisation of OWL-DL, for example, does not tell you how to interpret the semantics of OWL-DL. You have to read the OWL spec for that. Cheers Phil From p.lord at russet.org.uk Tue Jun 8 12:36:44 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Jun 8 12:43:20 2004 Subject: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: <1086709242.2691.58.camel@myhost.mydomain> References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Hi all, Mark> Nina and I are debating the most appropriate way to represent Mark> a MOBY service signature in RDF. The main source of Mark> controversy is with the inputs and outputs, in particular when Mark> it comes to collections. Mark> In the current draft, I have the input as a bnode type:Bag, Mark> with individual input articles coming off of it. Input Mark> articles in MOBY are either Simple or Collection, however at Mark> the moment I have made this distinction implicit - if the Mark> article is type:Bag, then it must be a Collection, and if it Mark> is not type:Bag, then it represents a Simple, and has various Mark> information (object_type, namespace, etc.) predicated to it. Mark> What concerns me is this: If we make the interpretation Mark> implicit, then we don't need additional predicates, whereas if Mark> we explicitly define the edge to an article as "has_simple", Mark> or "has_collection", then these predicates need to be defined. Mark> The data structure (Bag) is semantically identical (IMO) to Mark> what a Collection article is in MOBY, so I don't see a *need* Mark> to explicitly define this... but under either circumstance the Mark> person designing a query or a parser would need to understand Mark> how to interpret either the "shape" of the graph (if we leave Mark> it implicit), or the meanings of the predicates (if we make it Mark> explicit). Mark> ...?? This never ceases to befuddle me. It seems that, even Mark> with RDF, we can not get away from the requirement of Mark> community agreement on interpretation. I guess this reminds Mark> me of Phil's recurring statement "ontologies are only useful Mark> if they are shared"... Mark> ...but from those of you with more experience in RDF than I Mark> have, could you advise me which of these two options is "more Mark> correct"? Is it better to be explicit, and define new Mark> project-specific predicates, or is it better to let the data Mark> structure implicitly speak for itself using existing RDF/S Mark> predicates? Mark I'm not convinced that it makes any difference. Either way you have to have an interpretation of the RDF wrt to the application at hand. This is the same with all uses of RDF; the RDF serialisation of OWL-DL, for example, does not tell you how to interpret the semantics of OWL-DL. You have to read the OWL spec for that. Cheers Phil From markw at illuminae.com Tue Jun 8 18:43:18 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Jun 8 18:47:25 2004 Subject: [MOBY] Re: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: <1086734598.3559.20.camel@myhost.mydomain> > Mark > > I'm not convinced that it makes any difference. Either way you have to > have an interpretation of the RDF wrt to the application at > hand. That's what I thought. So if there isn't an accepted convention, I think I would prefer to avoid creating specific predicates. Cheers Phil! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Jun 8 18:43:18 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Jun 8 18:48:03 2004 Subject: [MOBY] Re: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: <1086734598.3559.20.camel@myhost.mydomain> > Mark > > I'm not convinced that it makes any difference. Either way you have to > have an interpretation of the RDF wrt to the application at > hand. That's what I thought. So if there isn't an accepted convention, I think I would prefer to avoid creating specific predicates. Cheers Phil! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From yanwong at ebgm.jussieu.fr Fri Jun 11 07:32:20 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: Fri Jun 11 07:35:16 2004 Subject: [MOBY-dev] Support for object polymorphism Message-ID: <1086953540.2119.3.camel@prot1.rpbs.jussieu.fr> For example, if someone has a PDB, you can either have an ID, or a plain text PDB or stored in a compressed way, is there any way to register that in bioMoby? From yanwong at ebgm.jussieu.fr Fri Jun 11 07:34:03 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: Fri Jun 11 07:36:59 2004 Subject: [MOBY-dev] for the polymorphism Message-ID: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> For example a service can accept either a object with namespace PDB or a plain text that is a PDB or anything else... How would this service, be registrated? From markw at illuminae.com Fri Jun 11 12:09:27 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Jun 11 12:13:39 2004 Subject: [MOBY] [MOBY-dev] for the polymorphism In-Reply-To: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> References: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> Message-ID: <1086970167.9793.67.camel@myhost.mydomain> Hi, There is a limitation in the current version of MOBY in that a service instance has strictly defined inputs and outputs - no "either/or" allowed. As such, your scenario would require registration of two service instances (though on the server-side they may well be handled by the same piece of code...) I must point out, however, that it would be quite peculiar for an object representing a PDB record not to have a PDB number in its namespace/id attributes, so I guess in principle I doubt that you would really need to create both services... However, if you feel there is a need for both, then I think you would also be well-advised to create a new Object representing a PDB record that inherits from text-formatted (PDB_Record ISA text_formatted, or something like that). This would allow you to specifically consume PDB records that may or may not have a PDB ID. I hope that helps! M On Fri, 2004-06-11 at 04:34, Yan Wong wrote: > For example a service can accept either a object with namespace PDB > or a plain text that is a PDB or anything else... > > How would this service, be registrated? > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Fri Jun 11 12:09:27 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Fri Jun 11 12:13:41 2004 Subject: [MOBY] [MOBY-dev] for the polymorphism In-Reply-To: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> References: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> Message-ID: <1086970167.9793.67.camel@myhost.mydomain> Hi, There is a limitation in the current version of MOBY in that a service instance has strictly defined inputs and outputs - no "either/or" allowed. As such, your scenario would require registration of two service instances (though on the server-side they may well be handled by the same piece of code...) I must point out, however, that it would be quite peculiar for an object representing a PDB record not to have a PDB number in its namespace/id attributes, so I guess in principle I doubt that you would really need to create both services... However, if you feel there is a need for both, then I think you would also be well-advised to create a new Object representing a PDB record that inherits from text-formatted (PDB_Record ISA text_formatted, or something like that). This would allow you to specifically consume PDB records that may or may not have a PDB ID. I hope that helps! M On Fri, 2004-06-11 at 04:34, Yan Wong wrote: > For example a service can accept either a object with namespace PDB > or a plain text that is a PDB or anything else... > > How would this service, be registrated? > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Tue Jun 15 11:03:48 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Jun 15 11:08:05 2004 Subject: [MOBY-dev] TEST MOBY Central registry available Message-ID: <1087311828.2155.99.camel@myhost.mydomain> Hi all, Yeah yeah yeah, I know it has been a long time coming! Yesterday I made some changes to the registry code that allowed it to read its configuration from a config file, pointed to by an environment variable in apache. This made it easier to run multiple instances of apache each with a different registry configuration. (Rebecca - this is something that your sysadmin requested ages ago! please tell him it is now done...) As such, there is now a test version of the registry running at mobycentral and you can feel free to mess that one up as much as you wish. There is currently no GUI client pointing to that, but you can interact with it using the client-side libraries. The test registry is a snapshot of how the "real" registry looked this morning, but it is running from its own set of mySQL databases, so feel free to add/remove/play because you wont harm the real registry nor the real ontologies (touch wood...) The URL and URI for the test registry are: URL 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl' URI 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' For those of you using my Perl libraries to connect, simply create an instance of the MOBY::Client::Central as follows: my $C = MOBY::Client::Central->new( Registries => { mobycentral => { URL => 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl', URI => 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' } } ); and then use the module as you normally would. The perl test suite also uses the test instance of the registry now, so "TotalCrap" should no longer appear as a valid object in our ontologies ;-) Cheers all! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Jun 15 12:14:07 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue Jun 15 12:18:17 2004 Subject: [MISC] [MOBY-dev] TEST MOBY Central registry available In-Reply-To: <1087311828.2155.99.camel@myhost.mydomain> References: <1087311828.2155.99.camel@myhost.mydomain> Message-ID: <1087316047.2155.120.camel@myhost.mydomain> Note that 'URL' in the message below does not refer to a human-readable web interface. It is the location of the test MOBY Central SOAP server. I have a student, Eddie, who is currently building a GUI interface for service registration, and that should be up in the next few weeks. M On Tue, 2004-06-15 at 08:03, Mark Wilkinson wrote: > Hi all, > > Yeah yeah yeah, I know it has been a long time coming! > > Yesterday I made some changes to the registry code that allowed it to > read its configuration from a config file, pointed to by an environment > variable in apache. This made it easier to run multiple instances of > apache each with a different registry configuration. (Rebecca - this is > something that your sysadmin requested ages ago! please tell him it is > now done...) > > As such, there is now a test version of the registry running at > mobycentral and you can feel free to mess that one up as much as you > wish. There is currently no GUI client pointing to that, but you can > interact with it using the client-side libraries. > > The test registry is a snapshot of how the "real" registry looked this > morning, but it is running from its own set of mySQL databases, so feel > free to add/remove/play because you wont harm the real registry nor the > real ontologies (touch wood...) > > The URL and URI for the test registry are: > > URL 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl' > > URI 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' > > > For those of you using my Perl libraries to connect, simply create an > instance of the MOBY::Client::Central as follows: > > my $C = MOBY::Client::Central->new( > Registries => { > mobycentral => { URL => > 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl', > URI => 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' > } > } > ); > > and then use the module as you normally would. The perl test suite also > uses the test instance of the registry now, so "TotalCrap" should no > longer appear as a valid object in our ontologies ;-) > > Cheers all! > > M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Tue Jun 15 20:51:25 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Jun 15 20:55:37 2004 Subject: [MOBY-dev] SQL table change Message-ID: <1087347085.2055.63.camel@myhost.mydomain> Hi dev'ers I finally tracked down (one of) the reasons that the registration of secondary parameters is so troublesome. The database definition is contrary to the API! For those of you running a local registry: To patch the database, execute the following SQL on the mobycentral database: alter table secondary_input change datatype datatype enum('String', 'Integer', 'DateTime', 'Float'); I have updated the main mobycentral database already. I'm about to make a bunch of commits that should fix all remaining problems with secondary parameters. Sorry for the trouble! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Wed Jun 16 15:20:46 2004 From: simont at mcw.edu (Simon Twigger) Date: Wed Jun 16 15:23:32 2004 Subject: [MOBY-dev] CommonSubs.pm Message-ID: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> Hi Mark, I updated my copy of the cvs today to get CommonSubs working with my services - I had been using some of Ken's modules before. To get it to work I had to go in and hack the code around CommonSubs::responseHeader() (See below) I had to comment out the <<<<<<<, ========= and >>>>>>>>> lines as they were causing things to break, Im guessing they were diff annotations or similar? Thought Id let you know, I didnt want to mess with the CVS by committing anything just in case its meant to be like this and Im just missing something! Simon. sub responseHeader { # <<<<<<< CommonSubs.pm warn "responseHeader Called..\n"; my ($auth) = @_; # ======= use HTML::Entities (); my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); # >>>>>>> 1.50 $auth ||="not_provided"; $notes ||=""; my $xml = "". "". ""; if ($notes){ my $encodednotes = HTML::Entities::encode($notes); $xml .="$encodednotes"; } return $xml; } -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From markw at illuminae.com Wed Jun 16 15:25:10 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Jun 16 15:29:27 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> References: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> Message-ID: <1087413909.15064.2.camel@myhost.mydomain> Hi Simon, This is likely specific to you - it looks like you have done some tweaking of that part of the code, which caused a CVS versioning conflict when you merged the public code into your own (the <<<<< and >>>>> sections reveal what the conflict was) just pick the more recent one and delete the rest. cheers! M On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: > Hi Mark, > > I updated my copy of the cvs today to get CommonSubs working with > myservices - I had been using some of Ken's modules before. > > To get it to work I had to go in and hack the code > aroundCommonSubs::responseHeader() (See below) > > I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they > were causing things to break, Im guessing they were diffannotations or > similar? > > > Thought Id let you know, I didnt want to mess with the CVS > bycommitting anything just in case its meant to be like this and Im > justmissing something! > > Simon. > > sub responseHeader { > # <<<<<<< CommonSubs.pm > > warn "responseHeader Called..\n"; > > my ($auth) = @_; > # ======= > use HTML::Entities (); > my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); > # >>>>>>> 1.50 > $auth ||="not_provided"; > $notes ||=""; > my $xml = "". > " xmlns:moby='http://www.biomoby.org/moby'xmlns='http://www.biomoby.org/moby'>". > ""; > if ($notes){ > my $encodednotes = HTML::Entities::encode($notes); > $xml.="$encodednotes"; > } > return $xml; > } > > > -- > > 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 -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Wed Jun 16 15:57:27 2004 From: simont at mcw.edu (Simon Twigger) Date: Wed Jun 16 16:00:12 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <1087413909.15064.2.camel@myhost.mydomain> References: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> <1087413909.15064.2.camel@myhost.mydomain> Message-ID: <64DF3130-BFCF-11D8-9A2B-000A959D1D82@mcw.edu> This makes sense, it did seem odd that you would commit something that broke everything! Cheers, Simon. On Jun 16, 2004, at 2:25 PM, Mark Wilkinson wrote: > Hi Simon, > > This is likely specific to you - it looks like you have done some > tweaking of that part of the code, which caused a CVS versioning > conflict when you merged the public code into your own (the <<<<< and >>>>>> sections reveal what the conflict was) just pick the more recent > one and delete the rest. > > cheers! > > M > > > On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: >> Hi Mark, >> >> I updated my copy of the cvs today to get CommonSubs working with >> myservices - I had been using some of Ken's modules before. >> >> To get it to work I had to go in and hack the code >> aroundCommonSubs::responseHeader() (See below) >> >> I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they >> were causing things to break, Im guessing they were diffannotations or >> similar? >> >> >> Thought Id let you know, I didnt want to mess with the CVS >> bycommitting anything just in case its meant to be like this and Im >> justmissing something! >> >> Simon. >> >> sub responseHeader { >> # <<<<<<< CommonSubs.pm >> >> warn "responseHeader Called..\n"; >> >> my ($auth) = @_; >> # ======= >> use HTML::Entities (); >> my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); >> # >>>>>>> 1.50 >> $auth ||="not_provided"; >> $notes ||=""; >> my $xml = "". >> "> xmlns:moby='http://www.biomoby.org/moby'xmlns='http:// >> www.biomoby.org/moby'>". >> ""; >> if ($notes){ >> my $encodednotes = HTML::Entities::encode($notes); >> $xml.="$encodednotes"; >> } >> return $xml; >> } >> >> >> -- >> >> 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 > -- > Mark Wilkinson (mwilkinson@mrl.ubc.ca) > University of British Columbia iCAPTURE Centre > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From mwilkinson at mobile.rogers.com Wed Jun 16 17:52:37 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed Jun 16 18:00:59 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162200.i5GM0fKr007166@portal.open-bio.org> Oh, I dunno Simon... But thanks for your (misplaced) faith :-) There were a couple of hours a few days ago where I broke things badly! Hence my impetus to finally set up a development server in Halifax. However, you are right - I am trying to be much more careful now that we have so many users. Generally I install the changes on my local server first and run the test suites. From now on I will install it remotely on the dev server and test it there as well before finally committing it to the production registry!! It's a dangerous time code-wise, as I am now going through the entire codebase and rearranging it to reflect a better architecture and design philosophy (to actually *have* a design philosophy, for a start ;-) ). There's a lot of opportunity for error in there, but hopefully the code will become easier to maintain/extend once it's done. Cheers all! I'm off to Winnipeg (the belly-button of Canada) to teach bioperl-for-newbies for a few days, so I'll be out of touch until Monday. Martin, I'll see you in Manila in a couple of weeks - hopefully we can push forward the CGIAR MOBY plans there! ...exciting times!!!! M -----Original Message----- From: Simon Twigger Date: Wed, 16 Jun 2004 14:57:27 To:markw@illuminae.com, Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm This makes sense, it did seem odd that you would commit something that broke everything! Cheers, Simon. On Jun 16, 2004, at 2:25 PM, Mark Wilkinson wrote: > Hi Simon, > > This is likely specific to you - it looks like you have done some > tweaking of that part of the code, which caused a CVS versioning > conflict when you merged the public code into your own (the <<<<< and >>>>>> sections reveal what the conflict was) just pick the more recent > one and delete the rest. > > cheers! > > M > > > On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: >> Hi Mark, >> >> I updated my copy of the cvs today to get CommonSubs working with >> myservices - I had been using some of Ken's modules before. >> >> To get it to work I had to go in and hack the code >> aroundCommonSubs::responseHeader() (See below) >> >> I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they >> were causing things to break, Im guessing they were diffannotations or >> similar? >> >> >> Thought Id let you know, I didnt want to mess with the CVS >> bycommitting anything just in case its meant to be like this and Im >> justmissing something! >> >> Simon. >> >> sub responseHeader { >> # <<<<<<< CommonSubs.pm >> >> warn "responseHeader Called..\n"; >> >> my ($auth) = @_; >> # ======= >> use HTML::Entities (); >> my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); >> # >>>>>>> 1.50 >> $auth ||="not_provided"; >> $notes ||=""; >> my $xml = "". >> "> xmlns:moby='http://www.biomoby.org/moby'xmlns='http:// >> www.biomoby.org/moby'>". >> ""; >> if ($notes){ >> my $encodednotes = HTML::Entities::encode($notes); >> $xml.="$encodednotes"; >> } >> return $xml; >> } >> >> >> -- >> >> 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 > -- > Mark Wilkinson (mwilkinson@mrl.ubc.ca) > University of British Columbia iCAPTURE Centre > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Wed Jun 16 18:05:44 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Jun 16 18:08:35 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <200406162200.i5GM0fKr007166@portal.open-bio.org> Message-ID: > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From mwilkinson at mobile.rogers.com Wed Jun 16 18:08:35 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed Jun 16 18:15:39 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162215.i5GMFcKr007508@portal.open-bio.org> Yeah, I'm really looking forward to it... And the timing couldn't be better as I am heading into another round of intensive grant writing, so this is a great moment to start laying the plans for world domination, and to get paid to execute them ;-) B.t.w. Is there any functionality that you would like to see completed before we meet? I have about a week of "free time" to dedicate to coding before I arrive in Manila, so I could focus on those aspects of MOBY to get them done before we get there. Let me know. Looking forward to seeing you! M -----Original Message----- From: Martin Senger Date: Wed, 16 Jun 2004 23:05:44 To:mwilkinson , Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Wed Jun 16 18:27:15 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed Jun 16 18:34:24 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162234.i5GMYLKr007783@portal.open-bio.org> Actually, what excites me most about this is that an organization like CGIAR is planning to make use of the tools that we have been building for these past two years. MOBY has moved from being an exploratory exercise for a bunch of bioinfo geeks, to being a project that actually has the potential to help people! I'm quite anxious to make sure that it lives up to, or beats, their expectations... Like I said, exciting times!! M -----Original Message----- From: "mwilkinson" Date: Wed, 16 Jun 2004 18:08:35 To:senger@ebi.ac.uk;moby-dev@portal.open-bio.org Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm Yeah, I'm really looking forward to it... And the timing couldn't be better as I am heading into another round of intensive grant writing, so this is a great moment to start laying the plans for world domination, and to get paid to execute them ;-) B.t.w. Is there any functionality that you would like to see completed before we meet? I have about a week of "free time" to dedicate to coding before I arrive in Manila, so I could focus on those aspects of MOBY to get them done before we get there. Let me know. Looking forward to seeing you! M -----Original Message----- From: Martin Senger Date: Wed, 16 Jun 2004 23:05:44 To:mwilkinson , Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Thu Jun 17 03:31:24 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Jun 17 03:34:15 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <200406162212.i5GMCuF29366@maui.ebi.ac.uk> Message-ID: > B.t.w. Is there any functionality that you would like to see completed > before we meet? > No, I do not have yet precise plan what to work on when there. Obviously, very important will be to work on their particular problems - but that would not need any new code in the current BioMoby I guess. But if time allows I would like to work on one the following issues: * LSID metadata server for moby registry (as we discussed in CSHL), or * More Java support for service providers (in the similar - or less similar, I do not know yet - direction where Paul started it) Would you have any preferences for *me* to work on, perhaps? Btw, when are you coming to Manila? Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From boris.steipe at utoronto.ca Thu Jun 17 08:59:42 2004 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Thu Jun 17 09:02:31 2004 Subject: [MOBY-dev] LSIDs for registry Was: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: Message-ID: <330BA12E-C05E-11D8-9695-000A9577512E@utoronto.ca> Martin, what are you planning to do ? Assign LSIDs to registered MOBY services ? Or data or service types ? Could you clue me in? (I'm just working on LSIDifying the lab, specifically with a view how to connect this all with MOBY). Warm regards, Boris ============= On Thursday, Jun 17, 2004, at 02:31 America/Winnipeg, Martin Senger wrote: > * LSID metadata server for moby registry (as we discussed in CSHL) From senger at ebi.ac.uk Thu Jun 17 13:54:08 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Jun 17 13:56:52 2004 Subject: [MOBY-dev] LSIDs for registry Was: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <330BA12E-C05E-11D8-9695-000A9577512E@utoronto.ca> Message-ID: > what are you planning to do ? Assign LSIDs to registered MOBY services > ? Or data or service types ? Could you clue me in? > The idea is to have somewhere repository of metadata attached to individual services. Actually, to allow to have more metadata repositories. The problem is who knows where these repositories are. Ideally, the one who is the issueing authority for LSIDs representing services should be also able to "resolve requests for metadata for these LSIDs". And it is the Moby Central. The solution we have discussed at the last moby developer meeting would/could be (at least what I remember, I need to double check with Mark): * to have an LSID resolution service as a part of each Moby Central * there will be a normal Moby-native service that would know about various metadata repositories (so metadata providers may register their repositories with this service) * now, when a Moby Central (actually its resolution service) gets a request for metadata, it asks this special service to get back known metadata repositories What is needed to be coded is: * a Moby Central LSID Resolution service - which I believe already exists (or almost) * a service registering metadata repositories: should this be just another biomoby registry, or something specific?... * an implementation of at least one metadata repository Obviously, I would prefer to clarify it first with Mark in person - I hope that meeting him in Manila in couple of weeks will help to this. With regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From r.bruskiewich at cgiar.org Thu Jun 17 05:50:27 2004 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Sun Jun 20 16:06:09 2004 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <5B37FD42AEA6C447B407B01116A40B6D5DD9BE@IRRIMAIL.irri.cgiar.org> Would there be any thought about reviewing/enriching the data and service type ontologies, and/or considering the merits of S-MOBY to MOBY-S merger (at the level of the data/service type representation)? I know... Radical... But hey, I'm willing to explore the lay of the land. One issue I *know* might come up is the one I previously mentioned: development of a MOBY Central local to our crop community (in this case, the Generation Challenge Program). We can probably debate the relative merits of this when you both come. Richard -----Original Message----- From: Martin Senger [mailto:senger@ebi.ac.uk] Sent: Thursday, June 17, 2004 3:31 PM To: mwilkinson Cc: moby-dev@portal.open-bio.org; Bruskiewich, Richard (IRRI) Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > B.t.w. Is there any functionality that you would like to see completed > before we meet? > No, I do not have yet precise plan what to work on when there. Obviously, very important will be to work on their particular problems - but that would not need any new code in the current BioMoby I guess. But if time allows I would like to work on one the following issues: * LSID metadata server for moby registry (as we discussed in CSHL), or * More Java support for service providers (in the similar - or less similar, I do not know yet - direction where Paul started it) Would you have any preferences for *me* to work on, perhaps? Btw, when are you coming to Manila? Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From yanwong at ebgm.jussieu.fr Thu Jun 24 08:13:45 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: Thu Jun 24 08:16:20 2004 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <1088079225.12763.21.camel@prot1.rpbs.jussieu.fr> I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? From mwilkinson at mobile.rogers.com Thu Jun 24 10:00:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu Jun 24 10:03:40 2004 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <200406241403.i5OE3ZKr004151@portal.open-bio.org> This is likely a bug - I'll have a look in a couple of hours and fix it ASAP. M -----Original Message----- From: Yan Wong Date: 24 Jun 2004 14:13:45 To:bioMoby Developer list Subject: [MOBY-dev] I would like some explanations about findService I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Thu Jun 24 10:00:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu Jun 24 10:03:40 2004 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <200406241403.i5OE3cKr004155@portal.open-bio.org> This is likely a bug - I'll have a look in a couple of hours and fix it ASAP. M -----Original Message----- From: Yan Wong Date: 24 Jun 2004 14:13:45 To:bioMoby Developer list Subject: [MOBY-dev] I would like some explanations about findService I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mrl.ubc.ca Wed Jun 30 17:16:50 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed Jun 30 17:20:55 2004 Subject: [MOBY-dev] Sesame? Message-ID: <1088630210.2105.237.camel@myhost.mydomain> Hey, has anyone got experience with Sesame? I'm reading their paper and it sounds too good to be true w.r.t. future plans of moving MOBY Central & the MOBY Ontologies to a pure RDF representation... I'd be interested to hear other's experience with it! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From adf at ncgr.org Wed Jun 30 17:41:47 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed Jun 30 17:44:11 2004 Subject: [MOBY-dev] Sesame? In-Reply-To: <1088630210.2105.237.camel@myhost.mydomain> Message-ID: Hi Mark- I did some experimenting with Sesame for a bit when I was more actively involved; it seemed to be a reasonably robust system in terms of supporting persistance and querying; IIRC, it uses a forward-chaining type strategy for inference, such that whenever a new statement is added to the model, it will attempt to infer all consequences of that new statement in conjunction with its current knowledge base, but I think its rules of inference were relatively simple- transitive closure over subtypes, and that sort of thing; depending on how intelligent you imagine the ontologies will need to be vis-a-vis dynamic classification (some of the things I think Simon and Phil have discussed in the past), you may not get the inferencing power you want from Sesame- but I suppose you could put a more powerful inference engine as a front end for updates and then use sesame as a persistance and query mechanism, or something like that. HTH On Wed, 30 Jun 2004, Mark Wilkinson wrote: > Hey, > > has anyone got experience with Sesame? I'm reading their paper and it > sounds too good to be true w.r.t. future plans of moving MOBY Central & > the MOBY Ontologies to a pure RDF representation... I'd be interested > to hear other's experience with it! > > M > > > -- Andrew Farmer adf@ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From adf at ncgr.org Wed Jun 30 17:41:47 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed Jun 30 17:44:12 2004 Subject: [MOBY-dev] Sesame? In-Reply-To: <1088630210.2105.237.camel@myhost.mydomain> Message-ID: Hi Mark- I did some experimenting with Sesame for a bit when I was more actively involved; it seemed to be a reasonably robust system in terms of supporting persistance and querying; IIRC, it uses a forward-chaining type strategy for inference, such that whenever a new statement is added to the model, it will attempt to infer all consequences of that new statement in conjunction with its current knowledge base, but I think its rules of inference were relatively simple- transitive closure over subtypes, and that sort of thing; depending on how intelligent you imagine the ontologies will need to be vis-a-vis dynamic classification (some of the things I think Simon and Phil have discussed in the past), you may not get the inferencing power you want from Sesame- but I suppose you could put a more powerful inference engine as a front end for updates and then use sesame as a persistance and query mechanism, or something like that. HTH On Wed, 30 Jun 2004, Mark Wilkinson wrote: > Hey, > > has anyone got experience with Sesame? I'm reading their paper and it > sounds too good to be true w.r.t. future plans of moving MOBY Central & > the MOBY Ontologies to a pure RDF representation... I'd be interested > to hear other's experience with it! > > M > > > -- Andrew Farmer adf@ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From markw at illuminae.com Wed Jun 30 17:44:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Jun 30 17:48:10 2004 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: References: Message-ID: <1088631841.1967.246.camel@myhost.mydomain> On Wed, 2004-06-30 at 14:41, Andrew D. Farmer wrote: > current knowledge base, but I think its rules of inference were relatively > simple- transitive closure over subtypes, Right - it sounds like it handles (i.e. "understands") only RDFS predicates... but even that is a joy! Do you have a feeling for how it compares to Jena v.v. speed and features? From the paper they are describing it as "Jena plus", but there may be features in Jena that are more powerful...?? M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Wed Jun 30 17:44:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Jun 30 17:48:13 2004 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: References: Message-ID: <1088631841.1967.246.camel@myhost.mydomain> On Wed, 2004-06-30 at 14:41, Andrew D. Farmer wrote: > current knowledge base, but I think its rules of inference were relatively > simple- transitive closure over subtypes, Right - it sounds like it handles (i.e. "understands") only RDFS predicates... but even that is a joy! Do you have a feeling for how it compares to Jena v.v. speed and features? From the paper they are describing it as "Jena plus", but there may be features in Jena that are more powerful...?? M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From adf at ncgr.org Wed Jun 30 19:28:48 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed Jun 30 19:31:07 2004 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: <1088631841.1967.246.camel@myhost.mydomain> Message-ID: > Do you have a feeling for how it compares to Jena v.v. speed and > features? From the paper they are describing it as "Jena plus", but > there may be features in Jena that are more powerful...?? When was the paper written? I seem to recall that at the time I was looking at sesame, jena was a fairly bare-bones api for rdf manipulation (I don't think at that time it supported persistance to an rdbms), but since then it seems to have flourished in many directions. My impression is that Jena is better designed for pluggable implementations of things like inference and persistance than sesame. OTOH, I think at this point sesame may still support a greater variety of query languages than does jena, and comes complete with a easy-to-use servlet interface for admin and query/browse of datastores. Gary knows much more about jena than I do, and might be able to give you more detailed info. Jena appears to have a larger active development community, which is no small consideration... > > M > > > -- Andrew Farmer adf@ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From adf at ncgr.org Wed Jun 30 19:28:48 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed Jun 30 19:31:08 2004 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: <1088631841.1967.246.camel@myhost.mydomain> Message-ID: > Do you have a feeling for how it compares to Jena v.v. speed and > features? From the paper they are describing it as "Jena plus", but > there may be features in Jena that are more powerful...?? When was the paper written? I seem to recall that at the time I was looking at sesame, jena was a fairly bare-bones api for rdf manipulation (I don't think at that time it supported persistance to an rdbms), but since then it seems to have flourished in many directions. My impression is that Jena is better designed for pluggable implementations of things like inference and persistance than sesame. OTOH, I think at this point sesame may still support a greater variety of query languages than does jena, and comes complete with a easy-to-use servlet interface for admin and query/browse of datastores. Gary knows much more about jena than I do, and might be able to give you more detailed info. Jena appears to have a larger active development community, which is no small consideration... > > M > > > -- Andrew Farmer adf@ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From gss at ncgr.org Wed Jun 30 20:30:43 2004 From: gss at ncgr.org (Gary Schiltz) Date: Wed Jun 30 20:36:12 2004 Subject: [MOBY-dev] Sesame? Message-ID: <40E35B33.7070206@ncgr.org> I looked at Sesame when I was trying to decide on the best architecture on top of which to implement S-MOBY (about 6 months ago). While it looked like a good tool, it didn't seem to be very actively maintained at the time. I just looked at the Sesame web site (www.openrdf.org), and it looks like the user forums have had a bit of traffic, so maybe it's more active than before. In the end, I settled on Jena (jena.sourceforge.net) as the underlying framework for working with RDF. It is quite actively supported by HP, and also seems to have an active user community. At least, its mailing list gets a large number of messages every day. // Gary From yanwong at ebgm.jussieu.fr Thu Jun 3 08:24:59 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 03 Jun 2004 14:24:59 +0200 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <1086265499.19817.24.camel@prot1.rpbs.jussieu.fr> I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! From mwilkinson at mobile.rogers.com Thu Jun 3 08:43:58 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 3 Jun 2004 08:43:58 -0400 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <200406031253.i53CrCKr019215@portal.open-bio.org> That's fantastic! Would you like to add this to the biomoby CVS? M -----Original Message----- From: Yan Wong Date: 03 Jun 2004 14:24:59 To:moby-dev at biomoby.org Subject: [MOBY-dev] a bioMoby Python API I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Thu Jun 3 08:43:58 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 3 Jun 2004 08:43:58 -0400 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <200406031253.i53CrDKr019219@portal.open-bio.org> That's fantastic! Would you like to add this to the biomoby CVS? M -----Original Message----- From: Yan Wong Date: 03 Jun 2004 14:24:59 To:moby-dev at biomoby.org Subject: [MOBY-dev] a bioMoby Python API I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mrl.ubc.ca Thu Jun 3 15:38:53 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 03 Jun 2004 12:38:53 -0700 Subject: [MOBY-dev] the rate of growth of MOBY Message-ID: <1086291533.1617.316.camel@myhost.mydomain> Hi all, I found these statistics quite interesting, so I thought I'd share them: The total number of hits on the public mobycentral machine (registry, ontology servers, and my own services) has quadrupled since January, and the number of calls to the MOBY Central API alone has now reached >40K per month! There are a lot of closet MOBYers out there!! What is reassuring is that, given our small messages, we have only transferred 1.1Gig since January, so that leaves a lot of room for expansion :-) Cheers all! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Jun 3 18:21:08 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 03 Jun 2004 15:21:08 -0700 Subject: [MOBY-dev] Bug Reports now accepted Message-ID: <1086301268.8080.13.camel@myhost.mydomain> Hi all, Someone (I forget who) requested a more formal bug-reporting procedure for the MOBY project, and that is now done. We're piggybacking on the open-bio "bugzilla" reporting system, and have our own little piece of that pie. I've set up a few slots for various MOBY-S components (Damian, please go ahead and set up whatever slots you wish). If you click on the new "BUGS" link on the homepage it will take you to the bug reporting/browsing page where you can submit your bug report and follow its progress to being squashed. Hopefully this will help us keep track of what still needs to be written/fixed, and give others incentive to jump in a do some bug-squashing themselves :-) Cheers all! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From yanwong at ebgm.jussieu.fr Fri Jun 4 04:22:40 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 04 Jun 2004 10:22:40 +0200 Subject: [MOBY-dev] How to add the bioMoby-python API to the CVS? Message-ID: <1086337360.1961.4.camel@prot1.rpbs.jussieu.fr> Yes, I can add the API to the CVS, How should I post it? From mwilkinson at mrl.ubc.ca Tue Jun 8 11:40:43 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 08 Jun 2004 08:40:43 -0700 Subject: [MOBY-dev] RDF descriptions of MOBY services Message-ID: <1086709242.2691.58.camel@myhost.mydomain> Hi all, Nina and I are debating the most appropriate way to represent a MOBY service signature in RDF. The main source of controversy is with the inputs and outputs, in particular when it comes to collections. In the current draft, I have the input as a bnode type:Bag, with individual input articles coming off of it. Input articles in MOBY are either Simple or Collection, however at the moment I have made this distinction implicit - if the article is type:Bag, then it must be a Collection, and if it is not type:Bag, then it represents a Simple, and has various information (object_type, namespace, etc.) predicated to it. What concerns me is this: If we make the interpretation implicit, then we don't need additional predicates, whereas if we explicitly define the edge to an article as "has_simple", or "has_collection", then these predicates need to be defined. The data structure (Bag) is semantically identical (IMO) to what a Collection article is in MOBY, so I don't see a *need* to explicitly define this... but under either circumstance the person designing a query or a parser would need to understand how to interpret either the "shape" of the graph (if we leave it implicit), or the meanings of the predicates (if we make it explicit). ...?? This never ceases to befuddle me. It seems that, even with RDF, we can not get away from the requirement of community agreement on interpretation. I guess this reminds me of Phil's recurring statement "ontologies are only useful if they are shared"... ...but from those of you with more experience in RDF than I have, could you advise me which of these two options is "more correct"? Is it better to be explicit, and define new project-specific predicates, or is it better to let the data structure implicitly speak for itself using existing RDF/S predicates? Your wisdom is welcome! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From p.lord at russet.org.uk Tue Jun 8 12:36:44 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 08 Jun 2004 17:36:44 +0100 Subject: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: <1086709242.2691.58.camel@myhost.mydomain> References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Hi all, Mark> Nina and I are debating the most appropriate way to represent Mark> a MOBY service signature in RDF. The main source of Mark> controversy is with the inputs and outputs, in particular when Mark> it comes to collections. Mark> In the current draft, I have the input as a bnode type:Bag, Mark> with individual input articles coming off of it. Input Mark> articles in MOBY are either Simple or Collection, however at Mark> the moment I have made this distinction implicit - if the Mark> article is type:Bag, then it must be a Collection, and if it Mark> is not type:Bag, then it represents a Simple, and has various Mark> information (object_type, namespace, etc.) predicated to it. Mark> What concerns me is this: If we make the interpretation Mark> implicit, then we don't need additional predicates, whereas if Mark> we explicitly define the edge to an article as "has_simple", Mark> or "has_collection", then these predicates need to be defined. Mark> The data structure (Bag) is semantically identical (IMO) to Mark> what a Collection article is in MOBY, so I don't see a *need* Mark> to explicitly define this... but under either circumstance the Mark> person designing a query or a parser would need to understand Mark> how to interpret either the "shape" of the graph (if we leave Mark> it implicit), or the meanings of the predicates (if we make it Mark> explicit). Mark> ...?? This never ceases to befuddle me. It seems that, even Mark> with RDF, we can not get away from the requirement of Mark> community agreement on interpretation. I guess this reminds Mark> me of Phil's recurring statement "ontologies are only useful Mark> if they are shared"... Mark> ...but from those of you with more experience in RDF than I Mark> have, could you advise me which of these two options is "more Mark> correct"? Is it better to be explicit, and define new Mark> project-specific predicates, or is it better to let the data Mark> structure implicitly speak for itself using existing RDF/S Mark> predicates? Mark I'm not convinced that it makes any difference. Either way you have to have an interpretation of the RDF wrt to the application at hand. This is the same with all uses of RDF; the RDF serialisation of OWL-DL, for example, does not tell you how to interpret the semantics of OWL-DL. You have to read the OWL spec for that. Cheers Phil From p.lord at russet.org.uk Tue Jun 8 12:36:44 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 08 Jun 2004 17:36:44 +0100 Subject: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: <1086709242.2691.58.camel@myhost.mydomain> References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Hi all, Mark> Nina and I are debating the most appropriate way to represent Mark> a MOBY service signature in RDF. The main source of Mark> controversy is with the inputs and outputs, in particular when Mark> it comes to collections. Mark> In the current draft, I have the input as a bnode type:Bag, Mark> with individual input articles coming off of it. Input Mark> articles in MOBY are either Simple or Collection, however at Mark> the moment I have made this distinction implicit - if the Mark> article is type:Bag, then it must be a Collection, and if it Mark> is not type:Bag, then it represents a Simple, and has various Mark> information (object_type, namespace, etc.) predicated to it. Mark> What concerns me is this: If we make the interpretation Mark> implicit, then we don't need additional predicates, whereas if Mark> we explicitly define the edge to an article as "has_simple", Mark> or "has_collection", then these predicates need to be defined. Mark> The data structure (Bag) is semantically identical (IMO) to Mark> what a Collection article is in MOBY, so I don't see a *need* Mark> to explicitly define this... but under either circumstance the Mark> person designing a query or a parser would need to understand Mark> how to interpret either the "shape" of the graph (if we leave Mark> it implicit), or the meanings of the predicates (if we make it Mark> explicit). Mark> ...?? This never ceases to befuddle me. It seems that, even Mark> with RDF, we can not get away from the requirement of Mark> community agreement on interpretation. I guess this reminds Mark> me of Phil's recurring statement "ontologies are only useful Mark> if they are shared"... Mark> ...but from those of you with more experience in RDF than I Mark> have, could you advise me which of these two options is "more Mark> correct"? Is it better to be explicit, and define new Mark> project-specific predicates, or is it better to let the data Mark> structure implicitly speak for itself using existing RDF/S Mark> predicates? Mark I'm not convinced that it makes any difference. Either way you have to have an interpretation of the RDF wrt to the application at hand. This is the same with all uses of RDF; the RDF serialisation of OWL-DL, for example, does not tell you how to interpret the semantics of OWL-DL. You have to read the OWL spec for that. Cheers Phil From markw at illuminae.com Tue Jun 8 18:43:18 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 08 Jun 2004 15:43:18 -0700 Subject: [MOBY] Re: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: <1086734598.3559.20.camel@myhost.mydomain> > Mark > > I'm not convinced that it makes any difference. Either way you have to > have an interpretation of the RDF wrt to the application at > hand. That's what I thought. So if there isn't an accepted convention, I think I would prefer to avoid creating specific predicates. Cheers Phil! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Jun 8 18:43:18 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 08 Jun 2004 15:43:18 -0700 Subject: [MOBY] Re: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: <1086734598.3559.20.camel@myhost.mydomain> > Mark > > I'm not convinced that it makes any difference. Either way you have to > have an interpretation of the RDF wrt to the application at > hand. That's what I thought. So if there isn't an accepted convention, I think I would prefer to avoid creating specific predicates. Cheers Phil! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From yanwong at ebgm.jussieu.fr Fri Jun 11 07:32:20 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 11 Jun 2004 13:32:20 +0200 Subject: [MOBY-dev] Support for object polymorphism Message-ID: <1086953540.2119.3.camel@prot1.rpbs.jussieu.fr> For example, if someone has a PDB, you can either have an ID, or a plain text PDB or stored in a compressed way, is there any way to register that in bioMoby? From yanwong at ebgm.jussieu.fr Fri Jun 11 07:34:03 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 11 Jun 2004 13:34:03 +0200 Subject: [MOBY-dev] for the polymorphism Message-ID: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> For example a service can accept either a object with namespace PDB or a plain text that is a PDB or anything else... How would this service, be registrated? From markw at illuminae.com Fri Jun 11 12:09:27 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 11 Jun 2004 09:09:27 -0700 Subject: [MOBY] [MOBY-dev] for the polymorphism In-Reply-To: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> References: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> Message-ID: <1086970167.9793.67.camel@myhost.mydomain> Hi, There is a limitation in the current version of MOBY in that a service instance has strictly defined inputs and outputs - no "either/or" allowed. As such, your scenario would require registration of two service instances (though on the server-side they may well be handled by the same piece of code...) I must point out, however, that it would be quite peculiar for an object representing a PDB record not to have a PDB number in its namespace/id attributes, so I guess in principle I doubt that you would really need to create both services... However, if you feel there is a need for both, then I think you would also be well-advised to create a new Object representing a PDB record that inherits from text-formatted (PDB_Record ISA text_formatted, or something like that). This would allow you to specifically consume PDB records that may or may not have a PDB ID. I hope that helps! M On Fri, 2004-06-11 at 04:34, Yan Wong wrote: > For example a service can accept either a object with namespace PDB > or a plain text that is a PDB or anything else... > > How would this service, be registrated? > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Fri Jun 11 12:09:27 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 11 Jun 2004 09:09:27 -0700 Subject: [MOBY] [MOBY-dev] for the polymorphism In-Reply-To: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> References: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> Message-ID: <1086970167.9793.67.camel@myhost.mydomain> Hi, There is a limitation in the current version of MOBY in that a service instance has strictly defined inputs and outputs - no "either/or" allowed. As such, your scenario would require registration of two service instances (though on the server-side they may well be handled by the same piece of code...) I must point out, however, that it would be quite peculiar for an object representing a PDB record not to have a PDB number in its namespace/id attributes, so I guess in principle I doubt that you would really need to create both services... However, if you feel there is a need for both, then I think you would also be well-advised to create a new Object representing a PDB record that inherits from text-formatted (PDB_Record ISA text_formatted, or something like that). This would allow you to specifically consume PDB records that may or may not have a PDB ID. I hope that helps! M On Fri, 2004-06-11 at 04:34, Yan Wong wrote: > For example a service can accept either a object with namespace PDB > or a plain text that is a PDB or anything else... > > How would this service, be registrated? > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Tue Jun 15 11:03:48 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 15 Jun 2004 08:03:48 -0700 Subject: [MOBY-dev] TEST MOBY Central registry available Message-ID: <1087311828.2155.99.camel@myhost.mydomain> Hi all, Yeah yeah yeah, I know it has been a long time coming! Yesterday I made some changes to the registry code that allowed it to read its configuration from a config file, pointed to by an environment variable in apache. This made it easier to run multiple instances of apache each with a different registry configuration. (Rebecca - this is something that your sysadmin requested ages ago! please tell him it is now done...) As such, there is now a test version of the registry running at mobycentral and you can feel free to mess that one up as much as you wish. There is currently no GUI client pointing to that, but you can interact with it using the client-side libraries. The test registry is a snapshot of how the "real" registry looked this morning, but it is running from its own set of mySQL databases, so feel free to add/remove/play because you wont harm the real registry nor the real ontologies (touch wood...) The URL and URI for the test registry are: URL 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl' URI 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' For those of you using my Perl libraries to connect, simply create an instance of the MOBY::Client::Central as follows: my $C = MOBY::Client::Central->new( Registries => { mobycentral => { URL => 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl', URI => 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' } } ); and then use the module as you normally would. The perl test suite also uses the test instance of the registry now, so "TotalCrap" should no longer appear as a valid object in our ontologies ;-) Cheers all! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Jun 15 12:14:07 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 15 Jun 2004 09:14:07 -0700 Subject: [MISC] [MOBY-dev] TEST MOBY Central registry available In-Reply-To: <1087311828.2155.99.camel@myhost.mydomain> References: <1087311828.2155.99.camel@myhost.mydomain> Message-ID: <1087316047.2155.120.camel@myhost.mydomain> Note that 'URL' in the message below does not refer to a human-readable web interface. It is the location of the test MOBY Central SOAP server. I have a student, Eddie, who is currently building a GUI interface for service registration, and that should be up in the next few weeks. M On Tue, 2004-06-15 at 08:03, Mark Wilkinson wrote: > Hi all, > > Yeah yeah yeah, I know it has been a long time coming! > > Yesterday I made some changes to the registry code that allowed it to > read its configuration from a config file, pointed to by an environment > variable in apache. This made it easier to run multiple instances of > apache each with a different registry configuration. (Rebecca - this is > something that your sysadmin requested ages ago! please tell him it is > now done...) > > As such, there is now a test version of the registry running at > mobycentral and you can feel free to mess that one up as much as you > wish. There is currently no GUI client pointing to that, but you can > interact with it using the client-side libraries. > > The test registry is a snapshot of how the "real" registry looked this > morning, but it is running from its own set of mySQL databases, so feel > free to add/remove/play because you wont harm the real registry nor the > real ontologies (touch wood...) > > The URL and URI for the test registry are: > > URL 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl' > > URI 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' > > > For those of you using my Perl libraries to connect, simply create an > instance of the MOBY::Client::Central as follows: > > my $C = MOBY::Client::Central->new( > Registries => { > mobycentral => { URL => > 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl', > URI => 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' > } > } > ); > > and then use the module as you normally would. The perl test suite also > uses the test instance of the registry now, so "TotalCrap" should no > longer appear as a valid object in our ontologies ;-) > > Cheers all! > > M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Tue Jun 15 20:51:25 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 15 Jun 2004 17:51:25 -0700 Subject: [MOBY-dev] SQL table change Message-ID: <1087347085.2055.63.camel@myhost.mydomain> Hi dev'ers I finally tracked down (one of) the reasons that the registration of secondary parameters is so troublesome. The database definition is contrary to the API! For those of you running a local registry: To patch the database, execute the following SQL on the mobycentral database: alter table secondary_input change datatype datatype enum('String', 'Integer', 'DateTime', 'Float'); I have updated the main mobycentral database already. I'm about to make a bunch of commits that should fix all remaining problems with secondary parameters. Sorry for the trouble! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Wed Jun 16 15:20:46 2004 From: simont at mcw.edu (Simon Twigger) Date: Wed, 16 Jun 2004 14:20:46 -0500 Subject: [MOBY-dev] CommonSubs.pm Message-ID: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> Hi Mark, I updated my copy of the cvs today to get CommonSubs working with my services - I had been using some of Ken's modules before. To get it to work I had to go in and hack the code around CommonSubs::responseHeader() (See below) I had to comment out the <<<<<<<, ========= and >>>>>>>>> lines as they were causing things to break, Im guessing they were diff annotations or similar? Thought Id let you know, I didnt want to mess with the CVS by committing anything just in case its meant to be like this and Im just missing something! Simon. sub responseHeader { # <<<<<<< CommonSubs.pm warn "responseHeader Called..\n"; my ($auth) = @_; # ======= use HTML::Entities (); my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); # >>>>>>> 1.50 $auth ||="not_provided"; $notes ||=""; my $xml = "". "". ""; if ($notes){ my $encodednotes = HTML::Entities::encode($notes); $xml .="$encodednotes"; } return $xml; } -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From markw at illuminae.com Wed Jun 16 15:25:10 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 16 Jun 2004 12:25:10 -0700 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> References: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> Message-ID: <1087413909.15064.2.camel@myhost.mydomain> Hi Simon, This is likely specific to you - it looks like you have done some tweaking of that part of the code, which caused a CVS versioning conflict when you merged the public code into your own (the <<<<< and >>>>> sections reveal what the conflict was) just pick the more recent one and delete the rest. cheers! M On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: > Hi Mark, > > I updated my copy of the cvs today to get CommonSubs working with > myservices - I had been using some of Ken's modules before. > > To get it to work I had to go in and hack the code > aroundCommonSubs::responseHeader() (See below) > > I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they > were causing things to break, Im guessing they were diffannotations or > similar? > > > Thought Id let you know, I didnt want to mess with the CVS > bycommitting anything just in case its meant to be like this and Im > justmissing something! > > Simon. > > sub responseHeader { > # <<<<<<< CommonSubs.pm > > warn "responseHeader Called..\n"; > > my ($auth) = @_; > # ======= > use HTML::Entities (); > my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); > # >>>>>>> 1.50 > $auth ||="not_provided"; > $notes ||=""; > my $xml = "". > " xmlns:moby='http://www.biomoby.org/moby'xmlns='http://www.biomoby.org/moby'>". > ""; > if ($notes){ > my $encodednotes = HTML::Entities::encode($notes); > $xml.="$encodednotes"; > } > return $xml; > } > > > -- > > 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 -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Wed Jun 16 15:57:27 2004 From: simont at mcw.edu (Simon Twigger) Date: Wed, 16 Jun 2004 14:57:27 -0500 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <1087413909.15064.2.camel@myhost.mydomain> References: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> <1087413909.15064.2.camel@myhost.mydomain> Message-ID: <64DF3130-BFCF-11D8-9A2B-000A959D1D82@mcw.edu> This makes sense, it did seem odd that you would commit something that broke everything! Cheers, Simon. On Jun 16, 2004, at 2:25 PM, Mark Wilkinson wrote: > Hi Simon, > > This is likely specific to you - it looks like you have done some > tweaking of that part of the code, which caused a CVS versioning > conflict when you merged the public code into your own (the <<<<< and >>>>>> sections reveal what the conflict was) just pick the more recent > one and delete the rest. > > cheers! > > M > > > On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: >> Hi Mark, >> >> I updated my copy of the cvs today to get CommonSubs working with >> myservices - I had been using some of Ken's modules before. >> >> To get it to work I had to go in and hack the code >> aroundCommonSubs::responseHeader() (See below) >> >> I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they >> were causing things to break, Im guessing they were diffannotations or >> similar? >> >> >> Thought Id let you know, I didnt want to mess with the CVS >> bycommitting anything just in case its meant to be like this and Im >> justmissing something! >> >> Simon. >> >> sub responseHeader { >> # <<<<<<< CommonSubs.pm >> >> warn "responseHeader Called..\n"; >> >> my ($auth) = @_; >> # ======= >> use HTML::Entities (); >> my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); >> # >>>>>>> 1.50 >> $auth ||="not_provided"; >> $notes ||=""; >> my $xml = "". >> "> xmlns:moby='http://www.biomoby.org/moby'xmlns='http:// >> www.biomoby.org/moby'>". >> ""; >> if ($notes){ >> my $encodednotes = HTML::Entities::encode($notes); >> $xml.="$encodednotes"; >> } >> return $xml; >> } >> >> >> -- >> >> 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 > -- > Mark Wilkinson (mwilkinson at mrl.ubc.ca) > University of British Columbia iCAPTURE Centre > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From mwilkinson at mobile.rogers.com Wed Jun 16 17:52:37 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed, 16 Jun 2004 17:52:37 -0400 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162200.i5GM0fKr007166@portal.open-bio.org> Oh, I dunno Simon... But thanks for your (misplaced) faith :-) There were a couple of hours a few days ago where I broke things badly! Hence my impetus to finally set up a development server in Halifax. However, you are right - I am trying to be much more careful now that we have so many users. Generally I install the changes on my local server first and run the test suites. From now on I will install it remotely on the dev server and test it there as well before finally committing it to the production registry!! It's a dangerous time code-wise, as I am now going through the entire codebase and rearranging it to reflect a better architecture and design philosophy (to actually *have* a design philosophy, for a start ;-) ). There's a lot of opportunity for error in there, but hopefully the code will become easier to maintain/extend once it's done. Cheers all! I'm off to Winnipeg (the belly-button of Canada) to teach bioperl-for-newbies for a few days, so I'll be out of touch until Monday. Martin, I'll see you in Manila in a couple of weeks - hopefully we can push forward the CGIAR MOBY plans there! ...exciting times!!!! M -----Original Message----- From: Simon Twigger Date: Wed, 16 Jun 2004 14:57:27 To:markw at illuminae.com, Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm This makes sense, it did seem odd that you would commit something that broke everything! Cheers, Simon. On Jun 16, 2004, at 2:25 PM, Mark Wilkinson wrote: > Hi Simon, > > This is likely specific to you - it looks like you have done some > tweaking of that part of the code, which caused a CVS versioning > conflict when you merged the public code into your own (the <<<<< and >>>>>> sections reveal what the conflict was) just pick the more recent > one and delete the rest. > > cheers! > > M > > > On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: >> Hi Mark, >> >> I updated my copy of the cvs today to get CommonSubs working with >> myservices - I had been using some of Ken's modules before. >> >> To get it to work I had to go in and hack the code >> aroundCommonSubs::responseHeader() (See below) >> >> I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they >> were causing things to break, Im guessing they were diffannotations or >> similar? >> >> >> Thought Id let you know, I didnt want to mess with the CVS >> bycommitting anything just in case its meant to be like this and Im >> justmissing something! >> >> Simon. >> >> sub responseHeader { >> # <<<<<<< CommonSubs.pm >> >> warn "responseHeader Called..\n"; >> >> my ($auth) = @_; >> # ======= >> use HTML::Entities (); >> my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); >> # >>>>>>> 1.50 >> $auth ||="not_provided"; >> $notes ||=""; >> my $xml = "". >> "> xmlns:moby='http://www.biomoby.org/moby'xmlns='http:// >> www.biomoby.org/moby'>". >> ""; >> if ($notes){ >> my $encodednotes = HTML::Entities::encode($notes); >> $xml.="$encodednotes"; >> } >> return $xml; >> } >> >> >> -- >> >> 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 > -- > Mark Wilkinson (mwilkinson at mrl.ubc.ca) > University of British Columbia iCAPTURE Centre > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Wed Jun 16 18:05:44 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 16 Jun 2004 23:05:44 +0100 (BST) Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <200406162200.i5GM0fKr007166@portal.open-bio.org> Message-ID: > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From mwilkinson at mobile.rogers.com Wed Jun 16 18:08:35 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed, 16 Jun 2004 18:08:35 -0400 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162215.i5GMFcKr007508@portal.open-bio.org> Yeah, I'm really looking forward to it... And the timing couldn't be better as I am heading into another round of intensive grant writing, so this is a great moment to start laying the plans for world domination, and to get paid to execute them ;-) B.t.w. Is there any functionality that you would like to see completed before we meet? I have about a week of "free time" to dedicate to coding before I arrive in Manila, so I could focus on those aspects of MOBY to get them done before we get there. Let me know. Looking forward to seeing you! M -----Original Message----- From: Martin Senger Date: Wed, 16 Jun 2004 23:05:44 To:mwilkinson , Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Wed Jun 16 18:27:15 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed, 16 Jun 2004 18:27:15 -0400 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162234.i5GMYLKr007783@portal.open-bio.org> Actually, what excites me most about this is that an organization like CGIAR is planning to make use of the tools that we have been building for these past two years. MOBY has moved from being an exploratory exercise for a bunch of bioinfo geeks, to being a project that actually has the potential to help people! I'm quite anxious to make sure that it lives up to, or beats, their expectations... Like I said, exciting times!! M -----Original Message----- From: "mwilkinson" Date: Wed, 16 Jun 2004 18:08:35 To:senger at ebi.ac.uk;moby-dev at portal.open-bio.org Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm Yeah, I'm really looking forward to it... And the timing couldn't be better as I am heading into another round of intensive grant writing, so this is a great moment to start laying the plans for world domination, and to get paid to execute them ;-) B.t.w. Is there any functionality that you would like to see completed before we meet? I have about a week of "free time" to dedicate to coding before I arrive in Manila, so I could focus on those aspects of MOBY to get them done before we get there. Let me know. Looking forward to seeing you! M -----Original Message----- From: Martin Senger Date: Wed, 16 Jun 2004 23:05:44 To:mwilkinson , Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Thu Jun 17 03:31:24 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 17 Jun 2004 08:31:24 +0100 (BST) Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <200406162212.i5GMCuF29366@maui.ebi.ac.uk> Message-ID: > B.t.w. Is there any functionality that you would like to see completed > before we meet? > No, I do not have yet precise plan what to work on when there. Obviously, very important will be to work on their particular problems - but that would not need any new code in the current BioMoby I guess. But if time allows I would like to work on one the following issues: * LSID metadata server for moby registry (as we discussed in CSHL), or * More Java support for service providers (in the similar - or less similar, I do not know yet - direction where Paul started it) Would you have any preferences for *me* to work on, perhaps? Btw, when are you coming to Manila? Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From boris.steipe at utoronto.ca Thu Jun 17 08:59:42 2004 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Thu, 17 Jun 2004 07:59:42 -0500 Subject: [MOBY-dev] LSIDs for registry Was: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: Message-ID: <330BA12E-C05E-11D8-9695-000A9577512E@utoronto.ca> Martin, what are you planning to do ? Assign LSIDs to registered MOBY services ? Or data or service types ? Could you clue me in? (I'm just working on LSIDifying the lab, specifically with a view how to connect this all with MOBY). Warm regards, Boris ============= On Thursday, Jun 17, 2004, at 02:31 America/Winnipeg, Martin Senger wrote: > * LSID metadata server for moby registry (as we discussed in CSHL) From senger at ebi.ac.uk Thu Jun 17 13:54:08 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 17 Jun 2004 18:54:08 +0100 (BST) Subject: [MOBY-dev] LSIDs for registry Was: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <330BA12E-C05E-11D8-9695-000A9577512E@utoronto.ca> Message-ID: > what are you planning to do ? Assign LSIDs to registered MOBY services > ? Or data or service types ? Could you clue me in? > The idea is to have somewhere repository of metadata attached to individual services. Actually, to allow to have more metadata repositories. The problem is who knows where these repositories are. Ideally, the one who is the issueing authority for LSIDs representing services should be also able to "resolve requests for metadata for these LSIDs". And it is the Moby Central. The solution we have discussed at the last moby developer meeting would/could be (at least what I remember, I need to double check with Mark): * to have an LSID resolution service as a part of each Moby Central * there will be a normal Moby-native service that would know about various metadata repositories (so metadata providers may register their repositories with this service) * now, when a Moby Central (actually its resolution service) gets a request for metadata, it asks this special service to get back known metadata repositories What is needed to be coded is: * a Moby Central LSID Resolution service - which I believe already exists (or almost) * a service registering metadata repositories: should this be just another biomoby registry, or something specific?... * an implementation of at least one metadata repository Obviously, I would prefer to clarify it first with Mark in person - I hope that meeting him in Manila in couple of weeks will help to this. With regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From r.bruskiewich at cgiar.org Thu Jun 17 05:50:27 2004 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Thu, 17 Jun 2004 02:50:27 -0700 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <5B37FD42AEA6C447B407B01116A40B6D5DD9BE@IRRIMAIL.irri.cgiar.org> Would there be any thought about reviewing/enriching the data and service type ontologies, and/or considering the merits of S-MOBY to MOBY-S merger (at the level of the data/service type representation)? I know... Radical... But hey, I'm willing to explore the lay of the land. One issue I *know* might come up is the one I previously mentioned: development of a MOBY Central local to our crop community (in this case, the Generation Challenge Program). We can probably debate the relative merits of this when you both come. Richard -----Original Message----- From: Martin Senger [mailto:senger at ebi.ac.uk] Sent: Thursday, June 17, 2004 3:31 PM To: mwilkinson Cc: moby-dev at portal.open-bio.org; Bruskiewich, Richard (IRRI) Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > B.t.w. Is there any functionality that you would like to see completed > before we meet? > No, I do not have yet precise plan what to work on when there. Obviously, very important will be to work on their particular problems - but that would not need any new code in the current BioMoby I guess. But if time allows I would like to work on one the following issues: * LSID metadata server for moby registry (as we discussed in CSHL), or * More Java support for service providers (in the similar - or less similar, I do not know yet - direction where Paul started it) Would you have any preferences for *me* to work on, perhaps? Btw, when are you coming to Manila? Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From yanwong at ebgm.jussieu.fr Thu Jun 24 08:13:45 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 24 Jun 2004 14:13:45 +0200 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <1088079225.12763.21.camel@prot1.rpbs.jussieu.fr> I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? From mwilkinson at mobile.rogers.com Thu Jun 24 10:00:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 24 Jun 2004 10:00:10 -0400 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <200406241403.i5OE3ZKr004151@portal.open-bio.org> This is likely a bug - I'll have a look in a couple of hours and fix it ASAP. M -----Original Message----- From: Yan Wong Date: 24 Jun 2004 14:13:45 To:bioMoby Developer list Subject: [MOBY-dev] I would like some explanations about findService I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Thu Jun 24 10:00:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 24 Jun 2004 10:00:10 -0400 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <200406241403.i5OE3cKr004155@portal.open-bio.org> This is likely a bug - I'll have a look in a couple of hours and fix it ASAP. M -----Original Message----- From: Yan Wong Date: 24 Jun 2004 14:13:45 To:bioMoby Developer list Subject: [MOBY-dev] I would like some explanations about findService I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mrl.ubc.ca Wed Jun 30 17:16:50 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 30 Jun 2004 14:16:50 -0700 Subject: [MOBY-dev] Sesame? Message-ID: <1088630210.2105.237.camel@myhost.mydomain> Hey, has anyone got experience with Sesame? I'm reading their paper and it sounds too good to be true w.r.t. future plans of moving MOBY Central & the MOBY Ontologies to a pure RDF representation... I'd be interested to hear other's experience with it! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From adf at ncgr.org Wed Jun 30 17:41:47 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 15:41:47 -0600 (MDT) Subject: [MOBY-dev] Sesame? In-Reply-To: <1088630210.2105.237.camel@myhost.mydomain> Message-ID: Hi Mark- I did some experimenting with Sesame for a bit when I was more actively involved; it seemed to be a reasonably robust system in terms of supporting persistance and querying; IIRC, it uses a forward-chaining type strategy for inference, such that whenever a new statement is added to the model, it will attempt to infer all consequences of that new statement in conjunction with its current knowledge base, but I think its rules of inference were relatively simple- transitive closure over subtypes, and that sort of thing; depending on how intelligent you imagine the ontologies will need to be vis-a-vis dynamic classification (some of the things I think Simon and Phil have discussed in the past), you may not get the inferencing power you want from Sesame- but I suppose you could put a more powerful inference engine as a front end for updates and then use sesame as a persistance and query mechanism, or something like that. HTH On Wed, 30 Jun 2004, Mark Wilkinson wrote: > Hey, > > has anyone got experience with Sesame? I'm reading their paper and it > sounds too good to be true w.r.t. future plans of moving MOBY Central & > the MOBY Ontologies to a pure RDF representation... I'd be interested > to hear other's experience with it! > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From adf at ncgr.org Wed Jun 30 17:41:47 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 15:41:47 -0600 (MDT) Subject: [MOBY-dev] Sesame? In-Reply-To: <1088630210.2105.237.camel@myhost.mydomain> Message-ID: Hi Mark- I did some experimenting with Sesame for a bit when I was more actively involved; it seemed to be a reasonably robust system in terms of supporting persistance and querying; IIRC, it uses a forward-chaining type strategy for inference, such that whenever a new statement is added to the model, it will attempt to infer all consequences of that new statement in conjunction with its current knowledge base, but I think its rules of inference were relatively simple- transitive closure over subtypes, and that sort of thing; depending on how intelligent you imagine the ontologies will need to be vis-a-vis dynamic classification (some of the things I think Simon and Phil have discussed in the past), you may not get the inferencing power you want from Sesame- but I suppose you could put a more powerful inference engine as a front end for updates and then use sesame as a persistance and query mechanism, or something like that. HTH On Wed, 30 Jun 2004, Mark Wilkinson wrote: > Hey, > > has anyone got experience with Sesame? I'm reading their paper and it > sounds too good to be true w.r.t. future plans of moving MOBY Central & > the MOBY Ontologies to a pure RDF representation... I'd be interested > to hear other's experience with it! > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From markw at illuminae.com Wed Jun 30 17:44:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 30 Jun 2004 14:44:02 -0700 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: References: Message-ID: <1088631841.1967.246.camel@myhost.mydomain> On Wed, 2004-06-30 at 14:41, Andrew D. Farmer wrote: > current knowledge base, but I think its rules of inference were relatively > simple- transitive closure over subtypes, Right - it sounds like it handles (i.e. "understands") only RDFS predicates... but even that is a joy! Do you have a feeling for how it compares to Jena v.v. speed and features? From the paper they are describing it as "Jena plus", but there may be features in Jena that are more powerful...?? M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Wed Jun 30 17:44:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 30 Jun 2004 14:44:02 -0700 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: References: Message-ID: <1088631841.1967.246.camel@myhost.mydomain> On Wed, 2004-06-30 at 14:41, Andrew D. Farmer wrote: > current knowledge base, but I think its rules of inference were relatively > simple- transitive closure over subtypes, Right - it sounds like it handles (i.e. "understands") only RDFS predicates... but even that is a joy! Do you have a feeling for how it compares to Jena v.v. speed and features? From the paper they are describing it as "Jena plus", but there may be features in Jena that are more powerful...?? M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From adf at ncgr.org Wed Jun 30 19:28:48 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 17:28:48 -0600 (MDT) Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: <1088631841.1967.246.camel@myhost.mydomain> Message-ID: > Do you have a feeling for how it compares to Jena v.v. speed and > features? From the paper they are describing it as "Jena plus", but > there may be features in Jena that are more powerful...?? When was the paper written? I seem to recall that at the time I was looking at sesame, jena was a fairly bare-bones api for rdf manipulation (I don't think at that time it supported persistance to an rdbms), but since then it seems to have flourished in many directions. My impression is that Jena is better designed for pluggable implementations of things like inference and persistance than sesame. OTOH, I think at this point sesame may still support a greater variety of query languages than does jena, and comes complete with a easy-to-use servlet interface for admin and query/browse of datastores. Gary knows much more about jena than I do, and might be able to give you more detailed info. Jena appears to have a larger active development community, which is no small consideration... > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From adf at ncgr.org Wed Jun 30 19:28:48 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 17:28:48 -0600 (MDT) Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: <1088631841.1967.246.camel@myhost.mydomain> Message-ID: > Do you have a feeling for how it compares to Jena v.v. speed and > features? From the paper they are describing it as "Jena plus", but > there may be features in Jena that are more powerful...?? When was the paper written? I seem to recall that at the time I was looking at sesame, jena was a fairly bare-bones api for rdf manipulation (I don't think at that time it supported persistance to an rdbms), but since then it seems to have flourished in many directions. My impression is that Jena is better designed for pluggable implementations of things like inference and persistance than sesame. OTOH, I think at this point sesame may still support a greater variety of query languages than does jena, and comes complete with a easy-to-use servlet interface for admin and query/browse of datastores. Gary knows much more about jena than I do, and might be able to give you more detailed info. Jena appears to have a larger active development community, which is no small consideration... > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From gss at ncgr.org Wed Jun 30 20:30:43 2004 From: gss at ncgr.org (Gary Schiltz) Date: Wed, 30 Jun 2004 18:30:43 -0600 Subject: [MOBY-dev] Sesame? Message-ID: <40E35B33.7070206@ncgr.org> I looked at Sesame when I was trying to decide on the best architecture on top of which to implement S-MOBY (about 6 months ago). While it looked like a good tool, it didn't seem to be very actively maintained at the time. I just looked at the Sesame web site (www.openrdf.org), and it looks like the user forums have had a bit of traffic, so maybe it's more active than before. In the end, I settled on Jena (jena.sourceforge.net) as the underlying framework for working with RDF. It is quite actively supported by HP, and also seems to have an active user community. At least, its mailing list gets a large number of messages every day. // Gary From yanwong at ebgm.jussieu.fr Thu Jun 3 12:24:59 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 03 Jun 2004 14:24:59 +0200 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <1086265499.19817.24.camel@prot1.rpbs.jussieu.fr> I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! From mwilkinson at mobile.rogers.com Thu Jun 3 12:43:58 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 3 Jun 2004 08:43:58 -0400 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <200406031253.i53CrCKr019215@portal.open-bio.org> That's fantastic! Would you like to add this to the biomoby CVS? M -----Original Message----- From: Yan Wong Date: 03 Jun 2004 14:24:59 To:moby-dev at biomoby.org Subject: [MOBY-dev] a bioMoby Python API I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Thu Jun 3 12:43:58 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 3 Jun 2004 08:43:58 -0400 Subject: [MOBY-dev] a bioMoby Python API Message-ID: <200406031253.i53CrDKr019219@portal.open-bio.org> That's fantastic! Would you like to add this to the biomoby CVS? M -----Original Message----- From: Yan Wong Date: 03 Jun 2004 14:24:59 To:moby-dev at biomoby.org Subject: [MOBY-dev] a bioMoby Python API I have developed a Python interface for bioMoby. You can retrieve the source package at http://bioserv.rpbs.jussieu.fr/RPBS/html/an/T0_Software.html Suggestions welcome! _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mrl.ubc.ca Thu Jun 3 19:38:53 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 03 Jun 2004 12:38:53 -0700 Subject: [MOBY-dev] the rate of growth of MOBY Message-ID: <1086291533.1617.316.camel@myhost.mydomain> Hi all, I found these statistics quite interesting, so I thought I'd share them: The total number of hits on the public mobycentral machine (registry, ontology servers, and my own services) has quadrupled since January, and the number of calls to the MOBY Central API alone has now reached >40K per month! There are a lot of closet MOBYers out there!! What is reassuring is that, given our small messages, we have only transferred 1.1Gig since January, so that leaves a lot of room for expansion :-) Cheers all! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Jun 3 22:21:08 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 03 Jun 2004 15:21:08 -0700 Subject: [MOBY-dev] Bug Reports now accepted Message-ID: <1086301268.8080.13.camel@myhost.mydomain> Hi all, Someone (I forget who) requested a more formal bug-reporting procedure for the MOBY project, and that is now done. We're piggybacking on the open-bio "bugzilla" reporting system, and have our own little piece of that pie. I've set up a few slots for various MOBY-S components (Damian, please go ahead and set up whatever slots you wish). If you click on the new "BUGS" link on the homepage it will take you to the bug reporting/browsing page where you can submit your bug report and follow its progress to being squashed. Hopefully this will help us keep track of what still needs to be written/fixed, and give others incentive to jump in a do some bug-squashing themselves :-) Cheers all! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From yanwong at ebgm.jussieu.fr Fri Jun 4 08:22:40 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 04 Jun 2004 10:22:40 +0200 Subject: [MOBY-dev] How to add the bioMoby-python API to the CVS? Message-ID: <1086337360.1961.4.camel@prot1.rpbs.jussieu.fr> Yes, I can add the API to the CVS, How should I post it? From mwilkinson at mrl.ubc.ca Tue Jun 8 15:40:43 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 08 Jun 2004 08:40:43 -0700 Subject: [MOBY-dev] RDF descriptions of MOBY services Message-ID: <1086709242.2691.58.camel@myhost.mydomain> Hi all, Nina and I are debating the most appropriate way to represent a MOBY service signature in RDF. The main source of controversy is with the inputs and outputs, in particular when it comes to collections. In the current draft, I have the input as a bnode type:Bag, with individual input articles coming off of it. Input articles in MOBY are either Simple or Collection, however at the moment I have made this distinction implicit - if the article is type:Bag, then it must be a Collection, and if it is not type:Bag, then it represents a Simple, and has various information (object_type, namespace, etc.) predicated to it. What concerns me is this: If we make the interpretation implicit, then we don't need additional predicates, whereas if we explicitly define the edge to an article as "has_simple", or "has_collection", then these predicates need to be defined. The data structure (Bag) is semantically identical (IMO) to what a Collection article is in MOBY, so I don't see a *need* to explicitly define this... but under either circumstance the person designing a query or a parser would need to understand how to interpret either the "shape" of the graph (if we leave it implicit), or the meanings of the predicates (if we make it explicit). ...?? This never ceases to befuddle me. It seems that, even with RDF, we can not get away from the requirement of community agreement on interpretation. I guess this reminds me of Phil's recurring statement "ontologies are only useful if they are shared"... ...but from those of you with more experience in RDF than I have, could you advise me which of these two options is "more correct"? Is it better to be explicit, and define new project-specific predicates, or is it better to let the data structure implicitly speak for itself using existing RDF/S predicates? Your wisdom is welcome! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From p.lord at russet.org.uk Tue Jun 8 16:36:44 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 08 Jun 2004 17:36:44 +0100 Subject: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: <1086709242.2691.58.camel@myhost.mydomain> References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Hi all, Mark> Nina and I are debating the most appropriate way to represent Mark> a MOBY service signature in RDF. The main source of Mark> controversy is with the inputs and outputs, in particular when Mark> it comes to collections. Mark> In the current draft, I have the input as a bnode type:Bag, Mark> with individual input articles coming off of it. Input Mark> articles in MOBY are either Simple or Collection, however at Mark> the moment I have made this distinction implicit - if the Mark> article is type:Bag, then it must be a Collection, and if it Mark> is not type:Bag, then it represents a Simple, and has various Mark> information (object_type, namespace, etc.) predicated to it. Mark> What concerns me is this: If we make the interpretation Mark> implicit, then we don't need additional predicates, whereas if Mark> we explicitly define the edge to an article as "has_simple", Mark> or "has_collection", then these predicates need to be defined. Mark> The data structure (Bag) is semantically identical (IMO) to Mark> what a Collection article is in MOBY, so I don't see a *need* Mark> to explicitly define this... but under either circumstance the Mark> person designing a query or a parser would need to understand Mark> how to interpret either the "shape" of the graph (if we leave Mark> it implicit), or the meanings of the predicates (if we make it Mark> explicit). Mark> ...?? This never ceases to befuddle me. It seems that, even Mark> with RDF, we can not get away from the requirement of Mark> community agreement on interpretation. I guess this reminds Mark> me of Phil's recurring statement "ontologies are only useful Mark> if they are shared"... Mark> ...but from those of you with more experience in RDF than I Mark> have, could you advise me which of these two options is "more Mark> correct"? Is it better to be explicit, and define new Mark> project-specific predicates, or is it better to let the data Mark> structure implicitly speak for itself using existing RDF/S Mark> predicates? Mark I'm not convinced that it makes any difference. Either way you have to have an interpretation of the RDF wrt to the application at hand. This is the same with all uses of RDF; the RDF serialisation of OWL-DL, for example, does not tell you how to interpret the semantics of OWL-DL. You have to read the OWL spec for that. Cheers Phil From p.lord at russet.org.uk Tue Jun 8 16:36:44 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 08 Jun 2004 17:36:44 +0100 Subject: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: <1086709242.2691.58.camel@myhost.mydomain> References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> Hi all, Mark> Nina and I are debating the most appropriate way to represent Mark> a MOBY service signature in RDF. The main source of Mark> controversy is with the inputs and outputs, in particular when Mark> it comes to collections. Mark> In the current draft, I have the input as a bnode type:Bag, Mark> with individual input articles coming off of it. Input Mark> articles in MOBY are either Simple or Collection, however at Mark> the moment I have made this distinction implicit - if the Mark> article is type:Bag, then it must be a Collection, and if it Mark> is not type:Bag, then it represents a Simple, and has various Mark> information (object_type, namespace, etc.) predicated to it. Mark> What concerns me is this: If we make the interpretation Mark> implicit, then we don't need additional predicates, whereas if Mark> we explicitly define the edge to an article as "has_simple", Mark> or "has_collection", then these predicates need to be defined. Mark> The data structure (Bag) is semantically identical (IMO) to Mark> what a Collection article is in MOBY, so I don't see a *need* Mark> to explicitly define this... but under either circumstance the Mark> person designing a query or a parser would need to understand Mark> how to interpret either the "shape" of the graph (if we leave Mark> it implicit), or the meanings of the predicates (if we make it Mark> explicit). Mark> ...?? This never ceases to befuddle me. It seems that, even Mark> with RDF, we can not get away from the requirement of Mark> community agreement on interpretation. I guess this reminds Mark> me of Phil's recurring statement "ontologies are only useful Mark> if they are shared"... Mark> ...but from those of you with more experience in RDF than I Mark> have, could you advise me which of these two options is "more Mark> correct"? Is it better to be explicit, and define new Mark> project-specific predicates, or is it better to let the data Mark> structure implicitly speak for itself using existing RDF/S Mark> predicates? Mark I'm not convinced that it makes any difference. Either way you have to have an interpretation of the RDF wrt to the application at hand. This is the same with all uses of RDF; the RDF serialisation of OWL-DL, for example, does not tell you how to interpret the semantics of OWL-DL. You have to read the OWL spec for that. Cheers Phil From markw at illuminae.com Tue Jun 8 22:43:18 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 08 Jun 2004 15:43:18 -0700 Subject: [MOBY] Re: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: <1086734598.3559.20.camel@myhost.mydomain> > Mark > > I'm not convinced that it makes any difference. Either way you have to > have an interpretation of the RDF wrt to the application at > hand. That's what I thought. So if there isn't an accepted convention, I think I would prefer to avoid creating specific predicates. Cheers Phil! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Jun 8 22:43:18 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 08 Jun 2004 15:43:18 -0700 Subject: [MOBY] Re: [MOBY-dev] RDF descriptions of MOBY services In-Reply-To: References: <1086709242.2691.58.camel@myhost.mydomain> Message-ID: <1086734598.3559.20.camel@myhost.mydomain> > Mark > > I'm not convinced that it makes any difference. Either way you have to > have an interpretation of the RDF wrt to the application at > hand. That's what I thought. So if there isn't an accepted convention, I think I would prefer to avoid creating specific predicates. Cheers Phil! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From yanwong at ebgm.jussieu.fr Fri Jun 11 11:32:20 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 11 Jun 2004 13:32:20 +0200 Subject: [MOBY-dev] Support for object polymorphism Message-ID: <1086953540.2119.3.camel@prot1.rpbs.jussieu.fr> For example, if someone has a PDB, you can either have an ID, or a plain text PDB or stored in a compressed way, is there any way to register that in bioMoby? From yanwong at ebgm.jussieu.fr Fri Jun 11 11:34:03 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 11 Jun 2004 13:34:03 +0200 Subject: [MOBY-dev] for the polymorphism Message-ID: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> For example a service can accept either a object with namespace PDB or a plain text that is a PDB or anything else... How would this service, be registrated? From markw at illuminae.com Fri Jun 11 16:09:27 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 11 Jun 2004 09:09:27 -0700 Subject: [MOBY] [MOBY-dev] for the polymorphism In-Reply-To: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> References: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> Message-ID: <1086970167.9793.67.camel@myhost.mydomain> Hi, There is a limitation in the current version of MOBY in that a service instance has strictly defined inputs and outputs - no "either/or" allowed. As such, your scenario would require registration of two service instances (though on the server-side they may well be handled by the same piece of code...) I must point out, however, that it would be quite peculiar for an object representing a PDB record not to have a PDB number in its namespace/id attributes, so I guess in principle I doubt that you would really need to create both services... However, if you feel there is a need for both, then I think you would also be well-advised to create a new Object representing a PDB record that inherits from text-formatted (PDB_Record ISA text_formatted, or something like that). This would allow you to specifically consume PDB records that may or may not have a PDB ID. I hope that helps! M On Fri, 2004-06-11 at 04:34, Yan Wong wrote: > For example a service can accept either a object with namespace PDB > or a plain text that is a PDB or anything else... > > How would this service, be registrated? > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Fri Jun 11 16:09:27 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Fri, 11 Jun 2004 09:09:27 -0700 Subject: [MOBY] [MOBY-dev] for the polymorphism In-Reply-To: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> References: <1086953643.2210.1.camel@prot1.rpbs.jussieu.fr> Message-ID: <1086970167.9793.67.camel@myhost.mydomain> Hi, There is a limitation in the current version of MOBY in that a service instance has strictly defined inputs and outputs - no "either/or" allowed. As such, your scenario would require registration of two service instances (though on the server-side they may well be handled by the same piece of code...) I must point out, however, that it would be quite peculiar for an object representing a PDB record not to have a PDB number in its namespace/id attributes, so I guess in principle I doubt that you would really need to create both services... However, if you feel there is a need for both, then I think you would also be well-advised to create a new Object representing a PDB record that inherits from text-formatted (PDB_Record ISA text_formatted, or something like that). This would allow you to specifically consume PDB records that may or may not have a PDB ID. I hope that helps! M On Fri, 2004-06-11 at 04:34, Yan Wong wrote: > For example a service can accept either a object with namespace PDB > or a plain text that is a PDB or anything else... > > How would this service, be registrated? > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Tue Jun 15 15:03:48 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 15 Jun 2004 08:03:48 -0700 Subject: [MOBY-dev] TEST MOBY Central registry available Message-ID: <1087311828.2155.99.camel@myhost.mydomain> Hi all, Yeah yeah yeah, I know it has been a long time coming! Yesterday I made some changes to the registry code that allowed it to read its configuration from a config file, pointed to by an environment variable in apache. This made it easier to run multiple instances of apache each with a different registry configuration. (Rebecca - this is something that your sysadmin requested ages ago! please tell him it is now done...) As such, there is now a test version of the registry running at mobycentral and you can feel free to mess that one up as much as you wish. There is currently no GUI client pointing to that, but you can interact with it using the client-side libraries. The test registry is a snapshot of how the "real" registry looked this morning, but it is running from its own set of mySQL databases, so feel free to add/remove/play because you wont harm the real registry nor the real ontologies (touch wood...) The URL and URI for the test registry are: URL 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl' URI 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' For those of you using my Perl libraries to connect, simply create an instance of the MOBY::Client::Central as follows: my $C = MOBY::Client::Central->new( Registries => { mobycentral => { URL => 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl', URI => 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' } } ); and then use the module as you normally would. The perl test suite also uses the test instance of the registry now, so "TotalCrap" should no longer appear as a valid object in our ontologies ;-) Cheers all! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Tue Jun 15 16:14:07 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Tue, 15 Jun 2004 09:14:07 -0700 Subject: [MISC] [MOBY-dev] TEST MOBY Central registry available In-Reply-To: <1087311828.2155.99.camel@myhost.mydomain> References: <1087311828.2155.99.camel@myhost.mydomain> Message-ID: <1087316047.2155.120.camel@myhost.mydomain> Note that 'URL' in the message below does not refer to a human-readable web interface. It is the location of the test MOBY Central SOAP server. I have a student, Eddie, who is currently building a GUI interface for service registration, and that should be up in the next few weeks. M On Tue, 2004-06-15 at 08:03, Mark Wilkinson wrote: > Hi all, > > Yeah yeah yeah, I know it has been a long time coming! > > Yesterday I made some changes to the registry code that allowed it to > read its configuration from a config file, pointed to by an environment > variable in apache. This made it easier to run multiple instances of > apache each with a different registry configuration. (Rebecca - this is > something that your sysadmin requested ages ago! please tell him it is > now done...) > > As such, there is now a test version of the registry running at > mobycentral and you can feel free to mess that one up as much as you > wish. There is currently no GUI client pointing to that, but you can > interact with it using the client-side libraries. > > The test registry is a snapshot of how the "real" registry looked this > morning, but it is running from its own set of mySQL databases, so feel > free to add/remove/play because you wont harm the real registry nor the > real ontologies (touch wood...) > > The URL and URI for the test registry are: > > URL 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl' > > URI 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' > > > For those of you using my Perl libraries to connect, simply create an > instance of the MOBY::Client::Central as follows: > > my $C = MOBY::Client::Central->new( > Registries => { > mobycentral => { URL => > 'http://mobycentral.cbr.nrc.ca:8080/cgi-bin/MOBY05/mobycentral.pl', > URI => 'http://mobycentral.cbr.nrc.ca:8080/MOBY/Central' > } > } > ); > > and then use the module as you normally would. The perl test suite also > uses the test instance of the registry now, so "TotalCrap" should no > longer appear as a valid object in our ontologies ;-) > > Cheers all! > > M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Wed Jun 16 00:51:25 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 15 Jun 2004 17:51:25 -0700 Subject: [MOBY-dev] SQL table change Message-ID: <1087347085.2055.63.camel@myhost.mydomain> Hi dev'ers I finally tracked down (one of) the reasons that the registration of secondary parameters is so troublesome. The database definition is contrary to the API! For those of you running a local registry: To patch the database, execute the following SQL on the mobycentral database: alter table secondary_input change datatype datatype enum('String', 'Integer', 'DateTime', 'Float'); I have updated the main mobycentral database already. I'm about to make a bunch of commits that should fix all remaining problems with secondary parameters. Sorry for the trouble! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Wed Jun 16 19:20:46 2004 From: simont at mcw.edu (Simon Twigger) Date: Wed, 16 Jun 2004 14:20:46 -0500 Subject: [MOBY-dev] CommonSubs.pm Message-ID: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> Hi Mark, I updated my copy of the cvs today to get CommonSubs working with my services - I had been using some of Ken's modules before. To get it to work I had to go in and hack the code around CommonSubs::responseHeader() (See below) I had to comment out the <<<<<<<, ========= and >>>>>>>>> lines as they were causing things to break, Im guessing they were diff annotations or similar? Thought Id let you know, I didnt want to mess with the CVS by committing anything just in case its meant to be like this and Im just missing something! Simon. sub responseHeader { # <<<<<<< CommonSubs.pm warn "responseHeader Called..\n"; my ($auth) = @_; # ======= use HTML::Entities (); my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); # >>>>>>> 1.50 $auth ||="not_provided"; $notes ||=""; my $xml = "". "". ""; if ($notes){ my $encodednotes = HTML::Entities::encode($notes); $xml .="$encodednotes"; } return $xml; } -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From markw at illuminae.com Wed Jun 16 19:25:10 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 16 Jun 2004 12:25:10 -0700 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> References: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> Message-ID: <1087413909.15064.2.camel@myhost.mydomain> Hi Simon, This is likely specific to you - it looks like you have done some tweaking of that part of the code, which caused a CVS versioning conflict when you merged the public code into your own (the <<<<< and >>>>> sections reveal what the conflict was) just pick the more recent one and delete the rest. cheers! M On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: > Hi Mark, > > I updated my copy of the cvs today to get CommonSubs working with > myservices - I had been using some of Ken's modules before. > > To get it to work I had to go in and hack the code > aroundCommonSubs::responseHeader() (See below) > > I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they > were causing things to break, Im guessing they were diffannotations or > similar? > > > Thought Id let you know, I didnt want to mess with the CVS > bycommitting anything just in case its meant to be like this and Im > justmissing something! > > Simon. > > sub responseHeader { > # <<<<<<< CommonSubs.pm > > warn "responseHeader Called..\n"; > > my ($auth) = @_; > # ======= > use HTML::Entities (); > my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); > # >>>>>>> 1.50 > $auth ||="not_provided"; > $notes ||=""; > my $xml = "". > " xmlns:moby='http://www.biomoby.org/moby'xmlns='http://www.biomoby.org/moby'>". > ""; > if ($notes){ > my $encodednotes = HTML::Entities::encode($notes); > $xml.="$encodednotes"; > } > return $xml; > } > > > -- > > 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 -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From simont at mcw.edu Wed Jun 16 19:57:27 2004 From: simont at mcw.edu (Simon Twigger) Date: Wed, 16 Jun 2004 14:57:27 -0500 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <1087413909.15064.2.camel@myhost.mydomain> References: <44DD9AE7-BFCA-11D8-9A2B-000A959D1D82@mcw.edu> <1087413909.15064.2.camel@myhost.mydomain> Message-ID: <64DF3130-BFCF-11D8-9A2B-000A959D1D82@mcw.edu> This makes sense, it did seem odd that you would commit something that broke everything! Cheers, Simon. On Jun 16, 2004, at 2:25 PM, Mark Wilkinson wrote: > Hi Simon, > > This is likely specific to you - it looks like you have done some > tweaking of that part of the code, which caused a CVS versioning > conflict when you merged the public code into your own (the <<<<< and >>>>>> sections reveal what the conflict was) just pick the more recent > one and delete the rest. > > cheers! > > M > > > On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: >> Hi Mark, >> >> I updated my copy of the cvs today to get CommonSubs working with >> myservices - I had been using some of Ken's modules before. >> >> To get it to work I had to go in and hack the code >> aroundCommonSubs::responseHeader() (See below) >> >> I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they >> were causing things to break, Im guessing they were diffannotations or >> similar? >> >> >> Thought Id let you know, I didnt want to mess with the CVS >> bycommitting anything just in case its meant to be like this and Im >> justmissing something! >> >> Simon. >> >> sub responseHeader { >> # <<<<<<< CommonSubs.pm >> >> warn "responseHeader Called..\n"; >> >> my ($auth) = @_; >> # ======= >> use HTML::Entities (); >> my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); >> # >>>>>>> 1.50 >> $auth ||="not_provided"; >> $notes ||=""; >> my $xml = "". >> "> xmlns:moby='http://www.biomoby.org/moby'xmlns='http:// >> www.biomoby.org/moby'>". >> ""; >> if ($notes){ >> my $encodednotes = HTML::Entities::encode($notes); >> $xml.="$encodednotes"; >> } >> return $xml; >> } >> >> >> -- >> >> 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 > -- > Mark Wilkinson (mwilkinson at mrl.ubc.ca) > University of British Columbia iCAPTURE Centre > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From mwilkinson at mobile.rogers.com Wed Jun 16 21:52:37 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed, 16 Jun 2004 17:52:37 -0400 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162200.i5GM0fKr007166@portal.open-bio.org> Oh, I dunno Simon... But thanks for your (misplaced) faith :-) There were a couple of hours a few days ago where I broke things badly! Hence my impetus to finally set up a development server in Halifax. However, you are right - I am trying to be much more careful now that we have so many users. Generally I install the changes on my local server first and run the test suites. From now on I will install it remotely on the dev server and test it there as well before finally committing it to the production registry!! It's a dangerous time code-wise, as I am now going through the entire codebase and rearranging it to reflect a better architecture and design philosophy (to actually *have* a design philosophy, for a start ;-) ). There's a lot of opportunity for error in there, but hopefully the code will become easier to maintain/extend once it's done. Cheers all! I'm off to Winnipeg (the belly-button of Canada) to teach bioperl-for-newbies for a few days, so I'll be out of touch until Monday. Martin, I'll see you in Manila in a couple of weeks - hopefully we can push forward the CGIAR MOBY plans there! ...exciting times!!!! M -----Original Message----- From: Simon Twigger Date: Wed, 16 Jun 2004 14:57:27 To:markw at illuminae.com, Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm This makes sense, it did seem odd that you would commit something that broke everything! Cheers, Simon. On Jun 16, 2004, at 2:25 PM, Mark Wilkinson wrote: > Hi Simon, > > This is likely specific to you - it looks like you have done some > tweaking of that part of the code, which caused a CVS versioning > conflict when you merged the public code into your own (the <<<<< and >>>>>> sections reveal what the conflict was) just pick the more recent > one and delete the rest. > > cheers! > > M > > > On Wed, 2004-06-16 at 12:20, Simon Twigger wrote: >> Hi Mark, >> >> I updated my copy of the cvs today to get CommonSubs working with >> myservices - I had been using some of Ken's modules before. >> >> To get it to work I had to go in and hack the code >> aroundCommonSubs::responseHeader() (See below) >> >> I had to comment out the <<<<<<<, ========= and >>>>>>>>> linesas they >> were causing things to break, Im guessing they were diffannotations or >> similar? >> >> >> Thought Id let you know, I didnt want to mess with the CVS >> bycommitting anything just in case its meant to be like this and Im >> justmissing something! >> >> Simon. >> >> sub responseHeader { >> # <<<<<<< CommonSubs.pm >> >> warn "responseHeader Called..\n"; >> >> my ($auth) = @_; >> # ======= >> use HTML::Entities (); >> my ($auth, $notes) = &_rearrange([qw[AUTHORITY NOTE]], @_); >> # >>>>>>> 1.50 >> $auth ||="not_provided"; >> $notes ||=""; >> my $xml = "". >> "> xmlns:moby='http://www.biomoby.org/moby'xmlns='http:// >> www.biomoby.org/moby'>". >> ""; >> if ($notes){ >> my $encodednotes = HTML::Entities::encode($notes); >> $xml.="$encodednotes"; >> } >> return $xml; >> } >> >> >> -- >> >> 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 > -- > Mark Wilkinson (mwilkinson at mrl.ubc.ca) > University of British Columbia iCAPTURE Centre > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Wed Jun 16 22:05:44 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 16 Jun 2004 23:05:44 +0100 (BST) Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <200406162200.i5GM0fKr007166@portal.open-bio.org> Message-ID: > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From mwilkinson at mobile.rogers.com Wed Jun 16 22:08:35 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed, 16 Jun 2004 18:08:35 -0400 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162215.i5GMFcKr007508@portal.open-bio.org> Yeah, I'm really looking forward to it... And the timing couldn't be better as I am heading into another round of intensive grant writing, so this is a great moment to start laying the plans for world domination, and to get paid to execute them ;-) B.t.w. Is there any functionality that you would like to see completed before we meet? I have about a week of "free time" to dedicate to coding before I arrive in Manila, so I could focus on those aspects of MOBY to get them done before we get there. Let me know. Looking forward to seeing you! M -----Original Message----- From: Martin Senger Date: Wed, 16 Jun 2004 23:05:44 To:mwilkinson , Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Wed Jun 16 22:27:15 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed, 16 Jun 2004 18:27:15 -0400 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <200406162234.i5GMYLKr007783@portal.open-bio.org> Actually, what excites me most about this is that an organization like CGIAR is planning to make use of the tools that we have been building for these past two years. MOBY has moved from being an exploratory exercise for a bunch of bioinfo geeks, to being a project that actually has the potential to help people! I'm quite anxious to make sure that it lives up to, or beats, their expectations... Like I said, exciting times!! M -----Original Message----- From: "mwilkinson" Date: Wed, 16 Jun 2004 18:08:35 To:senger at ebi.ac.uk;moby-dev at portal.open-bio.org Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm Yeah, I'm really looking forward to it... And the timing couldn't be better as I am heading into another round of intensive grant writing, so this is a great moment to start laying the plans for world domination, and to get paid to execute them ;-) B.t.w. Is there any functionality that you would like to see completed before we meet? I have about a week of "free time" to dedicate to coding before I arrive in Manila, so I could focus on those aspects of MOBY to get them done before we get there. Let me know. Looking forward to seeing you! M -----Original Message----- From: Martin Senger Date: Wed, 16 Jun 2004 23:05:44 To:mwilkinson , Core developer announcements Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > Martin, I'll see you in Manila in a couple of weeks - hopefully we can > push forward the CGIAR MOBY plans there! ...exciting times!!!! > Yes, Mark, that's what I have just heard! Looking forward for yet another hackatlon! See you there, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Thu Jun 17 07:31:24 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 17 Jun 2004 08:31:24 +0100 (BST) Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <200406162212.i5GMCuF29366@maui.ebi.ac.uk> Message-ID: > B.t.w. Is there any functionality that you would like to see completed > before we meet? > No, I do not have yet precise plan what to work on when there. Obviously, very important will be to work on their particular problems - but that would not need any new code in the current BioMoby I guess. But if time allows I would like to work on one the following issues: * LSID metadata server for moby registry (as we discussed in CSHL), or * More Java support for service providers (in the similar - or less similar, I do not know yet - direction where Paul started it) Would you have any preferences for *me* to work on, perhaps? Btw, when are you coming to Manila? Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From boris.steipe at utoronto.ca Thu Jun 17 12:59:42 2004 From: boris.steipe at utoronto.ca (Boris Steipe) Date: Thu, 17 Jun 2004 07:59:42 -0500 Subject: [MOBY-dev] LSIDs for registry Was: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: Message-ID: <330BA12E-C05E-11D8-9695-000A9577512E@utoronto.ca> Martin, what are you planning to do ? Assign LSIDs to registered MOBY services ? Or data or service types ? Could you clue me in? (I'm just working on LSIDifying the lab, specifically with a view how to connect this all with MOBY). Warm regards, Boris ============= On Thursday, Jun 17, 2004, at 02:31 America/Winnipeg, Martin Senger wrote: > * LSID metadata server for moby registry (as we discussed in CSHL) From senger at ebi.ac.uk Thu Jun 17 17:54:08 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 17 Jun 2004 18:54:08 +0100 (BST) Subject: [MOBY-dev] LSIDs for registry Was: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm In-Reply-To: <330BA12E-C05E-11D8-9695-000A9577512E@utoronto.ca> Message-ID: > what are you planning to do ? Assign LSIDs to registered MOBY services > ? Or data or service types ? Could you clue me in? > The idea is to have somewhere repository of metadata attached to individual services. Actually, to allow to have more metadata repositories. The problem is who knows where these repositories are. Ideally, the one who is the issueing authority for LSIDs representing services should be also able to "resolve requests for metadata for these LSIDs". And it is the Moby Central. The solution we have discussed at the last moby developer meeting would/could be (at least what I remember, I need to double check with Mark): * to have an LSID resolution service as a part of each Moby Central * there will be a normal Moby-native service that would know about various metadata repositories (so metadata providers may register their repositories with this service) * now, when a Moby Central (actually its resolution service) gets a request for metadata, it asks this special service to get back known metadata repositories What is needed to be coded is: * a Moby Central LSID Resolution service - which I believe already exists (or almost) * a service registering metadata repositories: should this be just another biomoby registry, or something specific?... * an implementation of at least one metadata repository Obviously, I would prefer to clarify it first with Mark in person - I hope that meeting him in Manila in couple of weeks will help to this. With regards, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From r.bruskiewich at cgiar.org Thu Jun 17 09:50:27 2004 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Thu, 17 Jun 2004 02:50:27 -0700 Subject: [MOBY-dev] Re: [MISC] CommonSubs.pm Message-ID: <5B37FD42AEA6C447B407B01116A40B6D5DD9BE@IRRIMAIL.irri.cgiar.org> Would there be any thought about reviewing/enriching the data and service type ontologies, and/or considering the merits of S-MOBY to MOBY-S merger (at the level of the data/service type representation)? I know... Radical... But hey, I'm willing to explore the lay of the land. One issue I *know* might come up is the one I previously mentioned: development of a MOBY Central local to our crop community (in this case, the Generation Challenge Program). We can probably debate the relative merits of this when you both come. Richard -----Original Message----- From: Martin Senger [mailto:senger at ebi.ac.uk] Sent: Thursday, June 17, 2004 3:31 PM To: mwilkinson Cc: moby-dev at portal.open-bio.org; Bruskiewich, Richard (IRRI) Subject: Re: [MOBY-dev] Re: [MISC] CommonSubs.pm > B.t.w. Is there any functionality that you would like to see completed > before we meet? > No, I do not have yet precise plan what to work on when there. Obviously, very important will be to work on their particular problems - but that would not need any new code in the current BioMoby I guess. But if time allows I would like to work on one the following issues: * LSID metadata server for moby registry (as we discussed in CSHL), or * More Java support for service providers (in the similar - or less similar, I do not know yet - direction where Paul started it) Would you have any preferences for *me* to work on, perhaps? Btw, when are you coming to Manila? Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From yanwong at ebgm.jussieu.fr Thu Jun 24 12:13:45 2004 From: yanwong at ebgm.jussieu.fr (Yan Wong) Date: 24 Jun 2004 14:13:45 +0200 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <1088079225.12763.21.camel@prot1.rpbs.jussieu.fr> I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? From mwilkinson at mobile.rogers.com Thu Jun 24 14:00:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 24 Jun 2004 10:00:10 -0400 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <200406241403.i5OE3ZKr004151@portal.open-bio.org> This is likely a bug - I'll have a look in a couple of hours and fix it ASAP. M -----Original Message----- From: Yan Wong Date: 24 Jun 2004 14:13:45 To:bioMoby Developer list Subject: [MOBY-dev] I would like some explanations about findService I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Thu Jun 24 14:00:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Thu, 24 Jun 2004 10:00:10 -0400 Subject: [MOBY-dev] I would like some explanations about findService Message-ID: <200406241403.i5OE3cKr004155@portal.open-bio.org> This is likely a bug - I'll have a look in a couple of hours and fix it ASAP. M -----Original Message----- From: Yan Wong Date: 24 Jun 2004 14:13:45 To:bioMoby Developer list Subject: [MOBY-dev] I would like some explanations about findService I would like to know how does work the findService function, I tried with my API to make some queries: I am looking for services that accept FASTA objects: FASTA moby 0 1 0 This query returns a service: -BlastFastaVsArabiProteincoding which seems the be the only one accepting FASTA objects as inputs Now, I am looking for services that return FASTA objects: FASTA moby 0 1 0 I thought that findService would return me only services that return a FASTA object but this time, it returns me 115 services?! (which seems to be all registrated services) Did I make any mistakes in my query? _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mrl.ubc.ca Wed Jun 30 21:16:50 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 30 Jun 2004 14:16:50 -0700 Subject: [MOBY-dev] Sesame? Message-ID: <1088630210.2105.237.camel@myhost.mydomain> Hey, has anyone got experience with Sesame? I'm reading their paper and it sounds too good to be true w.r.t. future plans of moving MOBY Central & the MOBY Ontologies to a pure RDF representation... I'd be interested to hear other's experience with it! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From adf at ncgr.org Wed Jun 30 21:41:47 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 15:41:47 -0600 (MDT) Subject: [MOBY-dev] Sesame? In-Reply-To: <1088630210.2105.237.camel@myhost.mydomain> Message-ID: Hi Mark- I did some experimenting with Sesame for a bit when I was more actively involved; it seemed to be a reasonably robust system in terms of supporting persistance and querying; IIRC, it uses a forward-chaining type strategy for inference, such that whenever a new statement is added to the model, it will attempt to infer all consequences of that new statement in conjunction with its current knowledge base, but I think its rules of inference were relatively simple- transitive closure over subtypes, and that sort of thing; depending on how intelligent you imagine the ontologies will need to be vis-a-vis dynamic classification (some of the things I think Simon and Phil have discussed in the past), you may not get the inferencing power you want from Sesame- but I suppose you could put a more powerful inference engine as a front end for updates and then use sesame as a persistance and query mechanism, or something like that. HTH On Wed, 30 Jun 2004, Mark Wilkinson wrote: > Hey, > > has anyone got experience with Sesame? I'm reading their paper and it > sounds too good to be true w.r.t. future plans of moving MOBY Central & > the MOBY Ontologies to a pure RDF representation... I'd be interested > to hear other's experience with it! > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From adf at ncgr.org Wed Jun 30 21:41:47 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 15:41:47 -0600 (MDT) Subject: [MOBY-dev] Sesame? In-Reply-To: <1088630210.2105.237.camel@myhost.mydomain> Message-ID: Hi Mark- I did some experimenting with Sesame for a bit when I was more actively involved; it seemed to be a reasonably robust system in terms of supporting persistance and querying; IIRC, it uses a forward-chaining type strategy for inference, such that whenever a new statement is added to the model, it will attempt to infer all consequences of that new statement in conjunction with its current knowledge base, but I think its rules of inference were relatively simple- transitive closure over subtypes, and that sort of thing; depending on how intelligent you imagine the ontologies will need to be vis-a-vis dynamic classification (some of the things I think Simon and Phil have discussed in the past), you may not get the inferencing power you want from Sesame- but I suppose you could put a more powerful inference engine as a front end for updates and then use sesame as a persistance and query mechanism, or something like that. HTH On Wed, 30 Jun 2004, Mark Wilkinson wrote: > Hey, > > has anyone got experience with Sesame? I'm reading their paper and it > sounds too good to be true w.r.t. future plans of moving MOBY Central & > the MOBY Ontologies to a pure RDF representation... I'd be interested > to hear other's experience with it! > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From markw at illuminae.com Wed Jun 30 21:44:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 30 Jun 2004 14:44:02 -0700 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: References: Message-ID: <1088631841.1967.246.camel@myhost.mydomain> On Wed, 2004-06-30 at 14:41, Andrew D. Farmer wrote: > current knowledge base, but I think its rules of inference were relatively > simple- transitive closure over subtypes, Right - it sounds like it handles (i.e. "understands") only RDFS predicates... but even that is a joy! Do you have a feeling for how it compares to Jena v.v. speed and features? From the paper they are describing it as "Jena plus", but there may be features in Jena that are more powerful...?? M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Wed Jun 30 21:44:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 30 Jun 2004 14:44:02 -0700 Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: References: Message-ID: <1088631841.1967.246.camel@myhost.mydomain> On Wed, 2004-06-30 at 14:41, Andrew D. Farmer wrote: > current knowledge base, but I think its rules of inference were relatively > simple- transitive closure over subtypes, Right - it sounds like it handles (i.e. "understands") only RDFS predicates... but even that is a joy! Do you have a feeling for how it compares to Jena v.v. speed and features? From the paper they are describing it as "Jena plus", but there may be features in Jena that are more powerful...?? M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From adf at ncgr.org Wed Jun 30 23:28:48 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 17:28:48 -0600 (MDT) Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: <1088631841.1967.246.camel@myhost.mydomain> Message-ID: > Do you have a feeling for how it compares to Jena v.v. speed and > features? From the paper they are describing it as "Jena plus", but > there may be features in Jena that are more powerful...?? When was the paper written? I seem to recall that at the time I was looking at sesame, jena was a fairly bare-bones api for rdf manipulation (I don't think at that time it supported persistance to an rdbms), but since then it seems to have flourished in many directions. My impression is that Jena is better designed for pluggable implementations of things like inference and persistance than sesame. OTOH, I think at this point sesame may still support a greater variety of query languages than does jena, and comes complete with a easy-to-use servlet interface for admin and query/browse of datastores. Gary knows much more about jena than I do, and might be able to give you more detailed info. Jena appears to have a larger active development community, which is no small consideration... > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell --- From adf at ncgr.org Wed Jun 30 23:28:48 2004 From: adf at ncgr.org (Andrew D. Farmer) Date: Wed, 30 Jun 2004 17:28:48 -0600 (MDT) Subject: [MISC] Re: [MOBY-dev] Sesame? In-Reply-To: <1088631841.1967.246.camel@myhost.mydomain> Message-ID: > Do you have a feeling for how it compares to Jena v.v. speed and > features? From the paper they are describing it as "Jena plus", but > there may be features in Jena that are more powerful...?? When was the paper written? I seem to recall that at the time I was looking at sesame, jena was a fairly bare-bones api for rdf manipulation (I don't think at that time it supported persistance to an rdbms), but since then it seems to have flourished in many directions. My impression is that Jena is better designed for pluggable implementations of things like inference and persistance than sesame. OTOH, I think at this point sesame may still support a greater variety of query languages than does jena, and comes complete with a easy-to-use servlet interface for admin and query/browse of datastores. Gary knows much more about jena than I do, and might be able to give you more detailed info. Jena appears to have a larger active development community, which is no small consideration... > > M > > > -- Andrew Farmer adf at ncgr.org (505) 995-4464 Database Administrator/Software Developer National Center for Genome Resources --- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. - Bertrand Russell ---