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

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

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
>
>

_______________________________________________
DAS mailing list
DAS at lists.open-bio.org

http://lists.open-bio.org/mailman/listinfo/das