Gustavo Salazar wrote:
Hello,
Thanks Andy for the comments about the XML example .
I notice that in your message said that the attribute in PROP should be
"key" but in the example you used "name". I look into the schema and the
right one is "key".
Sorry about that!
About the LOC I'm still confused because if you see the answer(DAS/1.53)
the element SEGMENT has its own start and stop attribute, independently
of the start and stop attributes for each feature. And even the class in
MyDas indicates that the start and stop attributes are mandatory for
both segment and feature element. And thats why I though that the range
in LOC belongs to the segment and then the start and stop should be
extra properties. And so, if those values are about just the feature i
dont have any information about the segment position, and therefore I
won't be able to create an instance of Segment which is the type of the
return parameter for the function getFeatures of MyDas.
Yes, segment is used in the response to the 1.53 features command as a
way of organising the features. It means "the segment that the client is
interested in", because it is derived from the query parameters sent by
the client. In DAS/2 the "segment of interest" is not included in the
response, and indeed in writeback the client does not provide one.
In DAS/2, a feature can be located on more than one segment. In 1.53,
this can only be represented by repeating the same feature multiple
times - once per segment:
<SEGMENT id="foo">
<FEATURE id="A">
<START> 1 </START>
<END> 4 </END>
</FEATURE>
<FEATURE id="B">
<START> 21 </START>
<END> 35 </END>
</FEATURE>
</SEGMENT>
<SEGMENT id="bar">
<FEATURE id="A">
<START> 51 </START>
<END> 54 </END>
</FEATURE>
<FEATURE id="B">
<START> 71 </START>
<END> 85 </END>
</FEATURE>
</SEGMENT>
Notice the segment start and end are not informative - I haven't
included them in my example and yet we know the positions of each
feature within each segment. In DAS/2, the <SEGMENT> element is replaced
entirely with LOC elements (for several reasons):
<FEATURE id="A">
<LOC segment="foo" range="0:4" />
<LOC segment="bar" range="50:54" />
</FEATURE>
<FEATURE id="B">
<LOC segment="foo" range="20:35" />
<LOC segment="bar" range="70:85" />
</FEATURE>
Because features are no longer arranged within segments, the segment ID
is missing and so needs to be provided within each feature. This is
done in the <LOC> element, which also contains the equivalent of <START>
and <END>.
In short: do not worry about the segment start and end, they do not need
to be stored. You would only need to provide them if you were replying
to the writeback request with a 1.53 features response (which I believe
you are not doing). In such a case you would have to create a SEGMENT
for each feature (with the same start and end).
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
