On 30 Jul 2010, at 16:35, Thomas Down wrote: > I'm going to go with Eugene, at least to the extent that treating '0' as a > magic index is ugly (and would seem to explicitly exclude the possibility of > ever applying DAS to coordinate systems which aren't 1..n).
A fair point. > Some of this comes down to whether positional and non-positional features are > likely to co-exist on a single DSN. My initial expectation is that they > don't -- but I'm not all that familiar with the conventions of protein DAS. > > If a given DSN is always either positional or non-positional, this seems like > a non-issue to me. > > If they do coexist then: > > a) I'd be quite interested to know more about the use-cases for this > so I can take them into account in my code. For some coordinate systems/servers it is either/or, but for others (specifically UniProt) the same source can provide both. For example, the location of SNPs (positional) and a publication citation (nonpositional). > b) I think there should be some way to distinguish between positional > and non-positional (in the TYPES response?) so Eugene's suggestion of > filtering on types is workable. > > I'm agnostic about whether there should be a difference between P99999 and > P99999:1,150... but if it helps, it would never occur to me to specify the > start and end when I'm expecting non-positional annotations. I guess what is most important is the reverse of this: i.e., would you be surprised to see nonpositional annotations if you specified P99999:1,150? I just checked uniprot's server and it does not return them if you do this. So either the spec as written needs to be changed to state that nonpositional features will not be returned if you specify start/end, or the uniprot server must be changed to return them. Either way, there is currently no way to get nonpositional features by themselves. Eugene's suggestion works if they can be identified in the types response as you suggest, but to be honest I can't say it's ever been a problem for me. I just request the whole segment, they're small enough that getting all the positional features too isn't an issue. Is anyone else bothered enough to add this? > Thomas. > > > > On Fri, Jul 30, 2010 at 4:00 PM, Andy Jenkinson <[email protected]> > wrote: > Hi list, > > I'd like to canvas for opinion on what is "expected" behaviour concerning how > servers respond to features queries in some circumstances. So, bear with me... > > Since protein DAS came along, the format of the segment parameter no longer > requires the start and end position. Personally, my take on this has always > been that this means that these two queries are effectively identical: > /das/source/features?segment=P99999 > /das/source/features?segment=P99999:1,150 [i.e. the full length of the > protein] > This interpretation is reflected in the 1.6 spec, with the advantage that it > is quite easy to explain the behaviour (use parts of the spec also use a "if > omitted, the default is XYX" paradigm). If you follow this interpretation, > nonpositional features (those without start/end positions) will always be > returned no matter what the start and end are, or indeed whether they are > included (since behaviour in both cases is identical). For me this is fine > because nonpositional features are annotations that apply to the whole > sequence/object, which includes all parts of it. > > Leyla came to a different view from me, reasoning that only the former of > these queries should return nonpositional features because they are really > outside the range of the second request. She has suggested that queries like > these could be possible ways to further control whether nonpositional and/or > positional features are returned: > /das/source/features?segment=P99999:0,0 [only nonpositional features] > /das/source/features?segment=P99999:0,150 [all positional and nonpositional > features] > > I guess this would be an additional functionality as I do not know of any > clients or servers that use zero as a meaningful query range, but i recognise > the logic so would like to know: what do others think? How do your existing > servers function? > > Sorry for the long email (as usual!) > > Cheers, > Andy > _______________________________________________ > DAS mailing list > [email protected] > http://lists.open-bio.org/mailman/listinfo/das > _______________________________________________ DAS mailing list [email protected] http://lists.open-bio.org/mailman/listinfo/das
