From fgibbons at hms.harvard.edu Wed Sep 1 11:25:45 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Sep 1 11:23:14 2004 Subject: [MOBY-l] OWL-S, and RDF ontology for MOBY? Message-ID: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Hey MOBYers, Couple of ideas for MOBY-S, wanted to throw them out there, see if they make any sense.... 1. OWL-S is (as I understand it) an extension of OWL to web services, enabling discovery and machine-machine negotiation of web services (that's the "-S" in OWL-S). Since OWL-S is RDF, and MOBY Central already produces RDF graphs as part of the registration process, it's really a question of making the RDF graphs OWL-S compatible. Is that something that's part of the plan for the ongoing re-write of MOBY-S? (Why not)? I realise that OWL-S is evolving, so it might not be mature enough for use yet, but perhaps there are other reasons why it wouldn't be a good idea? 2. I've been playing with extending the MOBY-S object ontology, and talking with the BioPAX people about how they propose to integrate other ontologies into theirs, so that we might do the same. A month ago, at ISMB, it sounded like they were planning to import the PSI-MI ontology (for example) wholesale, and integrate it into theirs. Subsequent changes to PSI-MI would require manual inclusion. MOBY's ontology works in a similar way: in order to use PSI-MI, I've had to register each object separately. From this, and some reading I've been doing, it seems like the best way (and certainly the Semantic Way) to extend the ontology would be to have it be RDF-based, so that extension would involve simply including the URI of the ontology we wish to include. In this way, any subsequent changes in the included ontology are automatically included in MOBY's. How practical would it be to use this method in MOBY-S? Presumably, that's what S-MOBY does - Gary? Feedback appreciated, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From p.lord at russet.org.uk Wed Sep 1 13:06:01 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Wed Sep 1 13:09:46 2004 Subject: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Message-ID: >>>>> "Frank" == Frank Gibbons writes: Frank> Hey MOBYers, Frank> Couple of ideas for MOBY-S, wanted to throw them out there, Frank> see if they make any sense.... Frank> 1. OWL-S is (as I understand it) an extension of OWL to web Frank> services, Frank> enabling discovery and machine-machine negotiation of web Frank> services (that's the "-S" in OWL-S). Since OWL-S is RDF, and Frank> MOBY Central already produces RDF graphs as part of the Frank> registration process, it's really a question of making the Frank> RDF graphs OWL-S compatible. Is that something that's part of Frank> the plan for the ongoing re-write of MOBY-S? (Why not)? I Frank> realise that OWL-S is evolving, so it might not be mature Frank> enough for use yet, but perhaps there are other reasons why Frank> it wouldn't be a good idea? OWL-S is, as the name suggests, based on OWL rather than RDF. It is certainly the case that you can represent OWL in RDF, but the full semantics of OWL are quite a bit richer than those available in RDF. So its not necessarily a trivial process to convert between them. Early in the mygrid project we looked at what was then DAML-S for incorporation into our service ontology... @ARTICLE{mygrid-services, TITLE = {{A Suite of DAML+OIL Ontologies to Describe Bioinformatics Web Services and Data}}, AUTHOR = {Chris Wroe and Robert Stevens and Carole Goble and Angus Roberts and Mark Greenwood}, YEAR = {2003}, JOURNAL = {the International Journal of Cooperative Information Systems}, VOLUME = {12}, NUMBER = {2}, PAGES = {597--624}, URL = {http://www.cs.man.ac.uk/~stevensr/papers/jcoopis-final.zip}, KEY = {ontology,stevens} } There is also a recent paper that I co-authored with Mark and co, which refers to some extent to OWL-S. @INPROCEEDINGS{iswc-bio-moby-comparison04, AUTHOR = {Phillip Lord and Sean Bechhofer and Mark D. Wilkinson and Gary Schiltz and Damian Gessler and Duncan Hull and Carole Goble and Lincoln Stein}, TITLE = {Applying Semantic Web Services to bioinformatics: Experiences gained, lessons learnt}, BOOKTITLE = {International Semantic Web Conference}, YEAR = 2004, NOTE = {Accepted For Publication}, PDF = {download/publications/biomoby-comparison-iswc2004.pdf} } I think OWL-S is mostly aimed at automated composition which is not really what moby-s is aimed at. You're unlikely to be able to get semantic descriptions rich enough to describe services well enough to be able to do this anyway, in which case you are accepting a lot of complexity from OWL-S which will not necessarily buy you very much. Frank> 2. I've been playing with extending the MOBY-S object Frank> ontology, and Frank> talking with the BioPAX people about how they propose to Frank> integrate other ontologies into theirs, so that we might do Frank> the same. A month ago, at ISMB, it sounded like they were Frank> planning to import the PSI-MI ontology (for example) Frank> wholesale, and integrate it into theirs. Subsequent changes Frank> to PSI-MI would require manual inclusion. MOBY's ontology Frank> works in a similar way: in order to use PSI-MI, I've had to Frank> register each object separately. From this, and some reading Frank> I've been doing, it seems like the best way (and certainly Frank> the Semantic Way) to extend the ontology would be to have it Frank> be RDF-based, so that extension would involve simply Frank> including the URI of the ontology we wish to include. In this Frank> way, any subsequent changes in the included ontology are Frank> automatically included in MOBY's. How practical would it be Frank> to use this method in MOBY-S? Presumably, that's what S-MOBY Frank> does - Gary? Again there is an outstanding issue here. In the case of BioPAX they are explicitly using OWL-DL, and its a bit of an unanswered question as to what importing an ontology into another actually means. Most of the tools can't cope with this, for example (some concepts would need to be uneditable). On the flip side, the strong semantics of OWL-DL do actually give you something to work on with ontology imports. It should be possible to determine the relationship between concepts (so long as they share at least some parental concepts in common) if they are both defined in OWL-DL. With RDF, per se, its a little less clear. What happens, for example, if two different imported ontologies defined the same concept in two different ways? Cheers Phil From jmfernandez at cnb.uam.es Wed Sep 1 15:00:02 2004 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Wed Sep 1 15:01:21 2004 Subject: [MOBY-l] Problems testing a newly created MOBY Central (+ Fix) Message-ID: <41361C32.1020405@cnb.uam.es> Hi everybody, soon I'm going to give a practical seminar about MOBY, and I'm creating a local MOBY Central for the practices. This is not my first time creating a MOBY Central (I created one 9 months ago), but last version in CVS seems to have problems. First of all, intructions in http://www.biomoby.org/InstallingMOBYCentral.html should be updated, because last RDF changes in MOBY require RDF::Core Perl library as a pre-requisite before running a MOBY Central (and perhaps a the other libraries??). The problem I have found is the next: I ran the testMOBYClientCentral_v05.pl script in order to check if the installation was correct. First try failed in the first test due the lack of RDF::Core. The second try (after installing RDF::Core) seemed to run well until it failed in the 18th one, which corresponds to registerService. Next lines are from the Apache error log: [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of hash element in void context at /usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52. [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db selectrow_array failed: Unknown column 'signatureURL' in 'field list' at /usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 172, line 34 I have dug inside the referenced file told by the error message, and it is a query to the tables service_instance and authority from mobycentral database. It seems the signatureURL column should exist in service_instance table, and so moby database skeletons in CVS should be updated. What data type should have that column, Mark? I have created it as a VARCHAR(255), and now it works. Last, moby database skeletons (ie mysql dumps) in CVS should also be updated in order to reflect the last small change Mark told us about the datatype of maximum_value and minimum_value. Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez@cnb.uam.es Tlfn: (+34) 91 585 46 69 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From mwilkinson at mrl.ubc.ca Wed Sep 1 15:30:30 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed Sep 1 15:31:00 2004 Subject: [MISC] [MOBY-l] Problems testing a newly created MOBY Central (+ Fix) In-Reply-To: <41361C32.1020405@cnb.uam.es> References: <41361C32.1020405@cnb.uam.es> Message-ID: <1094067029.17672.55.camel@myhost.mydomain> Sorry, I am hoping to get all of the documentation updated as quickly as possible, but grant deadlines are getting in the way... The change to the database structure was (I think) announced on the mailing list. You can also get it by calling the 'DUMP' method of MOBY::Central (or via the client), or you can examine the database directly by logging in to a mysql session with the username moby_external (no password) here's the table definition for service_instance: +---------------------+----------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------------+----------------------------------+------+-----+---------+----------------+ | category | enum('moby','soap','wsdl','cgi') | YES | | NULL | | | servicename | varchar(255) | | MUL | | | | service_type_uri | varchar(255) | | | | | | authority_id | int(10) unsigned | | | 0 | | | url | varchar(255) | | | | | | contact_email | varchar(255) | | | | | | authoritative | enum('1','0') | | | 0 | | | description | text | | | | | | service_instance_id | int(10) unsigned | | PRI | NULL | auto_increment | | signatureURL | varchar(255) | YES | | NULL | | +---------------------+----------------------------------+------+-----+---------+----------------+ M On Wed, 2004-09-01 at 12:00, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi everybody, > soon I'm going to give a practical seminar about MOBY, and I'm creating > a local MOBY Central for the practices. This is not my first time > creating a MOBY Central (I created one 9 months ago), but last version > in CVS seems to have problems. > > First of all, intructions in > > http://www.biomoby.org/InstallingMOBYCentral.html > > should be updated, because last RDF changes in MOBY require RDF::Core > Perl library as a pre-requisite before running a MOBY Central (and > perhaps a the other libraries??). > > The problem I have found is the next: I ran the > testMOBYClientCentral_v05.pl script in order to check if the > installation was correct. First try failed in the first test due the > lack of RDF::Core. The second try (after installing RDF::Core) seemed to > run well until it failed in the 18th one, which corresponds to > registerService. Next lines are from the Apache error log: > > [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of > hash element in void context at > /usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52. > [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db > selectrow_array failed: Unknown column 'signatureURL' in 'field list' at > /usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line > 172, line 34 > > I have dug inside the referenced file told by the error message, and it > is a query to the tables service_instance and authority from mobycentral > database. It seems the signatureURL column should exist in > service_instance table, and so moby database skeletons in CVS should be > updated. > > What data type should have that column, Mark? I have created it as a > VARCHAR(255), and now it works. > > Last, moby database skeletons (ie mysql dumps) in CVS should also be > updated in order to reflect the last small change Mark told us about the > datatype of maximum_value and minimum_value. > > Best Regards, > Jos? Mar?a -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From michael at acutrans.net Fri Sep 3 13:24:19 2004 From: michael at acutrans.net (Michael Jensen) Date: Fri Sep 3 13:24:43 2004 Subject: [MOBY-l] Taverna workflows? Other GUIs? Message-ID: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Anyone have any Taverna workflows for BioMOBY? I tried building one real quick but it didn't work (first time using Taverna). Maybe we should have a few example workflows on the BioMOBY site? It may have been polled here before, but anyone using BioMOBY with something other than Java or Perl? Also, are there other GUIs like Taverna that work with BioMOBY? THANKS! -Michael Jensen From gordonp at cbr.nrc.ca Fri Sep 3 13:52:28 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Fri Sep 3 13:56:59 2004 Subject: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Message-ID: <4138AF5C.2010807@cbr.nrc.ca> Michael Jensen wrote: > Anyone have any Taverna workflows for BioMOBY? I tried building one > real quick but it didn't work (first time using Taverna). Maybe we > should have a few example workflows on the BioMOBY site? > > It may have been polled here before, but anyone using BioMOBY with > something other than Java or Perl? There is a Ruby API. > Also, are there other GUIs like Taverna that work with BioMOBY? You can link to MOBY services from Bluejay. The GUI is being reworked for memory-starved applets, so it may be a little gimpy for the next couple weeks. For a quick example, go to the applet at http://bluejay.ucalgary.ca/test/ Once the welcome page has loaded, go Bookmarks->Viral Genomes -> SSV1. Click on a gene with a functional category, wait a second, and you'll get Moby services that take GO terms. The results show up in a separate windows. Attached is an example image. > > THANKS! > > -Michael Jensen > > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From mwilkinson at mrl.ubc.ca Fri Sep 3 13:59:26 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Fri Sep 3 13:59:48 2004 Subject: [MISC] [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Message-ID: <1094234365.2043.5.camel@myhost.mydomain> there's also a python API contributed by Yan Wong from the Ressource Parisienne en Bioinformatique Structurale. I imported it into the CVS about two weeks ago. M On Fri, 2004-09-03 at 10:24, Michael Jensen wrote: > Anyone have any Taverna workflows for BioMOBY? I tried building one > real quick but it didn't work (first time using Taverna). Maybe we > should have a few example workflows on the BioMOBY site? > > It may have been polled here before, but anyone using BioMOBY with > something other than Java or Perl? > > Also, are there other GUIs like Taverna that work with BioMOBY? > > > THANKS! > > -Michael Jensen > > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Fri Sep 3 17:17:45 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Fri Sep 3 17:18:05 2004 Subject: [MOBY-l] FAQ for MOBY Services Message-ID: <1094246265.2043.89.camel@myhost.mydomain> Hi all, I've set up a FAQ page for MOBY Services - it's just another page on the Wiki. You can get to it from the "tutorials" link on the biomoby homepage. Right now it's empty (not because nobody has ever asked a question ;-) ). Anyone can register to be a twiki author, or you can simply send me your FAQ/answer and I will add it to that page. It would be great to have this page created as a community effort, however. Thanks for Mathieu for the suggestion! Mark -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From rebecca.ernst at gsf.de Mon Sep 6 09:26:23 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Mon Sep 6 09:43:37 2004 Subject: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Message-ID: <413C657F.8020101@gsf.de> Hi Michael! I set up a Taverna workflow built of BioMoby services. I attached it - hope it works for you . You need to load that workflow file (You'll then see the whole workflow as diagram) once you say "run workflow" you'll get the input document with namespace and id. There are no values filled in so you have to fill in some. click on 'namespace' and then 'new input' and put "Global_Keyword". For id do the same and put "wuschel". Then you can run it. Good luck! Rebecca Michael Jensen wrote: > Anyone have any Taverna workflows for BioMOBY? I tried building one > real quick but it didn't work (first time using Taverna). Maybe we > should have a few example workflows on the BioMOBY site? > > It may have been polled here before, but anyone using BioMOBY with > something other than Java or Perl? > > Also, are there other GUIs like Taverna that work with BioMOBY? > > > THANKS! > > -Michael Jensen > > > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Mon Sep 6 09:54:26 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Sep 6 09:59:57 2004 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <413C657F.8020101@gsf.de> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> Message-ID: <1094478865.7402.10.camel@myhost.mydomain> Mailman seems to have stripped the attachment from Rebecca's message. I don't know why it sometimes does and sometimes doesn't. I'm trying to attach it again here... I hope! M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From rebecca.ernst at gsf.de Mon Sep 6 10:38:03 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Mon Sep 6 10:38:15 2004 Subject: [MOBY-l] Class ontology question In-Reply-To: <1094479321.7401.17.camel@myhost.mydomain> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> <1094478865.7402.10.camel@myhost.mydomain> <1094479321.7401.17.camel@myhost.mydomain> Message-ID: <413C764B.9080702@gsf.de> Hi Mark! I had some discussions on the class ontology with my colleague Dirk and we didn't come up with a solution to our problem so I hope you have an answer to it ;-) I read your DesignAnObject page and found out that my Virtual Sequence object is not correct in that terms. It looks like this: blabla atgtaag... If I get it right GenericSequence HASA String. this means that it contains exactly ONE instance of String. But my object contains TWO instances of String. If the relationship of GenericSequence would be HAS instead of HASA it would be 'legal' I suppose. What would be the correct way to Design the object? Should I have another object CommentedSequence ISA GenericSequence HASA String OR CommentedSequence ISA Virtural Sequence HAS String ??? What's the purpose of having two similar relationships (HASA and HAS)? Thanks in advance Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From markw at illuminae.com Mon Sep 6 10:02:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Sep 6 12:22:24 2004 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094478865.7402.10.camel@myhost.mydomain> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> <1094478865.7402.10.camel@myhost.mydomain> Message-ID: <1094479321.7401.17.camel@myhost.mydomain> Trying again as a tar.gz file attachment. On Mon, 2004-09-06 at 06:54, Mark Wilkinson wrote: > Mailman seems to have stripped the attachment from Rebecca's message. I > don't know why it sometimes does and sometimes doesn't. > > I'm trying to attach it again here... I hope! > > M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Mon Sep 6 10:51:39 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Sep 6 12:31:58 2004 Subject: [MISC] [MOBY-l] Class ontology question In-Reply-To: <413C764B.9080702@gsf.de> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> <1094478865.7402.10.camel@myhost.mydomain> <1094479321.7401.17.camel@myhost.mydomain> <413C764B.9080702@gsf.de> Message-ID: <1094482299.7894.7.camel@myhost.mydomain> Hi Rebecca, comments below... > I read your DesignAnObject page and found out that my Virtual Sequence > object is not correct in that terms. > > It looks like this: > > > > blabla > atgtaag... > Okay... I think you have made a few errors here, but they might just be typo's. The object above is nether a VirtualSequence, nor a GenericSequence, so your outer tag is incorrect. I assume that this is your "CommentedSequence" object that you describe below? > If I get it right GenericSequence HASA String. this means that it > contains exactly ONE instance of String. But my object contains TWO > instances of String. correct > If the relationship of GenericSequence would be HAS instead of HASA it > would be 'legal' I suppose. not really... > What would be the correct way to Design the object? Should I have > another object > CommentedSequence ISA GenericSequence HASA String > OR > CommentedSequence ISA Virtural Sequence HAS String > ??? The first one is correct. You should have: CommentedSequence ISA GenericSequence HASA String(Description) This is the purpose of the articleName attribute. Effectively, it functions as an RDF predicate, if you were to imagine it that way. > What's the purpose of having two similar relationships (HASA and HAS)? So that objects can have an indefinite number of contained objects. For example, if you were trying to model a Genbank feature table, you wouldn't know a priori how many exons the gene had, so those would be modelled with a "HAS" relationship. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Mon Sep 6 12:54:50 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Sep 6 12:55:43 2004 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094479321.7401.17.camel@myhost.mydomain> Message-ID: > Trying again as a tar.gz file attachment. > The sure way is to name it: XXXX.clean 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 markw at illuminae.com Mon Sep 6 18:55:51 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon Sep 6 19:05:15 2004 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: References: Message-ID: <1094511351.10474.0.camel@myhost.mydomain> OKay, let's try that idea... attached again with a .clean extension M On Mon, 2004-09-06 at 09:54, Martin Senger wrote: > > Trying again as a tar.gz file attachment. > > > The sure way is to name it: XXXX.clean > Martin -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Mon Sep 6 19:10:25 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Mon Sep 6 19:10:53 2004 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: > attached again with a .clean extension > I will never say again "a sure way"... M. -- 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 rebecca.ernst at gsf.de Tue Sep 7 03:14:17 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Tue Sep 7 03:14:46 2004 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094511351.10474.0.camel@myhost.mydomain> References: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: <413D5FC9.1000709@gsf.de> Thanks for trying Mark! There seems to be no way to attach it via the mailinglist. Anyone who is interested in the taverna example workflow let me know and I'll send it to you directly! Rebecca Mark Wilkinson wrote: >OKay, let's try that idea... > >attached again with a .clean extension > >M > > >On Mon, 2004-09-06 at 09:54, Martin Senger wrote: > > >>>Trying again as a tar.gz file attachment. >>> >>> >>> >> The sure way is to name it: XXXX.clean >> Martin >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>moby-l mailing list >>moby-l@biomoby.org >>http://biomoby.org/mailman/listinfo/moby-l >> >> -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From p.lord at russet.org.uk Tue Sep 7 09:44:40 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Sep 7 09:46:45 2004 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094511351.10474.0.camel@myhost.mydomain> References: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Stick it on the web, and send a URL. This always works. Probably. Phil From mwilkinson at mrl.ubc.ca Tue Sep 7 10:26:44 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Sep 7 10:26:56 2004 Subject: [SPAM] Re: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: References: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: <1094567204.1974.9.camel@myhost.mydomain> It is possible to attach documents to TWiki pages as well. That might be a good option in the longer-term. There is a FAQ on the MOBY TWiki now, and anyone who registers can add to it. M On Tue, 2004-09-07 at 06:44, Phillip Lord wrote: > >>>>> "Mark" == Mark Wilkinson writes: > > > > Stick it on the web, and send a URL. This always works. > > Probably. > > > Phil > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From michael at acutrans.net Wed Sep 8 14:39:45 2004 From: michael at acutrans.net (Michael Jensen) Date: Wed Sep 8 14:39:58 2004 Subject: [MOBY-l] versioning services...authentication... Message-ID: <747BC42E-01C6-11D9-AAE1-000393B6201C@acutrans.net> Are there suggestions for maintaining versions of your services? Say you have a version 2 that is quite different than version 1, it would seem you would either want to maintain version 1 as is, and register version 2 as a new service (with a new name), or alternatively to deregister service 1 and register service 2 with a new name. Maybe this has been brought up before or maybe there is a better way? Also, I am sure it has been discussed before, but what about authentication for services? Say I have a service that I need you to be a registered user for, how does that fit in with it all? Point me to any previous discussions if this has been exhausted previously. -Michael Jensen From michael at acutrans.net Wed Sep 8 15:25:44 2004 From: michael at acutrans.net (Michael Jensen) Date: Wed Sep 8 15:25:58 2004 Subject: [MOBY-l] RDQL and moby registry? Message-ID: What is the potential application of RDQL with the current registry system, or future revisions of the system, and do you think it will prove useful? (RDQL is a RDF query language basically) Here is a demo of RDQL. There is a perl module for RDQL too, I noticed. http://www3.wiwiss.fu-berlin.de/rdfapi-php/test/custom_rdql_test.php Just hit "submit me!" and it searches for the creator of the RDF document. -Michael Jensen From r.bruskiewich at cgiar.org Wed Sep 8 20:06:54 2004 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Wed Sep 8 20:05:46 2004 Subject: [MOBY-l] versioning services...authentication... Message-ID: <2A491C94FFBC5843A212A69CBEA5CEC7AA8417@IRRIMAIL.irri.cgiar.org> Re: authentication... I presume that you mean user authentication to use a specific web service on your provider? Remember that web services (e.g. MOBY) use HTTP and its cousins for access. You therefore have access to web server access authentication. Using HTTPS or similar protocols would provide for secure authentication. Using Java servlet web services might provide even more fine control. At least, that's the idea we're toying in our efforts... Cheers Richard ============================================== Richard Bruskiewich, PhD Senior Bioinformatics Specialist International Rice Research Institute DAPO 7777, Metro Manila, Philippines r.bruskiewich@cgiar.org Web: www.irri.org Tel: +63-2-580-5600 Fax: +63-2-580-5699 ============================================ -----Original Message----- From: Michael Jensen [mailto:michael@acutrans.net] Sent: Thursday, September 09, 2004 2:40 AM To: moby-l@biomoby.org Subject: [MOBY-l] versioning services...authentication... Are there suggestions for maintaining versions of your services? Say you have a version 2 that is quite different than version 1, it would seem you would either want to maintain version 1 as is, and register version 2 as a new service (with a new name), or alternatively to deregister service 1 and register service 2 with a new name. Maybe this has been brought up before or maybe there is a better way? Also, I am sure it has been discussed before, but what about authentication for services? Say I have a service that I need you to be a registered user for, how does that fit in with it all? Point me to any previous discussions if this has been exhausted previously. -Michael Jensen _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l From mwilkinson at mobile.rogers.com Wed Sep 8 21:02:09 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed Sep 8 21:11:04 2004 Subject: [MOBY-l] versioning services...authentication... Message-ID: <200409090111.i891B1Kr031886@portal.open-bio.org> Richard beat me to the punch :-) That is entirely correct. Moby-s inherits its authentication from SOAP, which inherits its authentication from HTTP. The MOBY::Client::Central module actually handles authentication if you are running your script from the command line (God help me if I remember exactly how... Matt Links and I wrote a few secure services in my living room a couple of years ago and that was the last time I looked at that code... Unfortunalely I left my machine in the lab today so I can't look it up) Anyway, authentication isn't something we need to worry deeply about. It is all handled by libraries below our Moby libs. It's nothing more than a trivial line or two of code to implement the solution for your own situation. M -----Original Message----- From: "Bruskiewich, Richard (IRRI)" Date: Wed, 08 Sep 2004 17:06:54 To:Michael Jensen , moby-l@biomoby.org Subject: RE: [MOBY-l] versioning services...authentication... Re: authentication... I presume that you mean user authentication to use a specific web service on your provider? Remember that web services (e.g. MOBY) use HTTP and its cousins for access. You therefore have access to web server access authentication. Using HTTPS or similar protocols would provide for secure authentication. Using Java servlet web services might provide even more fine control. At least, that's the idea we're toying in our efforts... Cheers Richard ============================================== Richard Bruskiewich, PhD Senior Bioinformatics Specialist International Rice Research Institute DAPO 7777, Metro Manila, Philippines r.bruskiewich@cgiar.org Web: www.irri.org Tel: +63-2-580-5600 Fax: +63-2-580-5699 ============================================ -----Original Message----- From: Michael Jensen [mailto:michael@acutrans.net] Sent: Thursday, September 09, 2004 2:40 AM To: moby-l@biomoby.org Subject: [MOBY-l] versioning services...authentication... Are there suggestions for maintaining versions of your services? Say you have a version 2 that is quite different than version 1, it would seem you would either want to maintain version 1 as is, and register version 2 as a new service (with a new name), or alternatively to deregister service 1 and register service 2 with a new name. Maybe this has been brought up before or maybe there is a better way? Also, I am sure it has been discussed before, but what about authentication for services? Say I have a service that I need you to be a registered user for, how does that fit in with it all? Point me to any previous discussions if this has been exhausted previously. -Michael Jensen _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l _______________________________________________ moby-l mailing list moby-l@biomoby.org http://biomoby.org/mailman/listinfo/moby-l !!!!!!!!!!!!!!!! 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 p.lord at russet.org.uk Thu Sep 9 12:19:45 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Thu Sep 9 12:23:08 2004 Subject: [MOBY-l] RDQL and moby registry? In-Reply-To: References: Message-ID: >>>>> "Michael" == Michael Jensen writes: Michael> What is the potential application of RDQL with the current Michael> registry system, or future revisions of the system, and do Michael> you think it will prove useful? Michael> (RDQL is a RDF query language basically) Michael> Here is a demo of RDQL. There is a perl module for RDQL Michael> too, I noticed. Michael> http://www3.wiwiss.fu-berlin.de/rdfapi-php/test/custom_rdql_test.php Michael> Just hit "submit me!" and it searches for the creator of Michael> the RDF document. I don't know whether Mark is putting a RDF/RDQL backend onto moby, but within the mygrid project we have created a similar semantically searchable registry. The current version, written by Pinar Alper, uses a RDF backend (using Jena) and gets all of its query functionality through RDQL. We've also used RDF/RDQL for storing It works quite well. So yes there is definitely a potential application for RDQL within future versions of moby. Mark can say for himself if he is going to try it. Cheers Phil From mwilkinson at mrl.ubc.ca Thu Sep 9 12:44:39 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Sep 9 12:44:50 2004 Subject: [MISC] Re: [MOBY-l] RDQL and moby registry? In-Reply-To: References: Message-ID: <1094748278.1633.30.camel@myhost.mydomain> Hi all, it seems that some of my messages from last night never got through... I'm re-sending my answer: It should be possible, in principle, to search MOBY Central using RDQL already. There is an RDF representation of the registry at: http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances It is auto-generated, so it should always be up-to-date. AFAIK there is no reason that you couldn't just do RDQL searches on that document. Let me know if it works for you. M On Thu, 2004-09-09 at 09:19, Phillip Lord wrote: > >>>>> "Michael" == Michael Jensen writes: > > Michael> What is the potential application of RDQL with the current > Michael> registry system, or future revisions of the system, and do > Michael> you think it will prove useful? > > Michael> (RDQL is a RDF query language basically) > > > Michael> Here is a demo of RDQL. There is a perl module for RDQL > Michael> too, I noticed. > > Michael> http://www3.wiwiss.fu-berlin.de/rdfapi-php/test/custom_rdql_test.php > > Michael> Just hit "submit me!" and it searches for the creator of > Michael> the RDF document. > > > I don't know whether Mark is putting a RDF/RDQL backend onto moby, but > within the mygrid project we have created a similar semantically > searchable registry. The current version, written by Pinar Alper, uses > a RDF backend (using Jena) and gets all of its query functionality > through RDQL. We've also used RDF/RDQL for storing > > It works quite well. > > So yes there is definitely a potential application for RDQL within > future versions of moby. Mark can say for himself if he is going to > try it. > > Cheers > > Phil > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From ian.donaldson at mshri.on.ca Fri Sep 10 01:20:15 2004 From: ian.donaldson at mshri.on.ca (Ian Donaldson) Date: Fri Sep 10 01:23:29 2004 Subject: [MOBY-l] BioMoby and SeqHound Message-ID: <490D0AFAF3D2D3119F6C00508B6FDF1506F1D2F8@ex.mshri.on.ca> Dear all: SeqHound is a freely available bioinformatics database warehouse resource that is available via a remote programming API in C, C++, Java and Perl. A number of SeqHound API calls have been wrapped up as BioMoby services by Mark Wilkinson. We (the SeqHound development group) are considering setting up our own BioMoby-SeqHound server that will make more SeqHound services available to BioMoby users. In order to direct our development efforts, we are looking for feedback (posted to this list) as to what API calls people would find most useful as BioMoby services. The capabilities of the SeqHound API include functions that return GenBank sequence records, MMDB or PDB structure records, GO annotation assignments and pre-computed BLAST and RPS-BLAST results. There are many others. A complete list of the API is available at http://www.blueprint.org/seqhound/api_help/seqhound_help_guides.html. Any requests/feedback is most welcome. Thanks Ian Ian Donaldson, Ph.D. Manager of Bioinformatics Software Development The Blueprint Initiative - North America 522 University Ave. Toronto, Ontario, Canada M5G 1W7 http://blueprint.org ian.donaldson@blueprint.org About SeqHound SeqHound is a freely available bioinformatics database warehouse resource. Over 300 Gigabytes of data are collected, integrated and updated from around the world on a nightly basis. Sources include the National Center for Biotechnology Information and the Gene Ontology Consortium. Programmers have unrestricted access to up-to-date data via a remote Application Programming Interface (API) written in Perl, Java, C and C++. Over 150 function calls allow access to the complete collection of GenBank, RefSeq and SwissProt sequences, 3-D structures, precomputed protein neighbours, redundancies and conserved domain analyses. Users may also access collected sequence annotations including taxonomy, Gene Ontology assignments and PubMed links. All functions are fully documented and tested on a daily basis. The Blueprint SeqHound server is supported by a redundant architecture (failover load-balancers, failover servers and, failover SANs) for complete fault protection against component failure and to ensure rapid response time. SeqHound encourages unrestricted 24x7 calls to its servers, to allow programmers rapid, uninterrupted, access to biological data on a global basis. SeqHound services over 700,000 hits per day. All SeqHound code is freely distributed under the GNU Public License. Find SeqHound at www.blueprint.org. SeqHound v3.0 is available for download now from http://www.blueprint.org/seqhound/api_help/seqhound_help_guides.html. Major changes to this release include a port to a MySQL database backend allowing users to install a virtually free bioinformatics-programming platform in-house using instructions provided in the SeqHound Manual. The remote API (available in Java and Perl) is now supported by a FastCGI server for even faster response times. We are interested in identifying developers who are already using SeqHound. If you are, please sign up for the seqhound.usergroup email list at http://lists.blueprint.org/mailman/listinfo/seqhound.usergroup. Feedback and discussions on future development are welcome at this list. From mwilkinson at mrl.ubc.ca Tue Sep 14 11:37:08 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Sep 14 11:37:11 2004 Subject: [MISC] Re: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Message-ID: <1095176228.3247.116.camel@myhost.mydomain> On Wed, 2004-09-01 at 10:06, Phillip Lord wrote: > I think OWL-S is mostly aimed at automated composition which is not > really what moby-s is aimed at. You're unlikely to be able to get > semantic descriptions rich enough to describe services well enough to > be able to do this anyway, in which case you are accepting a lot of > complexity from OWL-S which will not necessarily buy you very much. We looked into this in some detail at my lab meeting last week. The tentative conclusion was the we could, in principle, describe a MOBY service in OWL-S if we had to. It may or may not be useful to do so, and we need to overcome the current lack of a MOBYObject->XSD translator. However, what we could NOT describe was the MOBY Invocation Message structure, since the message structure allows multiple invocations in a single message, each of which may be a different object type (so long as they are ontologically related). So the final conclusion was that, at least as it exists today, MOBY-S cannot be described in OWL-S (at leats as far as we understand it). This is not a commentary on the usefulness/not of MOBY-S nor OWL-S, it is just an observation. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From fgibbons at hms.harvard.edu Tue Sep 14 13:30:30 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Tue Sep 14 13:27:01 2004 Subject: [MISC] Re: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: <1095176228.3247.116.camel@myhost.mydomain> References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040914132849.01a00098@email.med.harvard.edu> Mark, Philip, Thanks for clarifying things: both the question in my mind (could/should MOBY-S use OWL-S?), and the confusion caused by my incomplete grasp of things semantic. -F At 11:37 AM 9/14/2004, Mark Wilkinson wrote: >On Wed, 2004-09-01 at 10:06, Phillip Lord wrote: > > > I think OWL-S is mostly aimed at automated composition which is not > > really what moby-s is aimed at. You're unlikely to be able to get > > semantic descriptions rich enough to describe services well enough to > > be able to do this anyway, in which case you are accepting a lot of > > complexity from OWL-S which will not necessarily buy you very much. > >We looked into this in some detail at my lab meeting last week. The >tentative conclusion was the we could, in principle, describe a MOBY >service in OWL-S if we had to. It may or may not be useful to do so, >and we need to overcome the current lack of a MOBYObject->XSD >translator. > >However, what we could NOT describe was the MOBY Invocation Message >structure, since the message structure allows multiple invocations in a >single message, each of which may be a different object type (so long as >they are ontologically related). > >So the final conclusion was that, at least as it exists today, MOBY-S >cannot be described in OWL-S (at leats as far as we understand it). > >This is not a commentary on the usefulness/not of MOBY-S nor OWL-S, it >is just an observation. > >M >-- >Mark Wilkinson (mwilkinson@mrl.ubc.ca) >University of British Columbia iCAPTURE Centre >_______________________________________________ >moby-l mailing list >moby-l@biomoby.org >http://biomoby.org/mailman/listinfo/moby-l PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From p.lord at russet.org.uk Tue Sep 14 13:50:53 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Sep 14 13:52:44 2004 Subject: [MISC] Re: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: <1095176228.3247.116.camel@myhost.mydomain> References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> <1095176228.3247.116.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> On Wed, 2004-09-01 at 10:06, Phillip Lord wrote: >> I think OWL-S is mostly aimed at automated composition which is >> not really what moby-s is aimed at. You're unlikely to be able to >> get semantic descriptions rich enough to describe services well >> enough to be able to do this anyway, in which case you are >> accepting a lot of complexity from OWL-S which will not >> necessarily buy you very much. Mark> We looked into this in some detail at my lab meeting last Mark> week. The tentative conclusion was the we could, in Mark> principle, describe a MOBY service in OWL-S if we had to. It Mark> may or may not be useful to do so, and we need to overcome the Mark> current lack of a MOBYObject->XSD translator. Mark> However, what we could NOT describe was the MOBY Invocation Mark> Message structure, since the message structure allows multiple Mark> invocations in a single message, each of which may be a Mark> different object type (so long as they are ontologically Mark> related). Can you really not describe this in OWL-S? I will admit to not having looked at OWL-S for sometime, but surely the input/output slots are not constrained to being a specific named class? You should be able to put in arbitrary class definitions, in which case you should be able to use conjunctions of classes. Mark> So the final conclusion was that, at least as it exists today, Mark> MOBY-S cannot be described in OWL-S (at leats as far as we Mark> understand it). Mark> This is not a commentary on the usefulness/not of MOBY-S nor Mark> OWL-S, it is just an observation. Actually, it is a commentary on both! Although, that you can't do in MOBY-S what you can do in OWL-S and you can't do in OWL-S what you can in MOBY-S, is probably not that surprising. Nor that much of a problem for either. They are aimed at somewhat different markets. Cheers Phil From senger at ebi.ac.uk Tue Sep 14 16:10:11 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Sep 14 16:10:26 2004 Subject: [MOBY-l] versioning services...authentication... In-Reply-To: <200409090111.i891B1Kr031886@portal.open-bio.org> Message-ID: > Anyway, authentication isn't something we need to worry deeply about. > It is all handled by libraries below our Moby libs. It's nothing more > than a trivial line or two of code to implement the solution for your > own situation. > I am not sure about it. I would prefer to see some code documenting it. I know that I myself said that authentication is the task of the underlying protocol - that's what Richard expressed here and what Mark confirmed. But I think (but I may be wrong) that we all three were talking from the perspective of the service provider. Simply speaking: service provider does not need to change his/her code when [s]he wants to have the service only for registered users, [s]he just adds an HTTP special file with an HTTP authentication configuration to her/his CGI-bin directory. But from the client perspective it may be different. And I do not think that the Moby clients can handle authentication. Surely not my Java client. We probably need to extend our clients libraries in order to be able to accept user name and password (in a way that is dependent on their user interface) and use it in the HTTP/SOAP request (in another way to do what any Netscape does for us hiddenly for years). Just my 2c, and with regards, Martin PS. Mark, this email was also about versioning. Do you have an answer, or a policy for that? M. -- 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 mrl.ubc.ca Wed Sep 15 11:58:07 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed Sep 15 11:58:10 2004 Subject: [MOBY-l] URGENT: Attention ALL SERVICE PROVIDERS Message-ID: <1095263887.5954.78.camel@myhost.mydomain> Hi all, we are getting ready to make a very significant change in MOBY-S, so I need **all existing service providers** to do a one-time exercise. This is also important for those who have their own MOBY Central installations. As we discussed at the last MOBY meeting, it is desirable and 'good' for MOBY Central's registry to extract its information using a mechanism more like a web crawler (more like S-MOBY :-) ). As a result, Nina has written an agent that will crawl known MOBY service providers and extract their service signatures from RDF files. The agent runs on a cron, and behaves as follows: 1) It looks up the last known address of your service signature in the database 2) It GET's that address expecting to find an RDF file 3) If it doesn't find a valid RDF file there, then it flags an error; after a certain number of errors your service(s) will be deregistered. (I believe that it also emails the contactEmail address and tells them that there was an error.) 4) If it finds an RDF, it compares the signatures of each service described in that RDF with the database, and updates or adds these service descriptions as necessary. 5) If it expects to find a service signature in this RDF, and can't find it, it concludes that the service has been taken off-line, and it will de-register that service. 6) The agent should be (touch wood!) tolerant of additional RDF in this signature, such that you can add your own additional annotations to this RDF as you wish. The behaviour of MOBY Central is as follows: 1) When you register a service, you may include a SignatureURL field in your XML (or as a parameter to the MOBY::Client::Central API) indicating where your RDF will be located. 2) Upon successful registration of your service, MOBY Central will send you the RDF signature of your service - you will not have to generate this yourself! (unless you want to... and feel free to do so!). It appears in the block of the MOBY Registration object (the ->RDF method of the MOBY:Registration object) 3) To ensure that your service is not deleted, you must place this RDF signature in the location that you specified in the signatureURL field when you registered your service. 4) If you do not include a signatureURL in your service registration, your service will be de-registered the next time the agent runs (since it will be unable to find an RDF file matching your service). This might be useful for people who are doing simple test services, as they wont clutter up the registry for long... 4) The deregisterService method of the MOBY Central API will **NOT** function for any service that has a signatureURL. It will function as expected for any service does not have a signatureURL. So, in short, services now have a signatureURL that points to an RDF file describing their service. An agent will crawl around on a regular basis looking at these RDF signatures. If you update a service, you change the RDF. if you remove a service, you delete that portion of the RDF. If you add a service, you either add a new signature to the RDF and let the agent register it automatically, or you use the registerService function of MOBY Central as you have in the past, and allow MOBY Central to generate the RDF for you. Services without a signatureURL WILL BE DELETED!!!! Of course, at the moment nobody has a signatureURL :-) I have set up a simple CGI page for existing service providers where they can supply a URL and get the signature RDF for all of their existing services: http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl We will switch the agent on in a week or so, and after that all services without a signatureURL will be deleted, so please go to this page ASAP. If the script doesn't work, or if you have any problems please let me know and I or Nina will fix them immediately. I hope this isn't too disruptive to people. I'm convinced that it is a change for the better! Contact me by phone or email if you have any concerns. Cheers all! M -- Mark Wilkinson, Assistant Professor (Bioinformatics) Dept. of Medical Genetics, University of British Columbia James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research 166 - 1081 Burrard St. Vancouver, BC, Canada, V6Z 1Y6 tel: (604) 682 2344 ext. 62129 fax: (604) 806 9274 ------------------------------------------------------------------------ The death rate in Canada currently stands at one per person. Here at iCAPTURE, we are working hard to improve on that figure! ------------------------------------------------------------------------ From fgibbons at hms.harvard.edu Wed Sep 15 14:32:55 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Sep 15 14:29:27 2004 Subject: [MOBY-l] signatureURLs; test registry In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain> Message-ID: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> Mark, >we are getting ready to make a very significant change in MOBY-S, so I >need **all existing service providers** to do a one-time exercise. This >is also important for those who have their own MOBY Central installations. The CGI (http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl) you put up to make signature RDF worked fine for me (and was really fast), but it did raise one or two questions: >3) To ensure that your service is not deleted, you must place this RDF >signature in the location that you specified in the signatureURL field >when you registered your service. As soon as I had done it the first time, I realised "Oh no, that's not a good place to put the RDF!", so I ran the CGI again, this time with a more sensible location for the RDF. Will that work? In other words, does re-running it erase the old location, or will my services now end up being de-registered because there's no RDF in the first location I entered, although it is present and accessible in the second (and final) location I entered? Glad to hear the crawler will be "coming soon to a website near me" ;) I'm wondering how often it'll run - should I expect one visit a day, or one a week? Specifically, I'm wondering what the latency will be if I decide to register a new service by firing up IsaViz and adding to the RDF, rather than using a call to MOBY Central? In the latter case, I expect the service to be immediately registered, but what about the former? And finally, what's up with the test registry - I can't seem to connect any longer (worked fine on Monday, I believe). Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From mwilkinson at mrl.ubc.ca Wed Sep 15 14:36:56 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed Sep 15 14:36:59 2004 Subject: [MOBY-l] Re: [MISC] signatureURLs; test registry In-Reply-To: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> References: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> Message-ID: <1095273416.9055.152.camel@myhost.mydomain> On Wed, 2004-09-15 at 11:32, Frank Gibbons wrote: > In other words, does > re-running it erase the old location, or will my services now end up being > de-registered because there's no RDF in the first location I entered, > although it is present and accessible in the second (and final) location I > entered? It will re-set each time you run it, so don't worry if you change your mind and run it again. Whatever you chose the last time you ran it will be what is in the database. > I'm > wondering how often it'll run - should I expect one visit a day, or one a > week? Specifically, I'm wondering what the latency will be if I decide to > register a new service by firing up IsaViz and adding to the RDF To be honest, that is something that we haven't decided yet. I see no good reason why it shouldn't run every night. My "gut" tells me, however, that most people who set up services will be anxious to see them in the registry right away to test them, so I suspect that most people will continue to use the API call rather than passively wait for their exciting new service to be registered by the crawler :-) > And finally, what's up with the test registry - I can't seem to connect any > longer (worked fine on Monday, I believe). I'll look into that right away. It may have crashed?! Thanks for the heads-up. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Wed Sep 15 14:48:41 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed Sep 15 14:48:44 2004 Subject: [MOBY-l] Re: [MISC] signatureURLs; test registry In-Reply-To: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> References: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> Message-ID: <1095274121.5952.157.camel@myhost.mydomain> On Wed, 2004-09-15 at 11:32, Frank Gibbons wrote: > And finally, what's up with the test registry - I can't seem to connect any > longer (worked fine on Monday, I believe). yup. It looks like the machine was rebooted sometime recently - the production registry comes up automatically, but the test registry has to be started manually. It's up now. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Wed Sep 15 15:33:34 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Wed Sep 15 16:44:00 2004 Subject: [MOBY-l] Re: [MISC] signatureURLs; test registry In-Reply-To: <1095273416.9055.152.camel@myhost.mydomain> References: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> <1095273416.9055.152.camel@myhost.mydomain> Message-ID: <4148990E.3060701@cbr.nrc.ca> Would it not make sense to run the agent against the RDF URL shortly after (let's say 5 minutes?) the service is registered. In this way, deleted services will be auto-deregistered about when their potential replacement services are registered. >> I'm >>wondering how often it'll run - should I expect one visit a day, or one a >>week? Specifically, I'm wondering what the latency will be if I decide to >>register a new service by firing up IsaViz and adding to the RDF >> >> > >To be honest, that is something that we haven't decided yet. I see no >good reason why it shouldn't run every night. My "gut" tells me, >however, that most people who set up services will be anxious to see >them in the registry right away to test them, so I suspect that most >people will continue to use the API call rather than passively wait for >their exciting new service to be registered by the crawler :-) > > > From p.lord at russet.org.uk Thu Sep 16 11:55:01 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Thu Sep 16 11:57:30 2004 Subject: [MOBY-l] Re: [MOBY-dev] Java developers, let's talk together In-Reply-To: References: Message-ID: >>>>> "Martin" == Martin Senger writes: Martin> 2) Building. What about to use Ant? :-) At the moment, some Martin> subprojects Martin> does not support much re-building by other users. Such Martin> support should be a primary rule for an open source Martin> project. Or am I too autocrative here? Martin> 3) Third-party libraries (the ones we have only as jar Martin> files). Martin> There is no single solution. Easy rebuilding is an essential. You might want to take a look at Maven. Its a little complex, but has some nice features. I've not used it in anger yet, as its not worth moving over existing infrastructure, but if you are putting a lot of new stuff in. Probably the nicest thing about it, is that it has good support for third party libraries. It gives a clean mechanism for obtaining new versions, describing which sub-projects use what, and if you have several projects using maven for sharing files between them. This also makes publishing your own work in a form people can build on easy. It might be worth having a look at. It builds on top of ant, rather than replaces it. Cheers Phil From mwilkinson at mrl.ubc.ca Thu Sep 16 18:02:51 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Sep 16 18:02:56 2004 Subject: [MOBY-l] Re: [MISC] Re: [MOBY-dev] URGENT: Attention ALL SERVICE PROVIDERS In-Reply-To: References: Message-ID: <1095372170.11263.37.camel@myhost.mydomain> Hi Martin, you're absolutely right. I had it in there during debugging so that I could retrieve messages where the XML was incorrectly formatted. I've removed that now, but it has the unfortunate consequence that **EVERYONE** must do a cvs update on their MOBY::Client::Central, since the old client library assumed that it was CDATA, and wont extract the RDF-XML from the registration object. I will also make a new release for those who are only downloading the releases. Ugh... sorry about that! M On Wed, 2004-09-15 at 13:20, Martin Senger wrote: > Mark, > I wonder why the RDF part in the registration object is marked as > CDATA. Because RDF must be anyway a valid XML why to bother to surround it > by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is > there any reason you use CDATA for the RDF part? > > Thanks, > Martin -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Sep 16 18:25:11 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Sep 16 18:25:16 2004 Subject: [MOBY-l] CVS update required & new release available Message-ID: <1095373511.11263.42.camel@myhost.mydomain> Hi all, I just had to make a change in the client code that will allow you to extract the RDF from the Registration object (Perl users only). Please do a CVS update if you are using CVS, or download the latest release from the biomoby.org/releases page, otherwise the RDF will not be available to you in the MOBY::Registration object. Java users should be (?? Martin/Paul ??) unaffected by this change - all I did was remove the CDATA tags around the RDF-XML in the Registration XML message. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Thu Sep 16 18:32:23 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu Sep 16 18:32:21 2004 Subject: [MOBY-l] Re: [MOBY-dev] CVS update required & new release available In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain> Message-ID: > Java users should be (?? Martin/Paul ??) unaffected by this change > I am just coding the whole new registration stuff, so I do not need to announce a change because I have not commited it yet :-) I will let Java users know soon... (I already must thank to Eddie for his valuable suggestions and conrtibutions). Cheers, 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 senger at ebi.ac.uk Tue Sep 21 07:02:34 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue Sep 21 07:03:03 2004 Subject: [MOBY-l] Re: [MOBY-dev] URGENT: Attention ALL SERVICE PROVIDERS In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain> Message-ID: Mark, I found the agent's behaviour description slightly inconsistent in one place (perhaps agent is not inconsistent, perhaps it is only the description, I have not tested the agent itself): > The agent runs on a cron, and behaves as follows: > ... > 3) If it doesn't find a valid RDF file there, then it flags an error; > after a certain number of errors your service(s) will be deregistered. > ... > 5) If it expects to find a service signature in this RDF, and can't > find it, it concludes that the service has been taken off-line, and it > will de-register that service. > So: if there is no file at all, it will try several times before de-registering the service. But if there is any RDF file but without my service, it will de-register it immediatelly. Why does it not behave the same in these two cases? In reality, it would mean slightly different behaviour when I am adding my first service (so the RDF file with all my services does not exist yes) and when I am adding the second and more services (when the RDF file exists - havig my previous services - but it still does not have my last one). 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 rebecca.ernst at gsf.de Wed Sep 22 08:33:53 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed Sep 22 08:33:36 2004 Subject: [MOBY-l] deregistering services without RDF agent Message-ID: <41517131.90707@gsf.de> Hi Mark, Hi Nina! I just ran into one problem with the RDF agent: I changed the output object of two of my services and I therefore wanted to deregister these two services and register them again with the correct output objects. But once I try to deregister them with the script I get the message that "it is illegal to deregister a service that has a signatureURL. Such services must be deregistered by deleting the RDF at the location identified by the signatureURL". I believe that it should be possible to deregister the services also via the script. (otherwise the agent will have to run every hour to keep track of changes and developers will still have a hard time waiting for the changes they made.) Did you think about this before? Any suggestions how it can be solved? Cheers, Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From fgibbons at hms.harvard.edu Wed Sep 22 12:35:32 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Sep 22 12:31:37 2004 Subject: [MOBY-l] deregistration by removal of RDF Message-ID: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Question about the new (de)registration scheme: a week or two ago, we generated RDF for our existing services, which was produced as a single file containing all services. Now I wish to deregister one service, leaving the others intact. Obviously removal of the file is not an option, since then everything is deregistered at once. Well, I suppose I could do that, and then re-register everything, each with its own separate RDF document (which would have the advantage of simplicity, but result in a lot of work for me!) Another option is to edit the RDF (say, using IsaViz) to remove the offending service. That's easy, but then I'm wondering, how does MOBY Central *really* know what's registered? If it merely checks for the PRESENCE of the RDF file, my service will remain registered, even though it is no longer referred to in the RDF. So, my question really is: 1. does MOBY Central's web agent READ what's in the file. 2. And, since I'm no longer allowed to de-register by making a function call, how can I make MOBY Central aware of the deregistration in a prompt manner? Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From gordonp at cbr.nrc.ca Wed Sep 22 13:04:56 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Wed Sep 22 13:04:37 2004 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: > So, my question really is: > > 1. does MOBY Central's web agent READ what's in the file. That's the impression I got... > 2. And, since I'm no longer allowed to de-register by making a function > call, how can I make MOBY Central aware of the deregistration in a prompt > manner? Perhaps the deregister call should be replaced by a refreshRDF call, which allows the service providers to "push" update events, while MOBY still "pulls" the RDF data for integrity reasons... From senger at ebi.ac.uk Wed Sep 22 13:16:38 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Sep 22 13:16:21 2004 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: > 1. does MOBY Central's web agent READ what's in the file. > Yes, I would guess so. Mark wrote: > 4) If it finds an RDF, it compares the signatures of each service > described in that RDF with the database, and updates or adds these > service descriptions as necessary. > 2. And, since I'm no longer allowed to de-register by making a function > call, how can I make MOBY Central aware of the deregistration in a prompt > manner? > I hope, strongly hope that this will not be true. See my previous, and Rebecca's, message. 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 fgibbons at hms.harvard.edu Wed Sep 22 15:11:58 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed Sep 22 15:08:14 2004 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: References: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040922151048.019c9498@email.med.harvard.edu> At 01:16 PM 9/22/2004, you wrote: > > 1. does MOBY Central's web agent READ what's in the file. > > > Yes, I would guess so. Mark wrote: > > > 4) If it finds an RDF, it compares the signatures of each service > > described in that RDF with the database, and updates or adds these > > service descriptions as necessary. > > > 2. And, since I'm no longer allowed to de-register by making a function > > call, how can I make MOBY Central aware of the deregistration in a prompt > > manner? > > > I hope, strongly hope that this will not be true. See my previous, and >Rebecca's, message. Martin, thanks for the pointers - on reading Rebecca's earlier message, I realise that she asked the same question I did. -F PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Wed Sep 22 17:49:49 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Sep 22 17:49:35 2004 Subject: [MOBY-l] recent changes in jMoby In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain> Message-ID: Dear Java developers, I have made few changes in the Java libraries in order to reflect the changes in service registration procedures (and few other fixes). It is recommended to 'cvs update -dP'. The changes (from docs/ChangeLog) are: 2004-09-22 Martin Senger * Fixed option -rs-out in MobyCmdLineClient. * Added a -debug option to the TestingCentral client. * Fixed TestingCentral client - it used incorectly user-defined data type in the output secondary article. * Added HAS relationship type for children of MobyDataType objects. It uses a new class MobyRelationship (meaning that methods returning children in MobyDataType got new signatures). * Changes reflecting new service registration procedure: - MobyService has new members with corresponding set/get methods for storing 'signatureURL' and a fully qualified path to the place where the service signature (an RDF document) can be stored). - CentralImpl stores retrieved RDF in a local file (read API for MobyService class, it explains what CentralImpl is doing). - command-line program MobyCmdLineClient got few new options in order to deal with 'signatureURL' (see its new help). Cheers, 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 markw at illuminae.com Wed Sep 22 19:40:06 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Sep 22 19:39:53 2004 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922151048.019c9498@email.med.harvard.edu> References: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> <5.2.1.1.2.20040922151048.019c9498@email.med.harvard.edu> Message-ID: <41520D56.5050208@illuminae.com> You can immediately de-register a service that has no registered SignatureURI - this was to allow people to easily set up test services that would be deregistered rapidly if they forgot to do so manually. I guess if there is a need for a more immediate deregistration process for "real" services (i.e. those that had an RDF file sitting somewhere) then we could think about that. is it possible to remove your site from Google?? M Frank Gibbons wrote: > At 01:16 PM 9/22/2004, you wrote: > >> > 1. does MOBY Central's web agent READ what's in the file. >> > >> Yes, I would guess so. Mark wrote: >> >> > 4) If it finds an RDF, it compares the signatures of each service >> > described in that RDF with the database, and updates or adds these >> > service descriptions as necessary. >> >> > 2. And, since I'm no longer allowed to de-register by making a >> function >> > call, how can I make MOBY Central aware of the deregistration in a >> prompt >> > manner? >> > >> I hope, strongly hope that this will not be true. See my previous, >> and >> Rebecca's, message. > > > Martin, thanks for the pointers - on reading Rebecca's earlier > message, I realise that she asked the same question I did. > > -F > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From markw at illuminae.com Wed Sep 22 19:49:50 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed Sep 22 19:49:43 2004 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> References: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: <41520F9E.3000603@illuminae.com> Frank Gibbons wrote: > 1. does MOBY Central's web agent READ what's in the file. Yes, this is why you are able to use that same file to do updates to your service without having to contact MOBY Central directly. > 2. And, since I'm no longer allowed to de-register by making a > function call, how can I make MOBY Central aware of the deregistration > in a prompt manner? > I think there is a simple solution to this. Let me get back to Vancouver (next week) and I'll try to implement it quickly. The suggestion of a "refresh" function is a good one, and I just want to think about how best to implement it. M > From senger at ebi.ac.uk Wed Sep 22 19:50:22 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed Sep 22 19:54:11 2004 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <41520D56.5050208@illuminae.com> Message-ID: > You can immediately de-register a service that has no registered > SignatureURI > Yes, but this is no problem, is it? :-) > guess if there is a need for a more immediate deregistration process for > "real" services (i.e. those that had an RDF file sitting somewhere) > then we could think about that. > What harm would be done if we just keep the same mechanism as before for all services? I guess that the answer is security, right? The new system prevents other people to deregister your service. I have not thought about the security implications when I was discussing this issue... 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 gss at ncgr.org Fri Sep 24 11:44:35 2004 From: gss at ncgr.org (Gary Schiltz) Date: Fri Sep 24 11:47:57 2004 Subject: [MOBY-l] MOBY Meeting: 20-21 November in Santa Fe Message-ID: <415440E3.2070000@ncgr.org> Hello MOBY'ers! The next MOBY meeting will be held at NCGR (www.ncgr.org) in Santa Fe, New Mexico, the weekend of 20-21 November, 2004. We'll finish by about 3:00 MST on Sunday, so you could catch a flight as early as about 5:30. Also, Mark Wilkinson will be giving a talk on MOBY Services at NCGR on November 19 (some time in the afternoon, I believe); everyone is welcome to attend, so consider coming a day early. I'll soon put together a page of information with an agenda, links to accommodations covering a range of prices, and other details. There will be a small registration fee to cover breakfast and lunch for Saturday and Sunday. In the interim, please post suggestions for topics to cover at the meeting. ---- Gary Schiltz Principal Software Engineer National Center for Genome Resources Santa Fe, New Mexico gss@ncgr.org 505-995-4414 (Work) 505-670-5983 (Cell) From simont at mcw.edu Fri Sep 24 13:43:41 2004 From: simont at mcw.edu (Simon Twigger) Date: Fri Sep 24 13:43:21 2004 Subject: [MOBY-l] Objecs for ontology annotations Message-ID: <45E77A08-0E51-11D9-91FC-000A959D1D82@mcw.edu> Hi there, As a diversion from the RDF registration debate I have a question about expanding the existing object ontology to cope with different types of ontology annotations. Our scenario is as follows: We have a variety of ontologies/controlled vocabs that we are using at RGD: GO, Mammalian Phenotype Ontology (we're working with MGD on this, see http://www.informatics.jax.org/searches/MP_form.shtml), a Disease Ontology (based around MeSH terms) and a controlled vocab for pathways. We're annotating genes/gene products and also Strains and QTLs with these terms. These are all structured much like GO, the terms have an ID, a term and a definition and they are annotated to other objects with an evidence code and a reference, however, the evidence codes are different between the various ontologies. We've been working on defining appropriate objects for MOBY services that handle these ontologies and related annotations to other objects and I wanted to see if others had addressed this same problem. Im not sure if Im thinking in an appropriately MOBY fashion and as a result getting too complicated. Im still trying to write up what we have so it makes sense to an outside observer but I thought I'd ask to see if other people had ideas or if the Powers that Be (Mark?) could sketch out very briefly how they might solve this question? Brief questions: To connect an object and an annotation, Is it better to create an annotation object that contains the Annotated Object and the Annotated Data (eg an ontology term) and has attributes that define that annotation (eg. evidence code, reference, etc); or, should we subclass the annotated object and say it hasa annotation and add in attributes defining the annotation, eg. AnnotatedGene HASA GO term, and also HASA evidence code, reference, etc? At first glance the first option would seem more flexible than the second but I might be wrong. We want to link these ontology terms to genes/gene products so I think we may need a 'Gene' object of some description. No-one will agree on what a gene is but would something lightweight like a GeneLocus object with just a symbol and name String attributes be acceptable? Thanks for any ideas people may have! Simon. -- 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 fgibbons at hms.harvard.edu Wed Sep 1 11:25:45 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 01 Sep 2004 11:25:45 -0400 Subject: [MOBY-l] OWL-S, and RDF ontology for MOBY? Message-ID: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Hey MOBYers, Couple of ideas for MOBY-S, wanted to throw them out there, see if they make any sense.... 1. OWL-S is (as I understand it) an extension of OWL to web services, enabling discovery and machine-machine negotiation of web services (that's the "-S" in OWL-S). Since OWL-S is RDF, and MOBY Central already produces RDF graphs as part of the registration process, it's really a question of making the RDF graphs OWL-S compatible. Is that something that's part of the plan for the ongoing re-write of MOBY-S? (Why not)? I realise that OWL-S is evolving, so it might not be mature enough for use yet, but perhaps there are other reasons why it wouldn't be a good idea? 2. I've been playing with extending the MOBY-S object ontology, and talking with the BioPAX people about how they propose to integrate other ontologies into theirs, so that we might do the same. A month ago, at ISMB, it sounded like they were planning to import the PSI-MI ontology (for example) wholesale, and integrate it into theirs. Subsequent changes to PSI-MI would require manual inclusion. MOBY's ontology works in a similar way: in order to use PSI-MI, I've had to register each object separately. From this, and some reading I've been doing, it seems like the best way (and certainly the Semantic Way) to extend the ontology would be to have it be RDF-based, so that extension would involve simply including the URI of the ontology we wish to include. In this way, any subsequent changes in the included ontology are automatically included in MOBY's. How practical would it be to use this method in MOBY-S? Presumably, that's what S-MOBY does - Gary? Feedback appreciated, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From p.lord at russet.org.uk Wed Sep 1 13:06:01 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 01 Sep 2004 18:06:01 +0100 Subject: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Message-ID: >>>>> "Frank" == Frank Gibbons writes: Frank> Hey MOBYers, Frank> Couple of ideas for MOBY-S, wanted to throw them out there, Frank> see if they make any sense.... Frank> 1. OWL-S is (as I understand it) an extension of OWL to web Frank> services, Frank> enabling discovery and machine-machine negotiation of web Frank> services (that's the "-S" in OWL-S). Since OWL-S is RDF, and Frank> MOBY Central already produces RDF graphs as part of the Frank> registration process, it's really a question of making the Frank> RDF graphs OWL-S compatible. Is that something that's part of Frank> the plan for the ongoing re-write of MOBY-S? (Why not)? I Frank> realise that OWL-S is evolving, so it might not be mature Frank> enough for use yet, but perhaps there are other reasons why Frank> it wouldn't be a good idea? OWL-S is, as the name suggests, based on OWL rather than RDF. It is certainly the case that you can represent OWL in RDF, but the full semantics of OWL are quite a bit richer than those available in RDF. So its not necessarily a trivial process to convert between them. Early in the mygrid project we looked at what was then DAML-S for incorporation into our service ontology... @ARTICLE{mygrid-services, TITLE = {{A Suite of DAML+OIL Ontologies to Describe Bioinformatics Web Services and Data}}, AUTHOR = {Chris Wroe and Robert Stevens and Carole Goble and Angus Roberts and Mark Greenwood}, YEAR = {2003}, JOURNAL = {the International Journal of Cooperative Information Systems}, VOLUME = {12}, NUMBER = {2}, PAGES = {597--624}, URL = {http://www.cs.man.ac.uk/~stevensr/papers/jcoopis-final.zip}, KEY = {ontology,stevens} } There is also a recent paper that I co-authored with Mark and co, which refers to some extent to OWL-S. @INPROCEEDINGS{iswc-bio-moby-comparison04, AUTHOR = {Phillip Lord and Sean Bechhofer and Mark D. Wilkinson and Gary Schiltz and Damian Gessler and Duncan Hull and Carole Goble and Lincoln Stein}, TITLE = {Applying Semantic Web Services to bioinformatics: Experiences gained, lessons learnt}, BOOKTITLE = {International Semantic Web Conference}, YEAR = 2004, NOTE = {Accepted For Publication}, PDF = {download/publications/biomoby-comparison-iswc2004.pdf} } I think OWL-S is mostly aimed at automated composition which is not really what moby-s is aimed at. You're unlikely to be able to get semantic descriptions rich enough to describe services well enough to be able to do this anyway, in which case you are accepting a lot of complexity from OWL-S which will not necessarily buy you very much. Frank> 2. I've been playing with extending the MOBY-S object Frank> ontology, and Frank> talking with the BioPAX people about how they propose to Frank> integrate other ontologies into theirs, so that we might do Frank> the same. A month ago, at ISMB, it sounded like they were Frank> planning to import the PSI-MI ontology (for example) Frank> wholesale, and integrate it into theirs. Subsequent changes Frank> to PSI-MI would require manual inclusion. MOBY's ontology Frank> works in a similar way: in order to use PSI-MI, I've had to Frank> register each object separately. From this, and some reading Frank> I've been doing, it seems like the best way (and certainly Frank> the Semantic Way) to extend the ontology would be to have it Frank> be RDF-based, so that extension would involve simply Frank> including the URI of the ontology we wish to include. In this Frank> way, any subsequent changes in the included ontology are Frank> automatically included in MOBY's. How practical would it be Frank> to use this method in MOBY-S? Presumably, that's what S-MOBY Frank> does - Gary? Again there is an outstanding issue here. In the case of BioPAX they are explicitly using OWL-DL, and its a bit of an unanswered question as to what importing an ontology into another actually means. Most of the tools can't cope with this, for example (some concepts would need to be uneditable). On the flip side, the strong semantics of OWL-DL do actually give you something to work on with ontology imports. It should be possible to determine the relationship between concepts (so long as they share at least some parental concepts in common) if they are both defined in OWL-DL. With RDF, per se, its a little less clear. What happens, for example, if two different imported ontologies defined the same concept in two different ways? Cheers Phil From jmfernandez at cnb.uam.es Wed Sep 1 15:00:02 2004 From: jmfernandez at cnb.uam.es (=?ISO-8859-1?Q?Jos=E9_Mar=EDa_Fern=E1ndez_Gonz=E1lez?=) Date: Wed, 01 Sep 2004 21:00:02 +0200 Subject: [MOBY-l] Problems testing a newly created MOBY Central (+ Fix) Message-ID: <41361C32.1020405@cnb.uam.es> Hi everybody, soon I'm going to give a practical seminar about MOBY, and I'm creating a local MOBY Central for the practices. This is not my first time creating a MOBY Central (I created one 9 months ago), but last version in CVS seems to have problems. First of all, intructions in http://www.biomoby.org/InstallingMOBYCentral.html should be updated, because last RDF changes in MOBY require RDF::Core Perl library as a pre-requisite before running a MOBY Central (and perhaps a the other libraries??). The problem I have found is the next: I ran the testMOBYClientCentral_v05.pl script in order to check if the installation was correct. First try failed in the first test due the lack of RDF::Core. The second try (after installing RDF::Core) seemed to run well until it failed in the 18th one, which corresponds to registerService. Next lines are from the Apache error log: [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of hash element in void context at /usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52. [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db selectrow_array failed: Unknown column 'signatureURL' in 'field list' at /usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line 172, line 34 I have dug inside the referenced file told by the error message, and it is a query to the tables service_instance and authority from mobycentral database. It seems the signatureURL column should exist in service_instance table, and so moby database skeletons in CVS should be updated. What data type should have that column, Mark? I have created it as a VARCHAR(255), and now it works. Last, moby database skeletons (ie mysql dumps) in CVS should also be updated in order to reflect the last small change Mark told us about the datatype of maximum_value and minimum_value. Best Regards, Jos? Mar?a -- Jos? Mar?a Fern?ndez Gonz?lez e-mail: jmfernandez at cnb.uam.es Tlfn: (+34) 91 585 46 69 Fax: (+34) 91 585 45 06 Grupo de Dise?o de Proteinas Protein Design Group Centro Nacional de Biotecnolog?a National Center of Biotechnology C.P.: 28049 Zip Code: 28049 C/. Darwin n? 3 (Campus Cantoblanco, U. Aut?noma), Madrid (Spain) From mwilkinson at mrl.ubc.ca Wed Sep 1 15:30:30 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 01 Sep 2004 12:30:30 -0700 Subject: [MISC] [MOBY-l] Problems testing a newly created MOBY Central (+ Fix) In-Reply-To: <41361C32.1020405@cnb.uam.es> References: <41361C32.1020405@cnb.uam.es> Message-ID: <1094067029.17672.55.camel@myhost.mydomain> Sorry, I am hoping to get all of the documentation updated as quickly as possible, but grant deadlines are getting in the way... The change to the database structure was (I think) announced on the mailing list. You can also get it by calling the 'DUMP' method of MOBY::Central (or via the client), or you can examine the database directly by logging in to a mysql session with the username moby_external (no password) here's the table definition for service_instance: +---------------------+----------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------------+----------------------------------+------+-----+---------+----------------+ | category | enum('moby','soap','wsdl','cgi') | YES | | NULL | | | servicename | varchar(255) | | MUL | | | | service_type_uri | varchar(255) | | | | | | authority_id | int(10) unsigned | | | 0 | | | url | varchar(255) | | | | | | contact_email | varchar(255) | | | | | | authoritative | enum('1','0') | | | 0 | | | description | text | | | | | | service_instance_id | int(10) unsigned | | PRI | NULL | auto_increment | | signatureURL | varchar(255) | YES | | NULL | | +---------------------+----------------------------------+------+-----+---------+----------------+ M On Wed, 2004-09-01 at 12:00, Jos? Mar?a Fern?ndez Gonz?lez wrote: > Hi everybody, > soon I'm going to give a practical seminar about MOBY, and I'm creating > a local MOBY Central for the practices. This is not my first time > creating a MOBY Central (I created one 9 months ago), but last version > in CVS seems to have problems. > > First of all, intructions in > > http://www.biomoby.org/InstallingMOBYCentral.html > > should be updated, because last RDF changes in MOBY require RDF::Core > Perl library as a pre-requisite before running a MOBY Central (and > perhaps a the other libraries??). > > The problem I have found is the next: I ran the > testMOBYClientCentral_v05.pl script in order to check if the > installation was correct. First try failed in the first test due the > lack of RDF::Core. The second try (after installing RDF::Core) seemed to > run well until it failed in the 18th one, which corresponds to > registerService. Next lines are from the Apache error log: > > [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] Useless use of > hash element in void context at > /usr/lib/perl5/site_perl/5.8.3/RDF/Core/Serializer.pm line 52. > [Wed Sep 01 19:24:13 2004] [error] [client 127.0.0.1] DBD::mysql::db > selectrow_array failed: Unknown column 'signatureURL' in 'field list' at > /usr/lib/perl5/site_perl/5.8.3/MOBY/Adaptor/moby/queryapi/mysql.pm line > 172, line 34 > > I have dug inside the referenced file told by the error message, and it > is a query to the tables service_instance and authority from mobycentral > database. It seems the signatureURL column should exist in > service_instance table, and so moby database skeletons in CVS should be > updated. > > What data type should have that column, Mark? I have created it as a > VARCHAR(255), and now it works. > > Last, moby database skeletons (ie mysql dumps) in CVS should also be > updated in order to reflect the last small change Mark told us about the > datatype of maximum_value and minimum_value. > > Best Regards, > Jos? Mar?a -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From michael at acutrans.net Fri Sep 3 13:24:19 2004 From: michael at acutrans.net (Michael Jensen) Date: Fri, 3 Sep 2004 12:24:19 -0500 Subject: [MOBY-l] Taverna workflows? Other GUIs? Message-ID: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Anyone have any Taverna workflows for BioMOBY? I tried building one real quick but it didn't work (first time using Taverna). Maybe we should have a few example workflows on the BioMOBY site? It may have been polled here before, but anyone using BioMOBY with something other than Java or Perl? Also, are there other GUIs like Taverna that work with BioMOBY? THANKS! -Michael Jensen From gordonp at cbr.nrc.ca Fri Sep 3 13:52:28 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Fri, 03 Sep 2004 11:52:28 -0600 Subject: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Message-ID: <4138AF5C.2010807@cbr.nrc.ca> Michael Jensen wrote: > Anyone have any Taverna workflows for BioMOBY? I tried building one > real quick but it didn't work (first time using Taverna). Maybe we > should have a few example workflows on the BioMOBY site? > > It may have been polled here before, but anyone using BioMOBY with > something other than Java or Perl? There is a Ruby API. > Also, are there other GUIs like Taverna that work with BioMOBY? You can link to MOBY services from Bluejay. The GUI is being reworked for memory-starved applets, so it may be a little gimpy for the next couple weeks. For a quick example, go to the applet at http://bluejay.ucalgary.ca/test/ Once the welcome page has loaded, go Bookmarks->Viral Genomes -> SSV1. Click on a gene with a functional category, wait a second, and you'll get Moby services that take GO terms. The results show up in a separate windows. Attached is an example image. > > THANKS! > > -Michael Jensen > > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From mwilkinson at mrl.ubc.ca Fri Sep 3 13:59:26 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Fri, 03 Sep 2004 10:59:26 -0700 Subject: [MISC] [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Message-ID: <1094234365.2043.5.camel@myhost.mydomain> there's also a python API contributed by Yan Wong from the Ressource Parisienne en Bioinformatique Structurale. I imported it into the CVS about two weeks ago. M On Fri, 2004-09-03 at 10:24, Michael Jensen wrote: > Anyone have any Taverna workflows for BioMOBY? I tried building one > real quick but it didn't work (first time using Taverna). Maybe we > should have a few example workflows on the BioMOBY site? > > It may have been polled here before, but anyone using BioMOBY with > something other than Java or Perl? > > Also, are there other GUIs like Taverna that work with BioMOBY? > > > THANKS! > > -Michael Jensen > > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Fri Sep 3 17:17:45 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Fri, 03 Sep 2004 14:17:45 -0700 Subject: [MOBY-l] FAQ for MOBY Services Message-ID: <1094246265.2043.89.camel@myhost.mydomain> Hi all, I've set up a FAQ page for MOBY Services - it's just another page on the Wiki. You can get to it from the "tutorials" link on the biomoby homepage. Right now it's empty (not because nobody has ever asked a question ;-) ). Anyone can register to be a twiki author, or you can simply send me your FAQ/answer and I will add it to that page. It would be great to have this page created as a community effort, however. Thanks for Mathieu for the suggestion! Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From rebecca.ernst at gsf.de Mon Sep 6 09:26:23 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Mon, 06 Sep 2004 15:26:23 +0200 Subject: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> Message-ID: <413C657F.8020101@gsf.de> Hi Michael! I set up a Taverna workflow built of BioMoby services. I attached it - hope it works for you . You need to load that workflow file (You'll then see the whole workflow as diagram) once you say "run workflow" you'll get the input document with namespace and id. There are no values filled in so you have to fill in some. click on 'namespace' and then 'new input' and put "Global_Keyword". For id do the same and put "wuschel". Then you can run it. Good luck! Rebecca Michael Jensen wrote: > Anyone have any Taverna workflows for BioMOBY? I tried building one > real quick but it didn't work (first time using Taverna). Maybe we > should have a few example workflows on the BioMOBY site? > > It may have been polled here before, but anyone using BioMOBY with > something other than Java or Perl? > > Also, are there other GUIs like Taverna that work with BioMOBY? > > > THANKS! > > -Michael Jensen > > > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Mon Sep 6 09:54:26 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 06 Sep 2004 06:54:26 -0700 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <413C657F.8020101@gsf.de> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> Message-ID: <1094478865.7402.10.camel@myhost.mydomain> Mailman seems to have stripped the attachment from Rebecca's message. I don't know why it sometimes does and sometimes doesn't. I'm trying to attach it again here... I hope! M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From rebecca.ernst at gsf.de Mon Sep 6 10:38:03 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Mon, 06 Sep 2004 16:38:03 +0200 Subject: [MOBY-l] Class ontology question In-Reply-To: <1094479321.7401.17.camel@myhost.mydomain> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> <1094478865.7402.10.camel@myhost.mydomain> <1094479321.7401.17.camel@myhost.mydomain> Message-ID: <413C764B.9080702@gsf.de> Hi Mark! I had some discussions on the class ontology with my colleague Dirk and we didn't come up with a solution to our problem so I hope you have an answer to it ;-) I read your DesignAnObject page and found out that my Virtual Sequence object is not correct in that terms. It looks like this: blabla atgtaag... If I get it right GenericSequence HASA String. this means that it contains exactly ONE instance of String. But my object contains TWO instances of String. If the relationship of GenericSequence would be HAS instead of HASA it would be 'legal' I suppose. What would be the correct way to Design the object? Should I have another object CommentedSequence ISA GenericSequence HASA String OR CommentedSequence ISA Virtural Sequence HAS String ??? What's the purpose of having two similar relationships (HASA and HAS)? Thanks in advance Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From markw at illuminae.com Mon Sep 6 10:02:02 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 06 Sep 2004 07:02:02 -0700 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094478865.7402.10.camel@myhost.mydomain> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> <1094478865.7402.10.camel@myhost.mydomain> Message-ID: <1094479321.7401.17.camel@myhost.mydomain> Trying again as a tar.gz file attachment. On Mon, 2004-09-06 at 06:54, Mark Wilkinson wrote: > Mailman seems to have stripped the attachment from Rebecca's message. I > don't know why it sometimes does and sometimes doesn't. > > I'm trying to attach it again here... I hope! > > M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From markw at illuminae.com Mon Sep 6 10:51:39 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 06 Sep 2004 07:51:39 -0700 Subject: [MISC] [MOBY-l] Class ontology question In-Reply-To: <413C764B.9080702@gsf.de> References: <16FD952A-FDCE-11D8-8E51-000393B6201C@acutrans.net> <413C657F.8020101@gsf.de> <1094478865.7402.10.camel@myhost.mydomain> <1094479321.7401.17.camel@myhost.mydomain> <413C764B.9080702@gsf.de> Message-ID: <1094482299.7894.7.camel@myhost.mydomain> Hi Rebecca, comments below... > I read your DesignAnObject page and found out that my Virtual Sequence > object is not correct in that terms. > > It looks like this: > > > > blabla > atgtaag... > Okay... I think you have made a few errors here, but they might just be typo's. The object above is nether a VirtualSequence, nor a GenericSequence, so your outer tag is incorrect. I assume that this is your "CommentedSequence" object that you describe below? > If I get it right GenericSequence HASA String. this means that it > contains exactly ONE instance of String. But my object contains TWO > instances of String. correct > If the relationship of GenericSequence would be HAS instead of HASA it > would be 'legal' I suppose. not really... > What would be the correct way to Design the object? Should I have > another object > CommentedSequence ISA GenericSequence HASA String > OR > CommentedSequence ISA Virtural Sequence HAS String > ??? The first one is correct. You should have: CommentedSequence ISA GenericSequence HASA String(Description) This is the purpose of the articleName attribute. Effectively, it functions as an RDF predicate, if you were to imagine it that way. > What's the purpose of having two similar relationships (HASA and HAS)? So that objects can have an indefinite number of contained objects. For example, if you were trying to model a Genbank feature table, you wouldn't know a priori how many exons the gene had, so those would be modelled with a "HAS" relationship. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Mon Sep 6 12:54:50 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Mon, 6 Sep 2004 17:54:50 +0100 (BST) Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094479321.7401.17.camel@myhost.mydomain> Message-ID: > Trying again as a tar.gz file attachment. > The sure way is to name it: XXXX.clean 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 markw at illuminae.com Mon Sep 6 18:55:51 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Mon, 06 Sep 2004 15:55:51 -0700 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: References: Message-ID: <1094511351.10474.0.camel@myhost.mydomain> OKay, let's try that idea... attached again with a .clean extension M On Mon, 2004-09-06 at 09:54, Martin Senger wrote: > > Trying again as a tar.gz file attachment. > > > The sure way is to name it: XXXX.clean > Martin -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Mon Sep 6 19:10:25 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 7 Sep 2004 00:10:25 +0100 (BST) Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: > attached again with a .clean extension > I will never say again "a sure way"... M. -- 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 rebecca.ernst at gsf.de Tue Sep 7 03:14:17 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Tue, 07 Sep 2004 09:14:17 +0200 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094511351.10474.0.camel@myhost.mydomain> References: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: <413D5FC9.1000709@gsf.de> Thanks for trying Mark! There seems to be no way to attach it via the mailinglist. Anyone who is interested in the taverna example workflow let me know and I'll send it to you directly! Rebecca Mark Wilkinson wrote: >OKay, let's try that idea... > >attached again with a .clean extension > >M > > >On Mon, 2004-09-06 at 09:54, Martin Senger wrote: > > >>>Trying again as a tar.gz file attachment. >>> >>> >>> >> The sure way is to name it: XXXX.clean >> Martin >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>moby-l mailing list >>moby-l at biomoby.org >>http://biomoby.org/mailman/listinfo/moby-l >> >> -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From p.lord at russet.org.uk Tue Sep 7 09:44:40 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 07 Sep 2004 14:44:40 +0100 Subject: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: <1094511351.10474.0.camel@myhost.mydomain> References: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Stick it on the web, and send a URL. This always works. Probably. Phil From mwilkinson at mrl.ubc.ca Tue Sep 7 10:26:44 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 07 Sep 2004 07:26:44 -0700 Subject: [SPAM] Re: [MISC] Re: [MOBY-l] Taverna workflows? Other GUIs? In-Reply-To: References: <1094511351.10474.0.camel@myhost.mydomain> Message-ID: <1094567204.1974.9.camel@myhost.mydomain> It is possible to attach documents to TWiki pages as well. That might be a good option in the longer-term. There is a FAQ on the MOBY TWiki now, and anyone who registers can add to it. M On Tue, 2004-09-07 at 06:44, Phillip Lord wrote: > >>>>> "Mark" == Mark Wilkinson writes: > > > > Stick it on the web, and send a URL. This always works. > > Probably. > > > Phil > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From michael at acutrans.net Wed Sep 8 14:39:45 2004 From: michael at acutrans.net (Michael Jensen) Date: Wed, 8 Sep 2004 13:39:45 -0500 Subject: [MOBY-l] versioning services...authentication... Message-ID: <747BC42E-01C6-11D9-AAE1-000393B6201C@acutrans.net> Are there suggestions for maintaining versions of your services? Say you have a version 2 that is quite different than version 1, it would seem you would either want to maintain version 1 as is, and register version 2 as a new service (with a new name), or alternatively to deregister service 1 and register service 2 with a new name. Maybe this has been brought up before or maybe there is a better way? Also, I am sure it has been discussed before, but what about authentication for services? Say I have a service that I need you to be a registered user for, how does that fit in with it all? Point me to any previous discussions if this has been exhausted previously. -Michael Jensen From michael at acutrans.net Wed Sep 8 15:25:44 2004 From: michael at acutrans.net (Michael Jensen) Date: Wed, 8 Sep 2004 14:25:44 -0500 Subject: [MOBY-l] RDQL and moby registry? Message-ID: What is the potential application of RDQL with the current registry system, or future revisions of the system, and do you think it will prove useful? (RDQL is a RDF query language basically) Here is a demo of RDQL. There is a perl module for RDQL too, I noticed. http://www3.wiwiss.fu-berlin.de/rdfapi-php/test/custom_rdql_test.php Just hit "submit me!" and it searches for the creator of the RDF document. -Michael Jensen From r.bruskiewich at cgiar.org Wed Sep 8 20:06:54 2004 From: r.bruskiewich at cgiar.org (Bruskiewich, Richard (IRRI)) Date: Wed, 08 Sep 2004 17:06:54 -0700 Subject: [MOBY-l] versioning services...authentication... Message-ID: <2A491C94FFBC5843A212A69CBEA5CEC7AA8417@IRRIMAIL.irri.cgiar.org> Re: authentication... I presume that you mean user authentication to use a specific web service on your provider? Remember that web services (e.g. MOBY) use HTTP and its cousins for access. You therefore have access to web server access authentication. Using HTTPS or similar protocols would provide for secure authentication. Using Java servlet web services might provide even more fine control. At least, that's the idea we're toying in our efforts... Cheers Richard ============================================== Richard Bruskiewich, PhD Senior Bioinformatics Specialist International Rice Research Institute DAPO 7777, Metro Manila, Philippines r.bruskiewich at cgiar.org Web: www.irri.org Tel: +63-2-580-5600 Fax: +63-2-580-5699 ============================================ -----Original Message----- From: Michael Jensen [mailto:michael at acutrans.net] Sent: Thursday, September 09, 2004 2:40 AM To: moby-l at biomoby.org Subject: [MOBY-l] versioning services...authentication... Are there suggestions for maintaining versions of your services? Say you have a version 2 that is quite different than version 1, it would seem you would either want to maintain version 1 as is, and register version 2 as a new service (with a new name), or alternatively to deregister service 1 and register service 2 with a new name. Maybe this has been brought up before or maybe there is a better way? Also, I am sure it has been discussed before, but what about authentication for services? Say I have a service that I need you to be a registered user for, how does that fit in with it all? Point me to any previous discussions if this has been exhausted previously. -Michael Jensen _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l From mwilkinson at mobile.rogers.com Wed Sep 8 21:02:09 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Wed, 8 Sep 2004 21:02:09 -0400 Subject: [MOBY-l] versioning services...authentication... Message-ID: <200409090111.i891B1Kr031886@portal.open-bio.org> Richard beat me to the punch :-) That is entirely correct. Moby-s inherits its authentication from SOAP, which inherits its authentication from HTTP. The MOBY::Client::Central module actually handles authentication if you are running your script from the command line (God help me if I remember exactly how... Matt Links and I wrote a few secure services in my living room a couple of years ago and that was the last time I looked at that code... Unfortunalely I left my machine in the lab today so I can't look it up) Anyway, authentication isn't something we need to worry deeply about. It is all handled by libraries below our Moby libs. It's nothing more than a trivial line or two of code to implement the solution for your own situation. M -----Original Message----- From: "Bruskiewich, Richard (IRRI)" Date: Wed, 08 Sep 2004 17:06:54 To:Michael Jensen , moby-l at biomoby.org Subject: RE: [MOBY-l] versioning services...authentication... Re: authentication... I presume that you mean user authentication to use a specific web service on your provider? Remember that web services (e.g. MOBY) use HTTP and its cousins for access. You therefore have access to web server access authentication. Using HTTPS or similar protocols would provide for secure authentication. Using Java servlet web services might provide even more fine control. At least, that's the idea we're toying in our efforts... Cheers Richard ============================================== Richard Bruskiewich, PhD Senior Bioinformatics Specialist International Rice Research Institute DAPO 7777, Metro Manila, Philippines r.bruskiewich at cgiar.org Web: www.irri.org Tel: +63-2-580-5600 Fax: +63-2-580-5699 ============================================ -----Original Message----- From: Michael Jensen [mailto:michael at acutrans.net] Sent: Thursday, September 09, 2004 2:40 AM To: moby-l at biomoby.org Subject: [MOBY-l] versioning services...authentication... Are there suggestions for maintaining versions of your services? Say you have a version 2 that is quite different than version 1, it would seem you would either want to maintain version 1 as is, and register version 2 as a new service (with a new name), or alternatively to deregister service 1 and register service 2 with a new name. Maybe this has been brought up before or maybe there is a better way? Also, I am sure it has been discussed before, but what about authentication for services? Say I have a service that I need you to be a registered user for, how does that fit in with it all? Point me to any previous discussions if this has been exhausted previously. -Michael Jensen _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l _______________________________________________ moby-l mailing list moby-l at biomoby.org http://biomoby.org/mailman/listinfo/moby-l !!!!!!!!!!!!!!!! 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 p.lord at russet.org.uk Thu Sep 9 12:19:45 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 09 Sep 2004 17:19:45 +0100 Subject: [MOBY-l] RDQL and moby registry? In-Reply-To: References: Message-ID: >>>>> "Michael" == Michael Jensen writes: Michael> What is the potential application of RDQL with the current Michael> registry system, or future revisions of the system, and do Michael> you think it will prove useful? Michael> (RDQL is a RDF query language basically) Michael> Here is a demo of RDQL. There is a perl module for RDQL Michael> too, I noticed. Michael> http://www3.wiwiss.fu-berlin.de/rdfapi-php/test/custom_rdql_test.php Michael> Just hit "submit me!" and it searches for the creator of Michael> the RDF document. I don't know whether Mark is putting a RDF/RDQL backend onto moby, but within the mygrid project we have created a similar semantically searchable registry. The current version, written by Pinar Alper, uses a RDF backend (using Jena) and gets all of its query functionality through RDQL. We've also used RDF/RDQL for storing It works quite well. So yes there is definitely a potential application for RDQL within future versions of moby. Mark can say for himself if he is going to try it. Cheers Phil From mwilkinson at mrl.ubc.ca Thu Sep 9 12:44:39 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 09 Sep 2004 09:44:39 -0700 Subject: [MISC] Re: [MOBY-l] RDQL and moby registry? In-Reply-To: References: Message-ID: <1094748278.1633.30.camel@myhost.mydomain> Hi all, it seems that some of my messages from last night never got through... I'm re-sending my answer: It should be possible, in principle, to search MOBY Central using RDQL already. There is an RDF representation of the registry at: http://biomoby.org/RESOURCES/MOBY-S/ServiceInstances It is auto-generated, so it should always be up-to-date. AFAIK there is no reason that you couldn't just do RDQL searches on that document. Let me know if it works for you. M On Thu, 2004-09-09 at 09:19, Phillip Lord wrote: > >>>>> "Michael" == Michael Jensen writes: > > Michael> What is the potential application of RDQL with the current > Michael> registry system, or future revisions of the system, and do > Michael> you think it will prove useful? > > Michael> (RDQL is a RDF query language basically) > > > Michael> Here is a demo of RDQL. There is a perl module for RDQL > Michael> too, I noticed. > > Michael> http://www3.wiwiss.fu-berlin.de/rdfapi-php/test/custom_rdql_test.php > > Michael> Just hit "submit me!" and it searches for the creator of > Michael> the RDF document. > > > I don't know whether Mark is putting a RDF/RDQL backend onto moby, but > within the mygrid project we have created a similar semantically > searchable registry. The current version, written by Pinar Alper, uses > a RDF backend (using Jena) and gets all of its query functionality > through RDQL. We've also used RDF/RDQL for storing > > It works quite well. > > So yes there is definitely a potential application for RDQL within > future versions of moby. Mark can say for himself if he is going to > try it. > > Cheers > > Phil > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From ian.donaldson at mshri.on.ca Fri Sep 10 01:20:15 2004 From: ian.donaldson at mshri.on.ca (Ian Donaldson) Date: Fri, 10 Sep 2004 01:20:15 -0400 Subject: [MOBY-l] BioMoby and SeqHound Message-ID: <490D0AFAF3D2D3119F6C00508B6FDF1506F1D2F8@ex.mshri.on.ca> Dear all: SeqHound is a freely available bioinformatics database warehouse resource that is available via a remote programming API in C, C++, Java and Perl. A number of SeqHound API calls have been wrapped up as BioMoby services by Mark Wilkinson. We (the SeqHound development group) are considering setting up our own BioMoby-SeqHound server that will make more SeqHound services available to BioMoby users. In order to direct our development efforts, we are looking for feedback (posted to this list) as to what API calls people would find most useful as BioMoby services. The capabilities of the SeqHound API include functions that return GenBank sequence records, MMDB or PDB structure records, GO annotation assignments and pre-computed BLAST and RPS-BLAST results. There are many others. A complete list of the API is available at http://www.blueprint.org/seqhound/api_help/seqhound_help_guides.html. Any requests/feedback is most welcome. Thanks Ian Ian Donaldson, Ph.D. Manager of Bioinformatics Software Development The Blueprint Initiative - North America 522 University Ave. Toronto, Ontario, Canada M5G 1W7 http://blueprint.org ian.donaldson at blueprint.org About SeqHound SeqHound is a freely available bioinformatics database warehouse resource. Over 300 Gigabytes of data are collected, integrated and updated from around the world on a nightly basis. Sources include the National Center for Biotechnology Information and the Gene Ontology Consortium. Programmers have unrestricted access to up-to-date data via a remote Application Programming Interface (API) written in Perl, Java, C and C++. Over 150 function calls allow access to the complete collection of GenBank, RefSeq and SwissProt sequences, 3-D structures, precomputed protein neighbours, redundancies and conserved domain analyses. Users may also access collected sequence annotations including taxonomy, Gene Ontology assignments and PubMed links. All functions are fully documented and tested on a daily basis. The Blueprint SeqHound server is supported by a redundant architecture (failover load-balancers, failover servers and, failover SANs) for complete fault protection against component failure and to ensure rapid response time. SeqHound encourages unrestricted 24x7 calls to its servers, to allow programmers rapid, uninterrupted, access to biological data on a global basis. SeqHound services over 700,000 hits per day. All SeqHound code is freely distributed under the GNU Public License. Find SeqHound at www.blueprint.org. SeqHound v3.0 is available for download now from http://www.blueprint.org/seqhound/api_help/seqhound_help_guides.html. Major changes to this release include a port to a MySQL database backend allowing users to install a virtually free bioinformatics-programming platform in-house using instructions provided in the SeqHound Manual. The remote API (available in Java and Perl) is now supported by a FastCGI server for even faster response times. We are interested in identifying developers who are already using SeqHound. If you are, please sign up for the seqhound.usergroup email list at http://lists.blueprint.org/mailman/listinfo/seqhound.usergroup. Feedback and discussions on future development are welcome at this list. From mwilkinson at mrl.ubc.ca Tue Sep 14 11:37:08 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 14 Sep 2004 08:37:08 -0700 Subject: [MISC] Re: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Message-ID: <1095176228.3247.116.camel@myhost.mydomain> On Wed, 2004-09-01 at 10:06, Phillip Lord wrote: > I think OWL-S is mostly aimed at automated composition which is not > really what moby-s is aimed at. You're unlikely to be able to get > semantic descriptions rich enough to describe services well enough to > be able to do this anyway, in which case you are accepting a lot of > complexity from OWL-S which will not necessarily buy you very much. We looked into this in some detail at my lab meeting last week. The tentative conclusion was the we could, in principle, describe a MOBY service in OWL-S if we had to. It may or may not be useful to do so, and we need to overcome the current lack of a MOBYObject->XSD translator. However, what we could NOT describe was the MOBY Invocation Message structure, since the message structure allows multiple invocations in a single message, each of which may be a different object type (so long as they are ontologically related). So the final conclusion was that, at least as it exists today, MOBY-S cannot be described in OWL-S (at leats as far as we understand it). This is not a commentary on the usefulness/not of MOBY-S nor OWL-S, it is just an observation. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From fgibbons at hms.harvard.edu Tue Sep 14 13:30:30 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Tue, 14 Sep 2004 13:30:30 -0400 Subject: [MISC] Re: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: <1095176228.3247.116.camel@myhost.mydomain> References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040914132849.01a00098@email.med.harvard.edu> Mark, Philip, Thanks for clarifying things: both the question in my mind (could/should MOBY-S use OWL-S?), and the confusion caused by my incomplete grasp of things semantic. -F At 11:37 AM 9/14/2004, Mark Wilkinson wrote: >On Wed, 2004-09-01 at 10:06, Phillip Lord wrote: > > > I think OWL-S is mostly aimed at automated composition which is not > > really what moby-s is aimed at. You're unlikely to be able to get > > semantic descriptions rich enough to describe services well enough to > > be able to do this anyway, in which case you are accepting a lot of > > complexity from OWL-S which will not necessarily buy you very much. > >We looked into this in some detail at my lab meeting last week. The >tentative conclusion was the we could, in principle, describe a MOBY >service in OWL-S if we had to. It may or may not be useful to do so, >and we need to overcome the current lack of a MOBYObject->XSD >translator. > >However, what we could NOT describe was the MOBY Invocation Message >structure, since the message structure allows multiple invocations in a >single message, each of which may be a different object type (so long as >they are ontologically related). > >So the final conclusion was that, at least as it exists today, MOBY-S >cannot be described in OWL-S (at leats as far as we understand it). > >This is not a commentary on the usefulness/not of MOBY-S nor OWL-S, it >is just an observation. > >M >-- >Mark Wilkinson (mwilkinson at mrl.ubc.ca) >University of British Columbia iCAPTURE Centre >_______________________________________________ >moby-l mailing list >moby-l at biomoby.org >http://biomoby.org/mailman/listinfo/moby-l PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From p.lord at russet.org.uk Tue Sep 14 13:50:53 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 14 Sep 2004 18:50:53 +0100 Subject: [MISC] Re: [MOBY-l] OWL-S, and RDF ontology for MOBY? In-Reply-To: <1095176228.3247.116.camel@myhost.mydomain> References: <5.2.1.1.2.20040901111324.01a1acd8@email.med.harvard.edu> <1095176228.3247.116.camel@myhost.mydomain> Message-ID: >>>>> "Mark" == Mark Wilkinson writes: Mark> On Wed, 2004-09-01 at 10:06, Phillip Lord wrote: >> I think OWL-S is mostly aimed at automated composition which is >> not really what moby-s is aimed at. You're unlikely to be able to >> get semantic descriptions rich enough to describe services well >> enough to be able to do this anyway, in which case you are >> accepting a lot of complexity from OWL-S which will not >> necessarily buy you very much. Mark> We looked into this in some detail at my lab meeting last Mark> week. The tentative conclusion was the we could, in Mark> principle, describe a MOBY service in OWL-S if we had to. It Mark> may or may not be useful to do so, and we need to overcome the Mark> current lack of a MOBYObject->XSD translator. Mark> However, what we could NOT describe was the MOBY Invocation Mark> Message structure, since the message structure allows multiple Mark> invocations in a single message, each of which may be a Mark> different object type (so long as they are ontologically Mark> related). Can you really not describe this in OWL-S? I will admit to not having looked at OWL-S for sometime, but surely the input/output slots are not constrained to being a specific named class? You should be able to put in arbitrary class definitions, in which case you should be able to use conjunctions of classes. Mark> So the final conclusion was that, at least as it exists today, Mark> MOBY-S cannot be described in OWL-S (at leats as far as we Mark> understand it). Mark> This is not a commentary on the usefulness/not of MOBY-S nor Mark> OWL-S, it is just an observation. Actually, it is a commentary on both! Although, that you can't do in MOBY-S what you can do in OWL-S and you can't do in OWL-S what you can in MOBY-S, is probably not that surprising. Nor that much of a problem for either. They are aimed at somewhat different markets. Cheers Phil From senger at ebi.ac.uk Tue Sep 14 16:10:11 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 14 Sep 2004 21:10:11 +0100 (BST) Subject: [MOBY-l] versioning services...authentication... In-Reply-To: <200409090111.i891B1Kr031886@portal.open-bio.org> Message-ID: > Anyway, authentication isn't something we need to worry deeply about. > It is all handled by libraries below our Moby libs. It's nothing more > than a trivial line or two of code to implement the solution for your > own situation. > I am not sure about it. I would prefer to see some code documenting it. I know that I myself said that authentication is the task of the underlying protocol - that's what Richard expressed here and what Mark confirmed. But I think (but I may be wrong) that we all three were talking from the perspective of the service provider. Simply speaking: service provider does not need to change his/her code when [s]he wants to have the service only for registered users, [s]he just adds an HTTP special file with an HTTP authentication configuration to her/his CGI-bin directory. But from the client perspective it may be different. And I do not think that the Moby clients can handle authentication. Surely not my Java client. We probably need to extend our clients libraries in order to be able to accept user name and password (in a way that is dependent on their user interface) and use it in the HTTP/SOAP request (in another way to do what any Netscape does for us hiddenly for years). Just my 2c, and with regards, Martin PS. Mark, this email was also about versioning. Do you have an answer, or a policy for that? M. -- 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 mrl.ubc.ca Wed Sep 15 11:58:07 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 15 Sep 2004 08:58:07 -0700 Subject: [MOBY-l] URGENT: Attention ALL SERVICE PROVIDERS Message-ID: <1095263887.5954.78.camel@myhost.mydomain> Hi all, we are getting ready to make a very significant change in MOBY-S, so I need **all existing service providers** to do a one-time exercise. This is also important for those who have their own MOBY Central installations. As we discussed at the last MOBY meeting, it is desirable and 'good' for MOBY Central's registry to extract its information using a mechanism more like a web crawler (more like S-MOBY :-) ). As a result, Nina has written an agent that will crawl known MOBY service providers and extract their service signatures from RDF files. The agent runs on a cron, and behaves as follows: 1) It looks up the last known address of your service signature in the database 2) It GET's that address expecting to find an RDF file 3) If it doesn't find a valid RDF file there, then it flags an error; after a certain number of errors your service(s) will be deregistered. (I believe that it also emails the contactEmail address and tells them that there was an error.) 4) If it finds an RDF, it compares the signatures of each service described in that RDF with the database, and updates or adds these service descriptions as necessary. 5) If it expects to find a service signature in this RDF, and can't find it, it concludes that the service has been taken off-line, and it will de-register that service. 6) The agent should be (touch wood!) tolerant of additional RDF in this signature, such that you can add your own additional annotations to this RDF as you wish. The behaviour of MOBY Central is as follows: 1) When you register a service, you may include a SignatureURL field in your XML (or as a parameter to the MOBY::Client::Central API) indicating where your RDF will be located. 2) Upon successful registration of your service, MOBY Central will send you the RDF signature of your service - you will not have to generate this yourself! (unless you want to... and feel free to do so!). It appears in the block of the MOBY Registration object (the ->RDF method of the MOBY:Registration object) 3) To ensure that your service is not deleted, you must place this RDF signature in the location that you specified in the signatureURL field when you registered your service. 4) If you do not include a signatureURL in your service registration, your service will be de-registered the next time the agent runs (since it will be unable to find an RDF file matching your service). This might be useful for people who are doing simple test services, as they wont clutter up the registry for long... 4) The deregisterService method of the MOBY Central API will **NOT** function for any service that has a signatureURL. It will function as expected for any service does not have a signatureURL. So, in short, services now have a signatureURL that points to an RDF file describing their service. An agent will crawl around on a regular basis looking at these RDF signatures. If you update a service, you change the RDF. if you remove a service, you delete that portion of the RDF. If you add a service, you either add a new signature to the RDF and let the agent register it automatically, or you use the registerService function of MOBY Central as you have in the past, and allow MOBY Central to generate the RDF for you. Services without a signatureURL WILL BE DELETED!!!! Of course, at the moment nobody has a signatureURL :-) I have set up a simple CGI page for existing service providers where they can supply a URL and get the signature RDF for all of their existing services: http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl We will switch the agent on in a week or so, and after that all services without a signatureURL will be deleted, so please go to this page ASAP. If the script doesn't work, or if you have any problems please let me know and I or Nina will fix them immediately. I hope this isn't too disruptive to people. I'm convinced that it is a change for the better! Contact me by phone or email if you have any concerns. Cheers all! M -- Mark Wilkinson, Assistant Professor (Bioinformatics) Dept. of Medical Genetics, University of British Columbia James Hogg iCAPTURE Centre for Cardiovascular and Pulmonary Research 166 - 1081 Burrard St. Vancouver, BC, Canada, V6Z 1Y6 tel: (604) 682 2344 ext. 62129 fax: (604) 806 9274 ------------------------------------------------------------------------ The death rate in Canada currently stands at one per person. Here at iCAPTURE, we are working hard to improve on that figure! ------------------------------------------------------------------------ From fgibbons at hms.harvard.edu Wed Sep 15 14:32:55 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 15 Sep 2004 14:32:55 -0400 Subject: [MOBY-l] signatureURLs; test registry In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain> Message-ID: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> Mark, >we are getting ready to make a very significant change in MOBY-S, so I >need **all existing service providers** to do a one-time exercise. This >is also important for those who have their own MOBY Central installations. The CGI (http://mobycentral.cbr.nrc.ca/cgi-bin/getRDFXML.pl) you put up to make signature RDF worked fine for me (and was really fast), but it did raise one or two questions: >3) To ensure that your service is not deleted, you must place this RDF >signature in the location that you specified in the signatureURL field >when you registered your service. As soon as I had done it the first time, I realised "Oh no, that's not a good place to put the RDF!", so I ran the CGI again, this time with a more sensible location for the RDF. Will that work? In other words, does re-running it erase the old location, or will my services now end up being de-registered because there's no RDF in the first location I entered, although it is present and accessible in the second (and final) location I entered? Glad to hear the crawler will be "coming soon to a website near me" ;) I'm wondering how often it'll run - should I expect one visit a day, or one a week? Specifically, I'm wondering what the latency will be if I decide to register a new service by firing up IsaViz and adding to the RDF, rather than using a call to MOBY Central? In the latter case, I expect the service to be immediately registered, but what about the former? And finally, what's up with the test registry - I can't seem to connect any longer (worked fine on Monday, I believe). Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From mwilkinson at mrl.ubc.ca Wed Sep 15 14:36:56 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 15 Sep 2004 11:36:56 -0700 Subject: [MOBY-l] Re: [MISC] signatureURLs; test registry In-Reply-To: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> References: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> Message-ID: <1095273416.9055.152.camel@myhost.mydomain> On Wed, 2004-09-15 at 11:32, Frank Gibbons wrote: > In other words, does > re-running it erase the old location, or will my services now end up being > de-registered because there's no RDF in the first location I entered, > although it is present and accessible in the second (and final) location I > entered? It will re-set each time you run it, so don't worry if you change your mind and run it again. Whatever you chose the last time you ran it will be what is in the database. > I'm > wondering how often it'll run - should I expect one visit a day, or one a > week? Specifically, I'm wondering what the latency will be if I decide to > register a new service by firing up IsaViz and adding to the RDF To be honest, that is something that we haven't decided yet. I see no good reason why it shouldn't run every night. My "gut" tells me, however, that most people who set up services will be anxious to see them in the registry right away to test them, so I suspect that most people will continue to use the API call rather than passively wait for their exciting new service to be registered by the crawler :-) > And finally, what's up with the test registry - I can't seem to connect any > longer (worked fine on Monday, I believe). I'll look into that right away. It may have crashed?! Thanks for the heads-up. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Wed Sep 15 14:48:41 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 15 Sep 2004 11:48:41 -0700 Subject: [MOBY-l] Re: [MISC] signatureURLs; test registry In-Reply-To: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> References: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> Message-ID: <1095274121.5952.157.camel@myhost.mydomain> On Wed, 2004-09-15 at 11:32, Frank Gibbons wrote: > And finally, what's up with the test registry - I can't seem to connect any > longer (worked fine on Monday, I believe). yup. It looks like the machine was rebooted sometime recently - the production registry comes up automatically, but the test registry has to be started manually. It's up now. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From gordonp at cbr.nrc.ca Wed Sep 15 15:33:34 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Wed, 15 Sep 2004 13:33:34 -0600 Subject: [MOBY-l] Re: [MISC] signatureURLs; test registry In-Reply-To: <1095273416.9055.152.camel@myhost.mydomain> References: <5.2.1.1.2.20040915142417.01ab6938@email.med.harvard.edu> <1095273416.9055.152.camel@myhost.mydomain> Message-ID: <4148990E.3060701@cbr.nrc.ca> Would it not make sense to run the agent against the RDF URL shortly after (let's say 5 minutes?) the service is registered. In this way, deleted services will be auto-deregistered about when their potential replacement services are registered. >> I'm >>wondering how often it'll run - should I expect one visit a day, or one a >>week? Specifically, I'm wondering what the latency will be if I decide to >>register a new service by firing up IsaViz and adding to the RDF >> >> > >To be honest, that is something that we haven't decided yet. I see no >good reason why it shouldn't run every night. My "gut" tells me, >however, that most people who set up services will be anxious to see >them in the registry right away to test them, so I suspect that most >people will continue to use the API call rather than passively wait for >their exciting new service to be registered by the crawler :-) > > > From p.lord at russet.org.uk Thu Sep 16 11:55:01 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 16 Sep 2004 16:55:01 +0100 Subject: [MOBY-l] Re: [MOBY-dev] Java developers, let's talk together In-Reply-To: References: Message-ID: >>>>> "Martin" == Martin Senger writes: Martin> 2) Building. What about to use Ant? :-) At the moment, some Martin> subprojects Martin> does not support much re-building by other users. Such Martin> support should be a primary rule for an open source Martin> project. Or am I too autocrative here? Martin> 3) Third-party libraries (the ones we have only as jar Martin> files). Martin> There is no single solution. Easy rebuilding is an essential. You might want to take a look at Maven. Its a little complex, but has some nice features. I've not used it in anger yet, as its not worth moving over existing infrastructure, but if you are putting a lot of new stuff in. Probably the nicest thing about it, is that it has good support for third party libraries. It gives a clean mechanism for obtaining new versions, describing which sub-projects use what, and if you have several projects using maven for sharing files between them. This also makes publishing your own work in a form people can build on easy. It might be worth having a look at. It builds on top of ant, rather than replaces it. Cheers Phil From mwilkinson at mrl.ubc.ca Thu Sep 16 18:02:51 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Sep 2004 15:02:51 -0700 Subject: [MOBY-l] Re: [MISC] Re: [MOBY-dev] URGENT: Attention ALL SERVICE PROVIDERS In-Reply-To: References: Message-ID: <1095372170.11263.37.camel@myhost.mydomain> Hi Martin, you're absolutely right. I had it in there during debugging so that I could retrieve messages where the XML was incorrectly formatted. I've removed that now, but it has the unfortunate consequence that **EVERYONE** must do a cvs update on their MOBY::Client::Central, since the old client library assumed that it was CDATA, and wont extract the RDF-XML from the registration object. I will also make a new release for those who are only downloading the releases. Ugh... sorry about that! M On Wed, 2004-09-15 at 13:20, Martin Senger wrote: > Mark, > I wonder why the RDF part in the registration object is marked as > CDATA. Because RDF must be anyway a valid XML why to bother to surround it > by CDATA. Having CDATA there would prevent me to have CDATA in RDF. Is > there any reason you use CDATA for the RDF part? > > Thanks, > Martin -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Sep 16 18:25:11 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Sep 2004 15:25:11 -0700 Subject: [MOBY-l] CVS update required & new release available Message-ID: <1095373511.11263.42.camel@myhost.mydomain> Hi all, I just had to make a change in the client code that will allow you to extract the RDF from the Registration object (Perl users only). Please do a CVS update if you are using CVS, or download the latest release from the biomoby.org/releases page, otherwise the RDF will not be available to you in the MOBY::Registration object. Java users should be (?? Martin/Paul ??) unaffected by this change - all I did was remove the CDATA tags around the RDF-XML in the Registration XML message. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From senger at ebi.ac.uk Thu Sep 16 18:32:23 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 16 Sep 2004 23:32:23 +0100 (BST) Subject: [MOBY-l] Re: [MOBY-dev] CVS update required & new release available In-Reply-To: <1095373511.11263.42.camel@myhost.mydomain> Message-ID: > Java users should be (?? Martin/Paul ??) unaffected by this change > I am just coding the whole new registration stuff, so I do not need to announce a change because I have not commited it yet :-) I will let Java users know soon... (I already must thank to Eddie for his valuable suggestions and conrtibutions). Cheers, 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 senger at ebi.ac.uk Tue Sep 21 07:02:34 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Tue, 21 Sep 2004 12:02:34 +0100 (BST) Subject: [MOBY-l] Re: [MOBY-dev] URGENT: Attention ALL SERVICE PROVIDERS In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain> Message-ID: Mark, I found the agent's behaviour description slightly inconsistent in one place (perhaps agent is not inconsistent, perhaps it is only the description, I have not tested the agent itself): > The agent runs on a cron, and behaves as follows: > ... > 3) If it doesn't find a valid RDF file there, then it flags an error; > after a certain number of errors your service(s) will be deregistered. > ... > 5) If it expects to find a service signature in this RDF, and can't > find it, it concludes that the service has been taken off-line, and it > will de-register that service. > So: if there is no file at all, it will try several times before de-registering the service. But if there is any RDF file but without my service, it will de-register it immediatelly. Why does it not behave the same in these two cases? In reality, it would mean slightly different behaviour when I am adding my first service (so the RDF file with all my services does not exist yes) and when I am adding the second and more services (when the RDF file exists - havig my previous services - but it still does not have my last one). 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 rebecca.ernst at gsf.de Wed Sep 22 08:33:53 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Wed, 22 Sep 2004 14:33:53 +0200 Subject: [MOBY-l] deregistering services without RDF agent Message-ID: <41517131.90707@gsf.de> Hi Mark, Hi Nina! I just ran into one problem with the RDF agent: I changed the output object of two of my services and I therefore wanted to deregister these two services and register them again with the correct output objects. But once I try to deregister them with the script I get the message that "it is illegal to deregister a service that has a signatureURL. Such services must be deregistered by deleting the RDF at the location identified by the signatureURL". I believe that it should be possible to deregister the services also via the script. (otherwise the agent will have to run every hour to keep track of changes and developers will still have a hard time waiting for the changes they made.) Did you think about this before? Any suggestions how it can be solved? Cheers, Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From fgibbons at hms.harvard.edu Wed Sep 22 12:35:32 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 22 Sep 2004 12:35:32 -0400 Subject: [MOBY-l] deregistration by removal of RDF Message-ID: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Question about the new (de)registration scheme: a week or two ago, we generated RDF for our existing services, which was produced as a single file containing all services. Now I wish to deregister one service, leaving the others intact. Obviously removal of the file is not an option, since then everything is deregistered at once. Well, I suppose I could do that, and then re-register everything, each with its own separate RDF document (which would have the advantage of simplicity, but result in a lot of work for me!) Another option is to edit the RDF (say, using IsaViz) to remove the offending service. That's easy, but then I'm wondering, how does MOBY Central *really* know what's registered? If it merely checks for the PRESENCE of the RDF file, my service will remain registered, even though it is no longer referred to in the RDF. So, my question really is: 1. does MOBY Central's web agent READ what's in the file. 2. And, since I'm no longer allowed to de-register by making a function call, how can I make MOBY Central aware of the deregistration in a prompt manner? Thanks, -Frank PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From gordonp at cbr.nrc.ca Wed Sep 22 13:04:56 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Wed, 22 Sep 2004 14:04:56 -0300 (ADT) Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: > So, my question really is: > > 1. does MOBY Central's web agent READ what's in the file. That's the impression I got... > 2. And, since I'm no longer allowed to de-register by making a function > call, how can I make MOBY Central aware of the deregistration in a prompt > manner? Perhaps the deregister call should be replaced by a refreshRDF call, which allows the service providers to "push" update events, while MOBY still "pulls" the RDF data for integrity reasons... From senger at ebi.ac.uk Wed Sep 22 13:16:38 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 22 Sep 2004 18:16:38 +0100 (BST) Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: > 1. does MOBY Central's web agent READ what's in the file. > Yes, I would guess so. Mark wrote: > 4) If it finds an RDF, it compares the signatures of each service > described in that RDF with the database, and updates or adds these > service descriptions as necessary. > 2. And, since I'm no longer allowed to de-register by making a function > call, how can I make MOBY Central aware of the deregistration in a prompt > manner? > I hope, strongly hope that this will not be true. See my previous, and Rebecca's, message. 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 fgibbons at hms.harvard.edu Wed Sep 22 15:11:58 2004 From: fgibbons at hms.harvard.edu (Frank Gibbons) Date: Wed, 22 Sep 2004 15:11:58 -0400 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: References: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: <5.2.1.1.2.20040922151048.019c9498@email.med.harvard.edu> At 01:16 PM 9/22/2004, you wrote: > > 1. does MOBY Central's web agent READ what's in the file. > > > Yes, I would guess so. Mark wrote: > > > 4) If it finds an RDF, it compares the signatures of each service > > described in that RDF with the database, and updates or adds these > > service descriptions as necessary. > > > 2. And, since I'm no longer allowed to de-register by making a function > > call, how can I make MOBY Central aware of the deregistration in a prompt > > manner? > > > I hope, strongly hope that this will not be true. See my previous, and >Rebecca's, message. Martin, thanks for the pointers - on reading Rebecca's earlier message, I realise that she asked the same question I did. -F PhD, Computational Biologist, Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA. Tel: 617-432-3555 Fax: 617-432-3557 http://llama.med.harvard.edu/~fgibbons From senger at ebi.ac.uk Wed Sep 22 17:49:49 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Wed, 22 Sep 2004 22:49:49 +0100 (BST) Subject: [MOBY-l] recent changes in jMoby In-Reply-To: <1095263887.5954.78.camel@myhost.mydomain> Message-ID: Dear Java developers, I have made few changes in the Java libraries in order to reflect the changes in service registration procedures (and few other fixes). It is recommended to 'cvs update -dP'. The changes (from docs/ChangeLog) are: 2004-09-22 Martin Senger * Fixed option -rs-out in MobyCmdLineClient. * Added a -debug option to the TestingCentral client. * Fixed TestingCentral client - it used incorectly user-defined data type in the output secondary article. * Added HAS relationship type for children of MobyDataType objects. It uses a new class MobyRelationship (meaning that methods returning children in MobyDataType got new signatures). * Changes reflecting new service registration procedure: - MobyService has new members with corresponding set/get methods for storing 'signatureURL' and a fully qualified path to the place where the service signature (an RDF document) can be stored). - CentralImpl stores retrieved RDF in a local file (read API for MobyService class, it explains what CentralImpl is doing). - command-line program MobyCmdLineClient got few new options in order to deal with 'signatureURL' (see its new help). Cheers, 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 markw at illuminae.com Wed Sep 22 19:40:06 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 22 Sep 2004 16:40:06 -0700 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922151048.019c9498@email.med.harvard.edu> References: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> <5.2.1.1.2.20040922151048.019c9498@email.med.harvard.edu> Message-ID: <41520D56.5050208@illuminae.com> You can immediately de-register a service that has no registered SignatureURI - this was to allow people to easily set up test services that would be deregistered rapidly if they forgot to do so manually. I guess if there is a need for a more immediate deregistration process for "real" services (i.e. those that had an RDF file sitting somewhere) then we could think about that. is it possible to remove your site from Google?? M Frank Gibbons wrote: > At 01:16 PM 9/22/2004, you wrote: > >> > 1. does MOBY Central's web agent READ what's in the file. >> > >> Yes, I would guess so. Mark wrote: >> >> > 4) If it finds an RDF, it compares the signatures of each service >> > described in that RDF with the database, and updates or adds these >> > service descriptions as necessary. >> >> > 2. And, since I'm no longer allowed to de-register by making a >> function >> > call, how can I make MOBY Central aware of the deregistration in a >> prompt >> > manner? >> > >> I hope, strongly hope that this will not be true. See my previous, >> and >> Rebecca's, message. > > > Martin, thanks for the pointers - on reading Rebecca's earlier > message, I realise that she asked the same question I did. > > -F > > > PhD, Computational Biologist, > Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA > 02115, USA. > Tel: 617-432-3555 Fax: 617-432-3557 > http://llama.med.harvard.edu/~fgibbons > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > From markw at illuminae.com Wed Sep 22 19:49:50 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Wed, 22 Sep 2004 16:49:50 -0700 Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> References: <5.2.1.1.2.20040922123039.01a150c8@email.med.harvard.edu> Message-ID: <41520F9E.3000603@illuminae.com> Frank Gibbons wrote: > 1. does MOBY Central's web agent READ what's in the file. Yes, this is why you are able to use that same file to do updates to your service without having to contact MOBY Central directly. > 2. And, since I'm no longer allowed to de-register by making a > function call, how can I make MOBY Central aware of the deregistration > in a prompt manner? > I think there is a simple solution to this. Let me get back to Vancouver (next week) and I'll try to implement it quickly. The suggestion of a "refresh" function is a good one, and I just want to think about how best to implement it. M > From senger at ebi.ac.uk Wed Sep 22 19:50:22 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Thu, 23 Sep 2004 00:50:22 +0100 (BST) Subject: [MOBY-l] deregistration by removal of RDF In-Reply-To: <41520D56.5050208@illuminae.com> Message-ID: > You can immediately de-register a service that has no registered > SignatureURI > Yes, but this is no problem, is it? :-) > guess if there is a need for a more immediate deregistration process for > "real" services (i.e. those that had an RDF file sitting somewhere) > then we could think about that. > What harm would be done if we just keep the same mechanism as before for all services? I guess that the answer is security, right? The new system prevents other people to deregister your service. I have not thought about the security implications when I was discussing this issue... 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 gss at ncgr.org Fri Sep 24 11:44:35 2004 From: gss at ncgr.org (Gary Schiltz) Date: Fri, 24 Sep 2004 09:44:35 -0600 Subject: [MOBY-l] MOBY Meeting: 20-21 November in Santa Fe Message-ID: <415440E3.2070000@ncgr.org> Hello MOBY'ers! The next MOBY meeting will be held at NCGR (www.ncgr.org) in Santa Fe, New Mexico, the weekend of 20-21 November, 2004. We'll finish by about 3:00 MST on Sunday, so you could catch a flight as early as about 5:30. Also, Mark Wilkinson will be giving a talk on MOBY Services at NCGR on November 19 (some time in the afternoon, I believe); everyone is welcome to attend, so consider coming a day early. I'll soon put together a page of information with an agenda, links to accommodations covering a range of prices, and other details. There will be a small registration fee to cover breakfast and lunch for Saturday and Sunday. In the interim, please post suggestions for topics to cover at the meeting. ---- Gary Schiltz Principal Software Engineer National Center for Genome Resources Santa Fe, New Mexico gss at ncgr.org 505-995-4414 (Work) 505-670-5983 (Cell) From simont at mcw.edu Fri Sep 24 13:43:41 2004 From: simont at mcw.edu (Simon Twigger) Date: Fri, 24 Sep 2004 12:43:41 -0500 Subject: [MOBY-l] Objecs for ontology annotations Message-ID: <45E77A08-0E51-11D9-91FC-000A959D1D82@mcw.edu> Hi there, As a diversion from the RDF registration debate I have a question about expanding the existing object ontology to cope with different types of ontology annotations. Our scenario is as follows: We have a variety of ontologies/controlled vocabs that we are using at RGD: GO, Mammalian Phenotype Ontology (we're working with MGD on this, see http://www.informatics.jax.org/searches/MP_form.shtml), a Disease Ontology (based around MeSH terms) and a controlled vocab for pathways. We're annotating genes/gene products and also Strains and QTLs with these terms. These are all structured much like GO, the terms have an ID, a term and a definition and they are annotated to other objects with an evidence code and a reference, however, the evidence codes are different between the various ontologies. We've been working on defining appropriate objects for MOBY services that handle these ontologies and related annotations to other objects and I wanted to see if others had addressed this same problem. Im not sure if Im thinking in an appropriately MOBY fashion and as a result getting too complicated. Im still trying to write up what we have so it makes sense to an outside observer but I thought I'd ask to see if other people had ideas or if the Powers that Be (Mark?) could sketch out very briefly how they might solve this question? Brief questions: To connect an object and an annotation, Is it better to create an annotation object that contains the Annotated Object and the Annotated Data (eg an ontology term) and has attributes that define that annotation (eg. evidence code, reference, etc); or, should we subclass the annotated object and say it hasa annotation and add in attributes defining the annotation, eg. AnnotatedGene HASA GO term, and also HASA evidence code, reference, etc? At first glance the first option would seem more flexible than the second but I might be wrong. We want to link these ontology terms to genes/gene products so I think we may need a 'Gene' object of some description. No-one will agree on what a gene is but would something lightweight like a GeneLocus object with just a symbol and name String attributes be acceptable? Thanks for any ideas people may have! Simon. -- 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