[MOBY-dev] java api

Sat Feb 19 07:38:30 UTC 2005

Hi Paul, Aloha from Honolulu! (just a stopover on the way to Sydney, unfortunately...)

Thanks for the offer of your time in doing some java code merging!

I had planned to write a message to the group shortly in this regard, so now seems a good moment to do so :-). It seems to me that Eddie is a good choice for the person who makes the final decisions for the moby java codebase structure if only because he is currently employed to do java moby 100% of his time.  This doesn't mean that he wouldn't discuss it with everyone else, just that he would take the time (and responsibility) for taking the "best of the best" code and consolidating it into a unified API.

I was thinking that the next moby meeting (May) would be a good time to talk about this face-to-face and make sure everyone knows the strengths and limitations of each others code.

Na?  Opinions?

M

-----Original Message-----
From: Paul Gordon <gordonp at ucalgary.ca>
Date: Thu, 17 Feb 2005 08:21:41 
To:Core developer announcements <moby-dev at portal.open-bio.org>
Subject: Re: [MOBY-dev] java api

It's great to see all of this code coming out, who new there were so 
many Java MOBY developers! :-)

We should really think about how to consolidate the best parts of the 
everyone's code into a cohesive object hierarchy.  This can be a bit 
tricky, since it's easy to feel insulted because some great code you 
wrote doesn't make it into the amalgam.  In practice, current coders 
will probably continue to use the classes they have already developed, 
since they've build other code around it, so the amalgam is more for the 
benefit of new Java coders.  I'm volunteering myself to take some of Ben 
and Eddie's PIB and RDF type-checking code and fold it into the existing 
MobyDataSimpleInstance. 

Yan, I haven't looked thoroughly, does your Java code use Jython to 
access your underlying Python implementation of the API?

Simon, what data instance classes are you planning on using for the Axis 
streamlining?

>Hi,
>  No, unlike Python, I can't generate on the fly classes so the MobyObject
>class is generic, it describes an Moby XML object as a class with
>attributes:
>
>  -prefix (default is moby, for XML serialization)
>  -tag (for the XML serialization and specify what kind of Moby object it is)
>  -namespace (Moby namespace eg AGI_LocusCode)
>  -id (object identifier)
>  -articleName (name of this object)
>  -other moby objects (described in the ontology)
>  -a raw content (the serializer only require this object to have a
>toString method)
>
>To determine what kind of object it is, I just look at the tag property
>with a getTag method.
>
>It is possible to build a specific object from this one using inheritance.
>
>This structure should be enough exhaustive to describe all possible Moby
>objects:
>
>    <Object1 namespace="aNamespace" id="anId">
>        <Object2 articleName="something">
>            <Object3 articleName="A">
>                   <Xref .../>
>                   <Xref ...>Description</Xref>
>                   RAW CONTENT for Object with article Name A
>            </Object3>
>        </Object2>
>        <Object4 namespace="aNamespace" id="anId"/>
>        RAW Content for Object 1
>    </Object1>
>
>Just have a look at the MobyObject class and the example MobyWebservice
>(the method getRandomDNASequence return a DNA sequence object).
>
>Yan
>
>  
>
>>What about accessing the rest of the contents of the data in a MobyData
>>block (ie the primitive values)?
>>
>>-Ben
>>
>>Octave Noubibou wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>as Yan has mentioned, i have joined  the PlaNet  project  at MIPS
>>>since  3  months  now. one of my first tasks was to provide a generic
>>>API to  simplify access to the pameters (queryID, namespace, id)
>>>one needs from the moby input xml to run the services and also methods
>>>to generate moby conform xml result.
>>>
>>>I have used DOM4J and XPATH to implement concrete classes for this
>>>purpose.
>>>At the moment all you need to get your parameters is to use the method
>>>"allParsedData(inputxml)" no matter how complex the inputxml is.
>>>This method return a vector of the form e.g.:
>>>
>>>(((queryID1,ns,id))) for a simple type
>>>
>>>or (((queryID1,ns1,id1),(queryID1,ns2,id2),(queryID1,ns3,id3))) for a
>>>collection
>>>
>>>or
>>>(((queryID1,ns,id),(queryID1,ns,id),(queryID1,ns,id)),((queryID2,ns1,id1)))
>>>for an input with 2 invocations, the first been a collection and the
>>>second a simple type.
>>>
>>>currently i do not handle secondary articles, but this should not be
>>>difficult.
>>>
>>>we habe tried in our java services and everything seems to be ok.
>>>
>>>i am commenting the code now. once it is finished, i will like to
>>>share it with you for comment or rectification and of course use.
>>>Is there any possibility to upload this in central repository?
>>>
>>>best regards
>>>
>>>octave
>>>
>>>      
>>>
>>>>Hi,
>>>> I know that someone at mips (Octave Noubibou) is also working on that
>>>>field, on my side, I have an API in Java (based on the Python API) that
>>>>helps me to build moby webservices (with axis or j2ee)
>>>>
>>>>
>>>>        
>>>>
>>>>>>Hi Mark,
>>>>>>
>>>>>>I'll see how things are looking and get the documentation together.
>>>>>>The
>>>>>>basic goal was to create some basic classes to simplify access to the
>>>>>>MOBY payload of a webservice call so that we could concentrate on
>>>>>>getting the services up rather than parsing the MOBY XML and
>>>>>>rewriting
>>>>>>the XML prior to returning the result. We've been using Axis to
>>>>>>handle
>>>>>>the webservice part of the equation, we've created some core classes
>>>>>>and have a simple test service prototype that we are gearing up to do
>>>>>>something meaningful with. If you have people doing similar things it
>>>>>>would be great to get an overview of what you are working on too so
>>>>>>we
>>>>>>can divide and conquer where possible.
>>>>>>
>>>>>>Simon.
>>>>>>
>>>>>>
>>>>>>On Feb 14, 2005, at 10:04 PM, mwilkinson wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>_______________________________________________
>>>MOBY-dev mailing list
>>>MOBY-dev at biomoby.org
>>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>MOBY-dev mailing list
>>MOBY-dev at biomoby.org
>>http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>>    
>>
>
>
>_______________________________________________
>MOBY-dev mailing list
>MOBY-dev at biomoby.org
>http://www.biomoby.org/mailman/listinfo/moby-dev
>
>
>  
>

_______________________________________________
MOBY-dev mailing list
MOBY-dev at biomoby.org
http://www.biomoby.org/mailman/listinfo/moby-dev

!!!!!!!!!!!!!!!!
To respond to this message you MUST send your response to (note new address!)

markw_mobile2 at illuminae dot com

Responses to the reply-to address go directly to trash!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!