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...).
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
