[DAS] DAS 2.0 the real issue:

[Brian Gilman]

Hello again,

	I'd like to turn our attention back to the the 2.0 specification
for a little bit. While I believe the identifier problem is something we
will need to hash out, I would like to voice my opinion as to where we may
want to focus our attentions for the upcoming specification. 

	As Thomas has recently stated, the apache-axis, python soap, and
Soap::Lite frameworks are bringing the developer farther and farther away
from the actual SOAP headers, envelope etc. This allows the developer to
concentrate on the *objects* which are getting passed around and not the
XML encoding, namespaces used, etc. While this may be important in our
initial release of DAS 2.0, my opinion is that we should try and
concentrate on the /objects/ which we would like to pass around. To that
end, I would like to offer omniDAS as an object model and API which we are
using to perform DAS over SOAP. It follows the 1.0 specification very
closely for now. Once the identifier question stabalizes we will add this
facility as well as other queries and a link out facility
(Xlink/XPointer). 

	While there are still some technical issues to work out, I am
pleased to announce our first genomics service will be the DAS2ification
of our cSNP finding analysis pipeline's data (MITOG). This is working
internally and wil be released to the world in a few short weeks. 

	To get a sneak peak at this functionality all you have to do is
look in the omnitide package under omnigene. Unfortunately, you need to
checkout all the sourcecode for omnigene to get at omnitide. We will be
fixing this shortly. 

				Best, 

					-Brian

-----------------------
Brian Gilman <gilmanb@genome.wi.mit.edu>
Sr. Software Engineer MIT/Whitehead Inst. Center for Genome Research
One Kendall Square, Bldg. 300 / Cambridge, MA 02139-1561 USA
phone +1 617  252 1069 / fax +1 617 252 1902


On Wed, 28 Nov 2001, Lincoln Stein wrote:

> Hi Brian, Erich,
> 
> I agree with Brian that when we're talking about the request from the
> client to the server the class information isn't necessary.  When
> there's information coming back from the server to the client, it's
> useful for class information (Erich's OID_CLASS) to be attached to the
> identifier.
> 
> Lincoln
> 
> Brian King writes:
>  > 
>  > 
>  > > The pairing of OID and OID_CLASS represent discrete, fixed
>  > > minimum requirements for preservation of information content. 
>  > 
>  > I don't see why this is true.  The class information is in the datasource,
>  > not the client, so if you have a universally unique ID then the server
>  > should know how to retrieve and construct a class instance.  The data
>  > returned to the client should have enough information to determine the
>  > class.  
>  > 
>  > I can see that it would be convenient for the client to know the object
>  > class from the identifier prior to the query, but there are other ways to
>  > get that information.  For example, if the ID is a reference within an XML
>  > document, then you may know the class by the context, or at least know a
>  > base class.  Or you could query the server to say "what is the class of the
>  > object with ID 'ZZZZ'".  There have been cases in our systems we've changed
>  > data by moving it into a new subclass. But querying by ID would still return
>  > the same data.  Should the IDs now change to have the subclass name?  Should
>  > I be able to query by encoding either class or superclass in the ID?  Do we
>  > need to specify authority when we specify class to say whose ontology it is?
>  > I don't think embedding this type of meta-data in the ID will be a stable
>  > design.  
>  > 
>  > Regarding the I3C ID "paths", you're right that this is open to abuse.  I'd
>  > rather call the path a "hierarchy".  It is not a physical path in a
>  > filesystem or a path in a document; it is just a classification of the data
>  > source.  This seems consistent with the URN RFC.
>  > 
>  > Brian
> 
> -- 
> ========================================================================
> Lincoln D. Stein                           Cold Spring Harbor Laboratory
> lstein@cshl.org			                  Cold Spring Harbor, NY
> 
> NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. 
> PLEASE WRITE FOR DETAILS.
> ========================================================================
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das
>