[DAS] [DAS2] [Fwd: Re: Writeback implementation]

[Gustavo Salazar]

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
>>> <andy.jenkinson at gmail.com>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
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>>     
>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>