[DAS] [Fwd: Re: Writeback implementation]

Gustavo Salazar gustavo at nbn.ac.za
Wed Oct 29 15:38:36 UTC 2008


Hi Andy,

The way I start to implemented is following the idea of interfaces that 
MyDas has. In such a way i just extend the skeleton of MyDas to support 
other kind of source called DasWritebackInterface, it allows that every 
group implement the writeback in different ways but all of them should 
provide the same capabilities(so far I define 3 methods, add, update and 
delete)
As the source class can implement more than one interface, my idea for 
the query is that the source should implement both the writeback and the 
annotation source and in that way the server will use the feature 
command to provide the annotations.
do you think that this way will be enough for the hypotetical case that 
you describe?

I've been thinking that the commands in the writeback document should be 
extended, because so far the defined commands are DELETES and UPDATES 
(no command meaning ADD). An idea that i have is to put a command 
SYNONYMS to tag 2 or more features that coming from different servers 
and give the same information.
On the other hand a control version for the annotations will be very 
useful and in such a case at least 2 new command will be required 
getHistorical to get all the meta-annotations done over one feature, and 
setCurrent to define which version of the meta-annotations should be used.

By the way, Im not familiar with the Dasmi project, what is the idea of 
those rankings?

Regards,

Gustavo.

Andy Jenkinson wrote:
> Forgot to send this to the list...
>
> -------- Original Message --------
> Subject: Re: [DAS] Writeback implementation
> Date: Wed, 29 Oct 2008 09:56:53 +0000
> From: Andy Jenkinson <andy.jenkinson at ebi.ac.uk>
> Organisation: European Bioinformatics Institute
> To: Gustavo Salazar <gustavo at nbn.ac.za>
> References: <49058C89.7050301 at nbn.ac.za>
>
> Hi Gustavo,
>
> The decentralised 'annotations of annotations' approach is a direction
> that is likely to see most adoption in my opinion because it doesn't
> require the original data provider to modify their source.
>
> Were you planning on using the existing "features" command in order to
> retrieve the annotations, or something else? I ask because it's feasible
> to imagine a DAS source that does not support writeback but still
> annotates another source's annotations. In fact the DASMI architecture
> already does this with it's scoring servers.
>
> Cheers,
> Andy
>
> Gustavo Salazar wrote:
>> Hello everybody,
>>
>> This is my first post in this list, therefore I'm going to start to 
>> introduce myself. I'm Gustavo Salazar, I'm currently busy doing my  
>> MSc degree in computer science in the University of Cape Town - South 
>> Africa.
>> The project that I'm working on is about the implementation of the 
>> writeback capabilities in the DAS client Dasty.
>> My original Idea was to use as a server the writeback implementation 
>> created by Asia and Andreas. However i've been notice that this 
>> implementation works as an extra server and Dazzle is kind of 
>> middleman between the clients and the writeback (am I wrong?) which 
>> sound like a good idea in terms of independence, but it looks to me 
>> that it will be hard for a client to identify if a  feature is 
>> original or has been edited.
>> That's why I decided to explore others alternatives and now I started 
>> to work reimplementing the server DAS writeback capabilities not in 
>> Dazzle but in MyDas.
>> I thing the writeback server should works as a meta-annotation 
>> server, which means that none of the modifications, additions or 
>> deletions will be actually changing the original server. in such a 
>> way a DAS client should see the information of the writeback as an 
>> extra layer, therefore it should first query regular DAS servers, 
>> built in memory the graphic, and at the end it will query the 
>> writeback server to modify this graphic with the community information.
>> In this way the user can choose to use the wb information or not.
>> I will use the protocol as in 
>> http://biodas.org/documents/das2/das2_writeback.html with the 
>> modifications that appears in the Asia's Theses. which implies the 
>> use of OpenId as the authorization system, I agree with the pros and 
>> and cons of OpenId that Andy posted, therefore if the consensus is to 
>> use another authorization system I will adapt my implementation.
>> I will appreciate any comment or suggestions or if anybody wants more 
>> details of my ideas please no hesitate in ask me.
>>
>> Regards,
>>
>> -- 
>> Gustavo Salazar
>> _______________________________________________
>> 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




More information about the DAS mailing list