[DAS] DAS spec clarifications

[Steve Chervitz]

--- 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