[DAS2] Re: Apollo and DAS/2 priorities

Andrew Dalke dalke at dalkescientific.com
Sat Jan 28 01:05:43 UTC 2006

>  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


for searching and


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

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


and between


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


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


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*

					dalke at dalkescientific.com

More information about the DAS2 mailing list