[DAS] DAS spec clarifications

[Lincoln Stein]

This whole thing came up a few weeks ago on the bioperl-l list.  After ranging 
a bit, we decided to talk it over at a bar during BOSC.  I'm still up for it.

Lincoln

LinOn Monday 22 July 20coln
02 12:17 pm, Steve Chervitz wrote:
> --- Ewan Birney <birney@ebi.ac.uk> wrote:
> > On Fri, 19 Jul 2002, Steve Chervitz wrote:
> > > Some issues came up in our internal discussion at Affymetrix about DAS
> > > that
> >
> > I'd
> >
> > > like clarification on:
> > >
> > > * Should the server perform a logical AND or an OR when a feature
> > > command specifies both type and category?
> > >
> > > * It would be nice if the feature command permitted method
> > > specification in addition to type and category. This would enhance the
> > > usefulness of the
> >
> > method
> >
> > > information you get back from the types command.
> > >
> > > * Does a server have to deal in 1-based sequence coordinates to be
> > > DAS1-compliant? I'm assuming yes, but it would be good to state so
> >
> > explicitly
> >
> > > in the spec. This is relevant to a recent thread on the Bioperl list:
> >
> > Yes.
> >
> > > http://bioperl.org/pipermail/bioperl-l/2002-July/008318.html
> > >
> > > Internally, we make much use of 0-based half-open intervals (or
> >
> > "inter-base"
> >
> > > coordinates as we call them, where the numbers refer to the positions
> > > in-between the bases). It would be great if a server could specify the
> > > coordinate system it uses. It would then be up to the client to do the
> > > appropriate conversion if necessary. Perhaps something for DAS2?
> >
> > I would vote against DAS coordinates changing - pick one, and stick to
> > it. In the broader public arena we have 20 years of legacy in one base,
> > inclusive coordinates. start = internal_start+1 is not a hard thing to
> > put in server side....
>
> I agree that conforming to a single system for servers is the way to go
> (don't know what I was on with my previous suggestion).
>
> However (and this is more of a general rant on the coordinate system
> issue), I don't want us to feel forever imprisoned by decisions we or
> others made in the distant past. If we hit upon a new way of doing things
> that most or all developers agree is better, then it's frustrating and
> somewhat irrational to say we should never change.
>
> Compatibility with widely used legacy systems is extremely important, but
> we should not let legacy systems stifle innovation. There is a path
> forward, but I have faith that we'll be careful in choosing it.
>
> In the case of DAS, which didn't exist when the legacy systems were
> designed, server-side adaptors will have to be created anyway to bring the
> legacy data into the DAS world. start = one_based_start - 1 is also easy to
> do.
>
> Steve
>
> > > Steve
> > >
> > > =====
> > > Steve Chervitz
> > > sac@bioperl.org
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Health - Feel better, live better
> > > http://health.yahoo.com
> > > _______________________________________________
> > > DAS mailing list
> > > DAS@biodas.org
> > > http://biodas.org/mailman/listinfo/das
> >
> > -----------------------------------------------------------------
> > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> > <birney@ebi.ac.uk>.
> > -----------------------------------------------------------------
> >
> > _______________________________________________
> > DAS mailing list
> > DAS@biodas.org
> > http://biodas.org/mailman/listinfo/das
>
> =====
> Steve Chervitz
> sac@bioperl.org
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das