[DAS2] [DAS] [Fwd: Re: Writeback implementation]
asia at student.chalmers.se
Sun Nov 2 23:52:02 UTC 2008
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" />
> 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
More information about the DAS2