From xngvggut at webmails.com Thu Apr 1 07:58:40 2004 From: xngvggut at webmails.com (Anita Stahl) Date: Thu Apr 1 08:05:33 2004 Subject: [MOBY-dev] Fwd: Order pills online with no prescription shipped to you discreetly overnight Message-ID: From lstein at cshl.edu Thu Apr 1 16:11:57 2004 From: lstein at cshl.edu (Lincoln Stein) Date: Thu Apr 1 16:18:39 2004 Subject: [MOBY-dev] Meeting Location Message-ID: <200404011611.57893.lstein@cshl.edu> For those of you who are attending the BioMOBY developers' meeting this weekend at CSHL, the meeting will begin at 9:00 am on Saturday, April 3, in the Geery conference room in the Marks building. If you ask at the CSHL reception desk (in Grace Auditorium, you can't miss it), they will give you a map to the Marks building. I will bring in doughnuts, cofee and other unhealthy stuff for breakfast. If you'd like a more healthy breakfast, the CSHL cafeteria has very good and reasonable food, and opens at 7:30 am. Looking forward to seeing you all there! Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory 1 Bungtown Road Cold Spring Harbor, NY 11724 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://biomoby.org/pipermail/moby-dev/attachments/20040401/bea7fc42/attachment-0001.bin From rkturvvkfrlh at tvb.com.hk Fri Apr 2 21:52:05 2004 From: rkturvvkfrlh at tvb.com.hk (Jacklyn Mcginnis) Date: Fri Apr 2 21:58:16 2004 Subject: [MOBY-dev] Learn how to make BIG PROFITS with tiny little ads on the world's biggest search engine Message-ID: From letondal at pasteur.fr Wed Apr 7 04:40:26 2004 From: letondal at pasteur.fr (Catherine Letondal) Date: Wed Apr 7 04:45:22 2004 Subject: [MOBY-dev] DILS2004 Message-ID: <200404070840.i378eQh3465756@electre.pasteur.fr> Hi, This conference was 2 weeks ago, but I just wonder: is there any connection between biomoby and the topics addressed in this conference (ontologies, workflows...)? :-) Has someone from biomoby attended to this conference? (http://sun1.izbi.uni-leipzig.de/dils04/) -- Catherine Letondal -- Pasteur Institute Computing Center From simont at mcw.edu Mon Apr 19 11:25:36 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon Apr 19 11:30:28 2004 Subject: [MOBY-dev] Service Ontology developments Message-ID: Hi there, Following the MOBY meeting a few weeks back, I've started to sketch out a service ontology structure as a basis for discussions - Im sure it will get kicked around and reworked but thats the goal. I've committed some things to the moby-live repository in moby-live/Docs/ontologyDevelopment/ Given the S-MOBY direction of going to OWL and needing a decent editor and some practice with these things, I've been putting this together using Protege in OWL format. If we need to convert to something else, thats fine but its a reasonable place to start and Protege is a nice tool with the OWL plugin and the OWLviz graph add-on. If you open up the .pprj file in Protege you will be able to read the service descriptions, etc. which will help understand what I thought they all did. I went through Emboss and Pise and tried to use those tools to guide the types of classes we should have - I dont think they all will fit in what I have now but its a start. I looked at the MyGrid ontology and the reasoned version courtesy of Phil Lord and the power of being able to reason over the ontology is well worth considering and this was another reason I went with OWL (you can attach the Racer reasoning engine very easily). Their ontology is much more fully formed but that is the nature of DAML/OIL and OWL - you are trying to describe your 'knowledge space' and the hierarchical ontologies we have in MOBY right now are a very simple structure in comparison (but on the flip side, they are useable now!). Now I understand things a little more, there is much in the MyGrid ontology that we might want to use/copy/refer to. Im not yet at the point of being able to say if we should adopt it wholesale, that is a much larger issue but we all want to avoid reinventing these wheels. Key things for us to look at as I see it, bearing in mind I've only been looking at this for a few weeks: Development path - do we want to have some simple, incremental additions to our current Service Ontology so we can better classify services for MOBY-S or are we looking to make a quantum leap towards a more comprehensive ontology in OWL that is leading towards S-MOBY in the future, or more likely, both of these options? Structure of the ontology - I've be wresting with naming and how to partition services that obviously do more than one thing. Mark was going to check to see if a service could have more than one service ontology term attached to it, I think he said they could. Using OWL and reasoning would allow services to be described by their properties (input/output, what the service does, etc.) and the reasoning process would slot services into all the correct places that they belong, based on their properties - this would alleviate the problem of trying to fit a service into one service ontology category. [This would be more S-MOBY-esque, the RDF for the service could describe its properties and the discovery engine (moby-google, moogle?) could use those properties to slot it into the service ontology strucutre appropriately, no registration, etc required] I divided into bioApplicationService and infrastructureService as children of the parent ServiceClass node to try and separate bioinformatics services from other types of service that arent really bioinformatics but are essential to the system - service registration, etc. What are other's thoughts on this? I noticed I left Resolution in the wrong branch. At this point, have a look at what I have and give me your input and I'll go from there. I will also try and assemble a bibliography of all the papers I've been reading on OWL, etc., they would be useful for understanding S-MOBY too I suspect. Cheers, 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 p.lord at russet.org.uk Mon Apr 19 11:57:47 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Mon Apr 19 12:59:26 2004 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: References: Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi there, Simon> Following the MOBY meeting a few weeks back, I've started to Simon> sketch out a service ontology structure as a basis for Simon> discussions - Im sure it will get kicked around and reworked Simon> but thats the goal. I've committed some things to the Simon> moby-live repository in moby-live/Docs/ontologyDevelopment/ Simon> Given the S-MOBY direction of going to OWL and needing a Simon> decent editor and some practice with these things, I've been Simon> putting this together using Protege in OWL format. If we need Simon> to convert to something else, thats fine but its a reasonable Simon> place to start and Protege is a nice tool with the OWL plugin Simon> and the OWLviz graph add-on. If you open up the .pprj file in Simon> Protege you will be able to read the service descriptions, Simon> etc. which will help understand what I thought they all did. The OWLViz plug-in was written by people, here, at Manchester. So if you start using it please give me a shout; they would welcome the feedback. Simon> I went through Emboss and Pise and tried to use those tools Simon> to guide the types of classes we should have - If you have not already, then its worth having a look at the EMBOSS ACD type system. Simon> I dont think they all will fit in what I have now but its a Simon> start. I looked at the MyGrid ontology and the reasoned Simon> version courtesy of Phil Lord and the power of being able to Simon> reason over the ontology is well worth considering and this Simon> was another reason I went with OWL (you can attach the Racer Simon> reasoning engine very easily). Or, of course, the wonderful FaCT reasoner. http://www.cs.man.ac.uk/~horrocks/FaCT/ Hopefully there should be a new version of fact out soon, which does some things quite a bit quicker. Simon> Their ontology is much more fully formed but that is the Simon> nature of DAML/OIL and OWL - you are trying to describe your Simon> 'knowledge space' and the hierarchical ontologies we have in Simon> MOBY right now are a very simple structure in comparison (but Simon> on the flip side, they are useable now!). Now I understand Simon> things a little more, there is much in the MyGrid ontology Simon> that we might want to use/copy/refer to. Im not yet at the Simon> point of being able to say if we should adopt it wholesale, Simon> that is a much larger issue but we all want to avoid Simon> reinventing these wheels. My own feeling, which may surprise you, is that you should not adopt the ontology wholescale. Currently, I think the ontology is too big, and somewhat confusing to use. Within an end user tool, you would need to document all the concepts. And there are quite a few of them. Within mygrid our intention would not be to present the entire ontology to the end user, but chunks of it. It's not really possible to make this split in moby-s as it stands; at least not to my knowledge. Simon> Key things for us to look at as I see it, bearing in mind Simon> I've only been looking at this for a few weeks: Simon> Development path - do we want to have some simple, Simon> incremental additions to our current Service Ontology so we Simon> can better classify services for MOBY-S or are we looking to Simon> make a quantum leap towards a more comprehensive ontology in Simon> OWL that is leading towards S-MOBY in the future, or more Simon> likely, both of these options? If you want to go for OWL, in a way which enables you to reason, then you would need to think a fair bit about the ontology API which is not really up to it yet. It would also mean that you would have to tackle events like the ontology becoming inconsistent. Simon> Structure of the ontology - I've be wresting with naming and Simon> how to partition services that obviously do more than one Simon> thing. Mark was going to check to see if a service could have Simon> more than one service ontology term attached to it, I think Simon> he said they could. Using OWL and reasoning would allow Simon> services to be described by their properties (input/output, Simon> what the service does, etc.) and the reasoning process would Simon> slot services into all the correct places that they belong, Simon> based on their properties - this would alleviate the problem Simon> of trying to fit a service into one service ontology Simon> category. As it stands I think you could do this without reasoning. Essentially what you are asking for here is a multiple inheritance tree, I think. Where OWL gets very powerful is if your properties are complex, have constraints on them, or there are lots of them. Simon> [This would be more S-MOBY-esque, the RDF for the service Simon> could describe its properties and the discovery engine Simon> (moby-google, moogle?) could use those properties to slot it Simon> into the service ontology strucutre appropriately, no Simon> registration, etc required] Simon> I divided into bioApplicationService and Simon> infrastructureService as children of the parent ServiceClass Simon> node to try and separate bioinformatics services from other Simon> types of service that arent really bioinformatics but are Simon> essential to the system - service registration, etc. What are Simon> other's thoughts on this? I noticed I left Resolution in the Simon> wrong branch. Simon> At this point, have a look at what I have and give me your Simon> input and I'll go from there. I will also try and assemble a Simon> bibliography of all the papers I've been reading on OWL, Simon> etc., they would be useful for understanding S-MOBY too I Simon> suspect. I will try and comment on what you have in the next few days. Cheers Phil From simont at mcw.edu Mon Apr 19 14:55:00 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon Apr 19 14:59:41 2004 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: References: Message-ID: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> Hi Phil, Many thanks for your excellent comments. Im in agreement with you on the issue of using the MyGrid ontology, I think the hope would be that we could use branches of it or establish mappings between appropriate parts of MOBY and MyGrid ontologies so that the two systems could talk each other's language where appropriate. Definitions for the MyGrid ontology would be really nice - do they live somewhere that I can find them? I look forward to any other thoughts you have on the structure so far. Cheers, Simon. On Apr 19, 2004, at 10:57 AM, Phillip Lord wrote: > >>>>>> "Simon" == Simon Twigger writes: > > Simon> Hi there, > > Simon> Following the MOBY meeting a few weeks back, I've started to > Simon> sketch out a service ontology structure as a basis for > Simon> discussions - Im sure it will get kicked around and reworked > Simon> but thats the goal. I've committed some things to the > Simon> moby-live repository in moby-live/Docs/ontologyDevelopment/ > > > Simon> Given the S-MOBY direction of going to OWL and needing a > Simon> decent editor and some practice with these things, I've been > Simon> putting this together using Protege in OWL format. If we need > Simon> to convert to something else, thats fine but its a reasonable > Simon> place to start and Protege is a nice tool with the OWL plugin > Simon> and the OWLviz graph add-on. If you open up the .pprj file in > Simon> Protege you will be able to read the service descriptions, > Simon> etc. which will help understand what I thought they all did. > > > The OWLViz plug-in was written by people, here, at Manchester. So if > you start using it please give me a shout; they would welcome the > feedback. > > > Simon> I went through Emboss and Pise and tried to use those tools > Simon> to guide the types of classes we should have - > > If you have not already, then its worth having a look at the EMBOSS > ACD type system. > > > Simon> I dont think they all will fit in what I have now but its a > Simon> start. I looked at the MyGrid ontology and the reasoned > Simon> version courtesy of Phil Lord and the power of being able to > Simon> reason over the ontology is well worth considering and this > Simon> was another reason I went with OWL (you can attach the Racer > Simon> reasoning engine very easily). > > > > Or, of course, the wonderful FaCT reasoner. > > http://www.cs.man.ac.uk/~horrocks/FaCT/ > > > > Hopefully there should be a new version of fact out soon, which does > some things quite a bit quicker. > > > > > Simon> Their ontology is much more fully formed but that is the > Simon> nature of DAML/OIL and OWL - you are trying to describe your > Simon> 'knowledge space' and the hierarchical ontologies we have in > Simon> MOBY right now are a very simple structure in comparison (but > Simon> on the flip side, they are useable now!). Now I understand > Simon> things a little more, there is much in the MyGrid ontology > Simon> that we might want to use/copy/refer to. Im not yet at the > Simon> point of being able to say if we should adopt it wholesale, > Simon> that is a much larger issue but we all want to avoid > Simon> reinventing these wheels. > > > My own feeling, which may surprise you, is that you should not adopt > the ontology wholescale. Currently, I think the ontology is too big, > and somewhat confusing to use. Within an end user tool, you would need > to document all the concepts. And there are quite a few of them. > > Within mygrid our intention would not be to present the entire > ontology to the end user, but chunks of it. It's not really possible > to make this split in moby-s as it stands; at least not to my > knowledge. > > > Simon> Key things for us to look at as I see it, bearing in mind > Simon> I've only been looking at this for a few weeks: > > > Simon> Development path - do we want to have some simple, > Simon> incremental additions to our current Service Ontology so we > Simon> can better classify services for MOBY-S or are we looking to > Simon> make a quantum leap towards a more comprehensive ontology in > Simon> OWL that is leading towards S-MOBY in the future, or more > Simon> likely, both of these options? > > If you want to go for OWL, in a way which enables you to reason, then > you would need to think a fair bit about the ontology API which is not > really up to it yet. It would also mean that you would have to tackle > events like the ontology becoming inconsistent. > > > > > Simon> Structure of the ontology - I've be wresting with naming and > Simon> how to partition services that obviously do more than one > Simon> thing. Mark was going to check to see if a service could have > Simon> more than one service ontology term attached to it, I think > Simon> he said they could. Using OWL and reasoning would allow > Simon> services to be described by their properties (input/output, > Simon> what the service does, etc.) and the reasoning process would > Simon> slot services into all the correct places that they belong, > Simon> based on their properties - this would alleviate the problem > Simon> of trying to fit a service into one service ontology > Simon> category. > > > As it stands I think you could do this without reasoning. Essentially > what you are asking for here is a multiple inheritance tree, I > think. Where OWL gets very powerful is if your properties are > complex, have constraints on them, or there are lots of them. > > > Simon> [This would be more S-MOBY-esque, the RDF for the service > Simon> could describe its properties and the discovery engine > Simon> (moby-google, moogle?) could use those properties to slot it > Simon> into the service ontology strucutre appropriately, no > Simon> registration, etc required] > > > Simon> I divided into bioApplicationService and > Simon> infrastructureService as children of the parent ServiceClass > Simon> node to try and separate bioinformatics services from other > Simon> types of service that arent really bioinformatics but are > Simon> essential to the system - service registration, etc. What are > Simon> other's thoughts on this? I noticed I left Resolution in the > Simon> wrong branch. > > > Simon> At this point, have a look at what I have and give me your > Simon> input and I'll go from there. I will also try and assemble a > Simon> bibliography of all the papers I've been reading on OWL, > Simon> etc., they would be useful for understanding S-MOBY too I > Simon> suspect. > > > I will try and comment on what you have in the next few days. > > Cheers > > Phil > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From p.lord at russet.org.uk Tue Apr 20 05:09:00 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: Tue Apr 20 05:17:06 2004 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> References: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi Phil, Simon> Many thanks for your excellent comments. Im in agreement with Simon> you on the issue of using the MyGrid ontology, I think the Simon> hope would be that we could use branches of it or establish Simon> mappings between appropriate parts of MOBY and MyGrid Simon> ontologies so that the two systems could talk each other's Simon> language where appropriate. Definitions for the MyGrid Simon> ontology would be really nice - do they live somewhere that I Simon> can find them? DAML+OIL definitions yes; they are in the ontology. But English ones, sadly, no. Mappings are one way forward. Another way would be to use the (richer) mygrid ontology, appropriately marked up, to generate out the moby style ontology. This would also leave the mygrid ontology in a good place for s-moby to use it. Our ontology would form the basis of a "middle ontology"; describing all the core concepts of services in the domain, s-moby would make it more complicated with the concrete datatypes that they need, and moby-s would take a subset of it. Simon> I look forward to any other thoughts you have on the Simon> structure so far. Will do. Phil From mwilkinson at mrl.ubc.ca Tue Apr 20 15:48:32 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Apr 20 15:53:18 2004 Subject: [MOBY-dev] Welcome Nina! Message-ID: <1082490512.1656.77.camel@localhost.localdomain> Hi everyone, I wanted to send a quick note to introduce you to Nina - our newest MOBY developer. She will be acting as "my hands" for the foreseeable future cleaning/tightening the MOBY Central & Ontology Server core code and MOBY Cient/Server libraries, enhancing the functionality, bringing the entire MOBY-S API to fruition (finally!), and working with Martin and others to put together the Java libraries etc. She is hired as a 100% MOBY software developer, so this is great news for me/us! I'm pleased to have her working with me here at iCAPTURE! I apologize to you all for the lack of progress over the past couple of months, but having Nina around will get us back up to speed :-) Cheers all! Mark -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 14:25:58 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Apr 29 14:30:46 2004 Subject: [MOBY-dev] Update from the last developers meeting: MOBY-S API changes Message-ID: <1083263157.1632.41.camel@myhost.mydomain> Hi all, I am finally getting around to writing the update from our last developers meeting, hosted by Lincoln at CSHL. Thanks Lincoln! Well, the whisky and ideas flowed like a river :-) and as a consequence there were some important decisions made affecting the MOBY-S API: (1) The process of registering and deregistering a service will now become more of a "pull", rather than a "push"; your server will now host a simple RDF document that describes your service such that MOBY Central can GET this document on a regular basis to decide if your service is still registered and/or modified. Thus we don't need any fancy security model for deregistration, since presumably only you have access to your own server. This is quite Google-like. (2) The messaging XML format has changed slightly: (a) the moby:Query and moby:Response tags have now been merged into a single tag moby:mobyContent (b) the moby:queryInput and moby:queryResponse tags have now been merged into a single tag moby:mobyData -- these two changes now make the input message structure ~identical to the output message structure, thus we truly can pipe messages from one service to the next without fiddling with them. Change #1 has not yet been implemented, and might take a while. I'll try to make some progress on it this weekend. The idea is that you will register your service using the existing registerService API call as usual, with the inclusion of one additional parameter representing the location where you will store your service description RDF documents for MOBY Central to GET. MOBY Central will parse your registerService call and return you a registration Object as usual, however the registration Object will contain an additional parameter, representing the RDF document that describes your service as per the parameters you sent it - i.e. MOBY Central will create the RDF for you. You place the RDF in the location that you indicated in the registerService call and MOBY will troll your server every ~week to see if it is still there, and update the registry if it has changed. Change #2 will be implemented in the Perl libraries (e.g. MOBY::Client::Central and MOBY::CommonSubs), and hopefully also in the Java libraries, thus people using the libraries to create/parse the messages should not notice the change... so if you are not using the libraries, you should be! :-) I'm trying to ensure that both message structures are understood by these libraries so that we continue to have backward compatibility at least for a while. I'm going to update the API documentation on the web ASAP. I'll put the photo's from the meeting up on the web as soon as they have been edited for content... ;-) ;-) Cheers all! Mark -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 18:39:56 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Apr 29 18:44:39 2004 Subject: [MOBY-dev] CVS update required from all service providers Message-ID: <1083278395.1662.17.camel@myhost.mydomain> Hi everyone, All current service providers will need to cvs update their MOBY::CommonSubs module to bring everyone into sync with the message format changes. I just checked and all of my own services kicked back to life as soon as I updated, so as long as you are using the libraries a CVS update will fix everything and you wont have to change your services. ...I know... this was an ugly one... Sorry! :-( I hate changing the API, but we don't do this often, considering how young the project is! It's all for the best, though... or so they say ;-) Java people: If you do a simple substitution of Query -> mobyContent Response -> mobyContent queryInput -> mobyData queryResponse -> mobyData that is all that should be required to bring your code up to date with the API. M -- Mark Wilkinson (mwilkinson@mrl.ubc.ca) University of British Columbia iCAPTURE Centre From xngvggut at webmails.com Thu Apr 1 07:58:40 2004 From: xngvggut at webmails.com (Anita Stahl) Date: Thu, 01 Apr 2004 15:58:40 +0300 Subject: [MOBY-dev] Fwd: Order pills online with no prescription shipped to you discreetly overnight Message-ID: From lstein at cshl.edu Thu Apr 1 16:11:57 2004 From: lstein at cshl.edu (Lincoln Stein) Date: Thu, 01 Apr 2004 16:11:57 -0500 Subject: [MOBY-dev] Meeting Location Message-ID: <200404011611.57893.lstein@cshl.edu> For those of you who are attending the BioMOBY developers' meeting this weekend at CSHL, the meeting will begin at 9:00 am on Saturday, April 3, in the Geery conference room in the Marks building. If you ask at the CSHL reception desk (in Grace Auditorium, you can't miss it), they will give you a map to the Marks building. I will bring in doughnuts, cofee and other unhealthy stuff for breakfast. If you'd like a more healthy breakfast, the CSHL cafeteria has very good and reasonable food, and opens at 7:30 am. Looking forward to seeing you all there! Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory 1 Bungtown Road Cold Spring Harbor, NY 11724 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://www.biomoby.org/pipermail/moby-dev/attachments/20040401/bea7fc42/attachment-0002.bin From rkturvvkfrlh at tvb.com.hk Fri Apr 2 21:52:05 2004 From: rkturvvkfrlh at tvb.com.hk (Jacklyn Mcginnis) Date: Fri, 02 Apr 2004 22:52:05 -0400 Subject: [MOBY-dev] Learn how to make BIG PROFITS with tiny little ads on the world's biggest search engine Message-ID: From letondal at pasteur.fr Wed Apr 7 04:40:26 2004 From: letondal at pasteur.fr (Catherine Letondal) Date: Wed, 07 Apr 2004 10:40:26 +0200 Subject: [MOBY-dev] DILS2004 Message-ID: <200404070840.i378eQh3465756@electre.pasteur.fr> Hi, This conference was 2 weeks ago, but I just wonder: is there any connection between biomoby and the topics addressed in this conference (ontologies, workflows...)? :-) Has someone from biomoby attended to this conference? (http://sun1.izbi.uni-leipzig.de/dils04/) -- Catherine Letondal -- Pasteur Institute Computing Center From simont at mcw.edu Mon Apr 19 11:25:36 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon, 19 Apr 2004 10:25:36 -0500 Subject: [MOBY-dev] Service Ontology developments Message-ID: Hi there, Following the MOBY meeting a few weeks back, I've started to sketch out a service ontology structure as a basis for discussions - Im sure it will get kicked around and reworked but thats the goal. I've committed some things to the moby-live repository in moby-live/Docs/ontologyDevelopment/ Given the S-MOBY direction of going to OWL and needing a decent editor and some practice with these things, I've been putting this together using Protege in OWL format. If we need to convert to something else, thats fine but its a reasonable place to start and Protege is a nice tool with the OWL plugin and the OWLviz graph add-on. If you open up the .pprj file in Protege you will be able to read the service descriptions, etc. which will help understand what I thought they all did. I went through Emboss and Pise and tried to use those tools to guide the types of classes we should have - I dont think they all will fit in what I have now but its a start. I looked at the MyGrid ontology and the reasoned version courtesy of Phil Lord and the power of being able to reason over the ontology is well worth considering and this was another reason I went with OWL (you can attach the Racer reasoning engine very easily). Their ontology is much more fully formed but that is the nature of DAML/OIL and OWL - you are trying to describe your 'knowledge space' and the hierarchical ontologies we have in MOBY right now are a very simple structure in comparison (but on the flip side, they are useable now!). Now I understand things a little more, there is much in the MyGrid ontology that we might want to use/copy/refer to. Im not yet at the point of being able to say if we should adopt it wholesale, that is a much larger issue but we all want to avoid reinventing these wheels. Key things for us to look at as I see it, bearing in mind I've only been looking at this for a few weeks: Development path - do we want to have some simple, incremental additions to our current Service Ontology so we can better classify services for MOBY-S or are we looking to make a quantum leap towards a more comprehensive ontology in OWL that is leading towards S-MOBY in the future, or more likely, both of these options? Structure of the ontology - I've be wresting with naming and how to partition services that obviously do more than one thing. Mark was going to check to see if a service could have more than one service ontology term attached to it, I think he said they could. Using OWL and reasoning would allow services to be described by their properties (input/output, what the service does, etc.) and the reasoning process would slot services into all the correct places that they belong, based on their properties - this would alleviate the problem of trying to fit a service into one service ontology category. [This would be more S-MOBY-esque, the RDF for the service could describe its properties and the discovery engine (moby-google, moogle?) could use those properties to slot it into the service ontology strucutre appropriately, no registration, etc required] I divided into bioApplicationService and infrastructureService as children of the parent ServiceClass node to try and separate bioinformatics services from other types of service that arent really bioinformatics but are essential to the system - service registration, etc. What are other's thoughts on this? I noticed I left Resolution in the wrong branch. At this point, have a look at what I have and give me your input and I'll go from there. I will also try and assemble a bibliography of all the papers I've been reading on OWL, etc., they would be useful for understanding S-MOBY too I suspect. Cheers, 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 p.lord at russet.org.uk Mon Apr 19 11:57:47 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 19 Apr 2004 16:57:47 +0100 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: References: Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi there, Simon> Following the MOBY meeting a few weeks back, I've started to Simon> sketch out a service ontology structure as a basis for Simon> discussions - Im sure it will get kicked around and reworked Simon> but thats the goal. I've committed some things to the Simon> moby-live repository in moby-live/Docs/ontologyDevelopment/ Simon> Given the S-MOBY direction of going to OWL and needing a Simon> decent editor and some practice with these things, I've been Simon> putting this together using Protege in OWL format. If we need Simon> to convert to something else, thats fine but its a reasonable Simon> place to start and Protege is a nice tool with the OWL plugin Simon> and the OWLviz graph add-on. If you open up the .pprj file in Simon> Protege you will be able to read the service descriptions, Simon> etc. which will help understand what I thought they all did. The OWLViz plug-in was written by people, here, at Manchester. So if you start using it please give me a shout; they would welcome the feedback. Simon> I went through Emboss and Pise and tried to use those tools Simon> to guide the types of classes we should have - If you have not already, then its worth having a look at the EMBOSS ACD type system. Simon> I dont think they all will fit in what I have now but its a Simon> start. I looked at the MyGrid ontology and the reasoned Simon> version courtesy of Phil Lord and the power of being able to Simon> reason over the ontology is well worth considering and this Simon> was another reason I went with OWL (you can attach the Racer Simon> reasoning engine very easily). Or, of course, the wonderful FaCT reasoner. http://www.cs.man.ac.uk/~horrocks/FaCT/ Hopefully there should be a new version of fact out soon, which does some things quite a bit quicker. Simon> Their ontology is much more fully formed but that is the Simon> nature of DAML/OIL and OWL - you are trying to describe your Simon> 'knowledge space' and the hierarchical ontologies we have in Simon> MOBY right now are a very simple structure in comparison (but Simon> on the flip side, they are useable now!). Now I understand Simon> things a little more, there is much in the MyGrid ontology Simon> that we might want to use/copy/refer to. Im not yet at the Simon> point of being able to say if we should adopt it wholesale, Simon> that is a much larger issue but we all want to avoid Simon> reinventing these wheels. My own feeling, which may surprise you, is that you should not adopt the ontology wholescale. Currently, I think the ontology is too big, and somewhat confusing to use. Within an end user tool, you would need to document all the concepts. And there are quite a few of them. Within mygrid our intention would not be to present the entire ontology to the end user, but chunks of it. It's not really possible to make this split in moby-s as it stands; at least not to my knowledge. Simon> Key things for us to look at as I see it, bearing in mind Simon> I've only been looking at this for a few weeks: Simon> Development path - do we want to have some simple, Simon> incremental additions to our current Service Ontology so we Simon> can better classify services for MOBY-S or are we looking to Simon> make a quantum leap towards a more comprehensive ontology in Simon> OWL that is leading towards S-MOBY in the future, or more Simon> likely, both of these options? If you want to go for OWL, in a way which enables you to reason, then you would need to think a fair bit about the ontology API which is not really up to it yet. It would also mean that you would have to tackle events like the ontology becoming inconsistent. Simon> Structure of the ontology - I've be wresting with naming and Simon> how to partition services that obviously do more than one Simon> thing. Mark was going to check to see if a service could have Simon> more than one service ontology term attached to it, I think Simon> he said they could. Using OWL and reasoning would allow Simon> services to be described by their properties (input/output, Simon> what the service does, etc.) and the reasoning process would Simon> slot services into all the correct places that they belong, Simon> based on their properties - this would alleviate the problem Simon> of trying to fit a service into one service ontology Simon> category. As it stands I think you could do this without reasoning. Essentially what you are asking for here is a multiple inheritance tree, I think. Where OWL gets very powerful is if your properties are complex, have constraints on them, or there are lots of them. Simon> [This would be more S-MOBY-esque, the RDF for the service Simon> could describe its properties and the discovery engine Simon> (moby-google, moogle?) could use those properties to slot it Simon> into the service ontology strucutre appropriately, no Simon> registration, etc required] Simon> I divided into bioApplicationService and Simon> infrastructureService as children of the parent ServiceClass Simon> node to try and separate bioinformatics services from other Simon> types of service that arent really bioinformatics but are Simon> essential to the system - service registration, etc. What are Simon> other's thoughts on this? I noticed I left Resolution in the Simon> wrong branch. Simon> At this point, have a look at what I have and give me your Simon> input and I'll go from there. I will also try and assemble a Simon> bibliography of all the papers I've been reading on OWL, Simon> etc., they would be useful for understanding S-MOBY too I Simon> suspect. I will try and comment on what you have in the next few days. Cheers Phil From simont at mcw.edu Mon Apr 19 14:55:00 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon, 19 Apr 2004 13:55:00 -0500 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: References: Message-ID: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> Hi Phil, Many thanks for your excellent comments. Im in agreement with you on the issue of using the MyGrid ontology, I think the hope would be that we could use branches of it or establish mappings between appropriate parts of MOBY and MyGrid ontologies so that the two systems could talk each other's language where appropriate. Definitions for the MyGrid ontology would be really nice - do they live somewhere that I can find them? I look forward to any other thoughts you have on the structure so far. Cheers, Simon. On Apr 19, 2004, at 10:57 AM, Phillip Lord wrote: > >>>>>> "Simon" == Simon Twigger writes: > > Simon> Hi there, > > Simon> Following the MOBY meeting a few weeks back, I've started to > Simon> sketch out a service ontology structure as a basis for > Simon> discussions - Im sure it will get kicked around and reworked > Simon> but thats the goal. I've committed some things to the > Simon> moby-live repository in moby-live/Docs/ontologyDevelopment/ > > > Simon> Given the S-MOBY direction of going to OWL and needing a > Simon> decent editor and some practice with these things, I've been > Simon> putting this together using Protege in OWL format. If we need > Simon> to convert to something else, thats fine but its a reasonable > Simon> place to start and Protege is a nice tool with the OWL plugin > Simon> and the OWLviz graph add-on. If you open up the .pprj file in > Simon> Protege you will be able to read the service descriptions, > Simon> etc. which will help understand what I thought they all did. > > > The OWLViz plug-in was written by people, here, at Manchester. So if > you start using it please give me a shout; they would welcome the > feedback. > > > Simon> I went through Emboss and Pise and tried to use those tools > Simon> to guide the types of classes we should have - > > If you have not already, then its worth having a look at the EMBOSS > ACD type system. > > > Simon> I dont think they all will fit in what I have now but its a > Simon> start. I looked at the MyGrid ontology and the reasoned > Simon> version courtesy of Phil Lord and the power of being able to > Simon> reason over the ontology is well worth considering and this > Simon> was another reason I went with OWL (you can attach the Racer > Simon> reasoning engine very easily). > > > > Or, of course, the wonderful FaCT reasoner. > > http://www.cs.man.ac.uk/~horrocks/FaCT/ > > > > Hopefully there should be a new version of fact out soon, which does > some things quite a bit quicker. > > > > > Simon> Their ontology is much more fully formed but that is the > Simon> nature of DAML/OIL and OWL - you are trying to describe your > Simon> 'knowledge space' and the hierarchical ontologies we have in > Simon> MOBY right now are a very simple structure in comparison (but > Simon> on the flip side, they are useable now!). Now I understand > Simon> things a little more, there is much in the MyGrid ontology > Simon> that we might want to use/copy/refer to. Im not yet at the > Simon> point of being able to say if we should adopt it wholesale, > Simon> that is a much larger issue but we all want to avoid > Simon> reinventing these wheels. > > > My own feeling, which may surprise you, is that you should not adopt > the ontology wholescale. Currently, I think the ontology is too big, > and somewhat confusing to use. Within an end user tool, you would need > to document all the concepts. And there are quite a few of them. > > Within mygrid our intention would not be to present the entire > ontology to the end user, but chunks of it. It's not really possible > to make this split in moby-s as it stands; at least not to my > knowledge. > > > Simon> Key things for us to look at as I see it, bearing in mind > Simon> I've only been looking at this for a few weeks: > > > Simon> Development path - do we want to have some simple, > Simon> incremental additions to our current Service Ontology so we > Simon> can better classify services for MOBY-S or are we looking to > Simon> make a quantum leap towards a more comprehensive ontology in > Simon> OWL that is leading towards S-MOBY in the future, or more > Simon> likely, both of these options? > > If you want to go for OWL, in a way which enables you to reason, then > you would need to think a fair bit about the ontology API which is not > really up to it yet. It would also mean that you would have to tackle > events like the ontology becoming inconsistent. > > > > > Simon> Structure of the ontology - I've be wresting with naming and > Simon> how to partition services that obviously do more than one > Simon> thing. Mark was going to check to see if a service could have > Simon> more than one service ontology term attached to it, I think > Simon> he said they could. Using OWL and reasoning would allow > Simon> services to be described by their properties (input/output, > Simon> what the service does, etc.) and the reasoning process would > Simon> slot services into all the correct places that they belong, > Simon> based on their properties - this would alleviate the problem > Simon> of trying to fit a service into one service ontology > Simon> category. > > > As it stands I think you could do this without reasoning. Essentially > what you are asking for here is a multiple inheritance tree, I > think. Where OWL gets very powerful is if your properties are > complex, have constraints on them, or there are lots of them. > > > Simon> [This would be more S-MOBY-esque, the RDF for the service > Simon> could describe its properties and the discovery engine > Simon> (moby-google, moogle?) could use those properties to slot it > Simon> into the service ontology strucutre appropriately, no > Simon> registration, etc required] > > > Simon> I divided into bioApplicationService and > Simon> infrastructureService as children of the parent ServiceClass > Simon> node to try and separate bioinformatics services from other > Simon> types of service that arent really bioinformatics but are > Simon> essential to the system - service registration, etc. What are > Simon> other's thoughts on this? I noticed I left Resolution in the > Simon> wrong branch. > > > Simon> At this point, have a look at what I have and give me your > Simon> input and I'll go from there. I will also try and assemble a > Simon> bibliography of all the papers I've been reading on OWL, > Simon> etc., they would be useful for understanding S-MOBY too I > Simon> suspect. > > > I will try and comment on what you have in the next few days. > > Cheers > > Phil > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From p.lord at russet.org.uk Tue Apr 20 05:09:00 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 20 Apr 2004 10:09:00 +0100 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> References: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi Phil, Simon> Many thanks for your excellent comments. Im in agreement with Simon> you on the issue of using the MyGrid ontology, I think the Simon> hope would be that we could use branches of it or establish Simon> mappings between appropriate parts of MOBY and MyGrid Simon> ontologies so that the two systems could talk each other's Simon> language where appropriate. Definitions for the MyGrid Simon> ontology would be really nice - do they live somewhere that I Simon> can find them? DAML+OIL definitions yes; they are in the ontology. But English ones, sadly, no. Mappings are one way forward. Another way would be to use the (richer) mygrid ontology, appropriately marked up, to generate out the moby style ontology. This would also leave the mygrid ontology in a good place for s-moby to use it. Our ontology would form the basis of a "middle ontology"; describing all the core concepts of services in the domain, s-moby would make it more complicated with the concrete datatypes that they need, and moby-s would take a subset of it. Simon> I look forward to any other thoughts you have on the Simon> structure so far. Will do. Phil From mwilkinson at mrl.ubc.ca Tue Apr 20 15:48:32 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 20 Apr 2004 12:48:32 -0700 Subject: [MOBY-dev] Welcome Nina! Message-ID: <1082490512.1656.77.camel@localhost.localdomain> Hi everyone, I wanted to send a quick note to introduce you to Nina - our newest MOBY developer. She will be acting as "my hands" for the foreseeable future cleaning/tightening the MOBY Central & Ontology Server core code and MOBY Cient/Server libraries, enhancing the functionality, bringing the entire MOBY-S API to fruition (finally!), and working with Martin and others to put together the Java libraries etc. She is hired as a 100% MOBY software developer, so this is great news for me/us! I'm pleased to have her working with me here at iCAPTURE! I apologize to you all for the lack of progress over the past couple of months, but having Nina around will get us back up to speed :-) Cheers all! Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 14:25:58 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 29 Apr 2004 11:25:58 -0700 Subject: [MOBY-dev] Update from the last developers meeting: MOBY-S API changes Message-ID: <1083263157.1632.41.camel@myhost.mydomain> Hi all, I am finally getting around to writing the update from our last developers meeting, hosted by Lincoln at CSHL. Thanks Lincoln! Well, the whisky and ideas flowed like a river :-) and as a consequence there were some important decisions made affecting the MOBY-S API: (1) The process of registering and deregistering a service will now become more of a "pull", rather than a "push"; your server will now host a simple RDF document that describes your service such that MOBY Central can GET this document on a regular basis to decide if your service is still registered and/or modified. Thus we don't need any fancy security model for deregistration, since presumably only you have access to your own server. This is quite Google-like. (2) The messaging XML format has changed slightly: (a) the moby:Query and moby:Response tags have now been merged into a single tag moby:mobyContent (b) the moby:queryInput and moby:queryResponse tags have now been merged into a single tag moby:mobyData -- these two changes now make the input message structure ~identical to the output message structure, thus we truly can pipe messages from one service to the next without fiddling with them. Change #1 has not yet been implemented, and might take a while. I'll try to make some progress on it this weekend. The idea is that you will register your service using the existing registerService API call as usual, with the inclusion of one additional parameter representing the location where you will store your service description RDF documents for MOBY Central to GET. MOBY Central will parse your registerService call and return you a registration Object as usual, however the registration Object will contain an additional parameter, representing the RDF document that describes your service as per the parameters you sent it - i.e. MOBY Central will create the RDF for you. You place the RDF in the location that you indicated in the registerService call and MOBY will troll your server every ~week to see if it is still there, and update the registry if it has changed. Change #2 will be implemented in the Perl libraries (e.g. MOBY::Client::Central and MOBY::CommonSubs), and hopefully also in the Java libraries, thus people using the libraries to create/parse the messages should not notice the change... so if you are not using the libraries, you should be! :-) I'm trying to ensure that both message structures are understood by these libraries so that we continue to have backward compatibility at least for a while. I'm going to update the API documentation on the web ASAP. I'll put the photo's from the meeting up on the web as soon as they have been edited for content... ;-) ;-) Cheers all! Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 18:39:56 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 29 Apr 2004 15:39:56 -0700 Subject: [MOBY-dev] CVS update required from all service providers Message-ID: <1083278395.1662.17.camel@myhost.mydomain> Hi everyone, All current service providers will need to cvs update their MOBY::CommonSubs module to bring everyone into sync with the message format changes. I just checked and all of my own services kicked back to life as soon as I updated, so as long as you are using the libraries a CVS update will fix everything and you wont have to change your services. ...I know... this was an ugly one... Sorry! :-( I hate changing the API, but we don't do this often, considering how young the project is! It's all for the best, though... or so they say ;-) Java people: If you do a simple substitution of Query -> mobyContent Response -> mobyContent queryInput -> mobyData queryResponse -> mobyData that is all that should be required to bring your code up to date with the API. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From xngvggut at webmails.com Thu Apr 1 12:58:40 2004 From: xngvggut at webmails.com (Anita Stahl) Date: Thu, 01 Apr 2004 15:58:40 +0300 Subject: [MOBY-dev] Fwd: Order pills online with no prescription shipped to you discreetly overnight Message-ID: From lstein at cshl.edu Thu Apr 1 21:11:57 2004 From: lstein at cshl.edu (Lincoln Stein) Date: Thu, 01 Apr 2004 16:11:57 -0500 Subject: [MOBY-dev] Meeting Location Message-ID: <200404011611.57893.lstein@cshl.edu> For those of you who are attending the BioMOBY developers' meeting this weekend at CSHL, the meeting will begin at 9:00 am on Saturday, April 3, in the Geery conference room in the Marks building. If you ask at the CSHL reception desk (in Grace Auditorium, you can't miss it), they will give you a map to the Marks building. I will bring in doughnuts, cofee and other unhealthy stuff for breakfast. If you'd like a more healthy breakfast, the CSHL cafeteria has very good and reasonable food, and opens at 7:30 am. Looking forward to seeing you all there! Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory 1 Bungtown Road Cold Spring Harbor, NY 11724 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rkturvvkfrlh at tvb.com.hk Sat Apr 3 02:52:05 2004 From: rkturvvkfrlh at tvb.com.hk (Jacklyn Mcginnis) Date: Fri, 02 Apr 2004 22:52:05 -0400 Subject: [MOBY-dev] Learn how to make BIG PROFITS with tiny little ads on the world's biggest search engine Message-ID: From letondal at pasteur.fr Wed Apr 7 08:40:26 2004 From: letondal at pasteur.fr (Catherine Letondal) Date: Wed, 07 Apr 2004 10:40:26 +0200 Subject: [MOBY-dev] DILS2004 Message-ID: <200404070840.i378eQh3465756@electre.pasteur.fr> Hi, This conference was 2 weeks ago, but I just wonder: is there any connection between biomoby and the topics addressed in this conference (ontologies, workflows...)? :-) Has someone from biomoby attended to this conference? (http://sun1.izbi.uni-leipzig.de/dils04/) -- Catherine Letondal -- Pasteur Institute Computing Center From simont at mcw.edu Mon Apr 19 15:25:36 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon, 19 Apr 2004 10:25:36 -0500 Subject: [MOBY-dev] Service Ontology developments Message-ID: Hi there, Following the MOBY meeting a few weeks back, I've started to sketch out a service ontology structure as a basis for discussions - Im sure it will get kicked around and reworked but thats the goal. I've committed some things to the moby-live repository in moby-live/Docs/ontologyDevelopment/ Given the S-MOBY direction of going to OWL and needing a decent editor and some practice with these things, I've been putting this together using Protege in OWL format. If we need to convert to something else, thats fine but its a reasonable place to start and Protege is a nice tool with the OWL plugin and the OWLviz graph add-on. If you open up the .pprj file in Protege you will be able to read the service descriptions, etc. which will help understand what I thought they all did. I went through Emboss and Pise and tried to use those tools to guide the types of classes we should have - I dont think they all will fit in what I have now but its a start. I looked at the MyGrid ontology and the reasoned version courtesy of Phil Lord and the power of being able to reason over the ontology is well worth considering and this was another reason I went with OWL (you can attach the Racer reasoning engine very easily). Their ontology is much more fully formed but that is the nature of DAML/OIL and OWL - you are trying to describe your 'knowledge space' and the hierarchical ontologies we have in MOBY right now are a very simple structure in comparison (but on the flip side, they are useable now!). Now I understand things a little more, there is much in the MyGrid ontology that we might want to use/copy/refer to. Im not yet at the point of being able to say if we should adopt it wholesale, that is a much larger issue but we all want to avoid reinventing these wheels. Key things for us to look at as I see it, bearing in mind I've only been looking at this for a few weeks: Development path - do we want to have some simple, incremental additions to our current Service Ontology so we can better classify services for MOBY-S or are we looking to make a quantum leap towards a more comprehensive ontology in OWL that is leading towards S-MOBY in the future, or more likely, both of these options? Structure of the ontology - I've be wresting with naming and how to partition services that obviously do more than one thing. Mark was going to check to see if a service could have more than one service ontology term attached to it, I think he said they could. Using OWL and reasoning would allow services to be described by their properties (input/output, what the service does, etc.) and the reasoning process would slot services into all the correct places that they belong, based on their properties - this would alleviate the problem of trying to fit a service into one service ontology category. [This would be more S-MOBY-esque, the RDF for the service could describe its properties and the discovery engine (moby-google, moogle?) could use those properties to slot it into the service ontology strucutre appropriately, no registration, etc required] I divided into bioApplicationService and infrastructureService as children of the parent ServiceClass node to try and separate bioinformatics services from other types of service that arent really bioinformatics but are essential to the system - service registration, etc. What are other's thoughts on this? I noticed I left Resolution in the wrong branch. At this point, have a look at what I have and give me your input and I'll go from there. I will also try and assemble a bibliography of all the papers I've been reading on OWL, etc., they would be useful for understanding S-MOBY too I suspect. Cheers, 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 p.lord at russet.org.uk Mon Apr 19 15:57:47 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 19 Apr 2004 16:57:47 +0100 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: References: Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi there, Simon> Following the MOBY meeting a few weeks back, I've started to Simon> sketch out a service ontology structure as a basis for Simon> discussions - Im sure it will get kicked around and reworked Simon> but thats the goal. I've committed some things to the Simon> moby-live repository in moby-live/Docs/ontologyDevelopment/ Simon> Given the S-MOBY direction of going to OWL and needing a Simon> decent editor and some practice with these things, I've been Simon> putting this together using Protege in OWL format. If we need Simon> to convert to something else, thats fine but its a reasonable Simon> place to start and Protege is a nice tool with the OWL plugin Simon> and the OWLviz graph add-on. If you open up the .pprj file in Simon> Protege you will be able to read the service descriptions, Simon> etc. which will help understand what I thought they all did. The OWLViz plug-in was written by people, here, at Manchester. So if you start using it please give me a shout; they would welcome the feedback. Simon> I went through Emboss and Pise and tried to use those tools Simon> to guide the types of classes we should have - If you have not already, then its worth having a look at the EMBOSS ACD type system. Simon> I dont think they all will fit in what I have now but its a Simon> start. I looked at the MyGrid ontology and the reasoned Simon> version courtesy of Phil Lord and the power of being able to Simon> reason over the ontology is well worth considering and this Simon> was another reason I went with OWL (you can attach the Racer Simon> reasoning engine very easily). Or, of course, the wonderful FaCT reasoner. http://www.cs.man.ac.uk/~horrocks/FaCT/ Hopefully there should be a new version of fact out soon, which does some things quite a bit quicker. Simon> Their ontology is much more fully formed but that is the Simon> nature of DAML/OIL and OWL - you are trying to describe your Simon> 'knowledge space' and the hierarchical ontologies we have in Simon> MOBY right now are a very simple structure in comparison (but Simon> on the flip side, they are useable now!). Now I understand Simon> things a little more, there is much in the MyGrid ontology Simon> that we might want to use/copy/refer to. Im not yet at the Simon> point of being able to say if we should adopt it wholesale, Simon> that is a much larger issue but we all want to avoid Simon> reinventing these wheels. My own feeling, which may surprise you, is that you should not adopt the ontology wholescale. Currently, I think the ontology is too big, and somewhat confusing to use. Within an end user tool, you would need to document all the concepts. And there are quite a few of them. Within mygrid our intention would not be to present the entire ontology to the end user, but chunks of it. It's not really possible to make this split in moby-s as it stands; at least not to my knowledge. Simon> Key things for us to look at as I see it, bearing in mind Simon> I've only been looking at this for a few weeks: Simon> Development path - do we want to have some simple, Simon> incremental additions to our current Service Ontology so we Simon> can better classify services for MOBY-S or are we looking to Simon> make a quantum leap towards a more comprehensive ontology in Simon> OWL that is leading towards S-MOBY in the future, or more Simon> likely, both of these options? If you want to go for OWL, in a way which enables you to reason, then you would need to think a fair bit about the ontology API which is not really up to it yet. It would also mean that you would have to tackle events like the ontology becoming inconsistent. Simon> Structure of the ontology - I've be wresting with naming and Simon> how to partition services that obviously do more than one Simon> thing. Mark was going to check to see if a service could have Simon> more than one service ontology term attached to it, I think Simon> he said they could. Using OWL and reasoning would allow Simon> services to be described by their properties (input/output, Simon> what the service does, etc.) and the reasoning process would Simon> slot services into all the correct places that they belong, Simon> based on their properties - this would alleviate the problem Simon> of trying to fit a service into one service ontology Simon> category. As it stands I think you could do this without reasoning. Essentially what you are asking for here is a multiple inheritance tree, I think. Where OWL gets very powerful is if your properties are complex, have constraints on them, or there are lots of them. Simon> [This would be more S-MOBY-esque, the RDF for the service Simon> could describe its properties and the discovery engine Simon> (moby-google, moogle?) could use those properties to slot it Simon> into the service ontology strucutre appropriately, no Simon> registration, etc required] Simon> I divided into bioApplicationService and Simon> infrastructureService as children of the parent ServiceClass Simon> node to try and separate bioinformatics services from other Simon> types of service that arent really bioinformatics but are Simon> essential to the system - service registration, etc. What are Simon> other's thoughts on this? I noticed I left Resolution in the Simon> wrong branch. Simon> At this point, have a look at what I have and give me your Simon> input and I'll go from there. I will also try and assemble a Simon> bibliography of all the papers I've been reading on OWL, Simon> etc., they would be useful for understanding S-MOBY too I Simon> suspect. I will try and comment on what you have in the next few days. Cheers Phil From simont at mcw.edu Mon Apr 19 18:55:00 2004 From: simont at mcw.edu (Simon Twigger) Date: Mon, 19 Apr 2004 13:55:00 -0500 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: References: Message-ID: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> Hi Phil, Many thanks for your excellent comments. Im in agreement with you on the issue of using the MyGrid ontology, I think the hope would be that we could use branches of it or establish mappings between appropriate parts of MOBY and MyGrid ontologies so that the two systems could talk each other's language where appropriate. Definitions for the MyGrid ontology would be really nice - do they live somewhere that I can find them? I look forward to any other thoughts you have on the structure so far. Cheers, Simon. On Apr 19, 2004, at 10:57 AM, Phillip Lord wrote: > >>>>>> "Simon" == Simon Twigger writes: > > Simon> Hi there, > > Simon> Following the MOBY meeting a few weeks back, I've started to > Simon> sketch out a service ontology structure as a basis for > Simon> discussions - Im sure it will get kicked around and reworked > Simon> but thats the goal. I've committed some things to the > Simon> moby-live repository in moby-live/Docs/ontologyDevelopment/ > > > Simon> Given the S-MOBY direction of going to OWL and needing a > Simon> decent editor and some practice with these things, I've been > Simon> putting this together using Protege in OWL format. If we need > Simon> to convert to something else, thats fine but its a reasonable > Simon> place to start and Protege is a nice tool with the OWL plugin > Simon> and the OWLviz graph add-on. If you open up the .pprj file in > Simon> Protege you will be able to read the service descriptions, > Simon> etc. which will help understand what I thought they all did. > > > The OWLViz plug-in was written by people, here, at Manchester. So if > you start using it please give me a shout; they would welcome the > feedback. > > > Simon> I went through Emboss and Pise and tried to use those tools > Simon> to guide the types of classes we should have - > > If you have not already, then its worth having a look at the EMBOSS > ACD type system. > > > Simon> I dont think they all will fit in what I have now but its a > Simon> start. I looked at the MyGrid ontology and the reasoned > Simon> version courtesy of Phil Lord and the power of being able to > Simon> reason over the ontology is well worth considering and this > Simon> was another reason I went with OWL (you can attach the Racer > Simon> reasoning engine very easily). > > > > Or, of course, the wonderful FaCT reasoner. > > http://www.cs.man.ac.uk/~horrocks/FaCT/ > > > > Hopefully there should be a new version of fact out soon, which does > some things quite a bit quicker. > > > > > Simon> Their ontology is much more fully formed but that is the > Simon> nature of DAML/OIL and OWL - you are trying to describe your > Simon> 'knowledge space' and the hierarchical ontologies we have in > Simon> MOBY right now are a very simple structure in comparison (but > Simon> on the flip side, they are useable now!). Now I understand > Simon> things a little more, there is much in the MyGrid ontology > Simon> that we might want to use/copy/refer to. Im not yet at the > Simon> point of being able to say if we should adopt it wholesale, > Simon> that is a much larger issue but we all want to avoid > Simon> reinventing these wheels. > > > My own feeling, which may surprise you, is that you should not adopt > the ontology wholescale. Currently, I think the ontology is too big, > and somewhat confusing to use. Within an end user tool, you would need > to document all the concepts. And there are quite a few of them. > > Within mygrid our intention would not be to present the entire > ontology to the end user, but chunks of it. It's not really possible > to make this split in moby-s as it stands; at least not to my > knowledge. > > > Simon> Key things for us to look at as I see it, bearing in mind > Simon> I've only been looking at this for a few weeks: > > > Simon> Development path - do we want to have some simple, > Simon> incremental additions to our current Service Ontology so we > Simon> can better classify services for MOBY-S or are we looking to > Simon> make a quantum leap towards a more comprehensive ontology in > Simon> OWL that is leading towards S-MOBY in the future, or more > Simon> likely, both of these options? > > If you want to go for OWL, in a way which enables you to reason, then > you would need to think a fair bit about the ontology API which is not > really up to it yet. It would also mean that you would have to tackle > events like the ontology becoming inconsistent. > > > > > Simon> Structure of the ontology - I've be wresting with naming and > Simon> how to partition services that obviously do more than one > Simon> thing. Mark was going to check to see if a service could have > Simon> more than one service ontology term attached to it, I think > Simon> he said they could. Using OWL and reasoning would allow > Simon> services to be described by their properties (input/output, > Simon> what the service does, etc.) and the reasoning process would > Simon> slot services into all the correct places that they belong, > Simon> based on their properties - this would alleviate the problem > Simon> of trying to fit a service into one service ontology > Simon> category. > > > As it stands I think you could do this without reasoning. Essentially > what you are asking for here is a multiple inheritance tree, I > think. Where OWL gets very powerful is if your properties are > complex, have constraints on them, or there are lots of them. > > > Simon> [This would be more S-MOBY-esque, the RDF for the service > Simon> could describe its properties and the discovery engine > Simon> (moby-google, moogle?) could use those properties to slot it > Simon> into the service ontology strucutre appropriately, no > Simon> registration, etc required] > > > Simon> I divided into bioApplicationService and > Simon> infrastructureService as children of the parent ServiceClass > Simon> node to try and separate bioinformatics services from other > Simon> types of service that arent really bioinformatics but are > Simon> essential to the system - service registration, etc. What are > Simon> other's thoughts on this? I noticed I left Resolution in the > Simon> wrong branch. > > > Simon> At this point, have a look at what I have and give me your > Simon> input and I'll go from there. I will also try and assemble a > Simon> bibliography of all the papers I've been reading on OWL, > Simon> etc., they would be useful for understanding S-MOBY too I > Simon> suspect. > > > I will try and comment on what you have in the next few days. > > Cheers > > Phil > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Simon N. Twigger, Ph.D. Assistant Professor, Department of Physiology Medical College of Wisconsin 8701 Watertown Plank Road, Milwaukee, WI, USA tel: 414-456-8802 fax: 414-456-6595 AIM/iChat: simontatmcw From p.lord at russet.org.uk Tue Apr 20 09:09:00 2004 From: p.lord at russet.org.uk (Phillip Lord) Date: 20 Apr 2004 10:09:00 +0100 Subject: [MOBY-dev] Re: Service Ontology developments In-Reply-To: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> References: <0F3F1170-9233-11D8-8783-000A959D1D82@mcw.edu> Message-ID: >>>>> "Simon" == Simon Twigger writes: Simon> Hi Phil, Simon> Many thanks for your excellent comments. Im in agreement with Simon> you on the issue of using the MyGrid ontology, I think the Simon> hope would be that we could use branches of it or establish Simon> mappings between appropriate parts of MOBY and MyGrid Simon> ontologies so that the two systems could talk each other's Simon> language where appropriate. Definitions for the MyGrid Simon> ontology would be really nice - do they live somewhere that I Simon> can find them? DAML+OIL definitions yes; they are in the ontology. But English ones, sadly, no. Mappings are one way forward. Another way would be to use the (richer) mygrid ontology, appropriately marked up, to generate out the moby style ontology. This would also leave the mygrid ontology in a good place for s-moby to use it. Our ontology would form the basis of a "middle ontology"; describing all the core concepts of services in the domain, s-moby would make it more complicated with the concrete datatypes that they need, and moby-s would take a subset of it. Simon> I look forward to any other thoughts you have on the Simon> structure so far. Will do. Phil From mwilkinson at mrl.ubc.ca Tue Apr 20 19:48:32 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 20 Apr 2004 12:48:32 -0700 Subject: [MOBY-dev] Welcome Nina! Message-ID: <1082490512.1656.77.camel@localhost.localdomain> Hi everyone, I wanted to send a quick note to introduce you to Nina - our newest MOBY developer. She will be acting as "my hands" for the foreseeable future cleaning/tightening the MOBY Central & Ontology Server core code and MOBY Cient/Server libraries, enhancing the functionality, bringing the entire MOBY-S API to fruition (finally!), and working with Martin and others to put together the Java libraries etc. She is hired as a 100% MOBY software developer, so this is great news for me/us! I'm pleased to have her working with me here at iCAPTURE! I apologize to you all for the lack of progress over the past couple of months, but having Nina around will get us back up to speed :-) Cheers all! Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 18:25:58 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 29 Apr 2004 11:25:58 -0700 Subject: [MOBY-dev] Update from the last developers meeting: MOBY-S API changes Message-ID: <1083263157.1632.41.camel@myhost.mydomain> Hi all, I am finally getting around to writing the update from our last developers meeting, hosted by Lincoln at CSHL. Thanks Lincoln! Well, the whisky and ideas flowed like a river :-) and as a consequence there were some important decisions made affecting the MOBY-S API: (1) The process of registering and deregistering a service will now become more of a "pull", rather than a "push"; your server will now host a simple RDF document that describes your service such that MOBY Central can GET this document on a regular basis to decide if your service is still registered and/or modified. Thus we don't need any fancy security model for deregistration, since presumably only you have access to your own server. This is quite Google-like. (2) The messaging XML format has changed slightly: (a) the moby:Query and moby:Response tags have now been merged into a single tag moby:mobyContent (b) the moby:queryInput and moby:queryResponse tags have now been merged into a single tag moby:mobyData -- these two changes now make the input message structure ~identical to the output message structure, thus we truly can pipe messages from one service to the next without fiddling with them. Change #1 has not yet been implemented, and might take a while. I'll try to make some progress on it this weekend. The idea is that you will register your service using the existing registerService API call as usual, with the inclusion of one additional parameter representing the location where you will store your service description RDF documents for MOBY Central to GET. MOBY Central will parse your registerService call and return you a registration Object as usual, however the registration Object will contain an additional parameter, representing the RDF document that describes your service as per the parameters you sent it - i.e. MOBY Central will create the RDF for you. You place the RDF in the location that you indicated in the registerService call and MOBY will troll your server every ~week to see if it is still there, and update the registry if it has changed. Change #2 will be implemented in the Perl libraries (e.g. MOBY::Client::Central and MOBY::CommonSubs), and hopefully also in the Java libraries, thus people using the libraries to create/parse the messages should not notice the change... so if you are not using the libraries, you should be! :-) I'm trying to ensure that both message structures are understood by these libraries so that we continue to have backward compatibility at least for a while. I'm going to update the API documentation on the web ASAP. I'll put the photo's from the meeting up on the web as soon as they have been edited for content... ;-) ;-) Cheers all! Mark -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre From mwilkinson at mrl.ubc.ca Thu Apr 29 22:39:56 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 29 Apr 2004 15:39:56 -0700 Subject: [MOBY-dev] CVS update required from all service providers Message-ID: <1083278395.1662.17.camel@myhost.mydomain> Hi everyone, All current service providers will need to cvs update their MOBY::CommonSubs module to bring everyone into sync with the message format changes. I just checked and all of my own services kicked back to life as soon as I updated, so as long as you are using the libraries a CVS update will fix everything and you wont have to change your services. ...I know... this was an ugly one... Sorry! :-( I hate changing the API, but we don't do this often, considering how young the project is! It's all for the best, though... or so they say ;-) Java people: If you do a simple substitution of Query -> mobyContent Response -> mobyContent queryInput -> mobyData queryResponse -> mobyData that is all that should be required to bring your code up to date with the API. M -- Mark Wilkinson (mwilkinson at mrl.ubc.ca) University of British Columbia iCAPTURE Centre