From markw at illuminae.com  Sun Jun  3 21:52:58 2007
From: markw at illuminae.com (mark wilkinson)
Date: Mon, 4 Jun 2007 01:52:58 +0000 GMT
Subject: [MOBY-l] Fw: [MOBY-dev] The hijacked jMoby meeting in Vancouver
Message-ID: <1848373254-1180922039-cardhu_blackberry.rim.net-26936-@engine12-cell01>


--
Mark Wilkinson
...on the road!


-----Original Message-----
From: "mark wilkinson" <markw at illuminae.com>
Date: Mon, 4 Jun 2007 01:32:46 
To:Moby-dev at biomoby.org
Subject: [MOBY-dev] The hijacked jMoby meeting in Vancouver

Well, we just had a meeting of the core jMoby developers here in Vancouver.  The *intent* of the meeting was to consolidate the various Java toolkits, or at least to decide on a unified "face" to present to the world on the Java side of Moby, since there is a lot of overlap between the functionality of the various Java libraries (and increasingly on the Perl side as well) which makes it difficult for newcomers to navigate through what they are supposed to do.

But...

The meeting was hijacked!  The hijackers were Martin, Ivan, Paul and Me :-)

We ended-up discussing the core API, particularly in light of the recent deprecation of RPC encoding in SOAP (which is what Moby has used since the beginning)

You can browse the minutes of the meeting by clicking on the "General" blog category on the right hand column of the homepage.  There is a list of the 4 core API changes we are planning to implement, as well as the broader discussion of why we want to do this, and who is responsible for each one.  There is a TODO list of ~30 items that have been assigned to individuals at the meeting, but anyone in the Moby community is welcome to help in areas where they have specific expertise!

One of the most exciting developments was Paul Gordon's presentation of his SeaHawk Moby client.  Access to Moby from any web browsing session, and the auto-mobyfication of any web resource!  Absolutely amazing!!!  The usefulness of Moby is about to explode!!!!!!  We should all pay close attention to this client and utilize it/extend it as best we can as it is (IMO) the most powerful client we have seen so far!

Best wishes everyone!!

Moby-on!

Mark

--
Mark Wilkinson
...on the road!

_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev


From gordonp at ucalgary.ca  Mon Jun  4 10:50:36 2007
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon, 04 Jun 2007 08:50:36 -0600
Subject: [MOBY-l] [MOBY-dev] The hijacked jMoby meeting in Vancouver
In-Reply-To: <1671640238-1180920829-cardhu_blackberry.rim.net-1514-@engine08-cell01>
References: <1671640238-1180920829-cardhu_blackberry.rim.net-1514-@engine08-cell01>
Message-ID: <466426BC.3070101@ucalgary.ca>

Hi all,

While I appreciate Mark's plaudits, he has stolen a bit of my thunder :-)

My Seahawk manuscript should be published on-line in the next couple of 
weeks (it is now "accepted in principle" by the journal),
and in preparation for that, I am making some minor but critical updates 
to the applet so it does not overload MobyCentral
as more people use it. I'll post to the mailing lists when this "public" 
version is ready.  I will also setup somewhere where bugs can be
formally lodged by users.  This way I can be sure to fix them promptly!

The "auto-mobyfication" of any Web form is, alas, not part of Seahawk 
yet.  While I have done prototyping of this (and hence the
convincing screenshots Mark saw), it is a few months away from going 
into the public version.  Nevertheless, it is my primary focus
now and I am keen to unleash it on the world!

Regards,

Paul
> One of the most exciting developments was Paul Gordon's presentation of his SeaHawk Moby client.  Access to Moby from any web browsing session, and the auto-mobyfication of any web resource!  Absolutely amazing!!!  The usefulness of Moby is about to explode!!!!!!  We should all pay close attention to this client and utilize it/extend it as best we can as it is (IMO) the most powerful client we have seen so far!
>
> Best wishes everyone!!
>
> Moby-on!
>
> Mark
>
> --
> Mark Wilkinson
> ...on the road!
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> !DSPAM:60005,46636ce88021640413918!
>
>
>
>   


From mikedebo at gmail.com  Tue Jun 12 17:58:47 2007
From: mikedebo at gmail.com (Michael DiBernardo)
Date: Tue, 12 Jun 2007 14:58:47 -0700
Subject: [MOBY-l] Datatype queries on central registry with jmoby API
Message-ID: <36DD05E7-9C7F-4479-8532-4D79EC83B419@gmail.com>

