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

[Asia Grzibovska]

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
>