[DAS2] Fwd: [DAS] [Fwd: Re: Writeback implementation]
gregghelt at gmail.com
Tue Nov 4 23:02:41 UTC 2008
Forwarding more messages that didn't get cross-posted to das2 list:
---------- Forwarded message ----------
From: Gustavo Salazar <gustavo at nbn.ac.za>
Date: Tue, Nov 4, 2008 at 2:24 AM
Subject: Re: [DAS] [DAS2] [Fwd: Re: Writeback implementation]
To: Asia Grzibovska <asia at student.chalmers.se>
Cc: das at lists.open-bio.org
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
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
<WRITEBACK xmlns="http://biodas.org/documents/das2" xml:base="
<MESSAGE>phosphoinositide 3-kinase in leukocytes</MESSAGE>
<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/" />
Then for this example the id for the feature will be the uri
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.
Asia Grzibovska wrote:
> 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
> 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
> 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" />
> Best regards,
>> Gregg Helt wrote:
>>> On Fri, Oct 31, 2008 at 7:22 AM, Andy Jenkinson
>>> <andy.jenkinson at gmail.com>wrote:
>>>> I can't find a description of the response to a writeback command in
>>>> 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
>>> 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
>>> client has specified, and furthermore that changes a client requests in
>>> 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
>>> 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
>> DAS2 at lists.open-bio.org
> DAS mailing list
> DAS at lists.open-bio.org
DAS mailing list
DAS at lists.open-bio.org
More information about the DAS2