[MOBY-dev] jmoby using cached datatypes etc

Paul Gordon gordonp at ucalgary.ca
Thu Jun 26 15:44:09 UTC 2008


Hi Andreas & Martin,

The issue is that you should really be calling

new MobyDataObject("AGI_LocusCode", "at4g30110", central)

on the last line of your example, but of course it's not your fault.  
The org.biomoby.shared.data package takes Registry as an optional 
argument for all of the constructors, and I had a mechanism that allowed 
you to associate a Registry object with a cache.  Because we are moving 
to a unified caching mechanism, the ideal solution from my perspective 
would be for Registry to become an interface, Central extends Registry, 
and all of the CentralImpls are children of the old Registry object 
(which becomes RegistryImpl).  Martin, would you have any objections if 
I did this?  I think the Registry -> Central hierarchy makes sense as 
you move from metadata to metadata+data.

Of course, if you wanted to use the default central endpoint and caching 
directory, the

new MobyDataObject("AGI_LocusCode", "at4g30110")

call would be all that is required under the new system.

Regards,

Paul

groscurt wrote:
> this is an example code:
>
> Central central = new CentralDigestCachedImpl(
> "/home/pcb/groscurt/moby-live/Java/myCache" );
> MobyService mobyService = new MobyService();
> mobyService.setAuthority( "arabidopsis.org" );
> mobyService.setName( "Locus2Publications" );
> mobyService.setCategory( "" );
> mobyService = central.findService( mobyService )[0];
>
> MobyRequest mobyRequest = new MobyRequest( central );
> mobyRequest.setService( mobyService );
> mobyRequest.setInput( new MobyDataObject("AGI_LocusCode", "at4g30110") );
>
> running this starts to download the ontologies from biomoby.org. I guess the
> handling of the MobyRequest stuff is the problem here - but how to solve
> that ?
>
> Best and thanks
> andreas
>
> ----------------original message-----------------
> From: "Martin Senger" martin.senger at gmail.com
> To: "Core developer announcements" moby-dev at lists.open-bio.org
> Date: Wed, 25 Jun 2008 18:54:43 +0800
> -------------------------------------------------
>   
>>> but if i understand it correctly the CentralDigestCachedImpl does access
>>>       
> a
>   
>>> default moby registry and then caches it locally.
>>>       
>> Actually no. The class gets, in its constructor, a local directory where
>>     
> the
>   
>> cached ontology are located, and uses it. Only if the cache is empty, it
>> tries to fill it.
>>
>>
>>     
>>> What I'm interessted in is not to access any registry at all for getting
>>> the ontologies.
>>> My sitatuation is that i query the moby central to find some services
>>>       
> based
>   
>>> on e.g. their input and output parameters.
>>>       
>> The cache does not have the "find" method - we did not want to replicate
>>     
> the
>   
>> whole registry's API. But because all ontologies are locally available, it
>> is easy to get them all (that's why the class is also called "digest",
>> because it provides the cumulative methods that the registry's API does
>>     
> not
>   
>> provide in all cases) and iterate over them and make your search as you
>> wish.
>>
>> Martin
>>
>> -- 
>> Martin Senger
>> email: martin.senger at gmail.com,m.senger at cgiar.org
>> skype: martinsenger
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>
>>     
>
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> !DSPAM:60005,48622972109501804129376!
>
>
>
>   



More information about the MOBY-dev mailing list