[MOBY-l] MOBY at NCGR/CSHL- intro to ISYS and its conceptual relationship to MOBY

[Mark Wilkinson]

I picked the one thing that I could respond to quickly - I'll have to 
chew on the rest of it for a while...

>I have deliberately singled out the
>"id" here, since you've put it at the root of the whole moby_class hierarchy.
>While there may be other reasons for insisting on an id for all objects
>in the system, in terms of its use as a "lookup", it really seems only relevant
>for services that want to do a retrieval of information using that key.
>
>  
>
I have to disagree, but only because we are putting different emphases 
on the idea of an "id".  The root of the class hierarchy is actually the 
Triple <Instance/Namespace/ID>.  In services which require only 
sequences (e.g. a service which calculates GC content or something like 
that) you are right in saying that the service doesn't need an ID. 
 However, we *do* need an ID if we are submitting a large number of 
sequences to that service (in a single transation) and receiving a large 
number of results in response.  The ID is the way to match the input 
with its output... especially since we do not guarantee that the service 
will provide a result for every input that it is given.

Namespaces and ID's can be entirely arbitrary, and in these cases can be 
used by the Client for local "bookkeeping" , or they can be meaningful, 
such as when you have a retrieve service which requires a genbankGI 
number as input.  This is why the namespace parameter is optional during 
service registration - if the service doesn't care, then it just leaves 
that parameter out and is thus "discovered"  by anyone who has the 
correct object *type* in their hands, regardless of that object's namespace.

I need to send the MOBY manuscript to the group - I'll ask BIB if they 
mind me distributing it prior to publication.  In any case, I'll send it 
to you first thing tomorrow (remind me).

Cheers!

m