Hello all,

I'm working on a project where I'd like to be able to

(a) Get the definitions of all services from the registry
(b) Examine the inputs and outputs for each service
(c) Get a list of all _subclasses_ and all _children_ (i.e. types of  
which the type is composed) of the input and output parameter types.

Using the jmoby API, I do roughly the following as a stripped-down test:

		CentralDigestCachedImpl digest = new CentralDigestCachedImpl("/tmp");
		MobyService[] services = digest.getServices();
				
		for (int i = 0; i < 100; i++) {
			MobyService example = services[i];
			System.out.println(example.getName());
			
			// Just fetch the first output for now as a test.			
			MobyPrimaryData output1 = (example.getPrimaryOutputs())[0];
			System.out.println("Output is " + output1.getName());			
			
			MobyDataType type = output1.getDataType();
			MobyRelationship[] children = type.getAllChildren();
			System.out.println("Data type has " + children.length + "  
relationships.");
			
			for (MobyRelationship child : children) {
				System.out.println(child);
			}
		}

Note that I am doing this just to get the types of which the output  
type is composed. However, in each case the number of children  
returned by the getAllChildren call is 0. A similar thing happens if  
I request the names of the parent types of any of the input or output  
data types; 0 parents are returned. I can't even find a way of  
getting the _subclasses_ of a type, since there doesn't appear to be  
a getAllSubclasses() call on MobyType, just a getParents().

I wrote my own utility class that uses Jena to parse the Object  
ontology RDF to fetch the parents of any type, and I could do the  
same in order to get all of the components of any type, but I'd  
rather not dodge the API if I don't have to. Does anyone have any  
idea why the types of the parameters returned by the getPrimaryInputs/ 
getPrimaryOutputs calls aren't being completely populated? Also, does  
anyone have any suggestions of a nonhacky way to find the _subclass_  
of a given type as easily as one can find its superclass?

It seems to me that fetching the subclasses of a type would be a far  
more common operation than examining parents, because if you're  
writing any kind of software to orchestrate calls to MOBY services  
and you require an input to be of type T, you'd also want to admit  
any subclasses of type T as well. The parent classes, on the other  
hand, are irrelevant in this context. So basically I assume that this  
is possible and I'm just too stupid to figure it out.

Pointers would be appreciated!

-Mike

From gordonp at ucalgary.ca  Wed Jun 13 09:54:36 2007
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Wed, 13 Jun 2007 07:54:36 -0600
Subject: [MOBY-l] Datatype queries on central registry with jmoby API
In-Reply-To: <36DD05E7-9C7F-4479-8532-4D79EC83B419@gmail.com>
References: <36DD05E7-9C7F-4479-8532-4D79EC83B419@gmail.com>
Message-ID: <466FF71C.2090904@ucalgary.ca>

Hi Mike,

Actually, the opposite is true.  Suppose you are a service provider, and 
you accept class X. 
If you receive class Y, you want to see if it it inherits from class X.  
To do this, you recursive ascend the parents of Y until the
you reach X, or the ontology root ("Object").  This is considerably less 
expensive , i.e. O(log n) than a depth or breadth-first search of
the subclass trees, i.e. O(n). 

Checking subtypes would be useful for explicit cast operations though.
> It seems to me that fetching the subclasses of a type would be a far  
> more common operation than examining parents, because if you're  
> writing any kind of software to orchestrate calls to MOBY services  
> and you require an input to be of type T, you'd also want to admit  
> any subclasses of type T as well. The parent classes, on the other  
> hand, are irrelevant in this context. So basically I assume that this  
> is possible and I'm just too stupid to figure it out.
>   


> Pointers would be appreciated!
>   
With regards to your other questions, I'll have to take a closer look at 
the code and get back to you. 
> -Mike
> _______________________________________________
> moby-l mailing list
> moby-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-l
>
> !DSPAM:60005,466f171b80213255910610!
>
>
>
>   


From mikedebo at gmail.com  Wed Jun 13 10:57:32 2007
From: mikedebo at gmail.com (Michael DiBernardo)
Date: Wed, 13 Jun 2007 07:57:32 -0700
Subject: [MOBY-l] Datatype queries on central registry with jmoby API
In-Reply-To: <466FF71C.2090904@ucalgary.ca>
References: <36DD05E7-9C7F-4479-8532-4D79EC83B419@gmail.com>
	<466FF71C.2090904@ucalgary.ca>
Message-ID: <96075767-F177-4AB6-8EAF-B63FDD252299@gmail.com>


On 13-Jun-07, at 6:54 AM, Paul Gordon wrote:

> Hi Mike,
>
> Actually, the opposite is true.  Suppose you are a service  
> provider, and you accept class X. If you receive class Y, you want  
> to see if it it inherits from class X.  To do this, you recursive  
> ascend the parents of Y until the
> you reach X, or the ontology root ("Object").  This is considerably  
> less expensive , i.e. O(log n) than a depth or breadth-first search of
> the subclass trees, i.e. O(n).

Yes I realized this a couple of hours after I sent the previous  
email... another example of me jumping to conclusions before  
thoroughly thinking it through. Thanks for the verification.

> Checking subtypes would be useful for explicit cast operations though.
>> It seems to me that fetching the subclasses of a type would be a  
>> far  more common operation than examining parents, because if  
>> you're  writing any kind of software to orchestrate calls to MOBY  
>> services  and you require an input to be of type T, you'd also  
>> want to admit  any subclasses of type T as well. The parent  
>> classes, on the other  hand, are irrelevant in this context. So  
>> basically I assume that this  is possible and I'm just too stupid  
>> to figure it out.
>>
>
>
>> Pointers would be appreciated!
>>
> With regards to your other questions, I'll have to take a closer  
> look at the code and get back to you.

Thank you!

-Mike


From gordonp at ucalgary.ca  Mon Jun 18 12:41:35 2007
From: gordonp at ucalgary.ca (Paul Gordon)
Date: Mon, 18 Jun 2007 10:41:35 -0600
Subject: [MOBY-l] Seahawk MOBY Client published
Message-ID: <4676B5BF.2060206@ucalgary.ca>

Hello fellow MOBYers,

I am dropping you a line to let you know that our Seahawk applet for 
using MOBY services has just been published (provisional PDF):

Gordon P.M.K., Sensen C.W. (2007) Seahawk: Moving Beyond HTML in 
Web-based Bioinformatics Analysis 
<http://www.biomedcentral.com/content/pdf/1471-2105-8-208.pdf>. /BMC 
Bioinformatics/ <http://www.biomedcentral.com/bmcbioinformatics/> 8:208.

This weekend, I updated the MOBY CVS and also posted an updated version 
of the applet to

http://moby.ucalgary.ca/seahawk

Seahawk is a customizable, drag 'n' drop style browser that links MOBY 
with existing files, Web pages and data formats.  It will
/eventually/ allow you to wrap existing Web forms as MOBY Services using 
the same drag 'n' drop mechanisms.
Any and all comments (especially bug reports) are welcome!

Kind Regards,

Paul Gordon

From markw at illuminae.com  Mon Jun 18 13:23:33 2007
From: markw at illuminae.com (Mark Wilkinson)
Date: Mon, 18 Jun 2007 10:23:33 -0700
Subject: [MOBY-l] Moby Central access logs - FYI
Message-ID: <op.tt4nxkminbznux@personalpc>

Hi all,

I'm in the process of generating a progress report for Genome Canada on  
the BioMoby project, and have just run a series of statistics on the  
access logs.  The last time I reported this to the list there was some  
discussion about how "meaningful" these statistics were, since we couldn't  
discern who/why the "hits" were being made.

We've added user agent reporters into most of our software now, so I can  
report the statistics somewhat more accurately:

mobycentral.icapture.ubc.ca
For the month of May, 2007
--------------------------

Total Hits:  804,945  (our highest number ever!)

This breaks down as follows:

647,091 - mobycentral.pl (the main API interface)
71,540 - OntologyServer  (the API to query the ontology)
64,237 - Services.cgi (the daemon serving my Moby Services)
13,240 - Moby Pinger (the check if services are "alive")
9,738 - the RSS feeds
822 - Gbrowse Moby (the simple CGI client)


Language-wise we have the following:

107,438 - MOBY::Client::Central (my Perl client)
446,334 - Axis
157,796 - SOAP::Lite (someone else's Perl client?)


Geographically, the accesses break down as follows:

14.96%	.de (Germany)
14.17%	.ca (Canada)
12.79%	[unresolved numerical addresses]
11.52%	.uk (United Kingdom)
9.88%	.edu (USA Higher Education)
3.02%	.org (Non Profit Making Organisations)
2.76%	.net (Networks)
2.41%	.fr (France)
2.35%	.nl (Netherlands)
1.78%	.com (Commercial)
1.78%	.es (Spain)