Hello,
Thanks Asia for clarify some of our doubts of your implementation.
I agree with the idea of answer with a confirmation or a detailed error,
specially if the writeback is going to process atomic requests, because
if the "here's what I want to do" is just one task, the answer just
could be or DONE or a detailed error (even if the error is about
dependencies with other features).
About the URI, can this URI be built using the uri in the base of the
document + the uri atributte in the feature??
So far I have implemented a parser for a document that follows the DAS/2
schema and uses the properties defined by Asia for the features, an
example to add or update(in the DAS/2 schema there is not difference
between those commands):
<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
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" /> ??
If anybody have any comments about what else should I include in this
document please let me know.
Cheers,
Gustavo.
Asia Grzibovska wrote:
Hello,
I have noticed a writeback thread in the mailing list and read it with a
big interest. I agree with most of the ideas expressed by participants.
The writeback specification was quite uncertain at the time when I was
implementing it, and the aim of my project was rather to prove the
concept. In principle it was proved, and writeback could be implemented
in the real-life. However, the writeback specification needs to be more
concrete.
1)about response to a writeback command. The response was a simple
confirmation, it did not contain features, because writeback was not so
complex. It saved exactly as "here's what I want to do". If the changes
were successfully saved into the database, a simple confirmation was
enough. Otherwise nothing was saved and a full error description was sent
back. The source code can be found here
http://code.google.com/p/daswriteback/source/browse/trunk/servlet/src/uk/ac/sanger/DatabaseUtilities.java
2)about URI. It is correct that "every feature in DAS/2.0 has a unique
URI". For simplicity I did not include it into the writeback document, but
it would be good to have it in the real implementation.
3)meta-annotations could simplify many things and add more functionality
<FEATURE uri="http//my.server/feat123" ... >
<PROP key="my_thoughts" value="overexpressed in tissue XYZ" />
<LINK href="http://somewhere.else/feat123"; rev="meta-annotation" />
</FEATURE>
Best regards,
Asia
Gregg Helt wrote:
On Fri, Oct 31, 2008 at 7:22 AM, Andy Jenkinson
<[EMAIL PROTECTED]>wrote:
I can't find a description of the response to a writeback command in
Asia's
thesis. Does it contain features (as in DAS2) or just a confirmation?
Take a look at the writeback spec (
http://biodas.org/documents/das2/das2_writeback.html ), it's much
shorter
than the retrieval spec, just a few pages.
The general idea is that a server may not be able to do all the
creations/edits/deletes a client is requesting in exactly the same form
the
client has specified, and furthermore that changes a client requests in
one
feature can possibly trigger changes in other features. Therefore the
semantics of the client request are "here's what I want to do" and the
writeback server responds with "here's what I actually did". In the
DAS2
writeback spec these are communicated mostly by passing back and forth
feature XML, except for deletion getting it's own special bit of XML.
I looked at the DAS2 spec, but I was wondering specifically about Asia's
implementation - whether it did the same or returned either a simple
confirmation or a DAS 1.53 features response.
_______________________________________________
DAS2 mailing list
[EMAIL PROTECTED]
http://lists.open-bio.org/mailman/listinfo/das2
_______________________________________________
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
