Gustavo Salazar wrote:
<WRITEBACK xmlns="http://biodas.org/documents/das2";
xml:base="http://das.sanger.ac.uk:80/das/interpro/features";>
<MESSAGE>phosphoinositide 3-kinase in leukocytes</MESSAGE>
<FEATURES>
<FEATURE uri="G3DSA:1.10.1070.11" title="PI3/4_kinase_cat"
type="inferred from sequence similarity (ECO:0000044)" >
<LOC segment="O00329" range="830:1031" />
<PROP phase="-" />
<PROP score="0.0" />
<PROP commit_msg="added a new feature G3DSA:1.10.1070.11" />
<PROP user="http://user.myopenid.com/"; />
</FEATURE>
</FEATURES>
</WRITEBACK>
Then for this example the id for the feature will be the uri
http://das.sanger.ac.uk:80/das/interpro/features/G3DSA:1.10.1070.11
When updating a feature the URI field can be whatever would go into the
ID field, because both the server and the client need them to be the
same. The ID/URI can be assumed to be relative to the base of the
document in the same way as HTML relative links are processed. However,
your example is a URI in its own right because it contains a colon but no /.
Some examples:
URI - foo:something
base - http://das.sanger.ac.uk/das/interpro/features
final URI - foo:something
URI - something
base - http://das.sanger.ac.uk/das/interpro/features
final URI - http://das.sanger.ac.uk/das/interpro/something
URI - ./foo:something
base - http://das.sanger.ac.uk/das/interpro/features
final URI - http://das.sanger.ac.uk/das/interpro/foo:something
See page 26 of RFC3986, http://www.apps.ietf.org/rfc/rfc3986.html
So long as the absolute URI is derived in the same way for both servers
you should be fine using whatever the "base server" uses.
I'm not sure if this is the right way to submit the types... I'm parsing
the types element that is optional in the writeback document, however as
I understood that part of the document is used to add new types, which I
think is out of the scope of my project. Other issue that i have is
where should I put the information of the method maybe another PROP tag
like <PROP method="GENE3D" /> ??
It looks like only some of the fields in DAS are supported here, some of
those missing are constrained by the ontology (in parentheses):
type ID (e.g. SO:001234)
type label (e.g. exon)
type category (e.g. inferred from sequence similarity...)
method ID
method label
Really any of these can be changed so they should be represented. In the
interests of keeping your project manageable we can limit the
implementation to not adding new types (DAS and DAS/2 have different
ways of interpreting them anyway). But I can especially see a case for
changing the category (evidence). Since DAS/2 does not have an
equivalent for this, you could put it in a PROP element.
_______________________________________________
DAS mailing list
[email protected]
http://lists.open-bio.org/mailman/listinfo/das
