[DAS2] DAS URI resolvability

[Andy Jenkinson]

Gregg Helt wrote:
> Sorry, I think I confused the issue again -- I seem to be on a 
> terminology abuse binge.  I used "addressable" and "addressability" in 
> referring to URIs when I should have used "identifiable" and 
> "identifiability".  Please mentally do s/addressable/identifiable/g and 
> s/addressability/identifiability/g on everything I've written in the 
> past week...
> 
> I think you and I are in agreement as far as whether DAS URIs should be 
> resolvable.  Quoting myself from a previous thread I forwarded to the 
> list last night (with terminology corrections applied):
> 
> In general as part of a spec revision (DAS 2.1?) I'd like to eliminate 
> more of the resolvability requirements in the specification, and specify 
> that most URIs be used as identifiers with _optional_ resolvability.  
> After two years of working with the current spec I've come to believe 
> that for most cases requiring resolvable URIs is not necessary, places 
> added burden on server implementations, and limits the ability to do 
> non-authoritative decentralized annotation.
> 
> The spec can be stripped down so that the only URI references required 
> to be resolvable are those specified by the "query_uri" attribute of the 
> CAPABILITIES element. 

Great, I think we're on the same page.

> The only problematic part in the DAS/2 annotation retrieval spec would 
> be the segment URIs.  The current spec needs these to be resolvable as 
> that's the mechanism used to retrieve residues for a particular 
> segment/sequence.  But I think this could be revised without too much 
> implementation overhead to merge residues retrieval and the segments 
> query to make something more like a hybrid of the DAS2.0 segments and 
> DAS1.53 sequence queries.

Keeping one eye on our plans for the future, I think it's worth bearing 
in mind that DAS has many more "coordinate systems" than genome 
assemblies, and only some of these are sequence.

DAS clients need to be able to get:
1. a list of reference entities
2. reference data (sequence, structure) for a single entity
3. annotation data (features, interactions) for a single entity

We could combine 1 and 2 as you suggest, but the size of the data would 
mean it would have to emulate separate command (i.e. get me a list of 
sequences, but don't give me the sequence) so we might as well keep them 
separate (e.g. entry_points + sequence; entry_points + structure).

Incidentally, the concept of a segment is far less important in DAS now 
so it's probably too specific as a command name (shout if that needs 
explanation...).