[DAS2] Re: Apollo and DAS/2 priorities

[Andrew Dalke]

Nomi:
>  the part i've
> completed--loading features from das2xml and displaying them in
> apollo--is definitely good in terms of bang for the buck, because you 
> can
> look at an IGB display and an apollo display of the same data and it's
> clear that they match.

The das2xml for features has changed some, but not much.  Most
changes are elsewhere.

> it's obviously important to get the GET requests working before we 
> submit
> the progress report; gregg and i hoping the updates to the GET spec 
> will
> be done very soon so that he can bring the server up to spec before the
> code sprint, since we clearly need a current working server available
> during the code sprint to use for testing.

I haven't changed the GET query parameters.  There might be some
changes to the feature filters as it handles the "att" queries.
Otherwise that's it.

I would like to make a semi-structural change.  I want to
split the search interface from the list of features.  Right
now we have

   /feature?filter=something

for searching and

   /feature/ABC123

for the actual feature.  The spec doesn't actually require that.
It only says that features have URL and that there's some way
to get to a URL for queries.

The SOURCE document contains a "SET" element which looks like

       <SET type="features" id="human/Fall_2005/features">
           <FORMAT name="das2xml" mimetype="text/x-das-type+xml" />
       </SET>

It says the DAS features are accessible through the URL
"http://../Fall_2005/features".  It doesn't mean those features
are located under that URL. This means we can have

   http://.../human/Fall_2005/features? -- the query interface
   http://.../human/Fall_2005/feature/0001 -- a feature

I like this better because I've been confused on the
differences between

   http://.../human/Fall_2005/features
and
   http://.../human/Fall_2005/features/

and between

   http://.../human/Fall_2005/features?exacttype=exon
and
   http://.../human/Fall_2005/features/?exacttype=exon

By separating the two there is no confusion.

Ditto for the "type" information.

> - gregg thinks the specs for source and type GETs are more stable than
> the feature GETs, so i could start trying to get source & type.

They are more stable.  The sources and types only return a list
of the available sources and types.  There is no other
query interface (as yet?).

> - andrew, if you could give me an updated das2xml example of features, 
> i
> can make sure that my das2xml reader is up to spec (right now i'm using
> das2xml from gregg's server, which is at least three months out of 
> date).

Done.  See just sent email.

>   - read sequence from a das2xml file

The term "das2xml" is used in the spec as the "name" for
various format types.  Against a "features" URL it returns a
features document, against a "types" URL it returns types.

I think that's also the context in which you are using it,
but I wasn't sure so decided to mention it.


> i may start working on reading sequence from a das2xml file first, 
> since
> that's a necessary step in order to read it from a server anyway.

I don't have any sample sequence files.  Those are going to
be in FASTA format.  There is a new query interface for this.  It
will look something like

   .../residues/Chr4?range=300:500:-1

(for the RC of the given range).  This is different than the old
spec which had something like

   .../residues/Chr4/300:500:-1

We discussed this in December and everyone (as I recall) was
fine with the change.  That hasn't made it into the updated
draft of the spec.  *sigh*

					Andrew
					dalke at dalkescientific.com